The department on this code's cover stopped existing in 2023. The nine pages underneath needed the attention to detail they ask of software vendors.
Estimated reading time: 6 minutes
In short. The Software Security Code of Practice (May 2025) is a voluntary code asking software vendors to meet 14 security principles, co-designed with the NCSC and genuinely maintained since launch. It is also a document whose cover names a department that ceased to exist in February 2023, whose scope table numbers its principles in a way the code itself does not use, and which cites the EU's Cyber Resilience Act through a commercial training website rather than the law. Eight documented mistakes in nine pages: three stars. The doctrine is better than the drafting.
Escalated from the Daily Register under the site's criteria: a first-of-kind framework with no enforcement clause, in a sector measured in billions. This is a Tier 2 structured teardown: claims tested against the sources they rest on, mistakes counted, arithmetic shown.
The code itself is short. Published 7 May 2025, it sets out 14 principles across four themes (secure design and development, build environment security, secure deployment and maintenance, communication with customers) that vendors selling software to businesses are "expected to implement" [2]. It was co-designed with the NCSC, refined through a 2024 call for views, and has been updated twice since launch: a monitoring survey in November 2025 and, in January 2026, a Software Security Ambassadors Scheme with firms including Cisco, Palo Alto Networks, Sage, Santander and NCC Group championing the code across industry [1] [11].
The claims, tested
| The code's claim | What we found | Verdict |
|---|---|---|
| Co-designed with NCSC; supported by implementation guidance and an assurance framework | The implementation guidance [7] and the Assurance Principles and Claims [8] are live on the NCSC site, with a downloadable self-assessment template | Holds |
| "14 principles split across 4 themes" | Confirmed: 1.1 to 1.4, 2.1 to 2.2, 3.1 to 3.5, 4.1 to 4.3 [2] | Holds |
| '"shall" represents a requirement of the Code of Practice' | True as written, and the code is voluntary: the glossary borrows the grammar of a standard while the document carries no mechanism to oblige anyone | Holds, and proves the critics' point |
| Complementary to international approaches "including the US SSDF and the EU's Cyber Resilience Act" | The SSDF link goes to NIST. The Cyber Resilience Act link goes to european-cyber-resilience-act.com, a commercial site selling CRA training and certificates [5], not to the regulation itself [6] | Fails on sourcing |
| Resellers are covered by "principles 3 to 4"; in-house developers by "principles 1 and 2... as well as principle 3" | The code contains no principles numbered 1 to 4; those are theme numbers. Whether a reseller owes two principles or eight is not decidable from the text | Fails as written |
| A certification scheme is in development, "shared in due course" | Sixteen months and two page updates later: a survey and an ambassadors scheme, no certification scheme [1] | Still a promise |
The mistakes, counted
The cover (1). The code is attributed to the Department for Science, Innovation and Technology and the Department for Digital, Culture, Media and Sport [2]. The second of those stopped existing in February 2023, when the machinery of government changes that created DSIT stripped Digital from DCMS [3] [4]. This document was first published in May 2025, twenty-seven months after that name went away, and the badge has survived two subsequent updates.
The scope table (2). As above: the sentences that tell each audience which parts of the code apply to them use a numbering scheme ("principles 3 to 4") that does not exist in the code. In the one place where precision decides who does what, the text is ambiguous.
The citation (3). A government code of practice pointing readers at EU law routes them to a commercial training vendor's website rather than the Official Journal. The site sells CRA certificates [5]; the regulation lives at EUR-Lex [6].
The glossary definition that disagrees with itself (4). An incident is defined as "unauthorised access (or attempted access) to an organisation's IT systems", and the same entry then includes "accidental incidents (such as incidents where disruption is caused by vulnerabilities in software or updates)". An accidental disruption involves no access, attempted or otherwise. One of the two halves is wrong.
The stale sentence (5). The skills section still reads "In 2025 the NCSC plans to launch a revised undergraduate degree certification standard". The page was updated on 15 January 2026, by which point 2025 had ended; the future tense survived anyway [2].
The proofreading (6, 7, 8). "Measures that should be reasonably be expected" (a doubled "be", in the sentence defining the code's whole scope). "A software producers practices" (a missing apostrophe, in the glossary entry explaining the assurance method). And principle 4.2 begins "Provides at least 1 year's notice" where every one of the other thirteen principles is an imperative: Follow, Protect, Have, Make. Small, individually; but this is a nine-page document that had a public consultation, two named departments, the NCSC, and two maintenance updates to catch them.
What the code gets right
The count above is not the whole picture, and fairness requires the other column. The 14 principles are concrete and sensible: publish a vulnerability disclosure process, log changes to the build environment, give customers a year's notice before support ends. Every one of the thirteen outbound links we checked resolves, which is more than can be said for most guidance this site reads. The assurance layer is real, not decorative: the NCSC's principles-based assurance approach is wired to a usable self-assessment template [8]. And the document is visibly maintained, with two substantive updates in eight months and named firms publicly attached to it [11]. By the standards of the genre, this is a living document. That is exactly why the surviving errors are worth counting: the maintenance passes happened, and rolled past them.
Verdict
Three stars, from eight documented mistakes in nine pages. The doctrine is largely sound and the follow-through is unusually real; the drafting and sourcing let it down in ways a single careful proofread would have caught. The deeper question is structural and is not scored: a code whose glossary defines "shall" as a requirement, inside a document nothing requires anyone to read, is a standard on the honour system, while the EU it politely gestures at made the same demands law [6]. And the code now has an ownership problem through no fault of its drafters: DSIT, its surviving sponsor, was broken up in the July 2026 reshuffle, with digital functions moving to a reformed DCMS [9] [10]. A document that asks vendors to name a Senior Responsible Owner currently cannot name its own.
The star score counts eight documented mistakes: the defunct department attribution, the principles-versus-themes scope numbering, the commercial-site citation for EU law, the self-contradicting incident definition, the stale 2025 future tense, and three proofreading errors (the doubled "be", the missing apostrophe, the 4.2 verb form). Eight falls in the 4 to 9 band: three stars; the bands are on the ratings page. The July 2026 abolition of DSIT is noted but NOT counted: rebadging after a machinery of government change takes time, and the February 2023 DCMS attribution is counted once, not twice. Analysis is of the HTML edition as fetched on 12 September 2026, reflecting the 15 January 2026 update. The document is tracked in the Daily Register; a revision will get a diff entry.
Sources
- GOV.UK publication page, "Software Security Code of Practice" (update history: 7 May 2025, 28 November 2025, 15 January 2026). https://www.gov.uk/government/publications/software-security-code-of-practice
- "Software Security Code of Practice", HTML edition, updated 15 January 2026 (all quoted text). https://www.gov.uk/government/publications/software-security-code-of-practice/software-security-code-of-practice
- GOV.UK, "PM: Making government deliver for the British people" (February 2023 machinery of government changes creating DSIT). https://www.gov.uk/government/news/making-government-deliver-for-the-british-people
- Inside GOV.UK, "Updating GOV.UK when there is a machinery of government change" (confirms the February 2023 department changes). https://insidegovuk.blog.gov.uk/2023/06/15/updating-gov-uk-when-there-is-a-machinery-of-government-change/
- european-cyber-resilience-act.com, "Cyber Resilience Act (CRA) | Updates, Compliance, Training" (the commercial site the code links for the CRA). https://www.european-cyber-resilience-act.com/
- EUR-Lex, Regulation (EU) 2024/2847 (the Cyber Resilience Act itself). https://eur-lex.europa.eu/eli/reg/2024/2847/oj
- NCSC, "Software Security Code of Practice implementation guidance". https://www.ncsc.gov.uk/collection/software-security-code-of-practice-implementation-guidance
- NCSC, "Software Security Code of Practice: Assurance Principles and Claims". https://www.ncsc.gov.uk/guidance/software-security-code-of-practice-assurance-principles-claims
- GOV.UK organisation page for DSIT (carries the notice that the organisation is being replaced). https://www.gov.uk/government/organisations/department-for-science-innovation-and-technology
- The Register, "UK.gov's tech department gets the chop after two years" (21 July 2026). https://www.theregister.com/public-sector/2026/07/21/ukgovs-tech-department-gets-the-chop-after-two-years/5275573
- GOV.UK, "Cyber sector is target for growth as Government supports businesses against serious organised cyber crime" (January 2026; the Ambassadors Scheme and named firms). https://www.gov.uk/government/news/cyber-sector-is-target-for-growth-as-government-supports-businesses-against-serious-organised-cyber-crime