Access Control Policy: What Auditors Expect
An access control policy passes an audit when it matches what your systems actually do, not when it reads well. Auditors sample real access grants, real terminations, and real reviews against the policy's own claims. A polished document with no matching evidence fails every time.
Quick answer. An access control policy that passes audit names specific systems and roles, defines who approves each access grant, sets a fixed review cadence, and is backed by evidence, such as tickets and access logs, that the policy was actually followed. Under SOC 2 it maps to CC6.1 through CC6.3. Under ISO 27001:2022 it maps to Annex A 5.15 through 5.18 and 8.2 through 8.3.
What a policy needs to say
A policy that survives sampling covers five things directly, without vague language:
- Who can request access, and to what systems.
- Who approves each request, and what they check before approving.
- How access is provisioned, including whether it goes through single sign-on or a system with its own local accounts.
- How and when access is reviewed, with a stated cadence, not "periodically."
- How access is removed, on a role change and on termination, with a stated time limit.
A policy that says "access is granted based on need" without naming an approver, a system, or a timeline gives an auditor nothing to sample against. Specificity is what makes a policy testable.
Where it maps: SOC 2 CC6.1 to CC6.3
CC6.1 covers the logical access controls themselves: multi-factor authentication, role-based access, and least privilege. Your policy should state that MFA is required, not optional, for every account, including admin and service accounts.
CC6.2 covers how new access is issued. The policy needs an approval step before provisioning, tied to a real person and a documented business reason. Access requested and granted over a Slack message with no record behind it fails this test even if the person genuinely needed it.
CC6.3 covers removing or changing access when someone's role changes or they leave. This is the highest-risk sub-criteria in most audits, because auditors compare HR termination dates against directory deactivation timestamps directly. A policy that promises removal "promptly" needs a number behind it, most commonly same-day or within 24 hours.
For the full breakdown of all eight CC6 sub-criteria, see how to meet SOC 2 CC6 access controls.
Where it maps: ISO 27001 Annex A 5.15 to 5.18 and 8.2 to 8.3
ISO 27001:2022 splits the same ground across six controls:
- 5.15 Access control - the overarching rule for how access to information and systems is restricted, and the anchor control your policy sits under.
- 5.16 Identity management - how identities are created, verified, and managed across their lifecycle, from onboarding through offboarding.
- 5.17 Authentication information - how credentials such as passwords and MFA factors are managed and protected.
- 5.18 Access rights - provisioning, reviewing, and revoking rights, tied to a defined process rather than ad hoc requests.
- 8.2 Privileged access rights - tighter controls specifically for admin and other elevated accounts, since these carry the most risk.
- 8.3 Information access restriction - restricting access to information itself, not just systems, based on the access control policy and business requirements.
The ISO and SOC 2 requirements overlap heavily. A policy written to satisfy CC6.1 through CC6.3 covers most of 5.15 through 5.18 and 8.2 through 8.3 with the same evidence, which is the main reason to run both frameworks off one control set rather than two.
What makes a policy fail under sampling
The policy document is rarely the problem. These are the gaps that actually surface when an auditor samples against it:
Common gap
Common gap: The policy states a quarterly access review cadence, but the last review on file is from over a year ago, or no review record exists at all.
Common gap
Common gap: The policy promises deprovisioning within 24 hours, but a sampled termination shows an active account two weeks after the employee's last day.
Common gap
Common gap: The policy requires MFA for all users, but a handful of legacy or service accounts are exempt with no documented reason.
What good evidence looks like
For each requirement in the policy, keep the artifact that proves it happened: a signed acknowledgment of the policy itself, access request tickets showing approver and reason, SSO or directory exports showing deactivation timestamps against HR termination dates, and a dated access review with findings and follow-up actions. None of this needs to be complicated. It needs to exist, be dated, and match what the policy says will happen.
Writing a policy that matches reality, and then keeping the evidence current across an entire audit period, is exactly the kind of ongoing work a fractional CISO owns for you. If you want someone to write this policy and keep it audit-ready, see the SOC 2 readiness plan or book a call. See pricing if you want the numbers first.