Legacy Security Risk Statistics

A statistic is only as good as its attribution, and a security business case is exactly where that discipline gets tested. The temptation in a closing data piece is to reach for a frightening breach percentage, and the field is full of them, most repeated without a source anyone can find. This series has argued throughout that legacy risk is real and that it should be stated plainly rather than dramatically. The same rule governs the numbers: every figure below is named, dated, and reproduced exactly as its source stated it, and any figure we cannot stand behind that way is left out, even where the heading might invite one.

That omission is itself the most important point in this article, so it goes first.

What we do not publish, and why

You will not find a “X% of breaches involve legacy or unpatched software” figure here, because we do not have one we can name, date, and source from our maintained reference. Such numbers circulate widely. Most trace back to a single vendor report, a survey with an undisclosed method, or a citation chain that dead-ends. Publishing one to make this series land harder would violate the one rule the whole series rests on, never invent or launder a statistic, and it would hand any skeptic the thread that unravels the argument.

So the figures below do something more honest and, for a business case, more durable: they establish the scale, cost, and trajectory of legacy systems rather than a breach rate. They prove the systems are large, load-bearing, expensive to maintain, and staffed by a workforce that is leaving. That is the foundation a security case actually needs. The exposure of your specific system comes from assessing it, not from an industry average, a point the statistics hub and the technical-debt statistics make the same way.

The citable figures at a glance

Every figure in this article, with the source and date you must cite alongside it. Nothing here is ours to round or restate. Each appears exactly as its source gave it, and each is unpacked in its own section below.

Figure	Source	Date	What it establishes
Up to 70% of digital transformations fail to deliver on their objectives	Boston Consulting Group (BCG)	September 13, 2023	The base-rate case against big-bang change
Roughly 55% to 57% of enterprise IT spend goes to running existing systems	Deloitte (Global CIO surveys)	2016 to 2020	The cost of standing still
Average COBOL developer roughly 58, about 10% of the workforce retiring yearly	IBM, reported via Fujitsu	2020	The knowledge clock on legacy skills
An estimated 220 billion to 800 billion+ lines of COBOL in production	Reuters via IEEE Spectrum (about 220B), and Micro Focus (800B+)	2017, then by 2022	The scale of the systems at risk

The cost of maintaining what already exists

Roughly 55% to 57% of enterprise IT spend goes to running existing systems. Deloitte (Global CIO surveys, 2016 to 2020)

This is the macro frame for the whole series. When most of the IT budget goes to keeping existing systems alive, the systems carrying the EOL and compliance risk of Part 1 are the same systems consuming the budget, and the spend climbs as they age. It is the figure that connects the risk argument to the cost argument: the money is already going to legacy, and an ever-larger share of it to simply holding the line. Modernization is, in large part, the work of pointing that spend back at the roadmap instead of at the unpatchable past.

The base rate for big-bang change

Up to 70% of digital transformations fail to deliver on their objectives. Boston Consulting Group (BCG), September 13, 2023

This is the figure behind every “without a full rewrite” argument in the series, and especially Part 8. The base rate for large, all-at-once change programs is failure, which is the empirical case against responding to a security deadline with a big-bang rewrite. When the goal is to reduce risk, betting the system on a single cutover with a 70%-failure base rate is the move most likely to increase it. Slice-by-slice delivery exists to change which side of this number a modernization program lands on.

The knowledge clock

The average COBOL developer is roughly 58, and about 10% of the COBOL workforce retires each year. IBM, reported via Fujitsu, 2020

This is the human side of EOL risk, the knowledge risk named in Part 1, with a clock on it. The people who hold the undocumented rules of the oldest, highest-risk systems are leaving on a schedule, and each departure makes the eventual migration more expensive and more dangerous. It is the figure that turns “we should deal with this eventually” into “the cost of waiting is rising measurably.” The recovery effort grows as the institutional memory thins. It is a COBOL-specific figure, but the pattern generalizes to any deeply legacy stack.

The scale of the systems involved

An estimated 220 billion to 800 billion+ lines of COBOL are in production worldwide. Reuters, via IEEE Spectrum (about 220B, 2017). Upper bound, Micro Focus (800B+, by 2022)

The range is wide because credible sources disagree, which is exactly why we show the range rather than pick the number that flatters the case. Its purpose here is to establish that the most legacy-laden systems are not relics gathering dust. They are load-bearing infrastructure running the core of banks, insurers, and governments. The systems carrying the EOL and compliance risk this series describes are frequently the most critical ones in the enterprise, which is precisely why they cannot be modernized with a big-bang gamble.

