By Mario Peshev, DevriX
You are three weeks from close on a software or software-adjacent target, and a security question is sitting on your risk register with no owner and no dollar figure attached to it. That is the situation this article is written for. Not “is security important” (you know it is), but the sharper problem: your security workstream produced a 40-page vendor report full of findings, and you still cannot tell the deal partner whether this is a price adjustment, a covenant, a first-100-days project, or a walk. Security due diligence for private equity fails most often not because the work is thin, but because it never gets translated into a decision the investment committee can act on.
I run technical diligence and post-close engineering for PE-backed companies. The pattern repeats across deals: the security assessment gets treated as a compliance checkbox that either passes or fails, when the thing you are buying is enterprise value, and security is a set of risks that either move the price, gate the deal, or convert into a funded remediation plan. Below is how I judge a security diligence output, and what you should demand from whoever produces yours.
The question a deal partner is actually asking
A deal partner does not want a catalog of misconfigurations. They want an answer to four questions, in order:
- Is there a live breach or unmanaged incident right now that changes whether we transact at all?
- What will it cost to bring this asset to a defensible baseline, and is that cost material against the thesis?
- Which of these risks are we inheriting as liabilities versus which are cheap to fix in the first 100 days?
- Does the security posture threaten the exit, either through a customer-facing incident during the hold or through what the next buyer will price down?
Everything a security review produces should ladder up to one of those four. When I read a security section that opens with “we ran a vulnerability scan and found 217 issues,” I know the firm has confused activity with a decision. The number 217 informs nothing until it is sorted into what threatens the deal, what threatens the hold, and what threatens the exit. That sorting is the entire job.
This is the same discipline I described in buy-side technology due diligence: findings are raw material, and the value is in the translation to a commercial decision the investment committee can act on.
Deal-killers, price-movers, and 100-day work are three different piles
The single most useful thing a security review can do is separate findings into three buckets with money attached. If your provider hands you a severity matrix (critical/high/medium/low) and stops there, they have done a technical exercise and left the commercial work for you. Severity is a technical property. What you need is a commercial classification.
Deal-gating findings
These are the ones that change whether or how you transact. An active or recent unremediated breach. Customer data stored somewhere the target does not control and cannot account for. A contractual security commitment to a large customer that the company is materially failing, where discovery would trigger termination or claims. Regulated data handled without the required controls in a way that creates real exposure. These are rare, and finding one is exactly why you paid for the review. They belong in front of the deal partner within days, not in a report at the end.
Price-movers
These are real costs you can quantify and use in negotiation: a security program that needs a genuine build-out, remediation that will consume budget you had earmarked for growth, a compliance certification a major customer requires that the company does not hold and will take months and money to earn. You do not walk over these. You price them, and you either move the number or you build the remediation into the plan and hold someone accountable for it.
First-100-days work
Everything that is real, fixable, and not material to the price. Patch cadence, access reviews, MFA gaps, logging, an incident response plan that exists on paper but has never been tested. These are normal for a founder-run or lean company and belong in the integration plan, not the purchase agreement.
The failure mode I see most: a firm dumps all three piles into a single “findings” list sorted by technical severity, and the deal team spends a weekend re-sorting it into something they can actually use. You should not be doing that sort. That is what you paid for.
What a serious security review actually inspects
You are not buying a pen test. A pen test tells you whether an attacker can get in today. Diligence has to tell you whether the security posture is a liability against the thesis and the exit, which is a broader question. In a five-day technical review, the security-relevant surface I want covered is:
- Data inventory and control. What sensitive data does the company hold, where does it live, who can reach it, and can the company actually tell you? Inability to answer is itself a finding.
- Identity and access. Who has admin, how is access granted and revoked, is MFA enforced on the systems that matter, and are there dormant accounts and shared credentials nobody owns.
- Third parties and the supply chain. The vendors, dependencies, and integrations that carry data. A target’s security is only as strong as the sub-processors it hands customer data to.
- Incident history and response capability. Not just “have you been breached,” but is there a tested plan, logging that would let you detect an incident, and evidence of past incidents that were handled quietly.
- Compliance posture against customer and regulatory requirements. What certifications customers demand, what the company holds, and the gap.
- Secure development practices. Where security lives in the engineering process, which overlaps with the code quality assessment and the architecture and scalability review you should be running in parallel.
None of this is exotic. What separates a useful review from a checkbox is whether each finding arrives with an owner, an estimated cost or effort, and a bucket. A finding without a dollar figure and a bucket is a fact, not a decision input.
Why security keeps getting priced into deals now
The commercial reason security has moved from afterthought to standard workstream is not abstract. Regulators have tightened disclosure expectations. The U.S. Securities and Exchange Commission’s cybersecurity disclosure rules for public companies have raised the bar on what boards are expected to know and report, and that expectation flows downstream into what the next strategic or public-market buyer will demand from a target during your exit. What you tolerate at entry, the next buyer prices at exit.
The deal environment reinforces it. Bain’s Global Private Equity Report has documented longer holds and more competitive processes, which means more time for an incident to surface during your ownership and more scrutiny when you sell. Research from McKinsey on value creation has consistently pushed the same point: alpha increasingly comes from operational improvement rather than multiple expansion, and an unmanaged security liability is operational drag that shows up as a discount later. PitchBook and S&P Global Market Intelligence track the deal data that makes this concrete: software and data-heavy targets dominate mid-market flow, and those are precisely the assets where security posture and enterprise value are tightly linked.
I am not citing these to scare you into a bigger scope. I am pointing out that security has become a standard exit-readiness question, which means it is a standard entry question too. The Harvard Law School Forum on Corporate Governance has published extensively on board-level cybersecurity oversight expectations, and those expectations are what your eventual buyer’s board will hold them to.
How to judge the firm before you pay for the review
The quality of a security diligence output is mostly determined before the work starts, by who you hired. I wrote a longer piece on how to judge a SaaS technical due diligence firm before you sign, and the security-specific version comes down to a few tells.
Do they lead with commercial classification or with a severity dump?
Ask for a redacted sample report. If the summary is a table of CVEs and severities, that is a scanning shop. If the summary is three buckets with dollar ranges and owners, that is a diligence partner. You want the second.
Can they operate at deal speed?
Confirmatory diligence runs on a clock. A firm that needs six weeks is useless when you are two weeks from close. The review has to fit the deal timeline, which is why a focused five-day technical review exists as a shape at all. The scoping conversation should start pre-LOI so the deep work is targeted, not a fishing expedition once the exclusivity window is burning.
Will the same people help fix what they found?
A firm that only diagnoses hands you a problem. A firm that can also stand up the remediation, or oversee it, closes the loop between the finding and the value it protects. This is the argument for treating diligence and post-close as one relationship rather than two vendors. It is also why the same lens that produces the technology due diligence should carry into the first 100 days, where the price-movers and 100-day findings actually get resolved.
Turning findings into a remediation plan someone owns
A security review that ends at the report has done half the job. The other half is converting the findings into a plan with owners, sequencing, and a budget line, then making sure someone is on the hook for it. I have written about the difference between advice you can ignore and a plan someone is accountable for, and security is where that difference bites hardest, because the cost of ignoring it is asymmetric: cheap to fix, expensive to suffer.
The remediation plan should answer, for each material finding: who owns it, what it costs, when it lands relative to Day 1 and the first board meeting, and what risk it retires. That last column matters. If you cannot state which risk a task retires, the task should not be in the plan. This is the same accountability structure I use across the engineering and RevOps workstreams described in aligning engineering, product, and RevOps for PE value creation.
For portfolios without a full-time security or technology leader, the plan needs an owner who is actually present through the hold. That is the case for a virtual CIO or a part-time CTO seat that carries the decision rights to enforce the remediation, rather than a report that sits in a data room until it is someone else’s problem at exit.
The exit view, priced backward into today
The discipline that keeps security diligence honest is thinking backward from the exit. When you sell this asset in three to five years, a strategic or larger financial buyer will run their own security review, and their standard will be higher than the one the company meets today. Every gap you tolerate now is something their diligence surfaces and prices down, unless you close it during the hold.
I laid this out in more detail in exit readiness for portfolio companies. For security specifically, the exit-relevant questions are the durable ones: can the company demonstrate control over customer data, does it hold the certifications its customer base and its acquirers expect, and is there evidence of a functioning security program rather than a one-time cleanup. Those are the things that survive a buyer’s scrutiny. A patched vulnerability from last year does not; a repeatable program does.
This is why I treat the entry security review and the exit posture as the same conversation. The first two weeks of a technology and revenue audit post-close should re-run the entry findings as a baseline, so the remediation plan is measured against something concrete rather than a vibe. Actual versus plan, on security as on everything else.
What good looks like on one page
If your security diligence output does its job, the deal partner can read a single page and act. That page states, plainly:
- Whether anything is deal-gating, with the reasoning, escalated early rather than buried at the end.
- The total quantified cost of reaching a defensible baseline, sorted into price-movers versus 100-day work.
- The three to five findings that matter most, each with an owner, a cost, and the risk it retires.
- The exit view: what the next buyer will scrutinize and what it will take to be ready.
Everything else is appendix. If the summary page requires the deal team to do the commercial translation themselves, the review under-delivered regardless of how many findings it contains. Volume is not rigor. The Harvard Business Review body of work on M&A keeps returning to the same lesson: deals fail on integration and on risks that were visible but not acted on, not on risks nobody could have found. Security is squarely in the “visible but not acted on” category, which is the most avoidable failure there is.
The operator takeaway
Treat security due diligence for private equity as a decision engine, not a compliance artifact. Demand three commercial buckets with money attached, not a severity matrix. Insist that deal-gating findings reach the partner within days, not at report delivery. Hire a firm that classifies commercially, moves at deal speed, and can stand behind the remediation. Then carry the findings into a first-100-days plan where someone owns each item and every task retires a named risk. Do that, and security stops being the workstream that scares the committee and becomes one more lever you priced correctly at entry and de-risked before exit.
If you are approaching an LOI or in confirmatory diligence on a software or data-heavy target and you need a security and technical review that produces a decision rather than a document, DevriX runs a focused five-day technical due diligence and a lighter pre-LOI screen scoped to the deal clock. See the DevriX private equity practice to scope the engagement against your timeline.
