Access control failures account for a disproportionate share of data breaches IBM’s 2024 Cost of a Data Breach Report put compromised credentials at the root of nearly one in three incidents. For US organizations pursuing ISO 27001 certification, Annex A 5.15 through 5.18 translate that risk reality into a structured set of requirements that auditors will test with precision.
Getting the controls right is one challenge. Producing the evidence records that prove you’ve implemented them correctly is another. This guide covers both: what ISO 27001 actually requires for access control, the specific evidence your certification auditor will request, and how these requirements map to NIST SP 800-53, CMMC 2.0, and HIPAA the regulatory frameworks most US organizations already operate under.
What ISO 27001:2022 Requires for Access Control
ISO 27001:2022 restructured access control from a single Annex A domain into four discrete controls, each with a distinct scope. Understanding where one ends and the next begins is essential before you start documenting evidence.
Annex A 5.15 – Access Control Policy: This is the foundational requirement: a documented policy that defines principles for granting, reviewing, and revoking access across all information assets. The policy must state the organization’s approach to access need-to-know, least privilege, separation of duties and apply consistently whether access is managed in an on-premises Active Directory, a cloud identity provider like Azure AD or Okta, or both.
Annex A 5.16 – Identity Management: Where 5.15 sets the policy, 5.16 governs the full identity lifecycle. Every user account human or machine must follow a documented process from provisioning through deprovisioning. In practice, this means HR-triggered onboarding workflows that create accounts, role-change workflows that adjust permissions, and termination workflows that disable accounts on the employee’s last day. The ISO standard does not prescribe a specific tool, but the process must be traceable.
Annex A 5.17 – Authentication Information: This control covers password policies, multi-factor authentication (MFA), and the management of credentials more broadly including API keys, service account passwords, and certificates. For US organizations, the NIST Digital Identity Guidelines (SP 800-63B) provide the technical baseline that most auditors expect to see referenced or adopted. Password complexity alone is no longer sufficient; MFA on all privileged and internet-facing accounts is effectively table stakes for certification.
Annex A 5.18 – Access Rights: Periodic access reviews are the mechanism this control requires. Access rights must be formally reviewed at planned intervals typically quarterly for privileged accounts and annually for standard users with documented outcomes and remediation actions taken when over-provisioned access is found. This is where many organizations discover they have hundreds of accounts with permissions accumulated over years of role changes.
| ISO 27001:2022 vs 2013 – What Changed for Access Control |
| The 2022 revision consolidated what was previously a 12-control Access Control domain (A.9) into the four controls above, embedded within the broader ‘People’ and ‘Technological Controls’ categories. If your ISMS was certified to the 2013 version, your transition audit will specifically test whether you’ve mapped legacy controls to the new structure. |
Access control policies are only effective when they are supported by broader ISO 27001 organizational controls that define governance, risk management, supplier oversight and security responsibilities across the ISMS.
The 12 Evidence Records Auditors Will Request
Certification auditors do not take your word for it. During Stage 2 audit, they will pull specific documents, logs, and records to verify that each access control is operating as designed not just written down in a policy. The following twelve evidence types align to Annex A 5.15–5.18 and represent what UKAS-accredited and ANAB-accredited auditors consistently request in US engagements.
| Evidence Record | Control | Description | Format |
|---|---|---|---|
| Access Control Policy | 5.15 | Approved, version-controlled document stating principles, scope, and ownership. Must show management sign-off date. | Policy document |
| Asset Register with Access Classifications | 5.15 | List of information assets tagged with sensitivity classification and permitted access roles. | Spreadsheet / CMDB |
| User Provisioning Records | 5.16 | Tickets or workflow records showing access requests, approvals, and account creation dates. Should link to HR onboarding. | ITSM tickets |
| Account Deprovisioning Logs | 5.16 | Evidence that accounts are disabled within a defined SLA of termination. HR termination date vs. account disable timestamp. | AD/IdP export + HR data |
| Privileged Account Register | 5.16 | Complete list of all admin and service accounts, with business justification and named owner for each. | Register / spreadsheet |
| Password and MFA Policy | 5.17 | Technical policy document covering minimum length, complexity, rotation, and MFA requirements. Should reference SP 800-63B. | Policy + IdP configuration |
| MFA Enrollment Reports | 5.17 | Exports from your identity provider showing MFA enrollment status per user, particularly for privileged accounts. | Azure AD / Okta report |
| Credential Management Procedure | 5.17 | Documented procedure for managing shared credentials, service account passwords, and API keys — including storage (e.g., vault) and rotation schedule. | Procedure document |
| Access Review Records | 5.18 | Completed access review sign-off forms or system-generated reports showing who conducted the review, which accounts were assessed, and what action was taken on exceptions. | Review records / IAM reports |
| Access Review Remediation Tickets | 5.18 | Closure evidence for access rights removed or modified as a result of periodic reviews. Auditors check that exceptions are acted on, not just noted. | ITSM tickets |
| Separation of Duties Matrix | 5.15 / 5.18 | A role matrix documenting which functions cannot be held by the same individual, with evidence of technical or compensating controls where conflicts exist. | Matrix / spreadsheet |
| Third-Party Access Records | 5.15 / 5.16 | Vendor and contractor access provisioning records, including NDA/contract links, time-limited access justifications, and deprovisioning confirmation. | Vendor management records |
| Common Gap: Deprovisioning SLA |
| The single most common nonconformity finding in access control audits is the absence of a documented and enforced SLA for disabling accounts after termination. Best practice is 24 hours for standard users and same-day for privileged accounts. If your HR system and identity provider are not integrated, this gap will surface in your audit. |
US Regulatory Crosswalk: NIST, CMMC, and HIPAA Alignment
For US organizations, ISO 27001 access control requirements do not exist in a vacuum. They sit alongside and in most cases directly overlap federal and industry regulatory frameworks. Mapping these relationships reduces duplicate effort and strengthens your compliance posture across multiple frameworks simultaneously.
NIST SP 800-53 (Rev. 5) – Access Control Family: The AC control family in NIST SP 800-53 Rev. 5 covers essentially the same ground as Annex A 5.15–5.18, but with greater technical prescriptiveness. AC-2 (Account Management) maps to ISO 5.16; AC-3 (Access Enforcement) and AC-6 (Least Privilege) underpin ISO 5.15; IA-5 (Authenticator Management) aligns with ISO 5.17. Organizations pursuing FedRAMP authorization alongside ISO 27001 certification will find that satisfying NIST SP 800-53 Rev. 5 at Moderate or High baseline largely satisfies ISO access control requirements the evidence artifacts are largely the same.
CMMC 2.0 – Level 2 Access Control Practices: Defense contractors subject to CMMC 2.0 at Level 2 must implement 110 practices derived from NIST SP 800-171 Rev. 2. The AC domain (AC.L2-3.1.1 through AC.L2-3.1.22) directly parallels ISO 27001 Annex A 5.15–5.18. Organizations building a single evidence repository a System Security Plan (SSP) cross-referenced to both CMMC practices and ISO controls can satisfy both frameworks with a unified set of access control records. This dual-use approach is increasingly standard among US defense supply chain organizations pursuing ISO 27001 alongside CMMC.
HIPAA Security Rule: For healthcare organizations, the HIPAA Security Rule’s Technical Safeguard standards at 45 CFR § 164.312(a) address access control directly. The required implementation specifications unique user identification, emergency access procedure, automatic logoff, and encryption/decryption map to ISO 27001 5.15 and 5.17. A covered entity or business associate that implements ISO 27001 access controls with the HIPAA technical safeguard requirements in mind will satisfy both sets of obligations with the same evidence base.
| ISO 27001 Control | NIST SP 800-53 Rev. 5 | CMMC 2.0 (Level 2) | HIPAA Security Rule |
|---|---|---|---|
| 5.15 Access Control Policy | AC-1 Policy & Procedures, AC-6 Least Privilege | AC.L2-3.1.1, AC.L2-3.1.2 | § 164.312(a)(1) |
| 5.16 Identity Management | AC-2 Account Management, PS-4/5 Personnel Separation/Transfer | AC.L2-3.1.1, AC.L2-3.1.6 | § 164.312(a)(2)(i) |
| 5.17 Authentication Information | IA-5 Authenticator Mgmt, IA-2 Multi-Factor Auth | IA.L2-3.5.3, IA.L2-3.5.4 | § 164.312(a)(2)(i), § 164.312(d) |
| 5.18 Access Rights Review | AC-2(j) Account Review, AC-6(7) Privilege Review | AC.L2-3.1.3 | § 164.312(a)(1) |
Building an Access Control Policy That Passes Audit
An access control policy that satisfies auditors is not a three-paragraph statement of intent. It is a structured document that answers specific questions and can be cross-referenced to the controls and evidence records your ISMS maintains.
The policy must define the scope of coverage: which systems, which user populations, and which data classifications fall under its requirements. A healthcare organization, for example, will need explicit provisions for EHR access that differ from general corporate IT systems. A defense contractor will need separate provisions for CUI systems subject to CMMC.
At minimum, an ISO 27001-compliant access control policy should address:
- The principle of least privilege – access is granted only to the minimum level necessary for a defined business purpose.
- Need-to-know basis – access to specific information categories is restricted to users who require it for their role.
- Separation of duties – defined functions that cannot be held by the same individual or role, with compensating controls where technical separation is not feasible.
- Access request and approval process – the workflow for requesting, approving, and provisioning new access rights, including required documentation.
- Periodic review requirements – frequency of access reviews by account type (privileged vs. standard), and the process for revoking over-provisioned access.
- Remote and third-party access – specific requirements for contractor, vendor, and remote worker access, including VPN requirements, time-limited access, and monitoring obligations.
- Termination procedures – the SLA for revoking access upon employment or contract termination, and the responsible parties.
One structural point that auditors frequently flag: the policy should distinguish between the principles (what is required) and the operational procedures (how it is implemented). The policy document itself should remain stable between audit cycles; detailed how-to procedures belong in supporting operational documentation that can be updated without triggering a full policy review.
| GAICC Practitioner Insight |
| Organizations that structure their access control policy as a standalone document separate from the broader Information Security Policy find it easier to maintain and easier to evidence during audits. Auditors can go directly to a single document rather than searching a larger policy for access-specific provisions. |
Identity Lifecycle Management: From Onboarding to Offboarding
Annex A 5.16 follows the identity from creation to deletion, and auditors will trace that journey in your records. The most common gaps appear at the edges provisioning that does not sync with HR onboarding dates, and deprovisioning that lags behind termination.
Joiner process: Access provisioning should be triggered by an HR system event, not an informal email request. The ITSM ticket or workflow record should show the request date, approver, systems provisioned, and the date access was granted. Where role-based access control (RBAC) is in place, provisioning should be tied to a defined role template rather than ad hoc assignment this is both more secure and easier to evidence.
Mover process: Role changes are the most undercontrolled part of the identity lifecycle in most organizations. When a user changes departments or job functions, their original access rights should be reviewed against their new role requirements and adjusted not simply augmented. The accumulation of permissions across role changes (often called “access creep”) is one of the highest-risk patterns in enterprise environments and a frequent audit finding.
Leaver process: Account deprovisioning is the control with the clearest binary outcome: either the account was disabled within the SLA, or it was not. Best-practice organizations implement an automated trigger: when HR marks an employee as terminated in the HCM system, an API call disables the account in the identity provider within the same business day. The evidence is then a simple timestamp comparison. Where automation is not in place, manual processes require documented checklists with completion signatures and dates.
Privileged and service accounts: These require separate treatment. Privileged accounts (domain admins, root accounts, security tool administrators) should be inventoried in a dedicated register with a named business owner for each. Service accounts used by applications rather than humans should not have interactive login rights, should have documented owners, and should use unique credentials stored in a secrets management vault rather than hard-coded in application configuration files.
Authentication Controls: MFA, Password Policy, and Credential Evidence
The authentication landscape has shifted substantially since the 2013 edition of ISO 27001. Annex A 5.17 in the 2022 revision reflects that shift the control now encompasses not just passwords but the full range of authentication information, including MFA tokens, biometric factors, certificates, and non-human credentials like API keys.
Password policy alignment with NIST SP 800-63B: NIST updated its Digital Identity Guidelines in 2020 (and again with SP 800-63-4 in 2024) with recommendations that contradict traditional complexity requirements. The current guidance: prioritize minimum length (at least 15 characters for standard accounts) over forced complexity rules that lead to predictable substitutions. Mandatory periodic rotation is no longer recommended except when compromise is suspected. Most US-focused auditors now expect to see password policies that align to SP 800-63B rather than legacy complexity frameworks.
MFA as a practical requirement: While ISO 27001 does not explicitly mandate MFA, auditors evaluating Annex A 5.17 in 2025 treat MFA on internet-facing systems and privileged accounts as an expected control. The absence of MFA on email, VPN, or admin consoles will typically generate an observation or a nonconformity finding depending on the auditor’s judgment of the risk. For US organizations also subject to SEC cybersecurity disclosure rules or FedRAMP requirements, MFA is an explicit technical requirement that feeds directly into ISO 27001 evidence.
Evidence for authentication controls: The evidence for 5.17 is split between policy documentation and technical configuration artifacts:
- Password policy document referencing your length, complexity, lockout, and rotation requirements
- IdP configuration screenshots or exports showing enforced password settings (Azure AD Password Protection, Okta policies)
- MFA enrollment report showing percentage of users enrolled, with privileged account enrollment at 100%
- Secrets management register showing API keys, service account credentials, and certificates with rotation dates and vault storage confirmation
- Privileged Access Management (PAM) tool reports if a PAM solution is in use
| US Auditor Expectation: MFA Coverage |
| In ANAB and UKAS-accredited certification audits of US organizations, auditors routinely request an MFA enrollment report filtered to privileged accounts. 100% MFA coverage on admin accounts is the expected baseline. Standard user MFA coverage below 90% will prompt further questions. |
Running Access Reviews That Generate Audit-Ready Evidence
Periodic access reviews are the operational heartbeat of Annex A 5.18. They are also the control where the gap between policy and practice is most visible to auditors because the evidence is either there or it is not.
Frequency and scope: ISO 27001 requires reviews at “planned intervals” without specifying exact timeframes. In practice, the following schedule is auditor-defensible and operationally manageable for most US mid-market organizations:
- Privileged accounts: quarterly
- Standard user accounts: annually or upon role change
- Third-party and contractor accounts: tied to contract renewal or access period, at minimum annually
- System and service accounts: annually with a semi-annual spot check
The review process: A defensible access review is not a manager clicking “approve all” on a list. Auditors look for evidence that each access right was individually evaluated against the user’s current role and business need. The review record should capture who conducted the review, the date, the scope (which systems or applications), and the outcome for each account specifically: access confirmed, access modified, or access revoked.
Handling exceptions: When access review reveals over-provisioning, the remediation action is the evidence that matters most. An access review that identifies problems but does not resolve them is worse than no review at all from an audit perspective. The ITSM ticket closing out the access removal with timestamps is the artifact that completes the control cycle.
Tooling options: Manual access reviews via exported spreadsheets are compliant but resource-intensive and error-prone. Most mid-to-large US organizations conducting ISO 27001 audits in 2025 use one of the following approaches:
- Identity Governance and Administration (IGA) tools such as SailPoint, Saviynt or Microsoft Entra ID Governance these generate structured review campaigns with automated reminders and certification records
- Quarterly exports from Active Directory or Okta combined with manager attestation via a structured form
- Third-party access review platforms that integrate with common identity providers and generate audit-ready reports
Access Control in Cloud and Hybrid Environments
On-premises Active Directory managed access control for most US organizations through the 2010s. The current reality hybrid environments where some systems are on-premises and others in AWS, Azure, GCP, or SaaS platforms creates both complexity and common evidence gaps.
ISO 27001 Annex A 5.15–5.18 apply regardless of where systems sit. The controls do not differentiate between on-premises and cloud identity management. What changes in cloud environments is how access rights are expressed and how evidence is collected.
IAM in AWS and Azure: AWS Identity and Access Management (IAM) and Azure Active Directory (now Entra ID) each have native access review capabilities. AWS IAM Access Analyzer can identify unused permissions and external access at the resource level. Azure Entra ID Governance includes access reviews that can be configured to run on a scheduled basis with manager or resource-owner attestation. The reports these tools generate are directly usable as Annex A 5.18 evidence.
SaaS application access: One of the most common access control gaps in hybrid environments is SaaS applications provisioned outside the central identity governance process. Employees with direct logins to tools like Salesforce, GitHub, or Slack bypassing SSO represent unmanaged access rights that will not appear in centralized reviews. ISO 27001 auditors will ask about your SaaS application inventory and whether all user access is centrally governed or independently managed.
Zero Trust alignment: The NIST SP 800-207 Zero Trust Architecture framework increasingly referenced in US federal agency guidance and DOD requirements aligns well with ISO 27001 access control principles. Zero trust’s core premise (verify explicitly, use least privilege access, assume breach) maps directly to Annex A 5.15 principles. Organizations implementing Zero Trust as a security architecture can document that alignment as a maturity signal in their ISMS.
For a complete understanding of how access control fits into the standard, refer to the ISO 27001 Annex A controls list, which explains all 93 controls introduced in ISO/IEC 27001:2022
| Evidence Tip: Cloud Access Review Exports |
| AWS IAM Credential Reports and Azure Entra ID Access Review reports can be exported directly and stored as evidence artifacts in your ISMS document management system. Schedule a quarterly export and store the timestamped file alongside your review sign-off record. |
| Prepare for ISO 27001 Certification with GAICC |
| The GAICC ISO 27001 Lead Implementer certification equips you to build, document, and evidence ISMS controls including the full access control domain to the standard certification auditors apply. The program covers Annex A control implementation, evidence record construction, and audit readiness preparation with a US regulatory context. |
Frequently Asked Questions
What is the difference between Annex A 5.15 and 5.18 in ISO 27001:2022?
Annex A 5.15 covers the access control policy the principles and rules governing how access is granted. Annex A 5.18 covers the operational enforcement of those principles through periodic access rights reviews. Think of 5.15 as the rule book and 5.18 as the compliance check that verifies the rules are being followed.
How often does ISO 27001 require access rights to be reviewed?
ISO 27001 requires reviews at ‘planned intervals’ without specifying a timeframe. Most organizations and auditors accept quarterly reviews for privileged accounts and annual reviews for standard users as a defensible schedule. The key requirement is that the frequency is documented in your policy and consistently followed.
Does ISO 27001 require multi-factor authentication?
ISO 27001 Annex A 5.17 does not explicitly mandate MFA, but it requires that authentication information is managed appropriately to protect against unauthorized access. In practice, US certification auditors treat MFA on internet-facing systems and privileged accounts as an expected control. The absence of MFA will typically generate an audit observation or finding.
How does ISO 27001 access control align with CMMC 2.0 requirements?
CMMC 2.0 Level 2’s AC domain (derived from NIST SP 800-171) parallels ISO 27001 Annex A 5.15–5.18 closely. Organizations can build a unified evidence set a System Security Plan cross-referenced to both CMMC practices and ISO controls that satisfies both frameworks. CMMC is generally more prescriptive on technical implementation details, while ISO 27001 is more principles-based.
What happens if an access review identifies over-provisioned accounts?
The review itself is not the evidence auditors care about most the remediation is. When an access review finds over-provisioned access, the organization must remove or adjust those rights and document the action with timestamps. An ITSM ticket showing the access removal, closed within the defined remediation SLA, completes the control cycle. Reviews that find problems but do not act on them will generate nonconformity findings.
What is the SLA for disabling accounts after employee termination?
ISO 27001 does not specify an exact SLA, but your access control policy must define one, and auditors will test whether it is being met. Industry standard is same-day or within 24 hours for privileged accounts, and within one to three business days for standard accounts. The evidence is a timestamp comparison between the HR termination date and the account disable event in your identity provider.
Conclusion
ISO 27001 access control is not a paper exercise. Annex A 5.15 through 5.18 require a functioning identity lifecycle, a policy that reflects how the organization actually manages access, periodic reviews with documented outcomes, and authentication controls that account for the current threat landscape. The organizations that fare best in certification audits are those that built the evidence records as a natural byproduct of running their controls not those that scrambled to reconstruct documentation in the weeks before the Stage 2 audit.
For US organizations, the alignment between ISO 27001 access control and NIST SP 800-53, CMMC 2.0, and HIPAA is a genuine efficiency opportunity. A single set of well-documented access controls, mapped across frameworks, satisfies multiple compliance obligations simultaneously.
Ready to build an audit-ready access control program? The GAICC ISO 27001 Lead Implementer certification provides the framework-level expertise to implement and evidence every Annex A control including the full access control domain.
