Security Due Diligence for M&A: What Acquirers Look For

Security due diligence has moved from a checkbox at the end of an M&A process to a deal-shaping factor that can affect valuation, deal structure, and whether an acquisition closes at all. Acquirers have learned — often from painful post-acquisition discoveries — that security liabilities don't transfer at book value. They compound.

Whether you're preparing a startup for acquisition or evaluating a target, understanding what rigorous security due diligence looks like determines whether skeletons surface before or after the deal closes.

Why Security DD Has Changed

The 2017 Marriott acquisition of Starwood included a breach that had been active since 2014 — exposing 500 million records and costing Marriott over $600M in regulatory fines and remediation. The breach was in Starwood's systems at the time of acquisition. Marriott inherited the liability.

That case changed the industry. Acquirers now routinely commission independent security assessments before signing, and representations and warranties insurance (R&W) providers increasingly require evidence of security due diligence to underwrite.

The Technical Audit: What Gets Examined

A technical security audit during M&A differs from a standard penetration test. It's broader and less about exploitation than about understanding the architecture, identifying systemic risks, and quantifying remediation cost.

Infrastructure review:

Cloud configuration against CIS Benchmarks (AWS, GCP, Azure)
IAM policies: are permissions least-privilege or broadly permissive?
Network segmentation: are production, staging, and development environments isolated?
Encryption at rest and in transit: which databases and storage systems are encrypted, and which are not?
Backup and recovery: are backups tested, encrypted, and stored separately from primary infrastructure?

Application security:

Dependency audit: what third-party libraries are in use, and what is the CVE exposure across the dependency tree?
Authentication mechanisms: MFA enforcement, session management, password storage (bcrypt vs. MD5 is a real finding)
API security: exposed endpoints, authorization checks, rate limiting
Secrets management: are API keys and credentials in environment variables, a secrets manager, or — as is surprisingly common — hardcoded in source code?

Development practices:

Does the company use SAST/DAST tooling in CI/CD?
Are dependency updates automated?
Is there a defined vulnerability remediation SLA?
Code review practices: is security considered in reviews, or purely functional?

Access control:

How is off-boarding handled? Is access revocation immediate and verified?
Are admin credentials shared?
Does the target have a privileged access management solution for production systems?

Data Inventory: The Foundation of Risk Assessment

You cannot assess security risk without knowing what data exists, where it lives, and who can access it. Acquirers expect a target to have a data map — and if they don't, that's itself a finding.

Key questions for data inventory:

What categories of personal data are collected (PII, PHI, financial data)?
In which jurisdictions is data stored, and what regulations apply (GDPR, CCPA, HIPAA)?
Who has access to production data? Is it restricted to specific roles, or broadly available to engineers?
What is the data retention policy, and is it enforced technically or just in documentation?
Are there data processing agreements with all third-party vendors who handle customer data?
Is data subject to any existing legal holds or active regulatory inquiries?

Gaps in data inventory aren't automatically deal-breakers, but they indicate an organization that hasn't thought carefully about its data obligations — which creates post-acquisition compliance risk.

Incident History: What They're Looking For

Every company of meaningful scale has had security incidents. Acquirers know this. What they're evaluating isn't whether incidents occurred, but how the company identified them, responded, and learned from them.

Document your incident history honestly:

Maintain a log of security incidents, even minor ones (unauthorized access attempts, accidental data exposure, credentials in logs)
For each incident: what was the detection mechanism, what was the response timeline, what was the root cause, and what changed afterward?
Clearly distinguish between "incident" (unauthorized access, data loss) and "event" (failed login attempt, alert without confirmed breach)

Red flags for acquirers:

A company that claims zero incidents: suggests poor detection capability, not a clean record
Incidents where root cause is unknown: indicates inadequate logging and forensic capability
Repeated incidents of the same type: suggests systemic problems rather than one-off mistakes
Disclosed incidents that differ from what's in internal documentation

Active investigations or regulatory inquiries are material. Concealing an ongoing breach during M&A due diligence creates massive legal exposure for founders and creates grounds for deal termination or clawback.

Compliance Posture

Compliance certifications (SOC2 Type II, ISO 27001, HIPAA BAA, PCI-DSS) aren't security guarantees, but they signal program maturity and reduce integration risk for acquirers who serve regulated markets.

Acquirers examine:

Which frameworks are certified vs. self-attested vs. aspirational
When the last audit occurred and whether findings were remediated
Whether the certification scope covers the full product or is intentionally narrow
Third-party vendor compliance: do your key vendors also have relevant certifications?

A SOC2 Type II report is often shared directly with acquirer security teams under NDA. The findings sections matter more than the opinion — a clean opinion with 20 remediated findings tells a better story than no audit at all.

Integration Risk: The Post-Acquisition Concern

Even if the target's security posture is acceptable standalone, integrating their systems into an acquirer's network introduces risk. This is the most underestimated category in M&A security DD.

Integration risk areas:

Identity federation: How will the target's identity system integrate with the acquirer's SSO? Will this require re-issuing credentials to hundreds of users?
Network connectivity: If networks are connected before security parity is achieved, a vulnerable target becomes an attack path into the acquirer's environment.
Shared services: Extending shared services (email, Slack, development tooling) to acquired employees means those accounts become attack surface against the acquirer.
Third-party contracts: Does the target have vendor contracts that contain security provisions that conflict with the acquirer's requirements?

Experienced acquirers treat the target as an untrusted network for a defined period post-close, extending access incrementally as security controls are validated — not as soon as employees get new email addresses.

How to Prepare Your Startup for Security Due Diligence

If you're a founder anticipating an acquisition process, start preparing 12–18 months in advance:

Get a SOC2 Type II report: It's the most credible third-party attestation of your security program and the closest thing to a pre-packaged due diligence artifact.
Clean up IAM: Audit every service account, remove unused credentials, enforce MFA, and document who has production access and why.
Remediate known findings: If you have outstanding vulnerabilities from a previous pentest, fix them before the process starts. Acquirers will ask what happened to prior findings.
Build a data map: Know what data you hold, where it lives, and what regulations govern it. Document it formally.
Document your incident history: Create an honest incident log if you don't have one. Acquirers value transparency over a perfect record.
Engage a security attorney: Representations and warranties in acquisition agreements contain security provisions. Understand what you're signing before you sign it.

Security due diligence is no longer a formality. It's a risk quantification exercise that directly affects deal terms. Founders who treat their security program as a competitive asset — not just a cost center — are better positioned when the process begins.