Learn · SOC Reports

Moving from SOC 2
Type 1 to Type 2

A Type 2 is not a bigger Type 1. It replaces a question about design on one date with a question about operation across a window — which means a population, a sample and dated evidence for every control, every month the window runs.

The transition is a calendar problem before it is a controls problem. Most of the elapsed time between the two reports is simply the window you choose. Almost all of the difficulty is periodic controls that have to fall inside it, and evidence discipline that has to survive the months when nobody is watching.

Talk to a Compliance Advisor Type 1 vs Type 2 Compared

3–12 motypical Type 2 observation window

1 → none artefact per control becomes a population

250+SOC 2 engagements supported by TCSA

Plain-English explainer · AT-C 205 CPA firm examination · Last reviewed August 2026

Moving from a Type 1 to a Type 2 means choosing an observation window — commonly three, six or twelve months — that usually opens at or shortly after the Type 1 as-of date, then producing complete, dated evidence that every in-scope control operated throughout it. Elapsed time to the next report is mostly the window itself, plus roughly two to five weeks of fieldwork and two to six weeks of report production. Nothing in the attestation standards requires a Type 1 first, and nothing fixes the relationship between the Type 1 date and the start of the Type 2 window — it is an engagement-planning decision made with your service auditor. For the two report types set side by side, read Type 1 vs Type 2. This page is about the move between them.

Key Takeaways

The Type 2 window most commonly opens on or the day after the Type 1 as-of date, but no standard requires that — the real constraint is the date from which every in-scope control was genuinely operating and leaving records.
A gap between the Type 1 date and the window start is a question buyers ask: two to eight weeks with a stated reason passes without comment, while six months reads as a stalled programme.
The auditor’s work changes from suitability of design as of a date to operating effectiveness throughout a period — populations, auditor-selected samples, reperformance, and a results column against every control in Section 4.
Periodic controls decide the outcome: count how many times each one operates inside the window you are about to choose, because that count is the denominator every deviation is measured against.
Elapsed time is dominated by the window you choose; fieldwork and report production are near-fixed at roughly four to eleven weeks combined.
The failure that shows up most often is an occurrence that never happened, or happened and left no record, in the quiet weeks straight after the Type 1.

The starting point

What the Type 1 actually bought you

A Type 1 examines whether the description is fairly presented and whether controls were suitably designed and implemented as of a single specified date. The honest inventory below tells you what carries into the Type 2 and what expires with the sales cycle.

What it bought

A dated, independent document

A licensed CPA firm put its name to an opinion on a specific date, when you had nothing else to send. Often enough to hold a procurement gate open.

A system description that now exists

Section 3 — the boundary, the service commitments, the system components, the complementary user entity controls (CUECs), the subservice organisations and whether they are carved out or included — is written and has survived auditor review. The Type 2 description is this document plus the changes during the period.

An independent read on design

You know your controls address the criteria you mapped them to before spending six or twelve months producing evidence against them. Finding that out at month nine is the expensive version.

A rehearsed auditor relationship

The request format, the evidence portal, the turnaround, and what this particular firm accepts as an artefact. All of it transfers into the Type 2.

Where it stops

It speaks for one day only

A control in place on 31 March and quietly abandoned on 3 April is entirely consistent with a clean Type 1. That is the engagement as designed, and it is why experienced buyers discount the document.

No populations, no samples, no reperformance

Operating effectiveness was never tested, so nothing in the report speaks to whether the machine runs. Your evidence discipline — the thing that decides how the Type 2 goes — went unexamined.

A clean Type 1 is unremarkable

Most are. Design deficiencies are usually corrected before the as-of date rather than reported, so “no exceptions” is the normal case and signals little to an experienced reviewer.

Its commercial life is short

Many vendor-risk policies accept a Type 1 once, against a dated commitment to a Type 2. Some decline it outright. It buys you a cycle; a position has to be earned with a Type 2.

Treat the Type 1 as a rehearsal that produced two durable assets — the system description and a validated control-to-criteria mapping — and treat everything else about it as expiring. In particular, do not read a clean Type 1 as a prediction. The two examinations look for different things, and only one of them can find an operating failure.

Setting the clock

When the window can start

In market practice the window opens at or shortly after the Type 1 as-of date, and most reports follow that pattern. Convention, though — what actually binds is evidential: the auditor can only test a control for the time it was in place.

