SOC 2 access readiness: getting CC6 ready for a Type II
SOC 2 is an attestation against the AICPA Trust Services Criteria. The Security criteria, the Common Criteria, are mandatory, and within them the CC6 series covers logical and physical access. It is the part of the report a customer's security team reads most closely, because access is where their data is most exposed.
The distinction that shapes everything is Type I versus Type II. A Type I looks at whether your controls are designed properly at a single point in time. A Type II tests whether they operated effectively across a period, usually three to twelve months. For access, that means the auditor does not just confirm you have an offboarding process. They pull a sample of people who left during the period and check, for each one, that access was actually removed. That is why readiness means the control has to be true for every person in the sample, across the whole window, not just described in a document.
- SOC 2 is an attestation against the AICPA Trust Services Criteria; the mandatory Security criteria are the Common Criteria, and within them the CC6 series covers logical and physical access, the part a customer's security team reads most closely.
- A Type II tests whether controls operated effectively across a period, usually three to twelve months, so the auditor does not just confirm you have an offboarding process, they sample leavers and check access was actually removed for each.
- One leaver who kept access to a connected app is one exception, and a handful of exceptions is the difference between a clean opinion and a qualified one.
- CC6.1 covers identity, MFA, and credential protection; CC6.2 is the joiner-mover-leaver lifecycle where Type II sampling bites hardest; CC6.3 covers role-based access, least privilege, and periodic documented reviews.
- Access exceptions are rarely architectural: they live outside the systems IT watches most closely, in the SaaS and non-human identities the directory does not fully see.
- Readiness work belongs before the observation period opens, not during it, and it rests on a complete, current picture of who has access to what, the baseline the auditor assumes you already hold.
what cc6 tests, in plain terms
The logical-access criteria translate directly into identity and access work. The three that carry the most weight are CC6.1, CC6.2, and CC6.3.
CC6.1 reads: implement logical access security software, infrastructure, and architectures over protected information assets. In practice the auditor looks at how identity is managed, whether multi-factor authentication is enforced, how network boundaries and entry points are controlled, and how credentials are protected.
CC6.2 reads: register and authorise users before granting system access, and modify or remove credentials when access is no longer authorised. This is the joiner-mover-leaver lifecycle in audit language, and it is where Type II sampling bites hardest, because the auditor verifies that access was actually revoked on termination or role change.
CC6.3 reads: authorise, modify, or remove access to data, software, functions, and other protected assets based on roles, responsibilities, or system design. This is where role-based access, least privilege, periodic documented access reviews, and segregation of duties are tested. A single failed offboarding violates CC6.2's deprovisioning mandate and undercuts CC6.3's least-privilege assurance at the same time, so one stale account can become two findings.
The rest of CC6 covers boundary protection, restricting data movement, and protection against malicious software, all important, but the access exceptions that qualify reports almost always come from the first three. Underneath all of it sits an assumption the auditor relies on without stating: that you have a complete, current picture of who has access to what. If that picture is incomplete, every control above it is being sampled against the wrong baseline.
where the exceptions hide
SOC 2 access exceptions are rarely architectural. The control was designed fine. It slipped somewhere across the period. The usual sources, in roughly the order they turn up: a leaver kept access to a SaaS tool because offboarding only covered the core directory and the app had a direct login outside single sign-on; a mid-period contractor was granted access and never went through a review, so there is no record showing the access was appropriate; an admin role was added during an incident and never removed, and the auditor finds standing privilege nobody can justify; MFA had an exception that nobody rechecked, on a service account, a legacy login, or an admin that predated the policy; and an access review happened but was not evidenced, with no record of who reviewed what, when, or what changed. The pattern is the same one every framework exposes: the gap lives outside the systems IT watches most closely, in the SaaS and the non-human identities the directory does not fully see.
the readiness sequence
This work belongs before the observation period opens, not during it, and each piece closes a class of exception. What works is to build the complete access picture first, listing every system that holds customer data or supports the product and every identity that can reach each one, human and non-human, because you cannot evidence access you cannot see. Fix authentication coverage by confirming MFA is enforced everywhere it should be, including admin accounts, service accounts where supported, and any login that bypasses single sign-on, and document the exceptions you cannot close with a compensating control and a reason. Close standing privilege by finding admin and elevated access that is standing rather than needed and removing or time-boxing it, since standing admin nobody uses is the cleanest finding for an auditor to write up. Make joiner-mover-leaver evidenced, so access requests run through an approval with a record, role changes trigger a review, and offboarding closes every system, not just the directory, with a ticket or log that proves it. Run a real access review and keep the record, having resource owners confirm who should have access to what, recording their decisions, and acting on the removals. And set the cadence so it survives the window, with a light monthly check that keeps access from drifting back into exceptions, because a Type II tests the whole period and whatever is fixed now has to stay fixed.
the evidence an auditor will ask for
Each control maps to an artefact that proves it. The set worth having ready, current and complete: an identity inventory and access listing per in-scope system; MFA configuration showing enforcement and any documented exceptions; access request and approval records for a sample of grants; termination records showing access removal across systems for a sample of leavers; access review records showing who reviewed, when, and what changed; and a privileged access listing showing who holds admin and why. If you can produce these on request, the CC6 sampling holds. If you have to assemble them from memory the week before, that is where exceptions are born.
let's start with a conversation
Most first conversations start with not quite knowing what you have or where to begin. That's normal, and it's exactly where we're useful.
Tell us what prompted this. An upcoming audit, an incident, a client's security questionnaire, or just a sense that things have gotten messy.
We'll take it from there
+48 783 762 997
julian@unshadowit.com
