Security due diligence that fits inside a deal window

Security due diligence in an M&A process is a different exercise from a penetration test. There is no time for one inside most deal windows, and a pentest would not answer the deal question anyway, which is narrower: does this company’s security posture hide a cost or a liability big enough to change the price or the terms, and can we bound it before signing. That is answerable in days, if you cut in the right places.

One more thing worth saying early: the list of findings that stall deals is short. Most security findings are remediation budget. Knowing which pile a finding belongs to is most of the skill.

What security due diligence covers in a deal window

Access control first, because it fails silently. Who holds production access and admin rights across the core systems, whether offboarding revokes them, and how far single sign-on and MFA reach. The test we run is concrete: pick three people who left in the last year and check what they can still open. The result is a verifiable fact.

Secrets handling second. We scan repository history rather than only the current code, because a key committed in 2022 and later "removed" is still in the history and often still valid. The question that separates teams: if this credential leaked right now, how long would it take to rotate it everywhere. Credentials that cannot be rotated without downtime are an architectural finding rather than a hygiene note.

Dependency exposure third: whether an inventory exists at all, known-vulnerable versions on the internet-facing surface, and patching as a habit rather than an event. Then the operational basics: backups that have been restored at least once, encryption where the contracts promise it, and logging good enough that an intrusion could be reconstructed. These are the same items a founder can fix in the quarter before a process, as the founder’s guide to preparing for technical DD sets out.

Incident history beats the policy binder

Ask for the last three security incidents, with timelines. The answer is informative in every direction. A company with three specific stories, each ending in a fix and, where relevant, a customer notification, is showing you a posture that is real. A company with zero recorded incidents either does not detect them or does not record them, and both are findings. The way a team talks about incidents predicts future behavior far better than policy documents, which are largely written for questionnaires.

Incident history also carries legal weight in a deal. It feeds the reps and warranties, and a breach that surfaces post-close after being described differently in diligence becomes a dispute rather than a project.

The findings that stall deals

• An undisclosed breach, or one the logs describe differently than the seller did
• Customer data exposed, and still exposed at the time of the review
• Secrets in a public repository, or credentials nobody is able to rotate
• Regulated data (health, payments) handled outside the controls the customer contracts promise
• Extortion or ransomware history the seller did not surface

The common thread is blast radius and honesty, more than technical severity. Each one either creates a liability the buyer cannot bound, or reveals that the picture painted in the data room is unreliable. These findings move price, reshape warranties and indemnities, park money in escrow, or become conditions to close. Regulated-data findings tend to open a second front, because they overlap with the GDPR gaps that surface after closing.

The findings that get fixed post-close

Most of what a security review finds belongs here: MFA gaps on secondary systems, a patching backlog, an overdue pentest, incomplete logging, no formal security program at a company of forty people. These are line items for the first hundred days, each needing an owner, a budget and a date. Their presence at a startup is normal. Certification status usually sits in this pile too, and its absence can be fine for the stage; what SOC 2 proves in a deal is its own subject.

The failure mode to avoid is presenting this pile without a severity ranking, which makes forty routine items read like forty alarms and sours a workable deal. Ranking findings by what they cost in money, time and probability is the discipline, the same one behind the red flags that matter.

A security review scoped this way takes days rather than weeks, and its output is a bounded number: what it costs to fix, what must be warranted, what changes the price. That is how we run the security cut of a technical due diligence, sized to the deal window rather than to an auditor’s calendar.