Direct answer: The observation window is the period your report covers, and every control in scope has to operate and produce dated evidence across all of it. Choose the start date after your controls are genuinely live, not before, because a control turned on in month two leaves month one exposed and the usual remedy is to move the window, which moves your report date by months. Inside the window, the job is unglamorous: run the cadence, file the evidence as it is produced, and record any change to the environment while you still remember it.
Choosing the start date
The window start is the highest-leverage decision in a Type II, and it gets made carelessly more often than any other. The temptation is to start it as early as possible because the report date is what the deal is waiting on. The problem is that the auditor will sample across the whole period, and a control that was not operating in the first six weeks produces an exception no matter how well it ran afterwards.
The right test is simple. For every control in scope, can you point to it operating and producing evidence today, in a way you could hand over? If the answer is no for even a handful, the window has not started yet, whatever the calendar says.
Three months is the usual minimum for a first Type II and is what most buyers will accept when they are asking for a report urgently. Six or twelve months is more common for a second cycle. Longer windows are not harder to pass, but they are harder to stay disciplined through.
What has to happen every month
Access reviews are the control most likely to be sampled and the one most likely to be missing. If you said quarterly, do it quarterly, on a date, with a record naming who reviewed what and what changed as a result. A screenshot of a user list is not a review. The review is the decision.
Onboarding and offboarding evidence has to be produced at the time. Reconstructing a departure six months later means asking somebody to remember when access was actually revoked, and the honest answer is often uncomfortable.
Change management evidence accumulates automatically if your process runs through pull requests with approvals, and not at all if changes are pushed straight to production by whoever is on. This is the control where a small process change early in the window saves an enormous amount of argument later.
Vulnerability scanning and the triage that follows it. The scan is easy. The evidence auditors want is what happened to the findings, with dates.
Monitoring and alerting evidence, meaning that alerts fired, somebody saw them, and something happened. An alerting system nobody responds to is worse than none, because now you have a record of ignored alerts.
The quarterly and annual items inside the window
Depending on window length, some of these fall inside and some do not, which is worth mapping at the start rather than discovering in month eleven.
Vendor reviews, security awareness training, risk assessment refresh, policy review and re-approval, backup restore testing, and a penetration test if your criteria or your customer commitments include one. Each has to have happened inside the period, not before it and not after.
What breaks a window
A control turned on late. The most common one, and the reason the start date matters so much.
An environment change nobody recorded. You migrate a database, adopt a new identity provider, or spin up a second cloud account, and the system description now describes something that is not true. Auditors find this by walking the environment, and the conversation goes badly because the description is your own representation.
A gap in the middle. Someone leaves, the person who ran the access reviews is gone, and two quarters pass. This is invisible until fieldwork and cannot be repaired retroactively.
Evidence that exists but cannot be produced. The review happened in a Slack thread. The approval was verbal. The scan ran but the report was never saved. The control operated and you cannot prove it, which for audit purposes is close to the same as it not operating.
Scope changes mid-window
Business does not stop for an observation period. You will ship a new product, add a subprocessor, or bring a second environment into production. None of that ruins a window on its own, but each one needs a decision recorded: is this in scope, does it inherit the existing controls, and does the system description need updating.
Making that decision at the time takes ten minutes. Making it during fieldwork takes a week and a negotiation, because now the auditor is deciding whether your report can cover something the description never mentioned.
The last month before fieldwork
The window closes and the audit begins, and the gap between them is where a well-run programme shows its value. If the evidence has been filed as it was produced, this month is a review: check every control has coverage across the whole period, close the obvious gaps in the record, and prepare the walkthrough.
If it has not, this month is a scramble, and scrambles produce the two worst outcomes in an audit. Either you hand over evidence that does not support the control, which becomes an exception, or you delay fieldwork, which moves the report date you were trying to protect.
The part nobody enjoys
Nothing about operating a window is intellectually difficult. It is a cadence, held for a period, by somebody who cares whether it happens. That is precisely why it fails: it is nobody's most interesting work, and it competes with shipping.
Companies solve that three ways. Someone internal owns it explicitly, with the time protected. A platform automates the technical evidence, which genuinely helps for the subset it covers and does nothing for access reviews, vendor reviews or training. Or the cadence is operated by a firm on retainer, which is the same work with somebody else's calendar attached to it. What does not work is assuming it will happen because everyone agrees it should.
How the auditor actually samples the period
Most teams operate a window without knowing how the evidence will be pulled, which is why the request list feels arbitrary when it arrives. For a control that runs on an event, such as onboarding or a production change, the auditor asks you for the complete population of events in the period and then selects from it. For a control that runs on a cadence, such as a quarterly access review, the population is the number of times it should have run, and the sample is often all of them, because four occurrences do not need sampling. Frequency drives sample size in a fairly predictable way: a daily control might be tested on twenty to forty occurrences, a weekly one on five to eight, a monthly one on two to five, and a quarterly or annual one on every instance.
The practical consequence is that a control you set at a high frequency to look diligent will be tested far more often than one you set honestly. A team that writes "we review access weekly" because it sounds better than quarterly has just signed up for a population of roughly fifty reviews, each of which needs a record. Set the frequency you will actually hold, then hold it.
Completeness of populations, and why it sinks good programmes
The moment that catches most first-time teams is not the sample itself. It is the auditor asking how they know your population is complete. If you hand over a spreadsheet listing twelve leavers in the period, the reasonable next question is where that list came from and whether anything could be missing from it. A list typed by a person satisfies nobody. A list exported from the HR system, with the export parameters and the date visible, satisfies most auditors, because the system of record is the source and the export is reproducible.
The same logic applies to change management. A screenshot of merged pull requests is weaker than a query against the repository covering the whole period, filtered on the branch that deploys to production. If your deployment path allows changes that never touch that branch, hotfixes applied by hand during an incident being the common case, the population is incomplete and you would rather say so yourself than have it found. Auditors call this information produced by the entity, and the scrutiny of it has increased sharply over the last few years. Assume every list, report and export you provide will be challenged on where it came from and whether it can be regenerated.
What to do when you find a gap in month seven
Somebody notices in July that the Q1 access review never happened, or that the vulnerability scans stopped when the account they ran under was disabled in March. The instinct is to fix it quietly and hope the sample misses it. That instinct is wrong for two reasons: the population will show the gap anyway, and an undisclosed gap turns a control deficiency into a question about management integrity, which is a far worse conversation.
The correct move is to document the gap the day you find it. Record when the control stopped operating, how it was detected, what the exposure was during the lapse, what compensating evidence exists, and what changed so it cannot recur. Then perform the missed activity now, clearly dated as a catch-up rather than backdated, and tell your auditor before fieldwork. A disclosed lapse with a root cause and a fix frequently lands as a single exception with a clean management response. The same lapse discovered during fieldwork, with no analysis attached, tends to spread, because now the auditor is testing whether anything else was left unattended.
Exceptions are survivable, surprises are not
A qualified report is not the end of a sales cycle. Security reviewers read the exceptions section and ask three things: was the deficiency in a control that matters to them, did it affect production data, and did management fix it. An exception in a control over developer laptop encryption reads very differently to an exception in production access revocation. Most buyers will accept the former with a sentence of context and will pause on the latter.
Your leverage is the management response written into the report. That is your text, not the auditor's, and it is worth more attention than it usually gets. A weak response restates the finding. A strong one gives the specific cause, the specific change made, the date it took effect, and what now detects a recurrence. Write it as though the person reading it is a security reviewer trying to decide whether to escalate to their legal team, because that is who reads it.
Subservice organisations and the controls you do not run
Part of your environment is operated by other people. Your cloud provider runs physical security and hardware disposal. Your payroll or HR platform holds employee records. Your report has to say what you are doing about those, and the two options behave very differently. The carve-out method excludes the subservice organisation's controls from your scope and states the complementary controls you rely on them to run. The inclusive method pulls them into your report, which requires their cooperation and is rare outside of tight parent and subsidiary arrangements.
Carve-out is the normal choice, and it comes with a duty that teams forget: you have to monitor those subservice organisations during the window. In practice that means obtaining and actually reading their SOC 2 reports inside the period, checking the report covers dates that overlap yours, and reviewing the complementary user entity controls listed at the back. Those user entity controls are a list of things the provider is telling you that you must do, and auditors have started testing whether you read them. If a provider's report has a lapsed period or a string of exceptions, record what you concluded about it. A file of unopened PDFs is not vendor monitoring.
Bridge letters and the gap after the window closes
Your report covers a period that ended, and prospects will ask for coverage up to today. The instrument for that is a bridge letter, sometimes called a gap letter, which you write and sign yourself. It states the period between your report end date and the letter date, asserts that no material changes were made to the control environment during it, and discloses anything that did change. It is your assertion, not an auditor opinion, and it carries only as much weight as your honesty in writing it.
Two rules keep bridge letters credible. Do not stretch one past about three months, because buyers stop accepting them and some will treat a six month bridge as evidence that your next audit has slipped. And do not sign one that says nothing changed when you migrated identity providers in the interim. Say what changed and why the controls still operated. The letter that discloses a change reads far better than one that is silently wrong.
Where the money and the effort actually go
The audit fee is rarely the largest line. Internal time is, and it is concentrated in three places: producing evidence for populations that were never exported cleanly, the walkthroughs where an engineer explains a system to the auditor, and remediation of anything found during readiness. If you are running the window with tooling, the licence sits somewhere in the low thousands per year for an early-stage company and climbs with headcount and integrations. Readiness work, when a firm does it, is the other significant line, and our SOC 2 in 75 Days engagement starts at $3,000 for the gap analysis, with the rest scoped to what the analysis finds. Readiness also tends to pull the audit fee down rather than add to it, because an auditor who can see the evidence is already assembled quotes less fieldwork than one who is walking into an unknown.
The cost driver nobody prices in advance is the number of systems in scope. Every additional production environment, identity provider, ticketing system and code host adds a population to export and a walkthrough to sit through. Consolidating tooling before the window opens is usually cheaper than explaining three access review processes to an auditor for a year.
When you should not start a window at all
If your buyer has not asked for a Type II, do not start one. A Type I, which reports on design at a point in time, is enough for a meaningful share of mid-market deals and can be delivered in weeks rather than months. Buy the Type I, get the deal moving, and let the Type II window run behind it. Plenty of firms will sell you the longer engagement first because it is worth more to them.
If your company is under about ten people with one production environment and a founder who understands the stack, the cadence is genuinely runnable in-house with a calendar, a shared drive and a written policy set. Our free Workspace at /client-portal holds the evidence and the schedule without a licence fee, and that is often the right answer for a first window. Bring in help when the window is failing for structural reasons, meaning nobody owns it, or the person who did has left, or the environment changed enough that the system description no longer matches reality. That is what a retainer at /engage is for, and the fixed-scope options are set out at /pricing. Paying a firm to run a cadence you were already holding is money spent on comfort rather than outcome.
Set the next window before this report lands
The second cycle is where most programmes drift. The first report covers three or six months, the second is expected to cover twelve, and the two have to join without a gap in coverage or buyers will notice the missing months. Decide the second window's start date at the same time you close the first one, ideally so it begins the day after the first period ends. That continuity is what lets you keep sending a single unbroken record to procurement teams rather than explaining a hole in the timeline every quarter.
Keeping it true is the hard part. Continuous compliance on a monthly retainer: the reviews, the evidence and the calendar operated for you, so the next audit is a review rather than a rebuild.
See how a retainer worksOr talk about a retainer