Access Review Evidence Checklist for SOC 2, ISO 27001, and NIST

A completed access review campaign is not, by itself, audit evidence. What an auditor actually needs is a traceable chain from the approved policy and complete population, through the entitlement snapshot and reviewer decisions, to remediation, exceptions, and protected retention metadata.

That is why this access review checklist is not framed as a generic how-to. It is an evidence guide for teams that need to show what happened, who decided, what changed, and how the record was preserved. For SOC 2 access reviews, ISO 27001 audit evidence, and NIST access governance, the question is not whether the campaign finished. The question is whether you can prove scope, prove judgment, prove change, and prove preservation.

The evidence chain an auditor expects

The strongest access-review package proves six things in order:

1. The rule existed.

2. The population was complete.

3. The starting state was preserved.

4. An authorized person made each decision.

5. The decision changed reality.

6. The record can be trusted and retrieved.

That sequence matters because a screenshot of a green dashboard does not prove control operation. It can support the record, but it cannot replace it.

For a CIO, Head of IT, IAM owner, or auditor, this is also an operational issue. A complete evidence model reduces spreadsheet work, clarifies ownership, helps service-desk and application teams close actions faster, and gives leadership a consistent view across cloud, SaaS, on-premises, privileged, service, machine, and AI identities.

Access review checklist: the control record comes first

Before you extract data, retain the approved access-control policy and the access-review procedure in the version that governed the campaign. The campaign record should identify the control objective, in-scope identities and systems, review trigger, review cadence, reviewer roles, available decisions, escalation rules, exception handling, retention rules, and record-access limits.

A useful campaign record also includes a unique campaign ID, control mapping, policy and procedure version, owner, start and end timestamps with time zone, source systems, workflow version, reviewer rules, escalation configuration, status, and closure date. If the workflow changed mid-campaign, keep both versions and show which records each version governed.

In practical terms, this is the difference between a controlled review and a loose exercise in follow-up emails. If you cannot show the rule in force at the time, you are reconstructing the campaign after the fact.

Population completeness is the first hard question

An auditor will usually ask some version of: how do you know the list contains all relevant accounts and access?

A single export from one identity source is not enough if applications, cloud roles, local accounts, service identities, inherited permissions, or disconnected systems sit outside that source. For SOC 2 access reviews and ISO 27001 audit evidence, completeness is usually where weak campaigns fail first.

Retain:

• A system and application inventory showing what should be reviewed

• The identity sources used, such as HR, contractor or vendor registers, directory data, identity provider, privileged-access system, cloud accounts, application directories, databases, and service-account registers

• Extraction date and time with time zone

• Source system, connector or query version, filters, status rules, and record counts

• A row-level population with stable identity or account ID, account type, owner or sponsor, employment or sponsorship status, manager or owner, application or resource, role or group, entitlement, privilege level, direct or inherited access, account status, last-use data when available, start and expiry date, and source system

• Reconciliation totals by source, application, identity type, and status

• A list of exclusions with the reason, owner, risk assessment, and planned follow-up

• Evidence that connector failures, stale imports, partial exports, pagination limits, API errors, and failed reconciliation jobs were investigated

• The complete population used for sampling, if sampling was used, plus the sample basis and sample selection

• Pre-review and post-review population counts, with count changes explained

A strong population file lets an auditor select an item and trace it from source system to reviewer to decision to target-system change. A weak one has display names only, no stable IDs, no as-of timestamp, no source, and no reconciliation to the application estate.

Entitlement snapshots preserve the starting state

The snapshot is the “what access existed” layer. It should be a read-only or otherwise protected copy taken before review decisions and remediation alter the live system. Include the schema or data dictionary so the reviewer and auditor know what each field means.

The most useful fields are:

• Campaign ID and snapshot ID

• Source system and environment

• Extraction timestamp and time zone

• Stable identity or account ID and display name

• Identity type, including employee, contractor, partner, vendor, privileged, shared, service, machine, workload, or AI agent

• Account status and lifecycle state

• Manager, application owner, resource owner, sponsor, and non-human owner

• Application, tenant, cloud account, database, resource, group, role, permission, and entitlement

• Direct, inherited, nested-group, role-derived, or policy-derived access

• Privileged or sensitive designation and SoD or toxic-combination flag where applicable

• Business role, department, location, employment type, or other authorization attributes used by policy

• Access grant date, expiry date, last-use information when available, and source of the grant

• Risk flags such as dormant, orphaned, duplicate, excessive, expired, unowned, privileged, or conflicting

• Snapshot record count, export method, query or filter, connector version, and extraction errors

