SOC 2 after an acquisition or platform change, what to disclose

Does an acquisition or platform change break a SOC 2 report?

A significant change during the examination period usually does not void a SOC 2 report, but it must be handled deliberately. An acquisition closing, a new product going live or a cloud migration under way mid-period all need to be identified under CC3.4, described in the system description prepared against DC 200, and reflected in the scope the auditor tests. Where a customer or contract still needs a current report, the question is less whether the change breaks the report and more whether the report, as issued, accurately describes the system the customer is buying. The organization owns its controls and decides what counts as significant. An implementation partner can help prepare systems, change records and evidence, but only the independent CPA firm tests the controls and issues the report.

Start with a written change inventory for the period. For each change, record the date, the systems, data stores, services and teams affected, and whether the change touches the boundary of the system described in the report. Then assess it against the CC3.4 points of focus, which cover changes in the external environment, business model, leadership, systems and technology, vendor relationships and threats. An acquired company's identity provider, cloud accounts, ticketing tools and vendor contracts are the usual places where the boundary moves. Confirm with your CPA firm whether each item belongs inside the system description, whether it is a subservice organization, or whether it is out of scope for this report. Ask them to confirm the assessment in writing before fieldwork relies on it.

Some changes need more than a description update. Moving production workloads to a new cloud account or region changes the controls under CC6, CC7 and CC8, so the evidence must show that access rules, logging, backups and change approvals operated in both the old and new environments wherever both were in scope. An acquired company's systems may bring their own change process, and that process must be brought up to the standard the report describes or excluded with a clear statement. Confirm with the auditor whether the new product sits in the same system or needs a separate report, and whether a bridge letter will be needed for the gap between periods. The Journal of Accountancy advised in February 2026 that providers check whether a report is tailored to the system, so the system description should name the new components rather than describe the old environment in general terms.

How to handle a change from identification to the report

This sequence turns an acquisition, new product or platform move into a documented assessment, updated system description and test evidence that the independent auditor can examine. Each step has a named output so the change is traceable from the first signal to the final report.

Detect the change through a change log
Engineering, operations and corporate development record every proposed or completed change that could alter systems, data flows, vendors, ownership or leadership in a single change log. Security or the compliance lead reviews the log at the CC3 risk review and at each planned change window, so nothing reaches production or closes as a deal without a record. Done means every entry has an owner, a date and a classification, and the log is kept as evidence for the period.
Assess the change against controls
The compliance lead and the control owners judge whether the change could significantly affect the system of internal control, using the CC3.4 points of focus on the external environment, business model, leadership, systems, vendors and threats. For an acquisition, this includes the target's identity, access, logging and vendor relationships. The output is a short written assessment that states which controls are affected and why, or why none are.
Update the risk assessment and control matrix
Where the assessment finds an effect, the risk register gains the new or changed risks, and the control matrix is revised to show which controls cover them, who operates each control and where its evidence will come from. New tooling, a migrated environment or a newly integrated company often needs new control activities under CC5 or CC8. Done means the matrix and register reflect the post-change environment and the previous version is retained for comparison.
Record the change date for the system description
The management description of the system must state significant changes made during the period, as DC 200 requires, so the date and nature of each change are written into the working draft. The system description also needs updated components, subservice organizations and in-scope entities where they moved. Done means the draft records each change with its effective date and the owner has signed off that it is accurate.
Test the new or altered controls
Control owners run the new or altered controls and keep dated evidence of each operation, such as access approvals, configuration baselines, deployment records, alert reviews and vendor reviews for the acquired company. Changes made partway through the period need evidence from the change date onward, and the auditor may sample both the old and new operation. Done means each affected control has a populated evidence folder and the test results show whether it operated as designed.
Confirm the final description with the auditor
Management sends the revised system description, the updated control matrix and the change assessment to the independent CPA firm, which decides what testing the change requires and whether its scope still matches the report. The auditor issues the report and opinion, not the implementation partner or the company. Done means the auditor has accepted the final description in writing or raised exceptions that management has addressed before the report is issued.

How each type of change affects scope and the system description

An acquisition raises a scope question before it raises a control question. The 2017 Trust Services Criteria can be applied to an entire entity, to a subsidiary or division, or to narrower levels, so the acquired company can be examined separately or brought into the existing report later. Either choice changes the system description: the description must name the entities and systems covered, the services they provide and the systems they depend on. If the acquired company stays outside scope for now, the description and the report should say so, and the controls that connect the two organizations (shared identity, shared hosting, shared support) must be described where they touch the examined system.

