For many small businesses, the test environment is a major security blind spot. You might lock down your live customer database tight, but what happens when a developer needs to test a new feature? If they copy that real data into a test server, you have just bypassed your own security.
ISO 27001 Annex A 8.33 (Test Information) exists to plug this gap. It requires you to select, protect, and manage test data with the same rigour as your operational data.
What is ISO 27001 Annex A 8.33?
In simple terms, Annex A 8.33 requires you to secure the information you use for testing. The standard states that test information must be selected, protected, and managed.
For a small business, this control is about ensuring that you do not accidentally expose sensitive customer data (PII) or intellectual property while testing software, updates, or new processes.
The Golden Rule: Synthetic vs. Production Data
The easiest way for a small business to comply with Annex A 8.33 is to follow this golden rule: Do not use production (live) data for testing.
1. Use Synthetic Data (Recommended)
Synthetic data is “fake” data generated specifically for testing. It looks like real data (names, dates, credit card numbers) but contains no actual personal information. If this data is stolen, there is no breach because the people do not exist. For small businesses, this is the safest and cheapest route to compliance.
2. Anonymised Production Data
If you absolutely must use real data (e.g. to debug a specific complex issue), you must anonymise or “mask” it before it enters the test environment. Scramble names, redact emails, and blur credit card numbers so they cannot be reversed.
Why Small Businesses Get This Wrong
Small businesses often fail this control because of speed. It is faster to copy a live spreadsheet of 100 client orders to test a new invoicing tool than it is to generate dummy data. However, this creates significant risks:
- The GDPR Trap: Test servers often lack the strict access controls of live servers. If real personal data sits there, you are violating GDPR and Data Protection laws.
- The “Untidy” End: Developers often forget to delete test data. A copy of your customer database could sit on an insecure server for years, waiting for a hacker.
DO IT YOURSELF
STOP SPANKING £10,000s on CONSULTANTS and ISMS ONLINE PLATFORMS
How to Comply: A Step-by-Step Guide
To satisfy an auditor for Annex A 8.33, you do not need expensive enterprise software. You need a clear process.
Step 1: Define Your Policy
Write a simple statement in your Secure Development Policy: “Production data shall not be used for testing unless sanitised and authorised.”
Step 2: Control Access
Treat your test environment like your production environment. Only authorised staff should have access. Use unique logins and Multi-Factor Authentication (MFA) even for test servers.
Step 3: Log Activity
Keep a log of when data is moved to a test environment. If you copy data, log who did it, when, and who approved it. This audit trail is essential for your certification.
Step 4: Clean Up
Test data should have an expiration date. Implement a process to securely delete test information immediately after testing is complete.
What the Auditor Will Ask
During your ISO 27001 audit, the auditor will look for evidence of control. Be prepared for these questions:
- “Show me the data you are using in your test environment right now.”
- “If this is real data, can you show me the authorisation ticket for moving it here?”
- “How do you ensure this data is deleted once the project ends?”
Summary Checklist for SMEs
- Stop copying live customer databases to test folders.
- Start using synthetic/dummy data generators.
- Sanitise real data if it must be used (scramble names/IDs).
- Log every transfer of data into a test environment.
- Delete test data immediately after use.
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.