Options for when the SOC 2 Type 2 observation window can start relative to the Type 1 as-of date, how buyers read each one, and when each is appropriate.
Option	What it looks like	How buyers read it	When it is right
Abutting	Window opens the day after the as-of date. As-of 31 March 2026, period 1 April – 30 September 2026.	Nothing to explain; coverage runs on from the date they already hold.	The Type 1 was clean and every in-scope control was genuinely operating on the as-of date, with weeks of records behind it.
Same day	Window opens on the as-of date itself, so the two documents interlock with no one-day seam.	Indistinguishable from abutting in practice.	Either convention is fine. Ask which one your service auditor signs, then keep it across cycles.
Short remediation gap	Two to eight weeks, used to close design observations or finish a deployment.	Rarely challenged when the reason is stated; challenged when it is unexplained.	The Type 1 surfaced real observations. Opening the window over a known-broken control converts a design fix into a printed exception.
Long gap or restart	Six months or more, usually because budget or attention moved elsewhere.	Reads as a stalled programme. Expect the question in every review.	Almost never a decision. If it has happened, lead with the new window dates and leave the history behind.
Overlapping	The window opens before the as-of date, so the Type 1 date falls inside the tested period.	Uncontroversial — a reviewer reads only the period stated in the opinion.	Controls have been running for a while and the Type 1 was a formality. The constraint is evidence: you can only claim a start date whose population you can produce in full.

Note the asymmetry. A gap costs nothing technically — the Type 2 opinion is unaffected by what preceded the window — but it costs commercially, because a reviewer holding two documents with a hole between them asks what happened in the hole. Opening the window too early costs nothing commercially and a great deal technically, because every day a control was not yet operating is a day the auditor must report on. See choosing your observation period for the length decision and how long a report stays usable for why later windows should abut.

The work changes shape

Design testing becomes operating-effectiveness testing

Both engagements are examinations performed by a licensed CPA firm under the AICPA attestation standards — AT-C section 105 and AT-C section 205, the latter restructured as an assertion-based examination by SSAE No. 21 — with the system description prepared against the description criteria in DC section 200 and the controls evaluated against the 2017 Trust Services Criteria and their revised 2022 points of focus. Only the subject matter of the opinion differs, and that one change cascades through everything.

What changes between a SOC 2 Type 1 and a Type 2 across the opinion, the auditor’s procedures, the report structure, the evidence unit and management’s assertion.
Dimension	In the Type 1	In the Type 2
What the opinion addresses	Fair presentation of the description and suitability of design, as of a specified date.	The same, plus operating effectiveness of those controls throughout a specified period.
Date language in Section 1	“as of 31 March 2026”.	“throughout the period 1 April 2026 to 30 September 2026”. Experienced reviewers scan for this phrase first.
Auditor procedures	Inquiry, observation and inspection aimed at design and implementation.	Adds tests of operating effectiveness: inspection of items the auditor selects from your populations, reperformance, and observation across the window.
Section 4 of the report	Criteria and related controls. Typically no test procedures and no operating-effectiveness results.	Every control gains a tests-performed and a results column, including any exception stated as instances out of items tested.
The evidence unit	One current artefact per control: the approved policy, the configuration screenshot, today’s user list.	A defined population for the window, plus the auditor’s sample from it. The population is the deliverable now, not the artefact.
Who chooses what is tested	Effectively you, by choosing which artefact to hand over.	The auditor, from your listing. Client-selected samples are refused, and a pre-filtered population fails at completeness.
Periodic controls	Evidenced by the documented procedure and, at most, the latest run.	Must have occurred on schedule inside the window, with dated evidence for each occurrence selected.
What a failure looks like	A design deficiency — usually corrected quietly before the as-of date.	An exception — printed in Section 4 with an instance count, and in the document for its life.
Management’s assertion	Asserts fair presentation and suitable design as of the date.	Adds that controls operated effectively throughout the period. Management makes that claim before the auditor finishes testing it.

If you take one row, take the evidence unit. In a Type 1 the question is “can you show me the control?” In a Type 2 it is “can you show me every time the control should have operated, and let me pick?” The effort profile changes with it: a sprint ending on a date becomes a continuous discipline for the length of the window, with a second crunch at fieldwork.

