Your auditor doesn't want to read your access control policy. They want to see it working - timestamped, signed, and traceable across every system your people touch.

That gap between "we have a policy" and "here is the evidence" is where most ISO 27001 and SOC 2 audits stall. Findings pile up not because organizations lack controls, but because they can't produce the artifacts that prove those controls operated consistently over time. [1] is a major challenge precisely because controls that don't generate evidence in an acceptable format - with timestamps - leave teams scrambling in the days before an audit.

This playbook maps every identity artifact an auditor will ask for, control by control, for both ISO 27001:2022 Annex A and SOC 2 Common Criteria (CC6). For each artifact type, we describe what a strong evidence package looks like and where manual approaches break down.

The Framework Map: ISO 27001 Annex A ↔ SOC 2 CC6

Before diving into artifacts, it helps to know which controls you're satisfying simultaneously. [2] overlap significantly: the evidence required to satisfy SOC 2 CC6.1 and ISO 27001 Annex A 5.15 is largely identical - documented access control policies, records of periodic user access reviews, and logs showing timely deprovisioning. Evidence prepared for one audit can be directly reused for the other.

ISO 27001:2022 Annex A contains 93 controls across four categories: Organizational, People, Physical, and Technological. The access-control cluster spans A.5.3 (Segregation of Duties), A.5.15 (Access Control), A.5.16 (Identity Management), A.5.18 (Access Rights), and A.8.2 (Privileged Access Rights). On the SOC 2 side, [3] governing everything from logical access architecture to how you manage SSH keys. CC6 and CC7 together account for 68% of exceptions found in qualified SOC 2 reports.

Generating image…

The 8 Identity Artifact Categories - and What Auditors Actually Ask For

1. User Access Review / Certification Records

ISO 27001 controls: A.5.15, A.5.18 | SOC 2 criteria: CC6.3

[4] population lists (all users with access), approval records for provisioning, periodic access reviews, and proof that terminated users lose access promptly.

What the auditor asks: "Show me your last access review. Who reviewed it, when was it completed, and what access was removed as a result?"

What strong evidence looks like:

  • Dated review reports with named reviewers and their sign-off (not just a checkbox)
  • A record of what changed - access removed, access retained with justification
  • Timestamps showing the review completed within the required cadence
  • [2], sampled by the auditor to test operating effectiveness

ISO 27001:2022 requires privileged access to be reviewed at minimum every 6 months; SOC 2 doesn't specify a frequency but expects periodic reviews with documented outcomes. [5] covers both frameworks and is defensible in any audit context.

The auditor red flag: A review where nobody lost access. [6] - it signals the review was a rubber stamp, not a real control.

2. Joiner-Mover-Leaver (JML) Provisioning and Deprovisioning Logs

ISO 27001 controls: A.5.15, A.5.16 | SOC 2 criteria: CC6.2

[7] requires a formal process for the unique identification and registration of users, including the immediate removal of access upon termination of employment.

What the auditor asks: "Show me what happened the last time someone left. Walk me through the evidence."

What strong evidence looks like:

  • [7] (e.g., Jira/ServiceNow) showing timestamps for access creation and revocation
  • Cross-reference of recent leavers against active account lists - [8]
  • Mover records showing old permissions were removed when roles changed, not just new ones added
  • Evidence covering your full app stack - not just SSO-connected apps

The auditor red flag: [7]. Orphaned accounts are the most common identity-related finding in compliance audits.

3. Segregation of Duties (SoD) Conflict Reports

ISO 27001 controls: A.5.3, A.8.2 | SOC 2 criteria: CC6.3

[9]. The classic toxic combination: the same person who requests access also approves it. Or the developer who writes code also deploys it to production.

What the auditor asks: "Show me your SoD matrix. Show me that the person requesting access cannot also approve it."

What strong evidence looks like:

  • A defined matrix of conflicting roles (e.g., Developer vs. Release Manager), version-controlled and current
  • RBAC configuration exports showing technical enforcement of role separations
  • [9]
  • For small teams: documented exceptions with compensating controls (e.g., enhanced logging, independent management review) and the rationale for why full separation isn't feasible

