When You Buy a Company, You Buy Its Security Debt
The deal closes Friday. The wire transfers. The champagne comes out. And somewhere in a data center that used to belong to the company you just acquired, there is a server running Windows Server 2012 R2 with RDP exposed to the internet, credentials unchanged since 2018, holding four years of customer payment records that you now legally own.
You will find out about it in about six months when someone breaches it.
This is how cybersecurity works in mergers and acquisitions: the deal team runs months of financial, legal, and operational due diligence, and security gets a questionnaire that asks whether the target has a firewall and antivirus software. The acquirer closes with a confident spreadsheet about EBITDA margins and almost no reliable information about the actual state of the technical environment they just purchased.
That information gap has a cost. The acquirer owns the security debt from the moment of close, regardless of what the target's security questionnaire said.
What Standard Due Diligence Misses
The typical M&A security process goes something like this. The target company completes a self-assessment questionnaire covering their security practices, policies, and major certifications. The buy-side team reviews it, notes any obvious gaps, and potentially asks a few follow-up questions. A consultant may do a brief review of documented controls.
What this process reliably misses: the actual technical environment. Questionnaires capture what the target believes or wants to believe about their security posture. They do not surface the legacy system nobody remembers that is still connected to the network, the former employee's account that was never disabled, the cloud storage bucket that has been publicly accessible since a junior developer created it for a demo in 2021, or the critical software with a known vulnerability that has been sitting in the patching queue for eight months.
The distance between the self-assessment and the ground truth is the security debt you are buying. In many deals, that gap is substantial and would have materially affected valuation or deal terms if it had been visible.
Technical Due Diligence Is Different From Policy Review
Real security due diligence in M&A is technical, not documentary. It means running actual scans against external infrastructure to see what is exposed and what vulnerabilities are present. It means reviewing authentication and access management configurations rather than just reading the policy that describes how they are supposed to work. It means interviewing the people who actually manage the security infrastructure, not just the CISO presenting to the deal team.
The findings in well-run technical due diligence are consistently different from what the questionnaire suggested. External attack surface exposure that was described as managed shows misconfigured assets. MFA that was described as fully deployed shows exceptions for legacy systems and contractors. Backup processes that were described as comprehensive show gaps in the systems that matter most.
The gap is not always intentional misrepresentation. Security teams often genuinely believe their controls are in better shape than they are, because they lack visibility into their own environments. Due diligence that accepts the target's self-assessment at face value is accepting a best-case description of a situation that may look very different under examination.
The Timeline Pressure Nobody Talks About
Even when technical due diligence surfaces significant findings, the M&A timeline creates pressure to minimize them. Deal teams have momentum. Money is committed, relationships are built, and a close date has been announced. Security findings become deal risks to manage rather than information to act on, and the most common way to manage them is to accept a representation and warranty from the target that nothing they disclosed is materially false.
Representations and warranties are a legal mechanism, not a security one. A breach that occurs post-close because of a pre-close vulnerability does not un-happen because the target's lawyers wrote a warranty. It happens, you own it, and you spend the next six months dealing with the incident while also trying to integrate the company you just acquired.
The organizations that handle this well negotiate security-specific escrow arrangements for significant findings, tie a portion of the purchase price to remediation of defined vulnerabilities, or push for a security hold-back that releases only when the integration team has verified the most critical gaps are closed. These mechanisms are not common because they require security to be involved early enough in the deal process to influence terms, which is itself not common.
The Integration Period Is Its Own Risk Window
Post-close integration is when many M&A security incidents actually happen. Connecting two networks with different security postures, different access management practices, and different logging and monitoring creates a period of elevated exposure that is difficult to manage well.
The acquiring company's security controls may not extend to the acquired entity for months. Active Directory consolidations take time. Network integration requires careful planning to avoid creating paths between environments with very different trust levels. The people who understood the acquired company's security architecture are not always still there by the time integration is underway.
The standard approach is to treat the acquired entity as untrusted infrastructure during the integration period: no direct connectivity to production systems, careful monitoring of any cross-environment traffic, and explicit sign-off from security before any network bridging goes live. This is the correct approach and it is frequently ignored because it slows integration timelines that are themselves being measured on a schedule.
When to Get Security Involved
The answer that sounds obvious after the fact is: before the term sheet. Security due diligence that happens alongside legal and financial due diligence can influence valuation, deal structure, and representations. Security due diligence that happens after close can only inform remediation.
The practical version for most organizations is to get technical security resources involved as soon as the deal moves to confirmed diligence, with explicit scope to run external reconnaissance and request technical access for internal assessment. The cost of that work is negligible against deal size. The alternative is discovering the 2012 server with RDP exposed and customer data on board after the wire has already transferred.
The deal may be excellent. The financial model may be sound. The integration plan may be thorough. None of that changes what is running on the other company's infrastructure. And from the moment that deal closes, all of it is yours.