The assertion row deserves more than a line. Management’s Section 2 assertion that controls operated effectively throughout the period is written and signed before testing concludes, normally by an officer rather than the compliance owner. Exceptions found afterwards do not invalidate it: the assertion speaks to effectiveness against the criteria in the aggregate, and an unmodified opinion routinely sits over a Section 4 containing deviations. What does damage it is an assertion that could not have been honestly made — signed while management already knew a control had lapsed. That moves the problem out of Section 4 and into the description and the assertion themselves, which is the one category of finding that reliably costs you the opinion. It is also the whole reason the mid-window self-test in the calendar below exists: it is how you find out what you are about to assert. More in the management assertion.

Ownership

Who does what across the transition

The transition is an operating-discipline problem, which makes it a staffing question before it is a tooling one. Read the dashes as hard lines: where a column is empty, that party is barred from the step, and the independence of the opinion depends on it staying empty.

Responsibility split across the SOC 2 Type 1 to Type 2 transition between the service organisation, TCSA as readiness and coordination partner, and the licensed CPA firm.
Step	You	TCSA	CPA firm
Set the window dates	Decide. It is a commercial call about coverage and sales pressure.	Model the periodic-control overlay and count occurrences against each candidate window.	Confirms it can accept and examine the period proposed, and books fieldwork against it.
Write and maintain the system description	Own it. Section 3 is management’s document and management signs for it.	Drafts and maintains it against the DC section 200 description criteria, including changes during the period.	Evaluates whether it is fairly presented. Drafting it for you would break independence.
Sign management’s assertion	An officer signs, on behalf of management.	—	—
Operate the controls	Operate them, every day the window runs.	Runs the operating cadence: the calendar, the owners, the chase, the monthly evidence check.	—
Produce and prove the population	Run the exports from your own systems, with parameters and run dates visible.	Defines each population, reconciles it to an independent source, and tests completeness before it goes over.	Tests completeness and accuracy independently before sampling from it.
Select the sample	—	—	Selects. Sole responsibility, and the reason client-picked samples are refused.
Assemble sampled evidence	Pull each item from the source system.	Quality-checks every item against the control text before submission, so rejections happen internally.	—
Perform the tests and reperformance	—	—	Performs them, and decides whether to extend a sample when a deviation appears.
Draft Section 4 tests and results	—	—	Drafts. The wording of a test and its result is the auditor’s.
Draft management responses to exceptions	Own the response — it is printed in your name.	Drafts it with you: cause, remediation, date, and what stops a recurrence.	Prints it alongside the exception, without editing the substance.
Issue the opinion	—	—	Issues and signs it. A licensed CPA firm, and only a licensed CPA firm.

Two columns are dashes almost everywhere except one row each, and that is the shape of the thing. TCSA does readiness, control implementation, evidence operations and audit coordination; the licensed CPA firm selects, tests, drafts Section 4 and signs. A firm that designed your controls is barred from examining them, which is why auditor independence decides the org chart of a SOC 2 programme rather than merely describing it.

Evidence

What the CPA firm actually requests

The request list stops saying “send me the policy” and starts saying “send me the population.”

1. The population, and why its provenance is tested first

A population is a system-generated listing of every occurrence during the window: every joiner, every leaver, every production change, every incident ticket. The auditor will hold off sampling from it until satisfied it is complete and accurate, because it is information produced by the entity and the whole test rests on it. Expect to be asked which system produced it, who ran it, on what date, with which filters, whether the output can be edited before export, and how the record count ties to an independent source. In practice: export with the parameters, run date, logged-in user and row count visible. A tidied spreadsheet loses exactly the fields that prove provenance.

Typical populations for a Security-plus-Availability scope: joiners; leavers; privilege changes; production deployments; emergency changes; firewall and infrastructure changes; incidents and their tickets; alerts triaged; vulnerability scans and remediation records; backup jobs and restore tests; access reviews performed; vendor reviews performed. Few of these were requested in your Type 1, and none of them had to be complete across a period.

2. The sample, and who picks it

The auditor selects. Sample sizes are a matter of professional judgement — the AICPA publishes no mandatory table for SOC examinations — but most firms anchor to a familiar frequency convention worth planning against. As market practice, expect roughly one item for an annual control, two for quarterly, two to five for monthly, five to fifteen for weekly, twenty to twenty-five for daily, and twenty-five to forty for controls operating many times a day or event-driven controls with large populations. Where the population is smaller than the sample size, the auditor tests all of it — which is why the twelve joiners and five leavers in the worked calendar below are all tested, while twenty-five changes are drawn from two hundred and fourteen. Some automated controls can be tested once alongside evidence that the configuration did not change. More in sampling and sample sizes.