Do not place passwords, tokens, private keys, or authenticator secrets in the evidence package. A snapshot proves that access existed without reproducing the secret that authenticates it.

Reviewer authority must be explicit

“Manager approved” is too vague. The auditor needs to know which manager, for which population, under which rule, at what time. In some cases, application-owner review is the correct model because the manager may know the person’s job but not whether a technical entitlement is necessary.

Retain:

• Reviewer name and stable user ID

• Job role and relationship to the identity, application, resource, or business process

• The ownership or delegation rule that made the reviewer eligible

• Delegation record, including start and end dates, scope, and delegator

• Conflict-of-interest or self-approval check where supported

• Proof that the reviewer authenticated through an individual account

• Campaign assignment, reminder, escalation, completion, and acknowledgement records

• Approval of the reviewer model by the control or application owner when required by policy

For the reader building an access review checklist, this is the section that keeps the workflow from becoming a black box. If the reviewer cannot be tied to a role, a scope, and an authority basis, the decision record is weak.

Decision logs matter more than the final report

The final report is not enough. Every in-scope account or entitlement should have a disposition, including a documented reason when the answer is revoke, modify, reject, defer, or retain under exception.

Retain:

• Campaign and row or entitlement identifier

• Reviewer identity, role, and delegation state

• Original access from the snapshot

• Decision: approve or retain, revoke, modify, reject, delegate, exception, or pending

• Decision timestamp and time zone

• Reviewer comment or rationale, especially for privileged, sensitive, unusual, or retained access

• Risk or recommendation shown to the reviewer and the final human decision

• Decision status such as submitted, approved, executed, validated, overdue, failed, or closed

• Evidence of completion and any later correction or reopened decision

A blank row is not approval. A campaign completion percentage is not approval. If the workflow allows blanket approval, the evidence still needs to identify the population, reviewer, authority, date, and rationale. That distinction is central to credible SOC 2 access reviews.

Remediation proof must show the end state

A revoke or modify decision proves intent, not completion. For each action, retain the change record and the evidence that the target system reached the intended state.

Retain:

• Finding or action ID linked to the campaign row and entitlement snapshot

• Target system, account, resource, and old entitlement

• Requested, approved, executed, and verified timestamps with time zone

• Ticket, workflow, API, or change record identifier

• Actor or automation identity that performed the change

• New state, such as disabled, deleted, removed from group, downgraded, or expired

• Tool response, execution log, error, retry, and failure handling

• Post-change export or query showing the entitlement no longer exists or now matches the decision

• Validation method, validator, validation date, and unresolved discrepancy

• Reopened action or compensating action if the first remediation failed

A closed ticket that says “done” is weak proof unless it links to the target account and an after-state. For disconnected or legacy systems, keep the controlled manual procedure, operator identity, approval, evidence of the change, and subsequent verification. The most defensible proof is a later authoritative read-back.

Exceptions need expiry, ownership, and review

An exception is not a substitute for approval. It is a controlled risk acceptance with a finite life.

Retain:

• Identity, account, application, entitlement, and risk affected

• Business justification and why least privilege cannot currently be achieved

• Named business and technical owner

• Risk assessment and accepted risk

• Compensating controls such as additional monitoring, time-bound elevation, restricted source network, or enhanced review

• Approver and approval date

• Start date, expiration date, and next review date

• Conditions for early termination

• Current status and evidence that the exception was re-reviewed or closed

Never use “temporary” without an expiry or owner. An expired exception should trigger remediation or escalation, not silently become permanent access. In practice, this is one of the most important controls in the overall access review checklist because it keeps risk acceptance visible instead of buried in a spreadsheet.

Overdue, failed, and quality records show the control is real

A clean final report can hide operational failure. Retain reminders, escalation notices, overdue responses, rejected or returned decisions, failed connector jobs, incomplete imports, reconciliation exceptions, and campaign reopenings.

Also retain quality checks such as:

• Reconciliation between source and campaign counts

• Duplicate, orphan, dormant, terminated, and unowned-account checks

• Privileged-account and sensitive-entitlement completeness checks

• SoD conflict analysis where the organization uses it

• Sample or second-person quality review of decisions and remediation

• Campaign closure approval and unresolved-risk summary

This is where automation helps most. It can collect the evidence and surface failure, but it cannot make missing items disappear without creating a completeness problem. The right evidence package shows visible failure, ownership, escalation, and resolution.

Retention and integrity metadata belong in the package