The auditor red flag: [10]. A policy stating "all access requests are approved by a separate authoriser" when the IT Manager approves their own requests will collapse the moment an auditor traces three recent tickets.

4. Privileged Access Records

ISO 27001 controls: A.8.2 | SOC 2 criteria: CC6.3

[5]. The intent is consistent across frameworks.

What the auditor asks: "Show me your list of privileged users. Show me the approval for each. Show me the last review."

What strong evidence looks like:

  • [11]
  • [11]
  • [11]
  • Session logs or PAM records for sensitive operations
  • Evidence that privileged logs are stored where the privileged user cannot edit them - [12]

The auditor red flag: The ISO 27001 6-month review requirement for privileged access is often missed because organizations lump privileged and regular access reviews together, then run them annually.

5. Least-Privilege / Entitlement Evidence

ISO 27001 controls: A.5.15, A.5.18 | SOC 2 criteria: CC6.1, CC6.3

[8] for all entities - employees, contractors, service accounts, and automated processes.

What the auditor asks: "Show me your RBAC model. How do you know users only have the access they need for their current role?"

What strong evidence looks like:

  • [7]
  • Evidence that access is granted based on role, not personal request
  • Entitlement reports showing current permissions vs. role baseline - highlighting over-provisioned accounts
  • Records showing that when someone moved roles, their old permissions were removed (not just new ones added)

The auditor red flag: [8] - is one of the most common findings auditors surface.

6. Orphaned and Dormant Account Reports

ISO 27001 controls: A.5.16 | SOC 2 criteria: CC6.2

[8] - are invisible to most monitoring tools and ideal for attackers.

What the auditor asks: "Show me the list of users in your Active Directory. Now show me your HR termination list from the last 90 days. Let's compare."

What strong evidence looks like:

  • Regular orphaned-account reports cross-referenced against HRIS termination data
  • Dormant account reports (accounts with no login activity for 30/60/90 days) with disposition records
  • Evidence that discovered orphaned accounts were remediated - not just identified
  • [13], with proof that identities were disabled promptly for leavers

7. Non-Human / Service Account Evidence

ISO 27001 controls: A.5.16, A.8.2 | SOC 2 criteria: CC6.1, CC6.3

Service accounts, API keys, CI/CD tokens, and automation credentials are the blind spot in most identity programs - and auditors know it.

What the auditor asks: "How do you know that this specific API key is only being used for backups? Who owns it? When was it last reviewed?"

What strong evidence looks like:

  • [14] (e.g., AWS IAM, Azure RBAC)
  • An inventory of all non-human identities with named human owners
  • Evidence that service accounts follow least-privilege - [14]
  • Review records showing service accounts are periodically recertified, not just created and forgotten
  • [5] - they need a deprecation timeline, not just an exception note

8. Access Request and Approval Trail

ISO 27001 controls: A.5.15, A.5.18 | SOC 2 criteria: CC6.2, CC6.3

[15].

What the auditor asks: "Show me a sample access request from the last 90 days. Who requested it, who approved it, when was it fulfilled?"

What strong evidence looks like:

  • [16]
  • Timestamps at each stage - request, approval, provisioning
  • Evidence that the requester and approver are different people (SoD)
  • Records covering your full app stack, including apps that don't have native ticketing integrations

The auditor red flag: [8] - nobody can audit what was approved or by whom.

Why Spreadsheets Fail the Evidence Test

Manual and spreadsheet-based approaches fail auditors on three specific dimensions:

No immutable timestamps. [17]. An auditor can't accept a spreadsheet as proof that a control ran on a specific date - it could have been backdated or edited. [18].

Gaps and staleness. [17]. [19]. A SOC 2 Type 2 audit covers 6-12 months of operation; a spreadsheet updated the week before the audit covers none of it.

Coverage gaps. Manual offboarding across 40+ SaaS apps on the day someone leaves is operationally impossible without automation. [5] - and how orphaned accounts accumulate. Apps without SCIM or native API integrations are simply invisible to spreadsheet-based governance.

warning Warning