A deviation is not automatically a qualified opinion. The auditor evaluates what it means for the criterion, may extend the sample, and where the criterion is still met describes the exception in Section 4 as instances out of items tested. How those read to a buyer is covered in opinions and exceptions.

3. What a good artefact looks like

For a sampled termination: the HR record showing the last working day, the deprovisioning action with its timestamp, and the arithmetic between them visible without explanation. For a sampled change: the ticket, an approver who is distinct from the requester, test evidence, timestamps in the right order. For a sampled access review: the export the reviewer worked from, their decisions, the date, and the tickets that actioned removals. The test each item has to pass is whether it shows the control described in Section 3 operating on that specific item, with the dates and the actors legible.

4. What gets rejected

Undated screenshots, or screenshots cropped so the URL, the logged-in user or the system clock is hidden.

Evidence created after the auditor asked for it — the Q2 access review performed in October.

A policy where a record was requested. The policy says what should happen; the test is whether it did.

A Slack thread standing in for an approval when the control says the approval sits in the ticketing system.

A hand-typed spreadsheet with no tie back to a source system, or an export with the parameters and run date cropped out.

A population you filtered before sending. Completeness is tested before sampling, so this fails a step earlier than you think.

Samples you selected yourself, however fairly. Selection is the auditor’s procedure.

Evidence dated outside the window, offered for a control that was meant to operate inside it.

One rule sits under all of it: evidence must have existed when the control operated. Performing the missed quarterly review in month eleven is a real improvement, but it does not repair month four. The auditor records an exception for the occurrence that did not happen; disclosed early, management’s response can say exactly what you did about it. Disclosed late, it costs more than the exception.

5. What all of that turns into: one Section 4 row

The output of the population, the selection and the sampled evidence is a single row in Section 4 of the report, printed for the life of the document. Below is an illustrative specimen written to match the worked calendar in the next section — an invented control for an invented company, wired to the same numbers, rather than an extract from any client report. Reading one in this shape before fieldwork is the cheapest way to understand what your evidence is being turned into.

Illustrative specimen · Section 4 · Tests of controls and results

Control, as it appears in Section 3

CHG-02 — Production changes are recorded in the change-tracking system and approved by an individual other than the requester before deployment.

Criteria mapped

CC8.1

Test performed by the service auditor

Inspected a selection of 25 production changes from a population of 214 changes deployed during the period for evidence of approval by an individual other than the requester, completed test evidence, and deployment timestamps in sequence.

Result of test

Exceptions noted. For 3 of the 25 changes selected, the recorded approver was the same individual who raised the change.

Management response

Management identified the three changes as low-risk configuration updates deployed during a release freeze. The pipeline approval gate was reconfigured on 12 August 2026 to block self-approval at the system level, and a monthly reconciliation of deployments to approval records was introduced from September 2026.

Three things to notice. The test names the population and the selection size, so a reader can compute the deviation rate themselves. The result is stated as instances out of items tested, which is why a three-month window with one quarterly occurrence is such an unforgiving denominator. And the management response carries a cause, a dated fix and a preventive measure — which is the only part of that row you get to write. Section 4 rows in this shape are what an experienced reviewer reads first.

The periodic controls

Free in a Type 1, decisive in a Type 2

Read the two count columns as the planning question they really are: how many times does this control operate inside the window I am about to choose?

Periodic SOC 2 controls by cadence, the trust services criteria they map to, how many times each operates in a three-month and a twelve-month observation window, and the evidence the service auditor expects for each occurrence.
Control	Criteria	In 3 months	In 12 months	What the auditor wants
User access reviewQuarterly	CC6.1 – CC6.3	1	4	The export the reviewer worked from, the date, the decisions, and evidence that identified revocations were actioned. A review with no follow-through is an exception even though the review happened.
Risk assessmentAnnual, plus on change	CC3.1 – CC3.4	0 – 1	1	The assessment, the approval date, the participants, and a traceable line from each risk to a treatment decision. CC3.4 also expects changes affecting internal control to be identified and assessed.
Recovery testTypically annual	A1.3	0 – 1	1	Plan tested, date, systems in scope, participants, results against your stated recovery objectives, issues log. The test run must match the test the control describes: a control that promises failover is evidenced by a failover, and a tabletop evidences a tabletop.
Vendor and subservice reviewAnnual per tier	CC9.2	0 – 1	1 per vendor	Evidence you obtained the vendor’s current report, read it, and recorded a conclusion — including the CUECs it assigns to you. A dated memo naming the reviewer and the conclusion is what gets tested; a folder of downloaded PDFs leaves nothing to test.
Policy review and approvalAnnual	CC1.x, CC2.x, CC5.3	0 – 1	1	An approval record with a date and a named approver. A document header reading “reviewed annually” evidences an intention.
Security awareness trainingAnnual, plus on hire	CC1.4, CC2.2	On-hire items only	Full population	A completion report that reconciles to the roster of people employed during the window, with dates inside the required interval. Reconciliation is where this one usually fails.
Change managementEvent-driven	CC8.1	Every change	Every change	A complete listing of production changes with ticket identifiers; for each sampled change, an approver distinct from the requester, test evidence, and timestamps in the right order. Emergency changes are usually sampled separately.

