ISO 27001:2022 Annex A 5.15 access control: implement and pass audit

The due-diligence questionnaire asks who approved your administrators' access and when you last reviewed it. The answer lives in three spreadsheets and one person's memory. This guide shows how to implement ISO 27001:2022 Annex A 5.15 access control so that the answer becomes an export.

It is for information security managers, IT leads and compliance officers at UK regulated firms of 25 to 250 staff. The goal is to pass audit testing of ISO 27001 Annex A 5.15. You get the policy, the role design, the machine-identity rules, the automation and the auditor's sampling plan.

What is ISO 27001 A.5.15 access control?

ISO 27001 A.5.15 is the Annex A control that makes an organisation decide, in writing, the rules of entry to its buildings, rooms, systems and data. One policy governs both physical and logical access, starts from deny-by-default and derives its rules from business need and risk rather than tooling defaults.

Read ISO 27001:2022 A.5.15 as one decision, made once and written down: who or what may enter which room, system or data set, and why. The control names no product. It asks that the answer come from business need and risk, and that nobody inherits access simply because a cloud tool shipped with a permissive default.

Scope is wider than most security teams assume. The ISO explainer on access control says that controlling access to private information means dealing with physical access (buildings, devices and documents) and logical access (computer and system access). So A.5.15 puts the badge reader and the single sign-on prompt under one policy.

The control is preventive, and it protects confidentiality, integrity and availability together. Wrongly granted access enables reading, tampering and destruction alike, so stopping unauthorised entry before it happens is the whole mechanism. Most of what it asks for is what a well-run firm wants anyway: clear owners, sensible defaults and a record of who decided what.

What does A.5.15 require to ensure authorized access and to prevent unauthorized access to information and other associated assets?

The control's stated purpose is that the right people and systems reach information and other associated assets, and nobody else does. A.5.15 meets it with written, business-driven rules: nothing is reachable until a rule allows it, asset owners decide who needs what, and the rules cover machine identities as well as people.

Under ISO 27001:2022 control 5.15 access control, three working rules do the heavy lifting:

• Deny by default. Nothing is reachable until a written rule says it is.
• Owners decide. The person accountable for a system, not IT, decides who needs entry. IT executes. That single habit produces the approval trail auditors ask for.
• Machines count. Service accounts, integrations and devices sit under the same rules as staff.

The pressure to get this right arrives from three directions at once. Enterprise due diligence, ISO audits and cyber-insurance proposal forms converge on the same questions about joiners, leavers and reviews. Buyers read sloppy answers as a proxy for overall security maturity.

The ICO guide to UK GDPR data protection principles supplies the legal anchor. Article 5(1)(f) requires personal data to be processed with appropriate security, including protection against unauthorised or unlawful processing. Access rules are among the most direct measures against that risk, so evidence you build for ISO 27001:2022 control A.5.15 access control also supports your UK GDPR position.

Access is also the fastest generator of audit findings at this scale, because the evidence is so checkable. User lists, approval records and leaver dates either line up or they don't.

A policy nobody can reconcile to the live user list is a document, not a control.

How does ISO 27001:2022 Annex A 5.15 access control direct A.5.16, A.5.18 and A.8.2?

Annex A 5.15 is the umbrella policy of the access family. It sets the principles; A.5.16 (identity management) establishes who each identity belongs to, A.5.18 (access rights) grants and withdraws permissions, and A.8.2 (privileged access rights) governs the administrator tier. Each of those three controls carries out decisions the A.5.15 policy has already made.

What the ISO 27001:2022 A.5.15 access control policy hands to each control looks like this:

• To A.5.16: the rule that every identity, human or machine, traces to an accountable person or owner.
• To A.5.18: the principle that grants follow proven need and that owners, not IT, approve them.
• To A.8.2: the requirement that administrator access is separate, strongly authenticated and reviewed more often.

The order matters. Sensible rules key off data sensitivity, so the policy follows data classification under A.5.12 and comes before the three controls that build its machinery. Build the machinery first and you end up writing policy to describe whatever the tools already did.

The practical test is whether a grant traces back to the policy. Pick any grant in your identity provider and walk upward: the grant implements a role bundle, the role bundle follows a rule, and the rule appears in the policy. Where the chain breaks, either the policy is silent or the grant is an accident.

How do you implement ISO 27001 access control in five steps?

Implement A.5.15 in five steps for a firm of around fifty staff: write a two-to-four-page deny-by-default policy; build owner-approved role bundles in your identity provider; wire joiner-mover-leaver events to HR; harden the privileged tier with MFA; and review entitlements quarterly or annually, recording every remediation.

The five steps below satisfy ISO 27001:2022 Annex A control 5.15 access control in the order we would sequence them:

1. Write the policy. State deny by default, grant on proven need, least privilege and permissions bundled into roles. Anchor it in the NCSC identity and access management guidance, which expects a policy covering who should have access to which systems, data or functionality, why, and under what circumstances. Cover physical zones in the same document.
2. Build owner-approved role bundles. Create one set of identity provider groups per job family, sized as the next section describes. Every grant carries a recorded justification, so a later review can tell need from habit.
3. Wire joiner-mover-leaver events. A starter inherits their role bundle, a mover swaps bundles and sheds the old one, and a leaver is zeroed the same day. NCSC expects a joiners, movers and leavers policy so access is revoked or changed when people move on, and the trigger should come from HR rather than from anyone's memory.
4. Harden the privileged tier. Give administrators named admin accounts separate from their daily logins. Require MFA on all administrative access and on everything reachable from the internet, without exception.
5. Review on a cycle. Check admin and critical systems quarterly and everything else at least annually. Remediate the findings and record the remediation. Add an out-of-cycle check when roles or systems change materially.

