SOC 2

Type 1 vs. Type 2: Which SOC 2 Makes Sense for First-Timers?

Written by Shane Troyer
Published September 14, 2026

On this page

Key takeaways

1. Type 2 is the report enterprise and regulated buyers name, and it is increasingly the only one they will accept as a final answer.

2. Given that a Type 2 is where you are going, is there enough value in having a Type 1 sooner to justify running two examinations instead of one?

3. Company size is not the deciding variable. The deciding variables are what your buyers will accept, when they need it, and whether your controls can survive an observation period without accumulating exceptions.

A buyer asks for a SOC 2 report. There is no prior report, no internal reference point, and a deal attached to the answer. The first decision is which report to pursue, and it gets made with less information than it deserves.

The choice between a Type 1 and a Type 2 is usually presented as a compliance maturity question: start with a Type 1, graduate to a Type 2. For a SaaS company being asked for a report by a customer, it is not a maturity question at all. It is a commercial and timing question. Type 2 is the report enterprise and regulated buyers name, and it is increasingly the only one they will accept as a final answer. That makes the real question narrower and more useful:

Given that a Type 2 is where you are going, is there enough value in having a Type 1 sooner to justify running two examinations instead of one?

Company size is not the deciding variable. A ten-person SaaS company with settled access controls, enforced pull request reviews, running vulnerability management and clean evidence capture can go directly to a Type 2. A larger, more mature company might deliberately buy a Type 1 because a specific prospect has confirmed that a Type 1 in November unblocks procurement while the Type 2 follows in the spring. The deciding variables are what your buyers will accept, when they need it, and whether your controls can survive an observation period without accumulating exceptions.

This article covers what a SOC 2 report is and who is involved, what controls, design effectiveness and operating effectiveness actually mean, what separates a Type 1 from a Type 2, how to choose a path, and how to hold a deal together while the report does not yet exist.

What a SOC 2 report is

SOC 2 is an independent examination performed by a CPA firm against the AICPA’s Trust Services Criteria. The output is an opinion report describing your system, the controls you say are in place, what the auditor tested, and what they found. In Canada, reports are commonly issued under both CSAE and AICPA standards by an independent CPA firm, so a single engagement can serve customers in Canada, the United States, or both.

An attestation, not a certification

There is no SOC 2 certificate, no government registry, and no passing grade. You are not “SOC 2 certified.” You have a report, with an opinion in it, covering a defined scope and a defined date or period. This distinction matters commercially, because what you hand a buyer is a document they will read, not a badge they will glance at.

Two consequences follow:

The report can contain exceptions. A Type 2 that documents control failures still gets issued. Your customers see them.
Nothing can be claimed before issuance. “We are SOC 2 compliant” while an audit is underway is an overstatement that security reviewers catch.

Who performs the examination

Only an independent CPA firm can perform a SOC 2 examination and issue the report. Independence is not a formality. It is the reason the report carries weight with a buyer who has never met you, and it is a structural limit on what your auditor is allowed to do for you. An auditor who designed your controls cannot then issue an independent opinion on them.

The Trust Services Criteria and what scope means

The examination is performed against the Trust Services Criteria, organized into five categories:

Security (the Common Criteria). Required in every SOC 2 report.
Availability. Optional. Relevant where uptime commitments are contractual.
Confidentiality. Optional. Relevant where you handle customer data with defined confidentiality obligations.
Processing Integrity. Optional. Relevant where accuracy of processing is the product promise.
Privacy. Optional. Distinct from confidentiality and the heaviest to carry.

The criteria are principles, not a checklist. They describe outcomes and leave the implementation to you. That flexibility is what trips up first-time teams. There is no list to complete, so it is easy to build more than you need.

Scope compounds this. A SOC 2 examines the systems and processes that affect the service you deliver to your customers. What falls inside that boundary is a decision, and it is often a smaller decision than teams assume. Modest changes to how data is organized and how processes are separated can meaningfully reduce what has to be examined. Scope set under deal pressure is scope you live with through the observation period and the report that follows.

Why buyers ask for it specifically

US enterprise procurement teams standardize on SOC 2 because it gives them something their own risk process can consume: third-party verified evidence that a cloud vendor protects customer data, in a format their reviewers already know how to read. Domestic compliance statements and self-attestations do not clear that bar on their own. For a Canadian company selling south, the report functions as a translation layer that puts you on the same footing as US-based competitors.

