ISO 27001 Access Control Audit Evidence Guide

It is 09:10 on audit day. Maria, the CISO of a fast-growing FinTech and cloud platform, has her access control policy open. The IT lead is exporting conditional access settings from the identity provider. HR is searching for the termination ticket of a finance analyst who left six weeks ago. The internal auditor looks up and asks the question everyone knew was coming:

“Show me how access is requested, approved, enforced, reviewed and removed for a user with privileged access to personal data.”

That single sentence can expose whether an access control program is audit-ready or merely policy-ready.

Maria’s team had a mature Information Security Management System, an annual ISO/IEC 27001:2022 recertification cycle, multi-factor authentication in place, role-based access controls in core systems and quarterly access review spreadsheets. But this audit was different. The auditor’s request list included preparedness for emerging regulatory requirements. For Maria’s organization, that meant NIS2, DORA and GDPR, all examined through the same operational lens: identity, access, authentication, privilege and evidence.

The problem facing many CISOs is not that access control does not exist. The problem is that evidence exists in fragments. Onboarding approvals live in Jira or ServiceNow. MFA settings live in Microsoft Entra ID, Okta or another identity provider. AWS, Azure and Google Cloud permissions sit in separate consoles. Privileged actions may be logged in a PAM tool, or not at all. HR status sits in BambooHR, Workday or spreadsheets. Access reviews may be signed off in email.

When an auditor connects IAM, MFA, PAM, Joiner-Mover-Leaver events, personal data, cloud administration and regulatory expectations, fragmented evidence breaks apart quickly.

ISO/IEC 27001:2022 access control audits are not just technical configuration reviews. They are management-system tests. They examine whether identity and access risks are understood, treated, implemented, monitored and improved. When NIS2, DORA and GDPR are also relevant, the same evidence must show risk-based access governance, strong authentication, traceable approvals, timely revocation, privilege restriction, personal data protection and management accountability.

The practical answer is not a bigger binder. It is one access control evidence model that starts with ISMS scope and risk, flows through policy and control design, lands in IAM and PAM tooling, and maps cleanly to ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST and COBIT.

Why access control is the regulatory linchpin

Access control has become a board-level and regulator-facing topic because identity compromise is now a common path to operational disruption, data breach, fraud and supply chain exposure.

Under NIS2, Articles 2 and 3, read with Annex I and Annex II, bring many medium-sized and larger entities in listed sectors into scope as essential or important entities. This includes digital infrastructure and ICT service management providers such as cloud computing service providers, data centre service providers, managed service providers and managed security service providers. Member States were required to transpose NIS2 by October 2024 and apply national measures from October 2024, with entity lists due in April 2025. Article 20 makes management bodies responsible for approving cybersecurity risk-management measures and overseeing implementation. Article 21 requires technical, operational and organizational measures, including access control policies, asset management, cyber hygiene, incident handling, business continuity, supply chain security and MFA or continuous authentication where appropriate.

DORA adds a sector-specific operational resilience layer for financial entities and relevant ICT third-party service providers. Articles 1, 2 and 64 establish DORA as a uniform framework applying from 17 January 2025. Articles 5 and 6 require governance and a documented ICT risk management framework. Article 9 addresses protection and prevention, including ICT security policies, procedures, protocols and tools. Articles 24 to 30 add digital operational resilience testing and ICT third-party risk management. For financial entities, access control evidence becomes resilience evidence, not just IT administration evidence.

GDPR brings the personal data lens. Articles 2 and 3 define broad applicability for EU processing and EU market reach. Article 5 requires integrity, confidentiality and demonstrable accountability. Article 25 requires data protection by design and by default. Article 32 requires appropriate technical and organizational measures. In practice, that means controlled access, secure authentication, logging, review and timely removal for systems processing personal data.

