Inheriting a Compliance Program: The First 90 Days After an Acquisition
By Kenio Shirley · · 7 min read
What diligence does not surface, and the order to fix it in once the deal has closed.
Technical diligence is good at inventory. It will tell you the target holds a SOC 2 Type 2 report, signs business associate agreements, runs on a major cloud provider and had no reportable incidents in the last two years. All useful. None of it tells you the thing that actually matters after close: whether the control environment keeps functioning while you merge two engineering organizations.
It usually does not, and the reason is mundane. Controls are implemented in tooling, and integration replaces tooling. The identity provider changes. The ticket system changes. The pipeline is consolidated. Each of those migrations is run by an engineering team on a delivery deadline, and each one quietly severs a control from its evidence. Nine months later, an auditor asks for the change population spanning the migration and there are two partial systems of record and a gap in the middle.
Obligations transfer at close. Capability transfers over quarters. The distance between those two dates is where post-acquisition findings live.
Days 1–30: establish what you actually inherited
Before changing anything, write down the current state in the terms an auditor will use.
- Obligation register. Every commitment made to a customer, regulator or partner. Business associate agreements under HIPAA, contractual SOC 2 commitments, uptime and breach-notification clauses, data-residency promises. Contracts do not renegotiate themselves because ownership changed. HHS, Business Associates under HIPAA
- Control-to-tool map. For each control in the target’s most recent report, name the system that produces its evidence. This document becomes the veto list for integration planning.
- Evidence retention. Where does historical evidence live, who pays for that account, and what happens to it when the vendor contract consolidates? Evidence deleted during a tooling migration cannot be reconstructed, and the audit period does not restart because you were busy.
- Population boundaries. Which environments are in scope for which report. Acquired products often have in-scope and out-of-scope systems sharing infrastructure, and that distinction rarely survives a first-pass integration diagram.
Days 31–60: protect the evidence chain through migration
This is the phase where damage is done, so it deserves the strongest rule: no control-bearing system is decommissioned until its replacement produces equivalent evidence and both have run in parallel across a full reporting cycle.
Concretely, that means three things.
Freeze the join key
Before consolidating pipelines, agree on the identifier that links a deployment to its change record on both sides. Without it, the population spanning the migration cannot be reconciled and you will be matching timestamps by hand a year later.
Migrate access last, and with a reconciliation
Identity consolidation is the highest-risk single step. Access reviews depend on a stable roster, and merging directories mid-period produces users who existed in neither system according to the exports. Run the migration with a before-and-after entitlement snapshot and keep both.
Keep the old system readable
Read-only retention of the legacy ticket system and pipeline logs for the full retention period costs a fraction of what reconstruction costs. This is the single cheapest insurance in an integration budget and the first line cut when nobody speaks for it.
Days 61–90: rebuild the control, do not port it
Once the evidence chain is safe, the interesting work starts. An acquired control environment is usually the artifact of a smaller company’s constraints: manual approvals because there was no pipeline gate, weekly review meetings because there were twelve engineers, spreadsheets because a tool was not worth buying.
Porting those practices into a larger organization scales the cost without scaling the assurance. The better move is to re-derive each control from what the framework asks for. SOC 2 CC8.1 asks that changes be authorized, designed, tested, approved, documented and implemented — it does not specify a meeting or a spreadsheet. AICPA, Trust Services Criteria NIST SP 800-53 CM-3 asks for documented, impact-analyzed, tracked change control. NIST SP 800-53 Rev. 5, CM-3 Both are satisfiable by a pipeline that records what it did.
Integration is the rare moment when rewriting a control is cheaper than maintaining it. Everything is already moving; the only question is what it moves into.
The HIPAA-specific trap
If either party is a business associate, the covered-entity relationships come with the deal and the obligations are direct, not inherited by courtesy. Two items need attention inside the first quarter: whether existing business associate agreements survive the change of control on their own terms, and whether subcontractor agreements downstream still name the right entity. HHS, HIPAA Security Rule Neither is engineering work, but both land on engineering when the answer is no and a data flow has to change.
What good looks like at day 90
- One reconciled change population covering the pre-close period, the migration window and the current state, with a documented join key.
- An obligation register that a non-engineer can read, mapped to the systems that satisfy each line.
- Legacy evidence retained read-only, with an owner and a funded retention date.
- Approvals moved into the pipeline for the routine majority of changes, with the review forum reserved for changes that carry genuine coordination risk.
- A written list of the controls you deliberately chose not to port, and why — because the next auditor will ask, and “it changed during integration” is a much weaker answer than a dated decision.
The short version
Diligence buys you a snapshot. The first ninety days decide whether the control environment described in that snapshot still exists at the next audit. Map controls to tools before you touch either, never decommission ahead of a parallel run, protect the join key and the evidence archive, and use the disruption to rebuild controls around the pipeline instead of carrying someone else’s manual process into a bigger company.