Pre-Acquisition Security Due Diligence: The Checklist Investors and Buyers Use

When Verizon acquired Yahoo in 2017, it expected to pay $4.83 billion. Then two undisclosed data breaches surfaced during due diligence, affecting all three billion Yahoo user accounts. The purchase price dropped by $350 million. Verizon still bought the company, but walked into years of regulatory fallout, class-action lawsuits, and remediation costs that extended well beyond the discount.^[1]

When Marriott acquired Starwood Hotels in 2016 for $13.6 billion, nobody knew that Starwood's reservation system had been compromised since 2014. The breach wasn't discovered until 2018, two years after the deal closed. It exposed 500 million guest records and resulted in a $124 million GDPR fine from the UK's Information Commissioner's Office.^[2]

These aren't edge cases. They're illustrations of what happens when security due diligence is treated as an afterthought in M&A transactions. The acquiring company inherits every vulnerability, every compliance gap, every undisclosed incident, and every piece of technical debt the target has accumulated. And unlike financial debt, security debt doesn't show up on a balance sheet.

This article is the due diligence checklist we use when working with buyers, investors, and private equity firms who want to understand the security posture of an acquisition target before the deal closes.

Why security due diligence matters in M&A

The traditional M&A due diligence process covers financials, legal, operations, and intellectual property. Security has historically been lumped into IT due diligence, treated as a checklist item rather than a material risk factor. That approach is no longer adequate.

There are three categories of risk that security due diligence is designed to uncover:

1. Inherited breaches and incidents

When you acquire a company, you acquire its breach history, including breaches that haven't been discovered yet. Dwell time, the period between an attacker gaining access and the breach being detected, averages 204 days according to IBM's 2024 Cost of a Data Breach Report.^[3] That means a target company could be actively compromised during the acquisition process and nobody would know.

Post-acquisition, the buyer becomes the responsible party for notification, remediation, and regulatory response. The Marriott/Starwood case established this precedent clearly: Marriott was held liable for a breach that originated in a system they didn't build, on infrastructure they didn't manage, during a period when they didn't own the company.

2. Compliance gaps and regulatory exposure

If the target handles health data without proper HIPAA controls, processes payments without PCI DSS compliance, or stores EU personal data without GDPR-adequate protections, the acquiring company inherits that regulatory exposure immediately upon close. Regulators don't grant grace periods for mergers.

The fines can be substantial. GDPR penalties can reach 4% of global annual turnover. HIPAA violations can cost up to $2.13 million per violation category per year. And beyond the fines themselves, the remediation work required to bring a non-compliant system into compliance can consume engineering resources for quarters.

3. Technical debt and security debt

Technical debt is well-understood in M&A. Security debt is its more dangerous cousin. It includes unpatched systems, outdated dependencies with known vulnerabilities, hardcoded credentials, misconfigured cloud infrastructure, missing access controls, and architectural decisions that make the application fundamentally insecure.

Security debt compounds. An application built without proper authentication from the start doesn't just need authentication added. It needs every endpoint refactored, every data access pattern reviewed, and every integration point validated. That's not a sprint of work. It's a quarter of work, at minimum.

The M&A security due diligence checklist

The scope of security due diligence varies based on deal size, industry, and the target's business model. A $5 million acqui-hire of a dev team looks different from a $500 million acquisition of a SaaS platform with 10,000 enterprise customers. But the core areas remain consistent.

1. Infrastructure security

Infrastructure is the foundation. Misconfigurations here affect everything built on top of it.

Red flags at this stage include production databases exposed to the internet, root/admin accounts without MFA, infrastructure managed through shared credentials rather than individual IAM users, and the absence of any centralized logging. Each of these indicates systemic issues that extend beyond the specific finding.

2. Application security

For any acquisition where the target's software is a material part of the deal value, application security assessment is non-negotiable.