ISO/IEC 27001:2022 gives organizations the management-system engine to unify these obligations. Clauses 4.1 to 4.3 require the organization to understand context, interested parties, legal and contractual requirements, interfaces, dependencies and ISMS scope. Clauses 6.1.1 to 6.1.3 require information security risk assessment, treatment, Annex A comparison, a Statement of Applicability and approval of treatment plans and residual risk. Clause 8.1 requires operational control, documented information showing processes occurred as planned, change control and control over externally provided processes.

The audit question is therefore not “Do you have MFA?” It is “Can you prove, for in-scope identities and systems, that access risk is governed, treated, implemented, monitored and improved?”

Build the evidence spine from ISMS scope to IAM proof

Clarysec starts access control audit preparation by making evidence traceable from the business context. ISO/IEC 27001:2022 expects the ISMS to be integrated into organizational processes and scaled to the organization’s needs. A 30-person SaaS vendor and a multinational bank will not have the same access architecture, but both need a coherent chain of evidence.

ISO/IEC 27005:2022 is useful because it recommends consolidating legal, regulatory, contractual, sector-specific and internal requirements into a common risk context. Clauses 6.4 and 6.5 emphasize risk criteria that consider organizational objectives, laws, supplier relationships and constraints. Clauses 7.1 and 7.2 allow event-based and asset-based scenarios. For access control, that means assessing strategic scenarios such as “privileged SaaS administrator exports EU customer data” alongside asset scenarios such as “orphaned AWS IAM key attached to production storage.”

In Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap, this evidence spine is built during the Controls in Action phase. Step 19 focuses on technological controls for endpoint and access management, while Step 22 formalizes the organizational access lifecycle.

The Zenith Blueprint tells teams to verify that provisioning and deprovisioning are structured, integrated with HR where possible, supported by access request workflows and reviewed quarterly. It also instructs organizations to document identity types, enforce controls for individual, shared and service identities, apply strong password policies and MFA, eliminate dormant accounts, and maintain secure vaulting or documentation for service credentials.

That is exactly how auditors test access control: one identity, one system, one approval, one privilege, one review and one revocation at a time.

What to collect for audit-ready access control evidence

Your access control evidence pack should allow an auditor to sample any user and trace the lifecycle: request, approval, assignment, authentication, privileged elevation, monitoring, review and revocation.

A strong evidence pack includes:

1. Access control policy and user account policy
2. Joiner-Mover-Leaver procedure
3. Role matrix or access control matrix
4. List of in-scope applications, platforms and data repositories
5. Identity provider MFA configuration
6. Conditional access policies and exception list
7. Privileged account inventory
8. PAM workflow evidence, including approvals and session logs
9. Recent access review campaign output
10. Sample manager attestations and remediation actions
11. HR termination report matched to deactivation logs
12. Service account inventory, owners, rotation records and vault evidence
13. Break-glass account procedure and test log
14. Incident or alert evidence involving failed logins, privilege escalation or dormant accounts
15. Statement of Applicability entries for access-related Annex A controls

Clarysec policies make this expectation explicit. In the SME Access Control Policy-sme, the requirement is simple and audit-focused:

“A secure record must be maintained for all access provisioning, modifications, and removals.”

From section “Policy Implementation Requirements,” clause 6.1.1.

The same SME policy also links RBAC and MFA directly to role responsibilities:

“Implements role-based access controls (RBAC) and enforces strong authentication (e.g., multi-factor authentication (MFA)).”

From section “Roles and Responsibilities,” clause 4.2.3.

For larger organizations, the enterprise Onboarding and Termination Policy requires the IAM system to log account creation, role and permission assignments, and deactivation events, support role-based access templates, and integrate with HR systems for Joiners-Movers-Leavers triggers. That clause helps tell the audit story in one place: standardized onboarding, HR-triggered identity lifecycle and traceable IAM events.

Map IAM, MFA, PAM and reviews to ISO/IEC 27001:2022 controls

Clarysec’s Zenith Controls: The Cross-Compliance Guide treats access control as a connected control family, not a checklist item. For ISO/IEC 27001:2022, the most relevant controls include:

• Control 5.15, Access control
• Control 5.16, Identity management
• Control 5.17, Authentication information
• Control 5.18, Access rights
• Control 8.2, Privileged access rights
• Control 8.3, Information access restriction
• Control 8.5, Secure authentication
• Control 8.15, Logging
• Control 8.16, Monitoring activities

For Authentication information, Zenith Controls maps control 5.17 as a preventive control supporting confidentiality, integrity and availability, with the operational capability of Identity and Access Management. It ties directly to identity management, secure authentication, roles and responsibilities, acceptable use and compliance with policies. Credential security includes authenticator lifecycle, secure issuance, storage, reset, revocation, MFA tokens, private keys and service credentials.

For Access rights, Zenith Controls maps control 5.18 to formal granting, review, modification and revocation. It ties to access control, identity management, segregation of duties, privileged access rights and compliance monitoring. This is the control that turns least privilege into evidence.

For Privileged access rights, Zenith Controls maps control 8.2 to the special risk of elevated accounts, including domain administrators, root users, cloud tenant admins, database superusers and CI/CD controllers. The guide connects privileged access to identity management, access rights, information access restriction, secure authentication, remote working, logging and monitoring.

A single well-designed access review report can support ISO/IEC 27001:2022, NIS2, DORA and GDPR if it includes scope, system owner, reviewer, account list, role justification, privileged flag, decisions, removals, exceptions and completion date.

MFA evidence is more than a screenshot

A common audit mistake is presenting a screenshot that says “MFA enabled.” Auditors need more than that. They need to know where MFA applies, who is excluded, how exceptions are approved, whether privileged accounts are covered, and whether the technical configuration matches policy.

From the Zenith Blueprint, Controls in Action phase, Step 19, auditors will ask how password and MFA policies are enforced, which systems are protected, who MFA applies to, and whether critical applications can be tested with a sample account. Evidence may include IdP configuration, conditional access policies, MFA enrollment statistics and password reset procedures.

For enterprise environments, Clarysec’s User Account and Privilege Management Policy states:

“Where technically feasible, multi-factor authentication (MFA) is mandatory for: 6.3.2.1 Administrative and root-level accounts 6.3.2.2 Remote access (VPN, cloud platforms) 6.3.2.3 Access to sensitive or regulated data”

From section “Policy Implementation Requirements,” clause 6.3.2.

This creates a direct audit bridge. If MFA is mandatory for admin accounts, remote access and regulated data, the evidence pack should include administrative and root-level account lists, remote access configuration, cloud platform conditional access policies, sensitive data application lists, MFA enrollment reports, exception approvals, compensating controls and recent alert review evidence for failed logins or MFA bypass attempts.

For NIST SP 800-53 Rev. 5, this aligns with IA-2 Identification and Authentication, IA-5 Authenticator Management, AC-17 Remote Access and AU-2 Event Logging. For COBIT 2019, it supports DSS05.04 Manage user identity and logical access and related security monitoring practices.

Supporting ISO standards broaden the picture. ISO/IEC 27018:2020 extends authentication expectations for public cloud handling personal data. ISO/IEC 24760-1:2019 supports authenticator binding and lifecycle management. ISO/IEC 29115:2013 introduces authentication assurance levels, useful when deciding where hardware tokens or phishing-resistant MFA are necessary. ISO/IEC 27033-1:2015 supports strong network authentication for remote or inter-network access.

PAM evidence is the fastest route to a major finding or a clean audit

Privileged access is where auditors become skeptical because privileged accounts can override controls, extract data, create persistence and alter logs. In Zenith Blueprint, Step 19 states:

“In any information system, privileged access is power , and with that power comes risk.”

The guidance focuses on who has privileged access, what it allows, how it is managed and how it is monitored over time. It recommends an up-to-date inventory, least privilege, RBAC, time-based or just-in-time elevation, approval workflows, unique named accounts, avoidance of shared accounts, break-glass logging, PAM systems, credential rotation, vaulting, session recording, temporary elevation, monitoring and regular review.

