If you have been working within the framework of information security for a while, you’ve likely noticed that the ISO 27001 standard recently had a major makeover. One of the most significant shifts occurred in how we handle software development. Specifically, we are looking at the transition from the 2013 controls to the 2022 version’s Annex A 8.28, which focuses on Secure Coding.
In the 2013 version, guidance on secure development was somewhat fragmented. It was tucked away in various sections under “System Acquisition, Development, and Maintenance.” However, the 2022 update has consolidated these ideas into a much more robust and focused control. Let’s dive into what has actually changed and why it matters for your organisation.
Table of contents
From General Guidance to Specific Secure Coding
In the older 2013 standard, you might remember Control A.14.2.1 (Secure Development Policy) or A.14.2.5 (Secure System Engineering Principles). These were great for setting a high-level philosophy, but they often left developers wondering about the “how” in their day-to-day coding tasks.
The 2022 version introduces Annex A 8.28, dedicated entirely to Secure Coding. This isn’t just a name change; it represents a shift in mindset. The new control recognises that in today’s world, software isn’t just a tool, it is often the very foundation of the business. Therefore, security shouldn’t be an afterthought or a final check; it needs to be baked into the code from the very first character typed.
The Introduction of Governance and Proactivity
One of the biggest changes in the 2022 update is the emphasis on establishing a “minimum baseline” for security. Annex A 8.28 requires organisations to define and implement secure coding principles for all software development. According to the experts at Hightable.io, this means moving away from reactive patching and toward a proactive “security-by-design” approach.
While the 2013 version suggested having rules, the 2022 version expects you to have a living, breathing program. This includes using secure coding techniques, monitoring for known vulnerabilities, and ensuring that your developers are actually trained to spot common pitfalls like injection flaws or broken authentication.
Key New Requirements in Annex A 8.28
If you are comparing the two versions, there are a few specific areas where the 2022 standard raises the bar:
- External Libraries and Open Source: The 2013 version was relatively quiet on the risks of third-party code. The 2022 version explicitly expects you to manage the risks associated with external software components and libraries.
- Vulnerability Handling: There is a much stronger focus on how you identify and fix vulnerabilities after the code is deployed. It is no longer enough to just write “good code”; you need a plan for when things go wrong.
- Configuration and Environment: Secure coding now extends beyond the code itself to include the security of the development environment and the tools used to build and deploy the software.
Why the Change Was Necessary
The tech landscape has evolved massively since 2013. We’ve seen the rise of DevOps, cloud-native development, and an explosion in the use of open-source repositories. The old standard simply didn’t provide enough detail to protect against modern supply chain attacks. As Hightable.io points out, the 2022 update aligns ISO 27001 with modern development practices, making it much more relevant for software-as-a-service (SaaS) companies and internal dev teams alike.
How to Adapt to the 2022 Standard
If you are transitioning from the 2013 version, the first step is to stop looking for a 1:1 map. While the 2013 controls are often “included” in the 2022 version, Annex A 8.28 is broader. You will need to document your secure coding practices more formally than you might have in the past.
Start by identifying which programming languages and platforms your team uses and create specific coding standards for each. Make sure your “Definition of Done” includes security testing. This shift might seem like extra work initially, but it significantly reduces the long-term risk of a data breach or a costly system failure.
Conclusion
The change from the 2013 version to ISO 27001:2022 Annex A 8.28 is a welcome evolution. It brings the standard into the modern era, focusing on the practical reality of software development. By moving from general “engineering principles” to specific “secure coding” requirements, the standard helps organisations build more resilient, trustworthy software. It’s a challenge, certainly, but it’s one that will make your information security management system much stronger in the long run.