There should be clear requirements (commensurate with service levels) around DR & BC (and a pragmatic approach taken with regards DR/BC events planned for).
- -Continuity plans and supporting documentation should reflect the requirements, technical & architecture constraints etc.
- -This is an extra line.
- - - - -{% endblock %} diff --git a/app/views/solution-architecture-framework/requirements.njk b/app/views/solution-architecture-framework/requirements.njk index 72b117d5a..632b8fbc8 100644 --- a/app/views/solution-architecture-framework/requirements.njk +++ b/app/views/solution-architecture-framework/requirements.njk @@ -256,23 +256,23 @@Audit & logging requirements should be defined, and the solution can support them.
@@ -280,7 +280,7 @@Disaster Recovery & Business Continuity
There should be clear requirements (commensurate with service levels) around DR & BC (and a pragmatic approach taken with regards DR/BC events planned for).
diff --git a/app/views/solution-architecture-framework/requirements/d/d01.njk b/app/views/solution-architecture-framework/requirements/d/d01.njk new file mode 100644 index 000000000..6458e55c8 --- /dev/null +++ b/app/views/solution-architecture-framework/requirements/d/d01.njk @@ -0,0 +1,20 @@ +{% set pageTitle = "D01 - Document Storage" %} +{% set pageSection = "Standards and technology" %} +{% set subSection = "Solution Architecture Framework - Requirements - Documentation" %} +{% set pageDescription = "" %} +{% set beta = true %} +{% set hideContact = "false" %} +{% set dateUpdated = "07 August 2026 (SAF Version 1.1)" %} + +{% extends "includes/app-layout.njk" %} + +{% block breadcrumb %} + {% include "solution-architecture-framework/_breadcrumb.njk" %} +{% endblock %} + +{% block bodyContent %} + + + + +{% endblock %} diff --git a/app/views/solution-architecture-framework/requirements/d/d02.njk b/app/views/solution-architecture-framework/requirements/d/d02.njk new file mode 100644 index 000000000..2fb387678 --- /dev/null +++ b/app/views/solution-architecture-framework/requirements/d/d02.njk @@ -0,0 +1,20 @@ +{% set pageTitle = "D02 - Open Publication" %} +{% set pageSection = "Standards and technology" %} +{% set subSection = "Solution Architecture Framework - Requirements - Documentation" %} +{% set pageDescription = "" %} +{% set beta = true %} +{% set hideContact = "false" %} +{% set dateUpdated = "07 August 2026 (SAF Version 1.1)" %} + +{% extends "includes/app-layout.njk" %} + +{% block breadcrumb %} + {% include "solution-architecture-framework/_breadcrumb.njk" %} +{% endblock %} + +{% block bodyContent %} + + + + +{% endblock %} diff --git a/app/views/solution-architecture-framework/requirements/d/d03.njk b/app/views/solution-architecture-framework/requirements/d/d03.njk new file mode 100644 index 000000000..04db6db82 --- /dev/null +++ b/app/views/solution-architecture-framework/requirements/d/d03.njk @@ -0,0 +1,20 @@ +{% set pageTitle = "D03 - Document Scope" %} +{% set pageSection = "Standards and technology" %} +{% set subSection = "Solution Architecture Framework - Requirements - Documentation" %} +{% set pageDescription = "" %} +{% set beta = true %} +{% set hideContact = "false" %} +{% set dateUpdated = "07 August 2026 (SAF Version 1.1)" %} + +{% extends "includes/app-layout.njk" %} + +{% block breadcrumb %} + {% include "solution-architecture-framework/_breadcrumb.njk" %} +{% endblock %} + +{% block bodyContent %} + + + + +{% endblock %} diff --git a/app/views/solution-architecture-framework/requirements/dm/dm01.njk b/app/views/solution-architecture-framework/requirements/dm/dm01.njk new file mode 100644 index 000000000..1fd94a7c4 --- /dev/null +++ b/app/views/solution-architecture-framework/requirements/dm/dm01.njk @@ -0,0 +1,20 @@ +{% set pageTitle = "DM01 - Debt" %} +{% set pageSection = "Standards and technology" %} +{% set subSection = "Solution Architecture Framework - Requirements - Decision Making & Governance" %} +{% set pageDescription = "" %} +{% set beta = true %} +{% set hideContact = "false" %} +{% set dateUpdated = "07 August 2026 (SAF Version 1.1)" %} + +{% extends "includes/app-layout.njk" %} + +{% block breadcrumb %} + {% include "solution-architecture-framework/_breadcrumb.njk" %} +{% endblock %} + +{% block bodyContent %} + + + + +{% endblock %} diff --git a/app/views/solution-architecture-framework/requirements/dm/dm02.njk b/app/views/solution-architecture-framework/requirements/dm/dm02.njk new file mode 100644 index 000000000..e3da52f82 --- /dev/null +++ b/app/views/solution-architecture-framework/requirements/dm/dm02.njk @@ -0,0 +1,20 @@ +{% set pageTitle = "DM02 - External Controls" %} +{% set pageSection = "Standards and technology" %} +{% set subSection = "Solution Architecture Framework - Requirements - Decision Making & Governance" %} +{% set pageDescription = "" %} +{% set beta = true %} +{% set hideContact = "false" %} +{% set dateUpdated = "07 August 2026 (SAF Version 1.1)" %} + +{% extends "includes/app-layout.njk" %} + +{% block breadcrumb %} + {% include "solution-architecture-framework/_breadcrumb.njk" %} +{% endblock %} + +{% block bodyContent %} + + + + +{% endblock %} diff --git a/app/views/solution-architecture-framework/requirements/dm/dm03.njk b/app/views/solution-architecture-framework/requirements/dm/dm03.njk new file mode 100644 index 000000000..ab3d5ac0a --- /dev/null +++ b/app/views/solution-architecture-framework/requirements/dm/dm03.njk @@ -0,0 +1,20 @@ +{% set pageTitle = "DM03 - Risk and Issues" %} +{% set pageSection = "Standards and technology" %} +{% set subSection = "Solution Architecture Framework - Requirements - Decision Making & Governance" %} +{% set pageDescription = "" %} +{% set beta = true %} +{% set hideContact = "false" %} +{% set dateUpdated = "07 August 2026 (SAF Version 1.1)" %} + +{% extends "includes/app-layout.njk" %} + +{% block breadcrumb %} + {% include "solution-architecture-framework/_breadcrumb.njk" %} +{% endblock %} + +{% block bodyContent %} + + + + +{% endblock %} diff --git a/app/views/solution-architecture-framework/requirements/dm/dm04.njk b/app/views/solution-architecture-framework/requirements/dm/dm04.njk new file mode 100644 index 000000000..afd98123c --- /dev/null +++ b/app/views/solution-architecture-framework/requirements/dm/dm04.njk @@ -0,0 +1,20 @@ +{% set pageTitle = "DM04 - Stakeholder Involvement" %} +{% set pageSection = "Standards and technology" %} +{% set subSection = "Solution Architecture Framework - Requirements - Decision Making & Governance" %} +{% set pageDescription = "" %} +{% set beta = true %} +{% set hideContact = "false" %} +{% set dateUpdated = "07 August 2026 (SAF Version 1.1)" %} + +{% extends "includes/app-layout.njk" %} + +{% block breadcrumb %} + {% include "solution-architecture-framework/_breadcrumb.njk" %} +{% endblock %} + +{% block bodyContent %} + + + + +{% endblock %} diff --git a/app/views/solution-architecture-framework/requirements/dm/dm05.njk b/app/views/solution-architecture-framework/requirements/dm/dm05.njk new file mode 100644 index 000000000..ce8fa7408 --- /dev/null +++ b/app/views/solution-architecture-framework/requirements/dm/dm05.njk @@ -0,0 +1,20 @@ +{% set pageTitle = "DM05 - Governance Process" %} +{% set pageSection = "Standards and technology" %} +{% set subSection = "Solution Architecture Framework - Requirements - Decision Making & Governance" %} +{% set pageDescription = "" %} +{% set beta = true %} +{% set hideContact = "false" %} +{% set dateUpdated = "07 August 2026 (SAF Version 1.1)" %} + +{% extends "includes/app-layout.njk" %} + +{% block breadcrumb %} + {% include "solution-architecture-framework/_breadcrumb.njk" %} +{% endblock %} + +{% block bodyContent %} + + + + +{% endblock %} diff --git a/app/views/solution-architecture-framework/requirements/dm/dm06.njk b/app/views/solution-architecture-framework/requirements/dm/dm06.njk new file mode 100644 index 000000000..41f66b5fc --- /dev/null +++ b/app/views/solution-architecture-framework/requirements/dm/dm06.njk @@ -0,0 +1,20 @@ +{% set pageTitle = "DM06 - Governance Approach" %} +{% set pageSection = "Standards and technology" %} +{% set subSection = "Solution Architecture Framework - Requirements - Decision Making & Governance" %} +{% set pageDescription = "" %} +{% set beta = true %} +{% set hideContact = "false" %} +{% set dateUpdated = "07 August 2026 (SAF Version 1.1)" %} + +{% extends "includes/app-layout.njk" %} + +{% block breadcrumb %} + {% include "solution-architecture-framework/_breadcrumb.njk" %} +{% endblock %} + +{% block bodyContent %} + + + + +{% endblock %} diff --git a/app/views/solution-architecture-framework/requirements/dm/dm07.njk b/app/views/solution-architecture-framework/requirements/dm/dm07.njk new file mode 100644 index 000000000..5191075ad --- /dev/null +++ b/app/views/solution-architecture-framework/requirements/dm/dm07.njk @@ -0,0 +1,20 @@ +{% set pageTitle = "DM07 - Decision Records" %} +{% set pageSection = "Standards and technology" %} +{% set subSection = "Solution Architecture Framework - Requirements - Decision Making & Governance" %} +{% set pageDescription = "" %} +{% set beta = true %} +{% set hideContact = "false" %} +{% set dateUpdated = "07 August 2026 (SAF Version 1.1)" %} + +{% extends "includes/app-layout.njk" %} + +{% block breadcrumb %} + {% include "solution-architecture-framework/_breadcrumb.njk" %} +{% endblock %} + +{% block bodyContent %} + + + + +{% endblock %} diff --git a/app/views/solution-architecture-framework/requirements/dm/dm08.njk b/app/views/solution-architecture-framework/requirements/dm/dm08.njk new file mode 100644 index 000000000..562d5078d --- /dev/null +++ b/app/views/solution-architecture-framework/requirements/dm/dm08.njk @@ -0,0 +1,20 @@ +{% set pageTitle = "DM08 - Decision Making" %} +{% set pageSection = "Standards and technology" %} +{% set subSection = "Solution Architecture Framework - Requirements - Decision Making & Governance" %} +{% set pageDescription = "" %} +{% set beta = true %} +{% set hideContact = "false" %} +{% set dateUpdated = "07 August 2026 (SAF Version 1.1)" %} + +{% extends "includes/app-layout.njk" %} + +{% block breadcrumb %} + {% include "solution-architecture-framework/_breadcrumb.njk" %} +{% endblock %} + +{% block bodyContent %} + + + + +{% endblock %} diff --git a/app/views/solution-architecture-framework/requirements/nf/nf01.njk b/app/views/solution-architecture-framework/requirements/nf/nf01.njk new file mode 100644 index 000000000..000c26602 --- /dev/null +++ b/app/views/solution-architecture-framework/requirements/nf/nf01.njk @@ -0,0 +1,158 @@ +{% set pageTitle = "NF01 - Observability" %} +{% set pageSection = "Standards and technology" %} +{% set subSection = "Solution Architecture Framework - Requirements - Non-Functional Profile" %} +{% set pageDescription = "" %} +{% set beta = true %} +{% set hideContact = "false" %} +{% set dateUpdated = "07 August 2026 (SAF Version 1.1)" %} + +{% extends "includes/app-layout.njk" %} + +{% block breadcrumb %} + {% include "solution-architecture-framework/_breadcrumb.njk" %} +{% endblock %} + +{% block bodyContent %} + +++ +NF01 Solutions should incorporate workload observability and understand service health.
+
+This requirement is about ensuring that the solution can be monitored effectively and that teams understand how the service is performing. +
+ ++The solution should provide sufficient observability to understand service health, identify issues, investigate incidents and support operational decision-making. Observability should cover the workload being delivered, rather than relying solely on infrastructure metrics. +
+ +
+In simple terms:
+Teams should be able to see what the service is doing, understand whether it is healthy, and quickly identify and investigate problems.
+
| Score | +What it looks like | +Typical evidence | +Key gaps / risks | +
|---|---|---|---|
| 0 | +No evidence that workload observability exists. Service health is not measured or understood. | +No monitoring tools, dashboards, health metrics, telemetry or alerting. | +Significant risk that service failures, performance degradation or outages will not be detected promptly. | +
| 1 | +Limited evidence of monitoring. Monitoring is largely focused on infrastructure or ad-hoc checks. | +Basic infrastructure monitoring, manual operational checks, supplier assurances without supporting evidence. | +High-risk gaps. Limited visibility of user experience, application behaviour or operational performance. | +
| 2 | +Some elements of observability are implemented. Monitoring exists for parts of the solution but coverage is incomplete. | +Application logs, basic dashboards, limited alerting, selected service health indicators or partial telemetry. | +Significant notable gaps in monitoring coverage, alerting quality, ownership or operational processes. | +
| 3 | +Much of the requirement is met. Key workload and service health indicators are monitored and operational teams can investigate most incidents. | +Application monitoring, dashboards, health checks, structured alerting, logging platforms, operational runbooks and incident investigation evidence. | +Notable gaps remain in end-to-end visibility, dependency monitoring, business-level metrics or operational maturity. Mitigating actions are required. | +
| 4 | +Most of the requirement is met with good levels of evidence. Service health is actively monitored through defined indicators with clear operational ownership. | +Maintained dashboards, service-level indicators (SLIs), alert thresholds, operational reviews, monitoring standards, trend reporting and ownership documentation. | +Minor gaps only. Remaining risks are documented, understood and actively managed. | +
| 5 | +Comprehensive evidence that observability is mature, proactive and embedded within operational management. Monitoring capability exceeds normal expectations. | +End-to-end observability strategy, workload telemetry, proactive alerting, business and technical health indicators, post-incident learning, trend analysis and continuous improvement activities. | +Minimal gaps. Monitoring capability is routinely reviewed and drives service and architectural improvements. | +
+A score of 3 generally means the service is observable and operational teams can investigate issues, but there are notable gaps in coverage, ownership, dependency monitoring or monitoring maturity. +
+ ++A score of 4 requires evidence that monitoring is actively maintained, governed and regularly reviewed. Service health indicators are defined, ownership is clear and observability is embedded in operational processes. +
+ ++A score of 5 requires evidence that observability is used proactively rather than reactively. Monitoring informs operational improvement, incident reduction, capacity planning and architectural decision-making. Coverage is comprehensive across technical, operational and business perspectives. +
+ + ++Suggested examples of evidence (not SAF-mandated artefacts): +
+ +++ ++NF02 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). +
+
+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.
+
| 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. | +
+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): +
+ +++ ++NF03 An overall volume and performance model should exist and includes business-realistic exceptional scenarios. +
+
+This requirement is about understanding how much demand a solution must handle and whether +the architecture can meet expected performance levels under both normal and exceptional conditions. +
+ ++A documented volume and performance model should describe expected users, transactions, +data volumes, growth assumptions and workload patterns. The model should also consider +realistic exceptional scenarios such as seasonal peaks, major operational events, +service incidents or unexpected demand spikes. +
+ +
+In simple terms:
+The team understands how much load the service must handle today and in the future, and has evidence that the solution can perform under realistic operating conditions.
+
| Score | +What it looks like | +Typical evidence | +Key gaps / risks | +
|---|---|---|---|
| 0 | +No evidence that volume or performance requirements have been considered. Expected service demand is unknown. | +No volume model, performance requirements, sizing assumptions or capacity planning artefacts. | +Significant service risk. The solution may fail to meet user demand, suffer performance degradation or experience service outages under load. | +
| 1 | +Limited evidence that volumes and performance have been considered. Assumptions are informal, undocumented or based on estimates without validation. | +Informal discussions, supplier estimates, undocumented assumptions or basic capacity figures. | +High-risk gaps. Demand assumptions may be inaccurate and performance risks are poorly understood. | +
| 2 | +Some elements of a volume and performance model exist. Normal operating conditions may be documented but exceptional scenarios are incomplete or absent. | +Partial workload analysis, user estimates, basic performance requirements, limited capacity planning or historical usage data. | +Significant notable gaps in demand forecasting, growth assumptions, exceptional scenario modelling or architectural validation. | +
| 3 | +Much of the requirement is met. A documented volume and performance model exists and includes key business scenarios. | +Performance requirements, transaction forecasts, growth projections, workload models, architecture design assumptions and evidence of performance testing. | +Notable gaps remain in scenario coverage, forecasting confidence, dependency analysis or validation against real-world usage patterns. Mitigating action is required. | +
| 4 | +Most of the requirement is met with good levels of evidence. The model is maintained, reviewed and includes realistic exceptional scenarios and future growth assumptions. | +Approved performance model, capacity planning documentation, scenario analysis, performance test results, architecture reviews and documented assumptions. | +Minor gaps only. Remaining performance risks are understood, documented and actively managed. | +
| 5 | +Comprehensive evidence that the requirement is met and exceeds expectations in several areas. Volume and performance modelling is actively used to inform architecture, operational planning and investment decisions. | +Mature forecasting models, capacity management processes, multiple exceptional scenario assessments, trend analysis, performance engineering practices, periodic review cycles and evidence of continuous improvement. | +Minimal gaps. Performance risks are proactively identified, monitored and addressed before affecting service delivery. | +
+A score of 3 generally means that a credible volume and performance model exists and supports most architectural decisions, but there are notable gaps in forecast quality, exceptional scenario coverage, testing evidence or maintenance. +
+ ++A score of 4 requires evidence that the model is actively maintained, reviewed and used to support capacity planning and architecture decisions. Exceptional business scenarios should be explicitly considered and supported by evidence. +
+ ++A score of 5 requires evidence that volume and performance modelling is embedded within delivery and operational processes. Forecasts are regularly reviewed, validated against operational data and used proactively to identify and mitigate future performance risks. +
+ ++Suggested examples of evidence (not SAF-mandated artefacts): +
+ +++ +NF04 Methods to measure sustainability to establish baseline and show improvement should be defined.
+
+This requirement is about understanding the environmental sustainability impact of a solution and ensuring that improvements can be measured over time. +
+ ++The solution should have defined methods for measuring sustainability performance. A baseline should be established so that future improvements can be demonstrated. The approach should be proportionate to the nature of the service and aligned to organisational sustainability objectives where applicable. +
+ +
+In simple terms:
+The team understands how sustainable the solution is today and has a defined way to measure and demonstrate improvement over time.
+
| Score | +What it looks like | +Typical evidence | +Key gaps / risks | +
|---|---|---|---|
| 0 | +No evidence that sustainability has been considered or measured. | +No sustainability objectives, measurements, baseline data or assessment artefacts. | +Significant risk that sustainability impacts are unknown and opportunities for improvement cannot be identified. | +
| 1 | +Limited evidence that sustainability has been discussed, but no structured measurement approach exists. | +Informal discussions, undocumented assumptions or high-level statements regarding sustainability. | +High-risk gaps. No measurable baseline exists and improvement claims cannot be evidenced. | +
| 2 | +Some elements of sustainability measurement have been identified, but the approach is incomplete or inconsistently applied. | +Partial assessments, limited metrics, supplier sustainability information or draft sustainability objectives. | +Significant notable gaps in measurement scope, baseline data, governance or ongoing monitoring. | +
| 3 | +Much of the requirement is met. Sustainability measures have been identified and a baseline has been established for key areas. | +Sustainability assessments, documented baseline metrics, architectural decisions considering sustainability factors, and periodic reporting. | +Notable gaps remain in coverage, data quality, target setting or evidence of sustained improvement. Mitigating action is required. | +
| 4 | +Most of the requirement is met with good levels of evidence. Sustainability metrics are maintained, reviewed and used to inform decision-making. | +Approved sustainability measures, maintained baselines, improvement targets, governance review records and periodic reporting against objectives. | +Minor gaps only. Remaining sustainability risks and assumptions are understood and actively managed. | +
| 5 | +Comprehensive evidence that the requirement is met and exceeds expectations in several areas. Sustainability measurement is embedded within architecture, delivery and operational processes. | +Mature sustainability framework, established metrics and trends, continuous improvement initiatives, governance oversight and evidence that sustainability data influences strategic and architectural decisions. | +Minimal gaps. Sustainability performance is actively monitored, reported and improved. | +
+A score of 3 generally means that sustainability measurements exist and a baseline has been established, but there are notable gaps in governance, reporting, target setting or evidence of improvement. +
+ ++A score of 4 requires evidence that sustainability metrics are maintained, reviewed and actively used when making architecture or operational decisions. Improvement activities should be measurable and supported by governance. +
+ ++A score of 5 requires evidence that sustainability measurement is embedded within normal delivery and operational practices. Trends are monitored over time, improvements are demonstrable and sustainability data is routinely used to influence planning and decision-making. +
+ ++Suggested examples of evidence (not SAF-mandated artefacts): +
+ +++ +NF05 Audit & logging requirements should be defined, and the solution can support them.
+ +NCSC Logging and Protective Monitoring
+NCSC Principle 13: Audit information and alerting for customers
+
+This requirement is about ensuring that the solution generates, retains and makes available the audit and logging information needed to support operational management, security monitoring, incident investigation, compliance and governance activities. +
+ ++The service should have clearly defined audit and logging requirements. The architecture should demonstrate how logs and audit records are generated, protected, retained, accessed and used. Logging arrangements should be proportionate to the sensitivity, criticality and risk profile of the service. +
+ +
+In simple terms:
+The organisation knows what needs to be logged, why it needs to be logged, and can demonstrate that the solution captures and manages audit information effectively.
+
| Score | +What it looks like | +Typical evidence | +Key gaps / risks | +
|---|---|---|---|
| 0 | +No evidence that audit or logging requirements have been defined. The solution provides little or no ability to investigate operational or security events. | +No logging standards, audit requirements, monitoring design, retention policies or operational procedures. | +Significant service risk. Security incidents, operational failures and compliance issues may not be detectable or investigable. | +
| 1 | +Limited evidence that audit and logging have been considered. Logging is inconsistent, incomplete or largely dependent on default platform capabilities. | +Informal requirements, limited system logs, undocumented assumptions, supplier assertions or isolated logging implementations. | +High-risk gaps. Important events may not be recorded and audit coverage is insufficient to support investigations. | +
| 2 | +Some audit and logging requirements have been identified and partially implemented. Coverage exists for selected components but is incomplete. | +Partial logging standards, basic audit trails, limited retention policies, selected monitoring dashboards or security logging capabilities. | +Significant notable gaps in event coverage, retention arrangements, governance, access controls or operational use of logs. | +
| 3 | +Much of the requirement is met with an acceptable level of evidence. Key audit and logging requirements are defined and implemented across most critical service components. | +Documented logging requirements, security and operational logs, audit trail specifications, retention policies, monitoring arrangements and incident investigation processes. | +Notable gaps remain in coverage, consistency, governance, retention management, log protection or integration with monitoring processes. Mitigating action is required. | +
| 4 | +Most of the requirement is met with good levels of evidence. Audit and logging requirements are maintained, governed and aligned to operational and security needs. | +Approved logging standards, documented event catalogues, retention schedules, access controls, monitoring integration, governance reviews and evidence of regular use during operational and security activities. | +Minor gaps only. Remaining risks are known, documented and actively managed. | +
| 5 | +Comprehensive evidence that the requirement is met and exceeds expectations in several areas. Audit and logging capabilities are mature, consistently applied and actively support operational improvement, security monitoring and compliance activities. | +Enterprise-aligned logging strategy, centralised logging, automated analysis, defined audit controls, continuous review processes, monitoring integration and evidence that audit data informs operational and security decision-making. | +Minimal gaps. Logging and audit capabilities are routinely reviewed, validated and continuously improved. | +
+A score of 3 generally means that audit and logging requirements have been documented and largely implemented, but there are notable weaknesses such as inconsistent coverage, gaps in retention arrangements, unclear ownership or limited evidence that logs are actively used. +
+ ++A score of 4 requires evidence that logging and audit controls are governed, maintained and routinely used by operational and security teams. Coverage should be largely complete, with only minor gaps remaining. +
+ ++A score of 5 requires evidence that audit and logging capabilities are embedded within operational practice. Logging data is actively analysed, supports continuous improvement and is consistently used to strengthen service reliability, security and compliance. +
+ ++Suggested examples of evidence (not SAF-mandated artefacts): +
+ +++ +NF06 Disaster Recovery & Business Continuity. There should be clear requirements (commensurate with service levels) around DR & BC (and a pragmatic approach taken with regards DR/BC events planned for). Continuity plans and supporting documentation should reflect the requirements, technical & architecture constraints etc.
+
+This requirement is about ensuring the service can continue operating, or be recovered, +following a significant disruption. +
+ ++The solution should have clearly defined Disaster Recovery (DR) and Business Continuity (BC) +requirements that are appropriate for the service criticality and agreed service levels. +Recovery arrangements should be documented, understood, achievable and aligned to the +actual architecture. +
+ +
+In simple terms:
+The organisation knows how the service will continue or recover during major incidents, and there is evidence that the plans are realistic and aligned to the solution design.
+
| Score | +What it looks like | +Typical evidence | +Key gaps / risks | +
|---|---|---|---|
| 0 | +No evidence that DR or BC requirements have been defined. No documented recovery approach exists. | +No continuity plans, recovery procedures, architecture recovery documentation or ownership. | +Significant risk of prolonged outage, failure to recover critical services and unmanaged operational impact. | +
| 1 | +Limited evidence that DR and BC have been considered. Recovery arrangements are largely informal or based on assumptions. | +Draft notes, informal discussions, supplier statements or undocumented recovery expectations. | +High-risk gaps. Recovery responsibilities, dependencies and recovery methods are unclear. | +
| 2 | +Some elements of the DR and BC requirement are met. Recovery arrangements exist for parts of the solution but coverage is incomplete. | +Partial continuity plans, infrastructure recovery documentation, some dependency analysis or supplier commitments. | +Significant notable gaps in scope, testing, ownership, documentation or recovery coverage. | +
| 3 | +Much of the requirement is met. Recovery requirements are documented and linked to the solution architecture. Key recovery processes have been identified. | +DR strategy, continuity plans, operational runbooks, dependency mapping, architecture documentation and evidence of limited testing or tabletop exercises. | +Notable gaps remain in coverage, validation, documentation currency or supplier recovery arrangements. Mitigating action is required. | +
| 4 | +Most of the requirement is met with good levels of evidence. Recovery expectations, responsibilities and processes are documented, maintained and periodically reviewed. | +Approved DR and BC plans, recovery objectives, governance reviews, test reports, maintained recovery procedures and dependency analysis. | +Minor gaps only. Residual risks are documented, understood and actively managed. | +
| 5 | +Comprehensive evidence that the requirement is met and exceeds expectations in several areas. DR and BC capability is mature, governed and continuously improved. | +Regular recovery exercises, defined improvement actions, operational playbooks, supplier assurance evidence, governance reporting and measurable recovery outcomes. | +Minimal gaps. Recovery capability is routinely validated and refined through lessons learned. | +
+A score of 3 normally indicates that documented recovery arrangements exist and +there is a credible recovery approach. However, there are still notable weaknesses such as +untested plans, incomplete dependency analysis, outdated documentation or gaps in service coverage. +
+ ++A score of 4 requires evidence that plans are actively maintained, reviewed and tested, +and that recovery arrangements reflect the architecture and operating model. +
+ ++A score of 5 requires evidence that Disaster Recovery and Business Continuity are embedded +within operational governance. Recovery exercises are performed regularly, lessons learned drive +improvements, supplier assurance is in place and there is strong evidence that recovery objectives +can be achieved under realistic scenarios. +
+ ++Suggested evidence examples (not SAF-mandated artefacts): +
+