“Do you have SOC 2?” sounds like a yes-or-no question, but it hides a material distinction. A SOC 2 Type I report examines whether controls are suitably designed and implemented at a point in time. A SOC 2 Type II report examines design plus operating effectiveness throughout a defined observation period. Both are legitimate attestation reports; they answer different assurance questions.
Fast rule: if a customer’s requirement says “current SOC 2 Type II,” Type I is not a substitute unless the customer’s security and procurement owners approve it in writing. If they need independent assurance quickly and will accept a stepping stone, Type I can be useful while a Type II observation period runs.
What SOC 2 Type I actually proves
Type I is a point-in-time examination. The auditor selects a date and evaluates the design and implementation of controls relevant to the selected Trust Services Criteria. The question is broadly: on this date, were the controls suitably designed and in place to meet the applicable criteria? The auditor will review policies, interview control owners, inspect configurations and trace examples of implementation. A Type I report is not simply a policy review; the auditor must obtain evidence that the described controls exist.
Type I is valuable when a startup has formalised its programme recently. It gives a customer an independent view of the system boundary and control design, and it gives the team a concrete report to use in procurement conversations. It also creates a baseline for a future Type II. But it cannot show that monthly access reviews happened every month or that every production change followed the approval process over six months. It says what was in place at the examination date, not how consistently the team operated it before and after.
What SOC 2 Type II actually proves
Type II includes the Type I design assessment and adds tests of operating effectiveness across a defined period. The auditor chooses samples and tests whether controls were performed as described. Depending on the scope, that might mean inspecting several access reviews, a sample of joiner and leaver records, approved changes, vulnerability remediation tickets, incident records, vendor reviews, backup tests and security training results.
The observation period is commonly three, six or twelve months. A three-month period can be enough for a particular buyer or an early report, but many enterprise procurement teams expect six or twelve months because it provides more evidence of repeatability. The period is not a waiting room in which the auditor does nothing. The team must operate the controls, retain source evidence, record exceptions and respond to auditor requests. A control that exists in a policy but is not performed can lead to an exception in the report.
Type II is stronger evidence of operational discipline, not a guarantee that no incident occurred. A security incident can occur in a well-controlled environment; what matters is whether the organisation detected, responded to and documented it according to its process. Similarly, a sampled exception may be explainable, while repeated or material failures can affect the auditor’s opinion. Read the SOC 2 evidence checklist to see what operating evidence must be retained.
Type I versus Type II at a glance
| Factor | Type I | Type II |
|---|---|---|
| Core question | Are controls suitably designed and implemented now? | Were controls suitably designed and operating effectively throughout the period? |
| Time dimension | Point in time | Defined period, often 3–12 months |
| Evidence | Policies, configuration, walkthroughs and implementation examples | All Type I evidence plus repeated samples of control operation |
| Customer perception | Useful stepping stone; acceptance varies | Usual enterprise requirement |
| Best fit | New programme, urgent deal, buyer accepts it | Established controls, mature procurement, ongoing assurance |
| Common risk | Buyer rejects it as too limited | Weak evidence or exceptions accumulated over a long window |
What do buyers mean when they say “SOC 2 report”?
Do not infer the answer from a salesperson’s shorthand. Send a small set of questions to the customer’s security or procurement contact:
- Is Type I accepted, or is Type II mandatory?
- How recent must the report be at contract signature?
- What observation period is required for Type II?
- Is Security enough, or are Availability, Confidentiality, Privacy or Processing Integrity required?
- Will the customer accept a bridge letter between reports?
- Does it require a particular auditor, report format, subservice method or complementary user entity controls?
Some customers will accept a Type I for an initial pilot, then require Type II at renewal. Others accept a Type II with a three-month window if the service is low risk, while regulated or data-intensive buyers may insist on twelve months. Get the answer in the procurement record, not only in a sales call. A dated email from the customer’s decision-maker can prevent a startup from spending months on a report that does not meet the contract.
When Type I alone is enough
Type I alone can be enough where the buyer expressly accepts it, the service is entering a pilot, the customer’s risk model is proportionate, or the organisation needs a first independent baseline. It may also be appropriate where controls are new but the customer wants evidence that the programme has been implemented before granting access to its environment.
Type I is not enough merely because it is faster. A customer that says “Type II only” is signalling that it needs evidence of repeatable operation. A Type I report can still support the conversation, but describe it accurately and pair it with a written plan for the Type II window. Do not put “SOC 2 compliant” on a website when the report is limited to a point in time; share the report under NDA and explain scope, date and criteria.
When to move from Type I to Type II
Move to Type II when your target customers include enterprise buyers with mandatory vendor assurance, when contract renewal depends on ongoing evidence, or when your team has operated the core controls consistently enough to produce a clean sample. Type II is also the sensible destination if sales repeatedly receives the same request. A single Type I may unblock one prospect; Type II reduces repeated exceptions to the same question across prospects.
Do not start the observation period to create pressure before the foundations exist. First confirm the system boundary, implement the control owners and cadences, test evidence collection, and run a readiness review. A readiness assessment is not an audit and cannot produce the report, but it can expose missing controls before months of evidence are at stake. Our SOC 2 readiness service supports that preparation.
A practical startup decision process
- Write the acceptance statement: “Customer X will accept a SOC 2 Type I report dated by [date], covering Security and Confidentiality, while Type II evidence runs for six months.” If you cannot write this, keep asking questions.
- Map the commercial deadline: distinguish contract signature, production access and renewal dates. The report may be needed for one but not another.
- Assess control maturity: inspect access, change, vulnerability, incident, vendor, backup and training evidence. Identify whether controls are merely planned, implemented or operating.
- Choose an observation window: use the customer’s written requirement, not the shortest period an auditor is willing to quote.
- Plan the transition: if Type I is the first milestone, schedule the Type II readiness review and start date immediately after stable controls are implemented.
For a UK or EU startup selling to the US, the UK SaaS SOC 2 guide covers auditor selection, customer wording and commercial logistics. For a detailed calendar, use the SOC 2 audit timeline guide.
How exceptions affect the decision
A report can include exceptions; there is no simple pass/fail certificate. The auditor evaluates the nature and significance of exceptions and may modify the opinion if failures are material to the criteria. Type II creates more opportunities for an exception because it tests repeated operation, but that is also why customers value it. A mature response is to document the root cause, scope, compensating control and remediation date, then discuss it with the auditor rather than hiding the evidence.
For Type I, an exception in design can prevent the report from supporting the customer’s requirement at all. For Type II, a missed sample may be limited, or it may reveal a systemic failure. Control owners should know what the control requires, where its source evidence lives and what to do when the normal process fails. That operational discipline matters more than buying a compliance platform.
Frequently asked questions
Is Type II always better?
Type II gives more assurance about operation over time, but it is not automatically the right first milestone. It must match the customer’s required period and a control programme your team can operate. A narrow, accurate Type I is better than misrepresenting a Type II that has not happened.
Can Type I become Type II?
Not retrospectively. The Type II observation period starts on an agreed date, and the auditor tests operation across that period. Evidence collected before the period may inform readiness but does not automatically count as Type II testing.
How long does each take?
Readiness and fieldwork for Type I can take roughly six to twelve weeks for a small, controlled environment. Type II includes a three-to-twelve-month observation period, plus fieldwork and reporting. See the timeline guide for planning assumptions.
Does SOC 2 Type II replace ISO 27001?
No. ISO 27001 certification and SOC 2 attestation use overlapping controls but have different scopes, assessment models and outputs. Existing ISO evidence can reduce duplicated work when mapped properly.
Not sure which report your customer will accept?
Bring the procurement wording and your target date. We will separate Type I, Type II and interim evidence options in a 45-minute working session.
Book a 45-minute working session →