What happens after SOC 2: continuous assurance and recertification

The most common failure is treating each cycle as a fresh project. The team reopens every control, rewrites policies that never changed, and burns a quarter arriving back where it started. Scope the cycle against change instead.

Rescope when any of these move:

• People: headcount growth, new engineering teams, contractors, offshore delivery, or a change of control owner.
• Systems: new production services, a new cloud account or region, a change in identity provider, or a new deployment path.
• Data: new categories of customer data, new transfer routes, or a change in retention.
• Vendors: new subprocessors, a vendor taking on production access, or a critical vendor being replaced.
• Obligations: a buyer contract with new security schedules, or regulatory shifts such as DORA for financial-sector customers and the EU AI Act where models are in scope.

Write the rescoping decision down. A short scope note per cycle, listing what changed and which controls that touches, is the difference between a two-week checkpoint and a three-month rebuild.

Once scope is set, split the control set into three buckets: unchanged, changed, and new. Unchanged controls carry forward with a documented basis, which is simply a note that the design, owner, system, and evidence source are the same and a sample was reviewed. Changed controls get re-designed if needed and re-tested. New controls get designed, assigned, and evidenced from scratch.

This delta view is what keeps the workload proportional. It also makes management reporting honest: instead of a percentage that never moves, you report how many controls changed this cycle, how many gaps opened, and how many closed.

Keep the prior cycle intact rather than overwriting it. Auditors and buyers ask what changed and when, and a history of decisions answers that in minutes.

Evidence collected in a panic is thin, inconsistent, and often outside the audit period. Evidence collected on cadence is the same work spread across the year, and it holds up under sampling.

For each control, fix four things and keep them stable:

• Owner: a named person, not a team alias, with the access needed to produce the artefact.
• Expected artefact: what good evidence looks like, including the fields an auditor will read.
• Cadence: the frequency the control claims, matched by the frequency of the evidence.
• Location: where the artefact is filed, so collection is a retrieval task rather than an investigation.

A control that says quarterly but produces one artefact a year is a finding waiting to happen. Either the cadence is wrong or the operation is. Fix the mismatch when you see it, not when the auditor does.

Different assurance mechanisms have different triggers and outputs. Running them from one calendar prevents the pattern where a surveillance audit and an observation window land in the same fortnight as a funding process.

Work backwards from each external date. Internal checkpoints should land far enough ahead that findings can be remediated and evidence can accumulate inside the period, not after it.

Most of the commercial value of assurance is realised in security review, not in the audit itself. That value decays quietly: a posture summary written last year, a pentest attestation past its usefulness, an answer library that still names a vendor you replaced.

Refresh on a fixed rhythm:

• Every cycle: posture summary, certificate and report references, subprocessor list, and architecture or data-flow description.
• Annually or after material change: penetration test attestation and remediation summary.
• Quarterly: the questionnaire answer library, so responses reflect current controls and current tooling.

Version the pack and record what changed. When a buyer asks whether an answer given nine months ago still stands, the version history is the answer.

Drift rarely announces itself with a failed audit. It shows up first as small administrative decay. Watch for these and treat any of them as a checkpoint trigger:

• Control owners who have left, changed roles, or never confirmed the assignment.
• Evidence gaps in the current period for controls that claim a fixed cadence.
• Exceptions in use with no approval, no expiry date, and no compensating control.
• Prior-cycle findings still open past their remediation date.
• Policies past their review date, or approved by someone no longer accountable.
• Access reviews completed late, partially, or without an evidenced decision.
• New production systems that never entered the asset or control inventory.

None of these is dramatic on its own. Three of them together usually means the next audit will be a rebuild rather than a checkpoint, and that is worth catching a quarter early.