Cyber Risk Management Needs Planned Maintenance.
Nobody would commission a bridge and assume that because it was safe on the day it opened, it would remain safe indefinitely.
We inspect it. Maintain it. We replace components and reassess it as loads, usage and environmental conditions change. The same is true of aircraft, manufacturing equipment, power systems and almost every other engineered system upon which we depend.
Yet cybersecurity has an odd tendency to behave differently. We implement a control, test it and declare it effective. And then, consciously or otherwise, begin treating that effectiveness as though it were permanent.
It isn't. Controls degrade.
And that means cyber risk management needs something engineering has understood for a very long time:
Planned Maintenance.
Effective Today Doesn't Mean Effective Forever
Consider a well-configured firewall.
On the day it is implemented, the rules may accurately reflect the organisation's network, applications and security requirements.
Then the business changes. New applications are introduced. Temporary exceptions become permanent and people leave. Suppliers change. Networks are reconfigured Cloud services appear and rules accumulate.
The firewall may still be operating perfectly but the environment it was designed to control has changed. Its effectiveness may therefore have changed too.
The same principle applies elsewhere. An EDR platform can become less effective if coverage deteriorates or its configuration isn't maintained. Backups can exist while confidence in restoration quietly diminishes because recovery hasn't been tested.
An incident response plan can remain beautifully documented while the people, suppliers and technology upon which it depends have completely changed. Security awareness deteriorates as people forget training and new employees arrive. Vulnerability management deteriorates if scanning coverage no longer reflects the estate. Identity controls deteriorate as privileges accumulate.
The control hasn't necessarily "failed". The relationship between the control and the system has changed. The control effectiveness has degraded. It is this distinction that matters.
Controls Bound the Future
There is an engineering principle that I increasingly find useful when thinking about risk:
Effective controls bound the future within practical limits.
A control does not predict what will happen. Nor does it guarantee that something undesirable cannot happen. It constrains the range of plausible outcomes.
A tested backup cannot guarantee that an organisation will never suffer an outage. However, it can materially constrain how long that outage lasts and how damaging it becomes.
MFA cannot guarantee that an account will never be compromised but it can constrain the circumstances in which compromise is possible.
Network segmentation cannot guarantee that malware will never enter the environment although it can constrain how far it can travel.
That is what effective controls give us. Not certainty. Bounds.
And those bounds have economic value because they make future loss more manageable.
But the Bounds Move
Time also plays an important role. Imagine assessing a critical application today where its technology is understood, its accessibility is known and its vulnerabilities are being managed.
Assume that its controls are effective and its plausible financial exposure has been assessed. Management decides how much risk to mitigate, transfer, accept and avoid.
Excellent. But what happens next?
The application changes. The business changes. Controls change, the threat environment changes. Perhaps the financial importance of the application changes. Perhaps an application that supported £5 million of revenue now supports £50 million.
Perhaps an internal system becomes Internet-facing. Perhaps a new supplier gains privileged access. Perhaps the organisation acquires another company.
The assessment that was perfectly reasonable twelve months ago may no longer describe reality. This isn't necessarily because the original assessment was wrong. It is because time has passed.
Now, I appreciate that this is all pretty obvious but I use this simple illustration to show how controls specifically; and resilience generally, degrades over time.
Risk Assessments Have a Shelf Life
This creates an uncomfortable problem for traditional risk assessment.
We often treat an assessment as an artefact. We complete and approve it. Then we generate the report, store the evidence and that's it until we return next year.
But risk is not an artefact. It is a condition. And conditions change.
A risk assessment therefore begins ageing almost as soon as it is completed.
The question isn't whether, or when, it will become outdated. It is how quickly.
That degradation rate will differ between critical assets. Whilst a stable legacy application may change relatively slowly, a rapidly developing digital platform might change every week.
A merger can alter dependencies overnight. A new vulnerability can change exposure in hours.
So perhaps we should stop thinking primarily in terms of periodic reassessment and start thinking in terms of planned revision.
Revision Is Maintenance
I want to make another important distinction. Reassessment sounds like repeating an exercise.
Revision means asking what has changed since the last decision?
Has the asset changed?
Has its business importance changed?
Has its accessibility changed?
Has its technology changed?
Have vulnerabilities changed?
Have controls changed?
Have the plausible financial consequences changed?
Has insurance changed?
Has management's capacity or willingness to accept loss changed?
If nothing material has changed, there may be very little to do. However, if something has changed, revise the relevant assumptions and recalculate the position.
That is much closer to engineering maintenance. You don't rebuild an aircraft at every inspection. But you do need to inspect the things that matter, identify change or deterioration and intervene where necessary.
I believe that cyber risk management should work similarly.
Simplicity Matters
There is another connection with the earlier papers in this series.
If an assessment requires months of work and hundreds of questions, organisations will naturally resist repeating it. The cost of maintenance becomes too high and eventually the assessment becomes obsolete.
A practical risk methodology therefore has to be maintainable. That means being sufficiently concise that organisations can revisit assumptions as circumstances change.
This is another reason why:
If it doesn't improve the decision, it doesn't belong.
Noise isn't merely inconvenient during the initial assessment. It creates a maintenance burden forever afterwards. Every unnecessary field becomes another field that potentially needs reviewing and every unnecessary dependency becomes something that must be maintained.
Simplicity therefore has a lifecycle value.
Maintenance Has an Economic Purpose
Planned maintenance isn't simply good cyber hygiene, it protects the value of previous investment.
Suppose an organisation spends £1 million implementing a control that materially reduces financial exposure. If that control's effectiveness gradually deteriorates because nobody maintains it, part of the original investment is effectively being lost.
Maintenance expenditure therefore shouldn't automatically be regarded as another cybersecurity cost. It is expenditure intended to preserve the risk reduction already purchased.
That fact should change the conversation. Instead of asking:
"Why do we have to spend more money on this control?"
the better question may be:
"What investment is required to preserve the bounds this control was designed to provide?"
That's an economic question as much as a technical one.
Leading to a Bigger Question
Earlier in this series I asked how much cybersecurity is enough. There is a related question we haven't yet answered:
How long does the risk reduction we purchase actually last?
Two controls might cost the same amount. They might initially reduce similar amounts of financial exposure. But if one requires substantial continual investment while another remains effective with relatively little maintenance, their economics are not the same.
Eventually, I think cyber risk management will need to become much better at understanding this. Not merely:
Risk reduction ÷ cost
but something closer to:
Sustained risk reduction over time ÷ total cost of maintaining it.
We're not there yet but I believe that's where the economics of cyber resilience ultimately leads.
Resilience Is Maintained, Not Achieved
Perhaps the most important lesson from engineering is that resilience is never finished. We don't build resilience once. It's an ongoing effort. We maintain it.
The same needs to apply to cybersecurity. Controls are implemented. The environment changes. Effectiveness changes. Risk changes.
We review, revise and maintain. Then the cycle begins again.
This is why a cyber risk assessment should never really be considered "complete". It is simply an informed view of the entity at a particular point in time.
Good cyber risk management keeps that view sufficiently current to support the next decision. That requires planned maintenance.
In the final paper in this series, I'll bring together the ideas we've explored - from critical assets and financial consequences to risk treatment, portfolio management and planned revision -and ask one final question:
What does good actually look like?
Thought for the week:
"Resilience isn't achieved. It is maintained."
