SOC 2 Type 1 vs Type 2: Which Report Do You Actually Need?
Type 1 reports on control design at a single date. Type 2 reports on operating effectiveness over a period.
By Trustalis Published Last updated
The short answer
A SOC 2 Type 1 report covers whether your controls are suitably designed at a single point in time. A SOC 2 Type 2 report covers whether those controls actually operated effectively across a period, typically three to twelve months. If a prospect has asked you for "SOC 2" without specifying, they almost always mean Type 2, because a Type 1 tells them what you intended to do and a Type 2 tells them what you did.
Do not start with the audit. Start with the system boundary and the controls, then decide which report your buyer needs, because the sequence you choose decides how fast you get there.
What each report actually says
Type 1 is an opinion on the fairness of your description of the system and the suitability of the design of your controls, as of a specified date. It answers one question: if you operated these controls as described, would they meet the Trust Services Criteria? Nothing in it is evidence that you operated anything.
Type 2 is an opinion on the same thing, plus the operating effectiveness of those controls throughout a period. It requires samples: access reviews you actually performed, tickets that actually went through change management, alerts that were actually triaged. The auditor tests the evidence, not the intention.
Both are issued by an independent CPA firm under the AICPA's SOC 2 Trust Services Criteria. Neither is a certification. There is no certifying body, no certificate, and no such thing as a company that is "SOC 2 certified" — a phrase that shows up in vendor questionnaires constantly and means nothing. Saying it in a security review invites a follow-up question you will not enjoy.
Type 1 vs Type 2 at a glance
| SOC 2 Type 1 | SOC 2 Type 2 | |
|---|---|---|
| What it reports on | Design of controls at a specific date | Design and operating effectiveness across a period |
| Period covered | A single point in time | Typically 3–12 months |
| What a buyer learns | Your controls are sensibly designed | Your controls were performed, consistently, and can be proven |
| Typical effort | Lower: documentation and configuration review | Higher: a full evidence cycle, sampled by the auditor |
| Typical timing | Often achievable in weeks once controls exist | Three to twelve months after controls are operating |
| Renewal | Not typically renewed | Re-performed annually, usually with an annual cadence |
| Best used for | An early enterprise deal, a bridge while Type 2 accrues | Satisfying procurement, contracts, and vendor risk programs |
Which one does your buyer want?
First enterprise deal, early-stage company. A Type 1 will often unblock a procurement review that a company with no report fails outright, and it is honest about what it is. Do not represent it as a Type 2.
Contractually required Type 2, or a mature vendor risk program. Enterprise buyers, financial institutions, and healthcare organizations increasingly write Type 2 into the contract, with a defined observation period and an annual refresh. A Type 1 does not satisfy the clause.
Your own commitment to a renewal cycle. Once you are on Type 2, the practical rhythm is continuous: controls run all year, evidence accumulates, and the report is reissued annually. Companies that treat it as an annual scramble have usually not built the evidence pipeline.
A renewal with no material change. Still a Type 2 with a fresh period. A Type 1 in year two would signal that something went backwards.
The sequencing question, and the trap in it
The sensible path for most companies: readiness, then controls designed and operating, then a Type 1 if a deal needs a report now, then a Type 2 over a period.
The trap is believing the Type 1 is a shortcut. When your auditor issues a Type 1 dated today and you begin the Type 2 period tomorrow, your team has to operate every control, every day, for the whole period, and prove it. If engineering is still changing infrastructure weekly, or access reviews are still "when someone remembers," the Type 2 period will be a long expensive demonstration that the Type 1 was optimistic.
Two things worth deciding before you spend anything: how narrow your Trust Services Criteria scope can be, and how small your system boundary can be. Security is mandatory; Availability, Confidentiality, Processing Integrity, and Privacy are optional. Every additional criterion is more work, more evidence, and a longer report. Little is gained by scoping extra criteria you have not been asked for.
What auditors will actually test
The specific controls come from your system description, but the areas that generate findings look similar across companies:
- Access. Onboarding, role changes, terminations, and quarterly access reviews with evidence they happened and that action was taken.
- Change management. Tickets, approvals, testing, and deployment records for production changes, plus evidence that the pipeline enforces them.
- Monitoring and alerting. What is logged, who reviews it, and what happened when an alert fired.
- Vendor management. A vendor inventory, risk tiers, and due diligence for the ones that matter.
- Incident response. A plan, a tested response, and records of incidents actually handled.
- Availability and backups, where Availability is in scope. Restore testing, not just backup jobs.
- HR and personnel. Background checks where applicable, security awareness training, and acknowledgements of policy.
- Risk assessment. A documented assessment, refreshed on a defined cadence, with treatment decisions.
Cost: what drives the number
Market ranges move constantly and depend on scope, so treat any single figure with suspicion, including one from a vendor. The honest structure of the cost is:
- Readiness and gap work, usually the largest line for a company starting from scratch: policy development, control design, and technical remediation such as centralized logging, SSO, and enforced MFA.
- Auditor fees, driven by the number of criteria in scope, the length of the observation period, the size of the system boundary, and whether it is a first-year or recurring audit. First-year Type 2 engagements are typically more expensive than renewals because the auditor spends more time on the system description.
- Tooling, from a compliance automation platform to a SIEM. Useful for evidence collection; not a substitute for controls that operate.
- Internal time, which is always the underestimated line. Someone has to answer the auditor, and that person is usually an engineer.
The question worth asking a prospective auditor is not "what do you charge" but "what will you need from us, and when." The answer tells you what the engagement will really cost.
Five reasons a first Type 2 slips
- No evidence retention. The control ran, but the screenshot, ticket, or report was never captured, and the tool rotated logs after 30 days. This is the most common and most avoidable finding.
- Controls were designed but not operated. Policies existed in the wiki; reviews did not happen. The auditor samples a quarter and finds nothing.
- A boundary that includes systems nobody owns. Shadow infrastructure, a legacy service, a marketing site on the production cloud account. Every asset in the boundary needs an owner who can answer for it.
- Material change during the period. A migration mid-period means either new controls or a scope change. Both cost time.
- Treating the audit as documentation. The report describes the company. If the company's practice is thinner than the document, the testing finds it.
How to move fast without creating a problem
Narrow the criteria to what the buyer asked for. Define the system boundary in writing, with a diagram, before anyone writes a policy. Automate evidence collection before the observation period begins, not during it. Name a single owner with authority to chase people. And run a tabletop against your own evidence set before the auditor arrives: pick a sample of each control and ask to see the artifact. Whatever you cannot produce in ten minutes is the thing that will become a finding.
Where this fits
SOC 2 readiness is not a documentation exercise, and the report is a byproduct of how the company actually operates. The companies that pass cleanly are the ones who decided that access reviews, change approvals, and evidence capture are simply how work gets done.
Trustalis supports SOC 2 readiness, control design, evidence preparation, and coordination with your audit firm. We are not a CPA firm and we do not issue SOC 2 reports; the attestation comes from an independent auditor.
