Running the engagement
Your systems changed in the middle of the period. Now what?
Companies don't freeze for a Type 2 observation period. They migrate, swap tools and lose people. None of that breaks the examination. What it changes is the work: each version of a control has to operate for the part of the period it covered, and significant changes have to appear in the system description.
Back to SOC 2 services01 · Kinds of change
The changes that most often land mid-period
Some touch infrastructure, some touch people. All touch evidence.
- Moving clouds or regionsThe hosting provider is often a subservice organization, so the description, the carve-out and the complementary controls you rely on all shift.
- Replacing a toolA new identity provider, ticketing system or code host. The population for every control that ran in the old tool now lives in two places.
- A key person leavesThe owner of a recurring control walks out. Their own access must be removed, and the control must keep running under someone else.
- A new code baseA rewrite or a new repository. Branch protection and review rules must exist in the new place from its first production change.
- A vendor swapA new payment processor, email provider or monitoring service. It needs the same review your vendor control promises before it goes live.
02 · Every version
The rule: each version of a control operates for its slice
The auditor tests the old way before the change and the new way after it.
A Type 2 opinion covers operating effectiveness throughout the period. When a control changes partway, the period splits in two for that control. The auditor builds a population for each slice and samples from each. If the new tool went live in month five, months one to four are tested in the old system and the rest in the new one.
Before the change
- Old tool's records, kept until fieldwork
- Old control wording
- Evidence the old control ran up to the cutover date
After the change
- New tool's records from day one
- Updated control wording
- Evidence the new control ran from cutover to period end
The weak point is the cutover week. Changes approved in neither system, or leavers removed from only one, are where exceptions come from.
Don't switch off the old system too early
Cancelling a tool often deletes its logs. If those logs were your only evidence for the first half of the period, that half becomes untestable. Export the records before you decommission.
03 · Describing change
How significant changes reach the report
In a Type 2, the description has to tell the reader what changed while the period ran.
DC section 200 includes a criterion that applies to Type 2 reports only: if the system or its controls changed in a way that matters, the description says so, with enough detail for a reader to follow. These are significant changes. Management decides which changes qualify, with the reader in mind. The CPA firm then judges whether the description is fairly presented, so leaving out a change a user would care about is a description problem, not just a testing one.
- Name the change, the date it took effect and the controls it touched.
- Describe both versions of a changed control, so a reader can tell which applied when.
- Update the subservice organization list and complementary controls if a vendor in the system changed.
- Leave out cosmetic changes. A new dashboard theme is not significant; a new identity provider usually is.
04 · What gets tested
Change by change: what the auditor tests and what to keep
An illustrative guide, not a fixed procedure. Your CPA firm sets the tests.
| Change (illustrative) | What the auditor is likely to test | What to keep |
|---|---|---|
| Cloud migration | Access, change and monitoring controls in both environments; the carve-out of each provider | Cutover plan, migration change tickets, both providers' SOC reports for their time in scope |
| New identity provider | Provisioning, removal and access reviews in each system for its slice | Export of the old user list at cutover, mapping of old to new accounts, first review in the new tool |
| Control owner leaves | Removal of the leaver's access; continuity of the control they ran | Offboarding record, handover note, evidence the next occurrence ran on time |
| New repository | Review and approval rules from the first production change | Branch protection settings and their date, change list from both repositories |
| Vendor replaced | Your vendor review before the new vendor touched data | Due-diligence record, contract or DPA, the vendor's own assurance report if one exists |
05 · Habits
Two habits that make changes painless
Tell the CPA firm early, and keep a change log as you go.
Tell the CPA firm before the change, not at fieldwork
A short note to the engagement team when a significant change is planned lets them adjust their test plan and ask for the right evidence. Surprises found during fieldwork tend to cost more questions, more samples and more time than the same change announced in advance.
Keep a running change log
- What changed. System, tool, vendor or person.
- When. The effective date, which becomes the split point for testing.
- Which controls. Every control whose evidence moved or whose wording changed.
- Where the old evidence is. The export or archive, with its location.
- Who signed off. The owner who confirmed the new control was running.
Sources: AICPA DC section 200, 2018 Description Criteria for a Description of a Service Organization's System in a SOC 2 Report (significant changes during the period); AICPA AT-C section 205; AICPA guide, SOC 2 Reporting on an Examination of Controls at a Service Organization.
Questions about change during a period
Should we delay a migration until the period ends?
Only if delay is cheap. The examination can handle the change.
Running a business around an audit calendar is rarely worth it. A planned change with evidence on both sides is routine for an auditor. What hurts is an unplanned change with no records from the old system.
Does a mid-period change restart the observation period?
No.
The period stays the same. The changed control is tested in two slices, and the description explains the change. A control that didn't exist at all for part of the period is a different matter: that gap may be reported as a deviation.
What if a new control was weaker during the first weeks?
Say so; don't hide it.
If the auditor finds missed occurrences after cutover, they're evaluated like any other deviation. Disclosing the rough start yourself, with what you did to fix it, reads far better than having it discovered.
We changed our CPA firm and our cloud in the same year. Is that a problem?
It's more work, not a barrier.
Brief the new firm on both. Keep periods abutting and give them the change log so they can plan tests across the cutover.
Plan the change before the auditor finds it.
We map which controls a migration touches, what evidence to export, and how to describe it in Section 3.