By Mario Peshev, DevriX
You are three weeks from confirmatory diligence on a software or software-enabled target, and the security workstream just landed on your desk as a 40-page report full of CVSS scores, open ports, and remediation tickets. None of it answers the question you actually have: does this asset carry a liability that changes the price, the structure, or the decision to close at all? A deal partner does not need a vulnerability scan. A deal partner needs to know whether an undisclosed breach, a compliance gap, or a fragile architecture is going to show up as a working-capital hit, a customer churn event, a delayed integration, or a discount the next buyer applies at exit.
Security due diligence for M&A is not an IT audit dressed up for the data room. It is an underwriting exercise. The point is to convert technical facts into a small number of commercial decisions: proceed, reprice, add a reps-and-warranties condition, hold back escrow, or walk. I have watched deals stall because nobody translated the security findings into that language, and I have watched buyers overpay because the report looked reassuring and nobody asked the right follow-up. This piece is about how to run that translation and how to judge whether the people doing it for you are earning their fee.
The decision the report has to serve
Before you read a single finding, fix the decision the work exists to inform. In a buy-side context there are usually four, and they map to different moments in the deal.
- Price. Is there a discrete, quantifiable exposure that should move the number? An unresolved breach, an unlicensed dependency, a compliance regime the target is out of, or an architecture that needs a rebuild the seller has been deferring.
- Structure. Should this be handled through a specific indemnity, an escrow holdback, or a closing condition rather than a price adjustment? Some risks are better isolated contractually than baked into the multiple.
- Integration cost and timing. What does the security posture do to your first 100 days plan? A target running on shared credentials, no logging, and a founder who is the only person with production access is not a Day 1 integration, it is a project.
- Walk. Is there something here that is not fixable at a price you would pay? Rare, but it happens, usually when the security gap points at a business practice you cannot underwrite.
If a security report does not sort its findings into those buckets, it is doing forensics, not diligence. That distinction is the difference between a document that informs a decision and one that decorates a deal file. This is the same lens I apply across the broader technology due diligence workstream, security is one input into an underwriting call, not a standalone compliance exercise.
Bain’s annual private equity report has tracked how much of value creation now depends on operational improvement rather than multiple expansion, which means the operating risks you inherit at close, including security debt, are increasingly the ones that decide the return. You can read the running series in Bain’s Global Private Equity Report.
What actually threatens enterprise value here
Most security findings do not matter to a deal. A misconfigured staging server, an outdated library with no exploit path, a policy that exists but is not signed, these are hygiene items you note and hand to the operating team. The findings that move enterprise value are a shorter list, and a good process spends its time there.
An undisclosed or in-progress breach
The single most expensive thing you can miss. A breach that has already happened but has not been disclosed changes the reps, the notification obligations, and potentially the customer base. Evidence you want is real: log retention long enough to detect one, incident history, breach notification records, and whether the target could even tell you if it had been compromised. A target that cannot answer “would you know if you had been breached” has just answered it.
Customer and contractual exposure
Enterprise customers increasingly write security obligations into their contracts, and those obligations survive a change of control. If the target has committed to SOC 2, specific data-handling terms, or breach-notification SLAs it is not meeting, that gap becomes your gap the moment you close. This is where security diligence intersects with revenue, and why it should never run entirely separate from the commercial review. The exposure is not the missing certification, it is the customer who leaves or renegotiates when they learn it is missing.
Data and privacy posture
Where does regulated data live, who can touch it, and can the target prove it. For a target handling health, financial, or EU personal data, the diligence question is not “are they compliant” as a yes or no. It is “what would it cost and how long would it take to reach the posture your investment thesis requires,” and whether the seller has been quietly deferring that cost onto the buyer.
Architecture that makes any of the above unfixable quickly
Security is downstream of architecture. A monolith with no environment separation, secrets in the codebase, and no access controls is not a security problem you patch, it is a security problem you rebuild. This is why security cannot be assessed in isolation from the architecture and scalability review for the acquisition. The two workstreams share evidence and the same underlying question: how much of what you are buying has to be rebuilt before it is safe to grow.
How to read the findings like an underwriter
The mistake I see most often is treating the severity rating as the priority. A “critical” CVSS score on a system with no sensitive data and no path to your crown jewels matters less than a “medium” finding on the primary customer database. Severity is a technical measure. Priority is a commercial one, and only you can set it, because only you know the thesis.
Read every material finding through three questions:
- What is the exposure in money and time? Not “this is a risk” but “remediating this is roughly X of engineering effort over Y weeks, and until it is done the exposure is Z.” If your advisor cannot put ranges on this, they have not finished the job.
- Who owns it after close? Every material finding needs a named owner and a decision right. Is this something the existing team fixes, something your operating partners drive, or something that requires a hire you have not budgeted for?
- Does it change the deal or just the plan? Most findings change the 100-day plan, not the price. Be precise about which ones actually belong in the negotiation and which belong in the integration backlog. Overloading the negotiation with hygiene items weakens your position on the findings that matter.
This is the same discipline that separates a real assessment from a checklist exercise, and it is worth reading how to tell the difference before you commission the work. My guidance on how to judge a SaaS technical due diligence firm before you sign the engagement covers the questions that surface whether a provider thinks like an underwriter or a scanner.
Where security debt hides in a code and access review
A scan tells you what is exposed today. A review of the codebase and the access model tells you how it got that way and whether it will happen again. The two are different depths of work, and the second is where the expensive surprises live.
Secrets, credentials, and the access model
Look at how the target manages who can reach production. Shared admin accounts, credentials committed to the repository, no audit trail on who changed what, a single person holding the keys, these are not just security findings, they are key-person and operational-continuity risks that a buyer inherits directly. If the founder is the only human who can deploy, your integration timeline is now hostage to that person’s cooperation and retention.
Dependencies and the software supply chain
Modern products are assembled more than written. The security question in the code quality assessment for the acquisition is not only “is their code good” but “what are they depending on, is any of it abandoned or vulnerable, and are the licenses clean.” An unlicensed or copyleft dependency in the wrong place is a legal and commercial exposure, not merely a technical one, and it belongs in the same conversation as the security posture.
Whether anyone would notice an attack
Detection is the quiet differentiator. Two targets can have identical vulnerabilities, and the one with logging, monitoring, and alerting is a fundamentally lower risk because it can see and respond. When you assess security, weight the capability to detect and respond as heavily as the count of open findings. A clean scan on a blind system is a false comfort.
When this workstream actually matters in the deal timeline
Timing determines what security diligence can do for you. Run it too late and it only confirms a decision you have already made emotionally. Run it at the right triggers and it shapes the terms.
Pre-LOI
Before you sign the letter of intent, you do not need a full assessment. You need a fast read on whether there is a deal-breaker or a repricing lever hiding in plain sight. A focused pre-LOI look, the kind of scope a buy-side technology due diligence engagement front-loads, tells you whether the technical and security posture supports the price you are about to anchor. Anchoring high and then discovering a rebuild is a far weaker position than pricing the risk before you write the number.
Confirmatory diligence
This is where the full assessment belongs, because you have data-room access, engineering interviews, and time to verify claims against evidence. This is the window to convert findings into specific negotiation asks: indemnities, escrow, or a repriced number backed by a defensible estimate of remediation cost.
Day 1 and the first board meeting
The security findings that did not change the deal now become the operating agenda. The value of a good diligence report is that it hands your operating team a prioritized, owned, costed remediation backlog on Day 1 instead of a discovery period that burns the first quarter. A private equity audit of technology and revenue in the first two weeks reads very differently when the diligence already mapped the terrain.
What separates a report you can act on from one you file
I have read a lot of security diligence reports, and the difference between the useful ones and the expensive paperweights is consistent. The useful ones lead with the decision and put the technical detail in appendices. The paperweights bury three deal-relevant findings under 200 items of equal visual weight, forcing you to do the prioritization the advisor was paid to do.
Here is what I look for in a report I can actually underwrite from:
- A findings register that is triaged, not dumped. Every material item sorted by commercial impact, with a clear line between “changes the deal” and “changes the plan.”
- Cost and time ranges on remediation. Not precise to the dollar, but bounded enough to negotiate against and budget for.
- Named owners and dependencies. Who fixes what, in what order, and what each fix depends on. This is what makes the report survive into the integration.
- Evidence, not assertion. “We reviewed access logs for the trailing 12 months” beats “access controls appear adequate.” An assessment that cannot show its evidence has not earned your reliance.
- A clear statement of what was not covered. Scope honesty is a trust signal. A firm that tells you what it did not test is more reliable than one that implies it tested everything.
McKinsey’s private capital research has repeatedly made the point that operational rigor, not financial engineering, drives returns in the current cycle, which you can follow through McKinsey’s ongoing coverage. Security diligence done well is a piece of that rigor. Done as a checklist, it is theater. For the governance-minded, the Harvard Law School Forum on Corporate Governance tracks how deal risk allocation and disclosure obligations continue to tighten, which is exactly the pressure that turns an undisclosed security gap into a post-close dispute.
How security diligence connects to exit, not just entry
The security posture you buy is the security posture the next buyer inspects. Every gap you leave unaddressed is a discount someone applies in three to five years, and the diligence you run at entry is also a preview of the diligence you will face at exit. This is why I treat the entry assessment as the first draft of the exit readiness plan.
The gaps buyers price down at exit are not exotic. They are the missing SOC 2 that enterprise deals stalled on, the customer contracts with unmet obligations, the architecture that could not scale securely. I have written separately about the specific tech and GTM gaps buyers price down, and security sits squarely in that list. Fixing them early is cheaper than fixing them under exit pressure with a buyer’s advisor pointing at them.
Sustaining that posture through the hold usually does not require a full-time security executive on a lower-mid-market asset. It requires someone with a decision right and accountability, which is the model behind a virtual CIO for private equity or a part-time CTO seat that enforces real decision rules. Diligence identifies the debt. Someone on the hook has to retire it, and the difference between advice and delivery is the difference between an operational value creation plan someone owns and a memo you can ignore.
The operator takeaway
Security due diligence for M&A earns its fee only when it changes a decision. Everything else is documentation. Before you commission it, be explicit about the decisions it must serve, price, structure, integration, or walk. When you read it, demand triage, cost and time ranges, named owners, and evidence, and refuse to do the advisor’s prioritization for them. Time it to the LOI and confirmatory windows so it shapes terms rather than confirming a foregone conclusion. And treat the entry assessment as the opening move of your exit story, because the debt you accept at close is the debt the next buyer prices.
The best security diligence I have seen does not read like a security report at all. It reads like an underwriting memo that happens to be about technology, one that lets a deal partner, a CFO, and an operating partner each find the answer to their own question in the same document. That alignment across engineering, product, and revenue is the same discipline required to run the asset well after close, which I have covered in aligning engineering, product, and RevOps for PE value creation. Get the diligence right and the value-creation plan starts on Day 1 instead of Quarter 2.
Where to take this next
If you have a target under LOI or approaching confirmatory diligence and you need the security and technology posture translated into decisions a deal partner can act on, that is exactly the work our private equity practice runs. The 5-Day Tech DD delivers a triaged, costed, owner-assigned assessment inside a confirmatory timeline, and the pre-LOI read gives you a fast deal-breaker-or-repricing-lever check before you anchor the number. Bring us the asset and the decision you need to make, and we will scope the assessment to serve it.
