A Type II report covers a window of time, and you choose it. The start date, the end date, and the length are decisions your auditor will agree with you, not ones they impose. Teams often pick them by default: start as soon as possible, end whenever the sales team needs a report.
That works, sometimes. It also produces periods too short to test the controls that matter, end dates that fall in the middle of a migration, and gaps between one report and the next that buyers ask about every year.
This article covers how long the period should be, how the frequency of your controls constrains it, where to put the end date, and how the first period sets up the ones after it.
What the observation period is
The observation period, also called the audit period or review period, is the window over which your auditor tests whether controls operated effectively. Evidence from inside the window counts. Evidence from before it does not, and a control that only started partway through has not operated across the full period.
That is the core difference from a Type I, which reports on design at a single date. SOC 2 Type I vs Type II covers how that choice drives your timeline. Here the assumption is that you have chosen Type II and need to choose its window.
How long it should be
The AICPA does not fix a required length for a Type II period. In practice, periods commonly run from three to 12 months, and your auditor will have a view on what is long enough for your controls to be tested meaningfully.
The trade-off:
| Length | What it offers | What it costs |
|---|---|---|
| Three months | The fastest route to a first Type II report | Few occurrences of quarterly and annual controls, and some buyers read a short period as limited evidence |
| Six months | A common choice for a first period, with enough time to show controls operating repeatedly | A longer wait before the first report |
| 12 months | The full annual cycle, and the length many buyers expect once a program is established | The longest wait, and every lapse across the year is in scope |
A common pattern is a shorter first period, followed by 12-month periods that run back to back. The shorter period gets a Type II report into buyers' hands sooner. The annual periods that follow give them continuous coverage.
Control frequency sets the floor
The length you can choose is constrained by how often your controls run. An auditor tests a control by looking at its occurrences during the period. If a control does not occur, it cannot be tested as operating.
List your controls by frequency and check each against the proposed window:
Continuous and daily controls, such as automated alerts and backups, occur many times in any period. They are rarely the constraint.
Per-event controls, such as change approvals and onboarding, depend on activity. A short period still usually contains enough events.
Quarterly controls, such as access reviews, occur once in a three-month period. One occurrence gives the auditor little to test, and one late review is the whole sample.
Annual controls, such as the risk assessment, policy review, penetration test, recovery test, and security awareness training, may not occur in a short period at all.
For annual controls, schedule them. If your risk assessment happens every March and your period runs from April to September, the auditor cannot test it operating within the window. Move the activity into the period, or agree with your auditor how it will be treated before you start. How auditors sample controls covers how frequency affects what gets tested.
Where to put the start date
The start date is set by readiness, not by preference. Every in-scope control needs to be designed, implemented, and producing evidence on day one.
Before you commit to a start date, confirm:
Policies are approved and in effect, with dates before the period begins.
Controls are operating, and have run at least once so you know the evidence is produced correctly.
Evidence collection is in place, so nobody is reconstructing records at fieldwork.
Gaps from your readiness work are closed, or deliberately accepted.
Starting before you are ready does not save time. It moves the problem into the report, where it becomes an exception you cannot fix. Fixing gaps before the observation period starts covers that sequence.
Where to put the end date
The end date decides when your report can be issued, and it shapes every report after it. A few considerations:
Buyer timing. If many of your renewals or procurement reviews fall at one point in the year, end the period a few months before, so buyers read a recent report.
Major changes. Avoid ending the period in the middle of a cloud migration, an identity provider replacement, or a reorganization. Changes during the period must be described, and controls that changed may need to be tested in both states.
Fieldwork capacity. The weeks after the period ends are busy for the team supporting fieldwork. Avoid putting them over a product launch or a known holiday period for your team.
Other audits. If you also hold ISO 27001 or run other assessments, align calendars so evidence requests do not collide. Running several audits on one calendar covers that planning.
The auditor's schedule. Firms have busy seasons. Agree fieldwork and report dates when you agree the period.
Planning the second period before the first ends
A common avoidable problem with Type II reports is a gap between periods. If the first period ends in June and the second starts in October, four months of operation are covered by nothing but a bridge letter, and that gap stays in your history.
Run periods back to back. When the first period ends, the next one begins the following day. Your controls do not stop, so neither should the coverage. The only gap buyers then see is the time between your latest period end and the report date, which a bridge letter covers.
If you plan to change scope, such as adding a category, do it at a period boundary. A category added mid-period has controls that did not operate for the full window.
A worked example
Say a hypothetical 50-person SaaS company finishes readiness work in January. Its enterprise renewals cluster in the fourth quarter. A sensible plan:
First period: February 1 to July 31, six months. The annual risk assessment and penetration test are scheduled for April, inside the window. Quarterly access reviews run in March and June.
Fieldwork: August, with the report agreed for delivery in September.
Second period: August 1 to July 31 of the following year, 12 months, starting the day after the first ended.
Buyers reviewing in the fourth quarter read a report covering a period that ended a few months earlier, and later periods continue without gaps. The glossary entry for the audit period covers the related terms.
How TrustLynce helps
TrustLynce's evidence collection gathers evidence on a schedule from your cloud, identity, HR, and code systems, so every occurrence of a control in the window has a timestamped record. The readiness dashboard shows which controls are ready before you commit to a start date.