ISO 27001 Annex A access controls: implementing the clauses auditors sample
ISO 27001 certifies an information security management system. Most of the standard is process: risk assessment, the Statement of Applicability, management review, continual improvement. The control set lives in Annex A, which in the 2022 version has 93 controls across four themes: 37 organisational, 8 people, 14 physical, and 34 technological.
A meaningful share of those controls are access controls, and they cluster in two themes: the organisational theme (the A.5 controls) and the technological theme (the A.8 controls). They are also among the controls an auditor can test directly. You can write a strong access-control policy and still raise a nonconformity if the directory does not match it when the auditor samples it.
Certification runs on a three-year cycle: an initial two-stage audit (Stage 1 reviews your documentation and readiness, Stage 2 evaluates implementation on site), annual surveillance audits in years one and two, and a full recertification every three years. So access evidence has to stay true between audits, not get reassembled the week before each surveillance visit.
- A meaningful share of ISO 27001 Annex A:2022 controls are access controls, clustered in the organisational (A.5) and technological (A.8) themes, and they are among the controls an auditor can test directly.
- You can write a strong access-control policy and still raise a nonconformity if the directory does not match it when the auditor samples it.
- Certification runs on a three-year cycle with annual surveillance audits, so access evidence has to stay true between audits, not get reassembled the week before each visit.
- A.5.18 (access rights) is the control most likely to fail a sample, usually because a leaver kept access to an app outside the directory.
- Read together, the access controls ask for the same things every framework asks for: a known population of identities, strong authentication, least privilege, controlled admin access, and a review-and-removal process you can evidence.
- A practical order of work runs from the identity inventory outward, because everything else samples against it.
the access controls, one by one
A.5.15 access control
Establish and apply rules for granting and restricting access, based on business and security requirements. This is your access-control policy: who gets access to what, on what basis, and how it is authorised. Implement a written policy keyed to roles and data sensitivity, with least privilege as the default. Evidence: the policy itself, plus proof it is applied: access that maps to documented roles rather than ad-hoc grants.
A.5.16 identity management
Manage the full lifecycle of identities, human and non-human, across systems. Implement a single, current inventory of every identity, including service accounts and machine identities, each tied to an owner. Evidence: the identity inventory, showing it covers more than the core directory. Service accounts documented somewhere other than memory is a common gap here.
A.5.17 authentication information
Control the allocation and management of authentication information, meaning credentials and secrets. Implement managed credential issuance, secure storage, no shared passwords for individual accountability, and rotation where relevant. Evidence: credential-management process, and the absence of shared logins where actions need to be attributable.
A.5.18 access rights
Provision, review, and remove access rights in line with the access-control policy, including when people change roles or leave. Implement a joiner-mover-leaver process that grants, adjusts, and revokes access reliably, and periodic access reviews. Evidence: provisioning and termination records for a sample of people, and access-review records showing who reviewed what and what changed. This is the control most likely to fail a sample, usually because a leaver kept access to an app outside the directory.
A.8.2 privileged access rights
Restrict and control elevated access. Implement by limiting who holds admin, preferring just-in-time or time-boxed elevation over standing privilege, and reviewing privileged access more often than standard access. Evidence: a current list of privileged-access holders with justification, and review records.
A.8.3 information access restriction
Restrict access to information in line with the access-control policy. Implement least privilege at the data and application layer, not just at login. Evidence: access listings per sensitive system showing restriction by role.
A.8.5 secure authentication
Use strong authentication technologies and procedures. Implement multi-factor authentication across users and systems, with documented, compensated exceptions where you genuinely cannot enforce it. Evidence: MFA configuration showing enforcement and coverage, including the awkward edges: admins, remote access, and logins outside single sign-on.
A.8.15 logging and A.8.16 monitoring activities
Record events, including access, and monitor for anomalies. Implement logging of authentication and access events for in-scope systems, retain them, and watch for the anomalies that matter. Evidence: log samples and evidence that someone reviews them.
Read together, these ask for the same things every framework asks for: a known population of identities, strong authentication, least privilege, controlled admin access, and a review-and-removal process you can evidence.
where companies fall short
ISO access failures usually come from controls that exist on paper but do not survive a sample. The policy says reviews happen quarterly, but there is no record of the last two. A.5.18 says access is removed when people leave, but the auditor finds a former contractor still active in a connected app. A.8.5 says strong authentication is enforced, but a handful of admin accounts predate the policy. A.5.16 assumes a complete identity picture, but the service accounts live in someone's head. Each of these is a finding waiting to happen, and each would have been caught first by a current access map.
a practical order of work
Working through the controls in this order means the access portion of the audit samples cleanly because the controls are true, rather than because the timing was lucky.
- Identity inventory (A.5.16). Get one complete, owned list of every identity. Everything else samples against it.
- Authentication coverage (A.8.5). Confirm MFA enforcement and document the exceptions you cannot close.
- Privileged access (A.8.2). Find standing admin, justify it or remove it, and set a tighter review cadence.
- Access rights lifecycle (A.5.18). Make joiner-mover-leaver evidenced, and run a recorded access review.
- Policy and restriction (A.5.15, A.8.3). Make sure the written policy matches what the directory actually enforces.
- Logging (A.8.15, A.8.16). Confirm access events are recorded, retained, and reviewed.
The common thread is that a current, accurate picture of every identity and the access it holds is the input each of these controls depends on. Build that picture once, keep it true between audits, and the access controls stop being a scramble before each surveillance visit.
let's start with a conversation
Most first conversations start with not quite knowing what you have or where to begin. That's normal, and it's exactly where we're useful.
Tell us what prompted this. An upcoming audit, an incident, a client's security questionnaire, or just a sense that things have gotten messy.
We'll take it from there
+48 783 762 997
julian@unshadowit.com
