ISO 27001 A.8.33: Test information
What This Control Requires
Test information shall be appropriately selected, protected and managed.
In Plain Language
Copying your production database to a test environment is quick, easy, and a compliance nightmare. That test environment now contains real customer data, financial records, or personal information - subject to the same protection requirements as production but sitting in a far less secure environment. Under GDPR and similar regulations, this is a real liability. A breach in your test environment affects real people with real data. An auditor finding unmasked personal data in dev or test will flag it immediately. The answer is to use synthetic data (artificially generated) or anonymised data (production data with identifying information stripped) wherever possible. When production data genuinely must be used for testing, strict controls apply: formal authorisation, proper access restrictions, logging, and secure deletion when you are done.
How to Implement
Write a test data management policy that defines how test information is selected, created, protected, and managed. The default should be synthetic or anonymised data, with production data only as a documented exception. Generate synthetic test data wherever you can. Use test data generation tools to create realistic but fictitious datasets. Make sure your synthetic data covers edge cases and boundary conditions, not just the happy path. Build reusable datasets that work across multiple test cycles. When you need production-like characteristics, apply data masking or anonymisation (see A.8.11). Use consistent masking rules to maintain referential integrity across tables. Verify that masked data cannot be re-identified through cross-referencing. Confirm that the masked data still works for your test scenarios. If actual production data must be used (this should be exceptional and justified): get formal authorisation from the data owner, apply proper access controls to the test environment, log and monitor all access to the test data, limit the volume to the minimum needed, set a hard deadline for secure deletion, and confirm compliance with data protection regulations. Protect test data throughout its lifecycle. Restrict access based on need. Do not leave test data sitting on developer workstations. Securely delete it when testing is complete. Be especially careful with sensitive data in automated testing pipelines. Keep records of test data usage. Document what data is used, where it came from, who has access, and when it will be deleted. For personal data under GDPR, record test data usage in your processing activities register.
Evidence Your Auditor Will Request
- Test data management policy
- Records showing use of synthetic or anonymized test data
- Authorization records for any production data used in testing
- Test data access control and deletion records
- Data masking verification records for anonymized test data
Common Mistakes
- Full production data is copied to test environments without masking
- Personal data is used in testing without authorization or data protection measures
- Test data is not deleted after testing is complete
- No policy governing test data selection and management
- Developers have unrestricted access to production data for testing purposes
Related Controls Across Frameworks
| Framework | Control ID | Relationship |
|---|---|---|
| SOC 2 | CC8.1 | Partial overlap |
| GDPR | Art.5(1)(b) | Related |
| GDPR | Art.25 | Related |
Frequently Asked Questions
Can we use production data for testing under GDPR?
What tools can generate realistic test data?
Track ISO 27001 compliance in one place
AuditFront helps you manage every ISO 27001 control, collect evidence, and stay audit-ready.
Start Free Assessment