SOC 1 vs SOC 2: what IAM teams should verify first

At a glance

What this is: This comparison explains how SOC 1 and SOC 2 differ, with SOC 1 centred on financial reporting and SOC 2 centred on security and data handling controls.

Why it matters: It matters because IAM, IGA, and PAM teams often supply the evidence behind both reports, and weak access governance can undermine audit assurance across human and non-human identities.

👉 Read Zluri's comparison of SOC 1 vs SOC 2 for internal control assurance

Context

SOC 1 and SOC 2 are not identity controls themselves, but they depend on identity evidence. When access review, segregation of duties, or deprovisioning is weak, both reports become harder to support because the underlying control environment cannot show who had access, why they had it, or whether that access was still appropriate.

For identity and access teams, the practical distinction is scope. SOC 1 asks whether controls protect the accuracy of financial reporting. SOC 2 asks whether controls protect data and the services that process it. That means the same IAM programme may need to satisfy different assurance questions depending on whether the organisation is proving financial control integrity or broader operational trust.

Key questions

Q: How should security teams decide whether SOC 1 or SOC 2 matters more?

A: Choose SOC 1 when the service or system can affect financial reporting accuracy, and choose SOC 2 when the priority is proving security, privacy, availability, or processing integrity. Many organisations need both, but the deciding factor is the assurance question being asked by customers, partners, or auditors.

Q: Why do identity controls matter so much in SOC audits?

A: Because access is the mechanism that proves whether controls were actually enforced. If teams cannot show who had access, who reviewed it, and what changed after a review, the audit evidence is weak even when the policy exists. Identity governance turns control design into verifiable operating evidence.

Q: How do organisations make access reviews useful for SOC 2 evidence?

A: By linking each review to a concrete outcome such as removal of excess access, closure of orphaned accounts, or correction of privilege conflicts. A review that ends with no entitlement change rarely demonstrates real control operation, especially in Type 2 testing.

Q: Who is accountable when access governance fails in a SOC audit?

A: Accountability usually sits with the control owner, the system owner, and the identity governance function together. Auditors look for clear ownership, documented review actions, and evidence that exceptions were resolved before they became recurring control defects.

Technical breakdown

SOC 1 control scope and financial reporting evidence

SOC 1 is an assurance report tied to controls that can affect financial statements, transaction accuracy, and related reporting processes. The audit looks at whether controls are designed properly and whether they operate effectively over time, which means evidence quality matters as much as policy design. In practice, the identity layer shows up through access to financial systems, segregation of duties, privileged access, and evidence that access was reviewed and changed when roles shifted. A weak joiner-mover-leaver process often turns into an audit issue because it leaves no clean record of control enforcement.

Practical implication: align financial-system access reviews, SoD checks, and privileged approvals to the control objectives being tested.

SOC 2 trust services criteria and identity controls

SOC 2 evaluates security, availability, processing integrity, confidentiality, and privacy. The identity connection is strongest in the security criterion, but it extends into every other criterion because access governs who can view, change, or process data. Access controls, encryption key access, admin privileges, and application entitlements all become audit evidence. A SOC 2 Type 2 report goes beyond design and checks whether those controls actually worked across a period of time, so point-in-time access decisions are rarely enough. Continuous governance is what creates defensible evidence.

Practical implication: treat entitlement reviews, privileged access logs, and removal workflows as recurring evidence, not one-time compliance tasks.

Type 1 versus Type 2 assurance and control durability

Type 1 reports ask whether controls are suitably designed at a specific point in time. Type 2 reports ask whether those controls continued to work over an audit window. That difference is operationally important because identity controls are only persuasive when they show durability, not just intent. A well-written policy without access history, review outcomes, and remediation records will usually satisfy neither the spirit nor the evidence burden of a Type 2 review. The challenge for IAM teams is to show repeatable control operation across systems, not just a single clean snapshot.

Practical implication: build evidence pipelines that preserve review outcomes, approval history, and deprovisioning records across the full audit period.

NHI Mgmt Group analysis

