ISO 27001 Access Control Policy Template: Annex A Controls + Free Skeleton

An access control policy is usually the first ISO 27001 document that falls apart under audit pressure. It looks fine on the surface — a page or two of generic statements about “authorised users” — until an auditor asks who reviewed the marketing manager’s admin rights after she left eight months ago, or why three service accounts still have domain admin privileges nobody remembers assigning. At that point, the policy stops being a document and starts being evidence, and evidence needs to map to specific Annex A controls.

This guide covers exactly which ISO 27001:2022 Annex A controls an access control policy needs to address, why least privilege and role-based access should sit at its center, how it overlaps with the access control obligations already inside NIS2 Article 21(2)(i), and the audit findings that come up most often when this policy is written once and never touched again. It also includes a free mini policy skeleton you can adapt directly — see the ISO 27001 compliance guide for how this policy fits into the wider clause structure and Annex A control set.

Which Annex A Controls Does an Access Control Policy Actually Need to Cover?

“Access control policy” is often treated as shorthand for a single Annex A control, but ISO 27001:2022 spreads the topic across seven controls in two of the standard’s four Annex A themes. Four sit in the Organizational theme and set the policy-level rules; three sit in the Technological theme and govern how those rules get implemented in systems. A policy that only addresses one cluster and ignores the other will not hold up to a competent internal or certification audit.

Control	Title	What It Requires
A.5.15	Access Control	A documented, topic-specific access control policy based on business and security requirements [2]
A.5.16	Identity Management	A managed lifecycle for the identities of all users, systems, and services — creation, uniqueness, and eventual deactivation [4]
A.5.17	Authentication Information	Controlled allocation and protection of passwords, keys, and other authentication information across their lifecycle
A.5.18	Access Rights	Formal granting, periodic review, and prompt removal of user access rights, including privileged rights
A.8.2	Privileged Access Rights	Restriction and tighter management of privileged/administrative access, treated as high-risk and reviewed more often [3]
A.8.3	Information Access Restriction	Access to information and application functions actually restricted in line with the access control policy, not left to default permissions
A.8.5	Secure Authentication	Secure authentication technologies and procedures (e.g. multi-factor authentication) applied where risk warrants it

A useful way to read this table: A.5.15-A.5.18 answer “what is our rule and who owns which identity and right,” while A.8.2, A.8.3 and A.8.5 answer “how is that rule actually enforced in our systems.” Auditors commonly test both halves separately — a well-written policy document with no corresponding system evidence (or vice versa) is one of the more common non-conformities raised in this area.

Least Privilege and Role-Based Access: The Policy’s Backbone

Every one of the seven controls above ultimately serves one principle: give people, systems, and services the minimum access they need to do their job, and nothing more. ISO 27001 does not mandate a specific access model, but role-based access control (RBAC) is by far the most common way organisations operationalise least privilege, because it ties access to a job function rather than to an individual person. When someone changes role, their old role’s access is removed and their new role’s access is granted — rather than access accumulating indefinitely as a person moves through the organisation, which is exactly how “privilege creep” happens.

A workable policy states the principle once, near the top, and then lets every subsequent section — identity management, authentication, privileged access, review cadence — exist as an application of it. If an auditor can’t trace a specific access decision back to least privilege and a defined role, that decision looks arbitrary, and arbitrary access decisions are what internal audits and certification audits are both built to catch. The ISO 27001 internal audit checklist covers the specific audit questions used to test this in practice, including how auditors sample access rights against role definitions.

You Might Already Have Most of This: The NIS2 Article 21(2)(i) Overlap

If your organisation is already working toward NIS2 compliance, you do not need to write this policy from a blank page. NIS2 Article 21(2)(i) requires essential and important entities to implement measures covering “human resources security, access control policies and asset management” [1] as part of the directive’s baseline cybersecurity risk-management measures. In practice, that provision drives the same core behaviours ISO 27001’s Annex A access controls demand: access granted on a documented, need-basis policy; rights reviewed periodically; and access revoked promptly when someone leaves or changes role.

This is consistent with the roughly 70-80% foundational overlap between NIS2 and ISO 27001 that shows up across most of the two frameworks’ technical requirements — access control is one of the clearer examples of it. A NIS2-compliant organisation’s existing access control policy is very likely a strong starting point for the ISO 27001 version, not a rewrite from zero. The gaps tend to be structural rather than substantive: NIS2 doesn’t require you to name specific Annex A control numbers or maintain a Statement of Applicability, so an existing NIS2 policy usually needs re-mapping and a few missing elements (formal privileged-access review cadence, documented identity lifecycle steps) rather than a new policy philosophy. For the full control-by-control comparison, see NIS2 vs. ISO 27001: Differences, Overlap, and How to Align. If you’re weighing whether pursuing ISO 27001 on top of NIS2 makes sense for your organisation at all, ISO 27001 for NIS2-Compliant Organisations covers the business case.

Common Audit Findings in Access Control

The same three findings recur often enough in ISO 27001 internal and certification audits that they’re worth treating as a pre-audit checklist in their own right.

