# SOC 2 Type I and Type II reports Type I tests that controls were designed well at one date; Type II tests that they worked across a period. Which to do first, and how the period works. Source: https://sted.digital/docs/standards/soc-2/type-1-vs-type-2 · Last reviewed 17 October 2026 · Strand Standards and regulations A SOC 2 Type I report gives an opinion on whether your controls were suitably designed and in place at one date. A Type II report adds an opinion on whether they operated effectively throughout a period, with the auditor's tests and results. Most customers want Type II; a Type I is an optional first step. ## The requirement in plain English Both report types use the same criteria and the same system description. What differs is the question the auditor answers. ### Type I, a point in time The auditor checks that your system description is fair and that your controls, as of a stated date, were designed to meet the criteria you chose and had been put in place. They walk through each control once. Nothing shows the control kept working the next week, which is why many customers treat a Type I as a sign of progress rather than assurance. ### Type II, a period of time The auditor checks the same things and then tests whether each control operated effectively throughout the observation period. They take the whole population of events in the period (every leaver, every production change, every incident) and test a sample of it. A Type II report sets out each control, the test performed and the result, including any exceptions. The AICPA sets no minimum period. First periods are often three to six months, and renewals usually run for 12 months, each starting the day after the last one ended so that coverage has no gaps. ### Exceptions and opinions An exception is a sample that failed: for example, a leaver whose account stayed open for a month, against SOC 2 CC6.2. Your management can respond to each one in the report. An exception does not by itself change the opinion. The auditor qualifies the opinion only when the exceptions, taken together, mean a criterion was not met. Adverse opinions and disclaimers exist but are rare. ### Bridge letters Customers who receive a report months after its period ended may ask for a bridge letter: a statement from your management, not the auditor, that nothing material has changed since the period ended. This is guidance to help you understand the requirement, not legal advice. ## What good looks like An 18-person data company in Leeds has its first enterprise prospect asking for SOC 2. It spends three months getting controls running and producing records, then starts a six-month Type II period on 1 April. A Type I report as of 1 April goes to the prospect while the period runs. The Type II report covers 1 April to 30 September and arrives before the end of the year. From then on each period runs 1 October to 30 September, back to back, and the chief executive signs a bridge letter on request between reports. The calendar of recurring controls (quarterly access reviews, an annual penetration test, a yearly recovery test) is set so that every one falls inside each period at least as often as the policy says. Before each period starts, the operations lead walks the auditor through any change in tools or scope. ## Evidence an auditor expects Both report types need the system description and management's written assertion; the rest differs. - **Type I, design evidence**: approved policies and procedures, configuration screenshots or exports, and one walkthrough of each control on or near the report date. - **Type II, populations**: complete lists from the system of record for the whole period (all changes, all joiners and leavers, all incidents), so the auditor can choose a sample. - **Type II, samples**: for each sampled item, the record showing the control worked, such as an approval on a change under SOC 2 CC8.1. - **Type II, recurring controls**: every occurrence in the period: each quarterly review, each monthly check. - **Policy versions**: which version applied on which dates, if a policy changed during the period. - **Management responses**: a written response to each exception, for the report. ## Common mistakes ### Starting the clock before the controls run A period that starts the day a policy is approved catches the first weeks before anyone follows it, and those weeks become exceptions. Start the period once each control has produced at least one cycle of evidence. ### Treating Type I as the finish line A Type I report answers "did you design it?", not "does it work?". Plan the Type II period before the Type I report is signed, or the customer will ask again in six months. ### Leaving a gap between periods A renewal period that starts weeks after the last one ended leaves a stretch no report covers. A bridge letter cannot fill a long gap. Run periods back to back. ### Changing tools in the middle of a period Moving ticketing or identity systems mid-period splits the population across two systems, and the auditor needs both. Tell the auditor before you switch, and keep exports from the old system. ### Unanswered exceptions An exception with no management response reads worse than it is. Explain the cause, the fix and the date it took effect. ## How Sted helps Approving sets an effective date and a review date, which starts at the effective date plus the document's review frequency; a review task opens 30 days before the review date and turns overdue after it. Administrators and a document's owner can open superseded versions from History. Each revision records "Why this revision" and the changes; the PDF ends with a revision history of approved versions. You can set a record type to repeat (weekly to every two years) and Sted raises a task when it falls due. Nothing is scheduled until an owner picks a first due date. Only evidence from the last 12 months counts towards readiness. Sted does not choose your report type or agree your period. You settle those with your CPA firm, and your management signs any bridge letter. ## Related guides and terms - [The SOC 2 hub](/docs/standards/soc-2): how reports fit with the Trust Services Criteria. - [SOC 2 report](/docs/glossary/soc-2-report): what the report contains, section by section. - [SOC 2 evidence](/docs/standards/soc-2/evidence): populations, samples and the evidence calendar a Type II period needs. - [Working with your SOC 2 auditor](/docs/standards/soc-2/working-with-your-auditor): agreeing the period and the scope before it starts. - [Business continuity testing](/docs/guides/business-continuity-testing): scheduling the recovery test so it lands inside the period. ## Frequently asked questions Q: Can we skip Type I and go straight to Type II? A: Yes. Nothing requires a Type I first. If your controls already run and produce evidence, starting a Type II period straight away saves a report fee and gives customers the report they actually want sooner. Q: How long is a SOC 2 Type II observation period? A: The AICPA sets no minimum. Three months is a common shortest first period and 12 months is the norm for renewals. Agree the length with your auditor and check it with the customers who asked for the report. Q: What is a bridge letter? A: A letter from your management, not the auditor, that covers the time between the end of your last report period and today. It says whether anything material has changed in your system or controls. Customers accept it for a short gap, not as a substitute for the next report.