There is no universal SOC 2, ISO 27001, or NIST retention duration for access-review records. The organization should define the period in policy, based on legal, regulatory, contractual, and audit needs, then show the rule it used.

For each artifact or package, retain:

• Record type and control mapping

• Campaign, snapshot, action, exception, and ticket identifiers

• Creation, export, review, remediation, validation, closure, and disposition timestamps with time zone

• Source system, environment, connector or query version, schema, and record count

• Policy, procedure, workflow, and role-model version

• Retention schedule or category, retention start event, scheduled disposition date, and legal hold status

• Repository, owner, authorized access group, and evidence of access logging

• Version history and integrity mechanism required by policy

• Backup or recovery status where the repository is critical

• Disposition approval and deletion record when the retention period ends

• Retrieval test or index that lets the team produce the complete package without rebuilding it from source systems

Protect the evidence itself. It often contains sensitive employee, contractor, privilege, and application data. Apply least privilege to the repository, log evidence access, and keep raw entitlement exports out of uncontrolled email.

Framework crosswalk for SOC 2, ISO 27001, and NIST

The same evidence package may support several controls, but it does not satisfy them automatically. The control’s purpose, scope, and operating context still matter.

Framework or control	What the auditor is testing	Evidence to retain
SOC 2 CC6.1	Logical access security measures are designed to protect systems and information from unauthorized access	Approved access-control policy; identity and role model; access-review procedure; system and application scope; control owner; workflow configuration; evidence that the control was in place for the relevant report date or period
SOC 2 CC6.2	Internal and external users are registered and authorized before credentials and system access are issued	Identity source and account-owner records; access request and approval; authorization basis; account creation or provisioning record; contractor or sponsor record; reviewer-to-identity relationship; termination and transfer feed evidence
SOC 2 CC6.3	Access to data, software, functions, and protected information assets is authorized, modified, and removed according to roles and responsibilities, with least privilege in mind	Complete entitlement snapshot; role or permission definition; individual decision log; revoke or modify action; before-and-after state; remediation ticket; validation; exception and risk-acceptance record
ISO/IEC 27001:2022 Annex A 5.15	Access rules are established and applied according to business and information-security requirements	Access-control policy; role and attribute rules; scope and ownership register; review procedure; evidence that reviewers used the approved rules
Annex A 5.16	Identities are managed through their lifecycle	Joiner-mover-leaver records; identity or account correlation; account type; owner or sponsor; lifecycle state; orphan, dormant, duplicate, and terminated-account reconciliation
Annex A 5.17	Authentication information is allocated and managed appropriately	Account and authenticator-management procedure; shared or group-account change record when a member leaves; proof that secret values were not exported into review evidence; relevant authentication configuration or audit record
Annex A 5.18	Access rights are provisioned, reviewed, modified, and removed in line with the access-control policy and business requirements	Campaign configuration; entitlement snapshot; reviewer authority; decision log; revocation or modification evidence; completion report; unresolved-item and exception register
Annex A 8.2	Privileged rights are restricted and managed	Privileged-account population; named owner; role and justification; elevated-access approval; separate admin and non-admin identity where applicable; review decision; privileged action log; removal or downgrade proof; exception expiry
Annex A 8.3	Access to information and assets is restricted according to policy	Application or resource inventory and entitlement inventory; sensitivity or risk classification where used; direct and inherited access; least-privilege rationale; high-risk decision and remediation evidence
Annex A 5.33 and Clause 7.5	Records are protected and controlled so they remain retrievable and trustworthy	Retention policy and version; record classification; storage and access controls; immutable or write-protected copy where required; integrity and version metadata; legal hold; retrieval and disposition record
NIST SP 800-53 AC-2	Account types, account managers, authorized users, group or role membership, privileges, approvals, lifecycle changes, monitoring, periodic review, and termination or transfer alignment are defined and operated	Account inventory; account-type policy; owner or manager mapping; authorized-user and role or privilege export; approvals; create, modify, disable, and remove logs; review campaign; termination or transfer reconciliation; account-management audit records
NIST SP 800-53 AC-2(1) to AC-2(4)	Automated account management, temporary or emergency-account expiry, disabling conditions, and automatic audit of account actions work as intended	Automation configuration; job or run log; temporary or emergency expiry evidence; inactive or expired-account report; account-action audit log; failed-run and exception handling
NIST SP 800-53 AC-6 and AC-6 enhancements	Access is no broader than necessary; privileged accounts are restricted; privileges are periodically reviewed; privileged functions are logged and non-privileged users cannot execute them	Least-privilege policy; role or privilege matrix; privileged population; review-frequency setting; decision and removal records; privileged-function log; control-test output; documented rationale for retained elevated access
NIST SP 800-53 AU-9 and AU-11	Audit information is protected and retained for an organization-defined period	Protected evidence repository; access and change log for evidence; retention schedule; start event and disposition date; retention exceptions or legal hold; backup or recovery evidence; retrieval test
NIST CSF 2.0 PR.AA, especially PR.AA-05	Identities, credentials, access permissions, entitlements, and authorizations are managed and reviewed using least privilege and separation of duties	Identity and entitlement inventory; policy; authorization and role model; access-review package; SoD analysis; reviewer decisions; remediation and exception proof; outcome dashboard or management report

