How much cybersecurity is enough? The financial lessons from PHP2Shell.

What happened

On 21 October 2026, the PHP project released fixes for two critical vulnerabilities in PHP, the programming language behind about 69% of websites whose server-side language is known. Either flaw could allow an attacker to run code on an affected web server without logging in, and news of them leaked before the fixes were ready.

Rather than wait, many organisations switched their sites off. Government services went offline in several European countries, and in the Netherlands the Port of Rotterdam and a number of hospitals took their public sites down as a precaution.

Attackers moved quickly too. Amazon recorded an attempt to exploit the flaws on 17 October, four days before the fixes were published, and on 26 October the US Cybersecurity and Infrastructure Security Agency added both to its catalogue of vulnerabilities known to be exploited. As of 28 October 2026, no compromise of a named organisation has been publicly confirmed.

The cost of exposure, even without a breach

Taking a service offline is a decision with a price. Some revenue that would have run through a website or customer portal may be lost or delayed. Teams drop planned work to find every system running the vulnerable software, patch it, test it and bring it back. Customers go elsewhere or call instead. Service levels promised to clients may be missed. None of this requires an attacker to succeed. It is the cost of being exposed, paid at the moment an organisation chooses to protect itself.

That cost also arrived for thousands of organisations in the same week. When so many businesses depend on the same underlying technology, a single flaw creates exposure across industries and countries at once. For insurers and reinsurers this is the shape of accumulation risk: losses that move together across a portfolio rather than arriving independently. It also raises a practical question for cyber underwriters. Whether a policy responds to a business that switched itself off as a precaution depends on its wording, and PHP2Shell is a good test of how that wording reads.

Why spending cannot remove this kind of risk

Organisations with mature, well-funded security programmes were exposed to PHP2Shell on the same day as everyone else, because the flaw sat in a component they had every reason to trust. What differed between them was what it cost. That depended on how quickly they could find where PHP was running, how long their services stayed down, how much revenue depended on those services, and how well they could keep operating in the meantime.

For exposures that arise through shared technology, security investment cannot stop the underlying vulnerability from existing. What it can do is substantially reduce the likelihood of a successful attack, and the financial consequences when something does go wrong. That makes the financial question unavoidable: which investments reduce the losses that matter most to this particular business?

The investment question

There is always another security tool to buy, another control to strengthen and another vulnerability to address. Budgets are finite, so every security investment competes with other security investments, and with everything else the business could do with the money.

Those decisions are usually informed by maturity frameworks, peer benchmarks and expert judgement. Each of these says something useful about security posture. None of them says how much a proposed investment would reduce the organisation's financial exposure, or whether that reduction is worth what it costs.

Measuring the return on a security investment

The approach is the one already used for other risks that are managed in financial terms. Estimate the organisation's distribution of possible cyber losses as it stands today. Estimate it again with the proposed investment in place. The difference shows how much the investment reduces the expected annual loss, and how much it reduces the losses in a severe year.

The reduction in expected annual loss is the basis for judging the investment's financial return against its cost. The reduction in severe-year losses shows how much protection it offers against outcomes that could threaten liquidity, capital or the continuity of the business. The two measures complement each other, and they should not be added together.

Consider a hypothetical organisation with about R3 billion in annual revenue and R5 million to spend on cybersecurity over the next three years. Three proposals compete for it, each costing about R1.7 million a year once implementation and running costs are spread over the same three years. Before any new investment, the organisation's estimated expected annual cyber loss is R8.9 million, and its 1-in-100-year loss is about R106 million. That is the annual loss it has an estimated 1% chance of exceeding in any given year, not a loss that happens once a century.

On the average alone, threat detection and recovery are almost impossible to tell apart. Each returns about R1.20 of reduced expected loss for every rand spent. In a severe year they are far apart. Better recovery and continuity cut the 1-in-100-year loss by about R35 million, more than twice as much as threat detection, because long outages drive this organisation's worst years, and a precautionary shutdown of the kind PHP2Shell forced is one of them.

These are estimates, with real uncertainty around them. A difference of R0.1 million in expected-loss reduction would rarely justify a confident ranking on its own, and a real decision should also weigh plausible ranges, how well each control is likely to be implemented and how each performs under different scenarios.

Third-party risk controls reduce expected annual losses by less than their annual cost, and offer the smallest reduction in severe-year losses of the three proposals. On these assumptions they would be the hardest to justify, although a business that depends more heavily on its suppliers could reach a different conclusion. That is the point of the exercise: the right answer depends on the business, the systems involved, the controls already in place and the losses that would follow, and it can change depending on whether the board cares most about an average year or a bad one.

When is enough, enough?

Eliminating cyber risk is not possible, so it is not the goal. A defensible stopping point is reached when the organisation meets its security obligations, its remaining risk sits within the board's appetite, and further discretionary investment offers too little value compared with other uses of the money. That value includes both lower expected losses and greater protection against outcomes the business cannot afford to carry. Setting the appetite is a decision for the board, as it is for credit or market risk, and it should be revisited as threats, dependencies and the business itself change.

One distinction matters here. Essential security obligations, and urgent remediation of critical vulnerabilities like PHP2Shell itself, are not optional because a return estimate looks unfavourable. The investment question applies to discretionary spending beyond those requirements, which is where most of the hard choices sit.

The ultimate measure of a cybersecurity investment is not simply how much it improves an organisation's security posture, but how effectively it reduces the financial risk the organisation faces. PHP2Shell is a reminder that this risk extends beyond successful attacks, and that it can reach many organisations at the same moment.