A quarterly control operates once inside a three-month window. If that single occurrence is late, incomplete, or performed but never evidenced, the deviation rate is 100% — and Section 4 says so.

Annual controls create the mirror problem: in a short window they may not operate at all. Practice varies on what happens then — some firms test the most recent occurrence preceding the window and disclose the date tested, others report that the control did not operate during the period. Neither is as good as choosing a window the control falls inside. So before fixing the window, lay your periodic calendar over it: risk assessment, recovery test, penetration test, policy approvals, vendor reviews, training renewals. If three cluster outside it, move the window or move the cluster. Recovery testing is the usual casualty, which is why we treat it as a scheduling decision in DR testing for SOC 2. High-frequency controls such as anomaly review under CC7.2 attract the largest samples but are the easiest to survive when tooling records everything for you.

Worked calendar

One transition, month by month

An illustrative scenario built for this page, with no client behind it: a forty-person B2B SaaS platform with Security, Availability and Confidentiality in scope. A February readiness assessment raised two design observations — a formal offboarding checklist and a documented approval gate in the deployment pipeline — and both were built, approved and operating during March, before the as-of date. The Type 1 as of 31 March 2026 therefore carried no observations, and the report was issued 24 April. The window abuts it: 1 April to 30 September 2026.

Had either observation still been open on 31 March, abutting would have been the wrong choice: the right move is the short remediation gap from the table above, opening the window on the first date both controls were genuinely live. Opening over a control you know to be broken converts a design fix you could have made quietly into an exception printed with an instance count.

Apr 2026

Window opens 1 Apr

Both design observations were live and operating before the as-of date, so the window abuts cleanly with nothing outstanding to print. Q2 access review performed 15 April against a 31 March export; two revocations identified and raised as tickets the same day.

May 2026

Third parties

Reviews completed for the four critical subservice organisations: current reports obtained, read, and their CUECs recorded against an owner. One vendor report ends 30 June, so its bridge letter is requested now to cover July to September. Monthly restore test executed and logged.

Jun 2026

Risk and testing

Annual risk assessment refreshed and approved 12 June. External penetration test 22–26 June, findings triaged the same week so the retest lands inside the window.

Jul 2026

Recovery test

Failover test 18 July against the documented recovery objectives, with participants, timings and an issues log. Q3 access review 15 July. The failover test is a single-occurrence control in this window, so a miss cannot be recovered. The access review is the second of exactly two occurrences — 15 April and 15 July — so a miss there is a 50% deviation rate.

Aug 2026

Mid-window self-test

Pull your own populations for April to July and sample them as the auditor would. This is where teams find the access review that was genuinely performed but never evidenced, and the changes a single engineer both raised and approved. Here it surfaced the second, on the very control the Type 1 had judged suitably designed on 31 March: the approval gate was documented and required, and it still got bypassed. Design was never the problem, which is precisely what a Type 1 cannot tell you. The gate was reconfigured on 12 August to block self-approval at the system level, though the earlier instances stay in the population and in the sample frame.

Sep 2026

Window closes 30 Sep

Remaining periodic items completed, evidence frozen, population exports prepared with parameters and run dates visible. Nothing about the window improves after this date.

Oct 2026

Fieldwork

Populations delivered 5 October: 214 production changes, 6 emergency changes, 12 joiners, 5 leavers, 1,098 backup jobs across six systems, 26 vulnerability scans, 3 incidents, 2 access reviews, 4 vendor reviews. Selections returned 9 October: 25 changes, all 6 emergency changes, all 12 joiners and all 5 leavers because both populations sit below the sample size, 25 backup jobs, 8 scans, and every access review, vendor review and incident. Sampled evidence supplied over three weeks.

