When businesses rush to get a new feature out the door, the first thing that often gets compromised is security in the testing phase. Developers need data to test with, and the easiest path is often just copying a slice of the live production database. But this convenience is a massive security trap.
ISO 27001:2022 Annex A 8.33, titled “Test information,” is designed to close this specific loophole. It ensures that the data you use for testing, development, and quality assurance is selected carefully and protected just as rigorously as your live business data.
Table of contents
What is the Core Objective of Annex A 8.33?
The objective here is straightforward: protect your information during the testing process. The standard requires that test information be appropriately selected, protected, and managed. This prevents the unauthorized disclosure, modification, or loss of sensitive data in environments that are often less secure than your production systems.
If you are using real customer names, credit card numbers, or health records in a testing environment that half your dev team has admin access to, you are walking a fine line. Annex A 8.33 pushes you to move away from using “live” data or, at the very least, to lock it down tight.
Step-by-Step Implementation Guide
Implementing this control doesn’t mean you have to stop testing. It just means you need to be smarter about the data you use. Here is a practical approach to getting it right.
1. Prioritise Synthetic Data
The best way to protect sensitive data is to simply not use it. Whenever possible, your team should use synthetic or “dummy” data. This is data that looks and acts like real data—it has the right structure, formats, and relationships—but it doesn’t correspond to any real person or entity. If a hacker steals a database full of “John Doe” and “Jane Smith” records, your reputation remains intact.
2. Mask and Anonymise Live Data
Sometimes, synthetic data just won’t cut it. You might need to replicate a specific bug that only happens with complex, real-world data sets. If you must use production data, you need to sanitise it.
According to the guidance from Hightable.io, you should employ data masking or anonymisation tools before the data ever leaves the secure production environment. This could involve scrambling names, blurring credit card numbers, or stripping out personally identifiable information (PII) entirely. The goal is to make the data useless to an attacker while keeping it useful for the developer.
3. Lock Down the Test Environment
Treat your test environment with the same respect as your production environment. Just because it is “only testing” doesn’t mean you can leave the doors open. Implement the principle of least privilege. Only the developers and testers who actively need access to that specific data should have it. If you are using real data, strict access controls and robust authentication are non-negotiable.
4. Log Everything
You need to know who is accessing your test data and when. Enable logging in your test environments to create an audit trail. If data does leak, you need to be able to trace it back to the source. This also acts as a deterrent; if staff know their access is being monitored, they are less likely to mishandle the data.
5. The “Clean Up” Rule
Test data should have an expiration date. Once the testing is complete, the data should be securely deleted. Do not let copies of your production database sit on a test server for months “just in case.” The longer it sits there, the higher the risk of it being forgotten and eventually compromised.
DO IT YOURSELF
STOP SPANKING £10,000s on CONSULTANTS and ISMS ONLINE PLATFORMS
Common Challenges and Solutions
Challenge: Developers complain that scrubbing data takes too long and slows down their sprints. Solution: Automate the process. Build data masking scripts into your CI/CD pipeline so that fresh, sanitised test data is available on demand without manual intervention.
Challenge: We don’t have the budget for expensive data masking tools. Solution: Start simple. Even basic scripts that replace names with random strings or nullify email addresses can significantly reduce risk. Hightable.io suggests that if you must use real data without full masking, you should record this as a formal risk in your risk register and manage it accordingly.
A Quick Checklist for Annex A 8.33
Before your next internal or external audit, ensure you can answer “yes” to these questions:
- Do you have a policy that defines what data can be used for testing?
- Is the use of operational (live) PII in testing formally authorised and logged?
- Are test environments separated securely from production environments?
- Is test data erased immediately after the testing activity is finished?
- Are access rights to test information reviewed regularly?
Why This Matters Beyond Compliance
Implementing Annex A 8.33 is not just about satisfying an auditor. It is about protecting your business from a data breach that could happen in the place you least expect it. By rigorous management of your test information, you ensure that your innovation and development processes don’t become your biggest security liability.
About the author
Stuart Barker is a veteran practitioner with over 30 years of experience in systems security and risk management.
Holding an MSc in Software and Systems Security, Stuart combines academic rigor with extensive operational experience. His background includes over a decade leading Data Governance for General Electric (GE) across Europe, as well as founding and exiting a successful cyber security consultancy.
As a qualified ISO 27001 Lead Auditor and Lead Implementer, Stuart possesses distinct insight into the specific evidence standards required by certification bodies. He has successfully guided hundreds of organizations – from high-growth technology startups to enterprise financial institutions – through the audit lifecycle.
His toolkits represents the distillation of that field experience into a standardised framework. They move beyond theoretical compliance, providing a pragmatic, auditor-verified methodology designed to satisfy ISO/IEC 27001:2022 while minimising operational friction.
