SOC 2 CC6 Logical Access Guide: Criteria, Evidence and Common Exceptions

The CC6 series of the SOC 2 Trust Services Criteria is where most SOC 2 exceptions are found, because nearly every CC6 test is an identity test against a population that is larger and messier than the control owner expects. This guide works through CC6.1 to CC6.8 one criterion at a time: what each asks for, the controls service organisations typically describe, the evidence an auditor samples in a Type 2 period, and the exceptions that recur. It is for control owners, IAM and security engineers and compliance leads preparing for, or recovering from, a SOC 2 examination. The wider SOC 2 picture (report types, scoping, subservice organisations) is in the SOC 2 Guide, and a section-by-section preparation list is in the SOC 2 Readiness Checklist.

A note on sources: the criteria come from the AICPA's 2017 Trust Services Criteria (With Revised Points of Focus, 2022), TSP section 100, which the AICPA distributes as a download behind a free account. The criterion summaries below are paraphrased and were cross-checked against secondary published copies of the criteria and an EY summary of the 2022 revisions, not against the AICPA download itself; the criterion wording is the AICPA's, summarised here by NHI Mgmt Group; confirm exact wording against the AICPA text before quoting it in a system description.

Key takeaways

• CC6 has eight criteria covering logical access (CC6.1 to CC6.3, CC6.6), physical access (CC6.4), disposal (CC6.5), data movement (CC6.7) and malicious software (CC6.8).
• Points of focus are not a checklist the auditor ticks off: they are considerations to help design controls, and the entity decides which apply to its system.
• The population decides the outcome: exceptions usually come from accounts nobody counted, such as database users, cloud IAM roles, SaaS admins and service accounts, not from the identity provider itself.
• The 2022 points of focus widened the lens to logical access across the whole system architecture, explicitly including service accounts, and added recovery of devices such as laptops.
• Evidence must be system-generated and dated: tickets, exports and logs that show the control operated throughout the period, not screenshots taken the week before fieldwork.

The eight criteria at a glance

The table paraphrases each criterion and lists a selection of the points of focus the AICPA attaches to it.

How auditors test CC6

In a Type 2 examination the auditor tests whether each described control operated effectively across the review period. For CC6 the work follows a familiar pattern:

1. Walkthrough: inquiry with the control owner and inspection of one instance, to confirm the control is designed as described.
2. Population request: a complete list for the period (all new hires, all leavers, all accounts with production access, all service accounts), which the auditor checks for completeness against an independent source such as the HR system.
3. Sample selection: the auditor picks items from the population; sample sizes depend on control frequency and the firm's methodology.
4. Inspection and reperformance: each sampled item is traced to evidence (approval ticket, disable timestamp, review sign-off), and configuration settings may be reperformed or observed.
5. Exception evaluation: any failure is reported in the description of tests and results, with management's response if it chooses to give one.

Two consequences follow. First, a control that is described too precisely ("all access removed within 4 hours") creates exceptions the moment one leaver takes 5 hours: describe what you can operate every time. Second, a population that excludes a class of account (service accounts, a database, a SaaS admin console) is itself a finding risk, because the auditor tests completeness. Reading how exceptions appear in a finished report is covered in How to Read a SOC 2 Report Guide.

CC6.1: logical access architecture

CC6.1 is the broadest criterion and the one most often mapped to many controls. Typical controls and the evidence that supports them:

The 2022 points of focus ask entities to consider logical access across infrastructure, IT tools and access types including employee, contractor, vendor and service accounts. In practice that means the MFA report and the access inventory must cover more than the identity provider. See the Secrets Management Guide and the Network Segmentation Guide.

CC6.2 and CC6.3: provisioning, changes and removal

These two criteria generate most CC6 exceptions because they are tested by sampling people and accounts across the whole period.

• Joiners (CC6.2, CC6.3): a sample of new hires is traced from the HR start list to an approved access request with the role and approver, dated before or on the day access was granted. Exceptions arise when access is granted from a chat message, or the approver is the requester.
• Movers (CC6.3): role changes should trigger removal of access no longer needed. Auditors look for the old entitlements; accumulated access after a transfer is a common exception.
• Leavers (CC6.2): a sample of terminations is compared with disable timestamps in the identity provider, cloud consoles, databases and critical SaaS. The policy window (for example 24 hours for production, our suggestion) must be met for every system in scope, not just the identity provider. See the Joiner-Mover-Leaver Guide.
• Access reviews (CC6.2, CC6.3): periodic reviews of privileged and production access, with reviewer sign-off, evidence that the review list was complete, and closed revocation tickets for anything removed. A review that approves everything, or whose removals were never actioned, is an exception. See the Access Reviews Guide.
• Segregation of duties (CC6.3): developers who can deploy their own changes to production without review conflict with the change process in CC8.1. Describe the compensating control if this cannot be avoided.

Where identity fits: non-human accounts in CC6

