SOC 2 CC6 Access Review Checklist — Operator's Guide (2026)

Step-by-step SOC 2 CC6 access review checklist for IT operators. Covers CC6.1, CC6.2, CC6.3, evidence formats, common gaps, and automation options.

Author: Gowtham Palanisamy · Updated May 30, 2026 · 15-min read

Key Takeaways

• SOC 2 CC6 requires you to demonstrate that access is granted, reviewed, and revoked based on documented business need. CC6.1 covers provisioning controls, CC6.2 covers authentication, CC6.3 covers removal.
• The AICPA doesn't mandate a review frequency. Most auditors accept quarterly for privileged accounts and semi-annual for standard users — but consistency and documentation matter more than the cadence itself.
• Evidence must show: who had access, who approved it, when it was reviewed, and what changed. Screenshots are accepted; system-generated, signed logs are stronger.
• The four most common CC6 findings: (1) no documented review cadence, (2) terminated employee accounts still active past the SLA, (3) privileged access with no business justification on file, (4) the access reviewer being the same person who provisioned the access.
• Steps 1–4 and 6–8 of this checklist can be automated. Step 5 — manager sign-off — is always human.

If your auditor cited CC6 in a management letter, it usually comes down to one of three things: you didn't run a formal access review with documented evidence, you ran one but couldn't produce evidence in an auditor-readable format, or the evidence you produced showed a gap — terminated employees with active accounts, privileged access with no justification, or a reviewer who also provisioned the access.

This is the operational answer to all three. It's built for IT operators at 100–500 employee companies running their first or second SOC 2 Type II audit — teams without a dedicated identity program or an internal compliance function.

You can copy this checklist into your own Jira project, Notion template, or Google Sheet. Each step maps to a discrete ticket or row. The evidence columns are the fields your auditor will ask for.

For the full CC6.1/6.2/6.3 control-by-control mapping — which specific requirements live under each sub-control and what evidence fields each one demands — see the SOC 2 access review solution page. This article focuses on execution: the step-by-step checklist and the evidence format.

What does SOC 2 CC6 actually require?

CC6 is the AICPA Trust Services Criteria cluster for Logical and Physical Access Controls. The three sub-controls that generate most operational findings are CC6.1, CC6.2, and CC6.3.

CC6.2 is mainly a policy and configuration review. It lives at the IdP level — Okta, Microsoft Entra, Google Workspace — and auditors check your MFA enforcement settings, session policies, and privileged account controls. You don't run a workflow checklist for CC6.2; you document the configuration and produce a policy.

CC6.1 and CC6.3 are where the operational checklist lives. Those are the eight steps below.

The 8-step SOC 2 CC6 access review checklist

Scope this review covers: all production systems and SaaS apps that hold sensitive data, customer records, or privileged administrative access. At minimum: your IdP, GitHub, Jira, Slack, Salesforce, HubSpot, Zendesk, and any system named in your System Description document.

Cadence to document in writing: quarterly for admin and privileged accounts; semi-annual for standard users. Document this in a formal access review policy before your audit period opens. Auditors test consistency across the full period — four quarterly packets for a 12-month Type II audit.

Step 1: Pull the current user inventory

Extract a complete user list from every in-scope system. For each user, capture:

• Email address / username
• Access level (admin, standard, read-only, custom role)
• Last login date
• Account creation date
• MFA status (enrolled or not)

If your apps support API or SCIM export, use it. The system-generated export carries a timestamp from the source, which is stronger evidence than a manually-built spreadsheet. If not, export to CSV where the app allows it, or screenshot the admin console with the system clock visible.

Evidence to save: timestamped user inventory export from each in-scope system.

☐ Checklist item 1: User inventory extracted from all in-scope systems, timestamped.

Step 2: Cross-reference against your active employee roster

Pull your current active employee list from your HRMS — BambooHR, Darwinbox, HiBob, Keka, Greythr, Workday, or whichever system is your HR source of truth. Cross-reference it against every in-scope app's user list.

Flag three categories of mismatch:

