We see the same pattern in nearly every SOC 2 readiness engagement. The identity tooling is in good shape. Single sign-on is rolled out. Multi-factor authentication is enforced. Conditional access policies exist. The team is proud of the configuration, and they should be.

Then we run the Stage 4 mock audit, and the exception register fills up anyway. Access reviews are missing for a quarter. Service accounts with no human owner. A leaver who kept their SaaS access for nineteen days because the deprovisioning workflow didn’t reach that integration. The tooling didn’t fail. The operating model around the tooling did.

CC6 (Logical and Physical Access Controls) is where SOC 2 audits spend the most fieldwork hours, and it’s where most readiness programs leave gaps. What follows is how we’d structure your IAM program to survive that fieldwork: six areas of CC6, what the criterion actually expects, what the auditor will sample for, and what we engineer to close each one.

Why CC6 Is the Audit Center of Gravity

A typical Type II audit allocates roughly forty percent of fieldwork hours to CC6 in our experience. There are reasons. CC6 is where customer data flows; CC6 is where breach incidents start; CC6 is where evidence is concrete enough to sample. An auditor can’t easily sample your culture of risk awareness. They can absolutely sample your access reviews, your deprovisioning timeline, and your privileged session logs.

The framework gives them eight sub-criteria to work with, from CC6.1 (logical access security software) through CC6.8 (malicious software controls). For an IAM-focused conversation, six of those eight are where the IAM team’s work directly shows up. The remaining two (physical access and malicious software) overlap with facilities and endpoint security and sit outside the IAM scope for most enterprises.

Our previous post in this series, 10 Gaps That Will Fail Your SOC 2 Audit, covered the operational failures across the whole framework. This one zooms into CC6 specifically and the IAM operating model that addresses it.

The Six IAM Areas Auditors Test

Area 1: Logical access foundation: SSO, MFA, and password discipline

Anchored to: CC6.1

What the criterion requires: An entity has to implement logical access security software, infrastructure, and architectures to protect information assets from access by users and systems outside its boundaries. Translated: a credentialed identity layer exists, is enforced, and isn’t bypassed by legacy authentication paths.

What auditors actually test: Auditors walk through how a user is authenticated to your platforms. They look for MFA enforcement, phishing-resistant factors for administrators, and (the part that catches most clients) any remaining legacy authentication paths that allow login without MFA. They will ask you to evidence MFA coverage across all production access, not just SaaS apps.

What we engineer: We standardize on Entra ID or Okta as the primary identity plane (most enterprises already have one), enforce MFA universally including service accounts where the workload supports it, push phishing-resistant factors (FIDO2, hardware keys) for admins, and explicitly disable basic authentication and any remaining legacy protocols. Our Entra ID vs Okta decision framework covers the platform-choice conversation in more depth.

Area 2: Provisioning that ties credential issuance to a documented authorization

Anchored to: CC6.2

What the criterion requires: Before issuing system, credentials and granting access to a new user, the entity has to register and authorize the user, with someone accountable for the decision. The criterion is about the audit trail behind every account creation, not just the technical act of creation.

What auditors actually test: Auditors sample new hires and contractors during the observation window and trace the trail backward: who approved the role assignment, what was the basis, and where is the evidence. They will also ask about non-employee identities (vendors, integrations, service accounts) where the audit trail is frequently weakest.

What we engineer: We engineer provisioning, so HRIS hire events drive birthright entitlements automatically. Manager approval is captured in the workflow for anything above birthright. Vendor and integration identities follow a parallel workflow with an explicit sponsor in the business. Service accounts get a named human owner before they’re created. Evidence accrues without anyone having to remember to collect it.

Area 3: Access modification and removal on a defensible cadence

Anchored to: CC6.3

What the criterion requires: The entity authorizes, modifies, or removes access on a timely basis when a user’s role changes, when they leave, or when access is no longer needed. The auditor reads the policy SLA and then checks whether reality matches.

What auditors actually test: Sampling under CC6.3 catches the leaver gap reliably. The auditor picks terminations and traces revocation across all systems the user had access to. Any system where revocation took longer than the policy SLA is an exception. They also sample movers (role changes) where the previous entitlements should have been revoked but weren’t.

What we engineer: We engineer joiner-mover-leaver workflows so HRIS termination triggers same-day deprovisioning across every connected system, with four-hour SLA on privileged users. Active session revocation fires on leaver. PAM credentials rotate when an admin departs. Mover events trigger a forty-eight-hour review of previous-role entitlements with explicit approval to retain anything. Our Identity and Access Management service page goes into the JML architecture in more depth.

