A cyber resilience strategy is the set of decisions about where finite money and attention go: what you will defend hardest, which scenarios you plan for, how much disruption you are willing to accept, and how effort is split between stopping attacks and surviving them. A framework tells you what the components are. A strategy decides which of them you fund first, and why, in language a board can approve.
- A short list of what genuinely cannot be lost, rather than a claim that everything is critical.
- Named scenarios you are planning against, chosen deliberately.
- An agreed tolerance for disruption, signed off by people who own the consequences.
- An explicit split between prevention and recovery, instead of one by default.
- A sequence, because everything cannot be first.
- Measures that show progress without requiring an incident to prove it.
What is a cyber resilience strategy?
A strategy is a set of choices under constraint. If budget and attention were unlimited there would be no strategy, only a list of good practice to implement. The reason strategy exists is that you cannot do everything at once, so someone has to decide what comes first and what is knowingly accepted for now.
This is what distinguishes it from the framework. The cyber resilience framework sets out the functions that need covering and what evidence each produces. It is structural and it does not prioritise. A strategy takes that structure and answers the harder questions: given what we can afford this year, which gaps are we closing, which are we living with, and what would have to change for that answer to change.
Strategies fail in a recognisable way. They restate good practice as ambition, commit to improving everything, and provide no basis for saying no to anything. A document that would still read correctly if pasted into another organisation’s letterhead is not a strategy.
This page assumes the underlying concept. For what cyber resilience is, how it differs from cyber security and where the EU Cyber Resilience Act applies, start there.
What decisions does a cyber resilience strategy make?
Six, and they are easier to make in this order because each constrains the next.
- Assets: what would genuinely damage the organisation if lost, exposed or unavailable. If the list runs past a handful of things, the prioritisation has not happened yet.
- Threats: which scenarios you are planning against. Ransomware, insider misuse, supplier compromise and credential theft behave differently and do not all yield to the same spending.
- Appetite: how much disruption is acceptable, and where the line sits beyond which it is not. Vague appetite statements are the most common weak point.
- Balance: how effort divides between preventing incidents and surviving them. Left undecided, this defaults heavily towards prevention because prevention is easier to buy.
- Sequence: the order of work, ranked by risk reduced per unit of effort rather than by which team asked loudest.
- Measure: what tells you it is working before an incident does. Coverage by function, time to detect, time to recover, exercises completed.
The decision that most changes outcomes is the fourth. Organisations that never make it explicitly discover during their first serious incident that they bought detection tooling and never rehearsed a response, or that backups existed and nobody had timed a restore.
How do you decide the balance between prevention and recovery?
Not by principle, but by looking at where you already are. Most organisations arrive at this question with a heavy prevention bias, because prevention is sold as products with clear features while recovery capability is mostly rehearsal, ownership and discipline that nobody markets.
| Question | What a weak answer sounds like | What it should sound like |
|---|---|---|
| What are we defending? | Everything is business critical. | These four services, in this order, for these reasons. |
| How long can we be down? | As little as possible. | Four hours for payments, two days for reporting. |
| Would we spot it? | We have monitoring in place. | We detected the last simulation in 40 minutes. |
| Could we recover? | We have backups. | We restored this system in a test last quarter and it took nine hours. |
| Who decides on the day? | The incident team would convene. | Named person, named deputy, both exercised. |
Working down the right hand column is a faster route to a defensible strategy than any maturity model. Every specific answer is either already true, in which case it is evidence, or not yet true, in which case it is a priority. That distinction is the whole strategy.
There's a bigger picture behind this.
This page covers one part of business resilience. Real Resilience — IO’s framework for connecting security, privacy and AI governance — is where the full picture comes together.
How do you build the case for investment?
Cyber resilience competes for money against things with visible returns, and it loses when argued in technical terms. What travels is consequence expressed in the language the rest of the business uses.
- Lead with the service, not the threat: what customers cannot do, and for how long, rather than the name of the attack technique.
- Quantify the interval, not the incident: the cost of being unable to trade for a day is arguable in a way that estimates of total breach cost are not.
- Show tested capability against assumed capability: the gap between the two is the clearest argument available and it needs no forecasting.
- Bring the trade-off, not just the ask: what a smaller budget would mean in terms of accepted risk gives the board something to decide rather than approve.
- Use contract and tender pressure: where customers demand certification or evidence, resilience becomes a revenue condition rather than a cost centre.
- Report the same measures every time: a consistent short set beats a comprehensive dashboard nobody reads twice.
Certification is unusually useful here because it converts an internal claim into an externally verified one. A board that discounts a self assessment will generally accept an audited management system, and the evidence needed for one largely overlaps with the evidence a strategy should be producing anyway.
What should a cyber resilience strategy avoid?
The failure patterns are consistent enough to check against directly.
- A tool list disguised as a strategy: procurement plans describe what you will buy, not what you have decided.
- No stated appetite: without a line, every risk is arguable and nothing can be knowingly accepted.
- Everything critical: a critical asset list of forty items provides no basis for sequencing.
- Prevention only: an implicit assumption that recovery will work, which holds until it is tested.
- Threat led with no scenarios: threat intelligence describing what attackers do, with no decision about which of it you plan for.
- Measures nobody can produce: metrics chosen because they sound rigorous rather than because the data exists.
- Written once: a three year strategy never revisited, in a domain where the estate and the threats both move quarterly.
Get started easily with a personal product demo
One of our onboarding specialists will walk you through our platform to help you get started with confidence.
How does the strategy connect to the Resilience Loop?
A cyber resilience strategy that only considers cyber will be rewritten within a year, because the same assets it protects are also subject to privacy obligations and, increasingly, to AI governance requirements. Deciding your security priorities in isolation from those tends to produce three roadmaps competing for the same people.
The Resilience Loop runs information security under ISO 27001, data privacy under ISO 27701 and AI governance under ISO 42001 as one connected system. Sequencing across all three at once is what turns a cyber strategy into a resilience strategy, and it changes the arithmetic: a control implemented once counts three times, so the cheapest next move is often the one that serves more than one obligation. The wider structure is set out in the business resilience framework.
How do you know the strategy is working?
Before an incident, only two things tell you: coverage and tested capability. Coverage is whether every function has an owner and a current picture. Tested capability is the difference between what you assume works and what you have demonstrated works, and it is the only measure that cannot be gamed.
A short, repeated set of measures beats a comprehensive one. Time to detect in the last exercise. Time to restore the most critical service, measured rather than targeted. Proportion of critical services with a rehearsed response. Exercises completed against exercises planned. Each is producible from work you should be doing anyway, which is the test of a reasonable measure. The approach is set out in how to evidence resilience, and the Resilience Score gives you a baseline to move from.
Why choose ISMS.online for cyber resilience strategy?
A strategy is only as good as the evidence that it is being executed. ISMS.online connects the decisions to the work.
- Priorities linked to controls and risks: what you decided to defend connects to the controls protecting it and the risks against it.
- One control set, every framework: sequence work by how many obligations each control satisfies across ISO 27001, ISO 27701, ISO 42001 and ISO 22301.
- Tested against assumed, visible: exercise records and findings sit with the controls, so the gap is a number rather than a feeling.
- Board reporting from live data: report the same measures each cycle without assembling them by hand.
- Risk appetite recorded and applied: the line you agreed is held against the risks you are accepting, not filed and forgotten.
- Helps you achieve certification: turns internal claims into an independently audited position that boards and customers accept.
- Built for UK and regulated markets: designed for organisations that have to prove resilience to win and keep contracts.
See how it fits together on the business resilience platform, or book a demo.
FAQs
What is the difference between a cyber resilience strategy and a framework?
A framework is structural. It sets out the functions that need covering and what evidence each produces, and it applies to any organisation. A strategy is a set of choices specific to yours: which gaps you are closing this year given a finite budget, which you are knowingly accepting, and what you are defending hardest. The framework tells you what good looks like. The strategy decides what you are doing about it and in what order.
How long should a cyber resilience strategy be?
Short enough that the leadership team has read it. The decisions that matter, which assets, which scenarios, what appetite, what balance, what sequence and what measures, fit comfortably in a handful of pages. Length usually signals that good practice has been restated rather than choices made, and a strategy nobody can recall the priorities from is not operating.
How much of the budget should go to recovery rather than prevention?
There is no correct ratio, and any figure quoted as universal should be treated with suspicion. The useful approach is to look at your own position: if you can describe your preventive controls in detail but cannot say how long a restore of your most critical system takes, the imbalance is diagnosed and the next increment belongs to recovery. Make the split explicitly, because left undecided it defaults towards prevention.
Who owns the cyber resilience strategy?
It is written by whoever leads security and owned by the board, because the decisions in it are about accepted risk and that cannot be delegated to a technical function. The distinction matters in practice: a strategy owned only by the security team can be overruled by any budget round, whereas one the board has accepted the risk trade-offs in tends to survive them.
How often should the strategy be revisited?
Annually as a full review, with the sequence revisited whenever something material changes: a significant incident anywhere in your sector, a major system or supplier change, a new obligation, or an exercise that invalidates an assumption. The decisions themselves are reasonably stable. What moves is the sequence, because the risk reduced by each remaining piece of work changes as the estate changes.
