SOC 2 and CIAM: What Auditors Actually Look at in the Identity Section

Key takeaways

• SOC 2 is principle-based, not prescriptive — the controls are what the company says they are, evaluated against the Trust Service Criteria.
• Common Criteria CC6 (Logical and Physical Access) is the CIAM-heavy section; CC7 (System Operations) covers monitoring; both consume most of an auditor's CIAM time.
• Type II tests operating effectiveness over a window (usually 6-12 months). Documenting policy isn't enough; the audit wants evidence the policy was enforced every day.
• Deprovisioning evidence is the surprise audit failure. Auditors sample terminated employees; gaps in the offboarding process show up immediately.
• Phishing-resistant MFA isn't required by SOC 2 but is increasingly expected by SOC 2 customers — your buyers' security teams ask, and 'we use SMS OTP' is a soft no.

What SOC 2 actually is

A SOC 2 audit produces a SOC 2 report (Type I or Type II). The report is the document B2B SaaS buyers ask for in security questionnaires. Type II is what enterprise procurement teams require; Type I is rarely sufficient.

The 2017 Trust Services Criteria (with 2022 revisions) define five categories:

• Security — mandatory. The control environment, risk assessment, communication, monitoring, control activities, and logical access controls.
• Availability — system operational and available for use as committed.
• Confidentiality — data designated confidential is protected.
• Privacy — personal information is collected, used, retained, disclosed, and disposed of according to commitments and privacy notice.
• Processing Integrity — system processing is complete, valid, accurate, timely, and authorized.

CIAM controls primarily land under Security. The Common Criteria within Security relevant to CIAM:

• CC5: Control Activities — the policies and procedures.
• CC6: Logical and Physical Access Controls — the access lifecycle.
• CC7: System Operations — including monitoring of access.

CC6: the access lifecycle

CC6 has eight criteria; almost all of them touch CIAM.

CC6.1: Restrict logical access

The organization implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events.

CIAM evidence: the CIAM exists, it covers all production systems, every production system requires authentication to access. The auditor will sample applications and verify each enforces CIAM-based authentication, not bypass methods.

CC6.2: Authentication and authorization

Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users.

CIAM evidence:

• Documented provisioning workflow — new user requires manager approval, ticket trail, manager attestation.
• The CIAM logs the provisioning event with the requester, approver, and assigned access.
• Audit sample: pick three new hires from the audit window, request the provisioning ticket and the CIAM log showing access granted only after approval.

CC6.3: User access modifications

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.

CIAM evidence:

• Role-based access with documented role definitions.
• Role changes go through approval; the CIAM logs the change with approver.
• Access reviews on a documented schedule (quarterly is the common cadence; some auditors accept semi-annual).

CC6.4: Physical access (not CIAM)

Office and data center physical controls. Skip for CIAM purposes.

CC6.5: Logical access removal

The entity discontinues logical and physical protections over physical assets only after the ability to read or recover data and software from those assets has been diminished and is no longer required.

In CIAM terms, this is deprovisioning — when an employee leaves, their access is removed. This is the recurring SOC 2 audit failure:

• The HR system records termination on Day 0.
• The CIAM access removal is supposed to happen within a documented SLA (commonly 24 hours).
• The audit samples terminated employees, requests the HR-to-CIAM deprovisioning evidence, and looks for gaps.

The pattern that fails: deprovisioning is manual, gets queued, sometimes slips. The pattern that passes: HR system triggers CIAM deprovisioning automatically (via SCIM or webhook), the CIAM logs the timestamp, the GRC platform pulls the evidence.

SCIM (System for Cross-domain Identity Management) is the standard way to automate this; SCIM Provisioning covers the protocol. CIAMs with strong SCIM Directory Sync make this audit trivial; CIAMs without it create the failure pattern.

CC6.6: External users and threats

The entity implements logical access security measures to protect against threats from sources outside its system boundaries.

CIAM evidence: MFA for external access. WAF / DDoS protection in front of authentication endpoints. Rate limiting on login attempts. Account lockout policies. Phishing-resistant authentication for high-risk access.

CC6.7: Transmission and movement 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.

CIAM evidence: TLS for all authentication traffic. Encrypted at rest where the CIAM stores data. Session token security (HttpOnly, Secure, SameSite cookies).

CC6.8: Prevention of malicious software

CIAM rarely the right control for this; usually covered elsewhere.

CC7: System operations monitoring

CC7.2 (the entity monitors system components and the operation of those components for anomalies) and CC7.3 (the entity evaluates security events to determine whether they could or have resulted in a failure to meet its objectives) are the CIAM-relevant monitoring criteria.

Evidence:

• Audit logs from the CIAM streamed to a SIEM.
• Documented alerting rules — anomalous login patterns, MFA fatigue, account-takeover signals.
• Incident response runbook that exercises the CIAM logs.
• Periodic threat-hunting using the CIAM audit data.

What auditors actually sample

The recurring list of evidence requests on a CIAM-focused SOC 2 audit:

