If an enterprise prospect has asked for a SOC 2 report and you have nothing to send, your first action this week is to list every system that stores or processes customer data. That list becomes your audit scope, and the rest of this checklist hangs off it.
A SOC 2 Type I report is the quicker of the two report types. It puts an auditor's opinion in front of a buyer's security team while you work toward Type II. Below you'll find a 90-day plan, what to get in writing from vendors before you pay anyone, and what a Type I does not cover. The standards and vendor pages linked inline were last checked on 30 September 2026.
What does SOC 2 Type I prove, and how is it different from Type II?
A SOC 2 Type I report gives an auditor's opinion on whether your controls are designed appropriately at one point in time, while a Type II report also tests whether those controls operated effectively over a period.
Vanta's comparison describes Type 1 as assessing controls "at a single point in time" and Type 2 as assessing them over 3 to 12 months. Drata states that Type II is "required by most enterprise customers and partners". This suggests Type I works best as a stepping stone, not a destination. Before you commit to a timeline, ask the prospect's security contact which report they will accept. Some buyers take a Type I with a dated plan for Type II, and some won't. Only they can tell you.
Which trust services categories belong in a first audit?
The AICPA names five categories for SOC 2 reports: Security, Availability, Processing Integrity, Confidentiality and Privacy. Security, also called the common criteria, is the only mandatory one. Vanta's criteria guide says it is required because the other four categories build on it.
My recommendation: scope your first report to Security alone and add a category only when a specific customer contract asks for it. Each extra category adds controls you have to document and test, so you pay for scope that no buyer has requested yet.
Why are enterprise buyers asking for it at all?
Buyers ask because a breach at a vendor becomes their problem too. IBM's Cost of a Data Breach Report 2026 puts the global average cost of a breach at $4.99 million, a 12% increase over the previous year. That is an average across organisations of every size, so it says nothing about your own exposure. It does explain why procurement teams now treat an independent report as a gate.
How do you choose a compliance platform and an audit firm?
Get written quotes from at least two compliance platforms and two audit firms, because the big platforms don't publish prices, and compare what each quote includes rather than the headline number.
| Platform | How pricing is published (checked 30 Sep 2026) | What to ask |
|---|---|---|
| Vanta | Four tiers (Essentials, Plus, Professional, Enterprise); "personalized pricing" after a demo request | Which tier covers your integrations and how renewals are priced |
| Drata | No public prices; contact sales for a quote | Whether auditor access and policy templates are in the base quote |
Other vendors exist, and I haven't verified their current pricing, so I'm not listing numbers for them. Older blog posts quote specific dollar figures for platforms and audit firms. Those figures are left out here, because the pages that own the prices don't publish them. Drata's own article gives $7,500 to $60,000 for a Type 1 and 3 to 6 months for a first-time report, which is a vendor estimate, so treat it as a range to test against real quotes.
The platform matters less than the habits behind it. What breaks a SOC 2 program is usually an access review that lives in someone's head, a patch policy that doesn't match how your team ships, or evidence collection that starts late. A platform can automate evidence for cloud configuration. Human-process controls stay with you.
What does the 90-day SOC 2 Type I checklist look like?
The plan runs in five phases: scope, policies, control implementation, an evidence dry run, and audit engagement. Ninety days is realistic only if you already have basic hygiene such as SSO, MFA and an incident playbook.
| Days | Phase | Output |
|---|---|---|
| 1–15 | Scope and gap assessment | System boundary, gap list |
| 16–30 | Policy documentation | Policies that match real practice |
| 31–60 | Control implementation | Controls running, evidence export wired |
| 61–75 | Evidence dry run | Every control has at least one artifact |
| 76–90 | Audit engagement | Auditor chosen, system description submitted |
If you start from nothing, expect it to run longer. Drata's 3 to 6 month range for a first Type 1 suggests that 90 days is the fast end.
Days 1–15: scope and gap assessment
Define the system boundary before you touch any tooling. "In scope" means the system processes customer data, handles authentication, or stores anything covered by a customer contract. A narrow, accurate scope beats a broad one, because a scope that includes systems you can't control produces exceptions.
Then run a gap assessment against the Security criteria and sort findings into three piles: controls that don't exist, controls that exist but aren't documented, and controls that are documented but can't be proven. In my judgment the third pile is the one that catches teams out, because the paperwork exists but no record shows anyone followed it. If nobody on your team has done this before, consider paying for readiness help in this phase instead of paying an audit firm's hourly rate to write documents later.
Days 16–30: policies that describe what you actually do
Write policies for identity and access management, change management, incident response, vendor risk and business continuity. Describe present practice. "Engineers open a pull request for every change" is a policy you can prove. "Engineers should consider a pull request when possible" is a sentence an auditor will test and find wanting. If a policy describes a process you haven't built, build it or change the policy.
Days 31–60: control implementation
Work down this list and finish it by day 60:
- SSO enforced across every production system, with no exceptions for legacy tools or shared accounts.
- MFA required on every account with production access.
- A first access review completed, with the next one on the calendar.
- De-provisioning triggered by your HR or identity system when someone leaves.
- Centralised logging, with a retention period you have chosen and written down.
- A patch policy with a time window you can actually meet.
- A penetration test scheduled with a vendor. It can finish after the audit opens.
Set up automated evidence export early in this phase. Screenshots are slow to gather and hard to date, so ask your auditor which evidence formats they accept before you build the pipeline. That is a recommendation, not a rule from the standard.
Days 61–75: evidence dry run
Pull a full evidence package as if the audit opened today. Every control needs at least one artifact, and the gaps usually sit in human-process controls such as access review logs, change approvals and training records. Consider a hypothetical deploy that ships without the required approval. A control that operates correctly catches it, records the exception and logs a remediation note. A missing record for that exception is the finding.
Days 76–90: audit engagement
Pick your audit firm before day 76 and submit your system description before field work begins. That document, covering what the product does, where it runs and which controls are in scope, is often the first thing a buyer's security team reads, so make it accurate before the auditor sees it.
What does SOC 2 Type I not cover?
A Type I report does not certify that your product is secure, that you meet GDPR, ISO 27001, HIPAA or PCI DSS, or that an enterprise deal will close; it covers the design of in-scope controls on one date.
Buyers outside the US sometimes ask for ISO 27001 alongside SOC 2. Those are separate audits with overlapping controls, and healthcare or finance buyers may add frameworks on top. Ask early which ones your target customers require.
Start the Type II observation period as soon as the Type I report is issued. The window isn't passive waiting: access reviews, patch records and change approvals need to keep producing evidence every week. Build that habit during the Type I phase.
Architecture decisions feed into all of this. Consider how your multi-tenant SaaS separates customer data, because that is something you will be asked to describe. In Callidus, a clinic SaaS I built on React, Firebase and Stripe Connect, data lives under tenants/{tenantId} in Firestore, with role helpers in the security rules. I'm using it as a design example only. I'm not claiming a SOC 2 report for it. For the starting architecture, see the SaaS MVP stack guide, and for cost trade-offs when you staff compliance work, see SaaS development outsourcing costs and the in-house vs outsource comparison. For the wider picture of audit trails and GDPR, read SaaS Security and Compliance.
Your next step today: send the prospect's security contact one email asking whether Type I, Type II or Type I with a dated Type II plan will satisfy them, then write your in-scope system list while you wait for the answer.