Shipping during a SOC 2 observation window

You do not have to slow down. You have to make the record of each change a by-product of shipping it, because every merge in the window is in the population.

Last reviewed 2026-09-01Written by Jacob Masse, TrazTech Inc.

Nothing about a SOC 2 observation window requires you to deploy less often. Teams shipping thirty times a week pass Type 2 audits routinely, and teams shipping once a month fail them. What changes is that every production change between day one and the last day of the window enters a population the auditor samples from, typically 25 to 45 items for a three to twelve month window, and each sampled change has to show the same four facts. If those four facts are a by-product of your pipeline, volume is irrelevant. If they are something a person assembles afterwards, volume is fatal.

What does an auditor need from each change?

It was reviewed by somebody other than the author

Evidenced by the approval record on the merge, with a different identity from the committer. A convention that engineers review each other is not this. Branch protection enforcing it is.

It passed whatever gate you told the auditor about

If your description says tests gate deployment, the sampled run has to show tests passing. If it says nothing gates deployment, that is fine and testable. The exception is the gap between the two.

It was authorized, in the sense that somebody wanted it

A ticket, an issue, or a linked description. This is the weakest of the four in practice and the one auditors are most flexible about, but a merge titled "fix" with no linked anything is the one they circle. The change ticket evidence page covers what the record has to carry.

It reached production through the path you described

Deployed by the pipeline, not by somebody with a shell. Every manual push to production during the window is an item you will be explaining.

How many of our changes will actually be looked at?

Sampling is proportionate but strongly sublinear, which is the fact that should calm anyone worried about deploy frequency. Doubling your deploy rate does not double the sample. The bands below are the ranges Canadian CPA firms work to for change management populations, and the same figures are in the table under the chart.

The first row is the one that surprises people. A team that deliberately slowed to twenty deploys across a six month window did not reduce its audit burden, it guaranteed that every single change gets inspected. High volume is protective. Sloppy high volume is not.

Comparing firms for this? Tell us what you need and it goes to the ones in the directory that do this work. No charge, and no phone number required.

What creates an exception, and what does not?

What do we set up before the window opens?

Everything below is a configuration change, not a process change, and each one is the difference between a record that already exists and a record somebody has to assemble from memory in month four.

0 of 0 done · Reset

• Branch protection on every production branch, review required, force push disabled, and administrators included in the rule
• Every repository that reaches production is covered, including the small ones. The repository nobody remembers is where the unreviewed merge lives
• Bot and automation accounts identified, so the auditor can tell a machine merge from a human one without asking
• Infrastructure changes running through the same pipeline as application changes
• Direct production write access removed, or reduced to a named break-glass account with alerting on use
• Emergency change path written down, with who can invoke it and what they file afterwards
• Pipeline run history retention set longer than the window. Ninety-day defaults delete the evidence for a twelve month period
• A saved query or script that exports the full merge list for a date range, so the population is produced the same way every time
• Feature flag changes logged with actor and timestamp if flags gate customer-visible behaviour

Pipeline retention is the one that ends programs. Log and run-history retention cannot be applied backwards, so a default that expires at ninety days quietly destroys the first half of a twelve month window. Check it before day one, alongside the rest of the evidence routine.

The case for slowing down anyway

There is one, and it is not about the audit. If your change history is undisciplined, unreviewed merges, direct pushes, infrastructure by hand, then opening a window on top of it converts every week of shipping into another week of findings you will be writing management responses to. In that situation the right move is to delay the window start by four to six weeks and fix the pipeline, not to keep shipping into a population you already know is dirty. Where a customer date makes that delay look impossible, SOC 2 by a date that is not possible covers what to tell them instead. Delaying a window start is cheap. Explaining eleven exceptions in a report a customer will read is not.

The test is simple: export last month's merges and check the four facts on ten of them at random. If eight or more pass, open the window and keep shipping. If fewer, you have found your remediation work, and the timeline page shows what the delay does to your report date.