If you’ve spent any time on the security side of M&A, you’ll recognize this scenario immediately. The deal is two weeks from close. Legal sends over a request: “Here’s an infrastructure setup you’ve never seen — can you complete a security assessment in ten days so we can get sign-off?” The deal timeline doesn’t care about security thoroughness. The stakeholders want to connect this new chunk of risk to your company’s infrastructure as soon as possible, and your job is to rubber-stamp it or hold up a transaction that dozens of people have been working on for months.
At best, you can convince the legal team to fold a security remediation roadmap into the deal terms. But that only works if you know what you’re doing — and if you avoid the mistakes that turn M&A security assessments into theater. Having led security for transactions including the $69 billion Activision Blizzard King acquisition and multiple divestitures at Microsoft, I’ve seen the same pitfalls surface repeatedly. Here’s what they are and how to avoid them.
Mistake #1: Treating security as a gate, not a process
Every stakeholder involved in an acquisition treats security as a gate — a single checkpoint that needs to be cleared before the deal moves forward. Once cleared, security becomes a backburner task with no accountability.
This creates several compounding problems. Under time pressure, security teams triage toward critical findings only, leaving medium and low-severity issues undocumented. Band-aid solutions get applied to infrastructure that was never designed for security assessment. And the moment the gate is passed, ownership of identified issues evaporates — because no one defined who was responsible post-close.
The fix is structural: replace the single gate with multiple checkpoints at defined stages — before the letter of intent (LOI) stage, during due diligence, at close, and at 30/60/90 days post-close. Each checkpoint has a bounded scope and defined deliverables. Security stays in the process rather than exiting it. Here is how I would design minimal checkpoints at each critical stage of an acquisition and build security into key decision-making processes:

Mistake #2: Scoping against declared assets instead of actual data flows
Acquired companies frequently don’t have accurate asset inventories. They’ll hand you a list, but that list will be incomplete — shadow IT, legacy systems that were never decommissioned, third-party integrations that aren’t documented anywhere. As a security engineer, you know the real risk lives in the connective tissue, not the declared inventory. And yet, most M&A security assessments start and end with whatever the acquired company hands over.
The problem is compounded by incentives. The acquired company’s team wants the deal to close. They’re not deliberately hiding risk — but they’re also not going to volunteer that the marketing team has been running an unsanctioned SaaS tool with access to customer data for the past three years, or that a legacy system nobody uses anymore is still sitting on the network with default credentials. That information exists. It just doesn’t appear on any list they’re going to give you.
This is why Step One of any M&A security assessment should be independently validating the scope — not accepting it. Before you assess anything, get a crystal clear picture of what you’re actually looking at. An assessment that covers 10% of the real infrastructure and finds three low-severity findings is not a clean bill of health — it’s a gap with a stamp on it. And a gap with a stamp on it is worse than no assessment at all, because it creates false confidence.
Mature M&A security programs validate asset lists using multiple independent methods: external attack surface detection tools that scan for internet-facing systems regardless of what was declared, internal network scans, and third-party penetration test reports from the acquired company’s own security history. Cross-referencing these sources against the declared asset list will almost always surface discrepancies. Those discrepancies are your first findings — before you’ve even begun the formal assessment.
The goal is to build your own picture of the actual data flows and system dependencies, independent of what the acquired company hands you. Treat the declared asset list as a starting hypothesis, not a source of truth. What you find when you validate it — the undeclared systems, the forgotten integrations, the shadow IT — is often more revealing than anything in the formal assessment that follows.
Mistake #3: Failing to define security debt ownership before close
Vulnerabilities get identified, the deal closes, and six months later, nothing has been remediated — because no one was ever assigned to fix it. This happens everywhere in security, but it hits M&A particularly hard. Post-acquisition workforce changes blur team boundaries. Integration plans shift ownership structures. What was clearly one team’s responsibility before it becomes nobody’s problem after it.
The solution? A pre-close remediation roadmap: a documented record of every identified issue, who owns it, and what the expected resolution timeline is. Even a simple spreadsheet with these fields builds accountability that survives the organizational turbulence of integration. An easier way to bookkeep ownership is to keep ownership at the executive level rather than individual teams, where possible — executives survive reorgs better than individual contributors do.
One technique I’ve found effective: quantify security risks in business terms for executive stakeholders. Rather than reporting a critical vulnerability in technical language, translate it — what is the acquisition risk impact if this isn’t fixed? What is the financial or reputational exposure? Build a risk table or a risk register for the deal and share it with all stakeholders. Recurring reports in this format keep leadership informed and maintain pressure on remediation timelines long after close.
What good looks like
A few principles that define mature M&A security programs:
Start early. No one can do meaningful due diligence in ten days, and no one should be expected to. If security isn’t in the room at the letter of intent (LOI) stage, you’re already behind.
Scope broadly. Your assessment is only as good as the depth of your scope. Validate asset lists independently rather than accepting what the acquired company provides.
Define ownership before close. A remediation plan without named owners is a wish list. Build accountability into the deal terms where possible.
Treat the acquired security team as an asset. The people who built and maintained that infrastructure know where the gaps are. Bring them in early and listen to what they tell you. Ultimately, you are the security gate. Everything the organization inherits — the vulnerabilities, the technical debt, the undocumented integrations — gets signed off by you or your team. The question is whether you’re signing off with confidence on your assessment or signing off on a gap you haven’t yet found.




















