The cyber budget is agreed. The risk has changed. Now what?

The cyber budget is signed off. Headcount is agreed, the managed service contract is signed and the licence renewals are accounted for.

Then a vulnerability lands in the platform your supplier uses to keep production running.

The security team wants to restrict access. Operations wants to know whether the supplier can still complete scheduled maintenance. Finance wants to understand whether the proposed response will cost more than the disruption it is meant to prevent.

All three are asking reasonable questions. The annual budget does not answer any of them.

This is where cyber risk needs to become a more useful part of business decision-making. We need to connect what has changed, what we now believe could happen, and which available intervention is worth its cost.

That is the idea behind dynamic cyber capital allocation: reviewing where money, people and operational capacity can make the greatest difference as the evidence changes. Sometimes that means additional investment. Sometimes it means using an existing capability, investigating further or accepting an exposure for a defined period.

A budget is a commitment built on assumptions

An approved security budget expresses a view of the business at a point in time. It reflects the assets we believe matter, the threats we expect, the controls we think are effective and the losses we want to avoid.

Some of those assumptions will change before the next budget cycle.

A production line becomes more commercially important. A supplier gains access to another environment. An acquisition introduces systems the security team cannot yet see clearly. A recovery exercise reveals that restoring a critical service takes much longer than expected.

The technology can also remain exactly as it was while the consequences change. An interruption during a quiet maintenance period and the same interruption during peak production are different business problems.

The useful question for finance and security is therefore: which assumptions justified this investment, and what would cause us to revisit them?

That question gives a risk review something concrete to work with. It also makes a request for more money easier to challenge constructively.

Has the exposure changed, or have we learned something?

A newly disclosed vulnerability can generate an immediate sense that risk has increased. We need to be more precise about what happened.

Perhaps exploitation has become easier because attack code is now available. Perhaps attackers are targeting the technology more frequently. Or perhaps the weakness was already present and the disclosure has simply made us aware of it.

Those situations may justify different changes to the analysis.

Now suppose an investigation establishes that the affected gateway can reach one engineering workstation, while segmentation blocks access to the other production cells. We revise our estimate downwards.

Nothing has been patched. No account has been disabled. The investigation has improved our understanding of the environment.

That distinction matters when we report progress. We should not claim that a control reduced exposure when the number fell because an earlier assumption was too pessimistic. Equally, an increase in reported exposure can be evidence of better discovery rather than deteriorating security.

An attack-path model helps establish routes, permissions and prerequisites. It does not, on its own, tell us how likely an attacker is to use them or how much the business would lose. Those estimates still need evidence and clearly stated assumptions.

Follow the money through a specific decision

I have used a fictional manufacturer in the Cyber Capital Lab to make this easier to explore.

A supplier-access vulnerability is disclosed. Investigation confirms an affected route, but narrows its reach. The team then discovers that disconnecting the gateway would also interrupt a scheduled maintenance activity.

First, a useful distinction: retained loss is the amount left with the business after any assumed insurance recoveries.

In this example, the model assumes a 7% probability of a cyber loss event over the next 72 hours. If an event happens, the average retained loss across the model's weighted outcomes is £547,500.

Multiplying the two gives an expected retained cyber loss of £38,325 over the period. That average includes the possibility of no event. It is neither a forecast invoice nor the maximum the business could lose.

Here is how the options compare once the maintenance dependency is known, with normal production and insurance enabled:

Illustrative assumptions, rounded to the nearest pound. These are model outputs, not measured control performance. The patch option assumes a tested fix becomes available after 24 hours. Insurance applies to cyber losses, not the planned response costs shown here.

Broad isolation achieves the lowest modelled cyber loss. It also carries the highest combined cost because production is interrupted for eight hours.

Under these assumptions, a scoped restriction has a lower combined expected cost than waiting, by about £11,800. Whether it is an acceptable response still depends on being able to enforce the restriction, preserve necessary maintenance access and verify that it worked.

An average cannot settle every decision. A plausible loss could threaten the survival of the business, and safety or other mandatory constraints may rule out an otherwise attractive option. The model should make those considerations easier to discuss, rather than hide them behind a favourable return.

This example also puts a value on understanding the business. Discovering the maintenance dependency changes the cost of containment even though the estimated attack probability stays the same.

