SOC 2 Type 1 is an attestation engagement in which an independent CPA firm reports on whether a service organization's controls relevant to one or more Trust Services Criteria were suitably designed to meet the applicable criteria as of a specified date.
In security and compliance programs, Type 1 is the point-in-time design report. Auditors examine management's system description, the control design narrative, and related design evidence as of that date. They do not opine on whether those controls operated effectively across a multi-month audit period. That operating-effectiveness opinion is the job of SOC 2 Type 2.
In simple terms, SOC 2 Type 1 answers:
- As of the report date, which Trust Services Criteria and system boundaries were in scope?
- Were the described controls suitably designed to meet those criteria?
- Does the system description fairly present the system as of that date?
This page defines Type 1. For the umbrella definition see What Is SOC 2?. For a side-by-side comparison see SOC 2 Type 1 vs Type 2. Related reading includes SOC 2 Trust Services Criteria Explained, What Is SOC 2 Evidence?, and how to prepare for a SOC 2 audit.
Why SOC 2 Type 1 Matters
Teams often use Type 1 as an early diligence milestone when customers want an independent report before a full Type 2 period can complete.
Type 1 matters because:
- It packages a CPA opinion on control design for buyers who will not wait a full period.
- It forces clarity on system description, criteria, and control owners before operating evidence hardens.
- Design gaps surface earlier, when remediation is cheaper than mid-period firefighting.
- It can support sales conversations while the organization builds continuous evidence collection habits for Type 2.
- It is still an auditor attestation, not a self-issued "SOC 2 certified" badge.
Type 1 is not a permanent substitute for Type 2 when enterprise buyers expect operating effectiveness over time. See SOC 2 Type 1 vs Type 2.
Type 1 vs Type 2 vs Readiness Assessment vs Certification
Keep labels precise.
| Concept | Primary job | Time focus | Common confusion |
|---|---|---|---|
| SOC 2 Type 1 | Opinion on suitable design of controls | As of a specified date | Treating it as proof controls ran all year |
| SOC 2 Type 2 | Opinion on design and operating effectiveness | Across an audit period | Assuming Type 1 already covers operation |
| Readiness / gap review | Internal or consultant prep before fieldwork | Pre-engagement | Calling a readiness memo a SOC 2 report |
| Self-attested "certified" badge | Marketing language | N/A | Implying an auditor issued Type 1 when none exists |
Prefer precise language: "We have a SOC 2 Type 1 report as of [date] covering Security (and other criteria)." See What Is SOC 2? and ISO 27001 for neighboring schemes that are not Type 1.
How a Type 1 Engagement Typically Works
Teams usually move through readiness, design documentation, and a point-in-time exam:
- Define scope. System description, services, locations, and Trust Services Criteria. Security is nearly always included.
- Document controls. Policies, procedures, and design narratives that map to criteria.
- Assemble design evidence. Configurations, screenshots or exports, role matrices, and policy versions that show the design as of the report date.
- Engage a CPA firm. Auditors walk the system description, interview owners, and evaluate whether design is suitable.
- Remediate design gaps. Fix missing owners, weak procedures, or unclear carve-outs before report issuance via exception management when needed.
- Issue the Type 1 report. Share under NDA or portal controls with customers who asked for it.
- Plan the Type 2 period. Start collecting operating evidence immediately so the next report covers a full window.
Concrete good vs poor examples:
- Good: Type 1 with a clear system description that matches sales claims, plus a documented plan to retain access review and change evidence for Type 2.
- Poor: Type 1 used in marketing as if it proves a year of control operation.
- Good: design evidence dated to the as-of date with named control owners.
- Poor: undated policy PDFs and tribal knowledge with no system description alignment.
Evidence Themes for Type 1 (Design Focus)
Illustrative design themes. Exact requests depend on your controls and criteria:
| Theme | Type 1 design evidence examples |
|---|---|
| Logical access | Current access policy, IdP MFA settings, role design notes (access control, logical access, multi-factor authentication) |
| Change management | Change procedure, approval gates, branch protection settings (change management) |
| Risk | Current risk methodology and register design (risk assessment, risk register) |
| People | Training and policy acknowledgement procedures (policy acknowledgement, security awareness training) |
| Monitoring and incidents | Alerting design and incident procedure (monitoring, incident management) |
| Vendors | Vendor risk procedure and critical vendor inventory approach |
Type 1 emphasizes that the design exists and is suitable as of the date. Type 2 will later sample whether those activities left dated operating proof across the period. See audit evidence and What Is SOC 2 Evidence?.
Framework Notes
Trust Services Criteria
Security is the foundational category. Availability, Confidentiality, Processing Integrity, and Privacy may be added based on commitments and risks. See SOC 2 Trust Services Criteria Explained.
Customer diligence use
Some buyers accept Type 1 early in a vendor relationship, especially for first-time SOC 2 programs. Many enterprise questionnaires still prefer a current Type 2. State criteria, as-of date, and carve-outs clearly when you share the report.
Relationship to continuous readiness
Type 1 should accelerate, not replace, continuous evidence habits. Continuous compliance and control drift management matter as soon as the Type 2 clock starts.
Common Failures and Misconceptions
Watch for these patterns:
- Marketing Type 1 as proof of year-long operating effectiveness
- Skipping system description accuracy so sales claims do not match the report
- Treating readiness slides as a Type 1 report
- Collecting no operating evidence after Type 1, then scrambling for Type 2
- Assuming Type 1 forever satisfies buyers who updated their questionnaire to require Type 2
- Confusing Type 1 with ISO 27001 certification or a self-issued badge
These misconceptions create diligence friction and weak renewal cycles.
Continuous Compliance Bridge
Type 1 is a milestone. Staying ready for Type 2 is the operating model. Keep control operation and evidence current from day one of the period so the next report is routine. See AuditFlo's continuous compliance resource and how to prepare for a SOC 2 audit.
How AuditFlo Helps
AuditFlo (auditflo.co) helps teams retain continuous evidence collection and audit-period history for control artifacts when those records are stored or linked through connected systems and workflows your team already uses.
The focus is organizing dated proof so design readiness and the handoff into Type 2 operating evidence can be shown with history instead of last-minute screenshots. AuditFlo is positioned here as evidence and readiness support for the control program your organization defines. It does not issue SOC 2 reports, does not perform attestations, does not certify compliance, does not guarantee a clean opinion, and does not replace auditors or your CPA firm.
To see the workflow for your stack, request a demo.
Key Takeaway
SOC 2 Type 1 is an independent attestation on whether controls relevant to the Trust Services Criteria were suitably designed as of a specified date. It is not an opinion on operating effectiveness over a period. Use it as a design milestone, speak precisely about the as-of date and criteria, and start Type 2 evidence habits immediately after.