Requirements - Solution Design & Methods - SD01 - Design Methodology

An appropriate design methodology should be followed e.g. Domain Driven Design and should include NHS/CDDO Service Design and Secure by Design principles and methods.

Requirement description

This requirement is concerned with ensuring that solution design follows recognised and appropriate design methods rather than being developed in an ad hoc manner.

The selected design methodology should be suitable for the type of service being delivered and should incorporate service design, user-centred design and security considerations from the outset. The SAF specifically references approaches such as Domain Driven Design and requires consideration of NHS/CDDO Service Design and Secure by Design principles.

The objective is to ensure that solutions are designed systematically, with a clear understanding of user needs, business domains, operational requirements and security considerations.

In simple terms:
Use recognised design methods and ensure service design and security are built into the solution from the beginning.

Scoring rubric table – SD01 Design Methodology and Design Principles

Score What it looks like Typical evidence Key gaps / risks
0 No evidence that a design methodology has been followed. Solution design appears ad hoc or driven solely by implementation considerations. No design approach defined.
No service design evidence.
No security-by-design evidence.
No documented design activities.
Significant service risk. The solution may fail to meet user needs, business objectives or security requirements.
1 Limited evidence of structured design activity. Some design discussions may have taken place, but recognised methodologies are not consistently applied. Informal workshops.
Undocumented solution discussions.
Limited service design activity.
Minimal security consideration.
High-risk gaps. Design decisions may not be evidence-based and security or usability requirements may be overlooked.
2 Some elements of an appropriate design methodology have been applied, but adoption is incomplete or inconsistent. Partial service design outputs.
Some design artefacts.
Limited domain modelling.
Basic security assessments.
Evidence of some structured design activities.
Significant notable gaps. User needs, domain understanding or security considerations may not be fully reflected in the design.
3 Much of the solution design follows a recognised methodology. Service design and security considerations are visible within the design process. Design methodology documentation.
User research outputs.
Service design artefacts.
Domain models.
Architecture design workshops.
Security requirements captured during design.
Notable gaps remain. Some design decisions may lack traceability to user needs, domain models or security principles.
4 Most design activities follow a defined and appropriate methodology. Service design and Secure by Design practices are integrated into solution development. Documented design approach.
Comprehensive service design artefacts.
Domain-driven design outputs where appropriate.
Threat modelling or security design activities.
Traceability between user needs and solution design.
Governance review of design outputs.
Minor gaps only. Remaining issues are understood and unlikely to materially affect design quality.
5 Comprehensive and exemplar application of design methodologies. Service design, domain modelling and security practices are embedded throughout the solution lifecycle. Mature and well-documented design approach.
Strong integration of service design and architecture activities.
Comprehensive domain models.
Security-by-design embedded throughout delivery.
Evidence of iterative improvement based on user feedback.
Design decisions consistently informed by structured methods.
Minimal or no significant gaps. The design process is repeatable, evidence-based and continuously improved.

What assessors should look for

  1. Design methodology – Has an appropriate and recognised design methodology been adopted?
  2. Service design integration – Is there evidence that user needs and service design activities have informed the solution?
  3. Secure by Design – Have security requirements and design principles been considered from the outset?
  4. Domain understanding – Where appropriate, has the business domain been modelled and understood through structured techniques?
  5. Traceability – Can key design decisions be linked to user needs, business requirements or design activities?
  6. Consistency – Is the methodology applied consistently throughout the design process?

What separates a 3 from a 4 or 5

A score of 3 generally indicates that recognised design practices have been adopted and there is evidence of service design and security consideration, but application is inconsistent or incomplete.

A score of 4 requires a clearly defined and consistently applied design methodology, with good evidence that service design and Secure by Design principles are influencing architecture decisions.

A score of 5 requires design methodology, service design and security practices to be embedded throughout the lifecycle. Evidence should demonstrate mature, repeatable and well-governed design practices that actively improve solution outcomes.

Updated: 04 September 2026 (SAF Version 1.1)