--- title: "Beyond prevention: a cyber resilience strategy for the breach you will have" canonical: https://www.grcmana.io/blog/designing-for-the-breach published: 2026-03-10 updated: 2026-10-22 authors: ["Harry West"] --- # Beyond prevention: a cyber resilience strategy for the breach you will have ## Key takeaways A cyber resilience strategy starts from the assumption that a serious breach will happen. The FCA's operational resilience rules already test whether important business services stay within impact tolerance in a severe but plausible disruption, so a programme judged only by what it prevents answers the wrong question. Prevention is the floor; resilience has to be designed, rehearsed and evidenced. - **The premise** — The NCSC Cyber Assessment Framework states that incidents will invariably happen, and its Objective D asks for capabilities that minimise their impact and restore essential functions. - **The FCA test** — SYSC 15A.2.9 requires in-scope firms to stay within impact tolerance for each important business service during a severe but plausible disruption, and they had until 31 March 2025 to be able to. - **UK prevalence** — In the government's Cyber Security Breaches Survey 2025, 67% of UK medium-sized businesses reported a cyber breach or attack in the previous 12 months, yet many still had no incident response plan. - **Three design moves** — Contain the blast radius, rehearse the decisions leaders face in the first hours, and set recovery objectives from impact tolerances, proven by real restores rather than written into a plan. Your firm will have a serious breach. So a cyber resilience strategy should start from that assumption, not from the controls meant to prevent it. Plenty of security leaders would push back on that, because prevention is what budgets, board packs and certificates measure. But when your board asks what happens when you get breached, a list of controls doesn't answer it. The FCA asks a sharper question: can each important business service stay within its impact tolerance when a severe but plausible disruption happens? Not if. When. Prevention is the floor, not the plan. Here's why I hold that view, the strongest argument against it, and what I'd do about it. ## Why isn't a prevention-led security programme enough? A prevention-led programme measures what you have built to stop an attack. It says very little about how the firm behaves once an attack gets through. Breaches at firms your size are common, and many of those firms have no plan for the day after. Prevention scores answer a different question from the one your board is asking. The case for prevention is real, and I'd state it fairly. Prevention spend is visible. Control counts can be audited. A certificate gives the board and your clients something to point at. And the basics work: the NCSC still tells every organisation to start with the five foundational measures in Cyber Essentials. The trouble is what those proxies leave out. In the government's [Cyber Security Breaches Survey 2025](https://www.gov.uk/government/statistics/cyber-security-breaches-survey-2025), 67% of medium businesses (50 to 249 employees) reported a cyber breach or attack in the previous 12 months. Only 53% of medium businesses had an incident response plan, and in the finance and insurance sector the figure was 50%. The NCSC's [Cyber Assessment Framework](https://www.ncsc.gov.uk/collection/cyber-assessment-framework/caf-objective-d/principle-d1-response-and-recovery-planning) has a whole objective on minimising the impact of incidents, and it puts the premise plainly: "Incidents will invariably happen." A certificate tells you what was true on the day it was issued. As I've said before about annual certifications, that's not assurance. That's history. ## What does the FCA's operational resilience regime already assume? As I read them, the FCA's operational resilience rules assume disruption will happen and ask whether you can stay within tolerance when it does. In-scope firms had until 31 March 2025 to ensure they could keep each important business service within its impact tolerance. Prevention controls are not the test. The FCA set out the rules in [PS21/3](https://www.fca.org.uk/publications/policy-statements/ps21-3-building-operational-resilience) in March 2021, and they have applied since 31 March 2022. The core rule is [SYSC 15A.2.9](https://www.handbook.fca.org.uk/handbook/SYSC/15A/): "A firm must ensure it can remain within its impact tolerance for each important business service in the event of a severe but plausible disruption to its operations." Among the scenarios the FCA's guidance says you should consider in testing is the "corruption, deletion or manipulation of data critical to the delivery of its important business services". Ransomware is the obvious example, and the test asks how you recover from it, not how you would have stopped it. The FCA's [operational resilience page](https://www.fca.org.uk/firms/operational-resilience) now points firms at examples of "simulating severe but plausible cyber scenarios to stay within impact tolerance". The direction of travel is clear. A word on scope. SYSC 15A applies to banks, building societies, Solvency II insurers, enhanced scope SM&CR firms, and payment and e-money institutions, among others. If your firm sits outside that list, as many smaller core SM&CR firms do, it is not your rule. It is still the clearest statement I know of the question that matters. The NCSC says the same thing in different words. Writing in September 2025, its Director of National Resilience argued that ["Resilience is a continuous process, and it is every bit as important as prevention"](https://www.ncsc.gov.uk/blog-post/why-resilience-matters-as-much-as-defence). If you provide ICT services to EU financial entities, DORA reaches you through the contract rather than directly. Articles 11 and 12 of [Regulation (EU) 2022/2554](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) require those clients to have tested response and recovery plans, and, when they restore backups on their own systems, to use systems segregated from the source. For services that support critical or important functions, Article 30(3)(c) has them write into your contract a duty to "implement and test business contingency plans". ## Why is resilience the operating state, not a project? Reducing risk is the floor. Building resilience is the operating state the firm lives in every day, and trust is the commercial payoff. A cyber resilience strategy that treats resilience as an annual project, finished when the self-assessment is signed, has already drifted by the time anyone reads it. I've held security leadership roles as Global CISO at Pepper Advantage and Rackspace Technology, and as Head of Information Security at the UK National Audit Office. That's the vantage point I'm writing from. Three positions follow from it. - **A mapping is a point in time.** Impact tolerances, ICT dependencies and third parties all move. The question isn't whether you mapped your important business services once. It's whether the mapping is maintained and tested. - **Show the regulator, don't tell them.** SYSC 15A.6.1 already requires a written self-assessment. Lead with the evidence of what you tested and what you fixed, not the policy that says you will. - **Resilience is engineered.** Compliance works best as a continuous state, where drift is detected and flagged before it becomes an incident, not as an annual scramble. ## What is the strongest objection to planning for the breach? The strongest objection is about money. A firm of 80 people has a small security budget, and every pound spent on recovery is a pound not spent on keeping attackers out. Stop the breach and you never need the plan. It's a fair point, and it rests on a false choice. The objection assumes resilience is a separate budget line. Mostly it isn't. Segmenting the network and tightening privileged access are prevention controls, and they are also what limits how far one compromise spreads. The same pound buys both. The other two moves cost time, not money. Deciding who can take a service offline costs a meeting. The NCSC's [Exercise in a Box](https://www.ncsc.gov.uk/information/exercise-in-a-box) is "a free resource to help organisations rehearse their response to cyber attacks", and small and medium-sized enterprises are among its users. And a small firm has less slack, not more. Fewer people, fewer systems to fail over to, and less tolerance for a week offline. That's a reason to design for the breach, not to skip it. ## What should you do about it? Five moves, in order: 1. **Contain the blast radius.** Assume one account or one laptop is compromised and ask how far an attacker could get from there. Segment the network so a single foothold can't reach everything ([network segregation](https://www.grcmana.io/vault/iso-27001/annex-a-8-22-segregation-of-networks)), keep privileged access narrow, and map which systems each important business service depends on. 2. **Rehearse the decisions.** Write down who decides in the first hours, who tells the regulator and customers, and who has the authority to take a service offline. Then practise it in a tabletop exercise. The NCSC's Director of National Resilience is blunt: "the organisations that handle incidents best are the ones that have rehearsed them." Your [incident management planning](https://www.grcmana.io/vault/iso-27001/annex-a-5-24-information-security-incident-management-planning-and-preparation) should name people, not departments. 3. **Set recovery objectives from impact tolerances.** Work back from the maximum disruption each important business service can tolerate, and set recovery time and data loss targets inside it. Then prove them with real restores, not a line in a plan. [Backup and restore testing](https://www.grcmana.io/vault/iso-27001/annex-a-8-13-information-backup) is where a recovery claim meets reality. 4. **Keep the mapping live.** Review it whenever a service, supplier or system changes, not only at the annual self-assessment. Tie it to your [ICT readiness for business continuity](https://www.grcmana.io/vault/iso-27001/annex-a-5-30-ict-readiness-for-business-continuity), so a new dependency can't quietly break a tolerance. 5. **Keep the evidence.** Every exercise, restore test and fix belongs in the record you'd show the regulator. If you can't show it, you can't claim it. How you measure whether this is working is its own subject, and I'll cover it separately. ## Where should your cyber resilience strategy start? Prevention still matters. But it is the floor. The question your board and the FCA will ask is what happens next, and a cyber resilience strategy built on that question is one you can evidence. If you're starting from nothing, start with the document you'd reach for on the worst day: our [incident response plan template](https://www.grcmana.io/vault/templates/incident-response-plan).