Policy template · ISO 27001 / Cyber Essentials
Access control policy template
Who gets access, who approves it, and how fast it goes when people leave. A ready-to-edit Word access control policy that meets ISO 27001 A.5.15, A.5.18 and A.8.2 and supports Cyber Essentials, written for a UK firm of 25 to 250 people.
Key takeaways
An access control policy sets who may access your systems, who approves it, and how access is reviewed and removed. ISO 27001 controls A.5.15, A.5.18 and A.8.2 require access rules, a managed access lifecycle and restricted privileged access. This Word template covers joiners, movers and leavers, admin accounts, MFA and reviews for UK firms of 25 to 250 staff.
- Required by
- ISO 27001:2022 controls A.5.15, A.5.18 and A.8.2. Cyber Essentials tests the controls, not a policy
- Approved by
- Top management; system owners approve each grant
- Review cycle
- Policy annually; privileged access quarterly; other access at least annually
- Format
- Word, about 14 pages, with an access matrix and review record
A developer leaves in March. In September an auditor samples three leavers, and one of them can still sign in to the cloud console, because that console was never connected to single sign-on and nobody owned the step. An access control policy is where that step gets an owner. This template gives a UK firm of 25 to 250 staff a ready-to-edit access control policy in Word, mapped to ISO 27001 controls A.5.15, A.5.18 and A.8.2, with joiners, movers and leavers, privileged accounts, MFA and access reviews already covered.
What's in the template
One Word document, about 14 pages, version 1.0. It has four parts.
- The access control policy. Scope (people, systems, premises and service accounts), access principles, roles, identities and accounts, joiners, movers and leavers, privileged access, authentication and MFA, access reviews, supplier access, physical access, exceptions, and what happens when the policy is broken.
- Ready-to-use appendices. An access control matrix of roles against systems, a privileged accounts register, an access review record, and joiner, mover and leaver checklists you can turn into ticket templates.
- A getting-started guide and next steps. Which sections to tailor first, which options to choose between, and where the policy sits beneath your information security policy.
- A policy management checklist. Approval, named system owners, the first access review and a test leaver traced end to end: the records an auditor asks to see alongside the policy.
Every placeholder is in square brackets, and where firms genuinely differ (leaver timing, inactivity periods, standing or just-in-time admin, review cadence) the template offers worded options to pick from. Choose, delete the rest, and the policy is ready for management approval.
What is an access control policy?
An access control policy is the document that sets who may access your information and systems, on what basis, who approves it, and how that access is changed, reviewed and removed. It covers people and machines, cloud and premises, staff and suppliers. It's written for the people who run access: system owners, IT, HR and line managers.
The policy is where least privilege stops being a slogan. It names who owns each decision, how fast leavers lose access, which accounts count as privileged and how often someone checks. Customers ask for it for the same reason auditors do. A security questionnaire that asks "how quickly is access removed when staff leave?" or "is MFA enforced for administrators?" is asking about your access control policy, whether it says so or not.
Which standards require one
ISO 27001 asks for access control rules directly. Cyber Essentials doesn't ask for a policy document, but it tests the controls a good policy describes.
| Standard or source | What it asks for |
|---|---|
| ISO 27001:2022, control A.5.15 | Rules to control physical and logical access to information and other associated assets must be established and implemented, based on business and information security requirements. |
| ISO 27001:2022, control A.5.18 | Access rights must be provisioned, reviewed, modified and removed in line with your access control policy and rules. |
| ISO 27001:2022, control A.8.2 | The allocation and use of privileged access rights must be restricted and managed. |
| ISO 27001:2022, controls A.5.16, A.5.17 and A.8.5 | The full lifecycle of identities is managed, authentication information is allocated and handled under a management process, and secure authentication is implemented in line with the access control policy. |
| Cyber Essentials (user access control) | No policy document is required. The requirements expect a process to create and approve user accounts, unique credentials, removal or disabling of accounts when no longer needed (such as when someone leaves, or after a defined period of inactivity), MFA wherever available and always for cloud services, separate accounts for administrative work, and removal of special privileges when no longer needed. Accounts used by suppliers and managed service providers are in scope. |
| Customer due diligence | Security questionnaires commonly ask how access is approved, how quickly leavers are removed, whether MFA is enforced and when access was last reviewed. |
For the control detail, see the ISO 27001 A.5.15 access control guide, which covers deny-by-default, role granularity and service accounts. The lifecycle and review mechanics are in the A.5.18 access rights guide, and admin accounts in the A.8.2 privileged access rights guide. Identity and authentication have their own guides: A.5.16 identity management, A.5.17 authentication information and A.8.5 secure authentication.
How to create your access control policy with this template
With the groundwork in place, this takes about a day of drafting spread over a week, because system owners need to confirm their part, plus one management meeting. Without the groundwork, the policy will describe access you can't actually see, so check that first.
Before you start
An access control policy is only as true as your picture of where people sign in. Check you have:
- An information security policy. The access control policy sits beneath it and should use the same scope and owner. No top-level policy yet? Start with the information security policy template and the A.5.1 guide.
- A list of systems, each with an owner. Every SaaS tool, cloud console and line-of-business system people sign in to, and a named business owner who decides who needs it. No list yet? Your single sign-on catalogue, expense claims and finance's card statements are the quickest way to build one. The A.5.9 guide shows how it becomes your asset inventory.
- An HR trigger. A way for HR or line managers to tell whoever runs access that someone is joining, moving or leaving, with a date. No trigger yet? Agree one before you write the leaver section, because the policy will promise a timing that depends on it.
- An identity provider, or a plan for one. Most firms of this size already have one through their email platform. If some systems sit outside it, list them: they are where leavers keep access.
If none of these exist yet, the job is bigger than one policy. That's the point where most firms bring in help.
1. Map who needs what (2 to 3 hours, spread over a few days)
- Do this: fill in the access control matrix. List your job roles down the side and your systems across the top, mark the access level each role needs, and have each system owner confirm their column.
- The template: has the matrix laid out with example roles and system categories, so you're correcting a draft rather than designing one.
- Watch for: systems nobody owns. If no one will put their name to who should have access to the finance tool, nobody will approve requests or review it either. Name an owner before you go further.
2. Write the principles and roles (about an hour)
Next, adapt the sections on access principles and responsibilities: least privilege, deny by default, access decided by the system owner rather than IT, and who does what between HR, line managers, system owners and whoever administers your identity provider. The template has each role written in with [placeholders] for names. Keep the principles short. Their job is to settle arguments later, when someone asks for access "just in case".
3. Set the joiner, mover and leaver rules (1 to 2 hours)
- Do this: choose how fast leavers lose access, what happens on a move, and how long an unused account stays active before it is disabled. Then check each answer with HR and with whoever will actually do the work.
- The template: offers worded options for leaver timing (same working day, or within a set number of hours), inactivity periods, and the order of a move: remove the old role's access before adding the new.
- Watch for: a leaver rule the process can't meet. If HR tells IT about leavers a week late, "same working day" is untrue on the day it's approved. Fix the trigger first, or write the timing you can actually evidence.
4. Decide how privileged access and authentication work (about an hour)
Then write down which accounts count as privileged (domain and cloud admins, finance approvers, anyone who can create accounts or change security settings) and the rules they follow: a separate admin account used only for admin work, MFA on every one, approval by a named person, and a register of who holds them. Cyber Essentials expects separate admin accounts and MFA on cloud services, so this section does double duty. For passwords, follow NCSC guidance: length over complexity, a password manager, and no forced expiry. The template points to your acceptable use policy for the rules staff follow day to day.
5. Set the review cycle, then approve and publish (one management meeting, then 2 to 3 hours for the first review)
- Do this: set how often each system is reviewed and by whom, take the policy to management for approval, then run the first access review straight away, on your privileged accounts and most sensitive systems.
- The template: includes an access review record, a privileged accounts register and a policy management checklist for approval, reviews and the next review date.
- Watch for: a review cadence you won't keep, and reviews that never remove anything. Both are covered in How to use it so it holds up at audit.
A leaver rule nobody can evidence is a hope, not a control.
Do it yourself, or have us do it with you
| Do it yourself with the template | Do it with GRCMANA | |
|---|---|---|
| What you end up with | An approved access control policy and a first access review | This policy plus the access matrix, joiner-mover-leaver procedure, privileged access register and the related ISO 27001 and Cyber Essentials policies, consistent with each other, with leaver disables tied to HR events |
| Your time | About a day over a week, plus a meeting, if the groundwork is in place. Considerably more if it isn't | Agreed at scoping, depending on how many systems and owners are already mapped |
| Best if | You know where people sign in, every system has an owner, and someone can make the leaver and admin calls | Compliance landed on you alongside your day job, nobody is sure how many SaaS tools you use, the audit or Cyber Essentials date is fixed, or a client questionnaire is waiting on your answer |
Prefer the second column? Talk to us about ISO 27001 readiness.
What does a good access control policy look like?
Most access control policies state least privilege and stop there. The good ones say who decides, how fast, and how anyone would know it happened.
Weak and strong, side by side
| Clause | Weak | Strong | Why the strong one passes |
|---|---|---|---|
| Least privilege | "Users are given the access they need." | "Access is granted from the role profiles in [Appendix A]. Anything beyond the profile needs approval from the system owner, with a reason and an end date." | It names a baseline and an approver, so a grant can be traced. |
| Leavers | "Access is removed promptly when staff leave." | "Accounts are disabled by the end of the leaver's last working day, or at notification for contentious exits. HR raises the leaver ticket at least [5] working days before the leaving date." | An auditor can compare HR dates with disable timestamps. "Promptly" can't be tested. |
| Privileged access | "Admin access is restricted." | "Administrative tasks are done only from separate admin accounts, listed in [Appendix B], protected by MFA and approved by [CTO]. Admin accounts are not used for email or web browsing." | It matches A.8.2 and the Cyber Essentials requirement for separate admin accounts. |
| Authentication | "Strong passwords must be used." | "Every cloud service and remote access route uses MFA through [identity provider]. Passwords are at least [12] characters, stored in [password manager], and changed only when compromise is known or suspected." | It follows NCSC guidance and sets MFA as the rule, not the extra. |
| Reviews | "Access is reviewed regularly." | "System owners review privileged access and [critical systems] quarterly, and all other access at least annually. Each review records a decision for every account, and removals are completed within [5] working days." | A cadence, an owner and a decision per line are what a review record has to show. |
What an auditor checks in the first five minutes
Before reading the detail, most auditors check that:
- It's current. It has a version, an approval date and a review date that hasn't passed.
- Every system has an owner. The matrix or inventory names who approves access to each system, including the SaaS tools outside single sign-on.
- Leavers really leave. The policy states a timing, and a sampled leaver's accounts were disabled within it.
- Admins are known. There's a current list of privileged accounts, each with an owner and MFA.
- Reviews happen. The last review is recorded, on the cadence the policy states, and it removed something.
- Suppliers are covered. Accounts held by contractors and your managed service provider are named and time-limited.
If all six hold, the auditor moves on with confidence. If one fails, they tend to sample harder.
What good looks like at 25 staff and at 250
| Feature | Around 25 staff | Around 250 staff |
|---|---|---|
| Length | About eight pages, with the matrix as a one-page appendix | Eight to ten pages, with a separate joiner-mover-leaver procedure |
| Roles | A handful of role profiles, most access through one identity provider | Role profiles per team or job family, provisioned automatically from HR events |
| Privileged access | Two or three named admins with separate admin accounts and MFA | Just-in-time elevation or a privileged access tool, with alerts on admin group changes |
| Access reviews | Privileged accounts quarterly, everything else annually, done by a director in a spreadsheet | Privileged and critical systems quarterly, the rest at least annually, run as campaigns by system owners |
| Leavers | A shared checklist, disabled the same day by whoever runs IT | HR-driven disables through the identity provider, with a report of anything outside it |
| Owner | A director alongside their main role | An IT or security lead, with HR as co-owner of the joiner-mover-leaver process |
The common mistake at 25 staff is a policy written for an enterprise identity team: quarterly reviews of every system that nobody has time to run. The common mistake at 250 is the reverse, a policy written when everything sat behind one sign-in, silent on the SaaS tools teams have bought since.
How to use it so it holds up at audit
The policy is only half the evidence. An auditor tests whether it operates, and these are the records they usually ask for:
- The approval record: who approved this version, and when.
- Joiner records: an approval from the system owner for each sampled joiner, dated before the account was created.
- Leaver records: HR leaving dates alongside account disable dates, for every system the leaver used, not only the identity provider.
- The privileged accounts register: current, with an owner, approval and MFA status for each account.
- Access review records: the reviewer, the date, a decision for every account, and proof that removals were carried out.
- Exceptions: each with a reason, an approver and an end date that hasn't passed.
The most common reasons this policy fails audit:
- A sampled leaver still has an active account in a system outside single sign-on.
- Reviews are recorded as "no changes" every time, or the cadence in the policy hasn't been met.
- Admins use one account for everything, or MFA has exceptions nobody approved.
- Shared or generic accounts exist that the policy doesn't mention.
- Supplier or managed service provider accounts have no owner and no end date.
Each of these is cheaper to fix now than to explain in the audit room.
Access control policy questions
Who and what it covers, the access principles (least privilege, need-to-know, deny by default), who approves and who provisions, how accounts and identities are managed, the rules for joiners, movers and leavers, privileged access, authentication and MFA, how often access is reviewed, supplier access, exceptions, and what happens if the policy is broken.
Privileged accounts and your most sensitive systems are commonly reviewed quarterly, and everything else at least annually, with an extra review after a restructure or an incident. Choose a cadence you will keep: a review that happens on time and removes something counts for more than an ambitious schedule that slips.
By the end of their last working day is a defensible standard, and at the point of notification when the exit is contentious or the person has sensitive access. The policy should state the timing, and your HR process has to tell IT early enough to meet it.
Least privilege means each person, and each service account, gets only the access their role needs, and no more. In practice it means granting access from defined role profiles rather than copying another user, and removing access when a role changes.
Yes, as good practice and for Cyber Essentials, which expects separate accounts for administrative work. The admin account is used only for admin tasks, never for email or browsing, so that a phishing link opened from an everyday account doesn't run with admin rights.
Get the template
Start from a policy that already covers joiners, movers and leavers, admin accounts, MFA and access reviews, written for a firm your size. Download the Word template, fill in the matrix, and run your first access review the week it's approved.
This template is a starting point to adapt to your organisation, not legal advice.
