Software Security Code of Practice: What Changed in Cyber Essentials v3.3
Software Security Code of Practice: What Changed in Cyber Essentials v3.3
Cyber Essentials (CE) version 3.3 (the Danzell update, effective 27 April 2026) drops the Open Worldwide Application Security Project (OWASP) Application Security Verification Standard (ASVS) reference. In its place, the requirements now point to the UK government's Software Security Code of Practice. The Code of Practice is best practice guidance, not a CE pass/fail rule. If you don't build software, this change won't affect your assessment.
What actually changed
The software development section got two updates in v3.3.
The section name changed from its previous label. Older versions called it "Web applications." Version 3.3 calls it "Software development." The scope hasn't changed, but the new name hints at something broader than web apps alone.
The second change is the reference itself. Older versions pointed to the OWASP Application Security Verification Standard (OWASP ASVS) as best practice for fixing application flaws. Version 3.3 drops that link entirely, and it now says: "See the Software Security Code of Practice for further details."
That's the full change. Two sentences updated and one section renamed, which looks minor. But the shift from an open-source global framework to a UK government code is worth knowing about. This is especially true if your business builds software.
What is the Software Security Code of Practice?
The Software Security Code of Practice is a UK government guide. It sets out rules and practices for building secure software. The National Cyber Security Centre (NCSC) backs it. It forms part of the government's push to raise software security standards across UK businesses.
The code covers the full software development lifecycle. It looks at threat modelling, secure coding, dependency management, testing, and flaw disclosure. The goal is to help developers and managers build security into their process from the start, not bolt it on later.
OWASP ASVS is a global standard run by volunteers. The Software Security Code of Practice is a UK government document. The shift aligns CE with UK government guidance rather than a third-party standard. Both cover similar ground in different ways. (as noted in the October 2024 governance review).
For businesses going through a CE assessment, the gap between the two is academic. Neither is a pass/fail test for CE. The CE requirements list the Code of Practice as suggested reading, not as something your assessor will check.
How does this affect your CE assessment?
For most organisations, it doesn't change anything at all.
The scope rules for software in CE have not changed. Off-the-shelf web apps (the software your business buys and uses, like your customer relationship management (CRM) tool or accounting tool) are in scope by default. Your assessor checks that these apps are licensed, supported, and patched on time. That requirement stays exactly the same as before.
Bespoke and custom parts of web apps remain out of scope. If your team builds internal tools or customer-facing apps, those custom parts are not tested as part of CE. This was true before v3.3 and still is.
The Software Security Code of Practice is listed as best practice. Your assessor won't test you on it, and you won't fail for not following it. It shows up in the requirements as further reading for businesses that want to improve their software security beyond what CE covers.
| Element | v3.2 | v3.3 |
|---|---|---|
| Section name | Web applications | Software development |
| Best practice reference | OWASP ASVS | Software Security Code of Practice |
| Off-the-shelf web apps in scope | Yes | Yes (unchanged) |
| Bespoke/custom software in scope | No | No (unchanged) |
| Reference is mandatory for CE | No | No (unchanged) |
| Assessor tests against reference | No | No (unchanged) |
If you're renewing your CE and you don't build software, you can skip this change. It adds nothing to your assessment preparation.
What this means for your CE assessment
The Code of Practice is referenced in v3.3, so it's natural to wonder whether assessors will start asking about it. I've had clients ring me about this already.
Here's what I'd expect in practice based on the assessments I run. If your organisation doesn't develop software, this won't come up during your assessment at all. The assessor is checking the five technical controls against your in-scope systems. The Code of Practice sits outside those controls.
If your organisation does develop software, a thorough assessor might mention it in conversation. They might ask whether you follow a secure development framework as context for understanding your environment. But they won't mark you down for not following the Code of Practice. It's guidance rather than a pass/fail criterion for assessment.
Where it could matter is in the scope discussion. The section rename from "Web applications" to "Software development" might prompt assessors to ask more detailed questions about what software your organisation builds and how it interacts with your in-scope systems. That's not a trick question at all; it's the assessor making sure nothing's been missed from the scope definition.
My advice: if you build software, mention it during the scoping conversation and be clear about what's off-the-shelf and what's bespoke. That avoids any confusion later in the assessment.
What if your organisation develops software?
This is where the change gets more interesting, even though it won't change your CE result.
Say your business builds software of any kind. That might be internal tools, products you sell, or parts built into other systems. The Code of Practice gives you a hands-on framework backed by the UK government. Following it won't change your CE pass or fail. But it does place your development work against a known standard.
The line between CE scope and best practice is blurry here. CE keeps bespoke software out of scope. But the same document now points you to a code that covers exactly that bespoke software. The message is clear enough to anyone paying attention. Your custom code won't be tested in a CE assessment. But the guidance exists because you should follow it anyway.
Did you cite OWASP ASVS in your internal dev policies because the CE requirements named it? You may want to update those references. CE no longer points to OWASP ASVS directly. OWASP is still a valid and widely used framework, so there's no reason to stop using it. But if your docs say "following OWASP ASVS as named in CE requirements," that link is now stale.
If you build software for government contracts or public sector clients, the Code of Practice may carry more weight than OWASP ASVS. A UK government code named in the UK's main cyber security scheme sends a clear signal. It shows which framework the government expects businesses to follow.
The real question for dev teams is simple. If you already follow a secure development framework (OWASP ASVS, National Institute of Standards and Technology (NIST) Secure Software Development Framework (SSDF), or something in-house), the Code of Practice won't clash with it. These frameworks overlap a lot, but the difference is backing. CE now points to the UK government's code. That matters to auditors, buyers, and clients who ask about your security practices.
What hasn't changed
The core rules about software in CE scope stay the same.
Off-the-shelf web apps that your business uses are in scope. Your assessor checks they're licensed, supported, and getting security updates. Custom code your team writes is out of scope.
The five controls (firewalls, secure setup, security updates, user access control, and malware protection) have not changed. The 14-day patching deadline for critical and high-risk flaws still applies. Password and multi-factor authentication (MFA) rules are the same. Note that v3.3 has separate changes to MFA and FIDO2 covered in the Danzell changes overview.
Will the Code of Practice become mandatory?
Version 3.3 keeps the Code of Practice as best practice only. The wording is "See the Software Security Code of Practice for further details." It does not say "you must comply."
But the direction of travel is clear. CE used to point to an open-source global framework with no formal UK government backing. It now points to a UK government code. Renaming the section from "Web applications" to "Software development" broadens the implied scope. The actual assessment scope stays the same, for now.
No one can say if a future CE version will make the Code of Practice a firm rule. But the pattern is telling if you know where to look. CE tends to signal changes early (through guidance, renamed sections, and best practice notes) before making them mandatory later. Backup guidance took exactly the same path before becoming prominent. It moved from a minor note to its own section in v3.3, while still being non-mandatory.
If your business builds software and you want to stay ahead, read the Software Security Code of Practice now. It costs nothing and there's no downside. If it does become mandatory in a future version, you'll be ready.
What you need to do
If you don't build software: Nothing changes for your CE assessment. The renamed section and new reference don't affect what your assessor checks. Focus on the changes that do matter, such as the cloud services and MFA updates in the v3.3 overview.
If you build software and hold CE: Update any internal docs that cite OWASP ASVS through the CE requirements. Read the Software Security Code of Practice as best practice. Your CE assessment won't test you on it. But knowing it puts your team in a good spot for future changes.
If you're going for CE for the first time: The Code of Practice is background reading, not exam material. Your assessor will check that your off-the-shelf web apps are licensed, supported, and patched. They won't test your dev practices against any external code or standard.
You can see our CE assessment pricing on the website. CE Basic runs from £320 plus value added tax (VAT). CE Plus runs from £1,200 to £2,100 plus VAT. The price depends on the size and complexity of your scope.
Need help with your Cyber Essentials assessment? Get in touch, email [email protected], or call +44 20 3026 2904.
Related articles
- Cyber Essentials v3.3: What the Danzell Update Changes
- 14-Day Patching: What the Requirement Actually Means
- Cyber Essentials Scope Changes Under Danzell
- What to Expect on Cyber Essentials Assessment Day
- Building AI-Assisted Security Assessments
Get cybersecurity insights delivered
Join our newsletter for practical security guidance, Cyber Essentials updates, and threat alerts. No spam, just actionable advice for UK businesses.
Related Guides
Can Your CE Basic Certificate Be Revoked? What Happens When You Fail CE Plus Under Danzell
Under Danzell, failing the CE Plus second sample scan can revoke your CE Basic certificate too. Here is how revocation works, what it costs, and how to prevent it.
Cyber Essentials Plus First-Time Pass: What Danzell Actually Requires
Under Danzell, CE Plus scans must pass first time. No remediation during the assessment. Here is the double sampling process, what triggers it, and how to prepare.
Why RMM Scanners and Windows Defender Will Fail Your Cyber Essentials Plus Assessment
RMM tools and Windows Defender are not approved for CE Plus internal vulnerability scans. Here is what the assessment actually requires and why your IT provider's scanner will miss critical vulnerabilities.
Ready to get certified?
Book your Cyber Essentials certification or check your readiness with a free quiz.