• Terminated employees with active accounts — present in the app, absent from the active HRMS roster. This is the CC6.3 finding auditors test directly.
• Active employees missing required access — present in the HRMS but not in an app they need. Lower urgency, but document it.
• Role mismatches — employee's title or department changed in the HRMS, but their app access level didn't update.

Industry research puts the median time between an employee's last day and full SaaS access removal at around 11 days. Most auditors hold you to 24 hours for critical systems (your IdP, source code, customer database) and 5 business days for standard access. That gap is where CC6.3 findings come from.

Evidence to save: reconciliation output showing HRMS roster vs. app user list side by side, with each exception flagged and categorized.

☐ Checklist item 2: Active employee roster cross-referenced against all in-scope app user lists; exceptions flagged and documented.

Step 3: Categorize and log each exception

From the reconciliation output, log every exception with its category, account details, assigned reviewer, and planned remediation:

Every exception entry needs: account name, exception category, system, reviewer assigned, and planned remediation date. This log is the core CC6 evidence document — your auditor will pull it directly.

Evidence to save: exception log with all five fields populated for every exception.

☐ Checklist item 3: Exception log produced with category, account, system, reviewer, and planned remediation for each item.

Step 4: Remediate within the defined window

Every orphaned account must be disabled or deleted before the review cycle closes. Every excess-privilege account must be downgraded or have a signed business justification on file. Every dormant account needs a documented decision.

The critical constraint: a review that identifies problems but doesn't remediate them within the review period is not a completed review. It's an open-findings list, and your auditor will treat it as evidence that the access review process is not functioning.

Log each remediation with: timestamp of action, who took it, and before/after account state. A ticketed workflow in Jira or ServiceNow with timestamps is strong evidence. A signed email works too.

Note on retroactive privilege justification: if you find an admin account with no documented approval, get the justification written down now — retroactively, with the approver's name. A late justification is better than no justification. Going forward, require a ticket for every privilege elevation.

Evidence to save: remediation log with timestamp, actor, and before/after state for each exception.

☐ Checklist item 4: All exceptions remediated within the defined SLA window; remediation log produced.

Step 5: Collect manager sign-off (the step that always stays human)

Auditors are specifically looking for evidence that a person with knowledge of the business reviewed access levels and attested they're correct. A system running a check is not a substitute.

For each in-scope system, the relevant manager or department head reviews the access list for their team and formally attests one of:

• "Access levels are correct as shown."
• "Access levels are correct with the following exceptions: [list]."

Formats auditors accept: an email from the manager to the IT team with explicit attestation text; a comment on a Jira or ServiceNow ticket with the manager's name visible; a signed PDF attestation; or a workflow-logged approval in an identity system.

What they don't accept: verbal agreement with no record, a Slack emoji reaction, or a spreadsheet entry with no timestamp.

Segregation of duties: the person who reviews and attests must be different from the person who provisioned the access. If you're a solo IT team, document the compensating control explicitly — for example: "access provisioning decisions are made by the IT administrator; access review sign-off is obtained from each department head." One sentence in your access review policy, implemented consistently.

Evidence to save: timestamped sign-off records from the reviewer for each in-scope system.

☐ Checklist item 5: Manager sign-off collected for each in-scope system; timestamped; from a person different from the provisioner.

Step 6: Assemble the evidence packet

Bundle the outputs from steps 1–5 into a single review packet for this cycle. Each packet should contain:

1. Review date and period covered (e.g., "Q1 2026: January 1 – March 31, 2026")
2. Scope statement — which systems were reviewed and why
3. Reviewer names and titles
4. Timestamped user inventory exports from each in-scope system
5. Reconciliation output with the exception log
6. Remediation log with before/after state and timestamps
7. Manager sign-offs organized by system

Use a consistent folder structure across cycles. Auditors will be reviewing four quarters of packets during a 12-month audit. Inconsistent organization becomes friction that generates questions.

Evidence to save: the assembled packet for this cycle, organized as above.

☐ Checklist item 6: Evidence packet assembled; all seven components present; organized by cycle period.

Step 7: Store evidence where auditors can access it without your help

