Your Type II observation window started in January. The audit kicks off in six weeks. 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 observation 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 twelve 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 outside the scope of access governance specifically.
CC6.1: Logical access security
The control: the entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events.
Evidence the auditor wants:
- Policy documents describing the access control framework: role definitions, approval requirements, password policy, MFA enforcement.
- Logical access security architecture diagram showing IdP, IGA layer, downstream systems.
- A list of all production systems that fall under access governance scope.
- Configuration evidence: MFA enforcement settings, password policy snapshots, session timeout settings.
- Identity records for sample populations: dated role assignments, source-of-truth attribution (HRIS link).
Common failure: the policy document exists but doesn't match what's actually configured in the target systems. The auditor checks both.
CC6.2: User registration and authorization
The control: prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users.
Evidence the auditor wants:
- For each new hire in the observation window: HRIS record showing start date and role, plus the access grant log showing what was provisioned, when, and by whom (or by what policy).
- For each contractor or external party with system access: registration record, access grant log, expected end date.
- Sample population: the auditor typically pulls 25 to 40 access grants and asks for the full provisioning trail for each.
- Authorization evidence: for above-baseline access, the request and approval records.
- Birthright policy documentation: the role-to-access mapping that fires for new hires.
Common failure: the access grant exists in the target system but no record links it back to the HRIS event that triggered it. The auditor sees a user with access and no provisioning audit trail.
CC6.3: Access modification and removal
The control: the 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 least privilege and segregation of duties.
Evidence the auditor wants:
- Joiner-mover-leaver (JML) workflow documentation.
- For role changes in the observation window: HRIS record + access changes (additions and removals).
- For each departure in the observation window: HRIS termination record + access revocation log showing every system access was removed, with timestamps.
- Orphaned account scans: evidence that the team periodically checks for accounts belonging to departed users and remediates them.
- Access certification campaign records: completion dates, reviewer decisions per entitlement, remediation timestamps for "remove" decisions.
- Segregation of duties: examples of SoD conflicts detected and remediated, or attestation that conflicts are reviewed.
Common failure: the offboarding evidence covers SSO and the major SaaS apps but misses the long tail of non-SCIM apps where IT handled offboarding manually. The auditor finds an ex-employee with active access on an app that wasn't in the offboarding checklist.
CC6.6: External boundaries
The control: the entity implements logical access security measures to protect against threats from sources outside its system boundaries.
Evidence the auditor wants:
- External user inventory: vendors, partners, contractors with system access.
- Boundary controls: VPN configuration, network segmentation, public-facing system identification.
- External authentication controls: SSO federation for external parties, MFA requirements.
- Vendor access logs and periodic reviews.
Lighter touch for most mid-market companies, but the access boundary between internal employees and external parties is one the auditor will examine specifically.
CC6.7: Information transmission and removal
The control: the 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.
Evidence the auditor wants:
- Data classification policy.
- Encryption-in-transit evidence: TLS configuration snapshots, cipher suite audit.
- Encryption-at-rest evidence for stored data.
- Removal authorization: who can export data, who can delete records, who can transfer ownership during offboarding.
Adjacent to CC6.3: the offboarding flow handles data ownership transfer alongside access revocation.
What the auditor actually looks at
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.
How to produce this evidence without the scramble
Three things have to be true.
One audit trail per access event. Every grant, modification, and revocation captured in a single structured log, with the policy or human authorization that triggered it. Not five separate logs that have to be correlated by hand.
Trail covers the full stack. Every system under SOC 2 scope produces audit events in the same format. Including the non-SCIM apps. Including the contractor identities. Including the non-human identities.
Evidence exports as artifacts the auditor will accept. CSV or JSON, with timestamps, identity attributions, policy references, mapped to control numbers. The audit response is "for CC6.3, here's the artifact," not "let me query our system and pull something together."
Most GRC platforms (Drata, Vanta, Secureframe) handle the policy-document side of SOC 2 well. The access-event side is where the work happens. The IGA layer is what produces the events; the GRC platform is what packages them for the auditor.
Where Iden fits
Iden produces SOC 2 CC6 evidence continuously as the lifecycle runs. Every provisioning, modification, and revocation lands in the audit log mapped to the relevant control. The evidence pushes into Drata, Vanta, or Secureframe automatically. When the auditor asks for the Sarah-joined-March-15 trail, the export is a click.
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.