Clarysec’s enterprise Access Control Policy turns this into a control requirement:

“Administrative access must be tightly controlled through: 5.4.1.1 Separate privileged accounts 5.4.1.2 Session monitoring and recording 5.4.1.3 Multi-factor authentication 5.4.1.4 Time-bound or workflow-triggered elevation”

From section “Governance Requirements,” clause 5.4.1.

This quote is almost an audit test script. If the policy says separate admin accounts, show the privileged account list and prove each one maps to a named person. If it says session monitoring, show recorded sessions or PAM logs. If it says MFA, show enforcement for every privileged access path. If it says time-bound elevation, show expiration timestamps and approval tickets.

The SME version is equally direct. The User Account and Privilege Management Policy-sme states:

“Elevated or administrative privileges require additional approval by the General Manager or IT Lead and must be documented, time-bound, and subject to periodic review.”

From section “Policy Implementation Requirements,” clause 6.2.2.

For smaller organizations, this is often the difference between “we trust our admin” and “we control privileged risk.” The auditor does not require enterprise tooling in every SME, but they do require evidence proportionate to risk. A ticket, approval, temporary group assignment, MFA enforcement and review record may be enough when scope is limited and risk is lower.

Access reviews prove least privilege is operating

Access reviews show whether permissions silently accumulate. They also show whether managers understand the access their teams actually hold.

The enterprise User Account and Privilege Management Policy requires:

“Quarterly reviews of all user accounts and associated privileges must be conducted by IT Security in collaboration with department managers.”

From section “Policy Implementation Requirements,” clause 6.5.1.

For SMEs, the User Account and Privilege Management Policy-sme sets a proportionate cadence:

“A review of all user accounts and privileges must be performed every six months.”

From section “Policy Implementation Requirements,” clause 6.4.1.

A credible access review includes system name, scope, reviewer name, export date, review date, identity owner, department, manager, employment status, role or entitlement, privileged flag, data sensitivity flag, decision, remediation ticket, closure date, exception owner and exception expiry date.

For Zenith Controls, access rights 5.18 is where this becomes cross-compliance evidence. The guide maps access rights to GDPR Article 25 because access should be limited by design and default. It maps to NIS2 Article 21(2)(i) because access control policies and asset management require risk-based assignment, timely removal of unnecessary access and formal revocation. It maps to DORA because financial ICT systems need role-based access, monitoring and revocation processes.

NIST-oriented auditors often test this through AC-2 Account Management, AC-5 Separation of Duties and AC-6 Least Privilege. COBIT 2019 auditors look to DSS05.04 Manage user identity and logical access and DSS06.03 Manage roles, responsibilities, access privileges and levels of authority. ISACA ITAF auditors focus on whether evidence is sufficient, reliable and complete.

Offboarding and token revocation are easy to sample

Leavers are one of the easiest places to prove whether the lifecycle works. Auditors often select a recent terminated employee and ask for the HR termination record, ticket, account disablement log, SaaS deactivation evidence, VPN removal, MFA revocation, API token removal and asset return.

In the Onboarding and Termination Policy-sme, Clarysec states:

“Terminated accounts must be locked or deleted, and associated access tokens must be revoked, including remote access (VPN), MFA app bindings, and API tokens.”

From section “Policy Implementation Requirements,” clause 6.3.3.

This matters because modern access is not only a username and password. Access can persist through refresh tokens, API keys, SSH keys, OAuth grants, service accounts, local admin rights, mobile sessions and third-party portals. A deactivated HR record without token revocation is incomplete evidence.

The Zenith Blueprint, Controls in Action phase, Step 16, tells organizations to be ready with a documented termination checklist, evidence from a recent leaver, a user account disablement log from AD or MDM, a signed asset return form and offboarding documentation that includes confidentiality obligations.