Finding	Why It Happens	How the Policy Should Prevent It
Orphaned accounts	Departing employees retain access longer than necessary because offboarding relies on someone remembering to notify IT [5]	A.5.18-driven procedure that ties account deactivation to the HR leaver process, not to a manual email
Privileged access never reviewed	Admin and service accounts are provisioned once during a project and then left alone indefinitely	A.8.2 requirement for privileged access to be reviewed on a shorter, defined cycle than standard user access
No formal access-review cadence	Access reviews happen “when someone remembers,” with no record of who reviewed what or when	A.5.18 review cadence written into the policy with an owner, a frequency, and an evidence trail

None of these findings are exotic — they are what happens when an access control policy exists as a document but was never connected to an actual operating rhythm. Auditors increasingly expect to see evidence that a review happened (who reviewed it, what changed, what was removed), not just a policy statement saying reviews “will occur periodically” [5]. Industry practice generally treats standard user access as needing at least an annual review and privileged/administrative access as needing a materially shorter cycle, often quarterly, given the outsized damage a single compromised privileged credential can cause [5].

Free Mini Access Control Policy Skeleton

The outline below is a genuinely usable starting point — short enough to adapt in an afternoon, but built around the actual Annex A controls covered above. It is intentionally condensed; a full policy with role-specific access matrices, joiner-mover-leaver workflow detail, and cross-references to your risk register and Statement of Applicability goes well beyond what fits in a mini skeleton.

Purpose
This policy defines how [Organisation] grants, manages, reviews, and revokes access to information, systems, and applications, in order to protect the confidentiality, integrity, and availability of information assets.

Scope
This policy applies to all employees, contractors, and third parties who access [Organisation]’s information systems, and to all user, administrative, and service accounts within the ISMS scope.

Policy Statements

• Access to systems and information is granted on a documented business-need basis, following the principle of least privilege (A.5.15).
• Every user, system, and service is assigned a unique, traceable identity before being granted access; shared or generic accounts are not permitted without a documented exception (A.5.16).
• Passwords and other authentication information are protected throughout their lifecycle and are never stored or transmitted in clear text (A.5.17).
• User access rights are formally approved before provisioning, reviewed at planned intervals, and revoked without undue delay when a user changes role or leaves the organisation (A.5.18).
• Privileged and administrative access rights are allocated only where required for a role, logged, and reviewed on a shorter cycle than standard user access, with access to sensitive information restricted according to this policy rather than default system permissions (A.8.2, A.8.3).
• Secure authentication methods, including multi-factor authentication where risk warrants it, are required for access to systems processing sensitive information (A.8.5).

Roles & Responsibilities

Role	Responsibility
Information Security / ISMS Owner	Owns and approves this policy; approves exceptions; reviews audit and access-review results
System/Application Owners	Approve or reject access requests for systems they own; carry out periodic access reviews
IT/Systems Administrator	Provisions and de-provisions accounts; implements privileged access controls; maintains logs
People Managers / HR	Notify IT promptly of joiners, role changes, and leavers to trigger access updates

Review Cadence
Standard user access rights are reviewed at least annually and privileged access rights at least quarterly, with this policy itself reviewed at least annually or after any significant change to systems or organisational structure.

FAQ

Does ISO 27001 require a standalone access control policy document?
Annex A 5.15 requires a documented, topic-specific policy on access control that is communicated to relevant parties [2]. Many organisations issue it as its own document; some fold it into a broader security policy set. Either approach can satisfy the control as long as the content is complete and the policy is actually followed.

What’s the difference between A.5.15 Access Control and A.5.18 Access Rights?
A.5.15 is the policy layer — the rules for who can request access and on what basis. A.5.18 is the operational layer — actually granting, reviewing, and revoking specific users’ rights against that policy. A policy document alone satisfies A.5.15; you also need the granting/review/revocation process and its records to satisfy A.5.18.

If we already have a NIS2 access control policy, does it satisfy ISO 27001?
It’s a strong starting point but not a direct substitute. NIS2 Article 21(2)(i) drives the same underlying behaviours [1], but ISO 27001 additionally expects the policy to be explicitly mapped to specific Annex A controls, referenced in your Statement of Applicability, and supported by evidence that reviews actually happened on a defined cadence.

How often should access rights be reviewed?
ISO 27001 doesn’t mandate a specific frequency, but industry practice generally treats an annual review as the floor for standard user access, with privileged and administrative access reviewed more frequently, often quarterly, given how much damage a single compromised privileged account can cause [5].

What counts as “privileged access” under A.8.2?
Any access that lets a user bypass normal controls or make system-wide changes — domain admin rights, database admin accounts, root/superuser access, and most service accounts fall into this category. A.8.2 expects these to be identified, minimised, logged, and reviewed separately from standard user access [3].

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

• [1] NIS 2 Directive, Article 21: Cybersecurity risk-management measures, NIS2 Directive (EU) 2022/2555 text portal
• [2] ISO 27001:2022 Annex A 5.15 — Access Control, ISMS.online
• [3] ISO 27001:2022 Annex A Control 8.2 — Privileged Access Rights, ISMS.online
• [4] ISO 27001 Identity Management Explained (Annex A 5.16), High Table
• [5] Unlocking Access Reviews: How Automation Ensures Compliance and Bolsters Security, Scrut Automation