Who does what in a SOC 2 engagement

Four parties show up in most first SOC 2 engagements. Their boundaries are frequently misunderstood, and the misunderstanding is expensive.

Management

You own the control environment. Not the auditor, not the consultant, not the platform. Management is responsible for the system description, for deciding which controls exist, for assigning owners, for operating those controls, and for the assertion that accompanies the report.

Responsible for: scope decisions, control design and implementation, named owners, operating the controls, evidence retention, the management assertion.
Cannot delegate: ownership. Every recurring control needs a person’s name on it, not a tool’s.

The auditor (independent CPA firm)

The auditor plans the examination, tests your controls, and issues an opinion.

Responsible for: determining the testing approach, selecting populations and samples, evaluating whether controls are suitably designed, testing operating effectiveness over the period, forming and issuing the opinion.
Can do: explain what the criteria mean for a company your size, tell you what evidence they expect to see, and flag where your thinking is going to run into trouble.
Cannot do: design your controls, write your policies, implement your tooling, or otherwise perform management’s functions. Independence is what makes the opinion worth something to your buyer.

Engaging an auditor early is not the same as starting the audit. A common and avoidable mistake is waiting until you feel ready before making contact, which removes exactly the input that would have told you whether you were.

The readiness or security consultant

This is the party that can do the work the auditor cannot.

Responsible for: gap assessment, scope advice, control design, policy development, remediation, preparing the team for what fieldwork feels like.
Where the value concentrates: scope discipline. A good consultant stops you from building controls you do not need and cannot sustain, which is the single largest source of avoidable cost in a first SOC 2.
Cannot do: issue an opinion, or confer any assurance a buyer can rely on. A readiness assessment is an input to your decision, not an artifact of assurance, though some buyers will accept one as interim evidence.

The GRC platform

Compliance automation tools connect to your cloud, identity and code hosting providers, map configurations to criteria, and collect evidence continuously.

Responsible for: evidence collection and retention, control monitoring, mapping your environment against the criteria, reducing the manual burden of screenshots and spreadsheets.
Cannot do: know your context. The platform does not decide what applies to your business, who owns a control, what cadence it runs on, or whether the evidence it collected is the evidence that matters. It also cannot make anyone perform the control.
Frequent failure mode: buying the platform first and treating a green dashboard as readiness. Dashboard badges are not assurance and no auditor treats them as such.

Party	Owns	Cannot do
Management	Scope, control design, operation, evidence, the assertion	Transfer ownership to a vendor or tool
Auditor (CPA)	Testing approach, sampling, the opinion	Design, implement or operate your controls
Readiness consultant	Gap assessment, control design, remediation, scope advice	Issue an opinion or provide assurance
GRC platform	Evidence collection, monitoring, criteria mapping	Supply judgment, context or accountability

Controls, design effectiveness and operating effectiveness

What is a control?

Definition

A control is a specific, repeatable safeguard that reduces a specific risk. It has an owner, a cadence, and a trace it leaves behind. Controls fall into three broad types:

Preventive. Stops the bad outcome. Branch protection that blocks direct pushes to main.
Detective. Surfaces the bad outcome after the fact. Alerting on privileged role assignment.
Corrective. Restores the state. Restoring from backup after data loss.

Examples from a cloud-native SaaS environment:

Production changes require an approved pull request from someone other than the author.
Access to production is granted through defined roles and reviewed quarterly.
Employee offboarding revokes all system access within one business day.
Vulnerability scans run on a defined cadence and findings are remediated within severity-based timeframes.
MFA is enforced on all identity provider accounts.

Note what these are not. They are not policies. A policy says access reviews happen quarterly. The control is the review actually happening, performed by a named person, against a complete population, with a record of what was decided.

What is design effectiveness?

Design effectiveness asks: if this control operates as intended, does it actually address the risk?

A suitably designed control is:

Logically capable of reducing the risk it is aimed at. A quarterly access review does nothing about a shared admin credential nobody rotates.
Suitable to your business and mapped to the criteria. It reflects how you actually operate, not how a 500-person bank operates.
Documented clearly enough to be repeated and tested. Someone other than the author can perform it, and an auditor can determine whether it happened.
Implemented and in place. Design effectiveness includes implementation. This is the part teams miss.