Integrate or keep separate: Decide which option applies before the next period starts, and record the decision with the reason and the date it takes effect.
Identity and access: Shared directories, administrator accounts and single sign-on often link the two environments, so access controls for the acquired company may affect the examined system.
Subservice organizations: Hosting, email or tooling that the acquired company already uses may become new subservice organizations and need carve-out or inclusive treatment.
Auditor questions: Expect requests for the acquisition date, the integration plan, the account inventory and evidence that access was reviewed after the change.
Significant change disclosure: A material change in entities or systems during the period belongs in the description, so confirm with your auditor how to word it.

Before the period opens, confirm with your auditor in writing whether the acquired company is in scope, and document which controls its staff now operate under.

Moving infrastructure during the observation period

An infrastructure move during a SOC 2 observation period is a change to the system, so it falls under CC8.1, which covers every stage of a change to infrastructure, data, software or procedures. Treat the migration as a formal change program with its own authorization, design, configuration, testing, approval and implementation records. Before cutover, confirm which environment is in scope for each date in the period, and write the migration plan so that each step names the control owner, the approver and the test that proves the step worked. Auditors sample changes, so a move executed through a chat thread or an unrecorded console session will show up as an exception even when the result is correct.

Where the old and new environments are both in scope during overlap, the controls must operate on both. That means access reviews, logging, vulnerability scanning and backup jobs have to run in the legacy estate until it is decommissioned, and the new estate needs its own evidence from its first day. Retain the change tickets, approval records, pre- and post-cutover test results, runbook execution logs and the cutover record that shows when traffic and data moved. Ask your auditor early which evidence they expect for the migration itself, because the period's system description must also disclose the change as a significant change during the period under DC 200.

A move is also where controls most often lapse. Identity mappings can be recreated with broader privileges, log forwarding can be missing from the new accounts, and backup schedules or restore tests can be configured in the new environment without being verified. Build a control checklist for each of these three areas and sign it off before the old environment is switched off, then run a restore test and an access review on the new estate within the period. Confirm with your auditor how they plan to sample changes, and ask whether they want the migration treated as a separate test population. Illustrative example: a team that moved a logging pipeline without checking retention settings would have a gap that appears only when an auditor asks for logs from before the cutover.

What usually creates exceptions after a major change

Most SOC 2 exceptions after a major change do not come from the change itself. They come from gaps in the record: changes that were never logged, access that was inherited without review, documents that describe a system that no longer exists, and controls that quietly stopped running during the move. Each card below names one of these gaps and the step that prevents it.

Changes not logged during the period

Significant changes made during the period must be disclosed in the system description under DC 200, and CC3.4 expects the organization to identify and assess changes that could significantly affect internal control. When a reorganization, a new product line or a hurried infrastructure fix happens without a ticket or assessment record, the auditor has no way to confirm the change was reviewed. Keep a dated change register from the first day of the period, and confirm each entry links to an assessment and an approval.

Inherited access never reviewed

An acquired company usually arrives with its own directories, cloud accounts, shared administrator logins and vendor accounts that nobody on the buyer's side has reconciled. Under CC6 the auditor will expect access to be granted on authorization and reviewed periodically, and inherited accounts with no owner fail that test quickly. Before the acquired environment is connected, export its identities, assign an owner to each one, and remove or re-approve anything without a current business need.

System description written for the old architecture

The system description is management's account of the services, components, incidents and subservice organizations in scope, and it is evaluated against DC 200. After a migration or a new product launch, a description that still shows the previous hosting, data flows or ownership structure contradicts the controls the auditor tests. Walk the description against the current architecture diagram and the asset inventory before fieldwork, and note every component that changed during the period.

Vendors added without due diligence

New platforms, acquired software and replacement suppliers often enter production through a finance approval or an engineering decision rather than the vendor review process. CC9 expects risks from vendors and business partners to be identified and managed, and a subservice organization that is missing from the description creates a gap in the complementary controls. Route every new vendor through the same intake, collect its current SOC report or equivalent assurance, and record its role in the system description.

Controls switched off during migration

Migrations often disable logging, alerting, backup jobs or scanning agents while systems are moved, and nobody restores them to the same configuration afterward. A control that stopped for two weeks in the middle of an observation period is an operating effectiveness exception, even if the new environment is better. Keep a checklist of controls that must run continuously through the cutover, verify each one in the target environment on the day it goes live, and retain the evidence from both sides of the move.

Which approach fits: amend, carve out or wait for the next period

This table compares three ways to handle a significant change during a SOC 2 period: amending the current period, carving the change out, or completing the period and bringing the change into the next one. Read each row against your own timing and customer commitments, and use the questions to take to your CPA firm before deciding.

