SOC 2 · Identity Lens

SOC 2

SOC 2 is a controls report for your customers, and identity is the largest single control area in it.

Full name: SOC 2 — Service Organisation Controls (AICPA Trust Services Criteria)
Region: United States (used globally)
Applies to: Service organisations whose customers need assurance over the security, availability, processing integrity, confidentiality, or privacy of customer data. Common for SaaS vendors and cloud-service providers.

SOC 2 reports against the AICPA Trust Services Criteria (TSC) — five categories of which Security is always in scope. The criteria are principles-based rather than prescriptive: auditors expect the service organisation to design controls that meet the criteria and operate them over time. CC6 (Logical and Physical Access Controls) is the largest cluster of identity-relevant criteria.

What it asks for

The Identity Lens

The clauses that bite when identity architecture is weak, rewritten in plain English. Authoritative text is linked below.

CC6.1 — Logical access control

The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events. Identity providers, MFA, conditional access, and PAM all live here.

CC6.2 / CC6.3 — User registration and access modification

New users are registered and authorised before they get access, and that access is removed when no longer required. Joiner / mover / leaver as a continuous process, not a quarterly review.

CC6.6 / CC6.7 — Boundary protection and transmission

Access from outside the boundary is authenticated and the data in transit is protected. Federation patterns, browser-layer controls, and zero-trust access for contractors all map here.

CC6.8 — Detection and prevention of malicious software

Often overlooked from an identity angle: detection of credential theft, session hijack, and identity-based malware is in scope when those events affect the system.

CC7 — System operations and CC8 — Change management

Identity-related changes (new IdP integrations, role models, federation trusts) are formally managed and reviewed. Many SOC 2 findings come from undocumented identity changes, not missing controls.

Where teams miss it

Common Misses

Patterns we see again and again — usually because the identity programme runs in parallel to the compliance programme rather than inside it.

Auditors find shared admin credentials, undocumented service accounts, and unrotated tokens. Each becomes a finding even if every policy says otherwise.

Access reviews completed in spreadsheets, signed off by the wrong reviewers, evidence reconstructed at the end of the period.

MFA in place for SSO, bypassed for break-glass — the bypass path is the audit finding.

Customer-facing identity (CIAM) excluded from SOC 2 scope, while the service it protects is in scope. The mismatch produces a qualified report.

What works

Where Design Pays Off

Patterns we have seen survive supervisory review, audit, and the next change.

Continuous controls (drift detection, posture monitoring, federation health) producing the SOC 2 evidence as a side-effect of operating the platform, not as an audit task.

A single identity architecture document referenced from CC6 controls so the audit can follow one thread through the report.

Type II readiness baked into the platform: every change leaves an immutable record the auditor can sample directly.

Authoritative sources

Read the source

Every claim above is checkable. Start here.

AICPA

AICPA Trust Services Criteria (TSC)

AICPA

TSP Section 100 — 2017 Trust Services Criteria (with 2022 points of focus)

Related Services

Need a SOC 2-ready identity baseline?

We start with an assessment that maps your identity controls to SOC 2 requirements, then design and operate the gaps.

Book a Conversation