Maria’s auditor asked for a departing senior developer who had privileged access to production databases. Her team presented the Onboarding and Termination Policy-sme, the termination checklist built from Zenith Blueprint Step 16, the HR-triggered ITSM ticket, the directory disablement log, the VPN certificate revocation, the GitHub organization removal, the AWS IAM key deletion and the closed verification ticket signed by the IT manager. The evidence was complete, timely and directly tied back to policy.

Run a three-sample evidence sprint before the auditor does

A practical readiness exercise is to pick three samples before the audit:

1. A new employee who joined in the last 90 days
2. A privileged user with admin access to cloud, database, production or IAM
3. A leaver or role-changed employee from the last 90 days

Then connect each sample to the ISMS records: risk scenario, treatment decision, Statement of Applicability control selection, policy clause, technical configuration, review record and corrective action if any gap exists.

This turns audit preparation from document collection into control verification.

Prepare for different audit lenses

Different audit backgrounds lead to different questions, even when the evidence is the same.

Preparing evidence that satisfies all these perspectives demonstrates a mature compliance program and reduces duplicate work.

Common findings and preventive actions

Access control findings are predictable. The preventive actions are too.

The enterprise Access Control Policy adds a retention requirement that prevents one of the most common evidence failures:

“Approval decisions must be logged and retained for audit purposes for a minimum of 2 years.”

From section “Governance Requirements,” clause 5.3.2.

If approvals disappear after email cleanup, the control may have operated, but the audit cannot rely on it. Retention is part of control design.

Management accountability needs access metrics

NIS2 Article 20 and DORA Articles 5 and 6 make access control a management concern because identity compromise can become operational disruption, regulatory reporting, data breach and customer harm. ISO/IEC 27001:2022 Clauses 5.1 to 5.3 also require top management to align the ISMS with business strategy, provide resources, communicate importance, assign responsibilities and promote continual improvement.

Useful access control metrics include:

• Percentage of critical systems covered by SSO
• Percentage of privileged accounts with MFA
• Number of standing privileged accounts versus JIT accounts
• Access review completion rate
• Number of revoked excessive permissions
• Leaver deactivation SLA compliance
• Dormant account count
• Service account owner coverage
• PAM session recording coverage
• MFA exception count and age

These metrics help management approve risk treatment and demonstrate oversight. They also make audits more credible because the organization can show access control is monitored as a live risk, not rediscovered before every audit.

Turn scattered evidence into audit confidence

If ISO/IEC 27001:2022 access control evidence is scattered across HR, ITSM, IAM, PAM, cloud consoles and spreadsheets, the next step is not another policy rewrite. The next step is evidence architecture.

Start with this sequence:

1. Define in-scope systems, identities and data.
2. Map NIS2, DORA, GDPR and contractual requirements into the ISMS context.
3. Use ISO/IEC 27005:2022-style risk scenarios to prioritize IAM, MFA, PAM and access reviews.
4. Update the Statement of Applicability and risk treatment plan.
5. Align policy clauses with actual IAM and PAM workflows.
6. Run the three-sample evidence sprint.
7. Fix gaps before the auditor finds them.
8. Maintain a reusable evidence pack for certification, customer due diligence and regulatory reviews.

Clarysec can help you implement this through the Zenith Blueprint: An Auditor’s 30-Step Roadmap, cross-map requirements using Zenith Controls: The Cross-Compliance Guide, and operationalize requirements with the right Clarysec policy set, including Access Control Policy, User Account and Privilege Management Policy, and Onboarding and Termination Policy.

Access control audit readiness is not about proving you bought an IAM tool. It is about proving that identity, authentication, privilege and review processes reduce real business risk and satisfy the standards and regulations that matter to your organization.

Download the Clarysec toolkits, run the three-sample evidence sprint, and turn your access control evidence from a scattered mess into a clear, repeatable and defensible audit portfolio.