Requirements - Solution Design & Methods - SD11 - Policy Adherence

Solutions should adhere to the policies below.

Requirement

SD11: Solutions should adhere to:

  1. Government "Secure by Design" policy
  2. NCSC CAF
  3. Access Control Guidelines
  4. Policy - Strong Auth/MFA
  5. Storage and Processing of Data Outside of the UK - Information Governance Policy
  6. NHS England's API strategy and policy statements. E.g. API Landscape policy document (Word, Aalto.digital.nhs.uk)

(Note there are overlaps with the Engineering red lines; ensure a consistent response and do not repeat assessments)

Requirement description

This requirement is concerned with designing solutions that comply with key security, identity, access management, data protection and API governance requirements.

The focus is not simply whether security controls exist. Assessors should consider whether the solution design demonstrates alignment with recognised policies and frameworks and whether this alignment is evidenced, reviewed and maintained.

In simple terms:
The solution should demonstrate that security, identity, access management, data protection and API governance requirements have been considered and built into the architecture.

Scoring rubric table – Security, Identity and API Policy Compliance

Score What it looks like Typical evidence Key gaps / risks
0 No evidence that relevant security, identity, access control, data protection or API policy requirements have been considered. No security architecture artefacts, no compliance assessments, no documented controls or policy mappings. Significant service risk. Security, privacy, regulatory and operational risks are unmanaged.
1 Limited evidence that the requirements have been considered. Controls are largely informal or implemented without documented architectural justification. Isolated security controls, informal design discussions, unsupported compliance claims. High-risk gaps. Key policies may not be understood and compliance cannot be demonstrated.
2 Some relevant controls and design decisions are documented. Elements of the referenced policies and frameworks have been addressed. Partial threat assessments, architecture diagrams, security requirements, policy references within design documentation. Significant notable gaps remain. Coverage is incomplete, inconsistent or not evidenced across the solution.
3 Much of the requirement is met. The solution demonstrates alignment with most applicable policies and frameworks and there is acceptable supporting evidence. Security architecture documentation, access control design, authentication approach, API governance artefacts, compliance reviews, design authority discussions. Notable gaps remain. Some controls, policy mappings or assurance activities are incomplete and require mitigating action.
4 Most applicable requirements have been addressed and can be demonstrated through maintained architecture and assurance evidence. Compliance activities are actively governed. Policy compliance assessments, security design reviews, documented access control model, MFA implementation approach, API governance evidence, architecture governance approvals. Minor gaps only. Residual risks are understood, documented and actively managed.
5 Comprehensive and exemplar evidence that the solution aligns with applicable security, identity, access management, data protection and API governance requirements. Compliance is continuously maintained and demonstrably influences architecture decisions. Maintained compliance mappings, governance records, security assurance evidence, design reviews, exception management records, continuous improvement activity, measurable security and compliance outcomes. Minimal or no significant gaps identified.

What assessors should look for

  1. Secure by Design principles – Evidence that security requirements have been incorporated into architectural decisions from the outset.
  2. Cyber assurance alignment – Evidence that relevant security risks, controls and assurance activities have been identified and documented.
  3. Identity and access management – Evidence that authentication, authorisation and access controls are appropriate for the service.
  4. Strong authentication – Evidence that authentication approaches align with applicable MFA and identity policies.
  5. Data location and information governance – Evidence that data storage and processing considerations are understood and documented where applicable.
  6. API governance – Evidence that API-related policy requirements have been considered within the solution design.
  7. Governance and assurance – Evidence that compliance is reviewed, maintained and managed through appropriate governance processes.

What separates a 3 from a 4 or 5

A score of 3 normally demonstrates that security, identity, access management and API governance requirements have been considered and that acceptable evidence exists for most areas. However, there are still notable gaps, incomplete assurance activities or missing compliance evidence that require mitigation.

A score of 4 requires a stronger level of assurance. Relevant policies are demonstrably addressed, documentation is maintained, governance reviews have occurred and residual risks are clearly understood.

A score of 5 requires evidence that compliance is embedded within the architecture lifecycle. Controls are actively reviewed, exceptions are managed, evidence is routinely maintained and security and governance considerations demonstrably influence decision-making.

Suggested evidence examples (not SAF-mandated artefacts)

  • Security architecture documentation
  • Threat modelling outputs
  • Cyber risk assessments
  • Identity and access management design documentation
  • Role-based access control models
  • MFA implementation evidence
  • Data residency and information governance assessments
  • API standards compliance reviews
  • Architecture Decision Records (ADRs)
  • Design authority papers and governance approvals

Updated: 04 September 2026 (SAF Version 1.1)