The most common critical findings in application security reviews during M&A are broken access controls (IDOR vulnerabilities where users can access other users' data), mass assignment vulnerabilities in APIs, and insecure direct object references in administrative functions. These are the findings that can fundamentally undermine the value proposition of the acquired software.

3. Data security and privacy

Understanding what data the target collects, how it's stored, and who has access is critical for assessing both security risk and regulatory exposure.

Pay particular attention to data that the target may not realize it's collecting. Log files often contain PII. Analytics systems capture IP addresses and behavioral data. Customer support platforms store sensitive communications. Shadow IT and undocumented integrations can create data flows that nobody on the target's team is aware of.

4. Compliance and regulatory posture

Compliance findings can directly affect deal economics. A company that claims SOC 2 compliance but has never completed an audit, or one that processes payments without PCI DSS validation, represents quantifiable risk that should be reflected in the deal structure.

A common pattern we encounter is companies that have SOC 2 Type I reports (point-in-time assessment) but have never achieved Type II (assessed over a period, typically 6-12 months). The gap between the two often reveals that controls were implemented for the audit but aren't operationally maintained. Requesting the full management assertion and testing details, not just the summary report, provides significantly more insight.

5. Incident history and response capability

How a company has handled security incidents in the past tells you more about its security culture than any policy document.

Reluctance to share incident history is itself a finding. Companies that are transparent about past incidents and can demonstrate how they learned from them are typically more mature than companies that claim nothing has ever gone wrong. The question isn't whether incidents have occurred. It's whether they were detected, handled properly, and used as catalysts for improvement.

6. Third-party and supply chain risk

The target's vendors are your vendors after the acquisition. Their risk becomes your risk.

The software supply chain deserves special attention. A target application built on hundreds of open-source dependencies inherits the security posture of every one of those projects. A single compromised dependency, as demonstrated by incidents like SolarWinds, Codecov, and the XZ Utils backdoor, can undermine otherwise strong security controls. Request a software bill of materials (SBOM) and run it through a vulnerability scanner.

Common deal-breakers

Not every security finding is a deal-breaker. Vulnerabilities exist in every application, and gaps exist in every security program. The question is whether the findings indicate manageable risk or fundamental problems that could destroy the value thesis of the acquisition.

These findings don't always kill deals. But they fundamentally change the deal structure. Purchase price adjustments, escrow holdbacks, indemnification provisions, and representations and warranties insurance are all mechanisms for allocating the financial risk of security findings. The key is discovering them before close, not after.

How to assess security posture quickly: 30-day vs 90-day assessments

M&A timelines rarely allow for a comprehensive, months-long security audit. The assessment needs to be thorough enough to identify material risks but fast enough to fit within the deal timeline. We typically structure these as either a 30-day rapid assessment or a 90-day comprehensive review.

The 30-day assessment is designed for deals where the security risk is one factor among many, or where the acquisition value is primarily in the team or IP rather than the running software. It provides enough signal to identify deal-breakers and quantify material risks.

The 90-day assessment is appropriate for platform acquisitions where the acquired software will serve the buyer's customers, or for deals where the acquisition value is high enough that a thorough assessment is justified by the potential downside risk. It produces a complete picture of the security posture and a prioritized remediation plan with cost estimates that can inform integration planning.

Integration planning: merging security programs post-acquisition

Finding the risks is only half the challenge. The other half is integrating two different security programs, tool sets, and cultures into a unified posture. This is where many acquisitions stumble, not because the risks weren't identified, but because the integration plan didn't account for the time and resources needed to address them.

The first 30 days post-close

The immediate post-close period should focus on preventing new risks from the integration itself, not on fixing everything discovered during diligence.

1. Unified identity and access management. Provision accounts for the acquiring team. Revoke any access that was granted to deal advisors during diligence. Ensure MFA is enforced across all critical systems for both organizations.
2. Network segmentation. Keep the acquired company's network separate from the parent company's network until security baselines are established. Premature network integration is one of the most common ways that a compromised acquired system becomes a compromise of the parent.
3. Incident response unification. Establish a single point of contact for security incidents across both organizations. Define escalation paths. Ensure the acquired team knows who to call.
4. Critical vulnerability remediation. Address any critical findings from the due diligence assessment that represent immediate exploitability. These are the findings with active exploits or trivial attack paths.

Days 30 through 90

The medium-term integration focuses on aligning security tools, policies, and monitoring across the combined organization.

1. Tool consolidation. Identify overlapping security tools and standardize on a single platform for endpoint protection, SIEM, vulnerability scanning, and secrets management.
2. Policy alignment. Map the acquired company's security policies against the parent company's policies. Identify gaps and create a remediation plan with realistic timelines.
3. Security awareness. Onboard the acquired team into the parent company's security awareness program. Different companies have different security cultures, and alignment requires deliberate effort.
4. Compliance roadmap. If the acquired company needs to achieve certifications it doesn't currently hold (SOC 2, ISO 27001, PCI DSS), build the timeline now and allocate budget accordingly.

Days 90 through 365

The long-term integration addresses the deeper architectural and process issues identified during diligence.

1. Architecture remediation. Address fundamental security architecture issues, such as missing multi-tenancy isolation, inadequate authentication frameworks, or insecure data storage patterns. These are the items that require engineering quarters, not sprints.
2. Full penetration test. Conduct a comprehensive penetration test of the integrated environment, testing not just the individual systems but the integration points between them.
3. Vendor rationalization. Complete the assessment of the acquired company's vendor relationships and either bring them into the parent company's vendor management program or transition to approved alternatives.
4. Audit readiness. If the combined organization needs to undergo compliance audits, ensure the acquired systems and processes are included in scope and can pass assessment.

Real-world M&A security failures

The best argument for thorough security due diligence is what happens when it's skipped. These cases are publicly documented and illustrate the range of consequences.

These cases share a common thread: the security risks existed before the deal but weren't discovered until after. In each instance, proper due diligence either would have surfaced the issue (allowing deal terms to be adjusted) or would have accelerated detection and remediation.

Quantifying security risk in deal valuation

Translating security findings into financial terms is necessary for security due diligence to influence deal decisions. A list of technical findings, no matter how detailed, doesn't help a deal team adjust terms. Financial quantification does.

Direct costs

These are the easiest to quantify because they have clear dollar amounts attached:

• Remediation costs. Engineering time required to fix identified vulnerabilities. A critical architectural issue requiring a 6-month refactor of the authentication system by a team of three engineers has a calculable cost.
• Tool and infrastructure upgrades. If the target lacks basic security tooling (SIEM, endpoint protection, vulnerability scanning), budget for procurement and deployment.
• Compliance certification costs. If the acquisition thesis depends on selling to enterprise customers who require SOC 2 or ISO 27001, the cost of achieving those certifications should be factored in. SOC 2 typically costs $50,000-$150,000 for the audit alone, plus the engineering work for control implementation.
• Pending regulatory fines. If the diligence reveals unreported breaches or compliance violations, estimate the potential regulatory penalties based on the applicable frameworks.

Risk-adjusted costs

These require probability estimates and are inherently less precise, but they're critical for comprehensive risk quantification:

• Breach probability. Based on the findings, estimate the likelihood of a material breach in the next 12-24 months. Multiply by the estimated breach cost (IBM's 2024 average is $4.88 million for all organizations^[3]) to get a risk-adjusted exposure figure.
• Customer churn from security incidents. If the acquired product experiences a breach, what percentage of customers would leave? At what revenue impact?
• Regulatory investigation costs. Legal fees, forensic investigation, notification costs, and credit monitoring for affected individuals.
• Integration delays. Security remediation work that blocks planned integration milestones has an opportunity cost that can be estimated against the integration timeline.

The role of penetration testing in M&A due diligence

A penetration test during M&A due diligence serves a different purpose than a standard annual pentest. It's not about compliance checkbox completion or vulnerability counting. It's about answering a specific question: can an attacker compromise this system in a way that would materially affect the deal value?

What M&A-focused penetration testing looks like

The scope is typically broader and the objectives more business-aligned than a standard engagement:

• External attack surface assessment. Map every internet-facing asset of the target company. Identify forgotten systems, shadow IT, exposed development environments, and services that shouldn't be public.
• Application security testing. Deep testing of the target's primary applications, focusing on access control, data isolation (especially for multi-tenant SaaS), and the security of customer data.
• Infrastructure penetration testing. Attempt to move laterally through the target's internal network. Test whether a compromise of one system can lead to compromise of others, particularly systems containing sensitive data or intellectual property.
• Cloud configuration review. Assess the target's cloud environment for misconfigurations that could lead to data exposure, privilege escalation, or service compromise.
• Social engineering assessment. If in scope, test the target's human defenses through phishing simulations. The results indicate the organization's security awareness maturity.

How results inform the deal

Penetration test findings in an M&A context are typically categorized by their impact on the deal:

1. Deal-blocking findings. Active compromises, systemic access control failures that expose all customer data, or vulnerabilities that demonstrate the application is fundamentally insecure.
2. Price-adjusting findings. Significant vulnerabilities that require substantial engineering investment to remediate, compliance gaps that block the intended go-to-market strategy, or architectural issues that will delay integration.
3. Integration-planning findings. Moderate issues that need to be addressed post-close but don't affect the deal economics. These feed directly into the 30/90/365-day integration plan.
4. Accepted risk findings. Low-severity issues or findings in systems being decommissioned post-acquisition. These are documented and monitored but don't require immediate action.

The penetration test report becomes a foundational document for the integration team. It's the starting point for the remediation roadmap and provides the baseline against which post-acquisition security improvements are measured.

Building security due diligence into your M&A process

If you're on the buy side, whether as a strategic acquirer, a PE firm, or an investor, here's how to operationalize security due diligence:

1. Include security in the LOI or term sheet. Make it clear from the beginning that security due diligence is part of the process. This sets expectations and gives the target time to prepare documentation.
2. Engage security assessors early. Bring in your security due diligence team when you bring in your legal and financial teams, not after they're done. Parallel workstreams save weeks.
3. Require specific documentation. Don't accept "we're secure" as an answer. Request SOC 2 reports, penetration test results, incident logs, vendor inventories, architecture diagrams, and compliance certifications.
4. Conduct independent technical assessment. Documentation review tells you what the target says about its security. Penetration testing and configuration review tell you what's actually true. Both are necessary.
5. Quantify findings financially. Translate every material finding into dollar terms: remediation cost, risk exposure, or integration impact. This is what enables security to influence deal terms.
6. Build remediation into the deal structure. Use escrow holdbacks, indemnification provisions, or purchase price adjustments to allocate the cost of security remediation fairly between buyer and seller.
7. Plan the integration before you close. The 30/90/365-day security integration plan should be drafted during diligence, not after close. Knowing what you need to fix and when you'll fix it reduces post-close surprises.

If you're on the sell side, preparing for security due diligence before the process starts gives you a significant advantage. A clean penetration test report, current compliance certifications, documented incident history (even if it includes incidents), and a clear security architecture overview demonstrate maturity that directly supports your valuation.

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

We've completed 170+ security engagements across web apps, APIs, cloud infrastructure, and AI-generated codebases. Everything we publish here comes from patterns we see in real client work.