--- title: "ISO 27001:2022 Annex A 5.15 access control: implement and pass audit" canonical: https://www.grcmana.io/vault/iso-27001/annex-a-5-15-access-control published: 2023-02-20 updated: 2026-10-07 author: "Harry West" framework: "ISO 27001" control: "A.5.15 Access control" journeyStage: implementation --- # ISO 27001:2022 Annex A 5.15 access control: implement and pass audit ## Key takeaways ISO 27001:2022 Annex A 5.15 asks you to write one deny-by-default access policy covering premises, systems, data and machine identities. Owner-approved role bundles in your identity provider make it administrable, and HR-driven provisioning plus generated reviews leave audit evidence as a by-product. Auditors test it by tracing real joiners and leavers, not by reading the policy. - **Scope** — One policy governs entry to buildings, rooms, systems and data alike, so physical access such as badge zones and logical access such as SSO sit under the same written rules. - **Posture** — Nothing is reachable until a rule allows it. Asset owners, not IT, decide who needs entry, and machine identities such as service accounts and API keys fall under the same rules. - **Review cadence** — Review entitlements quarterly for admin and critical systems and at least annually elsewhere, remediate every finding, record the remediation, and run an extra check when roles or systems change materially. - **Audit sampling** — Auditors trace a joiner and a leaver end-to-end, reconcile a live user list to approvals, ask who owns a service account and spot-check badge records against the authorised list. 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](https://www.iso.org/information-security/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](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-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](https://www.ncsc.gov.uk/collection/10-steps/identity-and-access-management), 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. | Approach | What it catches | Cadence | Evidence left | | --- | --- | --- | --- | | Spreadsheet review | Only what someone remembers to list | Annual, often late | Hand-assembled sheet that rarely reconciles | | Review generated from live IdP data | Every current entitlement, including orphaned accounts | Quarterly for critical systems, annually elsewhere | Owner decisions captured in the tool | | Leaver handled by email request | Leavers someone remembers | Days or weeks after departure | Inconsistent tickets | | HR-driven leaver | Every departure recorded in HR | Same day | Platform timestamps beside HR dates | | Manual admin-group check | Changes spotted at the annual review | Annual | Screenshot taken for the audit | | Admin-group drift alert | Unexplained additions to privileged groups | Within hours | Alert and ticket trail | ## 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 ### What is the difference between need-to-know and need-to-use in A.5.15? Need-to-know limits which information a person can see. Need-to-use limits which systems and infrastructure they can operate. A finance analyst may need to know payroll figures yet have no need to use the production database, so apply both tests when an owner approves a grant. ### Can the A.5.15 access rules sit inside a wider information security policy? In principle the rules could live inside a broader document. In practice auditors, enterprise buyers and insurers ask for the access control policy by name, and a dedicated two-to-four-page document is quicker to evidence. If you keep the rules inside a larger policy, give them their own heading and approval date. ### How should A.5.15 treat contractor and agency access? Give third parties sponsored, expiring access: an internal owner, a stated end date and renewal as a conscious decision. Open-ended access that nobody sponsors is the pattern auditors find. A dedicated contractor role bundle makes end-dating a single group setting, and critical systems should include contractors in the quarterly review. ### Does A.5.15 expect separate people to request, approve and provision access? The principle is separating asking, approving and doing, so nobody can request, approve and provision access for themselves. At 50 staff that rarely needs three different people: the requester's manager or system owner approves, and IT provisions. Where an administrator must change their own access, have a second person check the change from the log. ### How long does implementing A.5.15 access control take for a 50-person firm? Plan on about a week for the policy and two to four weeks to wire role bundles into the identity provider, depending on the state of the estate. The longer lead time is evidence: an auditor wants to see reviews that ran and closed their findings, so complete the first quarterly review before the audit, not after it.