The SOC 2 Said Clean. The Backlog Said 4,200 Open Alerts.

The pattern shows up about twenty minutes into the technical session. The CIM led with a SOC 2 Type II report and a sentence about a "mature security posture." Then we run a dependency scan against the actual repos, and the founder's CTO goes quiet, because the scanner just returned 4,200 open vulnerability alerts and several hundred of them are CVSS criticals that have been sitting untouched long enough to grow a beard.

Here is the thing buyers miss: a SOC 2 Type II and a vulnerability backlog measure two completely different realities. The SOC 2 confirms that a set of controls existed and operated over an audit window. It does not say a single word about whether anyone is actually closing the criticals those controls surface. In practice, what we find in $20M to $100M ARR B2B SaaS targets is an engineering team that has spent the eighteen months before the exit systematically suppressing alerts — marking criticals as "won't fix," "accepted risk," or "low priority" — so the feature-velocity chart in the deck keeps pointing up and to the right. The audit stays green. The debt compounds underneath it.

This is not a fringe case. As documented in Veracode's State of Software Security, more than 70% of applications carry a security flaw that has been sitting in the backlog for over twelve months. So when a target tells you 68% of its open-source libraries are "monitored," ask what "monitored" means. Usually it means someone gets the email and archives it. You are not buying a monitored codebase. You are buying twelve-plus months of deferred work that lands on the new owner — and if you do not price it in diligence, you fund it in the first hundred days. The mechanics of how a quiet backlog becomes a public crisis are laid out in The $350M Security Case Study.

How to read a suppressed backlog as a number, not a vibe

"Accepted risk" is the most expensive phrase in a CIM, because it is an unbooked liability dressed up as a management decision. To price it, you stop reading severity labels and start reading the dismissal history. Pull the audit trail in the scanner or the issue tracker and count three things: how many criticals were dismissed, who dismissed them, and how fast. A backlog where a single engineering lead bulk-closed 300 alerts in one afternoon two weeks before the data room opened is telling you something the SOC 2 never will.

Then translate the live criticals into engineering hours. A fully loaded critical-vulnerability remediation runs in the low four figures once you count the patch, the dependency upgrade chain it triggers, the regression testing, and the redeploy. For a $30M ARR platform, a backlog of 500 live criticals is a routine finding, and the math comes out to a six-figure remediation bill before you have built a single feature in your thesis. That work does not happen on a spare weekend. It eats sprint capacity — and when a newly acquired team burns roughly a third of its cycles upgrading abandoned libraries and rewriting the APIs that the suppressed SQL-injection alerts pointed at, your effective engineering ROI in year one drops by the same third. The investment model assumed feature throughput; the team is doing remediation triage instead. This is exactly the gap between reported and actual capacity covered in What Is Technical Debt? A Plain-English Guide.

And the tail risk is asymmetric. According to the IBM Cost of a Data Breach Report, the global average cost of a breach now sits above $5 million — more than the entire remediation backlog, landing in a single event, on your watch, in the hold period. A sponsor cannot absorb that because a founder chose a launch date over a patch. So you do two things with these findings before signing: you take a purchase-price adjustment sized to the live remediation bill, and you write a pre-close covenant that puts the KEV-listed criticals on the seller's clock, not yours.

The first hundred days: drain the backlog without a developer exodus

Once you own it, the instinct is to declare a feature freeze and a "security sprint." Do not. A freeze tells your best engineers the new owner panics, and the people who actually understand the codebase are the easiest to poach. The goal is to drain the backlog while keeping the roadmap — and the team — intact. Three moves, in order.

Move one: separate the threats that are being actively exploited in the wild from the ones that merely look scary. Cross-reference the entire backlog against the CISA Known Exploited Vulnerabilities (KEV) catalog. A critical CVSS score with no real-world exploitation can wait a sprint; anything on the KEV list is being weaponized right now and gets patched in the next sprint regardless of what the roadmap says. This usually shrinks the "drop everything" pile from hundreds of alerts to a focused few dozen, which is the difference between a team that can execute and a team that gives up.

Move two: install a standing remediation allocation — a fixed share of every sprint, permanently reserved for working down the critical and high-severity queue until it hits zero. It is steady, it is predictable, and it does not require a heroic freeze that stalls revenue. Move three, and this is the one that actually stops the bleeding: fix the pipeline that let the backlog form. A 4,200-alert backlog is not a people problem, it is a missing build gate. Without automated security gating in CI/CD that blocks a merge introducing a new critical dependency, the team will generate fresh vulnerabilities faster than they retire old ones, and you will be back here in a year. The sequencing for a full paydown — and how to keep velocity while you do it — is in our 120-Day Technical Debt Paydown Case Study. Do this and the same backlog that was a price-reducing liability in diligence becomes a disciplined, gated codebase the next buyer pays a premium for.