Step 2 is where the effort concentrates, and it is where it pays back: every later step runs off the groups you build there.

The classic failure is the stale policy, written for the infrastructure of two migrations ago and never updated. Auditors ask when the policy was last revisited, and an old date beside a new estate answers badly. Put the policy's own review on the same calendar as the entitlement reviews.

How granular should access control roles be for a small team?

Grant access by job-family roles, not by hand-crafted per-person permissions. The right scheme is the one your team can actually administer: past about twenty staff, individual permission sets become unmanageable, and over-granular schemes drain security budget while staff route around them. Log, justify and time-box the exceptions instead.

A job-family bundle is the set of identity provider groups a Finance Analyst, a Support Engineer or a Developer receives on day one. Each bundle maps to the systems that job needs and nothing more. The bundle becomes the unit of approval: the owner signs off once on what the role contains, and every later grant is a simple membership question.

Three tests tell you whether granularity has gone too far:

• Explainability. One person can describe the whole role-to-permission matrix in a single sitting.
• Onboarding. A new starter gets correct access from one role request, not a dozen tickets.
• Exception volume. Exceptions number in the handful, not the dozens.

Exceptions are fine, but each needs a logged justification, a named approver and an end date. An exception without an expiry becomes a permanent entitlement, which is how the long-tenure employee ends up able to touch everything.

Over-engineering is the opposite pitfall to sprawl, and it costs just as much. A handful of well-named bundles and a short matrix is a scheme you can keep true.

How do you govern service accounts and API keys under A.5.15?

Service accounts, API keys and third-party integrations are identities and need the same governance as people: a named owner, a rule for what they may reach, an expiry or end date, and a place in every entitlement review. They are the half of the estate most often missed, and increasingly the half attackers target.

A service account nobody owns is a leaver nobody removed.

Start with an inventory. Pull every service account from the identity provider, every API key from your cloud and SaaS consoles, and every integration holding an OAuth grant. Then give each entry five attributes:

• Owner: a named person or team that answers for it, not a shared mailbox.
• Scope: the systems and data it may reach, following the deny-by-default rule.
• End date: an expiry, with renewal a conscious decision.
• Review slot: a line in every entitlement review.
• Alert: a ticket raised on anything unowned or overdue.

For third-party integrations, the owner is the internal sponsor who asked for the connection. If nobody will own it, nobody should be running it.

Excluding these credentials from reviews is the commonest gap. They often hold broad rights, they never take holiday, and nobody notices when they misbehave. The forgotten API key with production rights is a standard breach path. The inventory feeds the review cycle from the five-steps section, so it needs no separate process.

How can you automate A.5.15 access control with GRC engineering?

Automate A.5.15 by making the identity provider the source of truth: HR events trigger joiner, mover and leaver changes; reviews generate from live IdP data and route to owners; admin-group changes raise alerts. Evidence accumulates as a by-product of doing the work, not a pre-audit scramble.

Four mechanisms carry the build:

• HR-driven joiner-mover-leaver. The HR record changes and the identity provider changes with it. Platform timestamps become native evidence that the leaver was zeroed on the day.
• Reviews from live data. Entitlement reviews generate from current IdP and application exports and arrive with owners as tasks. Decisions are captured in the tool, so the re-certification record writes itself.
• Drift detection on the privileged tier. Any change to admin-group membership raises an alert and a ticket. Unexplained additions surface in hours, not at the annual review.
• Expiring machine credentials. The inventory from the previous section carries owners and end dates, and anything unowned or overdue alerts.

A leaver process that depends on someone remembering isn't a process.

Requests, approvals and removals run through ticketing too, so every grant and removal leaves its own record. The commercial upside follows. When an enterprise buyer's questionnaire asks how quickly leavers lose access, you export the answer instead of composing it, and the deal moves.

What do auditors sample when testing Annex A 5.15?

Auditors trace one recent joiner and one leaver end-to-end through request, approval, provisioning and removal, reconcile a system's live user list against approvals, pick a service account and ask for its owner, and spot-check badge records against the authorised list. A missing policy, reviews that never ran or live leaver accounts grade major.

Expect questions like these in the room:

• "Show me the access policy. Who approved it, and when was it last revisited?"
• "Pick a system: who are these users, who approved each, and can you show me the request?"
• "Walk me through your latest entitlement review. What did it catch, and what changed?"
• "How quickly does a leaver lose access? Prove it for your last one."
• "Who can enter the server room, and how would you know if someone else had?"

Have this evidence pack ready before they ask:

• The approved access control policy, current and dated.
• The role-to-permission mapping, usually the identity provider's group structure plus a short matrix.
• Request and approval tickets showing owner sign-off and stated need.
• Entitlement review records: what was reviewed, found, revoked and by whom.
• Leaver removal timestamps beside departure dates.
• MFA configuration for remote and admin access.
• Third-party access agreements with named sponsors and expiry dates.
• Badge exports, visitor logs and server-room lists.

Grading norms come from certification bodies, not from wording in the standard. In practice, a late review or a single grant missing its approval record grades minor, and repeated minors add up to a major as a pattern.

At this scale, auditors accept an identity provider export plus a quarterly review that visibly happened and closed its findings. That satisfies certification bodies and enterprise customers alike. What fails is a beautiful policy sitting on an unreviewed, hand-grown permission sprawl.

Frequently asked questions