If you develop or sell software in the UK, the Software Security Code of Practice is probably on your radar. It is voluntary today. It will likely become a procurement requirement for public sector and regulated industry contracts within the next 12–18 months. If you provide services to government, financial services, healthcare, or education, the question is not whether to do this. It is when.
We completed our own self-assessment in September 2025 and shared what we found in a previous article. This guide is based on that experience. It covers how the assessment works, how to approach it, and what to do when you find gaps.
What you are assessing against
The Code of Practice contains 14 principles across four themes:
Theme 1: Secure Design and Development - covers your development framework, third-party component management, testing processes, and secure-by-design practices. This is usually the most substantial section.
Theme 2: Build Environment Security - covers access control, authentication, and change logging for your build and release infrastructure.
Theme 3: Secure Deployment and Maintenance - covers how you distribute software, manage vulnerabilities, and deliver security updates. If you are a SaaS vendor, some claims in this theme will apply differently.
Theme 4: Communication with Customers - covers support and maintenance commitments, end-of-support notice periods, and incident communication.
The NCSC provides an Assurance Principles and Claims (APC) document that breaks each principle into specific, evidenceable claims. This is the actual assessment tool. You can download it from the NCSC website alongside a self-assessment template.
How to approach the assessment
-
Start with a readthrough, not a form-filling exercise. Read the full APC document before you start writing evidence. Understanding the structure and the relationships between claims helps you avoid repeating yourself and spot where a single piece of evidence covers multiple claims. Some of our development practices were relevant to three or four different claims.
-
Assign it to someone who knows the engineering, not someone from compliance. The claims are technical. They ask about development frameworks, build pipelines, dependency management, and testing practices. The person completing the assessment needs to know how your software is actually built and deployed. At Hexiosec, as our Engineering Team Lead, I completed the assessment. If your organisation is larger, you might need input from multiple engineers, but one person should own the document and be accountable for consistency.
-
Write evidence, not assertions. Each claim has an evidence column. Do not fill it with ‘yes, we do this.’ Describe specifically what you do, where it is documented, and which tools or processes support it. Note that in doing this, you don’t need to copy and paste your entire policy procedures, just referencing them is fine. If your development framework is documented in Confluence, say so. If your dependency management uses Renovate or Dependabot, name the tool. If your access control is managed through Terraform, explain how. Specificity is what separates a useful self-assessment from a tick-box exercise.
-
Use the arguments column to explain your reasoning. The APC template includes an ‘Arguments / Assumptions’ column alongside the evidence. Use it. This is where you explain why your evidence meets the claim - especially where your implementation is different from the most literal reading of the principle. For SaaS vendors, this column is essential for explaining how your delivery model addresses claims that were written with distributed software in mind.
-
Be honest about gaps. The point of a self-assessment is to find what needs improving, not to produce a clean sheet. If you cannot fully evidence a claim, say so clearly and describe what you plan to do about it. We found two areas where we wanted to strengthen our practices. Documenting them was the most valuable part of the process - it gave us concrete, prioritised actions rather than a vague sense that ‘we should probably tighten up our security.’
Common patterns to watch for
Third-party components are where most organisations will find work to do. Principle 1.2 asks you to identify all third-party components, verify their integrity, test them before deployment, test their updates, and have processes to manage and deploy those updates. Many development teams do some of this well and other parts inconsistently. The gap is usually in documentation - the practices exist but are not recorded in a way that can be evidenced.
The build environment is often under-documented. Theme 2 asks about access control, logging, and audit trails for your build infrastructure. Most teams have reasonable controls in place but have not written them down formally. If your build access is managed through platform defaults (GitHub roles, cloud IAM) but you have not documented the role structure or reviewed it recently, that is a common gap. Whilst assessing your response to this theme, you should be asking yourself:
- Do I know how to rebuild our infrastructure?
- Has the infrastructure evolved since the first version of the documentation was written?
Key tip: I’d suggest using terraform to do infrastructure as code, so you know it’s always up to date. This covers you for disaster recovery and business continuity planning as well.
Customer communication is easy to underestimate. Theme 4 asks about support commitments, end-of-life policies, and incident communication. SaaS vendors often handle these well operationally but have not published them clearly enough for a customer to find them independently. Reviewing your public-facing documentation through the lens of ‘could a customer answer these questions from what we have published?’ is a useful exercise.
How long it takes
Honestly, it depends on how well‑documented your practices already are.
At Hexiosec, the initial review and identification of existing evidence took just a few hours, with the full write‑up requiring only a few additional hours of focused work. The overall commitment represents a very low barrier to completing the assessment, while the value is exponential.
Admittedly, addressing the gaps we identified took longer, as it required real changes to processes rather than documentation alone but even so, the return on effort remains extremely high.
If your development practices are good but poorly documented, expect the documentation effort to be the majority of the work. If your practices have genuine gaps, the assessment will surface them quickly - and that is its value.
Is it worth it?
Yes. Three reasons.
It gives you a structured, evidence-based view of your software security posture that you can share with customers and procurement teams. That is increasingly what buyers are asking for.
It surfaces real, actionable improvements. Not theoretical risk items on a register, but specific gaps in specific processes that you can fix. And it positions you ahead of the curve. The Cyber Security and Resilience Bill is progressing through Parliament now. Procurement frameworks are tightening. Completing the self-assessment today means you are ready when ‘voluntary’ becomes ‘expected.’
Read how we approached this: Why Hexiosec adopted the Code of Practice and What we found in our self-assessment.
Not sure where to start with your own security posture? Run a free Hexiosec ASM scan and see what your organisation looks like from the outside.
Related Posts