Your auditor will request access to this evidence during fieldwork — typically four to eight weeks before the audit concludes. Make sure they can open and review it without:

• Logging into your production systems
• Asking you for individual files one at a time
• Decoding a naming convention you invented under pressure

A shared Google Drive folder, SharePoint site, or secure file transfer portal all work. Organize by: year → quarter → system. What doesn't work: files on a local machine, screenshots embedded in a Notion page that doesn't load for external users, or a proprietary export that only opens in your software.

☐ Checklist item 7: Evidence stored in auditor-accessible location; organized by review cycle; no production system login required to view.

Step 8: Set the trigger for the next review

A one-time review is worth almost nothing in a SOC 2 Type II audit. Type II tests consistency across the full audit period. Set the trigger now — before you forget.

Document it in writing:

• Calendar-triggered: a fixed quarterly or semi-annual review date, recurring in your calendar and referenced in your access review policy.
• Event-triggered: an HRMS termination event automatically initiates an access revocation review for that employee. This runs alongside the periodic review, not instead of it.
• Both: the calendar review handles full-scope periodic reviews; the event trigger handles individual offboardings on an ongoing basis.

Whatever the trigger, it needs to be documented in your access review policy — not just set as a private calendar reminder.

☐ Checklist item 8: Next review date set and documented; trigger mechanism recorded in the access review policy.

What evidence do auditors actually want to see?

The checklist above generates the evidence. The format matters as much as the substance.

Timestamping is non-negotiable. "We ran an access review in Q1" is not evidence. "On March 15, 2026 at 09:41 UTC, we extracted user lists from Google Workspace, GitHub, Jira, and Slack, cross-referenced against the BambooHR active roster dated March 15, 2026" — that is evidence.

Completeness across the full audit period. For a 12-month SOC 2 Type II audit with quarterly reviews, you need four complete packets. Missing one cycle is a gap. Auditors will ask for all four and test each one.

Segregation of duties is tested explicitly. The provisioner and the reviewer must be different people. If you're a small team, your compensating control needs to be documented and reviewable — not just something you explain verbally during the audit.

System-generated logs beat manually assembled screenshots — not because auditors distrust you, but because a tamper-evident, system-generated log leaves no ambiguity about what the system state was at the time of the review. It also takes less time to defend during fieldwork.

Format: auditor-readable means a non-expert can pick it up and understand it without asking you to explain it. PDFs, CSVs, and consistently named folders work. Proprietary exports from software only your team can open do not.

The four most common CC6 gaps

Gap 1: No documented review cadence. Teams run reviews when someone asks, but there's no written policy stating frequency, ownership, or scope. Without the policy, auditors can't verify consistency — and Type II tests consistency above everything. Fix: write a one-page access review policy before your audit period opens. Quarterly for privileged accounts, semi-annual for standard. Get it signed by your CISO or CEO.

Gap 2: Terminated employee access not removed within the SLA. This is the highest-severity CC6.3 finding. It's measurable, it's testable, and auditors test every termination in the audit period. The 11-day industry research median is not a safe place to be. Fix: automate the HRMS-to-revocation trigger, or build a documented manual procedure with a signed completion record for every termination, showing who took the action and when.

Gap 3: Privileged access without documented justification. A developer with GitHub admin rights and no ticket, approval, or role justification on file. Auditors look for every admin account in your inventory and ask for the approval that granted it. Fix: require a Jira or ServiceNow ticket for every privilege elevation going forward. Retroactively document the business justification for every admin account in your current inventory before the audit period opens.

Gap 4: Same person provisioned and reviewed the access. A segregation-of-duties violation. It gets caught because auditors cross-reference the provisioning record with the access review sign-off. Fix: document a compensating control in your access review policy — one line, implemented consistently.

What to automate vs. what stays human

Step 5 stays human by design. Auditors are looking for evidence that a person with business knowledge reviewed access levels and attested they're correct. An automated check against a static role table is not a substitute.

How KINT fits into this workflow

KINT automates steps 1–4 and 6–8. Every workflow it runs — onboarding, role change, offboarding — produces a signed, timestamped log mapped to SOC 2 CC6.1, CC6.2, and CC6.3.

