ISO 27001 Annex A 8.33 Audit Checklist

Use this pass/fail checklist to strictly validate compliance with ISO 27001 Annex A 8.33 (Test information). For a detailed methodology on how to conduct the interviews and system tests required to generate this evidence, refer to our Annex A 8.33 Audit Guide.

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.