This is the practical way to map one campaign package across frameworks without pretending that one artifact automatically satisfies every control.

What good evidence looks like in practice

Good evidence means the package contains an as-of entitlement snapshot from each in-scope source, reconciliation shows counts and exclusions, each row has a stable identity and entitlement ID, the named owner makes a dated decision, revoke decisions create linked change records, post-change read-back shows removal, exceptions have business reasons and expiry, and the package includes policy version, time zone, retention category, and controlled repository metadata.

Bad evidence looks very different. It is a spreadsheet with no extraction date, a screenshot of a green completion percentage, “manager approved” with no reviewer identity or authority, a revoked entitlement with only a closed ticket and no target-system verification, absent service accounts, silently excluded connector failures, expired exceptions with no expiry date, overwritten pre-review state, or records stored in an inbox with no retention or access control.

How Citadel Identity360 fits without replacing control ownership

For teams looking to reduce the manual burden, Citadel Identity360 is designed to help collect and connect the evidence chain across human, machine, and AI identities in cloud, SaaS, on-premises, and hybrid environments.

The product brief describes capabilities that can help teams:

• Run scheduled or event-driven access-review campaigns with workflow, escalation, and closure metadata

• Preserve reviewer authority and delegation evidence through configurable approval workflows

• Connect joiner, mover, leaver, provisioning, deprovisioning, and remediation records

• Support population completeness and entitlement snapshots through centralized identity, application, role, entitlement, and ownership views

• Prioritize dormant, orphaned, excessive, privileged, and SoD-conflicting access with risk analytics

• Govern service accounts, machine identities, workloads, APIs, and AI agents with owner, lifecycle, expiry, and review evidence

• Assemble decision, action, exception, and retention metadata through audit logging and reporting

• Reconcile sources through connectors to directories, HR systems, cloud platforms, SaaS applications, databases, and IT service-management tools

That said, the platform does not make the organization compliant by itself. Control owners still need complete integrations, correct ownership, sound policy, and validated remediation.

FAQ

What is the minimum evidence for an access review?

At minimum, retain the governing policy and campaign metadata, a complete dated entitlement population, reviewer authority, row-level decisions, remediation and validation for changes, exceptions, and protected retention metadata. A final certification screenshot alone is not enough.

How often should access reviews be performed for SOC 2, ISO 27001, or NIST?

There is no single universal interval in the source material reviewed. Define a risk-based cadence in policy, apply it consistently, and retain evidence of the cadence, missed reviews, escalations, and changes.

Is an access-removal ticket proof that remediation worked?

No. It is proof of an action request or workflow step, not necessarily the end state. Link the decision to the ticket and retain a target-system read-back or other validation showing that the entitlement was actually removed or changed.

Do service accounts, privileged accounts, and AI or machine identities belong in the review?

Yes, if they are in scope. NIST account-management material explicitly includes service and other non-person account types, and least-privilege principles apply to processes acting on behalf of users. If an identity type is excluded, document the scope, owner, rationale, and compensating control.

How long should access-review evidence be retained?

Use the applicable organizational retention schedule, legal, regulatory, and contractual obligations, and audit or certification needs. The standards reviewed do not supply one universal number of days; record the chosen period, start event, protection, legal hold, and disposition.

Can an IGA platform make the organization audit-ready by itself?

It can help automate collection, workflow, traceability, and reporting, but it cannot fix an incomplete population, wrong reviewer, weak policy, unowned account, unvalidated remediation, or expired exception. Control owners remain accountable.

Closing: prove the chain, not the dashboard

An auditor-ready access review is a preserved chain of evidence, not a green status indicator. Use the checklist to find the first missing link in your current campaign output: population completeness, reviewer authority, decision detail, remediation validation, exception expiry, or retention metadata.

If you want to reduce the manual work behind that chain, evaluate whether your identity governance process can collect the evidence continuously across hybrid sources, rather than reconstructing it after the audit begins.