# SOC 2 CC6 evidence checklist 30 evidence items across the 5 CC6 criteria that cover access governance. Version 2026-09-06. Points of focus quoted verbatim from AICPA, 2017 Trust Services Criteria (with Revised Points of Focus, 2022), TSP section 100. Maintained at https://www.idenhq.com/en/playbooks/soc-2-cc6-evidence-checklist Free to copy, adapt and share. No attribution required. --- ## How to use this Work down the list once at the start of your observation window and once about 6 weeks before fieldwork. The first pass tells you what to start capturing. The second tells you what you are going to be asked to explain. Auditors ask for the **full population** of an event first, then sample from it. For a large population that sample is commonly 25 to 40 items. For a quarterly control across a 12-month window there are only 4 occurrences, and the auditor may test all 4 rather than sample. So a population you cannot produce is a worse problem than a sample that has a gap. Every artefact you hand over needs to carry: - Source system the export came from - Extraction date - Reporting period the file covers - Who pulled it - A stable file name that does not change between requests An export nobody can reproduce is not evidence. This is the cheapest thing on the list to get right and one of the most common reasons a request comes back. --- ## CC6.1: Logical access security > The 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.1 Identifies and Manages the Inventory of Information Assets - [ ] **Evidence:** 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. - **Owner:** - **Source system:** ### CC6.1.2 Restricts Logical Access - [ ] **Evidence:** 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. - **Owner:** - **Source system:** ### CC6.1.3 Identifies and Authenticates Users - [ ] **Evidence:** 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. - **Owner:** - **Source system:** ### CC6.1.4 Considers Network Segmentation - [ ] **Evidence:** Network diagram showing segment boundaries and what crosses them. - **Auditor test:** Confirms the diagram matches firewall and VPC rules for a sample of boundaries. - **Owner:** - **Source system:** ### CC6.1.5 Manages Points of Access - [ ] **Evidence:** 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. - **Owner:** - **Source system:** ### CC6.1.6 Restricts Access to Information Assets - [ ] **Evidence:** 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. - **Owner:** - **Source system:** ### CC6.1.7 Manages Identification and Authentication - [ ] **Evidence:** Written identification and authentication standard, covering individuals and systems. - **Auditor test:** Checks the standard names systems, not only people. - **Owner:** - **Source system:** ### CC6.1.8 Manages Credentials for Infrastructure and Software (usually missing) - [ ] **Evidence:** 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. - **Owner:** - **Source system:** ### CC6.1.9 Uses Encryption to Protect Data - [ ] **Evidence:** Encryption-at-rest configuration per data store, dated. - **Auditor test:** Verifies a sample against the live setting. - **Owner:** - **Source system:** ### CC6.1.10 Protects Encryption Keys - [ ] **Evidence:** Key management procedure covering generation, storage, use and destruction, plus KMS access policy. - **Auditor test:** Asks who can export or delete a key. - **Owner:** - **Source system:** --- ## CC6.2: Registration and authorisation of new users > Prior 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.1 Controls Access Credentials to Protected Assets - [ ] **Evidence:** 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. - **Owner:** - **Source system:** ### CC6.2.2 Controls Access Credentials to Protected Assets - [ ] **Evidence:** 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. - **Owner:** - **Source system:** ### CC6.2.3 Controls Access Credentials to Protected Assets (usually missing) - [ ] **Evidence:** 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. - **Owner:** - **Source system:** ### CC6.2.4 Removes Access to Protected Assets When Appropriate - [ ] **Evidence:** 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. - **Owner:** - **Source system:** ### CC6.2.5 Reviews Appropriateness of Access Credentials - [ ] **Evidence:** 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. - **Owner:** - **Source system:** --- ## CC6.3: Modification and removal of access > 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 the concepts of least privilege and segregation of duties, to meet the entity's objectives. ### CC6.3.1 Creates or Modifies Access to Protected Information Assets (usually missing) - [ ] **Evidence:** 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. - **Owner:** - **Source system:** ### CC6.3.2 Removes Access to Protected Information Assets - [ ] **Evidence:** 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. - **Owner:** - **Source system:** ### CC6.3.3 Removes Access to Protected Information Assets - [ ] **Evidence:** 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. - **Owner:** - **Source system:** ### CC6.3.4 Removes Access to Protected Information Assets - [ ] **Evidence:** 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. - **Owner:** - **Source system:** ### CC6.3.5 Uses Role-Based Access Controls - [ ] **Evidence:** 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. - **Owner:** - **Source system:** ### CC6.3.6 Reviews Access Roles and Rules - [ ] **Evidence:** 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. - **Owner:** - **Source system:** --- ## CC6.6: Threats from outside the system boundary > The entity implements logical access security measures to protect against threats from sources outside its system boundaries. ### CC6.6.1 Restricts Access - [ ] **Evidence:** Rules restricting what can happen over each external communication channel. - **Auditor test:** Samples a channel and reads the rule set. - **Owner:** - **Source system:** ### CC6.6.2 Protects Identification and Authentication Credentials - [ ] **Evidence:** TLS configuration and cipher suite audit for external endpoints. - **Auditor test:** Runs or reviews a scan. - **Owner:** - **Source system:** ### CC6.6.3 Requires Additional Authentication or Credentials - [ ] **Evidence:** 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. - **Owner:** - **Source system:** ### CC6.6.4 Implements Boundary Protection Systems - [ ] **Evidence:** Firewall, WAF or IDS configuration, plus evidence it is monitored. - **Auditor test:** Asks who watches the alerts and what happened to the last one. - **Owner:** - **Source system:** --- ## CC6.7: Transmission, movement and removal of information > 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 to meet the entity's objectives. ### CC6.7.1 Restricts the Ability to Perform Transmission - [ ] **Evidence:** Who can export, bulk-download or delete records, per system. - **Auditor test:** Samples an export permission and asks who authorised it. - **Owner:** - **Source system:** ### CC6.7.2 Uses Encryption Technologies or Secure Communication Channels to Protect Data - [ ] **Evidence:** Encryption-in-transit configuration for data leaving the boundary. - **Auditor test:** Verifies against live configuration. - **Owner:** - **Source system:** ### CC6.7.3 Protects Removal Media - [ ] **Evidence:** Removable media policy and enforcement, or a documented prohibition. - **Auditor test:** Accepts a prohibition if it is actually enforced. - **Owner:** - **Source system:** ### CC6.7.4 Protects Mobile Devices - [ ] **Evidence:** MDM enrolment coverage and policy. - **Auditor test:** Compares enrolled device count against headcount. - **Owner:** - **Source system:** ### CC6.7.5 Restricts the Ability to Perform Transmission (usually missing) - [ ] **Evidence:** 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. - **Owner:** - **Source system:** --- ## Outside access governance These three CC6 criteria are in scope for your audit and not for this checklist, because they are not access-governance work: - **CC6.4** Physical access to facilities and protected assets - **CC6.5** Disposal of physical assets holding data - **CC6.8** Unauthorised and malicious software --- ## What this is not This maps criteria to the evidence auditors usually ask for. It is not an audit and it is not your auditor. Firms differ on what satisfies a criterion, how big a sample they want and what format they accept, and no checklist settles any of that. Use this to find gaps before somebody else does, then agree the specifics with the firm signing the report.