So integrations slip. Everyone knows this; it’s practically a law of nature, grimly joked about in every steering committee. What’s less discussed — and why this is a security column and not a project-management one — is what happens to the work that gets discovered mid-flight. It doesn’t get removed. It doesn’t usually even get formally added. It gets absorbed: done quickly, off-plan, by whoever is available, under schedule pressure, with none of the review the planned work received.
That’s the thesis of this post: unscoped work is ungoverned work. Scope discipline in M&A isn’t a commercial nicety or a consultant protecting margin. It is the mechanism by which the integration stays inside its own risk management.
Where the invisible scope comes from
The mid-flight discoveries follow a pattern so consistent you could print it on a bingo card. The application inventory was off by a third, and the missing third includes the ones with hard-coded authentication. A whole collaboration platform — file shares, an old intranet, a SaaS tool procured by one department — turns out to hold business-critical data and appears in no plan. The ‘simple’ environment has a subsidiary with its own tenant. Retention obligations surface that nobody flagged. Each discovery arrives with the same framing: it’s urgent, it’s blocking, and there’s no time to re-plan around it.
On one large integration, we paused mid-program and walked the forecast line by line against what the engagement had actually been asked to absorb. The reconciliation surfaced hundreds of hours of work that had quietly accreted onto the program — real work, work somebody genuinely needed — that appeared nowhere in the agreed scope. Some of it was explicitly excluded in writing. It had crept in anyway, one urgent hallway request at a time. And here is the part that should concern a security leader more than a CFO: essentially none of that absorbed work had been through any risk review. It wasn’t in the plan, so it wasn’t in the assurance either. Firewall changes, access grants, data moves — executed competently, documented nowhere, reviewed by no one.
Knowledge is a dependency with a departure date
The second unscoped force is quieter and more corrosive: the people who understand the acquired environment leave. Retention packages run out. The best engineers read the org chart’s future and act on it. And in most acquired environments, the documentation is the people — the reasons behind the strange firewall rule, the undocumented job that feeds the finance system, the service account nobody dares touch, all of it lives in the heads of individuals with, at best, a twelve-month retention agreement.
Integration plans model systems as the dependency. In practice, the binding dependency is institutional knowledge, and it has an expiration date the plan doesn’t show. When it walks out the door, the remaining team doesn’t stop making changes to the environment — they keep making them, minus the person who knew why things were the way they were. From a security standpoint, that’s when an environment becomes genuinely dangerous: still in production, still connected to yours, and newly unexplainable.
Change control is a security control
Here’s the reframe I push on every program: the integration plan is not a schedule. It is the documented basis for every assurance you’ve given — to your board, your auditors, your regulators — about how this merger is being governed. Risk assessments were performed against that plan. Day 1 trust boundaries were designed against it. When reality diverges from the plan and nobody formally reconciles the two, those assurances don’t degrade gracefully. They just quietly stop being true.
Which is why a good change request is not paperwork. It’s the act of forcing the plan back into agreement with reality — and re-running the risk conversation against what’s actually happening rather than what was originally imagined. The change requests that matter aren’t the date-slip formalities; they’re the ones that anchor scope: this was discovered, this is now in, this remains explicitly out, and here is who reviewed the risk of the delta. A program that has never issued a scope-anchoring change request isn’t a program without scope change. It’s a program absorbing scope change invisibly.
Running it differently
The countermeasures are organizational, not technical, and none of them are exotic. Gate the timeline behind discovery: a few weeks of structured discovery before dates are committed converts the plan from fiction to forecast, and it is always cheaper than the re-plan it prevents. Write down what is out, not just what is in: an explicit exclusion list is the single most powerful scope artifact, because invisible scope creeps through ambiguity, not through argument. Treat knowledge transfer as a deliverable with a deadline: structured documentation and shadowing sessions scheduled against retention windows, tracked like any other workstream, with the gaps analyzed before the experts leave rather than after. And instrument plan-versus-actual continuously: drift between what was planned and what is actually happening is the earliest signal of ungoverned work. This is a place Orbit has changed the conversation on our programs — when the current state of every wave and workstream is visible against the plan, scope drift shows up as data in week two instead of as a crisis in month six. But with or without tooling, the discipline is the same: someone must own the delta between the plan and the truth, and they must own it every week, not at the retrospective.
The takeaway
When a merger goes sideways, the post-mortem always finds the same thing: not a single catastrophic decision, but months of small, urgent, unreviewed ones — work nobody scoped, done by people nobody briefed, changing an environment nobody fully understood anymore. None of it looked like a security event at the time. Scope discipline, exclusion lists, knowledge-transfer deadlines, change control with teeth: these are unglamorous instruments. They are also how a security leader keeps the merger governed while it’s still cheap to govern. The alternative is finding out at the incident review exactly how much of your integration happened off the books.
Next in the series: Divestiture Is a Merger in Reverse — And Harder — carve-outs, tenant splits, and the TSA clock: why separating two companies is the sternest test of everything this series has covered. Cyclotron’s M&A practice helps security leaders own the merger — from Day 1 trust design through tenant consolidation, with Orbit providing the confidence layer across the entire integration.