CAF Principle B5: Resilient Networks and Systems
CAF principle B5 asks whether you can keep going and recover after an attack or system failure, through preparation, resilient design and usable backups. It matters under the Cyber Security and Resilience Bill (CSRB) because disruption and duration are both factors in assessing incidents.
The Bill is not yet law. Regulation and section references come from the Bill as brought from the Commons (HL Bill 32). The Lords has since amended the Bill, so numbering and detail may change in the final Act. This guide is general information, not legal advice.
What B5 asks
B5 in the National Cyber Security Centre's Cyber Assessment Framework (CAF) builds resilience against both cyber attack and system failure. Under the Cyber Security and Resilience Bill (CSRB), it is a reminder that preventing every attack is not the only goal: reducing how long and how badly a service is affected matters too.
| Outcome | Question |
|---|---|
| B5.a Resilience Preparation | Do you know how to restore the function, and in what order? |
| B5.b Design for Resilience | Can systems withstand attacks and resource limits? |
| B5.c Backups | Can you really recover from what you hold? |
Recovery order is a real deliverable
The partially achieved level of B5.a requires something many organisations have not written down: the order in which systems must be recovered to restore the function. Getting this right means understanding dependencies, including identity, DNS and network services that everything else needs first.
The achieved level adds tested business continuity and disaster recovery plans, using methods such as manual fail-over, table-top exercises or red-teaming. It also expects threat information to be able to trigger immediate, temporary security measures, for example during a widespread outbreak of very damaging malware.
Backups for an extreme event
B5.c is broader than data. The partially achieved level includes configuration information, software, equipment, processes and knowledge, and expects backups to remain accessible after an extreme event, including ransomware. So ask these questions:
- Could an attacker holding your admin credentials delete or encrypt the backups?
- Could you rebuild if your identity system and documentation were also unavailable?
- When did you last prove a real restore, and how long did it take?
Slow restoration counts as a warning sign if it does not bring back the essential function in a suitable time frame.
What can show it
These are our suggestions, not NCSC requirements:
- A dependency map and agreed recovery sequence for each essential function
- Dated results from restore and fail-over tests, including timings compared with targets
- A resource limitation register, with mitigations for single paths and geographical constraints
- Network architecture showing how essential systems are separated
- A list of temporary measures you could use if threat levels rise
Where organisations fall short
- Paper plans: continuity plans exist, but their practical implementation has not been assessed.
- Incomplete coverage: backups miss some of the data and information needed for restoration.
- Backups too infrequent: the function cannot be restored effectively from the latest copy.
- Hidden single points: one path or one location supports the function.
- Stale assessments: dependency and limitation reviews are not updated when systems change.
How B5 relates to the Bill
The Bill's text does not name the CAF, and the CAF is not itself legislation. B5 still connects to the Bill in practical ways.
For OES, RDSP and RMSP incidents, significance factors include the extent of disruption and the duration of the incident. Good resilience can reduce both, which helps your service as well as the risk involved. It does not remove your reporting duty if the test is met. For data centres, an incident that could have had a significant impact can also be reportable, even if resilient design avoided the worst.
RMSPs must also prevent and minimise the impact of incidents under regulation 14B. Recovery capability is a natural part of how you can show you have considered that.
Next, read CAF 4.0 explained, the CAF self-assessment guide and our overview of the framework.
Sources
Frequently asked questions
Backups should be secured, accessible in an extreme event including a ransomware attack, and routinely tested. At the achieved level, they are comprehensive, automatic and tested, and held at centrally accessible or secondary sites.
Yes. B5.b looks at segregation. Logical separation fits partially achieved, while separate network and system infrastructure with independent user administration is an example given at the achieved level.
Examples include network bandwidth limits and single network paths. B5.b expects you to identify and mitigate them.
B5 builds the ability to recover into your systems and preparations. D1 covers planning and running the response to an incident. They should work together.