The SOC 2 Type 2 trap: A policy document is necessary but not sufficient. Operational evidence is required. Type 2 means the auditor will sample actual authentication events, access reviews, and deprovisioning records from across the entire audit period — not just the week before the audit.

What Automated, Immutable Evidence Looks Like

The gold standard - [16] - provides irrefutable evidence of timely access revocation, directly satisfying CC6.2 and A.5.15.

More broadly, an automated IGA platform produces evidence that manual approaches structurally cannot:

  • Immutable provisioning logs with actor, timestamp, approver, and system - generated at the moment of action, not reconstructed afterward
  • Continuous access certifications that run on a defined cadence, capture reviewer sign-off, and record what changed as a result
  • Cross-stack coverage including apps without SCIM or APIs - so the evidence package covers your entire environment, not just the SSO-connected tier
  • Orphaned and dormant account reports generated automatically against live HRIS data, not manually compiled before each audit
  • SoD conflict detection that flags toxic role combinations in real time, not after the fact
  • Non-human identity inventory with ownership, last-reviewed date, and permission scope - ready to export on demand

This is exactly what Iden's agentic IGA platform is built to produce. With universal app coverage - including apps without SCIM or APIs - Iden closes the evidence gap that SSO-only and manual approaches leave wide open. Every provisioning action, access review, and deprovisioning event is logged with immutable timestamps and reviewer sign-off, ready to hand to an auditor on demand.

For a deeper look at how to structure your ISO 27001 program from the ground up, see our Step-by-Step Guide to Your First ISO 27001 2022. For SOC 2-specific identity architecture, see our Step-by-Step Guide to SOC 2-Ready Identity.

Interactive: Build Your Evidence Gap Assessment

Use this tool to identify which artifact categories you have covered, which are partial, and which are missing - and get a prioritized action list.

The Copy-Ready Audit Evidence Checklist

Print this, share it with your team, and use it as your pre-audit evidence pack checklist. Each item maps to the ISO 27001 and SOC 2 controls it satisfies.

Evidence Artifact ISO 27001 Control SOC 2 Criteria Minimum Standard
Access review reports with reviewer sign-off and timestamps A.5.15, A.5.18 CC6.3 Quarterly; named reviewer; changes documented
JML provisioning logs (joiner) A.5.15, A.5.16 CC6.2 Timestamped; approver named; role-based
JML deprovisioning logs (leaver) A.5.15, A.5.16 CC6.2 Same-day revocation; all systems covered
Mover records (role change) A.5.15, A.5.18 CC6.2 Old permissions removed; new permissions justified
SoD conflict matrix + enforcement evidence A.5.3, A.8.2 CC6.3 Technical enforcement + operating evidence
Privileged access inventory + approval records A.8.2 CC6.3 Named owners; 6-month review cadence
Privileged session / action logs A.8.2 CC6.3 Immutable; stored outside admin reach
Least-privilege / RBAC entitlement report A.5.15, A.5.18 CC6.1, CC6.3 Role-to-permission mapping; over-provisioning flagged
Orphaned account report + remediation records A.5.16 CC6.2 Cross-referenced against HRIS; dispositions logged
Dormant account report (30/60/90-day) A.5.16 CC6.2 Regular cadence; remediation documented
Non-human / service account inventory A.5.16, A.8.2 CC6.1, CC6.3 Named owners; least-privilege; periodic review
Access request + approval trail A.5.15, A.5.18 CC6.2, CC6.3 Requester ≠ approver; full stack coverage
lightbulb Tip

Dual-framework efficiency: Evidence prepared for ISO 27001 Annex A 5.15 can be directly reused for SOC 2 CC6. If you're pursuing both certifications, build your evidence package once and map it to both frameworks. Strategic integration of both frameworks through a unified approach can reduce audit burden by up to 40%.

The difference between a clean audit and a findings-heavy one almost always comes down to evidence quality, not control intent. Policies are table stakes. What auditors actually test is whether your controls ran consistently, produced immutable records, and covered your entire environment - including the 30 SaaS apps that aren't in your SSO.

That's the gap Iden closes: complete identity governance across your full stack, with an automated audit trail that's ready before the auditor asks.