This series has spent four posts on putting companies together. The finale is about taking them apart — because if a merger is the hardest thing most IT organizations ever do, a divestiture is the hardest thing most of them have never done. And the skills don’t transfer as cleanly as you’d hope.
A merger combines two environments that, whatever their flaws, each work. A carve-out asks you to extract a living business from inside an environment that was never designed to come apart — and to do it against a contractual clock, with lawyers checking the work. Here’s the structural problem in one sentence: your tenant is organized by how people collaborate; the deal is organized by what was sold. Those two maps have never once agreed.
The perimeter is a legal fiction your directory has never heard of
In a merger, the boundary is obvious — two tenants, two directories, a line down the middle. In a divestiture, the boundary exists only in the purchase agreement. Somewhere in a definitions section, lawyers have specified what conveys: these employees, these products, these contracts, this intellectual property. Nothing in your environment is organized that way.
Fifteen years of collaboration have entangled everything. The divested division’s engineers sit in shared Teams with retained-business colleagues. Their documents live in sites owned by departments that aren’t part of the deal. Shared mailboxes, shared distribution lists, shared service accounts, applications licensed to the whole company and used by half of it. The finance model for the divested product line sits in a workbook that also contains the retained businesses’ numbers — one file, two owners, per the contract.
This creates a security problem with two failure modes, and they punish you in opposite directions. Under-extract, and the divested company can’t operate — a commercial crisis with penalty clauses attached. Over-extract, and you have handed a third party — sometimes a competitor, often a private equity firm mid-roll-up — data that was never part of the deal: retained IP, other business units’ pricing, employee records of people who still work for you. Under-extraction is embarrassing and expensive. Over-extraction is a breach you executed yourself, on schedule, with project funding.
On one carve-out I supported, the perimeter mapping exercise found that a material fraction of the divested unit’s working documents lived in repositories the deal perimeter didn’t touch — and, in the other direction, that sites slated to convey were salted throughout with retained-business content that had accumulated there through years of ordinary collaboration. Nobody had done anything wrong. That’s precisely the problem: entanglement is what healthy collaboration looks like, right up until a purchase agreement demands you undo it.
The TSA is a countdown timer on your risk
Most carve-outs run through a Transition Services Agreement: the seller keeps operating the divested company’s IT — often inside the seller’s own tenant — for a fixed period after close. The TSA is priced to expire; extensions are expensive by design, and the exit date was negotiated by people optimizing the deal, not the migration.
Think about what the TSA period actually is, security-wise: two legally separate companies — with separate obligations, separate regulators, and potentially competing interests — operating inside one tenant, under one identity plane, with collaboration patterns built for the days when they were one firm. The seller’s CISO is now running an environment where a portion of the user base works for someone else, where every over-broad permission group is a live cross-company disclosure, and where offboarding governance is ambiguous by construction: whose leaver process applies to a divested-company employee in the seller’s directory?
This is the one scenario in enterprise IT where information barriers stop being a compliance abstraction and become the load-bearing wall. Segmenting conditional access, search, and sharing between two populations in a single tenant — without breaking the collaboration the TSA explicitly obliges you to provide — is genuinely hard, and it is the defining security engineering problem of the TSA period. Most organizations discover it exists in week three.
Separation you can’t prove didn’t happen
A merger ends with a working combined environment, and everyone can see that it works. A divestiture ends with an assertion: the data that should have conveyed, conveyed; the data that shouldn’t, didn’t; and the access that should have ended, ended — in both directions. That assertion goes to lawyers, sometimes to regulators, and occasionally to a courtroom years later. ‘We’re pretty sure’ is not an exhibit.
So the deliverable of a carve-out is not just a separated environment — it’s the evidence of separation. What was in scope, what moved, what was excluded and why, whose access was terminated and when, verified against the deal perimeter rather than against the project plan. Building that evidence retroactively, after the engineers who did the work have rolled off, is somewhere between expensive and impossible. Building it as you go is a design choice available only at the start. On our carve-outs this is where Orbit has been decisive — a continuously maintained record of separation state, wave by wave and object by object, means the closing attestation is an export, not an investigation. However you achieve it, the standard is unforgiving: if you cannot prove what crossed the boundary, you have not finished the divestiture; you’ve just stopped working on it.
Running the carve-out like it matters
The program follows from the three problems. Map the entanglement before committing to the TSA exit date — perimeter discovery, run against the deal definitions, is the carve-out’s equivalent of the merger’s identity discovery, and skipping it converts the TSA deadline from a plan into a bet. Stand up information barriers as the first workstream of the TSA period, not a remediation after the first incident. Classify as you extract, because every object crossing the boundary is a conveyance decision — the deal perimeter, not the folder structure, is the authority. And design the evidence pack on day one, because separation is a claim you will someday have to prove.
The takeaway — and the series in one paragraph
Five posts, one argument: M&A is not a project that security supports — it is a security program that the business happens to call a deal. The attack surface transfers at close, before anyone migrates anything. Identity is the substrate, not a workstream. Data obligations arrive with ownership, not with visibility. Unscoped work is ungoverned work. And separation, when it comes, must be provable, not merely finished. The organizations that internalize this don’t move slower through their deals — they move through them once, with the governance intact and the evidence in hand. That, more than any tool or timeline, is what it means for security to own the merger.
This concludes the Security Owns the Merger series. Cyclotron’s M&A practice helps security leaders own the deal lifecycle — merger, integration, and carve-out — from Day 1 trust design through tenant consolidation and separation, with Orbit providing the confidence layer across the entire engagement.