The figures this page deliberately leaves out

Being disciplined about what belongs here is the same discipline as sourcing it. A number used to prove something it does not measure is no better than an unsourced one. So these real, sourced figures live elsewhere, or nowhere.

Figure	Source	Why it is not here
A ”% of breaches involve legacy or unpatched software” number	No source we can name and date	Omitted entirely. We will not publish a breach rate we cannot stand behind
42% of developer time lost to technical debt	Stripe, 2018	Real and sourced, but it measures engineering capacity, not security risk. It lives in the technical-debt statistics
20% to 40% of estate value carried as technical debt	McKinsey, 2020	A technical-debt figure, covered where it belongs
A mainframe market-size projection through 2030	MarketsandMarkets, August 21, 2025	A market-size figure, kept with the mainframe series

How to use these in a security business case

Three rules carry from the technical-debt statistics, and they matter most in a security case where the pressure to overstate is highest:

• Pair every number with its source and date. “Up to 70% (BCG, 2023)” is citable. “Most transformations fail” is not, and it invites the dismissal the number was meant to prevent.
• Use them for scale, not as your measurement. These establish that the problem is real and large across the industry. They do not measure your exposure. That comes from assessing your own systems, as Part 9 lays out. Presenting an industry average as your own risk is the overreach that loses a skeptical room.
• Show ranges where sources disagree, and omit what you cannot source. The COBOL estimate spans 220 billion to 800 billion+ because credible sources differ. Reporting the range, and leaving out the breach percentage we cannot stand behind, is more credible than a single confident number with no provenance.

Which figure leads, by who is in the room

The same four figures make different arguments to different people. Lead with the one that speaks to whoever is deciding, and keep the rest as support. No new numbers, just the right one first.

Audience	Lead figure	Why it lands
CFO or finance	Deloitte, 55% to 57% of IT spend on running existing systems	Frames modernization as redirecting money already being spent, not as new cost
Board or CEO	BCG, up to 70% of transformations fail	Makes the case that the big-bang fix is the risk, and slice-by-slice is the mitigation
CISO or head of risk	The COBOL knowledge clock plus the scale of production code	Ties the exposure to people leaving and to systems too critical to gamble on
Enterprise architect	The 220 billion to 800 billion+ line estate	Grounds the discussion in how much load-bearing legacy actually exists

How to vet a statistic before you cite it

The same test we applied to every figure here is the one to apply to any legacy statistic you find elsewhere, because a security case is only as strong as its weakest number.

• Is it named and dated? A figure without a source and a year is a rumor, not a statistic. Do not put it in front of a skeptic.
• Does the primary source exist? Follow the citation to the original report, not the blog that repeated it. If the chain dead-ends at a page with no method, treat the number as unusable.
• Does it measure what you are using it for? A technical-debt figure does not measure a breach rate. A market-size figure does not measure your risk. Borrowing a real number for the wrong argument is its own kind of fabrication.
• Is it an average or your number? Industry aggregates establish the general case. They never measure your specific system. Never present one as the other.
• Would it survive a hostile question? If a skeptic asking “where is that from?” would unravel your point, the statistic is a liability, not support. Cut it.

What these numbers can’t do

Statistics persuade, which is exactly why a security case has to handle them with care. The figures above make the general case, that legacy systems are large, costly, aging, and risky to modernize all at once. They do not make the specific case for your system, and they cannot. A number quoted without its source, stripped of its date, or stretched past what it measured is worse than no number at all, because it converts a careful argument into one a single skeptical question can dismiss. Cite these to establish that the problem is real and well-documented. Then assess your own systems to say what the risk actually is for you. The two together are persuasive. Either one asked to do the other’s job is not.

Where this series leads

That completes the arc this series set out to walk. We mapped the five risks of end-of-life software, traced how they surface in the compliance frameworks and the audits and insurance renewals that formalize them, got concrete about the unpatched runtimes and EOL stacks that generate them, built the planning calendar that gets you ahead of the dates, and laid out how to retire the risk without a full rewrite, sequenced by a compliance-driven roadmap. The whole series, in order, lives at the EOL, Security & Compliance Risk hub.

If your own EOL exposure has moved past the point where compensating controls can hold it, whether an unsupported component on a reachable and sensitive path, a recurring finding no in-place fix can close, or a renewal getting harder each year, the next step is not another spreadsheet but a conversation. ModernLift retires legacy security and compliance risk the way this series describes: incrementally, with validated parity, highest exposure first, and the business running the entire time. Book a 30-minute discovery call, no deck, and we will scope what bringing the risk down would actually take.