The Real Cost of Running Outdated Software

In January we wrote about auditing your stack and the hidden cost of ignoring security updates. Those posts focused on the technical side: which versions are reaching end of life, what tools to run, and why patching matters from an engineering perspective.

This post is aimed at a different audience. If you're a founder, CTO, or anyone who signs off development budgets, this one is for you. Because outdated software isn't just a technical risk sitting on a Jira board somewhere. It's a financial liability, and it belongs on the risk register alongside everything else that could cost your business real money.

Putting a number on it

IBM's 2024 Cost of a Data Breach Report found that the global average cost of a data breach reached $4.88 million, a 10% jump from the previous year and the largest annual increase since the pandemic. Seventy percent of breached organisations reported significant or very significant business disruption, and recovery took more than 100 days for the majority of those affected.

Those are global averages. For specific industries, the numbers are far worse. Healthcare organisations averaged $9.77 million per breach. Financial services came in at $6.08 million. Even if your business sits outside those sectors, the average still dwarfs what it would cost to keep your software current.

The report also found that organisations with severe security staffing shortages paid $1.76 million more per breach on average. That's worth noting because under-resourced teams are often the same teams where maintenance gets deprioritised in favour of feature work.

The UK regulatory picture

If the global figures feel abstract, the UK's Information Commissioner's Office has been making the domestic picture very concrete.

In 2025, the ICO shifted its enforcement strategy significantly. Fewer fines overall, but dramatically larger ones. The average penalty jumped from around £150,000 to over £2.8 million. The biggest case saw Capita fined £14 million following a ransomware breach that affected nearly seven million people across 600 pension funds. The ICO's investigation pointed to failures in privilege escalation controls, slow response to security alerts, and inadequate penetration testing.

Advanced Computer Software Group, a provider of digital services to the NHS, was fined over £3 million after attackers gained access through an account that didn't have multi-factor authentication enabled. The ICO specifically cited failings in patch and vulnerability management. These were basic security controls - not advanced threat detection, not zero-day defence. Patch management and MFA.

Under UK GDPR, maximum penalties can reach £17.5 million or 4% of annual global turnover, whichever is higher. The ICO has made it clear that organisations are expected to implement basic security measures, and "we didn't get around to it" is not a defence.

The costs you don't see on an invoice

Regulatory fines make headlines, but they're often not the largest cost of running outdated software. The less visible costs are the ones that really compound.

Downtime and lost revenue. When a breach forces you to take systems offline, every hour has a price tag. If your application generates revenue directly - through e-commerce, subscriptions, or API access - the maths is straightforward. If it supports internal operations, the cost shows up in lost productivity instead. Either way, it's real.

Incident response. Forensic investigation, legal counsel, mandatory breach notifications under GDPR, credit monitoring for affected users, public relations crisis management. These costs start accumulating immediately and continue for months. The IBM report found that the average breach lifecycle - from identification to containment - was 258 days. That's nearly nine months of active spend.

Customer trust. This is the one that's hardest to quantify but arguably the most damaging. Customers who learn their data was compromised because your team didn't apply a security patch don't tend to be understanding about it. Trust is slow to build and fast to lose, and in competitive markets, customers have alternatives.

Opportunity cost. After a breach, your development team isn't building features or improving the product. They're firefighting. They're responding to security audits. They're doing the upgrade work they should have done six months ago, but now under pressure and with far less margin for error.

Why the upgrade always costs more later

We covered the technical side of this in our January posts, but it's worth framing in business terms too. Software maintenance has a compounding cost curve.

Staying one major version behind on your framework is usually a straightforward upgrade. A developer can handle it in a day or two, run the test suite, and deploy with confidence. The cost is predictable and low.

Falling two or three versions behind is a different story entirely. Dependencies have drifted. Breaking changes have stacked up across multiple releases. Deprecated features need rewriting. What would have been a routine afternoon has become a multi-week project that pulls developers off roadmap work and introduces risk during migration.

We see this pattern constantly. A business delays a Laravel upgrade because there's always something more urgent. Six months pass, then twelve, then eighteen. By the time the upgrade becomes unavoidable - because a hosting provider drops support, or a penetration test flags critical issues, or a vulnerability is actively being exploited - the scope has ballooned and the timeline is compressed.

The difference between proactive maintenance and reactive remediation isn't just the engineering hours. It's the conditions under which the work gets done. Proactive work happens on your schedule, with proper testing and a calm rollout. Reactive work happens on someone else's timeline, under pressure, and with the organisation already in damage-control mode.

Building a business case for maintenance

If you're trying to justify ongoing maintenance spend internally, here are some numbers that help frame the conversation.

The IBM report found that organisations with incident response teams and regularly tested security plans had breach costs that were $2.66 million lower on average. Those using AI and automation in their security operations saved $2.2 million compared to those without. And organisations that detected breaches internally rather than having them disclosed by an attacker saved nearly $1 million per incident.

These aren't technology findings. They're business findings. The common thread is preparedness - and preparedness starts with keeping your software current.

A reasonable rule of thumb is to allocate 15-20% of your development capacity to ongoing maintenance, security updates, and infrastructure upkeep. That sounds substantial until you compare it to the alternative. A single breach can cost more than years of proactive maintenance. And unlike a breach, maintenance spend is predictable, plannable, and doesn't come with reputational damage attached.

What to take away from this

If you're responsible for a software product or a digital service, the question isn't whether you can afford to invest in maintenance. It's whether you can afford not to.

Every unpatched dependency, every end-of-life framework version, every server running outdated packages is a liability. It might never be exploited. But if it is, the cost will be orders of magnitude higher than what it would have taken to prevent it.

The organisations that treat software maintenance as a cost of doing business are the ones that avoid the headlines. They spend less overall, experience fewer disruptions, and keep the trust of their customers.

If you're not sure where your applications stand, or you need help building a maintenance strategy into your development workflow, get in touch. We help businesses across the UK keep their Laravel applications and API infrastructure current, secure, and resilient.