In the modern digital landscape, software is eating the world, but vulnerabilities are eating software. If your organisation develops its own code—whether it is a core product, a customer portal, or just internal scripts—you are essentially a software company. And that means you have a target on your back.
ISO 27001:2022 Annex A 8.28, “Secure coding,” serves as the industry standard’s answer to this problem. It shifts the focus from “patching later” to “securing now.” It mandates that security principles be baked into the software development lifecycle (SDLC) from the very first line of code.
Table of contents
What is the Objective of Annex A 8.28?
The objective is preventing vulnerabilities at the source. Instead of relying solely on firewalls and antivirus software to catch attacks, Annex A 8.28 requires you to build software that is inherently resistant to attack. It ensures that secure coding principles are applied to software development to reduce the number of potential vulnerabilities in software.
This control applies not just to the code you write, but also to the code you borrow (open-source libraries) and the tools you use to build it.
Step-by-Step Implementation Guide
Implementing secure coding practices can feel overwhelming, especially for agile teams used to moving fast. However, it is about integrating security, not blocking development. Here is how to approach it.
1. Establish Secure Coding Principles
You cannot expect developers to write secure code if you haven’t told them what that looks like. You need a set of “Rules of the Road.”
According to the experts at Hightable.io, you shouldn’t try to reinvent the wheel here. The industry already has gold standards. Adopt frameworks like the OWASP Top 10 or the SANS Top 25. Your policy should explicitly state that code must be written to prevent common flaws like SQL injection, Cross-Site Scripting (XSS), and broken authentication.
2. Secure the Supply Chain (External Components)
Modern software is rarely built from scratch; it is assembled like LEGO using open-source libraries and frameworks. A significant portion of your codebase is likely code you didn’t write.
Annex A 8.28 requires you to manage the risk of these external components. You need a process to track which libraries you are using and monitor them for known vulnerabilities (often called Software Composition Analysis). If a library you use is found to have a critical flaw (like the infamous Log4j incident), you need to know immediately so you can update or patch it.
3. Secure the Development Environment
It is not just about the code; it is about the factory where the code is built. If a hacker compromises a developer’s laptop or your CI/CD pipeline, they can inject malicious code without anyone noticing.
Ensure that access to code repositories (like GitHub or GitLab) is strictly controlled with Multi-Factor Authentication (MFA). Hightable.io emphasizes the importance of logging access to these environments to create an audit trail of who changed what and when.
4. Competence and Training
The most sophisticated security tools in the world cannot fix a lack of knowledge. Developers are often trained to make code work, not necessarily to make it secure.
To comply with Annex A 8.28, you must provide regular training on secure coding practices. This keeps security top-of-mind and empowers developers to spot potential issues during peer reviews, long before the code reaches the testing phase.
5. Integrate Testing Before Deployment
This control goes hand-in-hand with Annex A 8.29 (Security testing). You must verify that your secure coding principles were actually followed.
Implement automated tools such as Static Application Security Testing (SAST) to scan code as it is written. This provides immediate feedback to developers, allowing them to fix security bugs as easily as they fix syntax errors.
DO IT YOURSELF
STOP SPANKING £10,000s on CONSULTANTS and ISMS ONLINE PLATFORMS
Common Challenges
“It slows us down.” This is the most common pushback. The counter-argument is that fixing a security breach in production is infinitely slower (and more expensive) than fixing a bug in development. By automating scans, the impact on speed is minimal.
“We don’t develop software.” Be careful with this assumption. Even if you don’t sell software, you likely use scripts, macros, or API integrations. As Hightable.io notes, if you are writing instructions for a computer to execute, you are coding, and this control applies.
A Quick Checklist for Annex A 8.28
Before your audit, ensure you can tick these boxes:
- Do you have a documented Secure Development Policy?
- Are developers trained on the OWASP Top 10 (or equivalent)?
- Do you maintain an inventory of third-party libraries (SBOM)?
- Is access to the source code repository restricted and monitored?
- Are code reviews mandatory and do they include security checks?
- Do you scan code for vulnerabilities before it goes to production?
Why This Control is Critical
Annex A 8.28 is the foundation of digital trust. By implementing secure coding, you are building resilience into the DNA of your organization. It ensures that your applications are not the weak link in your security chain, protecting both your data and your reputation.
About the author
Stuart Barker is a veteran practitioner with over 30 years of experience in systems security and risk management.
Holding an MSc in Software and Systems Security, Stuart combines academic rigor with extensive operational experience. His background includes over a decade leading Data Governance for General Electric (GE) across Europe, as well as founding and exiting a successful cyber security consultancy.
As a qualified ISO 27001 Lead Auditor and Lead Implementer, Stuart possesses distinct insight into the specific evidence standards required by certification bodies. He has successfully guided hundreds of organizations – from high-growth technology startups to enterprise financial institutions – through the audit lifecycle.
His toolkits represents the distillation of that field experience into a standardised framework. They move beyond theoretical compliance, providing a pragmatic, auditor-verified methodology designed to satisfy ISO/IEC 27001:2022 while minimising operational friction.
