How to implement ISO 27001 Annex A 8.28 – A certification bodies guide

Welcome to this guide on secure coding. If you are reading this, you are likely looking at the ISO 27001 Annex A controls and wondering how to handle software development. You might be a startup building a new app or an established firm updating your processes. Regardless of your size, Annex A 8.28 is a critical control if you develop code or scripts.

At ISO27001.com, we see many companies struggle with this control because they think it requires complex tools or expensive consultants. It does not. It requires a structured approach to writing software that is safe and secure. Here is how you can implement this control and what we, as a certification body, expect to see.

What is Annex A 8.28 Secure Coding?

Secure coding is the practice of writing software in a way that guards against security vulnerabilities. In the context of ISO 27001, Annex A 8.28 requires you to apply secure coding principles to your software development. This applies to the entire lifecycle of the software. It covers the planning stage, the actual coding, and the review process.

The goal is simple. You want to ensure that the software you build does not introduce risks to your organisation or your customers. This control is not just for software companies. If you write scripts to automate tasks or build internal tools, this control applies to you.

Why This Control Matters to Your Audit

When an auditor looks at your system, they are checking for risk. Poorly written code is a massive risk. It is a common entry point for hackers. If you do not have rules for how you write code, you cannot guarantee the security of your data.

We want to see that you are proactive. We do not expect perfect code that never has a bug. We expect a system that reduces the chance of bugs and catches them quickly when they happen.

Step 1: Define Your Secure Coding Principles

You cannot expect developers to write secure code if you do not tell them what that means. The first step is to establish a set of rules. You do not need to invent these from scratch. You can adopt industry standards.

The most common standard is the OWASP Top 10. This list covers the most critical security risks to web applications. Stating that your development team follows the OWASP guidelines is a great starting point. You should document this in a policy or a procedure document. This document tells your team what is expected of them.

Step 2: Create a Secure Development Environment

Where you write code is just as important as how you write it. You need to secure your development environment. This usually involves access control. Only authorised developers should have access to the code repositories.

You should also separate your environments. Do not develop code in the live environment. You should have a development environment, a testing environment, and a production environment. This ensures that unfinished or insecure code does not impact your live data. We will look for evidence of this separation during an audit.

Step 3: Implement Code Reviews and Testing

Trust but verify. This is a core concept in security. You need a process to check the code before it goes live. Peer review is a very effective method. This is where another developer reviews the code written by a colleague. They check for errors and security issues.

You should also use automated tools. There are many tools that scan code for common vulnerabilities. These are known as Static Application Security Testing (SAST) tools. You do not need the most expensive tool on the market. You just need a tool that works for your technology stack.

Step 4: Manage Your Libraries and Third Party Components

Modern software is rarely built from scratch. Developers use libraries and frameworks to speed up the process. However, these external components can have their own vulnerabilities. Annex A 8.28 requires you to manage these risks.

You need a process to track what libraries you are using. You also need to check if those libraries have known security flaws. If a vulnerability is found in a library you use, you need a plan to update it. This is often called software composition analysis.

Step 5: Training and Competence

Your developers need to know how to write secure code. It is not enough to just give them a policy. You must provide training. This could be an annual workshop, an online course, or regular briefings on new threats.

Keep records of this training. If an auditor asks how you ensure your team is competent, showing them training records is the best answer. It proves you are investing in your people and your security.

What the Auditor Will Ask For

When we come to audit you, we will look for evidence. We are not there to read your code line by line. We are there to check your process. Here is what we might ask to see:

• Policy Documents: We want to see your secure coding guidelines.
• Access Logs: We might check who has access to your code repositories.
• Review Records: We want to see proof that code reviews happen. This could be pull requests in GitHub or GitLab.
• Test Results: We might ask for reports from your security scanning tools.
• Training Records: We need to see that your developers have been trained on secure coding principles.

Common Mistakes to Avoid

We often see companies fail this control because they overcomplicate it. Do not write a policy that is too hard to follow. If your policy says you will review every single line of code but you only have two developers, you will fail. Make your policy realistic.

Another mistake is ignoring legacy code. If you have old software that you still use, you need to assess it. You might not be able to rewrite it, but you should have a plan to manage the risks it poses.

Conclusion

Implementing Annex A 8.28 is about building a culture of security in your development team. It is about defining the rules, providing the tools, and checking the work. If you follow these steps, you will satisfy the auditor and, more importantly, you will have more secure software.

If you need templates or more detailed guides on this control, ISO27001.com has resources that can assist you. Start small, be consistent, and keep records of everything you do.