A practical guide to Annex A's 93 controls, how to build your Statement of Applicability, and why access control is where audits actually stall.
Your Statement of Applicability lists ninety-three controls. Ninety of them are marked "implemented."
Your auditor picks three to spot-check. Two are physical and organizational controls: badge access logs, a signed acceptable use policy. Clean evidence, five minutes each.
The third is A.5.18, Access Rights.
"Show me how you know the access shown in this control actually matches who should have it today."
You pull up your identity provider. It shows federated access for your core systems. The auditor asks about the finance team's expense platform, the marketing team's analytics tool, the contractor accounts from a project that ended four months ago.
None of those went through the identity provider. Nobody deprovisioned the contractor accounts. The SoA says A.5.18 is implemented. What's actually implemented is a policy document and partial visibility.
This is the gap that fails ISO 27001 audits. Not missing controls. Controls that exist on paper but can't produce evidence they're operating the way the SoA claims.
What's inside:
- What ISO 27001 Annex A Controls Actually Are
- How Annex A Connects to Your Statement of Applicability
- The Access Control Domain: A.5.15 Through A.5.18
- Design Effectiveness vs. Operating Effectiveness
- Why Access Control Fails More Audits Than Any Other Domain
- Building Access Control Evidence That Survives an Audit
- ISO 27001 vs. ISO 27002, Briefly
- Getting There Without Twelve Months of Documentation First
What ISO 27001 Annex A Controls Actually Are
Annex A of ISO/IEC 27001:2022 lists the reference set of controls an organization draws from when building its Information Security Management System (ISMS). The 2022 revision consolidated the previous 114 controls into 93 controls, organized into four themes:
- Organizational controls (37): policies, roles, supplier relationships, incident management, business continuity
- People controls (8): screening, terms of employment, security awareness, disciplinary process
- Physical controls (14): secure areas, equipment security, clear desk practices
- Technological controls (34): access control, cryptography, logging, malware protection, secure development
Annex A isn't a checklist you complete top to bottom. It's a menu. ISO 27001 requires a risk assessment first (Clause 6.1.2), and your risk assessment determines which controls are relevant, which are irrelevant, and which need to go beyond the baseline description in Annex A.
Organizations that treat Annex A as a compliance checklist, implementing all 93 controls uniformly regardless of actual risk, end up with two problems: resources spent hardening low-risk systems, and thin, undocumented implementation on the controls that matter most. Auditors notice the second problem immediately.
How Annex A Connects to Your Statement of Applicability
The Statement of Applicability (SoA) is the document that turns Annex A from a reference list into your organization's actual commitment. For every one of the 93 controls, the SoA records:
- Whether the control is applicable to your organization
- If applicable, whether it's implemented, partially implemented, or planned
- The justification tying the control back to your risk assessment
- If excluded, the justification for exclusion
This is where most first-time certification attempts go wrong. Teams write the SoA as a documentation exercise, working backward from Annex A's control list rather than forward from their actual risk assessment. The result is a SoA that reads as comprehensive but doesn't reflect what the organization can actually demonstrate.
A well-built SoA does the opposite. It starts with the risk assessment, maps risks to specific Annex A controls, and only marks a control "implemented" when there's evidence to back it, not just a policy that describes intent.
For access control specifically, that evidence requirement is where things get difficult, because access sprawls across every application your organization uses, not just the ones connected to your identity provider.
The Access Control Domain: A.5.15 Through A.5.18
Four technological controls in Annex A govern access directly:
A.5.15 Access Control. Rules to control physical and logical access to information and associated assets, based on business and security requirements. This is the umbrella policy control: does an access control policy exist, and does it define who gets access to what and under what conditions.
A.5.16 Identity Management. The full lifecycle of identities, from creation through modification to deletion, should be managed. This covers provisioning new employees, updating access when roles change, and removing access when someone leaves or a contract ends.
A.5.17 Authentication Information. Allocation and management of authentication information (passwords, tokens, certificates) should be controlled through a managed process, including guidance for personnel on proper handling.
A.5.18 Access Rights. Access rights to information and associated assets should be provisioned, reviewed, modified, and removed in accordance with the organization's access control policy. This is the control that requires periodic review, and it's the one most often cited in nonconformities.
Read together, these four controls describe a full loop: define the policy (A.5.15), manage identities against it (A.5.16), secure the credentials (A.5.17), and prove access rights match policy on an ongoing basis (A.5.18). A gap anywhere in that loop shows up as a finding.
Design Effectiveness vs. Operating Effectiveness
ISO 27001 audits test two separate things, and conflating them is the most common reason organizations walk into a certification audit unprepared.
Design effectiveness asks: is the control appropriately designed to address the risk? Do you have an access control policy? Does it define who approves access requests, how often reviews happen, what triggers deprovisioning? This is a documentation question, and most organizations pass it. Policies are relatively easy to write.
Operating effectiveness asks: is the control actually working, consistently, over time? Did the last three quarters of access reviews happen on the documented schedule? Did the deprovisioning process actually remove access within the committed timeframe for the last ten departures? Can you show, not describe, that the policy is being followed?
An SoA entry marked "implemented" without operating evidence is a design-effectiveness claim wearing an operating-effectiveness label. Auditors are trained to test the gap between the two, and the access control domain is where that gap is widest, because access changes constantly and most organizations don't have systematic visibility into whether their policy is being followed everywhere access exists.
Why Access Control Fails More Audits Than Any Other Domain
Physical controls are static: a badge system either logs entries or it doesn't. People controls are periodic: background checks happen once, awareness training happens on a schedule. Access control is neither. It changes with every hire, every role change, every offboarding, every new application anyone in the organization signs up for.
Three patterns show up repeatedly in access control nonconformities:
Coverage gaps. The identity provider shows clean, reviewable access for federated applications. It shows nothing for the applications that were never connected, departmental tools purchased with a credit card, applications with direct login, anything outside the organization's official app catalog. If the SoA claims A.5.18 is implemented but the evidence only covers a fraction of the applications actually in use, the claim doesn't hold.
Stale access rights. A.5.18 requires access rights to be reviewed and modified in line with policy. If the policy says quarterly review but the last review evidence is nine months old, or if reviews happened but nobody could show what was changed as a result, the control isn't operating even if it's designed correctly.
Orphaned identities. A.5.16 requires managing the identity lifecycle end to end. Contractor accounts that outlive the contract, service accounts nobody owns, accounts for employees who changed departments but kept the old access, all of these are identity management failures that surface during A.5.16 and A.5.18 testing.
None of these patterns require a missing control. They require a control that's designed correctly on paper and not fully operating in practice, which is exactly what a certification audit is built to find.
Building Access Control Evidence That Survives an Audit
Start with complete visibility, not the identity provider's view. SSO typically covers a minority of an organization's actual application estate. Discovery methods beyond SSO federation, finance system integration for expensed software, browser-based discovery, HR system integration, close that gap and give you a defensible answer when an auditor asks how you know your access inventory is complete.
Tie identity lifecycle events to actual triggers. A.5.16 evidence is strongest when provisioning and deprovisioning are triggered by HR system events, not manual tickets that depend on someone remembering to file them. When an employee's status changes in the HR system, that should be traceable to the corresponding access change, with a timestamp gap you can defend.
Make reviews produce a record, not just an outcome. A.5.18 evidence needs to show who reviewed what, when, what decision was made, and what happened as a result. A review that concludes "everything looks fine" with no documented reasoning is weaker evidence than one with per-user decisions and reviewer identity attached.
Close the loop on findings. If a review identifies access that should be revoked, the evidence trail needs to show the revocation happened, when, and that it was verified rather than just requested. Auditors specifically probe whether findings from prior reviews were acted on.
Cover service accounts and non-human identities. A.5.16 doesn't carve out an exception for accounts without a person attached to them. Integration accounts, API keys, and automation accounts are frequently excluded from access reviews entirely, which is precisely why auditors have started asking about them directly.
ISO 27001 vs. ISO 27002, Briefly
ISO 27001 is the certifiable standard: it defines the ISMS requirements and the Annex A control list your SoA draws from. ISO/IEC 27002 is a companion standard, not certifiable on its own, that provides implementation guidance for each of the same 93 controls, one page of detail per control versus Annex A's brief title and description.
In practice: use ISO 27001 and your risk assessment to decide which controls apply and why. Use ISO 27002 as a reference when you need detail on how a specific control is typically implemented. Neither standard tells you how to produce ongoing evidence that a control like A.5.18 is operating, that's an operational and tooling question, not a documentation one.
Getting There Without Twelve Months of Documentation First
Zluri is an identity security platform built for exactly the access control evidence gap described above.
For the access control domain specifically, that means visibility that goes beyond SSO to cover the applications your identity provider doesn't see, identity lifecycle events tied to HR system triggers so A.5.16 evidence is automatic rather than manually assembled, scheduled reviews that generate timestamped, reviewer-attributed records for A.5.18, and closed-loop remediation so revoked access is verified, not just requested.
Organizations building their SoA around what they can actually operate, rather than what looks complete on paper, tend to mark fewer controls "implemented" up front and pass more of them cleanly when the auditor spot-checks arrive.
See how Zluri generates access control evidence for ISO 27001 → Book Demo
Frequently Asked Questions
What are ISO 27001 Annex A controls?
Annex A of ISO/IEC 27001:2022 lists 93 reference controls across four themes: organizational, people, physical, and technological. Organizations select which controls apply based on their risk assessment and document that selection in a Statement of Applicability.
How many controls does ISO 27001 have?
The 2022 revision reduced the control count to 93, down from 114 in the 2013 version. They're organized into four themes: 37 organizational controls, 8 people controls, 14 physical controls, and 34 technological controls.
What is the Statement of Applicability?
The Statement of Applicability (SoA) is the document where an organization records, for each of the 93 Annex A controls, whether it applies, whether it's implemented, and the risk-based justification for that decision. It's one of the core documents auditors review during certification.
Which Annex A controls cover access control specifically?
Four technological controls: A.5.15 Access Control (the policy), A.5.16 Identity Management (lifecycle), A.5.17 Authentication Information (credentials), and A.5.18 Access Rights (provisioning, review, and removal in line with policy).
Why do access control findings show up so often in ISO 27001 audits?
Access changes continuously with hiring, role changes, and offboarding, and it spans every application in use, not just the ones connected to an identity provider. Most organizations have partial visibility and can show a policy exists but struggle to prove the policy is operating consistently everywhere access exists.
What's the difference between design effectiveness and operating effectiveness?
Design effectiveness asks whether a control is appropriately built to address the risk, typically demonstrated through policy documentation. Operating effectiveness asks whether the control is consistently working in practice over time, demonstrated through evidence like review records and remediation logs. Audits test both, and the gap between them is where most findings occur.
Do service accounts need to be covered under Annex A access controls?
Yes. A.5.16 Identity Management applies to the full identity lifecycle without excluding non-human identities. Service accounts, API keys, and automation accounts are frequently missed in practice, which makes them a common audit focus point.
How is ISO 27001 different from ISO 27002?
ISO 27001 is certifiable and defines ISMS requirements plus the Annex A control list. ISO 27002 is a non-certifiable companion standard offering detailed implementation guidance for the same controls. Organizations use 27001 to decide what applies and 27002 as a reference for how controls are typically implemented.
Can I pass an ISO 27001 audit with all 93 controls marked "implemented"?
Only if you can produce evidence for each one when asked. Auditors spot-check rather than review every control in full depth, but marking a control "implemented" without operating evidence to back it is the most common source of nonconformities, particularly in the access control domain.
.svg)
