SOC 2 Type 1 to Type 2: what actually changes in the observation window

A Type 1 report is a photograph. A Type 2 is a film. The Type 1 says that on a given date your controls were designed properly and in place. The Type 2 says that over an observation window — typically six to twelve months — they operated, every time, and you can prove it. Teams that sail through the first one and stumble on the second almost always stumble for the same reason: nobody owned the calendar.

The controls don't change. The evidence does.

Your control set is the same in both reports. What changes is what the auditor asks for. For a Type 1, "we review access quarterly" is satisfied by showing the policy and one completed review. For a Type 2, the auditor samples: if the window is twelve months they will pick two, three or four quarters and expect a dated, signed-off review for each, with evidence of remediation where access was removed.

That pattern repeats for every recurring control:

• Access reviews — one per period, with the reviewer, the date and the actions taken.
• Vulnerability scans and patching — scan output per cycle plus tickets showing critical findings were closed inside your stated SLA.
• Onboarding and offboarding — the auditor picks a sample of hires and leavers and wants the ticket, the account provisioning, and for leavers the deprovisioning timestamp.
• Change management — a sample of production changes, each with a reviewer and an approval that pre-dates the deploy.
• Backups and restore tests — evidence the restore test happened, not just that backups run.

Where the window gets lost

The failure mode is not a control that doesn't exist. It's a control that ran in month one and month twelve and nobody can show months two through eleven. The observation window is unforgiving about gaps: a control that ran ten times out of twelve is an exception in the report, and an exception in a Type 2 is what your customer's procurement team will ask you about.

The Type 2 isn't a harder audit. It's the same audit, run against the evidence of a year, and the year is what most teams don't plan for.

Three things we put in place before any client's window opens:

• A control calendar with a named owner per control. Not "the engineering team" — a person. Their name is on the evidence.
• Evidence collected at the moment the control runs, not reconstructed at audit time. A compliance platform is useful here; so is a shared folder with a naming convention, if that's what the team will actually keep up.
• A mid-window internal audit, usually at month four to six, where we sample exactly the way the external auditor will. Anything missing is fixable then. At month eleven it isn't.

Choosing the window

Six months gets you a report sooner. Twelve months is what most enterprise and bank customers expect on renewal, and it's what removes the "why is your window so short?" question from the next questionnaire. Our usual advice is a six-month first Type 2 if a customer is waiting on it, then move to twelve-month windows from the second report onward. The important thing is that the window starts the day your controls are actually running — not the day you decide you'd like a report.

Takeaway: Put a name and a date on every recurring control before the window opens. The Type 2 is won or lost in months two through eleven.