SOC 2 CC6 is the Logical and Physical Access Controls criterion cluster and is where the majority of IAM-relevant requirements in a SOC 2 engagement sit. CC6.1 through CC6.8 cover logical access security, user registration and authorisation, access modification and removal, external threat protection, transmission controls, and malicious software prevention. Together they define what an auditor expects to see from an organisation’s access control infrastructure throughout the audit period.
CC6 is also where most organisations find their largest evidence gaps when they first pursue SOC 2 Type II. CC6.2’s user registration requirement needs structured provisioning records covering every user onboarded during the audit period. CC6.3’s access modification and removal requirement needs evidence that access changes and deprovisioning occurred through a governed process, not ad hoc. CC6.6’s boundary protection requirement needs MFA evidence covering external access throughout the period. None of these can be satisfied by pulling records together before the audit. The evidence must exist continuously.
This blog covers what each CC6 criterion requires technically, what a SOC 2 Type II auditor examines for each, and how IAM controls produce the continuous operating evidence each criterion demands. All criteria references are drawn from the AICPA Trust Services Criteria and Akku’s SOC 2 compliance mapping documentation, which addresses 14 of the 61 top-level Trust Services Criteria with 31 overlapping mapping points across 11 modules.
CC6.1 requires that logical access security software, infrastructure, and architectures are implemented to protect against threats from sources outside the system boundary. This is the foundational access control criterion covering the identity and authentication infrastructure itself.
CC6.1 requires that the organisation has implemented a logical access control infrastructure capable of restricting access to systems and data to authorised users. This covers the identity store, the authentication layer, the access control policy enforcement mechanism, and the monitoring infrastructure that detects unauthorised access attempts.
For IAM specifically, CC6.1 requires a centralised identity management system, consistent authentication enforcement including MFA, role-based access controls, and a logging infrastructure capturing authentication events and access decisions. The criterion does not prescribe specific technologies but auditors assess whether the implemented infrastructure provides meaningful protection against external threats.
Auditors examining CC6.1 typically review the identity infrastructure architecture, verifying that a centralised identity system exists and that applications authenticate through it. They review MFA configuration, verifying that MFA is enforced for access to in-scope systems. They review access control policy documentation and verify that it is technically enforced rather than policy-stated. They sample authentication event logs to verify that the logging infrastructure is producing continuous, structured records.
Akku’s unified cloud identity store, SSO infrastructure, and Adaptive MFA constitute the logical access security infrastructure CC6.1 requires. Cloud Directory addresses CC6.1 and CC6.2 across two mapping points. SSO and IDP addresses CC6.1 across one mapping point. Adaptive MFA addresses CC6.1 and CC6.6 across two mapping points. Access Manager addresses CC6.1 and CC6.6 across two mapping points.
CC6.2 requires that prior to issuing system credentials and granting system access, the entity registers and authorises new internal and external users. This is the user provisioning control, and it requires a structured process producing a documented record for every user onboarded during the audit period.
CC6.2 requires a formal user registration process with documented authorisation before access is granted. Every user must be registered through a defined workflow. Access must be authorised, meaning approved by an appropriate authority, before credentials are issued. The process must apply consistently to all users throughout the audit period, not only at audit time.
For SOC 2 Type II purposes, this means every provisioning event during the audit period must have a corresponding record showing that the user was registered through the formal process and that access was authorised before it was granted. Auditors sample provisioning events from across the audit period. Provisioning events with no authorisation record, or with informal records such as email threads, do not satisfy CC6.2.
Auditors select a sample of users onboarded during the audit period and request the provisioning records for each. They verify that each record contains a formal authorisation, an approved access request, and evidence that credentials were issued only after authorisation was complete. They also verify that the process was consistent across the sample, not applied only to some users or only for part of the period.
Akku’s structured access request and provisioning workflows produce the formal authorisation records CC6.2 requires for every provisioning event. Every user registration captures requester identity, approver identity, justification, timestamp, and downstream provisioning confirmation. SCIM-based provisioning synchronises approved access to connected applications with a timestamped sync record. User Lifecycle Manager addresses CC6.2 and CC6.3 across two mapping points. Identity and Access Governance addresses CC5.1, CC6.2, and CC6.3 across three mapping points.
CC6.3 requires that the entity authorises, modifies, or removes access to data, software, functions, and other protected information assets based on approved and documented access requests and the system of record for user entitlements. This covers role changes, access reviews, and deprovisioning.
CC6.3 requires that access changes and removals occur through the same structured, documented process as initial provisioning. A role change that results in access being silently carried forward without review does not satisfy CC6.3. A user departure where access is removed only from some systems and not others does not satisfy CC6.3. Every access modification and removal must be authorised, documented, and traceable to the system of record.
The periodic access review requirement is the mechanism for identifying and correcting access that is no longer appropriate. CC6.3 requires that the system of record for entitlements be accurate and current. Access reviews certify that current entitlements reflect current requirements and revoke those that do not.
Auditors examine a sample of role changes and departures from the audit period. For role changes, they verify that access from the previous role was reviewed and that entitlements no longer appropriate were removed. For departures, they verify that deprovisioning across all in-scope systems completed promptly and that a timestamped record of each account removal exists. They also examine access review records, verifying that reviews were conducted on a defined cadence throughout the audit period with documented outcomes.
Automated User Lifecycle Management handles role changes and departures with full audit trail coverage. Role changes trigger re-provisioning workflows with documented review and approval. Departures trigger automated deprovisioning across all connected applications with a timestamped record of every account removed. Access review and re-certification campaigns run on a defined cadence, producing timestamped certification or revocation decisions for every entitlement reviewed. Privileged Access Manager addresses CC6.3 alongside CC5.2, CC6.1, CC6.8, and CC7.2 across five mapping points.
CC6.6 requires that logical access security measures protect against threats from persons acting outside the entity’s system boundaries. This covers external access controls including MFA enforcement for remote and external users, network boundary controls, and contextual access restrictions.
CC6.6 requires that access from outside the organisation’s network boundary is subject to additional security controls proportionate to the risk. For IAM, this means MFA is enforced for all remote and external access to in-scope systems. Contextual access controls restrict access based on device compliance, geographic location, IP reputation, and time of day. Access from unmanaged devices or high-risk locations is subject to additional challenge or restriction.
The boundary protection requirement also covers external users including contractors, partners, and clients who access organisational systems. Their access must be governed through the same registration and authorisation process as internal users, with equivalent security controls applied.
Auditors examine MFA configuration and verify that MFA is consistently enforced for external and remote access throughout the audit period. They review authentication event logs to verify that no external sessions to in-scope systems occurred without a preceding successful MFA event. They also examine contextual access policy configuration, verifying that device compliance, location, and IP restrictions are technically enforced.
Adaptive MFA applied through the centralised authentication layer enforces MFA for all external and remote access. Step-up authentication triggers for access from new locations, unrecognised devices, or outside normal hours. Contextual access controls restrict access by device compliance status, IP range, geographic location, and time of day. Adaptive MFA addresses CC6.1 and CC6.6 across two mapping points. Access Manager addresses CC6.1 and CC6.6 across two mapping points.
CC6.7 requires that the transmission, movement, and removal of information is restricted to authorised internal and external users and processes. This covers data transfer controls at the endpoint and network layer.
CC6.7 requires controls preventing unauthorised data movement from organisational systems. At the endpoint layer, this covers USB storage restrictions, file sharing limitations, personal cloud drive blocking, and print restrictions. At the network layer, this covers FTP restrictions, upload controls, and DNS-based filtering of high-risk destinations.
GPO Manager enforces USB storage restrictions, file sharing limitations, personal cloud drive and personal email blocking, FTP restrictions, upload controls, and screenshot prevention at the endpoint layer. DNS-based filtering restricts access to high-risk web categories. MDM enforces equivalent controls on mobile endpoints through app whitelisting and data transfer restrictions. GPO Manager addresses CC6.1, CC6.7, CC6.8, and CC7.1 across four mapping points. Mobile Device Manager addresses the same four criteria across four mapping points.
CC6.8 requires that the entity implements controls to prevent or detect and act upon the introduction of unauthorised or malicious software. This covers endpoint application controls and software installation restrictions.
CC6.8 requires that endpoints are protected against unauthorised software installation and execution. Application whitelisting or blacklisting controls restrict which software can be installed and run. Software installation blocking prevents users from installing unapproved applications. Browser and download restrictions limit the introduction of malicious content through web browsing.
GPO Manager enforces executable and application launch controls, software installation blocking, and download restrictions at the endpoint layer. MDM enforces app whitelisting on mobile devices and restricts installation of unapproved applications. These controls address CC6.8 alongside CC6.1, CC6.7, and CC7.1. Privileged Access Manager additionally addresses CC6.8 through session-level controls preventing unauthorised software execution during privileged sessions.
SOC 2 Type II requires that CC6 controls operated effectively throughout the audit period. Every provisioning event, every access modification, every deprovisioning action, every authentication event, and every endpoint policy enforcement action must produce a structured, timestamped record throughout the period.
Akku’s continuous audit trail generates this evidence as a byproduct of daily operations. Provisioning records are created at the time of each onboarding event. Access review decisions are recorded at the time of each certification campaign cycle. Deprovisioning records are created at the time of each offboarding event. Authentication event logs are generated for every login attempt across all connected systems. Endpoint policy enforcement records are generated by GPO Manager and MDM for every policy application event.
When a SOC 2 Type II auditor samples CC6 controls from across the audit period, every sampled event has a corresponding structured record available for examination without retrospective compilation.
For any user onboarded during the last twelve months, can you produce the provisioning record showing formal authorisation before access was granted, without reconstructing it from email history?
When a user departed your organisation during the last twelve months, can you produce a timestamped record of every account removed across every in-scope system, and verify that removal completed within the same business day?
Has your access review process run on a defined cadence throughout the last audit period, producing documented certification or revocation decisions at every cycle, rather than running once before the audit?
Does your MFA enforcement cover all external and remote access to in-scope systems consistently throughout the audit period, with an authentication event log that auditors can sample from any point in that period?
Are your endpoint data movement controls, USB restrictions, file sharing limitations, and software installation blocking, technically enforced through GPO or MDM with configuration records, or policy-stated without technical enforcement evidence?
See how Akku maps to SOC 2 CC6 logical access controls requirements across user registration, access modification, boundary protection, and endpoint controls.
Book a conversation with the Akku team to assess your current IAM posture against SOC 2 Type II CC6 operating effectiveness requirements.
What is the primary difference between SOC 2 CC6.2 and CC6.3, and why do both require separate evidence?
CC6.2 covers user registration and authorisation before access is granted. It requires evidence of a formal process producing documented authorisation for every user onboarded. CC6.3 covers modification and removal of access as circumstances change. It requires evidence that role changes and departures resulted in timely, documented access adjustments and removals. CC6.2 is satisfied by provisioning records. CC6.3 is satisfied by access change records, deprovisioning audit trails, and access review outcomes. Both require continuous evidence throughout the audit period, not point-in-time documentation.
What does CC6.6’s boundary protection requirement mean for remote workers and contractors accessing systems from outside the corporate network?
CC6.6 requires that access from outside the organisation’s network boundary is subject to security controls proportionate to the external threat. For remote workers and contractors, this means MFA is enforced for every session to in-scope systems regardless of location, device compliance is verified before access is granted, and contextual access restrictions apply based on location and IP reputation. The boundary is not a physical network perimeter but a logical access boundary. Every access attempt from outside that boundary requires the additional controls CC6.6 specifies.
How frequently should access reviews run to satisfy CC6.3’s operating effectiveness requirement for SOC 2 Type II?
SOC 2 Type II does not specify a mandatory review frequency. The operating effectiveness standard requires that the review process ran consistently throughout the audit period and produced documented outcomes. Quarterly access reviews are the most common cadence among organisations seeking to demonstrate robust CC6.3 compliance. Annual reviews conducted once in the pre-audit window do not satisfy the operating effectiveness standard because auditors sample from across the period and a single review produces evidence for only one point in time.
What does CC6.7 require for data movement controls, and how is this different from a data loss prevention solution?
CC6.7 requires that the transmission, movement, and removal of information is restricted to authorised users and processes. This covers endpoint-level controls including USB restrictions, personal cloud drive blocking, and file sharing limitations. A dedicated data loss prevention solution performs content inspection and classification, intercepting transfers based on the content of the data. CC6.7 can be satisfied without content-level DLP by enforcing endpoint controls that restrict the channels through which data can be moved, regardless of content. GPO Manager and MDM address CC6.7 through channel-level restrictions at the endpoint layer.
Can a single IAM deployment produce CC6 evidence for both SOC 2 Type II and ISO 27001:2022 certification simultaneously?
Yes. The overlapping technical controls are substantial. SOC 2 CC6.1 and ISO 27001 A.8.5 both require logical access security infrastructure. SOC 2 CC6.2 and ISO 27001 A.5.16 both require formal user registration and provisioning processes. SOC 2 CC6.3 and ISO 27001 A.5.18 both require periodic access rights review and documented modification or removal. SOC 2 CC6.6 and ISO 27001 A.8.5 both require boundary protection and MFA for external access. A single Akku deployment implementing these controls produces compliance evidence for both frameworks from the same audit trail and governance infrastructure.
What is the consequence of having CC6.2 gaps where some users were provisioned outside the formal process during the audit period?
In a SOC 2 Type II engagement, CC6.2 gaps where provisioning occurred outside the formal process are typically raised as exceptions or nonconformities. Auditors sampling provisioning events from across the audit period who find events without formal authorisation records will note these as instances where the control did not operate as designed. If the exceptions are isolated, the auditor may note them without qualifying the opinion. If they are systemic or frequent, the auditor may qualify the opinion on CC6.2. The operating effectiveness standard requires consistent operation throughout the period, and gaps in the evidence record directly affect the audit outcome.
Introduction GDPR Article 25 requires that data protection be built into system architecture by design and that data minimisation be…
Introduction ISO 27001:2022 Annex A.8.15 requires that logs recording user activities, exceptions, faults, and security events be produced, kept, and…
Introduction Every compliance audit, regardless of framework, arrives at the same point: the auditor requests evidence that specific controls operated…
Introduction RBI 2023 Master Direction Clause 19 is the most technically detailed access control provision in the framework. It establishes…
Introduction SEBI CSCRF's Protect function contains the Access Authentication sub-category PR.AA, which runs from PR.AA.S1 through PR.AA.S17 and represents the…
Introduction DPDPA Clause 6 sets specific conditions for consent as a lawful basis for processing personal data. Consent must be…