SOC 2 Type 1 and Type 2: one date, one period, and a deadline already given

A Type 1 opinion speaks about one date. A Type 2 opinion speaks about a stretch of time that has already closed by the time anyone can read the report. Almost everything expensive about the choice follows from that second sentence, and most of it is a scheduling problem rather than a security one.

The distinction is set out in the AICPA's description criteria, DC section 200, which govern what management writes and what the service auditor evaluates it against. Footnote 5 states it directly:

"There are two types of SOC 2 examinations (type 1 and type 2), and the subject matters vary depending on which type of examination the service auditor performs. The subject matters of a type 1 examination are (a) the description and (b) the suitability of the design of the controls … The subject matters in a type 2 examination are (a) the description, (b) the suitability of design of the controls … and (c) the operating effectiveness of controls to provide reasonable assurance that the service organization's service commitments and system requirements were achieved based on the applicable trust services criteria."

	Type 1	Type 2
Subject matters	The description; the suitability of design of the controls	The description; the suitability of design of the controls; the operating effectiveness of the controls
What the opinion attaches to	the date of the description	the period of time covered by the description
System incidents the description must disclose (DC4)	"as of the date of the description (for a type 1)"	"during the period of time covered by the description (for a type 2)"

Design and operation are separate questions, and DC section 200 .03 keeps them separate in the opinion itself. The service auditor expresses a view on whether controls "were suitably designed to provide reasonable assurance that the service organization's service commitments and system requirements would be achieved if controls operated effectively based on the applicable trust services criteria" — and then, in a type 2 examination, on whether they "operated effectively". A Type 1 answers the conditional. A Type 2 answers the condition.

The report is dated after the period, and that is the whole problem

AT-C section 205 lists what a practitioner's report must contain. Paragraph .63c requires

"An identification or description of the subject matter or assertion being reported on, including the point in time or period of time to which the measurement or evaluation of the subject matter or assertion relates."

So the period is printed on the report, and it is the first thing a competent vendor-risk reviewer reads. Two further requirements show that the standards assume a gap between the end of that period and the date of the report, and put work into it. Paragraph .49 requires the practitioner to inquire about

"any events subsequent to the period (or point in time) covered by the assertion-based examination engagement up to the date of the practitioner's report that could have a significant effect on the subject matter or assertion."

And the written representations under .51c must cover communications received "between the end of the period addressed in the written assertion and the date of the practitioner's report".

Work backwards from that and the calendar assembles itself. A report in a customer's hands by a given date needs a period that closed before it, fieldwork after the period closed, and a report dated after the fieldwork. The period itself cannot begin before the controls are operating, because operating effectiveness is opined on across the whole of it. So the honest answer to "how quickly can we get a Type 2" is a question about when your controls started running, not about how quickly an auditor can be booked.

A Type 1 sits on a shorter horizon for exactly this reason: its subject matter is design at a date, so the date can be recent. It answers a different question, and a customer whose process asks for evidence of operation over a period will read the Type 1 and ask again.

The length of the period is decided by how often your controls run

The period is management's to choose and management's to stand behind. AT-C 205 .10 requires the service auditor to request a written assertion from the responsible party, and paragraph .A9 closes the obvious escape:

"Situations may arise in which the current responsible party was not present during some or all of the period covered by the practitioner's report. Such persons may contend that they are not in a position to provide a written assertion that covers the entire period … This fact, however, does not diminish such persons' responsibilities for the subject matter as a whole. Accordingly, the requirement for the practitioner to request a written assertion from the responsible party that covers the entire relevant period or periods still applies."

What makes a chosen period useful is the cadence of the controls inside it. Operating effectiveness is concluded from evidence of a control operating within the period, so a control that runs quarterly produces one instance a quarter and a control that runs on every change produces as many instances as there were changes. Pick a window shorter than the cadence of your slowest in-scope control and the report will have very little to say about that control — which a reader who counts the tests will notice.

Two consequences worth carrying into a planning conversation. Set the window against your own control calendar rather than against a number someone quoted you. And start the clock when the controls are actually running, because the opinion covers the period from its first day, not from the day the evidence became tidy.

A period is a claim about every day in it

The difference between a date and a period is not arithmetic. It changes what the description has to admit.

DC4 requires the description to disclose identified system incidents that "were the result of controls that were not suitably designed or operating effectively" or that "otherwise resulted in a significant failure in the achievement of one or more of those service commitments and system requirements" — for a type 2, "during the period of time covered by the description" — with three things about each: "a. Nature of each incident · b. Timing surrounding the incident · c. Extent (or effect) of the incident and its disposition."

DC9 requires, in a description covering a period, "the relevant details of significant changes to the service organization's system and controls during that period that are relevant to the service organization's service commitments and system requirements". Its implementation guidance sets the expectation: disclosure "is expected to include an appropriate level of detail, such as the date the changes occurred and how the system differed before and after the changes". Its listed examples include "Changes to the services provided", "Significant changes to IT and security personnel", and significant changes to system processes, IT architecture and applications, and to the processes and system used by subservice organisations.

A control that lapsed in month two of a twelve-month period does not become invisible by month twelve. A change of infrastructure, or of the people running it, arrives in the report with a date attached. And where the service auditor concludes, on the evidence obtained, that the subject matter is not in accordance with the criteria in all material respects — and, in the practitioner's professional judgment, the effect of the matter is or may be material — AT-C 205 .70 requires the opinion to be modified, and .71 requires "a separate paragraph in the practitioner's report that provides a description of the matter giving rise to the modification". Paragraph .72 sets out when that modification is a qualified opinion.

That is the operational point. A Type 2 period is evidence collected as it runs, not assembled at the end. Ticket histories, review records, access approvals and change records are produced by the controls themselves while the window is open, and a month with none of them is a month the description has to account for. That has consequences for what you retain, and for when you start retaining it.

"In progress" names activity. A report names a period

The phrase carries no period, and the period is what a reader needs. Until one has been chosen, run to its close and opined on by a licensed CPA firm, there is no date range on any report for a customer to check and nothing on which a service auditor has expressed a view. Security Brigade's own SOC 2 Type II is in progress, and that sentence is worth exactly what the same sentence is worth from any supplier: it describes activity.

A supplier who tells you their SOC 2 is in progress is answering a different question from the one a Type 2 report answers. The useful follow-up is not when it will be finished — it is which type, which trust services categories under TSP section 100, and what period the report will name.

Which one to buy

Ask the customer who asked you. "SOC 2" alone underspecifies the request in three ways at once: type, categories, and period. A procurement questionnaire that says Type 2 and says nothing about the period is asking for something whose cost and timing you cannot yet estimate.

Then settle who does what. The opinion is signed by the licensed CPA firm you engage as service auditor, and independence under the AICPA Code — ET section 1.295, on nonattest services — governs what that firm may have done for you beforehand. The preparation is a separate engagement with a separate supplier: control design, the evidence retention that makes a period survivable, and readiness against the applicable criteria. That is the side of the line Security Brigade works on, and who issues what, in an ISO 27001 or SOC 2 programme sets out the parties in both schemes. For what the finished report actually contains, and why no party to it produces a certificate, see why "SOC 2 certified" is a phrase that cannot be true.

Every paragraph number, quotation and date above was checked against published text on 27 August 2026.