What Auditors Actually Look for in Access Control Evidence

Access controls are consistently the most-tested area in both SOC 2 and ISO 27001 audits. They're also the area where companies most frequently generate findings. The gap isn't usually a missing control — it's a misunderstanding of what auditors actually need to see to give a control a pass.

This post focuses on access control specifically. Not because other areas don't matter, but because access control testing is where most audit time is spent and where most findings originate. If you get this right, you've addressed the primary audit risk.

The Three Access Control Questions Every Auditor Asks

Regardless of framework, auditors are trying to answer three questions about your access control program:

1. Do people get access to the right systems through a documented, approved process?
2. Do you review existing access on a regular basis and remove access that's no longer appropriate?
3. Is access removed promptly when someone leaves the company?

These questions map to SOC 2 CC6.1 (logical access security), CC6.2 (access provisioning), CC6.3 (access removal), and ISO 27001 controls 5.15, 5.16, 5.17, 5.18. The evidence requirements for each are different, and auditors look for specific things in each category.

Access Provisioning Evidence

For provisioning, auditors want to see: the request, the approval, and the implementation. All three. A ticket in Jira or ServiceNow showing the request and manager approval, followed by evidence that the access was actually granted, is the standard evidence structure.

Common gaps:

• Verbal approvals. If your process is "ask your manager on Slack and they'll tell IT," that's not auditable. The approval needs to be documented in a system that retains it. Slack messages are acceptable if your retention policy keeps them, but a ticketing system is cleaner.
• Provisioning without request records. If you have access in your IdP but no request record, auditors will flag it. This particularly shows up when engineers provision their own access directly.
• Privilege escalation without re-approval. If a user's role changes and their access is updated without a new approval, that's a finding. The upgrade to admin access needs its own approval record, separate from the original provisioning.

Auditors typically sample 10–25 provisioning events from the observation period. They'll pick a mix of standard and privileged access grants. For each sample, they want: the request date, who requested, who approved, and the IdP record showing when access was granted. If any of these are missing for a sampled event, it's a finding.

Access Review Evidence

This is where most companies fall short. Quarterly access reviews are required under most serious SOC 2 programs. The evidence requirement is more involved than most people realize.

Auditors want to see four things for each review cycle:

1. The roster that was reviewed — a system-generated list of users and their access levels at the review date
2. Evidence that a qualified person reviewed it — a sign-off record with a name and date
3. The results of the review — which users were confirmed as appropriate, which were flagged for removal
4. Evidence of remediation — for any user who was flagged, proof that the change was made

The step most companies miss is number 4. Doing the review and making the list is not the same as making the changes. Auditors will cross-reference the flagged users in your review results against your current IdP state. If someone was marked for removal in Q2 and still has access in Q3, that's a significant finding — it means your review process has no enforcement mechanism.

The review also needs to cover privileged access specifically. Many companies do a basic user review but don't separately review admin accounts, service accounts, and API keys. SOC 2 CC6.3 and ISO 27001 8.2 both require explicit review of privileged accounts, and auditors will ask for it separately.

Offboarding Evidence

Termination and offboarding access removal is one of the highest-risk areas and the one auditors probe most aggressively. They'll sample a set of terminated employees from your observation period and check whether their access was removed — from every relevant system, not just your primary IdP.

The evidence required: a documented offboarding checklist or ticket showing when the termination was effective and when access was removed from each system. Auditors typically want to see removal within 24 hours of termination for SOC 2, and "without delay" for ISO 27001 (which most auditors interpret as same-day for active employees).

The failures are predictable:

• Access removed from Okta but not from individual SaaS tools that don't federate through SSO
• Contractors whose access was never formally provisioned and therefore never formally revoked
• API keys and service accounts associated with former employees that were never rotated
• Shared accounts where access removal requires a credential change that nobody completed

The last one is particularly common. If you have any shared accounts or service credentials, your offboarding process needs to include a check for whether the departing person had access to those credentials, and a rotation step if they did.

What Good Access Control Evidence Looks Like

The companies that consistently pass access control testing without findings share a few structural traits: they use their IdP as the authoritative access record, they run access reviews through their ticketing system so there's a built-in audit trail, and they have an automated offboarding workflow that fires on HR system termination events.

The gap between "we have access controls" and "we can prove our access controls function correctly" is mostly a record-keeping problem. The controls themselves are often fine. The documentation of when they ran, who reviewed them, and what happened as a result is where the audit evidence falls short.