Decision point	Amend the current period	Carve out for now	Wait for the next period
When it fits	The change touches controls already in scope and the team can show the new control design and operation from the change date onward	The acquired company or new product runs on separate systems that do not share controls, data or access with the in-scope system	The change is late in the period, the new environment is not yet stable, or the change does not affect the controls being tested
Effect on the report	The system description discloses the change under DC 200 and the controls covering it are tested for the period in which they operated	The report covers only the defined system, and the carved-out entity or product is not described as included	The current report describes the system as it was, and the change appears as a significant change in the system description for the period after it
Assessment under CC3.4	Management documents the risk assessment of the change and how controls were adjusted before the change took effect	Management documents why the separation holds and reviews it as the boundary changes over time	Management records the change under CC3.4 in the current period, even though it is not yet in the tested system
Customer communication	Customers may ask whether the report covers the changed system, so the description and bridge letter must match	Customers must understand that the carved-out product or entity has no SOC 2 coverage yet	Customers may need interim assurance or a bridge letter covering the period before the new scope starts
Questions for the CPA firm	Can the change be tested within the current period, and how will sampling cover before and after the change date?	Does the firm accept the boundary, and what evidence shows no shared access, data flows or administration?	How will the firm treat the change in the current report, and what does the next period need to test from day one?
Main risk	Controls may not yet be designed or operating consistently across the changed environment when testing begins	Shared identity providers, logging pipelines or staff can quietly pull the carved-out product back into scope	A gap in assurance appears for customers who expected continuous coverage across the change

What to tell customers and bridge letters

Customers read a SOC 2 report against their own third-party risk expectations, and a regulated customer may test whether the report covers the activity it buys. The Federal Register's interagency guidance on third-party relationships (88 FR 37920) says a bank may consider whether the scope and results of SOC reports are relevant to the activity performed, or decide that more scrutiny of the third party is needed. After an acquisition, a new product or a platform move, the question a customer asks is less about whether the report exists and more about whether it describes the system they actually use. Before you send the report, compare the system description with the current architecture, the entities in scope, the hosting locations and the subservice organizations, and confirm which changes fall inside the examination period.

A bridge letter covers the gap between the end of the last report period and the date a customer asks about, and it is the place to explain a change that the report does not yet cover. Its content, form and sign-off belong to management, not to the implementation partner, and the independent CPA firm does not certify it as a report. Ask your auditor how it will treat a change made after the period ends, and confirm with your legal team whether your customer contracts specify the letter's coverage window. If an acquired company's systems are not yet in the examination, say so plainly in the letter and in your customer communications rather than implying coverage that does not exist.

The Journal of Accountancy advised in February 2026 that service organizations review their SOC 2 report even after paying for it, to confirm it will satisfy business partners. Use that review to check whether the report is tailored to your system, whether the controls reflect the risks of the changed environment and whether the test procedures match the controls. Assign one owner to keep a register of changes, the customer questions they triggered and the answers given, so that sales, security and the auditor work from the same account of the system.

What to ask a CPA firm and a consultant before signing

A SOC 2 that spans an acquisition, a new product or a platform move depends on who is doing the work and how the engagement is written. The questions below separate the independent CPA firm that issues the report from the consultant who prepares your systems and evidence, and they test how each will handle change during the period.

How the firm treats mid-period changes

Ask how the firm expects to learn about a change during the examination period, and what it does with a change that lands partway through. A CPA firm will want to see whether the change is reflected in the system description and whether the controls over it operated from the day it went live. Ask for a written example of how the firm has handled a mid-period migration before, and confirm who on the firm's team makes that call.

Experience with migrated or acquired environments

Ask whether the team has examined environments that were moved, merged or inherited from an acquisition, and how those engagements were scoped. Acquired systems often arrive with different identity providers, change pipelines and logging, so the firm should explain how it tests controls that were designed by another organization. Request references you can verify through your own network rather than relying on the firm's summary alone.

Scope changes and fee effects in the engagement letter

Read how the engagement letter defines the system, the in-scope entities and the process for adding a newly acquired company or product. Confirm whether a scope change requires a written amendment, whether it can move the report date, and how any additional testing is priced. Ask the consultant to show the same terms in its own statement of work, so that neither party is surprised when a new subsidiary joins the scope.

Who prepares evidence and who issues the opinion

Only the independent CPA firm issues the SOC 2 report and its opinion, while a consultant prepares the controls, documentation and evidence that the auditor will test. Ask each party to name the people who will work on your evidence and to confirm in writing that the consultant will not sign, attest or sign off on the report. Keep the two roles separate in your contracts so that the auditor's independence is never in question.

Controls over the change pipeline

Ask the consultant how it will document the change management controls that cover the migration itself, including authorization, testing, approval and rollback records under CC8.1. Confirm which tickets, pull requests and deployment logs will be retained as evidence and who owns their retention after the consultant leaves. Clarify whether the consultant will also review changes made by your own team during the transition.

Risk assessment updates for the new scope

