A deal team runs the cybersecurity section of diligence. The target company has an antivirus product deployed across endpoints. They have a firewall. They have a written information security policy, dated and signed. They completed a SOC 2 Type II audit eleven months ago.

Every box on the questionnaire gets a green check.

Sixty days after close, the acquirer’s IT integration team pulls the target’s patch management logs. The last full patch cycle across the server environment finished nineteen months ago. Three of the domain administrator accounts belong to people who left the company more than a year prior. A former IT contractor still has active VPN credentials.

None of that showed up in diligence. All of it is now the acquirer’s problem.

This scenario is not rare. It is the standard outcome when cybersecurity due diligence is run as a documentation review instead of an actual assessment.

The Difference Between Security Documentation and Security Reality

Financially sophisticated buyers know cybersecurity matters in a transaction. They order the cyber section of the QoE. They ask for the security policies. They confirm certifications. They check the box.

Then they move on to the parts of the deal they find more interesting.

The problem is that a security policy tells you what the company said it does. A compliance certification tells you what an auditor validated on a specific set of dates. Neither one tells you what the security posture actually looks like today.

That distinction is where inherited liability lives.

What Standard Cybersecurity Due Diligence Actually Assesses

Walk through a typical M&A cybersecurity checklist. Here is what it confirms:

• The target has purchased and deployed endpoint protection software

• A firewall exists at the network perimeter

• A written security policy has been drafted and signed

• Multi-factor authentication is enabled for at least some systems

• The company holds a current SOC 2, ISO 27001, HIPAA, or similar certification

Each item is answered yes or no. The yes answers are treated as evidence of a functioning security program.

They are not. They are evidence that the company has invested in the visible artifacts of a security program.

The visible artifacts and the operational reality can be very different things. An antivirus product installed on every endpoint tells you nothing about whether definitions are current, whether alerts are being triaged, or whether the tool has been in a broken state for six months. A firewall tells you nothing about the rule set inside it. A signed security policy tells you nothing about whether anyone follows it.

The checklist confirms procurement. It does not confirm posture.

The Four Questions That Surface Real Cybersecurity Liability

To move from documentation review to actual assessment, four questions do most of the work. Each one targets a specific area where inherited liability accumulates quietly and surfaces expensively after close.

1. When Was the Last Full Patch Cycle, and What Is the Current Backlog

Every operating system, application, and firmware component in the target environment has a patch stream. Vendors release security patches on a cadence. The security posture of the environment is a direct function of how quickly those patches get applied.

Ask for the patch management logs. Ask for the date the last full patch cycle completed across servers, workstations, network devices, and firmware. Ask for the current count of missing critical and high-severity patches by category.

A well-run environment shows a monthly or quarterly full cycle with a backlog of critical patches in the single digits. An environment with a nineteen-month-old patch cycle and hundreds of missing critical patches is carrying real, quantifiable risk. That risk transfers on close.

Patch backlog is one of the clearest indicators of operational maturity in an IT organization. It is also one of the easiest things to hide behind a green checkbox on a questionnaire.

2. Who Has Privileged Access, and What Controls Sit Around It

Privileged access is the top vector in modern breaches. Ransomware operators, nation-state actors, and opportunistic attackers all target the same thing: an account with administrator rights.

The right question is not “does the company have privileged access controls.” The right question is a full inventory:

• How many accounts have domain administrator, global administrator, or equivalent rights?

• Is MFA enforced on every one of them, including service accounts and break-glass accounts?

• What is the offboarding process when a privileged user leaves the company, and how quickly does it execute?

• Is there a Privileged Access Management (PAM) system in place, or are admin credentials sitting in a password vault that anyone with enough access can query?

The offboarding question is the tell. Ask for the list of accounts with administrator rights, then cross-reference it against the current employee roster and the list of terminations over the last twenty-four months. Orphaned admin accounts are common. They are also how a former IT contractor becomes an active threat vector months after their engagement ended.

3. Has There Been a Breach or Near-Miss in the Last 24 Months

This question requires more than a yes or no. It requires the incident log.

Ask for every security incident logged over the last twenty-four months, including near-misses. Ask what the incident was, how it was detected, how it was contained, and whether it was disclosed to regulators, customers, or partners.

Two things matter here.

First, the incidents themselves. A breach that touched customer data creates disclosure obligations under state breach notification laws, HIPAA if the target handles PHI, SEC rules if the target is public or has public reporting obligations, and sector-specific regulations depending on industry. Undisclosed incidents at the target become the acquirer’s disclosure problem after close.

Second, the response quality. How the target handled a past incident is a strong signal of how they will handle the next one. An incident that was detected within hours, contained cleanly, and documented completely tells you a functioning security operation exists. An incident that was detected weeks later because a customer called about strange emails tells you something else entirely.