That last point is worth dwelling on, because it drives the most common misconception about Type 1 reports.

Operating effectiveness

Operating effectiveness asks: did the well-designed control actually operate, consistently, throughout the period?

Testing operating effectiveness means working from populations and samples. The auditor establishes the complete population of events the control should have covered, selects samples across the period, and looks for evidence of each occurrence: what happened, who performed it, when, who approved it, and where the record lives.

This is where the gap between a control that exists and a control that runs becomes visible. A quarterly access review that happened in January and April but not July is a design that works and an operation that failed.

Control	Design effectiveness evidence	Operating effectiveness evidence
Peer review of production changes	Branch protection configuration requiring one approval, direct pushes to main disabled, CI gates enforced	A sample of merged pull requests across the period showing an approver other than the author, and the population of merges to confirm no bypasses
Quarterly access review	A documented procedure, a named owner, a defined review population, evidence of one completed review	Every scheduled review across the period, each with the population reviewed, decisions made, removals actioned, and dates
Offboarding	The checklist, the ticket template, the one-business-day standard, evidence for a recent departure	The full population of departures in the period, each tested against the access revocation timeline
Vulnerability management	Scanner configured and running, severity definitions, remediation SLAs documented	Scan results across the period, findings tracked to closure within SLA, exceptions documented and approved

Type 1 and Type 2

What a Type 1 covers

A Type 1 is an examination of whether controls are suitably designed and in place as of a single date.

Controls must exist, be constructed to address the risk, and be functioning on that date, with evidence.
There is no observation window, so a Type 1 runs on readiness work alone.
The report contains the system description, the management assertion, the control set, and the auditor's opinion on design as of the as-of date.

The misconception worth correcting: a Type 1 is not a policy review, and it is not the easy option. Written policies with nothing behind them do not pass. Auditors verify that controls are implemented and expect evidence that mechanisms such as MFA, logging, backups and access provisioning are operational at that point in time. It is a substantial amount of evidencing work.

A Type 1 also carries the same scope as the Type 2 that follows. Scope decided quickly under deal pressure for the Type 1 is scope you carry through the observation period.

What a Type 2 covers

A Type 2 is an examination of whether those same controls operated effectively across a defined observation window, typically 3 to 12 months.

It tests design and operation. The design evaluation does not disappear.
It requires an evidence trail across the period, tested through populations and samples.
The observation window is calendar time. It does not compress.
It is the default request from enterprise and regulated buyers.

The distinction in plain terms:

Side by side

	SOC 2 Type 1	SOC 2 Type 2
What is tested	Control design and implementation	Control design and implementation, plus operating effectiveness
Coverage	A single date	A period, typically 3 to 12 months
What it proves	The controls were suitably designed and in place that day	The controls actually operated throughout the period
Evidence examined	Configuration, procedure documentation, and evidence of implementation at a point in time	Samples drawn from complete populations across the period
Time driver	Readiness work only	Readiness work plus the observation window plus issuance
Buyer acceptance	Accepted by some SMB and mid-market buyers, and by enterprise buyers as interim assurance with a committed Type 2 date	The baseline requirement for enterprise and regulated procurement

The two clocks

Almost every mistake in this decision comes from treating one clock like the other.

The effort clock is the readiness work: scoping the examination, designing and implementing controls, remediating gaps, getting evidence capture running. It responds to effort, money and experience. Push harder, finish sooner.

The calendar clock is the observation window. It starts when your controls are operating and running cleanly, and it ends when the period closes. No amount of effort turns six months of operating history into three. Report issuance follows the window close by several more weeks.

You can accelerate the first. You cannot accelerate the second. That is the entire commercial problem, and it is what a Type 1 is sometimes bought to solve: a Type 1 compresses time-to-assurance. It does not compress time-to-Type-2.

Where the effort clock actually compresses

These are the levers that are real:

Scope discipline. The fastest path is usually the narrowest defensible one. Security-only scope, a tightly drawn system boundary, and resisting optional criteria that no customer has asked for. Every criterion you add is controls to design, operate and evidence, forever.
Not overbuilding. The Trust Services Criteria read as though they were written for mature organizations, because they were. Teams respond by adopting enterprise process a lean team cannot sustain. A readiness consultant who pushes back on scope and tells you what you do not need to build usually pays for themselves before fieldwork starts.
Inheriting from your cloud provider. Most cloud-native teams are not starting from zero. Physical and environmental security, network infrastructure and large parts of the data centre control set sit with your hyperscaler and are addressed through the provider’s own report and your vendor management. Identity, cloud and code hosting configuration often covers a meaningful share of what remains.
Configuring tooling so daily work produces the evidence. The goal is not a parallel compliance chore. Branch protection, ticket workflows, identity provider settings and a GRC platform connected to all three mean the evidence accumulates as a by-product of the work.
Engaging the auditor early. Not to start the examination, but to find out what they expect to see before you build something else.
Human review of automated evidence. Automated collection is fast and context-blind. Having an experienced person check evidence for completeness and relevance before it goes to the auditor removes rounds of back-and-forth and avoidable exceptions.

Where it does not compress

The two paths: bridge or direct

Path A: the bridge (Type 1, then Type 2)

You complete readiness work, get a Type 1 issued as of a date, establish the operating cadence, open the Type 2 window, and deliver the Type 2 later.

What it buys:

What it costs:

Where it fits:

Where it does not fit: the belief that a Type 1 is how you find your gaps. It is not. Readiness work finds gaps, whether you do it internally or with a consultant, and it does so earlier and more cheaply. What a Type 1 adds is an independent opinion on design that you can put in a buyer’s hands. If no buyer needs that, you have paid for a checkpoint rather than assurance.

Path B: direct to Type 2

You complete readiness work, confirm evidence is generating cleanly, open the window, and deliver the report buyers actually asked for.

What it buys:

What it costs:

Where it fits:

Buyers are enterprise or regulated and will not accept a Type 1 as a final answer.
The pipeline is far enough out that the window fits, ideally 6 to 12 months before a final report is strictly required.
Controls are already running on a consistent cadence and evidence is easy to produce.
Prospects will accept interim evidence, or will wait out the window.

Working the decision

Decide in this order.

What assurance does this buyer actually require?

Not “they asked whether we are SOC 2 compliant.” Find out:

Is SOC 2 a contractual requirement, or did someone tick a questionnaire box?
Will they accept a Type 1? Will they accept a Type 1 with a committed Type 2 date?
Do they require a Type 2 with no alternative?
Which criteria do they expect, and what period length?

When the buyer cannot answer these questions, the report is often a checkbox nobody will read closely. That is still worth knowing. Decide deliberately, rather than guessing or complying blindly.

When must acceptable assurance exist?

If a Type 2 must exist before signature and the buyer will not move, a Type 1 does not solve your problem and buying one delays the thing that does. If the buyer needs independent assurance in eight weeks and will accept a Type 1 plus a committed Type 2 roadmap, the Type 1 has real economic value. If nothing in the pipeline needs anything for nine months, the case for an interim report is thin.

Could you start the observation period tomorrow without knowingly accumulating exceptions?

Not “are we mature enough.” Specifically:

Are access changes captured, with an approval trail?
Are pull request approvals enforced rather than encouraged?
Is vulnerability remediation actually happening within your stated timeframes?
Are periodic reviews assigned to named people and scheduled?
Is evidence retained somewhere you can retrieve it?
Are incidents documented?
Are joiners, movers and leavers handled consistently?

If the answer is yes, direct-to-Type-2 gets much more attractive. If the answer is no, you have a readiness problem. A readiness problem is solved by readiness work. Turning it into a second audit fee does not fix it.

Bridge vs. direct

	Bridge (Type 1 then Type 2)	Direct to Type 2
Time to first artifact	Weeks after readiness completes	After the window closes and the report issues
Total cost	Two engagements	One engagement
Team load	Two fieldwork sprints in twelve months	One fieldwork sprint
Best when	A deal is blocked now and the buyer confirmed a Type 1 clears it	Buyers require a Type 2 and the timeline allows the window
Main risk	Buying a milestone nobody asked for, then leaving a gap after it	No independent artifact to show during the window

A note on short observation windows