1. MFA enrollment: sample 10 production-access user accounts, request screenshots or CIAM exports showing MFA enrolled and used in the audit window.
2. New-user provisioning: sample 5 new hires, request the approval ticket and the CIAM log showing access granted after approval.
3. Access reviews: request the most recent quarterly access review with sign-off from each system owner. Verify it covers all production systems and identifies/removes excess access.
4. Deprovisioning: sample 5-10 terminated employees, request the HR termination record and the CIAM access removal log, calculate elapsed time.
5. Privileged access: list of privileged users, evidence that elevation is logged, evidence of any time-bound or just-in-time elevation if applicable.
6. Audit log retention and tamper-evidence: evidence the CIAM logs are retained per policy and that they can't be modified after the fact.
7. Password policy: documented policy, evidence the CIAM enforces it (or evidence the CIAM uses passwordless and the policy is moot).
8. Incident response evidence: any access-related incidents in the audit window with the response artifacts.

The Vanta / Drata / GRC automation layer

Manually collecting the above evidence quarterly is weeks of work for a small team. The GRC automation platforms (Vanta, Drata, Sprinto, Secureframe, Scrut, Thoropass) integrate with the CIAM to pull evidence continuously:

• They scrape the CIAM API for MFA enrollment status, role assignments, access review completion.
• They monitor the deprovisioning latency from HR → CIAM via webhook integrations.
• They alert when controls drift (a user without MFA, an over-privileged role assignment, a stale account).
• They produce auditor-ready evidence packages on demand.

The CIAM still has to ship the underlying controls; the GRC platform automates the evidence-gathering. For early-stage SaaS, the combination of a modern CIAM (Auth0, Okta Workforce, Microsoft Entra, WorkOS for SCIM-driven B2B) plus a GRC platform is what makes Type II achievable without a dedicated compliance hire.

The standalone vendor comparisons live in /tools/top-10-compliance-automation-platforms-2026/ and the head-to-heads under /tools/alternatives-to-drata/.

Subservice organization model

Your CIAM vendor's own SOC 2 report doesn't eliminate your scope, but it reduces it materially. The mechanism:

1. Your auditor reviews the CIAM vendor's SOC 2 Type II report.
2. The report's "complementary user entity controls" (CUECs) section lists what you are responsible for on top of what the vendor handles.
3. You implement and document the CUECs.
4. Your auditor verifies the implementation.

CUECs for a typical CIAM vendor include: configuring MFA per the vendor's documentation, managing user provisioning approvals on your side, enabling audit log retention per the vendor's settings, restricting administrative access in the CIAM tenant.

Vendors with strong public CUEC documentation and audited subservice posture: Auth0, Okta, Microsoft Entra, Ping Identity, WorkOS, ForgeRock. Many smaller CIAM vendors don't publish CUECs cleanly, which complicates the auditor's review on your side.

SOC 2 + customer questionnaires

The practical reality of SOC 2 in 2026: the audit gets you the report; the customer questionnaires that come after the report ask deeper questions. Common asks:

• "Do you require phishing-resistant MFA for all production access?" SOC 2 doesn't require it; customers increasingly expect it. FIDO2/passkeys is the right answer.
• "Do you support SAML and SCIM for our SSO?" Has to be yes for enterprise.
• "What's your deprovisioning SLA?" Customer wants to see the SLA and evidence you meet it.
• "How do you handle service accounts and rotate their credentials?" Picks up the gap many CIAMs leave.
• "What's your incident response time for security events?" Tied to the CIAM's audit log surfacing.

The CIAM evaluation for SOC 2 + customer-questionnaire reality:

• MFA: yes, default FIDO2/passkeys.
• SSO: SAML + OIDC, per-Organization.
• SCIM: yes, with documented attribute mapping.
• Audit logs: comprehensive, SIEM-streamable, retention configurable.
• Service accounts: first-class, with rotation.
• Phishing-resistant MFA: yes.

The CIAMs that ship all of these well are also the ones that customers' security teams have already vetted: WorkOS, Auth0, Okta, Microsoft Entra, Frontegg, MojoAuth, Ping Identity. Smaller / specialized vendors fit specific niches; for the SOC-2-plus-enterprise-customer workload, the safe bet is the established names.

Implementation guidance

1. Pick a CIAM that ships SCIM Directory Sync. Deprovisioning evidence is the audit failure most often caused by missing SCIM.
2. Default MFA everywhere. FIDO2/passkeys preferred; TOTP acceptable; SMS OTP avoid.
3. Quarterly access reviews on a documented schedule. Use a GRC platform to automate the reviewer prompts and evidence capture.
4. Audit log → SIEM streaming. Real-time. Alerting on the security-relevant events.
5. Service accounts modeled as first-class principals. Rotation, scope, audit, no shared service accounts.
6. GRC automation from day one (Vanta, Drata, Sprinto, Scrut, Secureframe). Manual evidence collection does not scale.
7. Document the CUECs. Implement them. Reference them in your audit prep package.
8. Pre-audit with the CPA firm. A readiness review weeks before the formal window opens catches gaps cheaply.