Complete a 2-Minute Cybersecurity Assessment to Identify Security Gaps.

Area 4: Periodic access reviews that actually happen

Anchored to: CC6.3 (continued)

What the criterion requires: Access has to be reviewed on a defined cadence and removed when no longer needed. The criterion is silent on tooling but explicit on operating effectiveness. A review that’s documented in policy and not executed in practice will fail.

What auditors actually test: Auditors sample multiple quarters of the observation window and ask for the review artifacts. Missing quarters, email-thread evidence rather than system reports, and reviews that completed but didn’t drive revocations are all exceptions. Reviews of privileged accounts get extra scrutiny.

What we engineer: We move reviews out of email and into automated attestation campaigns inside Entra ID Governance or Okta Identity Governance. Reviews fire quarterly with auto-revoke on non-response. Privileged reviews fire monthly. Results land in the GRC platform as timestamped evidence, exportable on demand. The review is no longer a deadline anyone can miss.

Area 5: Privileged access controls that produce session evidence

Anchored to: CC6.6

What the criterion requires: Logical access security measures over information assets protect against threats from outside system boundaries. For privileged accounts (administrators, service accounts, vendor access), the criterion expects controls disproportionate to standard users: vaulting, just-in-time elevation, session recording, monitoring of activity.

What auditors actually test: Auditors will ask how privileged access is requested, approved, elevated, monitored, and recorded. They will sample privileged sessions and trace whether the activity was logged, retained, and reviewable. Production console access without session recording is a near-automatic finding.

What we engineer: We move privileged access through a PAM tool (CyberArk, BeyondTrust, or HashiCorp Vault, depending on what’s already in play). JIT elevation replaces standing privilege. Session recording is enabled by default for high-risk operations. Logs flow to the SIEM with retention aligned to your auditor’s expectations. The detection and incident response on top of those logs remains with your chosen SOC and IR partner; we engineer the evidence layer.

Area 6: Segregation of duties that’s enforced, not just documented

Anchored to: CC6.6 (continued)

What the criterion requires: The criterion expects that conflicting responsibilities don’t accumulate in a single user. A user who can both approve and execute the same financial transaction is a documented gap. The same applies to other toxic combinations (e.g., the engineer who deploys code and the same engineer who approves the change).

What auditors actually test: Auditors will ask for the SoD matrix and then test whether it’s actually enforced. They will sample users and look for toxic combinations. They may ask for a system-generated report; if you can’t produce one, the gap is evident even before sampling.

What we engineer: We define the SoD matrix in your IGA tool with named toxic combinations. Provisioning fires SoD checks before granting access. Quarterly attestations include an SoD review. Where existing combinations exist (most enterprises start with several), we document a compensating control and remediation timeline that the auditor accepts.

How This Plays Out in Practice

An 800-person SaaS organization came to us six months into their first SOC 2 Type II observation window. Their Okta tenant was, in their words, a showcase. SSO across 60 applications. MFA enforced. Conditional access policies tuned. The CTO presented it at every board meeting.

Stage 4 mock audit findings: access reviews hadn’t been completed for three of the four quarters in the window. Four service accounts had no human owner. The IGA module had been licensed but not configured to fire reviews automatically. Two leavers from the previous quarter still had access to Slack and Notion because the JML connector for those apps was on the backlog.

None of that was a tooling problem. The platform was capable of doing everything. The discipline of operating the platform on cadence had quietly slipped while the team focused on feature rollouts. Three weeks of remediation, and the next mock audit came back clean. The external audit was clean too. The lesson we took into every subsequent engagement: invest equally in tooling configuration and operating-model engineering, or the SOC 2 program will surprise you.

If You’re Building or Hardening Your SOC 2 IAM Program

The pattern that produces clean Type II reports is consistent. Engineer the six CC6 areas above into your IAM platform, with named owners and automated evidence flow. Run a Stage 4 mock audit 30 to 60 days before fieldwork to surface gaps when there’s still runway to fix them. Treat the IAM operating model as a continuous program, not a project that ends at the first report.

Our practice engineers exactly this work across Entra ID and Okta as primary platforms, with PAM and IGA supporting capabilities where the engagement requires. BluEnt is your readiness partner; AICPA independence rules mean we are never your auditor. We coordinate handover to your chosen CPA firm and stay engaged through fieldwork.

For the full SOC 2 readiness methodology, see our SOC 2 Compliance Services page. For the IAM operating model in depth, see our Identity and Access Management page.