What is the difference between SOC 2 Type 1 and Type 2?

Why This Matters for Security Teams

soc 2 type 1 and Type 2 are often treated as a packaging decision, but for identity and NHI security they signal very different levels of proof. Type 1 shows a control exists and looks reasonable on paper at one point in time. Type 2 shows the control kept working under real operational pressure. That distinction matters when the control is approval workflows, secret rotation, logging, or offboarding.

For teams managing service accounts, API keys, and automation, Type 2 is usually the harder standard because it forces evidence of persistence, not just design. The gap is visible in NHIMG research: the Ultimate Guide to NHIs — What are Non-Human Identities reports that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them. That is exactly the kind of gap Type 2 exposes.

In practice, many security teams discover control drift only after an audit request arrives, rather than through intentional monitoring.

How It Works in Practice

Type 1 testing is a point-in-time assessment. Auditors examine whether policies, procedures, and control designs are suitable for the stated objective. For identity teams, that might mean proving that approvals are required before access is granted, that logging is enabled, or that secrets are stored in a controlled system. It is a design check, not a durability check.

Type 2 goes further by sampling evidence over a defined review period, often several months. Auditors expect to see that the control operated consistently: access requests were approved before provisioning, periodic reviews happened on schedule, alerts were generated and handled, and exceptions were tracked. For NHI environments, that often means showing lifecycle evidence for service accounts, key rotation records, CI/CD controls, and revocation logs. This aligns closely with the evidence-driven discipline described in the Ultimate Guide to NHIs — What are Non-Human Identities, where secrets sprawl and weak offboarding are recurring operational risks.

Practitioners usually map SOC 2 evidence collection to core control families such as access management, change management, monitoring, and incident response. The NIST Cybersecurity Framework 2.0 is useful as a crosswalk because it frames identity and logging as ongoing functions, not one-time setup tasks. In mature programs, evidence is pulled from ticketing systems, PAM workflows, secrets managers, SIEM logs, and quarterly access reviews, then reconciled against the audit period.

• Type 1 answers, "Is the control designed correctly?"
• Type 2 answers, "Did the control work repeatedly during the period?"
• Identity evidence must show approvals, provisioning, rotation, and revocation happened as intended.
• Continuous logging and review matter more than written policy language alone.

That said, Type 2 does not prove every control is perfect. It proves the sampled controls operated consistently within the auditor’s scope. These controls tend to break down when access is granted outside formal workflows, because the evidence trail becomes incomplete or non-reproducible.

Common Variations and Edge Cases

Tighter evidence requirements often increase operational overhead, requiring organisations to balance audit readiness against engineering speed. That tradeoff is most visible when automated systems generate high volumes of short-lived access, because teams may confuse "ephemeral" with "low risk" and under-document the lifecycle.

There is no universal standard for exactly how much evidence is enough beyond the auditor’s scoping and testing approach, so current guidance suggests treating repeatability as the real objective. If a secret is rotated by automation, the team still needs proof of the trigger, approval, execution, and verification. If an access review is delegated to managers, the organisation still needs timestamps, attestations, and follow-up on exceptions.

For NHI-heavy environments, Type 1 may be acceptable early in a control rollout when the focus is proving the design. Type 2 becomes the more meaningful benchmark once the environment depends on service accounts, API keys, and machine-to-machine trust. It is also the better fit when the business wants assurance that controls survive staffing changes, pipeline changes, and production incidents. Teams that rely on spreadsheets or ad hoc screenshots usually find Type 2 evidence collection painful because the audit period exposes every manual exception. The practical lesson is simple: if a control cannot be evidenced twice, it is not yet operating as a control in the soc 2 type 2 sense.

Related resources from NHI Mgmt Group

• What is the difference between attack surface management and NHI governance?
• What is the difference between reviewing human access and reviewing NHIs?
• What is the difference between role-based access and API key governance for NHI security?
• What is the difference between human IAM controls and NHI governance?