Compressing the window to three months in order to produce a Type 2 sooner has its own failure mode. Many enterprise buyers expect a minimum of six months of coverage, and a three-month period can read as a rushed report, which invites questions you did not want. If a short period will not satisfy the buyer, you may end up paying for a second Type 2 sooner than planned. A Type 1 plus an engagement letter committing to a 6 to 9 month Type 2 often lands better than a three-month Type 2 that gets re-requested a year later.

Moving from a Type 1 to a Type 2

What is missing after a Type 1 is narrower than teams assume. Not the control set and not evidence capability, since the Type 1 required both. What is missing is the operating cadence and the accumulated trail.

The interval between the Type 1 as-of date and the window start is real work. Access reviews, change records, vulnerability cycles, incident handling and evidence retention need to be running on schedule before the window opens, because the window tests exactly that.
Open the window when evidence generation is working, not on a date someone picked off a calendar.
Do not leave a long gap. Commercial value decays as buyers move on to asking for the Type 2, and the longer the gap, the more of the Type 1 scoping work you end up redoing.

Scope drift

The system description has to describe the system as it operated during the window. If the environment moves after the as-of date, the Type 1 baseline stops matching reality.

Common causes:

Infrastructure growth. New cloud accounts, new clusters, or third-party SaaS tools that bypass existing logging and access controls.
Product expansion. New services or business units processing in-scope data that were not in the original system description.
New data flows and new tooling, including AI tooling touching customer data.
Personnel and process change. Turnover or shifting workflows that leave periodic controls unassigned or undocumented.
New customer commitments that pull in criteria the Type 1 did not carry.

How to manage it:

Keep the Type 2 system description tightly aligned with what was tested in the Type 1, and defer major architectural changes until after the window closes where you can.
Keep a change log. Record every significant infrastructure, vendor or policy change when it happens, not at fieldwork.
Run a mid-period sync with the auditor to review organizational changes and confirm whether new assets belong in scope.

Common mistakes

Treating the calendar clock like the effort clock. Promising a buyer a report date that cannot exist, or believing more effort will compress the window. This is the most common and the most damaging, because it breaks trust with the buyer you were trying to keep.
Buying a Type 1 nobody asked for. If no buyer needs an interim milestone and controls are already running, it is a second fee for little commercial return.
Assuming the window opens the day the Type 1 issues, before the operating cadence and evidence trail are running. Month one then produces exceptions that land in the report.
Leaving a gap after the Type 1. Value decays and scope drifts.
Rushing the Type 1 scope. It is the same scope as the Type 2. A scope decided under deal pressure is one you live with through the window and the report.
Over-engineering. Adopting enterprise frameworks, committees and policy libraries a lean team cannot sustain. A control you cannot maintain is worse than no control, because its failure is documented.
Buying a GRC platform first and treating it as autopilot. The platform maps your environment to criteria. It does not decide what applies, who owns it, or what cadence it runs on.
Waiting until you are “ready” to engage an auditor. You lose the input that would have told you what ready means.
Skipping readiness because you are going direct to Type 2. Going direct does not mean going in blind. The readiness work still happens, internally or with a consultant.
Underestimating evidence collection. Access reviews, vulnerability cycles, SDLC evidence and control monitoring are routinely discovered mid-testing rather than designed in advance.
Relying on generic policies. Policies that are obviously not operationalized are visible to auditors and buyers alike.
Missing the adjacent documentation. Data flow diagrams, subprocessor lists, defined AI usage and privacy obligations surface late and slow everything down.
Failing to prepare sales. If the people in front of buyers cannot describe the controls or the timeline accurately, the report does not help.
Overclaiming. Saying you are SOC 2 compliant before the report is issued.

Can the audit wait?

Wait, and do nothing formal yet

Core infrastructure, repositories and data pipelines are changing weekly. Auditing an unstable architecture means auditing something that will not exist in six months.
No stable customer commitments.
Product-market fit is still being validated with self-serve or SMB customers who do not require third-party assurance.
Capital and engineering hours spent on a formal audit pull directly from product survival.

Not yet, but start building

This is the most common position and the one most articles skip.

This position does not need an auditor engaged. It needs the foundations: named control owners, enforced change management, access lifecycle, evidence capture configured into daily work. None of that is path-dependent and none of it is wasted.

