The ultimate audit guide to ISO 27001 Annex A 8.33 Test Information
Table of contents
- 1. Test Data Policy Formally Documented
- 2. Risk Assessment of Test Environments Verified
- 3. Synthetic Data Default Confirmed
- 4. Formal Authorisation for Production Data Copying
- 5. Data Masking & Anonymisation Enforced
- 6. Test Environment Security Equivalence
- 7. Access Control Restrictions Verified
- 8. Audit Trail of Data Movement Verified
- 9. Secure Data Deletion Validated
- 10. Staff Training on Test Data Risks
1. Test Data Policy Formally Documented
- Verification Criteria: A specific policy (or section within the Secure Development Policy) exists that explicitly prohibits the use of unmasked production data in testing without formal authorization.
- Required Evidence: The “Secure Development Policy” or “Test Data Management Procedure” (Version controlled and approved).
Pass/Fail Test: If the organisation has no written rule regarding the use of live PII in test environments, mark as Non-Compliant.
2. Risk Assessment of Test Environments Verified
- Verification Criteria: The risk assessment explicitly considers threats specific to test environments (e.g., developers having excessive access to PII) rather than just production risks.
- Required Evidence: The “Risk Register” containing a specific entry for “Test/Dev Environment Data Leakage.”
Pass/Fail Test: If the risk register covers “Production DB Breach” but ignores the copy of that DB sitting in the “Staging” environment, mark as Non-Compliant.
3. Synthetic Data Default Confirmed
- Verification Criteria: The default standard for testing is the use of synthetic (dummy) or anonymised data, with production data treated as a strictly controlled exception.
- Required Evidence: Test data generation scripts or a “Data Inventory” showing the distinction between “Synthetic” and “Live” data sets.
Pass/Fail Test: If developers routinely copy the entire live customer database to their laptops for debugging “because it’s easier,” mark as Non-Compliant.
4. Formal Authorisation for Production Data Copying
- Verification Criteria: A traceable authorisation workflow exists for every instance where operational (live) data is copied into a test environment.
- Required Evidence: Jira/ServiceNow tickets titled “Data Refresh Request” showing approval from the Data Owner (not just the developer).
Pass/Fail Test: If the DBA refreshes the Staging environment from Production weekly using an automated script with no approval gate, mark as Non-Compliant.
5. Data Masking & Anonymisation Enforced
- Verification Criteria: Technical controls automatically strip or mask sensitive fields (PII, Credit Cards) during the transfer from production to test.
- Required Evidence: A screenshot of the “Customer Table” in the Test Database showing “Obfuscated” names (e.g., “User_992”) or redacted credit card numbers.
Pass/Fail Test: If you query the “Staging” database and see real customer names and email addresses in plain text, mark as Non-Compliant.
6. Test Environment Security Equivalence
- Verification Criteria: Security controls in the test environment (e.g., encryption, MFA, logging) are equivalent to those in the production environment if sensitive data is present.
- Required Evidence: Configuration settings for the Test Environment showing “Encryption at Rest = Enabled” and “MFA = Enforced.”
Pass/Fail Test: If Production requires MFA but the “Staging” environment (containing the same data) allows single-factor login, mark as Non-Compliant.
7. Access Control Restrictions Verified
- Verification Criteria: Access to test information is restricted based on the principle of least privilege, rather than granting “Admin” rights to all developers.
- Required Evidence: Access Control Lists (ACLs) for the Test Database showing that only assigned testers/developers have access, not the entire IT department.
Pass/Fail Test: If the entire development team shares a single “Root” password for the test database, mark as Non-Compliant.
8. Audit Trail of Data Movement Verified
- Verification Criteria: Logs exist that track the copying, movement, and deletion of operational information into and out of test environments.
- Required Evidence: Database transaction logs or ETL tool logs showing the “Export” and “Import” events with timestamps and user IDs.
Pass/Fail Test: If a snapshot of the production database was copied to a test server yesterday but no log of this event exists, mark as Non-Compliant.
9. Secure Data Deletion Validated
- Verification Criteria: Test data is securely deleted immediately after testing is complete, rather than being stored indefinitely.
- Required Evidence: A “Data Cleanup Schedule” or automated script logs showing the purging of test datasets post-deployment.
Pass/Fail Test: If you find test datasets from projects completed 2 years ago still sitting on the server, mark as Non-Compliant.
10. Staff Training on Test Data Risks
- Verification Criteria: Developers and testers have received specific training on the risks of handling production data in non-secure environments.
- Required Evidence: Training records showing completion of a module on “Secure Development” or “Data Privacy in Testing.”
Pass/Fail Test: If a developer cannot explain why copying live PII to a USB drive for testing is a violation, mark as Non-Compliant.
About the author
