Welcome to this guide on ISO 27001 Annex A 8.25. As a certification body, we often see confusion around this control. You might think it only applies if you are a software house writing complex code. This is not the case. If you develop software, configure systems, or even manage minor scripts, this control applies to you. At ISO27001.com, we want to ensure you pass your audit with flying colours. This article will walk you through what you need to do and what we expect to see.
Table of contents
What is Annex A 8.25?
Annex A 8.25 deals with the Secure Development Life Cycle. In simple terms, it requires you to build security into your development process from the very start. You cannot just build a product and try to stick security on top of it at the end. That approach rarely works. Instead, you must consider information security at every stage of the life cycle. This includes the initial idea, the design, the coding, the testing, and the maintenance.
The goal is to ensure that information security is an integral part of development. It ensures that you reduce risks and vulnerabilities before the software goes live. Whether you use a Waterfall method or an Agile approach, the principles remain the same. You need defined checkpoints for security.
Establishing Your Policy
The first step is paperwork. We know it sounds boring, but as auditors, we need to see the rules you have set for yourself. You need a Secure Development Policy. This document should outline how you handle security in development. It does not need to be a novel. It just needs to be clear.
Your policy should state that all development work must adhere to secure coding guidelines. It should mention that you will test for security issues before release. If you outsource development, your policy must state how you ensure that third party follows your security rules. When we visit you for an audit, we will ask to see this document first.
Defining Security Requirements
Before you write a single line of code, you must define your requirements. This is where many people fail. You likely have a list of features you want to build. You must also have a list of security requirements for those features. For example, if you are building a login page, a functional requirement is that a user can log in. A security requirement is that the password must be encrypted.
You should document these requirements. During an audit, we might ask to see the project plan for a recent update. We will look for evidence that you discussed security before you started building. If you use a ticketing system like Jira, we might look for a ticket that details these security needs.
Secure Design and Coding
Now comes the build phase. You need to ensure your developers or system administrators know how to build securely. This often involves training or following established standards. You might use the OWASP Top 10 as a baseline for web applications. This is a list of the most common security risks.
We expect you to have guidelines in place. If you use external developers, you must ensure they are competent. You should separate your development environment from your production environment. You should never develop or test on the live system. We will check your network diagram and interview your staff to confirm this separation exists.
Testing and Review
You cannot assume your code is secure. You must test it. Annex A 8.25 requires you to check your work. This can take many forms. You might use static code analysis tools that scan your code for errors automatically. You might perform peer reviews where one developer checks the work of another.
For larger changes, you might perform penetration testing. This is where you pay an ethical hacker to try and break your system. You do not need to do this for every small change, but you must have a process for deciding when it is necessary. We will ask for evidence of these tests. A screenshot of a scan result or a sign-off sheet from a peer review is perfect evidence.
The Maintenance Phase
The job is not done once the software is live. You must maintain it. This means patching bugs and updating libraries. If a vulnerability is found in a code library you use, you need a process to update it quickly. This ties in with other controls regarding vulnerability management.
We will look to see if you have a register of the software components you use. We want to know how you track their security status. If you leave your software to rot, it will eventually become insecure. You must show us that you keep it healthy.
What the Auditor Wants to See
At ISO27001.com, we stress that evidence is king. You can tell us you are secure, but you must prove it. When we audit Annex A 8.25, we look for three main things.
First, we look for the policy. Is it written down, approved, and communicated to staff? Second, we look for the process. Can you show us the steps you take from idea to launch? Third, we look for records. We want to see the test results, the code review logs, and the requirement documents. If you have these three elements, you are in a very good position.
Common Mistakes to Avoid
Do not make the mistake of thinking this does not apply to off the shelf software. If you configure a CRM system or a cloud platform, you are developing a solution. You must secure that configuration. Another mistake is ignoring the human element. You must train your developers. Secure code comes from secure coders.
Finally, do not overcomplicate it. If you are a small business, your secure development life cycle can be simple. It does not need to be a heavy bureaucratic burden. It just needs to be effective and consistent. Start small, document what you do, and ensure you actually do what you documented.
Implementing Annex A 8.25 is a vital step in protecting your information. It reduces the risk of data breaches and ensures your systems are robust. If you follow these steps and keep good records, you will satisfy your certification body and, more importantly, secure your business.