Start now

Holding the deal together before the report exists

The report is what the buyer asked for. It is not the only thing that moves a security review forward. By the time you are in one, there is already demand for your product.

First, determine whether SOC 2 is a blocker or friction

Blocker: contract language, an RFP requirement with no equivalency clause, or a risk tier that mandates it. The negotiation is about exception paths, conditional signature, limited scope or the next procurement cycle.
Friction: a questionnaire default or a security reviewer preference. The negotiation is about the shape of the evidence you provide instead.

The credibility hierarchy

Procurement teams rank security artifacts, whether or not they say so.

Tier 1, definitive assurance. A completed SOC 2 Type 2, or ISO 27001 where relevant. Audited operation over time.
Tier 2, point-in-time assurance. A SOC 2 Type 1, and a recent third-party penetration test with remediation status. A clean baseline plus external validation.
Tier 3, process assurance. An auditor engagement letter naming a dated observation window and expected issuance, a completed standardized questionnaire (CAIQ or SIG), a readiness assessment, architecture and subprocessor documentation.
Tier 4, low or unverified assurance. GRC dashboard badges, generic policy PDFs, roadmaps and sales claims.

A Type 1 paired with a committed Type 2 date reads stronger than either alone: independent verification now, and a defined path to what they actually want.

The interim package

Assemble it once and keep it current. Share under NDA, and tailor what you send to who is asking. A non-technical procurement contact does not need your architecture internals.

Architecture summary and data flow overview
Data location, encryption and retention
Core policy summaries
Subprocessor list
Incident response overview
Recent penetration test summary with remediation status
Completed security questionnaire
Evidence of foundational controls such as enforced MFA and access management
The signed auditor engagement letter, the dated observation window and expected issuance date
A named contact for their security reviewer

What to say, and what not to

Accuracy is the whole game here. Security reviewers compare what you said with what they see.

Weak: “We are working on SOC 2.”
Stronger: “We are SOC 2 Type 2 in progress, engaged with an independent CPA firm, observation period opening in March and the report expected in the fourth quarter. Here is the engagement letter and our current security package.”
Do not say: “We are SOC 2 compliant” or “we are certified” before issuance.

What to ask for in exchange

If you are handing a buyer interim assurance, ask for something commercially meaningful in return. That is what makes a Type 1 worth buying in the first place.

If nothing changes commercially once the interim assurance is delivered, you bought an expensive waypoint.

FAQ

Can the same firm perform the Type 1 and the Type 2?

Yes. Continuity usually helps, since the scope and system description carry forward.

Can you go straight to a Type 2 without a Type 1?

Yes. There is no requirement to complete a Type 1 first. What you cannot skip is the readiness work that gets controls designed, implemented and operating before the window opens.

Will buyers accept a Type 1?

Some will, particularly SMB and mid-market buyers. Enterprise and regulated buyers usually require a Type 2, though many will accept a Type 1 in the interim when it comes with a committed Type 2 date. Ask the specific buyer rather than assuming.

What happens to the Type 1 once the Type 2 is issued?

The Type 2 becomes the report you circulate. The Type 1 keeps historical value only, covering a date rather than a period.

How long does a first SOC 2 Type 2 take?

Readiness work, plus the observation window, plus issuance. The window is typically 3 to 12 months, with 6 months a common first choice, and readiness varies widely depending on what is already in place.

Do we need all five Trust Services Criteria?

No. Security is mandatory. Add others when a customer commitment or a genuine business obligation calls for them, not pre-emptively.

Is our company too small for SOC 2?

No. The “too small” worry comes from reading criteria written for mature organizations, which is a reading problem rather than an eligibility problem. Change management on a five to ten person engineering team, where the person writing the code often deploys it, is the standard example: peer review through branch protection and automated gates is what gets examined, not a change advisory board. You do not need to imitate an enterprise. You need to show that your actual operating model is understood, controlled and credible.

About the author

Shane Troyer

Partner at Citadel Point, a licensed Canadian CPA firm in Victoria, British Columbia.

Not sure which report your buyer will accept?

Tell us what the buyer asked for and when they need it, and we will tell you plainly which path fits.

CitadelPoint

Victoria, British Columbia