Nov 2026

What came back

Two exceptions, both raised in the closing meeting rather than in the draft. One of the five terminations was deprovisioned on day four against a stated one-business-day commitment (CC6.2). Three of the twenty-five changes selected carried an approver who was also the requester (CC8.1). Opinion unmodified; a management response was filed against each, and the specimen row above is the second one.

Nov 2026

Report issued

Draft reviewed, management responses finalised, the firm completes its engagement quality review, report issued around 13 November.

Oct 2026 →

Next window running

The second period opened 1 October 2026 and runs to 30 September 2027 — before the first report was even issued. Consecutive windows abut, so no month is left uncovered.

Elapsed time from the Type 1 as-of date to a Type 2 report in hand: about seven and a half months, six of which were the window. Fieldwork and reporting are near-fixed — two to five weeks of testing, then two to six weeks of drafting, management responses and the firm’s quality review — so the only lever that moves the date much is window length. A three-month window lands the report roughly four and a half to five and a half months after it opens; six months lands at about seven and a half to eight and a half, as here; twelve months lands at about fourteen. Readiness time beforehand is close to zero straight after a Type 1, which is the strongest argument for moving on rather than pausing.

On cost: TCSA prices readiness, control implementation, evidence operations and audit coordination at a fixed fee from $4,000 for early-stage startups, quoted after scoping. The CPA firm’s attestation fee is separate and billed by the firm — we coordinate the examination, we never perform or sign it.

The interval

What to tell customers while the window runs

For six or twelve months you hold a report buyers consider weak and promise one they cannot see. Two things do the work: a document you can send today, and a clause they can sign against.

Lead with dates

“Our Type 1 is as of 31 March 2026. The Type 2 observation period runs 1 April to 30 September 2026 and we expect the report in November.” Dates survive being pasted into a vendor-risk tracker, and they set an expectation you can be held to. Adjectives like “SOC 2 compliant” invite a correction later, usually in front of the person who repeated them internally.

Share the report itself, under NDA

The Type 1 in full, with an offer to walk through Section 1 and Section 3. A logo, a one-page summary or a compliance-dashboard screenshot offered in its place signals that the document says something you would rather keep back.

The management status letter, element by element

A bridge letter conventionally covers the interval after a Type 2 period ends, asserting nothing material has changed since. After a Type 1 there is no tested period to bridge from, so what you issue instead is a status letter: the same instrument, honestly labelled. Five elements, and the fifth is the one that keeps it defensible.

The date and the signatory: an officer of the company signing on behalf of management, rather than the security lead or the compliance owner.

The observation window: start and end dates, written exactly as they will appear in the opinion, so the letter and the eventual report agree.

The scope: the trust services categories being examined and the system the description covers.

The service auditor: the licensed CPA firm by name, that the examination is under way, and the expected report date.

The limitation, in plain words: this is management’s own statement, it conveys no assurance, and no CPA procedures have been performed over it.

What the letter must avoid asserting is anything about operating effectiveness — that no control has failed, that the environment is secure, that the examination is going well. Management can state facts about scope and schedule. Any claim about how the controls are performing during a period the CPA firm is still testing is a claim you may have to withdraw when Section 4 is drafted. Related: bridge letters.

The clause a buyer will accept in place of a report

Where a customer’s policy requires a Type 2, ask for conditional acceptance: sign now against a contractual commitment, supported meanwhile by the Type 1, a completed security questionnaire and your penetration test summary. The commitment that gets accepted has a shape.

“Vendor shall deliver a SOC 2 Type 2 report prepared by a licensed CPA firm covering a period of not less than six months ending no later than [date], within sixty days of the end of that period.”

Four elements: a licensed CPA firm, a minimum period length, a period end date, and a delivery tail. The tail is the part buyers routinely forget to specify and the part vendors should volunteer, because a clause that says “deliver a Type 2 report by 30 September” is breached by a two-week drafting delay you do not control, while “covering a period ending no later than 30 September, delivered within sixty days of period end” is a promise you can actually keep. Sixty days is generous enough to absorb a normal reporting cycle and tight enough that a buyer reads it as a commitment rather than an escape.

Longer treatment in what to tell customers while your SOC 2 is in progress and SOC 2 for enterprise sales.

Edge cases

Where this gets contested

The clean path is well documented. These generate the real questions — and the answer is often “agree it with your service auditor before the window opens; fieldwork is too late.”

A control goes live part-way through the window

