DSPT 9.5.11: Software Security Code of Practice Explained
Short answer: DSPT evidence item 9.5.11 is a new mandatory requirement for Category 2 IT suppliers in 2026-27. It requires that software you supply to health and care organisations is developed in line with the UK government's Software Security Code of Practice, a 14-principle framework for secure software development, co-designed by DSIT and the NCSC. If your development team has never heard of it, this is the year to introduce them.
What the Software Security Code of Practice actually is
The Software Security Code of Practice was published by the Department for Science, Innovation and Technology (DSIT) in May 2025, co-designed with the National Cyber Security Centre (NCSC) and developed through public consultation with industry. On its own, it's voluntary; DSIT built it as a baseline for software vendors generally, supported through an industry "Software Security Ambassadors Scheme" with firms including Cisco, Palo Alto Networks and Santander.
What DSPT 9.5.11 does is take that voluntary code and make it a mandatory evidence item for anyone supplying software to the NHS and care sector. If you sell into health and care, it stops being optional.
The 14 principles
The Code organises its 14 principles across four themes:
Secure design and development: follow an established secure development framework; understand your software's composition and assess risk from third-party components throughout development; run clear testing processes before distribution; apply secure-by-design and secure-by-default principles throughout.
Build environment security: protect build environments from unauthorised access; control and log changes to build infrastructure.
Secure deployment and maintenance: distribute software securely to customers; implement and publish an effective vulnerability disclosure process; proactively detect, prioritise and manage vulnerabilities in your components; report vulnerabilities to relevant parties where appropriate; provide timely security updates, patches and notifications.
Communication with customers: specify the level of support and maintenance you provide; give customers at least one year's notice before software goes out of support; make incident information available to customers where there's a significant impact.
What this means for evidencing 9.5.11
NHS England's evidence text for 9.5.11 requires that software provided to health and care is developed "in accordance with" the Code. In practice, that means being able to show, not just assert, that your development lifecycle maps to these 14 principles. For most development teams, the gaps tend to cluster in a few predictable places:
- Third-party component risk. Do you maintain a software bill of materials (SBOM) or equivalent, and do you actually assess the components you pull in, rather than just tracking them?
- Vulnerability disclosure. Do you have a published, functioning process for someone outside your organisation to report a vulnerability, not just an internal bug tracker?
- End-of-support notice. Can you show customers get at least a year's notice before a product version stops being supported? This is a specific, checkable commitment, not a general policy statement.
- Build environment controls. Is access to your build and CI/CD infrastructure actually restricted and logged, or is this assumed rather than evidenced?
If your team already works to a recognised secure development lifecycle (Microsoft's SDL, OWASP SAMM, or similar), you're likely covering most of this already, the work is in mapping existing practice to the Code's specific language and gathering evidence an auditor can review, not necessarily building new processes from scratch.
How this fits with DSPT 26-27 more broadly
9.5.11 is one of five evidence changes for Category 2 in 2026-27, alongside the new MFA/identity federation requirement (4.5.6), the updated Supply Chain Charter item (9.5.10), the new Products and Services data collection, and two dropped requirements. We've covered the full picture in our DSPT 2026-27 guide for Category 2 IT suppliers.
What to do now
- Share the Code of Practice with your development and engineering leads; this is new ground for DSPT, and most dev teams won't have mapped against it before.
- Run a gap assessment against the 14 principles, prioritising vulnerability disclosure and end-of-support notice, since these are the most concretely checkable in an audit.
- Document how your existing development lifecycle maps to each theme, rather than starting a parallel compliance process.
How Periculo can help
Periculo supports IT suppliers in mapping their development lifecycle against new DSPT evidence requirements like 9.5.11, alongside penetration testing, Cyber Essentials Plus and ISO 27001 certification, and DSPT independent audit.
Get in touch if you want a second opinion on whether your organisation requires an audit.
Related reading: NHS DSPT 2026-27: The Complete Guide for Category 2 IT Suppliers, DSPT 4.5.6: MFA and Identity Federation Explained, DSPT 2026-27: The 12 Mandatory Audit Areas for IT Suppliers, CAF v4 in the DSPT.
FAQs
What is DSPT evidence item 9.5.11?
A new mandatory evidence item for Category 2 IT suppliers in 2026-27, requiring software supplied to health and care to be developed in accordance with the government's Software Security Code of Practice.
What is the Software Security Code of Practice?
A 14-principle secure software development framework published by DSIT in May 2025, co-designed with the NCSC — voluntary generally, but mandatory for NHS/care suppliers via DSPT 9.5.11.
Is the Software Security Code of Practice mandatory?
Not on its own, but DSPT 9.5.11 makes alignment with it mandatory for suppliers to health and care organisations.
What are the four themes of the Code?
Secure design and development, build environment security, secure deployment and maintenance, and communication with customers.
How much notice must suppliers give before software goes out of support?
At least one year, per the Code's communication-with-customers principles.
