If you sell software to other businesses in the UK, there is now a government baseline for how that software should be built and looked after. The Software Security Code of Practice, published by the Department for Science, Innovation and Technology and the National Cyber Security Centre, sets out 14 principles that software vendors are expected to follow. It is voluntary. It is also written with buyers in mind, and that is the part a small SaaS company should pay attention to.
This post explains what the Code asks for, who it applies to, how you show you meet it, and where an application security review fits in and where it does not.
Who it applies to
The Code is aimed at any organisation that develops and sells software to businesses, and it names Software as a Service providers explicitly. If you build the product and sell it, you are what the Code calls a "software developer and distributor", and you are expected to follow all 14 principles. The government describes them as measures that should be reasonably expected from organisations of any size, so being a team of five does not take you out of scope.
The Code is addressed to senior leaders rather than engineers. It asks each vendor to name a Senior Responsible Owner at leadership level who is accountable for the principles being followed. In a small company that is usually a founder or the CTO.
What the 14 principles cover
The principles sit in four themes. In plain terms:
- Secure design and development. Follow an established secure development approach, know what third-party components are in your software and the risks they carry, have a clear process for checking software and updates before release, and build secure by design and secure by default.
- Build environment security. Protect the systems that build and package your software from unauthorised access, and control and log changes to them.
- Secure deployment and maintenance. Distribute software securely, publish a way for people to report vulnerabilities to you, have processes for finding, prioritising and managing vulnerabilities, report them where appropriate, and ship timely security updates.
- Communication with customers. Tell customers what support and maintenance they get, give at least a year's notice before support ends, and share information about notable incidents that could affect them.
The NCSC publishes implementation guidance for the technical teams doing the work, and it is worth reading alongside the Code itself.
Why buyers come into it
The Code says plainly that organisations buying software can use it to inform negotiations with suppliers and to shape their contracts. The government's Software Security Ambassadors Scheme goes further: the software buyers who sign up commit to building the Code into their procurement and supplier management, and the software suppliers who sign up commit to publishing a self-assessment or a third-party verification.
We cannot tell you how many of your own prospects will ask about it, and nobody else honestly can yet either. What we can say is that it gives larger buyers a ready-made, government-backed list of questions to put to smaller suppliers, and it costs nothing to be ready for them.
How you show you meet it
There is no certificate to buy today. The government provides a free self-assessment form, built on the NCSC's Principles Based Assurance approach, which breaks each principle into claims you support with your own evidence. You can use it internally, or share it with customers as assurance. The government has said it is developing a certification scheme and will share details in due course, and the NCSC's own pages on the Code suggest its Cyber Resilience Testing scheme for organisations that want a higher level of assurance.
So the honest starting point for most small teams is the self-assessment: read the claims, collect the evidence you already have, and fix the gaps you find.
Where an application security review fits, and where it does not
An application security review does not make you compliant with the Code, and anyone who tells you otherwise is overselling. Several principles are about how your organisation runs, such as your support commitments to customers or the security of your build systems, and a review of the application does not reach them.
What a review does do is produce exactly the kind of evidence a few of the principles ask for:
- Knowing your components (1.2). A review that checks your dependencies tells you which third-party packages carry known issues and which need updating.
- Secure by design and by default (1.4). Findings such as missing access checks, weak session handling or permissive default settings are the gaps this principle is about, and a dated record of fixing them supports your claims.
- A way to report vulnerabilities (3.2). A review can note whether you publish a vulnerability disclosure route, such as a security.txt file, and what a simple one looks like.
- Finding, prioritising and managing vulnerabilities (3.3). A report that ranks every finding by severity and effort, plus a record of what was fixed and confirmed, is a working example of the process this principle describes.
- Timely security fixes (3.5). Dated remediation records support your own record of issues closed. Releasing updates and telling your customers stay with you.
That makes the review useful input to your self-assessment, not a substitute for it. You still complete and sign the form yourself, and you decide what to share with customers.
A sensible order for a small team
Name your Senior Responsible Owner. Download the self-assessment form from the Code's page on GOV.UK and read through the claims once, marking what you can already evidence. Publish a vulnerability disclosure route if you do not have one, because it is quick and visible. Then look hard at the application itself, find what is weak, and fix the most serious and easiest items first, keeping a dated record as you go. That record is what turns "we take security seriously" into something you can actually show.
If you want help with the application side
Our Application Security Review looks at your application by hand as well as with tools, ranks every finding by severity and effort to fix, and maps the findings to the principles of the Code they relate to, so your team knows which parts of the self-assessment the work supports. Remediation is optional, in fixed blocks, and we prepare and verify each fix while your team ships it. It does not certify you against the Code, and we will say so plainly. You can see a fictional example report or get in touch through our website.