SOC reports expose identity governance, not just compliance posture. Organisations often treat SOC 1 and SOC 2 as document exercises, but both reports ultimately test whether identity controls can be evidenced under scrutiny. Access reviews, privileged access, and lifecycle governance are the mechanisms that make the control story believable. If those are inconsistent, the assurance report becomes a summary of process intent rather than control reality. The practitioner implication is that audit readiness is an identity governance problem first and a paperwork problem second.

SOC 2 broadens the identity question beyond financial systems. SOC 1 stays anchored to reporting accuracy, but SOC 2 pulls identity into service reliability, privacy, and confidentiality. That means IAM teams cannot confine their thinking to finance applications and administrators alone. User access, service account access, and third-party access all become relevant evidence when data handling is under review. The practitioner implication is to map identity controls to the trust services criteria, not to a single control checklist.

Access review quality is the named control gap that most often decides audit credibility. SOC evidence collapses when reviews are slow, superficial, or disconnected from actual privilege changes. Review cadence matters less than whether the process catches excessive access, orphaned accounts, and SoD conflicts before auditors ask for proof. This is where identity lifecycle discipline matters across human and non-human access. The practitioner implication is to measure whether review outcomes change access, not just whether reviews were completed.

Operational effectiveness is the standard that separates policy from proof. Type 2 reporting makes it hard to hide behind design-only controls, because auditors expect evidence that controls operated as intended over time. That makes recurring access governance, deprovisioning, and exception handling central to the assurance story. The field should stop treating identity evidence as an adjunct to compliance and start treating it as the control plane for trust. The practitioner implication is to evidence execution, not aspiration.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• For a broader control baseline, see NHI Lifecycle Management Guide for how identity governance disciplines apply across provisioning, rotation, and offboarding.

What this signals

Control evidence is becoming the real audit differentiator. As organisations mature, the question is no longer whether they have an access review process, but whether it consistently changes entitlements and resolves exceptions before audit time. That is why identity lifecycle discipline, including the NHI Lifecycle Management Guide, matters even in discussions that appear to be about financial reporting or compliance scope.

For practitioners, the signal is that audit readiness and identity governance are converging. The same evidence patterns that support SOC-style assurance also support broader Zero Trust and IAM programmes, especially when privileged access, deprovisioning, and third-party entitlements need to be defended with records rather than intent.

The stronger your entitlement hygiene and review traceability, the easier it becomes to satisfy both control design questions and operating-effectiveness questions. That reduces last-minute audit fire drills and gives security, compliance, and finance teams a shared evidence model.

For practitioners

• Map identity evidence to the report scope Separate financial-reporting access evidence from broader service and data-protection evidence so teams know which controls support SOC 1 and which support SOC 2.
• Tie access reviews to real control outcomes Show that recertification changes entitlements, removes stale access, and resolves SoD conflicts rather than simply producing signed review logs.
• Prove operating effectiveness over time Retain approval history, deprovisioning records, and exception handling evidence across the audit window so Type 2 testing can verify repeated control operation.
• Include non-human identities in the control population Extend SOC evidence to service accounts, API tokens, and privileged integrations so machine access is governed with the same rigor as human access.

Key takeaways

• SOC 1 and SOC 2 differ mainly by assurance scope, but both depend on identity controls that can be evidenced under audit.
• Type 2 reporting raises the bar from policy design to repeated operating effectiveness, which makes access review quality and lifecycle discipline critical.
• IAM teams should treat entitlement evidence, deprovisioning records, and privileged access review outcomes as core audit artefacts, not supporting paperwork.

Key terms

• Soc 1: A SOC 1 report is an assurance assessment of controls that may affect financial reporting. It focuses on whether those controls are designed and operating in a way that supports accurate financial information and reliable transaction handling for customers, partners, and auditors.
• Soc 2: A SOC 2 report evaluates controls against the trust services criteria for security, availability, processing integrity, confidentiality, and privacy. It matters when an organisation must demonstrate that its systems and access practices protect data and service reliability over time.
• Type 2 Report: A Type 2 report checks whether controls operated effectively over a period of time, not just whether they were designed well on a single date. That makes it a stronger test of real-world control discipline because evidence must show repeatable execution, not only policy intent.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.

This post draws on content published by Zluri: Security & Compliance SOC 1 vs SOC 2: What Is The Difference? Read the original.