A SOC 2 access audit is decided in the first month of the observation window, not in the 6 weeks before fieldwork. By the time you are assembling evidence it either exists or it does not, and assembly cannot create a record nobody wrote.
Your Type II observation window started in January. Fieldwork is close enough to be on a calendar. The CC6 controls (logical access security) are usually where teams either coast through or get found. The difference is what evidence you assembled while the window was running.
This is the practitioner's checklist. What CC6 requires by control number, what evidence the auditor wants for each, and how to produce that evidence without a wall-of-Excel scramble the week before the audit.
What CC6 is
The CC6 series sits inside the SOC 2 Trust Services Criteria under the Common Criteria. It covers logical and physical access controls. The Type II audit looks for evidence that controls operated effectively over the observation window (typically three to 12 months).
For access governance specifically, five sub-controls matter most.
- CC6.1. Logical access security implementation.
- CC6.2. Provisioning new users and credentials.
- CC6.3. Modifying and removing access.
- CC6.6. Protection from external threats.
- CC6.7. Information transmission and removal restrictions.
The remaining sub-controls (CC6.4, CC6.5, CC6.8) cover physical access, asset disposal, and malicious software. Important, but they're outside access governance specifically.
The checklist
30 evidence items across the 5 CC6 criteria that cover access governance. Every point of focus below is quoted verbatim from the AICPA's 2017 Trust Services Criteria with the 2022 revised points of focus, so the language matches what your auditor is working from.
Tick as you go. It remembers, in your browser only.
30 evidence items · 5 criteria
CC6.1 Logical access security
0/10The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives.
CC6.1.1Identifies and Manages the Inventory of Information Assets
System inventory with owner, data classification and in-scope flag per system. Dated, with the source it was pulled from.
Auditor test. Traces a sample of production systems back to the inventory, and looks for systems in your architecture diagram that never made the list.
Common exception. The inventory covers what SSO knows about and misses the apps bought on a card.
CC6.1.2Restricts Logical Access
Access-control configuration per in-scope system: role definitions, group-to-permission mapping, and the rule sets that enforce them.
Auditor test. Compares the documented policy against the live configuration in a sample of systems.
Common exception. The policy document describes a control the target system is not actually configured to enforce.
CC6.1.3Identifies and Authenticates Users
MFA enforcement settings, password policy, and session timeout, as dated screenshots or config export per system.
Auditor test. Checks enforcement is universal rather than optional, and looks for the exempted accounts.
Common exception. MFA is enforced for employees and not for service or break-glass accounts.
CC6.1.4Considers Network Segmentation
Network diagram showing segment boundaries and what crosses them.
Auditor test. Confirms the diagram matches firewall and VPC rules for a sample of boundaries.
CC6.1.5Manages Points of Access
Inventory of external access points, what data flows through each, and who or what uses them.
Auditor test. Asks who reviewed the list and when.
CC6.1.6Restricts Access to Information Assets
Evidence that access rules are built from data classification, not only from job title.
Auditor test. Picks a classified data store and asks who can reach it and why.
CC6.1.7Manages Identification and Authentication
Written identification and authentication standard, covering individuals and systems.
Auditor test. Checks the standard names systems, not only people.
CC6.1.8Manages Credentials for Infrastructure and Softwareusually missing
Register of non-human identities: service accounts, API keys, CI credentials, integration users, agents and MCP servers. Owner, purpose, scope and creation date for each. Plus evidence that credentials are removed when the software is no longer in use.
Auditor test. Samples non-human credentials and asks who owns each one and what removed the last one you retired.
Common exception. There is no register at all, so the population cannot be produced and the control cannot be tested.
CC6.1.9Uses Encryption to Protect Data
Encryption-at-rest configuration per data store, dated.
Auditor test. Verifies a sample against the live setting.
CC6.1.10Protects Encryption Keys
Key management procedure covering generation, storage, use and destruction, plus KMS access policy.
Auditor test. Asks who can export or delete a key.
CC6.2 Registration and authorisation of new users
0/5Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users whose access is administered by the entity. For those users whose access is administered by the entity, user system credentials are removed when user access is no longer authorized.
CC6.2.1Controls Access Credentials to Protected Assets
Full population of access grants in the observation window. Per grant: person, system, entitlement, date, and the authorisation, whether that is a named approver or the birthright policy that fired.
Auditor test. Pulls a sample, typically 25 to 40, and traces each grant back to its authorisation.
Common exception. The grant exists in the target system and nothing links it to the HRIS event or approval that triggered it.
CC6.2.2Controls Access Credentials to Protected Assets
Role-to-access mapping (the birthright policy) showing what each role receives by default, with a version history.
Auditor test. Checks that grants to sampled new hires match the policy for their role.
Common exception. The HRIS job title does not match any role in the policy, so the mapping was applied by hand.
CC6.2.3Controls Access Credentials to Protected Assetsusually missing
For external users, contractors and vendors: registration record, sponsor, scope, and expected end date.
Auditor test. Checks whether the end date passed and the access did not.
Common exception. Contractors are not in the HRIS, so no lifecycle event ever fires for them.
CC6.2.4Removes Access to Protected Assets When Appropriate
Above-baseline grants with the request, the approval, and the expiry set at approval time.
Auditor test. Looks for elevated access with no expiry.
Common exception. An exception was approved with a note and no end date, and is still live two years later.
CC6.2.5Reviews Appropriateness of Access Credentials
Completed access review campaigns for the window: scope, reviewer per system, per-entitlement decisions, and completion dates.
Auditor test. A quarterly control over 12 months gives 4 occurrences, and the auditor may test all 4 rather than sample.
Common exception. A cycle was late or skipped. This is one of the two most common findings.
CC6.3 Modification and removal of access
0/6The entity authorizes, modifies, or removes access to data, software, functions, and other protected information assets based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties, to meet the entity's objectives.
CC6.3.1Creates or Modifies Access to Protected Information Assetsusually missing
Full population of role changes in the window, each showing both halves: what was added and what was removed.
Auditor test. Samples movers and checks the removal half exists.
Common exception. Only the grant side is recorded. The access from the previous role was never removed and nobody noticed, because nothing broke.
CC6.3.2Removes Access to Protected Information Assets
Full population of terminations in the window. Per person: HRIS termination record, and a revocation log covering every system they held, with timestamps.
Auditor test. Samples leavers and traces each to a complete revocation across all in-scope systems, not just the identity provider.
Common exception. An unexplained active account belonging to a terminated employee. This is the single most common qualifying finding in an access audit.
CC6.3.3Removes Access to Protected Information Assets
Revocation coverage for apps outside SSO and SCIM, in the same log and format as everything else.
Auditor test. Deliberately picks a sampled leaver's long-tail app, because that is where the gap usually is.
Common exception. Offboarding covers the identity provider and the major SaaS, and misses the app finance set up years ago.
CC6.3.4Removes Access to Protected Information Assets
Orphaned account scans on a schedule, showing both the finding and the remediation, with dates for each.
Auditor test. Asks what happened to the accounts the last scan found.
Common exception. The scan ran and the remediation did not. A finding with no closure reads worse than never having looked.
CC6.3.5Uses Role-Based Access Controls
Role definitions and the segregation-of-duties conflicts they are designed to prevent.
Auditor test. Asks for examples of SoD conflicts detected and what was done about them.
CC6.3.6Reviews Access Roles and Rules
Per-entitlement review decisions, and for every remove decision a matching revocation with a timestamp.
Auditor test. Traces remove decisions through to the revocation actually happening.
Common exception. The review recorded removals that never fired. This produces evidence that reviews happened without proving they meant anything, which auditors and internal compliance teams both catch.
CC6.6 Threats from outside the system boundary
0/4The entity implements logical access security measures to protect against threats from sources outside its system boundaries.
CC6.6.1Restricts Access
Rules restricting what can happen over each external communication channel.
Auditor test. Samples a channel and reads the rule set.
CC6.6.2Protects Identification and Authentication Credentials
TLS configuration and cipher suite audit for external endpoints.
Auditor test. Runs or reviews a scan.
CC6.6.3Requires Additional Authentication or Credentials
MFA and device policy for access originating outside the boundary.
Auditor test. Checks it applies to contractors and vendors, not only employees.
Common exception. External parties authenticate with a shared login and no second factor.
CC6.6.4Implements Boundary Protection Systems
Firewall, WAF or IDS configuration, plus evidence it is monitored.
Auditor test. Asks who watches the alerts and what happened to the last one.
CC6.7 Transmission, movement and removal of information
0/5The entity restricts the transmission, movement, and removal of information to authorized internal and external users and processes, and protects it during transmission, movement, or removal to meet the entity's objectives.
CC6.7.1Restricts the Ability to Perform Transmission
Who can export, bulk-download or delete records, per system.
Auditor test. Samples an export permission and asks who authorised it.
CC6.7.2Uses Encryption Technologies or Secure Communication Channels to Protect Data
Encryption-in-transit configuration for data leaving the boundary.
Auditor test. Verifies against live configuration.
CC6.7.3Protects Removal Media
Removable media policy and enforcement, or a documented prohibition.
Auditor test. Accepts a prohibition if it is actually enforced.
CC6.7.4Protects Mobile Devices
MDM enrolment coverage and policy.
Auditor test. Compares enrolled device count against headcount.
CC6.7.5Restricts the Ability to Perform Transmissionusually missing
Data ownership transfer at offboarding: files, documents, dashboards and repositories reassigned rather than deleted with the account.
Auditor test. Samples a leaver and asks what happened to what they owned.
Common exception. The account was deleted and took its owned files with it. Not recoverable, and it shows up as a data-availability problem months later.
Take it with you
All 30 items, the verbatim points of focus, and the empty columns your team fills in. Free to copy, adapt and share, no attribution required.
Version 2026-09-06
How auditors work through this
Two things about the mechanics change how you should prepare.
They ask for the population before the sample. Access control fieldwork opens with a request for every provisioning event, every role modification and every termination in the observation window. Only then do they sample from it. For a large population that sample is commonly 25 to 40 items. A population you cannot produce at all is a much worse problem than a sample with one gap in it, and it is the more common failure.
Low-frequency controls get tested completely. A quarterly access review across a 12-month window has 4 occurrences. There is no meaningful sample to draw, so the auditor may simply test all 4. One late cycle is 25% of the evidence for that control.
Then there is the part nobody warns you about. Every artefact you hand over has to carry enough metadata that the auditor can reproduce the request:
- The source system the export came from
- The extraction date
- The reporting period the file covers
- Who pulled it
- A stable file name that doesn't change between requests
An export nobody can reproduce isn't evidence. This is the cheapest item on the entire list to get right and one of the most common reasons a request comes back a second time.
Worth knowing which way the odds run before you start.
An active account belonging to a terminated employee. This is a qualifying finding in close to every access audit that has one, and it almost always sits in the long tail rather than in the identity provider. The auditor samples a leaver and then deliberately picks an app that isn't in your SSO, because that's where the gap lives.
A late or skipped access review cycle. The second most common, and the most avoidable, because the deadline was on a calendar 3 months in advance.
Both are CC6.3 problems. If you only have time to get 2 things right before fieldwork, get those.
The Type II audit isn't a document review. The auditor pulls samples and traces individual events end to end.
For provisioning: "show me Sarah's onboarding. She joined March 15. What systems was she provisioned to? When? By whom? What policy authorized it?" The auditor wants a continuous trail from HRIS event to access grant in target system.
For offboarding: "show me everyone who left in April. For each one, what systems did they have access to? What was revoked? When?"
For access reviews: "show me the Q2 certification. Who was the reviewer for each application? What decisions did they make? Were 'remove' decisions actually executed? When?"
If your evidence requires assembling artifacts from five different systems (HRIS exports, SSO logs, app admin panels, ticketing system, manual spreadsheet) per sample, the auditor gets the picture. The control might still pass; the operational maturity rating won't.
Doing this without a tool
Plenty of companies pass SOC 2 with no IGA layer at all. It's worth being clear about what that costs, because the cost is real and it isn't the audit fee.
- Start the evidence log on day one of the observation window, not 6 weeks before fieldwork. Retroactive evidence is the single most common reason a control gets a qualified rating.
- One append-only sheet, one row per access event: person, system, action, who authorised it, timestamp. Contemporaneous beats elegant every time.
- Screenshot configuration state quarterly, dated. MFA enforcement, password policy, session timeouts.
- Run an orphaned-account scan each quarter and record the remediation, not just the finding. The finding alone reads worse than not looking.
- Keep the non-SCIM apps in the same log as everything else. The auditor's sample will include one, and a gap there is the finding that costs you.
- Reconcile the log against HRIS joiners and leavers monthly. Anything in one and not the other is a gap you can still fix.
A day a month during the window, plus 2 to 3 weeks before fieldwork.
Whether those last 3 weeks are assembly or archaeology is decided in month one, while nothing appears to be happening. Evidence captured as events occur is a filing job. Evidence reconstructed afterwards is an investigation, and auditors can tell which one they're reading.
What still needs a person
Scope. Which systems fall under SOC 2 for your company is a judgment call made with your auditor, and no tool can make it. Get it wrong in either direction and the rest of the work is either insufficient or wasted.
Two others. Somebody has to own the relationship with the audit firm, because most disagreements about evidence are resolved by conversation rather than by artefact. And somebody has to decide what an acceptable exception looks like, which is a risk decision that belongs to whoever carries the risk.
What this checklist is not
This maps controls to the evidence auditors usually ask for. It isn't an audit, and it isn't your auditor.
Firms differ on what satisfies a control, how big a sample they want, and what format they'll accept. A checklist can't settle any of that. Use this to find the gaps before somebody else does, then agree the specifics with the firm actually signing the report. The one thing that transfers across every firm we've seen is column three: being able to show what happened, per system, for a named person, on a named date.
Where Iden fits
Steps 1, 4 and 6 above, running on their own.
Every provisioning, modification and revocation writes an evidence row as it happens, mapped to the control it satisfies. The orphaned-account scan is continuous rather than quarterly, and it shows the remediation state alongside the finding, which is the half auditors actually test.
Findings als Eingang. Links Kategorien und Anzahl, rechts die Warteschlange, zwei Kategorien stehen schon auf null. Angelina wurde vor drei Tagen offgeboardet und hält noch sechs Applikationen.
Evidence pushes into Drata, Vanta or Secureframe as the lifecycle runs. When the auditor asks for the Sarah-joined-March-15 trail, the export is a click rather than a week.
Teams that have done one SOC 2 cycle on Iden tend to describe the second one as uneventful. That's the highest praise the audit experience can attract.