If you are navigating the transition from the old ISO 27001:2013 standard to the updated 2022 version, you have likely noticed that things look quite different. The Annex A controls have been streamlined, reordered, and in many cases, strengthened. One area that has seen a significant shift in focus is how we validate our security measures. This brings us to the new control: Annex A 8.29, which covers Security Testing in Development and Acceptance.
In the 2013 version, testing requirements were somewhat scattered across the standard. With the 2022 update, these have been pulled together to create a more cohesive and demanding requirement. Let’s break down what has actually changed and what it means for your compliance journey.
Table of contents
From Fragmented Requirements to a Unified Control
In the ISO 27001:2013 standard, testing was primarily addressed under Control A.14.2.8 (System Security Testing) and A.14.2.9 (System Acceptance Testing). While these were effective for their time, they often felt like separate hurdles to jump over at different stages of a project.
The 2022 update introduces Annex A 8.29 as a more comprehensive “Technological” control. It merges the concepts of security testing during development with the final acceptance testing phase. The goal here is simple: ensuring that security isn’t just checked at the very end, but is a continuous part of the lifecycle. By consolidating these, the standard encourages a “shift-left” mentality where testing happens earlier and more frequently.
The New Emphasis on Continuous Validation
One of the standout changes in Annex A 8.29 is the expectation for a more rigorous and structured testing process. It isn’t just about checking if a system “works” anymore; it’s about verifying that the security requirements defined at the start of the project are actually functioning as intended in the final product.
According to insights from Hightable.io, this control now places a heavier emphasis on documenting the test results and ensuring that the testing environment closely mimics the real-world production environment. This reduces the risk of a “it worked on my machine” scenario where security vulnerabilities only appear once the system goes live.
What Exactly is Required Now?
When comparing the two versions, the 2022 standard is much more explicit about what your testing programme should look like. Under Annex A 8.29, you are expected to:
- Test During Development: Security testing must be integrated into the development activities, not just performed as a final audit.
- Define Acceptance Criteria: You must have clear, pre-defined criteria that a system must meet before it is allowed to go live.
- Verify Security Functionality: Testing should specifically target security features, such as access controls, encryption, and logging, to ensure they behave correctly.
- Use Representative Data: While testing, you must ensure that any data used is protected, following the guidelines often found in related controls like 8.33 (Test Data).
Why the Change? The Rise of Agile and DevOps
The 2013 version of the standard was written in a world where “Waterfall” development was still common. You built a system, you tested it, and then you launched it. In today’s world of Agile, DevOps, and continuous integration/continuous deployment (CI/CD), that old model doesn’t hold up.
As noted by Hightable.io, the 2022 update reflects the need for security testing to keep pace with rapid development cycles. Annex A 8.29 is designed to fit into modern workflows where software is updated weekly, daily, or even hourly. It moves the standard away from a “point-in-time” check and toward an ongoing assurance process.
How to Transition Your Testing Processes
If you are already compliant with the 2013 version, you likely have some form of testing in place. However, to meet the 8.29 requirements, you may need to formalise your documentation. Start by reviewing your system development lifecycle (SDLC) and identifying where security testing is officially recorded.
You should also ensure that your acceptance testing includes a formal sign-off that specifically references security. It is no longer enough for a stakeholder to say “the system is ready”; they need to confirm that the system is securely ready based on the tests performed during the engineering phase.
Conclusion
The shift from the 2013 controls to ISO 27001:2022 Annex A 8.29 is a clear signal that the standard is evolving alongside technology. By merging development and acceptance testing into one robust control, ISO has made it easier to understand the full scope of system validation while making it harder for vulnerabilities to slip through the cracks. For organisations looking to stay ahead, embracing this more integrated approach to security testing is a vital step in maintaining a modern and effective Information Security Management System (ISMS).