Requirements - Non-Functional Profile
-
NF02 - Reliability & Resilience
Reliability & Resilience needs should be defined (in terms of standard NHS England service levels) and solution mechanisms to meet these needs are defined including metrics such as Recovery Time Objective (RTO) and Recovery Point Objective (RPO).
Requirement description
This requirement is about ensuring that reliability and resilience expectations are understood, documented and reflected in the solution design.
The service should have clearly defined availability, recovery and resilience requirements. The architecture should include mechanisms that enable those requirements to be met. This includes documented recovery objectives such as RTO and RPO where applicable.
In simple terms:
The team understands how reliable the service needs to be and can demonstrate how the architecture delivers those reliability and resilience requirements.
Scoring rubric table – NF02 Reliability & Resilience
| Score | What it looks like | Typical evidence | Key gaps / risks |
|---|---|---|---|
| 0 | No evidence that reliability or resilience requirements have been defined. The architecture does not demonstrate how service continuity will be maintained. | No service level requirements, resilience requirements, recovery objectives, architecture evidence or operational documentation. | Significant service risk. Service reliability expectations are unknown and recovery capability cannot be assessed. |
| 1 | Limited evidence that reliability and resilience have been considered. Requirements are informal, assumed or inconsistently documented. | Informal discussions, supplier statements, draft documents or undocumented assumptions regarding availability and recovery. | High-risk gaps. Recovery expectations, availability targets and resilience mechanisms are unclear or unverified. |
| 2 | Some reliability and resilience requirements have been defined. Elements of the architecture support resilience objectives, but significant gaps remain. | Partial non-functional requirements, draft service levels, limited RTO/RPO definitions, documented backup or failover arrangements. | Significant notable gaps in requirements coverage, architecture alignment, operational readiness or validation. |
| 3 | Much of the requirement is met. Reliability and resilience requirements are documented and the architecture contains mechanisms intended to meet them. | Approved non-functional requirements, documented service levels, recovery objectives, resilience patterns, architecture diagrams, risk assessments and operational procedures. | Notable gaps remain in coverage, testing, dependency management, operational capability or evidence that objectives can be achieved. Mitigating action is required. |
| 4 | Most of the requirement is met with good levels of evidence. Reliability and resilience requirements are maintained, understood, and reflected throughout the architecture and operating model. | Approved and maintained non-functional requirements, documented service level targets, defined and reviewed RTO/RPO values, resilience architecture documentation, governance reviews and resilience testing evidence. | Minor gaps only. Remaining risks are known, documented and actively managed. |
| 5 | Comprehensive evidence that the requirement is met and exceeds expectations. Reliability and resilience are embedded throughout design, delivery and operations. | Mature resilience strategy, architecture patterns aligned to service objectives, regular resilience testing, documented lessons learned, evidence of continual improvement, service-level reporting and governance oversight. | Minimal gaps. Reliability objectives are demonstrably achieved and resilience capability is continually reviewed and improved. |
What assessors should look for
-
Defined service level requirements
Evidence that availability, reliability and recovery expectations have been formally documented. -
Recovery objectives
Evidence that RTO, RPO or equivalent recovery expectations have been defined and agreed. -
Architectural resilience mechanisms
Evidence that the design includes appropriate resilience measures such as redundancy, failover, replication or recovery processes. -
Alignment between requirements and design
Evidence that the architecture can realistically meet the stated service level objectives. -
Risk and dependency management
Evidence that resilience risks, single points of failure and critical dependencies have been identified and managed. -
Validation and testing
Evidence that resilience assumptions, recovery arrangements and service objectives have been tested or validated.
What separates a 3 from a 4 or 5
A score of 3 usually means that reliability and resilience requirements have been defined and the architecture contains mechanisms intended to meet them, but there are notable gaps in testing, validation, dependency management or operational assurance.
A score of 4 requires evidence that requirements are actively maintained, reviewed and aligned to the architecture. Recovery objectives are understood, documented and supported by operational processes and governance.
A score of 5 requires evidence that resilience is treated as an ongoing capability rather than a design exercise. The organisation regularly validates resilience measures, learns from incidents and exercises, and continuously improves the architecture and operational processes.
Suggested examples of evidence (not SAF-mandated artefacts):
- Non-functional requirements specification.
- Service level objectives (SLOs).
- Availability and resilience requirements.
- RTO and RPO definitions.
- Architecture decision records.
- Resilience architecture diagrams.
- Failover and recovery procedures.
- Resilience testing reports.
- Operational readiness reviews.
- Service continuity risk assessments.
Updated: 07 August 2026 (SAF Version 1.1)