What is SOC 2 Type I vs Type II? A Practitioner's Definition

Definition

SOC 2 Type I and Type II are two forms of SOC 2 attestation reporting for service organizations. The main difference is scope over time: Type I evaluates the design of controls at a single date, while Type II evaluates both design and operating effectiveness over a defined period.

How it works

SOC 2 is based on the AICPA Trust Services Criteria, usually covering Security and sometimes Availability, Confidentiality, Processing Integrity, and Privacy. In practice, an independent auditor reviews a company’s controls and issues a report describing what was assessed and the auditor’s opinion.

Type I is the faster, narrower option. It answers a question like: Were the controls in place and suitably designed as of June 30, 2026? The auditor looks at policies, procedures, technical safeguards, and evidence that the control environment exists at that moment. This makes Type I useful for organizations early in their compliance journey that have recently formalized controls.

Type II goes further. It answers a question like: Did those controls operate effectively from January 1, 2026 through June 30, 2026? The auditor tests evidence across the review window, such as access reviews, ticket approvals, logging, onboarding and offboarding records, vulnerability remediation, backup tests, and change management records. Because it assesses execution over time, Type II is typically more persuasive to customers and procurement teams.

For practitioners, the easiest way to explain the difference is this:

• Type I: “We designed the control.”
• Type II: “We designed the control and can prove we followed it consistently.”

That distinction matters because many security and compliance failures do not come from missing policies. They come from controls that exist on paper but are not performed reliably.

Technical Notes

Common examples of evidence reviewed in a SOC 2 assessment include:

- HR onboarding and termination tickets
- MFA enforcement screenshots or IdP policy exports
- Quarterly access review records
- Vulnerability scan reports and remediation tickets
- Production change approvals
- Backup job success logs and restore test results
- Security awareness training completion reports

A simple internal evidence checklist might look like:

Control: Quarterly privileged access review
Owner: IAM team lead
Frequency: Quarterly
Evidence:
  - Review export from identity provider
  - Ticket showing manager approval
  - Record of removed stale accounts
  - Date performed within control window

If you are preparing for Type II, consistency and timestamps matter. Auditors will usually want to see not just that a control exists, but that it happened on schedule and was documented.

When you’ll encounter it

Most people encounter SOC 2 Type I and Type II during vendor security reviews, enterprise sales cycles, procurement questionnaires, or due diligence. If you sell SaaS, managed services, cloud applications, or handle customer data, prospects will often ask which report you have.

A Type I report often appears when a company is relatively new to formal compliance. It can help unblock initial conversations with customers, especially when the organization has mature controls but has not yet completed a monitoring period long enough for Type II. Some buyers accept this temporarily, but many treat it as an intermediate milestone rather than the final destination.

A Type II report is what larger customers usually want. Security teams, GRC analysts, and procurement reviewers prefer Type II because it gives them more confidence that controls are operational, not just documented. In competitive sales environments, not having a Type II report can slow deals or trigger extra questionnaires and follow-up evidence requests.

You may also encounter the distinction internally when planning a compliance roadmap:

• Startups may pursue Type I first to show baseline control maturity.
• Growing SaaS vendors often move to Type II once they can sustain evidence collection over time.
• Mature organizations generally maintain Type II on a recurring basis.

For SMB owners and IT leads, the business takeaway is straightforward: if customers are security-conscious, expect Type II to matter more. If you only have Type I, be ready to explain your timeline for achieving Type II and how you are maintaining controls in the meantime.

Technical Notes

Teams commonly operationalize Type II readiness by centralizing evidence in ticketing, identity, and logging systems. Useful artifacts include:

# Example: export privileged group membership for access review
aws iam get-group --group-name Admins

# Example: verify MFA policy in Microsoft Entra / Azure AD via CLI tooling
az ad conditional-access policy list

# Example: list recent changes in infrastructure-as-code repos
git log --since="2026-04-01" --name-only

Useful log or audit patterns:

User lifecycle:
  "account created"
  "role assigned"
  "MFA enabled"
  "account disabled"

Change management:
  "pull request approved"
  "deployment succeeded"
  "rollback executed"

Monitoring:
  "alert acknowledged"
  "incident closed"
  "backup completed successfully"

These records help demonstrate operating effectiveness over the review period.

Related terms

Trust Services Criteria

The control framework underlying SOC 2. Security is mandatory; the other criteria are optional depending on scope.

Operating effectiveness

Whether a control actually functioned as intended over time. This is the core differentiator in a Type II report.

Point in time

A snapshot date used in Type I reporting. It tells you what existed on a specific date, not whether it worked consistently afterward.

Review period

The time window covered by Type II, often 3 to 12 months. The auditor samples evidence from this period to test control performance.

Bridge letter

A short communication organizations may provide to cover the gap between the end date of a SOC 2 report and the current date. Customers sometimes request this when a report is aging.

Vendor risk assessment

The process customers use to evaluate the security and compliance posture of a third party. SOC 2 reports are commonly requested here.

So what should you do with this distinction?

If you are reviewing a vendor, treat Type I as evidence of control design maturity, but not proof of reliable execution. Ask follow-up questions about how long controls have been operating, whether any exceptions occurred, and when a Type II report will be available.

If you are the service provider, use Type I as a milestone, not the end state. Build repeatable evidence collection, assign control owners, and make sure recurring tasks like access reviews, vulnerability remediation, and change approvals are documented in systems of record. That is what turns a clean Type I into a credible Type II.

In short, SOC 2 Type I shows that a company has designed the right controls. SOC 2 Type II shows that the company can run those controls consistently in the real world. For most practitioners, Type II is the report that answers the question buyers actually care about: Can we trust this organization to keep doing the right things over time?

For further reading, check out our articles on CVE-2026-53994 and 2026-04-04 Digest: iOS Spyware Developments.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.