Service accounts, API keys, OAuth integrations, CI/CD pipeline identities and AI agents are "users" for CC6 purposes when they hold access to in-scope systems. The 2022 revision named service accounts among the access types to consider. Auditors increasingly request a separate population for them and test that each has a named owner, a documented purpose, least privilege permissions, no interactive login where not required, rotation in line with policy, and inclusion in access reviews.

The detailed evidence pack for machine identities is in Audit Readiness for AI Agents and NHIs, and an inventory format is in the Service Account Inventory Template.

CC6.4 and CC6.5: physical access and disposal

• Physical access (CC6.4): for most cloud-hosted service organisations, data centre controls are carved out to the cloud provider and covered by its own SOC 2 report; the entity still owns office access if offices hold in-scope assets, and badge provisioning, removal and periodic review are tested like logical access. The 2022 points of focus added recovery of physical devices, so leaver procedures should show laptops were returned.
• Disposal (CC6.5): evidence that devices and media were wiped or destroyed before leaving entity control, such as certificates of destruction or device management wipe records. See the Media Sanitisation Guide.

CC6.6 to CC6.8: boundary, data movement and malicious software

• External threats (CC6.6): MFA for remote and administrative access, boundary protection such as firewalls and web application firewalls, and protection of credentials in transit and at rest. Evidence is configuration exports and a sample of rule changes with approvals.
• Data movement (CC6.7): TLS for data in transit, restrictions on who can export or share data, encryption of endpoints and controls on removable media. Device management compliance reports showing disk encryption across the in-scope fleet are typical evidence. See the Encryption Guide.
• Malicious software (CC6.8): anti-malware or endpoint detection on servers and staff devices, restricted software installation, detection of unauthorised configuration changes and a defined change control process. Evidence is agent coverage reports reconciled to the asset inventory and alerts with follow-up. See the Application Allowlisting Guide.

Preparing CC6 for a first Type 2

1. Define populations first: list every system in scope and every account type on it, human and non-human. Agree with the auditor during readiness which populations they will request.
2. Write controls you can operate every time: realistic time windows, named control owners, and frequency stated (per event, quarterly).
3. Automate the evidence: connect HR, identity provider, cloud and ticketing exports so populations and disable timestamps are system-generated. See the Audit Evidence and Continuous Controls Monitoring Guide.
4. Run a mock test: before the period starts, sample 5 to 10 joiners, leavers and service accounts yourself and trace each to evidence (our suggestion). Fix the gaps the mock test finds.
5. Start the period only when the controls are running: a Type 2 period that starts before the leaver process is reliable will carry those exceptions into the report.
6. Track exceptions during the period: record any missed control promptly with root cause and remediation, so management's response is ready if the auditor finds it.

Decision guidance: small and large organisations

Detection and measurement

• Median and maximum time from HR termination to disable in each in-scope system.
• Share of in-scope accounts, human and non-human, covered by the last access review.
• Number of in-scope accounts without MFA, and number of approved exceptions.
• Service accounts and API keys without an owner or past their rotation date.
• Endpoint and anti-malware agent coverage against the asset inventory.
• Exceptions self-identified during the period against those found by the auditor.

Framework mapping

This NIST mapping is our own and indicative. For a full crosswalk see the SOC 2 to ISO 27001 Mapping Guide.

Common failure patterns

• Leavers removed from the identity provider only: local database users, cloud IAM users and SaaS admin accounts outside single sign-on stay active and are found in the leaver sample.
• Service accounts outside the population: the access review covers people only, so shared or orphaned service accounts surface when the auditor asks for all accounts with production access.
• Rubber-stamp reviews: a review with 100% approvals, signed in minutes, or with removals never actioned. Auditors test the follow-through, not the signature.
• Over-precise control descriptions: windows or frequencies the team cannot meet every time, which turn small delays into reported exceptions.
• Screenshot evidence: undated screenshots of settings instead of exports showing the setting held across the period.
• MFA gaps on secondary consoles: MFA enforced in the identity provider but not on a cloud root account, a data platform or a break-glass login.

Practitioner checklist

• List every in-scope system and every account type on it, including non-human identities.
• Map each CC6 criterion to named controls, owners and evidence sources.
• Rewrite control descriptions to time windows and frequencies you can meet every time.
• Reconcile HR leavers to disable timestamps in every in-scope system, monthly.
• Include service accounts, API keys and agents in access reviews, with owners.
• Report MFA coverage across all consoles, not only the identity provider.
• Reconcile endpoint, encryption and anti-malware coverage to the asset inventory.
• Run a mock sample test before the Type 2 period starts.
• Log self-identified exceptions with root cause and remediation during the period.

Standards and references

• AICPA and CIMA: 2017 Trust Services Criteria (With Revised Points of Focus, 2022)
• EY: AICPA revises guidance on applying its Trust Services Criteria and SOC 2 Description Criteria
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: SOC 2 Guide · SOC 2 Readiness Checklist · Audit Readiness for AI Agents and NHIs · Access Review Checklist