Buying a company means buying its data, its infrastructure, and every unresolved vulnerability sitting inside it, whether anyone disclosed those vulnerabilities or not. Financial due diligence has a decades-old playbook. Legal due diligence has one too. Cybersecurity due diligence is still catching up, and the gap between how seriously buyers treat cyber risk and how seriously they should is exactly where deals go wrong after close.
The scale of the problem, in numbers
More than half of organizations involved in M&A activity report encountering a critical cybersecurity issue during a deal serious enough to put the transaction itself at risk, and a majority say they've experienced real regret over a completed acquisition specifically because of cybersecurity concerns that surfaced too late . An overwhelming majority of decision-makers treat an undisclosed data breach at a target company as an immediate deal-breaker once it's found , which raises an obvious question: how many of those breaches are being found before close instead of after.
The honest answer is not many. Industry estimates suggest only around one in ten M&A deals gets a genuinely thorough cybersecurity due diligence assessment, even as roughly 84% of M&A professionals expect scrutiny of cyber risk to increase significantly over the next one to two years . That gap between rising expectation and low actual coverage is exactly where inherited risk hides. Boards are paying attention to the downside: a majority of directors say discovering major security vulnerabilities during diligence would likely affect their final decision on a deal, and a significant share say a high-profile breach at a target would meaningfully lower the valuation they're willing to pay .
The pattern across all of this data points to the same conclusion. Cyber risk is now a valuation driver, not a compliance footnote, and treating it as an afterthought handled during post-close integration is how buyers end up owning problems they never priced into the deal.
Why traditional due diligence doesn't catch this
Financial due diligence audits the balance sheet. Legal due diligence audits contracts, litigation exposure, and regulatory standing. Neither one is built to answer a completely different question: is this company's technical infrastructure actually secure, or does it just look fine on paper. A target's SOC 2 report, if one even exists, attests to controls being in place. It doesn't confirm that those controls hold up against actual exploitation attempts, and it's frequently months out of date by the time diligence starts.
This is exactly the gap a technical security assessment is built to close, and it's a gap most deal teams aren't equipped to close themselves. A significant share of decision-makers admit their internal IT teams aren't given adequate time to properly review a target's cybersecurity posture before a deal closes, and a similar share doubt their teams even have the specialized skills required to run that kind of assessment competently . That's not a criticism of internal IT. Vulnerability assessment and penetration testing are specialized disciplines, and deal timelines rarely leave room to build that capability internally mid-transaction.
What actually needs to be assessed
A proper cybersecurity due diligence engagement covers the same layers a standard security audit does, scoped specifically to answer acquisition-relevant questions rather than general hygiene.
Internet-facing assets and application security. Every website, API, and exposed service the target operates needs evaluation the way an external attacker would approach it. This is where broken access control, exposed credentials, and unpatched software with known vulnerabilities typically surface first, and it requires no privileged access to test, which makes it the fastest layer to assess even under a tight diligence window.
Cloud and infrastructure configuration. Overly permissive IAM roles, exposed storage buckets, and misconfigured network rules are common in fast-growing companies where security review historically took a back seat to shipping speed, exactly the profile of many acquisition targets. This layer matters especially in a deal context, because cloud misconfigurations are often invisible from the outside and won't show up in a target's self-reported security questionnaire.
Identity and access management. How authentication is structured, whether privileged accounts are properly scoped, and whether role boundaries actually enforce what they claim to, all need verification with test access. This layer becomes critical the moment integration planning starts, since combining user directories, single sign-on systems, and access policies between acquirer and target is one of the most common sources of new vulnerabilities introduced after close, not before.
Data handling and compliance posture. What sensitive data the target actually holds, where it lives, how it's protected, and whether compliance claims like SOC 2 or PCI DSS attestations are current and accurate rather than stale documents nobody has revisited since the last audit cycle.
Breach history and unresolved findings. Any prior security assessments, incident history, and outstanding remediation items the target has on record. A target that can produce a recent, clean vulnerability assessment report is a fundamentally different risk profile than one that has never had independent testing done, or one sitting on findings it never actually fixed.
Third-party and vendor exposure. The target's own vendor relationships, integrations, and shared credentials extend your risk surface the moment the deal closes. A target with weak vendor management inherits every one of its suppliers' security problems, and after acquisition, so do you.
Legacy technical debt. Acquisition targets, especially earlier-stage companies, frequently carry outdated dependencies, deprecated infrastructure, and undocumented systems built under time pressure. None of that shows up in a cap table or a contract review. It shows up in a technical assessment, and it's often where the most expensive post-close surprises live.
Choosing the right depth of testing for the deal timeline
Not every deal needs the same depth of technical scrutiny, and matching the assessment to the transaction size and timeline is what makes cyber due diligence actually achievable rather than a bottleneck that stalls the deal.
For smaller or mid-market acquisitions, a scoped vulnerability assessment covering the target's internet-facing assets, APIs, and cloud accounts is usually sufficient to surface the highest-impact risks within a realistic diligence window. This is the fastest layer to execute, requires no internal access from the target, and can be scoped and delivered quickly enough to fit inside a standard diligence timeline without becoming the reason a deal slips.
For larger transactions, regulated industries, or any deal where the target holds particularly sensitive data, a deeper penetration test becomes worth the additional time and cost, especially one that includes authenticated access across identity and access management. This is where a manual-augmented, exploitation-focused engagement earns its place, verifying not just what's exposed but how far an actual attacker could get once inside.
The practical approach most experienced buyers land on: run a fast vulnerability assessment early, often pre-LOI or immediately after, as a screening step to catch obvious dealbreakers before investing more time, then scope a deeper penetration test during formal diligence if the deal size and risk profile justify it. Frontier AI-driven assessment makes the first step realistic even under compressed timelines, since a scoped audit against a target's external attack surface can start the same day and deliver verified findings fast enough to actually inform a moving deal process instead of trailing behind it.
Where cyber findings actually change deal terms
Findings from a technical assessment aren't just informational, they're negotiating leverage. A clean report supports the valuation as presented. A report showing unresolved critical or high-severity findings gives a buyer grounds to negotiate a price adjustment, request an escrow holdback tied specifically to remediation, or in the most serious cases, walk away entirely. Representation and warranty insurance is increasingly factoring cyber risk into underwriting too, and a policy is far less likely to respond cleanly to a post-close breach that originated from a condition that existed, and was discoverable, before the deal closed. Buyers who skip the technical assessment aren't just skipping information. They're skipping the evidence that would have let them price the deal correctly or negotiate around what they found.
What happens after close matters just as much
The moment a deal closes, the target's infrastructure becomes part of your attack surface, whether integration has actually happened yet or not. A pre-close assessment answers what the target's security posture looked like on the day it was tested. It doesn't answer what it looks like six months into integration, once systems start connecting, credentials start merging, and the combined entity's attack surface looks nothing like either company's did independently.
This is exactly why the acquisitions that go well from a security standpoint treat the pre-close assessment as the starting point, not the finish line. Rolling the newly acquired company into a recurring quarterly assessment cadence, rather than treating cybersecurity due diligence as a one-time deal gate, catches the vulnerabilities that integration itself introduces: newly connected systems, merged identity providers, and infrastructure that's being actively reconfigured during the exact window when it's most likely to be temporarily misconfigured. A target that looked clean on the day of the pre-close audit can look very different three months into integration, and the only way to know is to keep testing.
Building this into your deal process
The practical framework for buyers: scope a vulnerability assessment against the target's internet-facing assets and cloud infrastructure as early in the process as access allows, ideally before final terms are locked in. For larger or higher-risk deals, layer in a deeper penetration test covering identity and access during formal diligence. Use the findings as real negotiating input, not just a compliance checkbox to file away. And once the deal closes, don't let the assessment stop there, fold the newly acquired environment into a recurring audit cadence so the security posture you priced the deal on doesn't quietly drift the moment integration begins.
Cyber risk in M&A stopped being a niche concern years ago. The buyers still treating it as an afterthought are the ones most likely to discover, after the wire transfer clears, exactly what they actually bought.