Changes During Your
Observation Period

Changing the system mid-period does not invalidate a SOC 2 Type 2 report. Because the examination reports on controls operating effectively throughout a stated period, a change creates two obligations: management must disclose the relevant details of significant changes in the system description, and the CPA firm must obtain evidence covering both sides of the change. The first is written down. DC9 of the AICPA description criteria (DC section 200) requires a type 2 description to contain “the relevant details of significant changes to the service organization’s system and controls during that period that are relevant to the service organization’s service commitments and system requirements.” The second follows from the examination itself: performed under the AICPA attestation standards (AT-C sections 105 and 205), the opinion speaks to controls operating effectively throughout the period, so every month needs coverage. That is where projects come unstuck — a control first operated six weeks before the period closed has six weeks of population behind it, and drafting cannot create evidence that never existed. The change is also a tested subject: CC8.1 covers whether changes to infrastructure, data, software and procedures are authorised, tested, approved and implemented, and CC3.4 whether the entity identifies and assesses changes that could significantly impact internal control.

Because the opinion covers the whole period, the superseded control is tested over the months it was in force and the new one over the remainder, so Section 4 carries two control descriptions with their operating dates, two sets of procedures and two results. Each side is sampled against its own sub-period population, so the year’s total lands near two full samples — the frequency table below gives the arithmetic. That sizing is auditor judgement, which is the reason to raise the change before the switch and again at planning.

Replace a hosting provider or a managed service mid-period and both were subservice organizations during the period, so both belong in the description with the dates each was used and the method applied. Under the carve-out method their controls sit outside the description; your monitoring stays inside it. CC9.2 asks whether the entity assesses and manages risks associated with vendors and business partners, and a migration is exactly when that control is exercised — expect testing of diligence on the incoming provider and of offboarding on the outgoing one.

The inclusive method makes a mid-period provider change materially harder, and this is the part teams discover late. Under it the subservice organization’s controls sit inside your description and inside the scope of the examination, so the outgoing provider’s own management would have to give a written assertion covering the months you used them and submit to the service auditor’s procedures for those months — after you have already left as a customer. Providers rarely agree, which is why a mid-period provider change is almost always handled carve-out.

A carve-out then shifts review of the provider’s own SOC report onto your reader: use one provider until June and another from July, and they need assurance covering both stretches, from reports whose periods never align with yours. The outgoing provider’s last report will usually end before your period does, so the reader needs that report plus a bridge letter from the provider for the tail — and a provider that has already lost you as a customer is the least motivated party in the transaction. Ask during offboarding, while the contract is still live.

Offboarding has one artefact auditors reliably request under CC9.2: dated evidence that your data was returned or destroyed on the terms the contract set, in the form of a certificate of destruction or a written confirmation from the provider. Teams that closed the account and moved on can rarely obtain it afterwards. Check the complementary user entity controls too, since the new provider may assume different things of you than the old one did.

Everything in that list is information produced by the entity — IPE. AT-C 205.36 requires the practitioner to evaluate whether information you produced is sufficiently reliable, obtaining evidence about its accuracy and completeness before relying on it. In practice four things travel with every export: the source system and the exact query or report parameters, the filter applied, the run date and time with the account that ran it, and a record count that reconciles to the source.

A mid-period change turns that from hygiene into a deadline. Once the source system is decommissioned, the completeness of an export drawn from it can never be re-performed by anyone — the auditor cannot re-run the query, and neither can you. An export validated at the moment it was taken survives the decommissioning; one taken casually and validated eight months later has only your word behind it. Export first, migrate second.

Two rejections cost the most time. The dashboard screenshot — a compliance tool showing a green tile for access reviews is a monitoring artefact, not the record of who reviewed what and when. And the artefact produced after the request: a policy updated the week fieldwork started, a reconciliation performed in January for a May cutover. Tranquility Cybersecurity does this work alongside a live examination — keeping the description accurate as the system moves, defining populations before systems are retired, assembling both sides of a change. See our SOC 2 services.

Everything in this section is market practice; no published threshold fixes it. A change in the first third of the period is absorbed with a disclosure and slightly larger populations. The middle third produces the two-sub-period pattern above. The last third needs the CPA firm consulted before the change is scheduled. And the final six weeks generally cannot support the opinion for anything operating less often than weekly.

The mechanism is arithmetic. Sampling needs a population, and six weeks of a twelve-month period gives a quarterly control none and a monthly control one. Work a single case: replace a quarterly access review on 15 November of a January-to-December period and the new control has 6.5 weeks and zero completed quarterly cycles behind it, so there is no occurrence for the auditor to test at all. The report then carries the DC9 disclosure with an empty result column beside it, while the superseded control is tested across the 10.5 months it did operate. A daily control lands differently on the same date: six weeks is roughly 42 occurrences, which is a testable population on its own.

That gives the operational rule for discretionary change. Where it can slip past the period end, it becomes a subsequent-event disclosure and costs one paragraph. Where it lands inside, it costs a second bounded population, a second sample and a second result line for every criterion it touches — plus the drafting time to describe both states of the system. Two weeks of patience is usually cheaper than either.