The auditor can only test it from its implementation date. Depending on the firm and the criterion, the report either describes the control as implemented on a stated date with testing from that point, or records an exception for the earlier part of the period. If a control cannot be live on day one, move the start date.

Adding trust services categories at the same time

Upgrading a Security-only Type 1 into a Security, Availability and Confidentiality Type 2 is sensible — but the added criteria apply for the whole window, periodic controls included. A1.3 recovery testing is the usual casualty. Add categories at the start of a window, never mid-way.

Your subservice organisation’s report does not cover your window

Under the carve-out method the subservice organisation’s own controls sit outside your description and outside the opinion — but your monitoring of that organisation stays firmly inside both. You are tested on obtaining their current report, evaluating it, tracking the CUECs it assigns you against named owners, and covering any interval their period fails to reach, usually with their bridge letter. Where their period ends mid-way through yours, that gap belongs to you to evidence. This is a common late surprise, because vendor report cycles are set by the vendor. Under the inclusive method the subservice organisation’s controls are described and tested alongside yours, which changes the evidence load materially and needs their agreement long before fieldwork.

Changing CPA firm between the two reports

Permitted; there is no continuity requirement. Expect the incoming firm to run its own risk assessment, form its own view of your description and mapping, and place no reliance on the predecessor’s design conclusion. Where independence forces the change — a firm that built your controls cannot examine them — it is not optional.

The system boundary moves inside the window

A migration, a new region or a newly launched product means evidencing two control environments rather than one, and the description must disclose significant changes during the period. Where the change is large enough that the description would cover two different companies, closing the window early and opening a clean one is usually cheaper.

A security incident during the window

Not automatically an exception. What is tested is whether the controls described — detection, response, communication — operated. The description criteria require disclosure of identified system incidents that resulted from controls not being suitably designed or not operating effectively, or that otherwise caused a significant failure to achieve your service commitments and system requirements. Concealment therefore converts a control question into a description question, which is far worse.

Windows shorter than three months

Nothing in the attestation standards fixes a minimum period. Three months is the shortest commonly seen, and many firms decline anything shorter: a period too short for periodic controls to operate leaves the opinion resting almost entirely on high-frequency automated controls.

Objection handling

What buyers push back on during the transition

“Your Type 1 is dated March and the Type 2 window starts in July. What happened in between?”

Name the cause and give two dates: “we closed two design observations and finished rolling out centralised logging; the window opened 1 July, closes 31 December, report expected mid-February.” A reason plus dates ends the conversation. “We were getting ready” extends it.

“Why is your first Type 2 only three months?”

Because it is the first, and continuous coverage beat a longer first window — then say what follows, with dates: a twelve-month second period beginning the day after this one closes. A short window that is visibly the first rung reads very differently from one offered as the destination.

“Your Type 1 had no exceptions and the Type 2 has five. Did things get worse?”

No. A Type 1 cannot produce operating exceptions because operating effectiveness goes untested in one; the comparison that carries information is Type 2 to Type 2. Walk them through each exception, its instance count, the criterion affected and the management response.

“Send us your SOC 2 certificate.”

There is no such thing. SOC 2 is an attestation examination by a licensed CPA firm, and the deliverable is a report restricted by its own terms to specified parties, which service organisations typically also release under NDA. Send the report and offer to walk through Section 1 and Section 4; use SOC 3 if what they need is public-facing.

“Does the report cover the period we have been a customer?”

Answer with the window dates, then say what covers the interval either side. If they onboarded before the window opened, say so and offer the Type 1 for the earlier date rather than implying coverage the opinion does not give. Reviewers forgive gaps they can see.

Three mistakes produce most of these questions: treating the Type 1 as the finish line rather than the first milestone; letting evidence discipline lapse in the weeks after it, when the auditor has gone quiet; and choosing a short window to reach the market quickly without checking which periodic controls fall inside it. The first two are cultural, the third is arithmetic — and the arithmetic ends up printed in Section 4. More in common SOC 2 pitfalls.

Frequently Asked Questions

Do I need a SOC 2 Type 1 before a Type 2?

No. Nothing in the AICPA attestation standards requires a Type 1 first, and many organisations go straight to a Type 2. A Type 1 earns its cost in two situations: a live sales cycle needs a dated, independent document now, or you want an independent read on control design before committing to a six- or twelve-month window. Outside those, it buys a document with a short commercial life that most enterprise buyers accept exactly once.

When should the Type 2 observation period start after a Type 1?