If the answer to this question is “we have not had any incidents,” treat that with skepticism. Every environment of meaningful size has near-misses. If they are not being logged, they are not being detected.

4. Which Third Parties Have Active Access, and Under What Controls

The Target Corporation breach in 2013 happened through an HVAC vendor’s credentials. The MOVEit incidents in 2023 hit hundreds of organizations through a single third-party file transfer product. Third-party access is where the perimeter dissolves.

Ask for the complete list of vendors, contractors, and partners with active access to the target’s environment. For each one:

• What systems can they reach?

• What credentials do they use?

• Is MFA enforced on their access?

• When was the last time their access was reviewed?

• What contractual security obligations do they carry?

The answer often reveals dozens of active third-party connections that no one at the target has thought about in years. Old vendor accounts that were never deprovisioned. Contractor VPN access that outlasted the engagement. Legacy integrations from platforms the company stopped using.

Each one is a live path into the environment. Each one transfers on close.

What Compliance Certifications Actually Tell You

SOC 2, ISO 27001, HIPAA compliance, PCI DSS, and similar certifications are useful. They tell you the target company invested in a formal audit and that a qualified third party validated a set of controls on a specific date range.

That is what they tell you. Here is what they do not tell you.

A SOC 2 Type II report covers a defined observation period, typically six to twelve months, ending on a specific date. The report tells you the controls operated effectively during that window. It does not tell you what the controls look like today, which could be six months or fifteen months after the observation period ended.

ISO 27001 certifications are valid for three years with surveillance audits in between. The initial certification confirms an Information Security Management System exists and functions. It does not confirm that patches are current, that access reviews happen quarterly, or that the incident response plan has been tested in the last year.

HIPAA compliance is self-attested. There is no HIPAA certification authority. Companies claim HIPAA compliance based on their own internal assessment. That claim is only as reliable as the assessment behind it.

Compliance certifications describe a point in time. Security posture is continuous. The difference matters when you are about to write a check.

How Inherited Vulnerabilities Become the Acquirer’s Problem

The legal and financial exposure created by cybersecurity liability transfers with the deal. That is well established. The specifics are worth naming.

If a breach occurred at the target before close and was not disclosed or was not discovered, the acquirer inherits the disclosure obligation. State attorneys general, the FTC, the SEC, HHS OCR for HIPAA-covered entities, and sector regulators can all take enforcement action against the successor entity. Fines, consent decrees, and mandatory breach notifications create direct financial and reputational damage.

Cyber insurance carriers routinely deny claims when the underlying incident predates the current policy or when material misrepresentations were made in the application. If the target’s security posture was described one way in diligence and turns out to look another way after close, the acquirer’s policy may not respond.

Regulatory exposure compounds. A breach discovered post-close that touched EU data creates GDPR exposure. A breach that touched California residents’ data creates CCPA and CPRA exposure. A breach at a target with government contracts can create false claims exposure if security representations were made in those contracts.

None of this is theoretical. Every year produces new examples of acquirers absorbing the security debt of targets they thought they had diligenced.

What an Active Cybersecurity Assessment Looks Like

A questionnaire review is a paper exercise. An active assessment is different work.

An active assessment involves:

• Direct queries against the target’s patch management, endpoint protection, and identity systems to observe actual state rather than reported state

• Vulnerability scanning of external-facing assets and, where possible, internal segments

• Review of privileged account inventories cross-referenced against HR records

• Log analysis of the last twenty-four months of security incidents, alerts, and detections

• Review of third-party access inventories with control validation

• Interviews with the technical staff who actually operate the environment, not just the executives who own the policy

The output is not a compliance checklist. The output is a picture of the security posture the buyer is inheriting, quantified in specific risks, remediation costs, and disclosure exposures.

That picture changes deals. Sometimes it lowers the price. Sometimes it moves specific risks to the seller through indemnification. Sometimes it surfaces something material enough to walk away. In every case, the buyer closes with an accurate understanding of what they bought.

The Bottom Line

Cybersecurity due diligence run as a checkbox exercise confirms that the target has purchased security products and signed security policies. It does not confirm the target is actually secure.

Cybersecurity due diligence run as an active assessment confirms the actual posture, quantifies inherited liability, and gives the buyer real information to price and structure the deal around.

The difference between the two shows up after close. The active assessment costs a fraction of what a single undisclosed breach costs to inherit.

If you have a deal in diligence and the cybersecurity workstream is being run as a document review, that is worth a conversation. We run active security assessments in M&A context, on both buy-side and sell-side, and we have surfaced findings that materially changed how deals closed. Reach out before the signing table, not after.