ISO 27001 Access Control Policy: The Complete 2026 Guide

An ISO 27001 access control policy is the document a certification auditor will ask for within the first hour of your Stage 2 audit, and it is one of the easiest to get wrong. Most drafts fail for the same reason: they describe what the IT team already does instead of setting rules that management has approved and that every in-scope system can be measured against.

This guide covers what an ISO 27001 access control policy must contain in 2026, which Annex A controls it carries, the evidence auditors match it against, and the mistakes that turn a serviceable document into a minor nonconformity.

What an ISO 27001 Access Control Policy Is — and Is Not

An ISO 27001 access control policy is a short, management-approved statement of the rules governing who gets access to what, on what basis, and for how long. It sits one level below your overarching Information Security Policy and one level above the procedures your administrators actually execute.

Annex A control 5.15 of ISO/IEC 27001:2022 — the third edition, published 25 October 2022 — requires rules controlling both physical and logical access to be established and implemented on the basis of business and information security requirements. The word rules is doing the work in that sentence. An auditor is not looking for a description of your identity provider configuration. They are looking for a decision, made by someone with the authority to make it, that an administrator can be held to.

What it is not: it is not a runbook, not an inventory of every application you own, and not ISO 27002 guidance text pasted into a template. Policies written that way age badly, because every tooling change forces a revision and a fresh management approval cycle.

Which Annex A Controls Your ISO 27001 Access Control Policy Has to Carry

ISO 27001:2022 contains 93 Annex A controls grouped into four themes — 37 organizational, 8 people, 14 physical and 34 technological. Nine of them are access-related, and a well-built policy is the anchor document for all nine. If you exclude any, your Statement of Applicability has to justify why, because clause 6.1.3 makes the SoA mandatory.

Annex A control	Theme	What your policy must settle
5.15 Access control	Organizational	The access model itself — role-based, attribute-based or a hybrid — and the need-to-know and least-privilege principles behind it
5.16 Identity management	Organizational	The full identity lifecycle for people, systems, services and devices: registration, verification, provisioning, maintenance, de-registration
5.17 Authentication information	Organizational	Password and secret handling, issue and reset rules, and the ban on shared credentials
5.18 Access rights	Organizational	Who approves access, how rights change on transfer, and how fast they are revoked on exit
8.2 Privileged access rights	Technological	Separate admin accounts, time-bound elevation, and a named owner for every privileged role
8.3 Information access restriction	Technological	How restrictions follow your information classification scheme, including read-versus-write separation
8.4 Access to source code	Technological	Repository permissions, branch protection and who can approve a merge to production
8.5 Secure authentication	Technological	Where multi-factor authentication is mandatory and what counts as an acceptable factor
8.18 Use of privileged utility programs	Technological	Which utilities can override system controls, who may run them, and how that use is logged

Splitting these across nine separate documents is a common mistake. One policy with clearly numbered clauses is easier to approve, easier to communicate under Annex A 5.1, and considerably easier to audit. If you want the wider picture first, our guide to the ISO 27001:2022 Annex A controls maps all 93.

What an ISO 27001 Access Control Policy Must Contain

Ten sections cover the requirement without padding. Every ISO 27001 access control policy we review is missing at least one of them. Keep the whole thing to four or five pages.

1. Purpose and scope. Which entities, systems, locations and information assets the policy applies to. Match this to your ISMS scope statement exactly — a mismatch is an easy finding.
2. Roles and responsibilities. Name the system owner, the access approver and the administrator as distinct roles. Where one person holds two of them, say so and describe the compensating control.
3. Access principles. Least privilege, need-to-know, deny-by-default, and segregation of duties stated as binding rules rather than aspirations.
4. Identity lifecycle. Joiner, mover and leaver handling, with a stated revocation target. Twenty-four hours for standard accounts and immediate for privileged accounts is a defensible baseline.
5. Authentication requirements. Where MFA is mandatory, which factors are acceptable, and how secrets are stored. Phishing-resistant factors are worth naming explicitly — see our note on phishing-resistant MFA.
6. Privileged access. Separate administrative accounts, no routine work from an admin account, time-bound or just-in-time elevation, and mandatory logging.
7. Third-party and remote access. How vendors are granted access, for how long, and under what agreement.
8. Physical access. Annex A 5.15 covers physical as well as logical access, and this is the clause most drafts forget entirely.
9. Access review cadence. A stated frequency per access tier, with a named reviewer.
10. Exceptions, monitoring and enforcement. How an exception is requested, who approves it, when it expires, and what happens when the policy is breached.

A defensible review cadence

Access tier	Typical review frequency	Reviewer
Privileged / administrative	Quarterly	System owner
Access to confidential or regulated data	Quarterly to half-yearly	Information owner
Standard business application access	Annually	Line manager
Third-party and contractor accounts	Quarterly, plus at contract renewal	Contract owner

These are typical ranges, not requirements — ISO 27001 does not prescribe a frequency. What it does require is that you set one, justify it against your risk assessment, and then meet it.

Policy, Standard or Procedure — Where Each Rule Belongs

