A readiness assessment ends with a list of gaps. The list is the easy part. The hard part is deciding which gaps must close before the SOC 2 Type II observation period starts, which can wait, and how to know a fix has actually worked rather than been declared finished.
The stakes are specific. Once the period starts, every control is tested on how it operated across the period. A gap that exists on day one is a gap the auditor can find in the sample. This article covers how to sort the list, what "fixed" has to mean, and how to choose a start date you will not regret.
Why the start date changes everything
Before the period, a gap is a project. After the period starts, it is a potential exception in a report your customers will read.
If a control is missing when the period begins and you implement it partway through, the auditor can usually only test it from the date it started operating. Depending on the firm and the control, the report may describe the shorter testing window, or the missing months may be reported as a deviation. Either way, a reader of the report sees that the control did not cover the whole period.
That asymmetry is the reason to work through the list before you commit to a date, not after. If you are still deciding between report types, the comparison of SOC 2 Type I and Type II explains why the period matters only for a Type II.
Sort the gaps by type
Gaps differ in what fixing them involves. Sorting them first makes the plan realistic.
| Gap type | Example | What "fixed" means before the period |
|---|---|---|
| Design | No process exists for reviewing vendor risk | Process defined, owner named, policy approved, first review done |
| Implementation | MFA required by policy but not enforced in the identity provider | Setting enforced, exceptions removed or recorded, setting exported |
| Operating | Access reviews happen, but not every quarter | One review completed on schedule, the next one on the calendar |
| Evidence | Code review happens, but approvals are not recorded | Branch protection requires approval, so every merge leaves a record |
Design gaps take longest, because they need a decision before any work starts. Evidence gaps are often the quickest, because the control already runs and only the record is missing. Start the design gaps first.
Decide what must close before day one
Not every gap has to close before the period starts. Use three questions.
Does the control operate continuously or on events? Access provisioning, change approval, MFA enforcement, encryption and logging run all the time. These must work on day one, because every instance in the period can be sampled.
Does the control run once in the period? The annual risk assessment, the penetration test and annual training do not need to have happened before the period starts. They need to happen inside it. Put them on the calendar, with an owner, and they stop being gaps.
Does the gap belong in scope at all? A gap in a system that does not support the service you are reporting on may be resolved by a scope decision. Be careful: scoping something out to avoid a gap only works if buyers do not need it covered, and the system description has to be accurate.
Policies are their own case. Every policy the controls depend on should be approved, with the approval dated, before the period starts. A policy approved in month two leaves the first month without a documented requirement.
Prove each fix works
A gap marked closed in a tracker is not the same as a control that operates. Before the period starts, each fix should pass a short test.
Run the control once, for real. Perform the quarterly review, approve the access request, onboard the test user. The first run exposes the steps the design missed.
Produce the evidence in the form you will use. If the auditor will inspect a ticket, check the ticket holds what they need: who, what, when, and the approval.
Have someone else check it. The person who built the fix is the worst judge of whether it works. A colleague reading the evidence cold is a better test.
Sample yourself. For frequent controls, pick a few recent instances at random and check each has its evidence. If one is missing, the fix is not finished.
Fixes that change a system configuration deserve one more check. The change itself should have gone through your change management process, with its approval recorded. An auditor who sees MFA enforcement switched on a week before the period will reasonably ask how the change was made and who approved it, and the answer should be a ticket, not a recollection.
The readiness work is also the point to confirm each control description matches the fixed process, because the auditor will test the description. First-audit mistakes covers why descriptions copied from templates cause trouble later.
Choose a start date you can hold
The period should start on a date when every continuous control is operating, every policy is approved, and every annual control is scheduled inside the window. That date comes from the gap list, not from a sales deadline.
If the gap list says the date is later than the business wants, you have a few honest options:
Move the date. Usually the right answer. A period that starts a month later and runs cleanly is worth more than one that starts on time with known exceptions.
Obtain a Type I first. It tests design at a point in time and gives buyers something to review while the Type II period runs. See planning your first audit timeline for how the two fit together.
Narrow the scope, where the gap sits in something buyers do not need covered.
Accept a known exception, and fix it early in the period. This is a real option, not a failure. A report with an exception and a clear management response can still serve buyers. Discuss it with your auditor before you rely on it.
Whichever you choose, tell your auditor. Firms can advise on how a known gap will be tested and reported, even though they cannot design the fix for you.
What to do in the last two weeks
The final stretch before the period starts is for checking, not building.
Walk the full control list with each owner and confirm the control is running.
Confirm every policy approval is recorded and dated.
Confirm the annual controls are booked inside the window, with owners.
Confirm the populations for each frequent control can be produced.
Record the start date in writing, agreed with the auditor.
If something fails this check, it is still a project. One day later, it is an exception. The SOC 2 readiness page covers the assessment that produces the gap list in the first place.
How TrustLynce helps
The readiness dashboard shows gap analysis per framework, so you can see which controls are not yet operating before you commit to a start date. Once the period begins, continuous monitoring flags a control that stops working while there is still time to act.