What is the spending actually buying?

A budget category is an accounting description. To assess its value, we need to understand the capability it funds.

“More SOC coverage” might mean faster investigation, fewer missed incidents or greater confidence in containment decisions. Those benefits need different evidence. A response retainer might improve access to specialist help without making an attack less likely. A recovery exercise might expose a dependency that changes the restoration plan.

The argument should connect the spending to an operational effect and then to a financial consequence.

For example, an investment in recovery could reduce the duration of an outage. We would want evidence about restoration time, the services that can be recovered and the conditions under which those results were achieved. That gives us something more useful than assuming a percentage reduction in risk because a tool was purchased.

The FAIR Controls Analytics Model is relevant here because it describes how controls affect the frequency or magnitude of loss, including their interactions. Two controls addressing the same route cannot automatically claim their full standalone benefit when deployed together.

The FAIR Materiality Assessment Model develops the loss-magnitude side in greater detail. Its breakdown of financial consequences provides a useful basis for considering costs such as business interruption and incident response.

The practical discipline is to be able to explain what a control changes, how we know, and where its benefit depends on something else working.

ROSI needs a defined decision and a consistent horizon

Return on security investment can be useful when we are comparing a specific intervention with a clear alternative.

For a simple first-year comparison:

ROSI = (expected annual loss reduction − additional first-year cost) ÷ additional first-year cost.

The difficult part is establishing a credible loss reduction. The arithmetic is straightforward.

We also need to include the costs of implementation, integration, training and operation. A licence price rarely captures the whole commitment. For investments whose costs and benefits extend over several years, the comparison needs a consistent multi-year treatment rather than squeezing everything into a first-year percentage.

An emergency decision over the next 72 hours needs its own analysis. We should not justify the immediate cost of containment by casually comparing it with a full year's expected benefit.

Insurance changes how much of a loss the business ultimately retains, so the treatment of response and interruption costs matters. In the Lab, assumed insurance recoveries are applied to the modelled cyber losses. The separate costs of carrying out a containment action, including the production interruption it causes, remain with the business. That is a simplifying assumption for this scenario, not a statement that those costs are always uninsured. A real assessment would need to establish which costs are covered, under what conditions and when reimbursement might arrive. Insurance does not remove the attack path or restore production.

Finally, expected loss reduction is not cash arriving in the bank. It is an estimate of exposure avoided. Finance should be able to see that distinction alongside the very real money being committed.

Dynamic does not mean constantly changing the budget

I would not want a security programme that lurches between investments every time a threat report appears.

Contracts, recruitment and major delivery commitments have lead times. Some capacity protects many services at once, and moving it can create an exposure elsewhere. The next decision may concern analyst time or a maintenance window rather than an unspent pot of money.

A workable approach is to agree the conditions for review before the urgent request arrives:

• Which business services and loss scenarios justify reconsidering the current plan?
• What evidence would materially change the decision?
• Which actions and spending limits are already authorised?
• Who can accept the residual exposure, and when must that acceptance be reviewed?

This is also where the discussion meets machine-speed defence. We should establish the operational and financial boundaries for repeatable containment decisions in advance. Requiring a new financial assessment during every incident would introduce another bottleneck.

Where the consequence is uncertain or the intervention could interrupt a critical service, a human decision may still be needed. That person should have an actionable comparison, with the assumptions visible, rather than a severity label and an urgent request to approve.

There is a deeper discussion to have about the cost of waiting, the value of further investigation and when an intervention should be pre-authorised. The starting point is knowing which decision we are trying to improve.

Put the decision under pressure

I built the Cyber Capital Lab to make these trade-offs something you can explore for yourself. It uses a fictional manufacturer and illustrative assumptions. The ranges show sensitivity to those assumptions, not confidence intervals or Monte Carlo results.

Start at “Dependency found”, with normal production and insurance enabled, to reproduce the comparison above. Try disconnecting the gateway, then compare it with restricting supplier access. Switch to peak production and see what happens to the cost of interruption.

You can also change the insurance setting or explore the separate annual investment view. The question throughout is the same: what changes the decision, and why?

Explore the Cyber Capital Lab

Which assumption would you challenge first, and what evidence would you need before authorising the decision?