Most commonly on, or the day after, the Type 1 as-of date, so coverage runs on from a date the buyer already holds. That is convention rather than requirement. The binding constraint is evidential: the auditor can only test a control for the period it was in place, so the window should open on the first date from which every in-scope control was genuinely operating and producing records. If the Type 1 raised design observations, close them first and take a short, explainable gap.

Is a gap between the Type 1 date and the Type 2 window a problem?

Technically no — the Type 2 opinion covers only its stated period and is unaffected by what came before. Commercially it is a question you will be asked, because a reviewer holding two documents with an interval between them wants to know what happened in it. Two to eight weeks with a stated reason passes without comment. Six months or more reads as a stalled programme, and the fix is to lead with the new window dates rather than the history.

How long should the first Type 2 window be?

Three, six and twelve months are all common and all legitimate. Decide by counting occurrences rather than by preference: lay your periodic controls over the candidate window and count how many times each operates inside it. Three months gives a quarterly control one instance and may give an annual control none. Six months is the usual compromise while periodic controls bed in; three is defensible when you also commit to a twelve-month second window beginning the day after it closes.

How long does the whole transition take?

The window, plus roughly two to five weeks of fieldwork, plus two to six weeks of report production — drafting, management responses to any exceptions, and the firm’s engagement quality review. The worked calendar above traces a six-month window end to end and lands the report about seven and a half months after the Type 1 as-of date, with the spreads for three- and twelve-month windows given alongside it. Readiness time beforehand is close to zero straight after a Type 1.

What actually changes in the auditor’s work?

The subject matter of the opinion. A Type 1 addresses whether the description is fairly presented and whether controls were suitably designed as of a date; a Type 2 adds whether those controls operated effectively throughout a period. That brings populations, auditor-selected samples and reperformance, and adds tests-performed and results columns to every control in Section 4. Your side changes from producing an artefact per control to producing a complete, provable population per control.

Who signs management’s assertion, and what happens if exceptions turn up after it?

An officer signs it on behalf of management, normally the CEO or CFO rather than the compliance owner, and it is signed before testing concludes. Exceptions found afterwards do not invalidate it: the assertion addresses effectiveness against the criteria in the aggregate, and unmodified opinions routinely sit over a Section 4 containing deviations. The dangerous case is an assertion that could not have been honestly made — signed while management knew a control had lapsed. That becomes a description and assertion problem rather than a control exception, and it is the category that damages an opinion.

Do we have to use the same CPA firm for the Type 2?

No — there is no continuity requirement, and firms change between reports routinely. Expect the incoming firm to run its own risk assessment, form its own view of your description and control mapping, and place no reliance on the predecessor’s design conclusion, so budget time in the first weeks. Independence can also force the change: a firm that designed your controls cannot then examine them, which is why readiness work and the examination sit with different organisations.

Can a bridge letter cover the gap between our Type 1 and our Type 2?

Not really. A bridge letter is a management statement conventionally used to cover the interval after a Type 2 period ends, asserting nothing material has changed since; it carries no audit assurance because the CPA firm performs no procedures on the gap. After a Type 1 there is no tested period to bridge from. What works instead is a dated management status letter naming the observation window, the categories in scope, the service auditor and the expected report date, with an explicit line that it conveys no assurance — the five-element skeleton set out above.

Why does our first Type 2 have exceptions when the Type 1 had none?

Because a Type 1 cannot produce operating exceptions — operating effectiveness goes untested in one, so a clean Type 1 is the normal case rather than a distinction. A first Type 2 commonly surfaces a handful, most often a periodic control performed late or performed but never evidenced, and deprovisioning that missed a stated timeframe. Exceptions described with instance counts and answered with a specific management response sit comfortably under an unmodified opinion; unexplained ones are what cost deals.

Written By Expert Auditors

Surendra Pal Singh

Chief Information Security Officer & Data Protection Officer

CISODPOCISAMCSEITILISO 27001 Lead AuditorISO 27701 Lead AuditorISO 42001 Lead Auditor

Saundhi Chauhan

Lead Auditor

ISO 27001 Lead AuditorISO 27701 Lead Auditor

Last reviewed: August 2026•Content verified by certified lead auditors

Keep Exploring

Get in touch

Book a free consultation or send us your requirements. We respond within 24 hours.

Quick Call

Pick a time slot

Send Requirements

Get a custom quote in 24 hours

We're Online

Moving from SOC 2Type 1 to Type 2