If you are navigating the transition from the old ISO 27001:2013 standard to the shiny new ISO 27001:2022 version, you’ve probably noticed that things have been moved around quite a bit. The Annex A controls have been consolidated, renamed, and in many cases, sharpened to deal with modern digital risks. One specific area that has seen a subtle but important shift is the management of test information, now found under Annex A 8.33.
Protecting the data used in testing environments has always been a bit of a headache for security officers. Let’s break down what has changed and what you need to do to stay compliant.
Table of contents
From Control 14.3.1 to Annex A 8.33
In the 2013 version of the standard, the requirements for protecting test data were found under Control 14.3.1, titled “Protection of test data.” It was part of the domain focused on system acquisition, development, and maintenance. In the 2022 update, this has been renumbered to Annex A 8.33 and is now simply titled “Test information.”
The change in title from “data” to “information” is more than just semantics. It reflects a broader scope. While “data” often makes people think of rows in a database, “information” covers everything from configuration files and credentials to the intellectual property contained within your testing scripts.
What Are the Primary Changes?
The core objective hasn’t changed: you still need to ensure that the information you use for testing is protected. However, the 2022 version is much more explicit about the risks associated with using production data in a test environment. In the past, many organisations took a somewhat relaxed approach to “refreshing” their test databases with live customer information. Under the new guidelines, this is a major red flag.
According to the experts at Hightable.io, the 2022 version emphasises that the use of operational (live) data for testing should be avoided whenever possible. If you absolutely must use it, the controls required are now much more stringent. You aren’t just expected to “protect” it; you are expected to justify why synthetic data couldn’t be used instead.
The Requirement for Better Sanitisation
One of the key shifts in Annex A 8.33 is the focus on the techniques used to protect information. If you are using real-world information for testing, the 2022 standard expects a higher level of governance. This includes:
- Anonymisation and Masking: You need to prove that sensitive elements have been removed or obscured so that the information can no longer identify an individual or a specific business transaction.
- Access Control: Just because it is a “test” environment doesn’t mean access should be a free-for-all. Access to test information must be as strictly controlled as access to production information.
- Logging and Monitoring: You are now expected to keep better records of when test information is created, used, and most importantly deleted.
Why the Change Matters for Modern Teams
The 2013 standard was written in a world where “DevOps” was still a relatively new term for many. Today, with continuous integration and continuous deployment (CI/CD) pipelines, code and data move faster than ever. The 2022 version of Annex A 8.33 is designed to fit into these automated workflows.
As noted by Hightable.io, the update encourages organisations to move toward “Privacy by Design.” This means that instead of trying to secure a copy of the production database, teams are encouraged to build systems that generate high-quality synthetic data from the start. This removes the risk of a data breach in the development environment entirely, which is a much more robust way to manage risk.
Meeting the New Expectations
If you are updating your Statement of Applicability (SoA) for the 2022 version, you should look at Annex A 8.33 not just as a technical hurdle, but as a policy requirement. You need a clear process for how test information is selected, protected, and disposed of.
Auditors will no longer be satisfied with a simple “we don’t use real data” statement if they can see developers running queries against older backups. You will need to show the tools and methods you use for data masking or the logic behind your synthetic data generation. By aligning with these updated requirements, you aren’t just ticking a box for ISO 27001:2022; you are significantly reducing the likelihood of a costly data leak from your non-production environments.
Conclusion
The transition from ISO 27001:2013 Control 14.3.1 to ISO 27001:2022 Annex A 8.33 marks a shift toward more professional, intentional management of testing environments. By broadening the focus from “data” to “information” and narrowing the allowance for using live production data, the standard has caught up with the complexities of the modern tech landscape. For most organisations, this is the perfect time to audit their dev-test-prod pipelines and ensure that their “sandboxes” are as secure as their live environments.