The signature is Ed25519, which makes the log tamper-evident. The export is three clicks: date range, sub-controls, download. The evidence it generates for CC6.3 specifically: timestamp when the HRMS termination event was received, timestamp when revocation started across each connected app, completion timestamp for each app, and a signed final state. One offboarding → one complete evidence packet, automatically.

For the CC6.1/6.2/6.3 control mapping and the full evidence format, see the SOC 2 access review solution page. For the export model and tamper-evidence detail, see the audit trail and compliance documentation.

What KINT doesn't do: the manager sign-off. KINT routes the review and logs the attestation, but a real person attests. That step is always human.

One note on KINT's own compliance posture: SOC 2 Type I is complete. Type II is in the audit period — report expected this quarter. We're running the same checklist above on our own systems.

About KINT

KINT (by Kingsley Integrators) is an HR-driven identity lifecycle automation platform for companies with 100–500 employees. It automates onboarding, role changes, and offboarding across SaaS apps — including apps without APIs, via browser automation — and produces SOC 2 CC6 audit evidence as a byproduct. Pricing is published per employee per month ($3 Starter, $5 Growth). Self-serve signup at kingsleyint.com.

Want to see the automated half of this checklist in practice?

Book 15 minutes and I'll walk you through the evidence export from an actual offboarding workflow — what it looks like, what an auditor sees, and where the manual steps still live.

Book 15 minutes → calendly.com/kint-in/30min

14-day trial · No card required · SOC 2 Type I complete

FAQ

How often do you need to run a SOC 2 CC6 access review?

The AICPA Trust Services Criteria don't mandate a specific frequency. In practice, most Type II auditors accept quarterly reviews for privileged and admin accounts, and semi-annual reviews for standard user accounts. The frequency matters less than documented consistency — a written policy that defines the cadence, followed every cycle across the full audit period, with evidence that each review completed on schedule. A 12-month audit period with quarterly reviews means four complete review packets on file.

What does a CC6 access review evidence package need to include?

The core components: timestamped user inventory exports from each in-scope system, a reconciliation output showing HRMS roster vs. app user list, an exception log with category and remediation status, manager sign-offs (timestamped, from a different person than the provisioner), and remediation records with before/after state. Everything needs to be organized by review cycle and accessible without a login to your production systems.

What's the difference between CC6.1 and CC6.3?

CC6.1 covers how you control who gets access in the first place — authorization policies, least-privilege enforcement, role-based provisioning controls. CC6.3 covers how quickly and completely you remove access when it's no longer needed — specifically at termination and at role change. CC6.3 findings tend to be more severe because the gap between termination and revocation is directly measurable and auditors test it for every termination in the audit period. For the full sub-control evidence mapping, see the SOC 2 access review solution page.

Can screenshots serve as CC6 audit evidence?

Yes. Auditors accept screenshots provided they're timestamped (system clock visible), organized by review cycle, and complete — covering every in-scope system and every review period in the audit window. System-generated exports with automatic timestamps are stronger evidence than screenshots because they're harder to challenge as retroactively assembled or selectively curated. If screenshots are your only option, use a consistent naming convention and maintain a log showing which screenshot maps to which review cycle.

What happens if a terminated employee still has access during a CC6.3 audit test?

It depends on the system, the access level, and how long the account remained active. Active access to a critical system — your IdP, source code repository, or customer database — after termination is a significant finding that will likely appear in the auditor's opinion as an exception. Access to a low-risk system that was closed within 5 business days, with a documented remediation record on file, is unlikely to generate a formal finding. The severity depends on what access the account had, not just that it existed.

Does KINT handle the full CC6 access review process?

KINT automates the access lifecycle — provisioning, role changes, offboarding — and generates Ed25519-signed, timestamped evidence logs mapped to CC6.1 and CC6.3. This covers the automated portion of the checklist: user inventory, HRMS reconciliation, exception detection, revocation, and the evidence trail. The manager sign-off step stays human — KINT routes the review and logs the attestation, but a person attests. KINT's own SOC 2 Type I is complete; Type II is in the audit period.