SOC 2 Type II evidence: built during the window, not after

Q: How long does a SOC 2 Type II observation window have to be?

The AICPA does not mandate a minimum, though its guidance leans toward six months or more; the window is agreed with your auditor. In practice windows run 3 to 12 months. First audits often use three to six months to get a report into customers' hands sooner, then move to an annual 12-month cycle so consecutive reports cover consecutive periods.

Q: Can we backfill evidence for months we did not document?

No. You can rebuild a policy document; you cannot rebuild a timestamp. If a control has no records for month two, the honest outcomes are an exception in the report or a delayed window start. Backdating records for an audit is misrepresentation, and auditors are practiced at spotting evidence created in a burst the week before fieldwork.

Q: What does the auditor actually sample across the window?

Recurring control events spread over the period: leavers and joiners, access reviews, changes shipped, incidents handled, assets disposed of, backups restored. For each sampled item they want the record the control produced at the time it operated, with its timestamp.

Q: Does a compliance-automation platform replace this?

It complements it. GRC platforms are collectors: they screenshot configurations and chase owners for artifacts. The stronger position is when your systems of record write the evidence in the course of running, and the collector merely gathers it. An asset register nobody updates produces nothing worth collecting.

Q: Does using OnTrackio make us SOC 2 compliant?

No. A SOC 2 report is an auditor's opinion on your whole control environment across the period. OnTrackio produces the asset and access portion of that evidence continuously; policies, the wider control set, and the audit itself remain yours.

2026-07-16

A Type I and a Type II report test the same controls against the same criteria. The difference is one word in the auditor’s opinion: period. Type I says your controls were suitably designed and in place on a given day. Type II says they operated effectively across an observation window, usually 3 to 12 months, and the auditor samples across that whole window to test it. This changes what counts as evidence in a way that catches teams every year: a perfect set of documents assembled in the month before fieldwork can pass a Type I and fail a Type II, because the one thing you cannot assemble retroactively is a timestamp.

What Type II actually tests

For a Type II engagement, the auditor picks recurring control events and samples them across the months: an incident handled early in the window, a disposal from the middle, an access review near the end, changes shipped in between. For each sampled item they ask for the record the control produced when it ran. Design questions (“show me the offboarding checklist template”) give way to operating questions (“show me the completed checklist for this specific person, dated within your policy window”).

That sampling pattern is why the window has no quiet months. If your monthly reconciliation ran only in January and June, the auditor counting twelve expected runs against two records finds the gap, and the gap goes in the report.

Why the audit-season sprint fails

The sprint pattern is familiar: the audit is announced, a shared folder appears, and a team spends three weeks producing inventories, review records, and sign-offs. For a Type I, that can work. For a Type II it fails structurally, for three reasons.

First, timestamps. A record created in September cannot evidence April. Either it is honest about its creation date, and proves nothing about April, or it is backdated, and that is misrepresentation. There is no third option.

Second, consistency. Sprint-built records look sprint-built: uniform formatting, identical dates, one author, no drift. Real operational records accumulate texture: different operators, occasional corrections, gaps explained by holidays. Auditors read hundreds of evidence sets a year and know the difference.

Third, the underlying state. If the asset register was not maintained during the window, reconstructing it now does not answer the question the sample asks: what did this person hold on their last day in May? An answer that was never captured cannot be recovered.

Choosing the window, honestly

Since the window length is agreed with your auditor rather than fixed by the AICPA, the practical guidance is:

First report: three to six months is common, because customers are waiting and a shorter window gets a report into their hands sooner. Controls should already be operating when the window opens. One switched on mid-window is not fatal, since the auditor tests it from its go-live date and discloses the change in the system description, but the months before go-live stay uncovered, and a window that opens the week your offboarding process launches will sample its first failures.
Steady state: annualize to 12 months so consecutive reports cover consecutive periods and no months fall between them.

Either way, the window start date is a commitment: from that day, every recurring control needs to leave records.

Evidence that accumulates by itself

The way out of the sprint is to make the records a side effect of operating. Evidence that survives a Type II sample has three properties: it was created at the moment the control operated, it is tied to the specific item the control touched, and it is retained at least as long as the window.

For the asset and access portion of SOC 2, that looks like:

Assignment history. Every issue and return of a device written to the asset’s own record with a date and an operator, so “what did this person hold in May” is a query, not an investigation.
Reconciliation data. An endpoint agent reporting daily gives you a continuous register-versus-reality trail; the auditor can pick any month and see the estate reconciled.
Change and lifecycle records. Status changes, disposals with their certificates, warranty and renewal events, each logged when they happened.
Access trails. Grants and revocations logged with provenance at the moment they occur, joiner to leaver, as covered in the offboarding post. If you keep the inventory in a spreadsheet, the ungated asset inventory template ships a review-log sheet built for exactly this window.
Review artifacts. The one category that still needs a human ritual: access reviews and inventory reviews, run on a schedule, each leaving a dated record when it runs.

Design the cadence before the window opens

The recurring rituals are the part no tool fully automates, so put them on a calendar with an owner before the window starts:

Monthly: exception review. Unassigned devices, leavers still holding assets, licenses without owners. Fifteen minutes if the register is live, and the dated record it leaves is what the auditor samples.
Quarterly: access review and inventory reconciliation, signed off by a named person, dated when performed.
Continuously: let the systems of record log. Resist the urge to keep parallel spreadsheets; every copy of the truth is a future inconsistency for an auditor to find.

Run that cadence from day one of the window and audit season stops being a season. The evidence request list becomes an export exercise.

How OnTrackio produces period evidence

OnTrackio’s records are built to serve as period evidence. Assignment history, status changes, and disposals write to a tamper-evident, hash-chained audit log with per-tenant retention (twelve months by default) and CSV or JSON export, so any later alteration or deletion is detectable and the trail outlives a standard window. The endpoint agent reports daily, with rollups retained for twelve months, so the reconciliation is there for any month of an annual window the auditor samples. And the SOC 2 CC6 evidence pack generates from live data on any day of the window, which makes it a self-test: if the pack looks wrong in month two, you found the exception months before your auditor does.

The scope caveat: this covers the asset and access slice of a Type II. Policies, vendor management beyond your software estate, incident response outside asset incidents, and the review rituals themselves are yours. And we hold ourselves to the rule this post argues: our own observation window has not opened yet, and the security page says so outright rather than implying otherwise. If your window opens soon and the asset half of your evidence still lives in a spreadsheet, book a 30-minute demo; US teams will find the identity and residency details on the US overview.

Frequently asked questions

How long does a SOC 2 Type II observation window have to be? No fixed rule; agreed with the auditor. In practice 3 to 12 months, with first audits often at 3 to 6 and steady state at an annual 12.

Can we backfill evidence for months we did not document? No. Missing months are an exception or a later window start. Backdating is misrepresentation, and burst-created evidence is recognizable.

What does the auditor actually sample across the window? Recurring control events spread over the period: leavers, reviews, changes, disposals, incidents, each traced to the record created when the control ran.

Does a compliance-automation platform replace this? It complements it. Collectors gather artifacts; your systems of record have to generate them. A register nobody maintains produces nothing worth collecting.

Does using OnTrackio make us SOC 2 compliant? No. OnTrackio produces the asset and access evidence continuously; the rest of the control environment and the auditor’s opinion make up the report.