The most common structural failure in an ISO 27001 access control policy is putting technical parameters into the policy itself. Once “minimum 14 characters” sits in a management-approved document, changing it needs another approval cycle.

Document	Contains	Example
Policy	Rules and principles that rarely change	Privileged access is granted only on approval by the system owner and reviewed quarterly
Standard	Measurable technical parameters	Password length, lockout thresholds, approved MFA factors
Procedure	Step-by-step execution	How to raise, approve and fulfil an access request ticket

How to Write an ISO 27001 Access Control Policy in Five Steps

1. Inventory what you are protecting. Pull your asset register and information classification scheme first. You cannot set access rules for assets you have not classified.
2. Map the nine Annex A controls to sections. Write the section headings before the prose, so nothing is silently dropped.
3. Write rules, not descriptions. Every clause should be testable. “Access is appropriately managed” is untestable. “Leaver accounts are disabled within 24 hours of the HR termination record” is testable.
4. Get documented approval. Annex A 5.1 requires policies to be defined, approved by management, published, communicated and acknowledged. Keep the approval record — clause 7.5 makes it documented information you must control.
5. Set the review trigger. At planned intervals and on significant change. Annual review with an out-of-cycle trigger for reorganizations, acquisitions and major platform migrations works well.

The Evidence Auditors Match Against Your ISO 27001 Access Control Policy

The policy is the claim. These are the artefacts that prove it, and a Stage 2 auditor will sample them:

• The approval record, with a date and an approver who has the authority
• A completed access review for at least one full cycle, showing findings and their remediation
• Joiner and leaver records traced end to end for named individuals, usually two or three picked by the auditor
• A list of privileged accounts reconciled against current employees
• Exception records that are still within their approved expiry date
• Evidence the policy was communicated, such as acknowledgement records or onboarding sign-off

Almost every access-related finding traces to the gap between a well-written policy and a review that was never run. Your ISO 27001 internal audit should test this before the certification body does.

Five Mistakes That Turn a Policy Into a Nonconformity

These five account for most of the findings raised against an ISO 27001 access control policy at first certification.

• Scope mismatch. The policy covers the whole company; the ISMS scope covers one product line. Pick one and align.
• No revocation timeframe. “Promptly” is not auditable. State the number of hours.
• Orphaned service accounts. Annex A 5.16 covers non-human identities. Service accounts with no named owner turn up in most first-time audits.
• Physical access omitted. Control 5.15 explicitly covers it, and reviewers routinely leave it out.
• Reviews documented but never performed. The most expensive mistake, because it is a failure of operation rather than of documentation, and it cannot be fixed the week before the audit.

Credential-driven intrusion remains a live risk even as the mix shifts. Verizon 2026 Data Breach Investigations Report placed exploitation of vulnerabilities ahead of credential abuse as the leading initial access vector for the first time, with credential abuse falling to roughly 13% of breaches as an entry point — still high enough that disciplined access reviews earn their keep.

ISO 27001 Access Control Policy FAQ

Is an access control policy a mandatory document under ISO 27001?

Not by name. The documented information required outright sits in clauses 4 to 10 — ISMS scope, information security policy, the risk assessment and treatment process, the Statement of Applicability, objectives, competence records, and internal audit and management review results. Annex A 5.15 nonetheless requires access rules to be established and implemented, and in practice every certification body expects a written access control policy as the evidence of that. Treat it as mandatory.

How long should an ISO 27001 access control policy be?

Four to five pages. Anything past ten usually means technical standards have leaked into it. Short policies get read, acknowledged and followed; long ones get filed.

Can one policy cover ISO 27001, SOC 2 and HIPAA?

Yes, and it usually should. The logical access requirements in the SOC 2 common criteria and the HIPAA Security Rule overlap heavily with Annex A 5.15 to 5.18. Write one policy and keep a mapping table showing which clause satisfies which framework. Remember that SOC 2 is an attestation and HIPAA is a legal obligation — neither is a certification, so neither replaces ISO 27001.

How often does the policy need to be reviewed?

Annex A 5.1 requires review at planned intervals and when significant changes occur. Annual is the norm. Log the review even when nothing changes, because the auditor is testing that the review happened, not that the document was edited.

Do we need a separate policy for privileged access?

Only if privileged access is complex enough to warrant it — a large estate with just-in-time elevation and session recording, for example. For most organizations a dedicated section inside the main policy is cleaner and easier to keep current.

Getting the Document Written

Writing an ISO 27001 access control policy from scratch takes a competent person two to three days, plus the review cycle. Starting from a structured draft that already maps to Annex A 5.15 through 8.18 removes most of that.

Our ISO 27001 Toolkit includes an editable Access Control Policy alongside 164 other ISMS templates — the Information Security Policy it sits under, the Password Reset Procedure and Vendor Access Procedure it hands off to, the Statement of Applicability, and a 77-question internal audit checklist covering all 93 Annex A controls. It is $99 for the set, in native Word and Excel format.

For the wider path to certification, start with our guide to ISO 27001 certification, or browse the full range of ISO 27001 policy templates to see what else your ISMS needs.