The Software Security Code of Practice explained
The Software Security Code of Practice is a voluntary UK government code with 14 principles for organisations that develop and sell software. It is not part of the Cyber Security and Resilience Bill (CSRB) and is not a legal duty, but customers can use it in contracts and vendors can self-assess against it.
The Bill is not yet law. Regulation and section references come from the Bill as brought from the Commons (HL Bill 32). The Lords has since amended the Bill, so numbering and detail may change in the final Act. This guide is general information, not legal advice.
What it is
The Software Security Code of Practice is a voluntary UK government code for organisations that develop and sell software. It was first published on 7 May 2025 and the page was last updated on 15 January 2026. The NCSC helped develop it, and the Canadian Centre for Cyber Security co-seals it.
It is not part of the Cyber Security and Resilience Bill (CSRB), and following it is not a legal duty under the Bill.
Who it is for
The Code's primary audience is senior leaders at software vendors, who it says should appoint a Senior Responsible Owner. Technical teams and buyers are also audiences.
| If you are... | The Code says you mainly need... |
|---|---|
| A software developer and distributor | All principles |
| A reseller | Principles 3 and 4 |
| A developer that does not sell software | Principles 1 and 2 |
| A buyer | Use it in negotiations and contracts |
Open-source developers and maintainers are not its primary audience.
The 14 principles
1. Secure design and development
- 1.1 Follow an established secure development framework.
- 1.2 Understand the software's components, and assess risks from third-party components.
- 1.3 Have a clear process for testing software and updates before distribution.
- 1.4 Follow secure by design and secure by default principles.
2. Build environment security
- 2.1 Protect the build environment against unauthorised access.
- 2.2 Control and log changes to the build environment.
3. Secure deployment and maintenance
- 3.1 Distribute software securely to customers.
- 3.2 Implement and publish an effective vulnerability disclosure process.
- 3.3 Detect, prioritise and manage vulnerabilities in software components.
- 3.4 Report vulnerabilities to relevant parties where appropriate.
- 3.5 Provide timely security updates, patches and notifications to customers.
4. Communication with customers
- 4.1 Tell customers what level of support and maintenance is provided.
- 4.2 Give at least one year's notice before ending support or maintenance.
- 4.3 Make information available about notable incidents that may significantly affect customers.
These summaries are shortened. Use the full Code for the exact wording.
"Code of practice" can mean three things here
| Document | What it is | Who it is aimed at |
|---|---|---|
| Software Security Code of Practice | Voluntary code, already published | Software vendors and buyers |
| Cyber Governance Code of Practice | Voluntary code for board-level cyber governance | Boards and directors. See our guide |
| Code under section 36 of the Bill | A possible future code describing recommended measures for regulated persons | Regulated persons |
A section 36 code would be issued by the Secretary of State, with Parliamentary procedure. It does not exist yet. Don't assume that it will copy the Software Security Code.
How it relates to the Bill
The Bill does not, in the print we reviewed, make the Software Security Code mandatory. Some commentary suggests it could become a practical baseline for software suppliers. That is a prediction, not a legal requirement.
It may still matter to software companies in practice:
- Large SaaS or cloud firms could be relevant digital service providers, with their own legal duties. See large SaaS and enterprise software.
- Suppliers to regulated organisations may get asked for evidence of secure development.
- Designated critical suppliers would have legal duties, and following the Code could help show good practice, though it would not itself prove compliance.
How to check your position
The Government provides a self-assessment form. You can use it for an internal check or to share with customers as evidence. It follows the NCSC's Principles Based Assurance approach. The Government has also said it is developing a certification scheme, with details to follow.
A practical first pass:
- Appoint a Senior Responsible Owner.
- Work out your role for each product: developer, distributor or reseller.
- Look at the quick checks first. Do you have a published vulnerability disclosure route? Do customers know your support periods?
- Check build security. Who can change your pipeline, and is every change logged?
- Decide how you'll handle third-party components. Can you list them and act quickly when one is vulnerable?
- Write your customer incident process, so that principle 4.3 is not being invented during an incident.
- Complete the self-assessment, and record evidence and gaps.
Using it as a buyer
You can ask suppliers whether they have self-assessed against the Code and, if so, for the result. Good follow-up questions include:
- How much notice do you give before ending support?
- How do you tell customers about vulnerabilities and notable incidents?
- How do you protect your build environment?
If a supplier's product is important to your service, consider writing these commitments into the contract.
Sources
Frequently asked questions
No. It describes itself as voluntary. Customers can still make it a contract requirement.
There are 14, across four themes: secure design and development, build environment security, secure deployment and maintenance, and communication with customers.
No. Section 36 of the Bill is a separate power to issue a code for regulated persons. That code does not yet exist.
The Government provides a self-assessment form and has said it is developing a certification scheme, with details to follow.