Ask how the risk assessment will be refreshed when an acquisition or new product changes the business model, vendors or threats. Under CC3.4 the organization must identify and assess changes that could significantly affect internal control, and both the firm and the consultant should explain how they will evidence that step. Request a sample risk register update from a past engagement to judge the depth of the work.

Questions buyers ask about SOC 2 after a change

Does an acquisition restart the SOC 2 observation period?

Not automatically. The observation period belongs to the report of the entity or system being examined, and management decides how the period and scope are defined in the system description. An acquisition changes the system and possibly the boundary, so the auditor will want to know which controls the acquired company runs, when they came under your control, and whether the change falls inside the current period or needs disclosure as a significant change. Ask the auditor early how they will treat the transition, because the answer depends on the scope you define and on how much of the acquired environment is folded into your existing controls before the next period starts.

Must the acquired company be audited separately?

It depends on what the buyer's customers need the report to cover. A SOC 2 describes a defined system, so if the acquired product or environment is part of what you sell, it must either sit inside the existing report's system description or be examined on its own. Separate examinations make sense when the acquired business keeps its own people, tooling and customer contracts for a while. Folding it in makes sense when shared identity, logging and change processes already run on the parent's controls. Confirm with your CPA firm which option fits, and ask what evidence they will need to test the acquired controls from day one.

How long does the internal change assessment take to prepare?

No reliable duration is available for every organization, so ask for a timeline based on your own inventory. The effort depends on how many systems, data stores, vendors and procedures the change touches, how well the current system description and control matrix are documented, and how quickly teams can produce records of past changes. Acquisitions usually add the most work because the acquired company's assets, access grants and vendor relationships must be listed before they can be assessed. Ask the implementation partner or auditor to scope the assessment in writing, including which artifacts they expect and who will review them.

What does the work need from the internal team?

The work needs named owners who can answer for each affected area, not just a project manager. Typically that means someone who knows the infrastructure and access model, someone who owns the software delivery pipeline, someone who manages vendors and contracts, and someone who can describe how the business and its leadership changed. Engineers must be able to export change records, access lists and configuration history, and HR or the acquiring entity's administrators must confirm joiner and leaver records for transferred staff. Plan for these people to spend recurring time with reviewers, because questions usually come after the first draft of the assessment.

Can we do the change assessment in-house?

Often yes, for the assessment itself, provided the team understands the criteria and keeps a documented record. CC3.4 asks the organization to identify and assess changes that could significantly affect internal control, and the assessment is management's work. The part that usually benefits from outside help is the independence and quality check: a second reviewer who tests whether the assessment is complete and whether the resulting system description is accurate. Only the independent CPA firm issues the report. An implementation partner such as DeployOpen can prepare systems, controls and evidence for that review, but it cannot opine on the result. Confirm in writing which tasks are yours, which are the partner's and which the auditor will check.

What happens if we discover a significant change late?

A late discovery is a problem to disclose and document, not a reason to hide it. Under the description criteria, the system description must cover significant changes during the period, so the first step is to tell the auditor and record when the change happened, what it affected and what controls were applied. The auditor will then test whether the change was assessed and whether the affected controls operated throughout the period. Depending on the timing and effect, the result may be an exception in the report or a broader finding. Ask your auditor how they handle late-identified changes before the examination starts, so that remediation evidence is collected while the facts are fresh.

How DeployOpen prepares systems and evidence after a change

After an acquisition, a new product or a platform move, DeployOpen works inside your own infrastructure to bring the changed systems under the controls your SOC 2 describes and to prepare the evidence an independent CPA firm will test. DeployOpen prepares systems and evidence only. Your organization owns its controls, and the auditor issues the report.

How we scope

Written scope lists the acquired systems, new product components or migrated platforms to be brought into the system description.
Scope records which changes occurred during the period and which controls under CC3.4 and CC8.1 they affect.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

Controls for the changed environment are configured in your cloud accounts, data centers or air-gapped networks, aligned to your existing control matrix.
Change records cover authorization, design, configuration, testing, approval and deployment for each change touching infrastructure, software or procedures.
Open-source platforms are hardened and integrated so logs, access records and change tickets can be produced for the auditor.

How we hand over

Documentation covers the updated system description inputs, control ownership, and the evidence location for each control affected by the change.
Evidence packages are organized by control and period so your CPA firm can sample items without rebuilding the record.
Your team receives runbooks and training so controls keep operating after the engagement closes.

How we support

Ongoing support, upgrades and continuous testing are available as retainers for systems that keep changing between audit periods.
Follow-up reviews can check that new components stay inside scope as the business and its vendors change.
Confirm with your CPA firm early which changes they expect to see disclosed in the report, since the auditor decides what the examination covers.

SOC 2 after an acquisition, new product or platform change