Cyber due diligence in M&A: what buyers actually check
By Kike Gandia · Co-Founder & CEO, OSCP
If you're on the buying side of an acquisition, technical cybersecurity due diligence is where problems surface that even the seller didn't know they had: active vulnerabilities, former employee accounts that still have access, or a security incident never formally reported. This guide explains what a well-run cyber due diligence should cover and how to translate findings into business decisions — price, terms, or walking away.
The four areas a complete cyber due diligence covers
Technical posture: active vulnerabilities in infrastructure and applications through analysis and, if timing allows, a scoped pentest. Access management: orphaned accounts, excessive privileges, shared or unrotated credentials. Incident history: past breaches, whether they were properly notified to the AEPD (Spanish Data Protection Agency) when required, and whether they were genuinely remediated. Regulatory compliance: exposure to pending fines under NIS2, GDPR or other sector regulations.
Why security debt costs more after closing
A finding discovered during due diligence is negotiable: it adjusts the price, part of the payment is held in escrow conditional on remediation, or it's included as a warranty in the purchase agreement. The same finding discovered after closing is entirely the buyer's responsibility, with no negotiating leverage. The cost difference between the two scenarios can be substantial.
Red flags that justify digging deeper
A total absence of security documentation (no policy, no incident log), a technical team that cannot explain who has administrative access to critical systems, systems running outdated software with no upgrade plan, or reluctance to grant full access for the review. Any of these justifies expanding the scope of analysis before closing.
How to translate findings into the negotiation
Not every finding carries the same weight: a critical vulnerability in the revenue-generating core product matters far more than a minor weakness in a secondary internal system. A useful due diligence report doesn't just list findings — it prioritizes them by impact on the real value of the asset you're buying, with an estimate of remediation cost and time for each.
From finding to contractual mechanism
The useful conversation with legal counsel is not "we found vulnerabilities," but which contract mechanism absorbs each type of finding. This is the mapping used in practice:
| Type of finding | What it means for value | Usual mechanism |
|---|---|---|
| Exploitable vulnerability in the revenue-generating product | Quantifiable remediation cost and disruption risk | Price adjustment or condition precedent before closing |
| Past breach not notified when it should have been | Regulatory and reputational exposure with a long tail | Specific representation and warranty, with indemnity |
| Orphaned accounts and unmanaged privileges | Operational debt, cheap to fix, expensive to ignore | Commitment to clean up within the first 90 days post-closing |
| Critical dependency on one person holding every access | Continuity risk for the acquired business | Retention clause and documented handover of access |
| Unsupported software on core systems | Mandatory near-term investment not in the plan | Escrow holding back part of the price until migration |
The broader takeaway is that almost no technical finding kills a deal on its own: what changes the outcome is discovering it before or after signing.
FAQ
How long does a cyber due diligence take in an M&A deal?
It depends on scope and the access the seller provides, but a reasonably complete analysis typically takes 1 to 3 weeks.
Can I request one even if the seller already presents their own report?
Yes, and it's advisable. The seller's report is a good starting point, but as a buyer it's worth validating findings independently, especially when there's a lot at stake in the deal.
What if I find something serious mid-negotiation?
It becomes a negotiation point: price adjustment, part of the payment held in escrow conditional on remediation, or specific warranty clauses in the purchase agreement.
Can the pentest run against the seller's production environment?
It can, and in many deals it is the only option because no comparable staging environment exists, but it needs written rules before starting: an agreed time window, exclusion of denial-of-service testing and any destructive action, a seller-side technical contact reachable throughout the window, and an immediate stop criterion. The part that gets forgotten is authorization: you need written permission from the system owner and, if it is hosted with a cloud provider, a check of their security testing terms. Under those conditions, non-intrusive analysis against production is routine; without them it is an unnecessary risk at exactly the point where the relationship between the parties is most delicate.
What access should we request from the seller, and in what order?
From least to most friction: first what requires touching nothing — asset and vendor inventory, technical org chart, previous audit reports, incident log; then read-only access to the admin console of the email and collaboration environment and to the cloud console, which is where the real state of privileged access becomes visible at a glance; and finally, if scope justifies it, active testing. Starting with documentation also surfaces an important signal: how long the seller takes to produce information they should have at hand.
What if the seller will not authorize technical testing until after signing?
That is common in competitive processes, and there is a way through. Active testing is replaced with a documentation and configuration review in assisted sessions — the seller's team shares their screen and walks through the consoles while the analyst asks for specific evidence — complemented by external reconnaissance, which needs no authorization because it only uses publicly accessible information. Whatever that review cannot cover moves into the contract as a specific warranty, with a full technical verification agreed for the first months after closing.
What deliverable should I demand from the due diligence provider?
Three things, and they are worth requesting before contracting: a two-page summary aimed at the investment committee, stating the recommended decision and why; the technical detail with evidence per finding; and a cost and timeline estimate for remediating each relevant finding, which is the piece actually used in the negotiation. A report without that estimate leaves the job half done, because nobody can turn it into a number on the table.
Related service
cybersecurity for startups and scaleups
Related content
- Cybersecurity audit services
- Cybersecurity audit before selling your company
- Penetration testing for businesses
- About us: the team behind the analysis
Sources
- NIST SP 800-115 — the reference methodology for the technical analysis and scoped pentest in a due diligence
- AEPD — guide to notifying personal data breaches, the reference for checking whether a past incident was properly notified
- EUR-Lex — Regulation (EU) 2016/679 (GDPR), the regulatory framework cited for exposure to fines
- EUR-Lex — Directive (EU) 2022/2555 (NIS2), another regulatory framework cited for exposure to fines