ISO 27001 Annex A 8.11 Audit Checklist

The ultimate audit guide to ISO 27001 Annex A 8.11 Data Masking

1. Data Masking Policy Formalisation Verified

Verification Criteria: A documented policy exists defining the requirements for data masking, including the specific datasets, roles authorised to view unmasked data, and approved technical methods.

Required Evidence: Approved Information Classification and Handling Policy or a dedicated Data Masking Standard.

Pass/Fail Test: If the organisation cannot produce a formal document specifying when and how data should be masked, mark as Non-Compliant.

2. PII Obfuscation in Non-Production Environments Confirmed

Verification Criteria: Personal Identifiable Information (PII) and sensitive business data are masked or anonymised when used in testing, development, or QA environments.

Required Evidence: Database snapshots or screenshots from UAT/Dev environments showing masked fields (e.g., “j***@example.com” or “XXXX-XXXX-XXXX-1234”).

Pass/Fail Test: If a developer or tester has access to unmasked production PII in a non-production environment, mark as Non-Compliant.

3. Role-Based Access to Unmasked Data Validated

Verification Criteria: Technical access controls ensure that only specific authorised roles have the ability to toggle or view unmasked sensitive data.

Required Evidence: Application permission matrix or IAM role configurations showing restricted access to “View Unmasked Data” privileges.

Pass/Fail Test: If standard support or administrative roles can view full sensitive fields (e.g., full credit card numbers) without a verified business “need-to-know”, mark as Non-Compliant.

4. Dynamic Data Masking (DDM) Implementation Verified

Verification Criteria: Real-time masking is applied to data in transit or at the presentation layer to prevent exposure to unauthorised users.

Required Evidence: SQL Server, Oracle, or SaaS application configuration logs showing active Dynamic Data Masking rules on sensitive columns.

Pass/Fail Test: If the application displays sensitive data in plain text to unauthorised users before a masking rule is applied at the UI level, mark as Non-Compliant.

5. Pseudonymisation Integrity and Key Protection Confirmed

Verification Criteria: Where pseudonymisation is used, the “key” or mapping table that allows re-identification is stored separately and secured with restricted access.

Required Evidence: Architectural diagram showing segregation of mapping tables and restricted ACLs/logs for the mapping database.

Pass/Fail Test: If the pseudonymised data and the re-identification keys are stored in the same database or accessible by the same user role, mark as Non-Compliant.

6. Anonymisation Irreversibility Validated

Verification Criteria: Data intended to be anonymised is processed such that individuals cannot be re-identified through “linkage attacks” or combined datasets.

Required Evidence: Technical assessment or “k-anonymity” report proving that individuals cannot be singulated within the dataset.

Pass/Fail Test: If a third party could reasonably re-identify an individual by combining the “anonymised” data with other public information, mark as Non-Compliant.

7. Masking Tool and Algorithm Strength Verified

Verification Criteria: The organisation utilises industry-standard masking algorithms (e.g., Format Preserving Encryption) rather than weak or proprietary methods.

Required Evidence: Technical specifications of the masking tool (e.g., Informatica, Delphix, or native cloud tools) and configuration of the hashing/masking algorithm.

Pass/Fail Test: If the organisation uses reversible “Base64” encoding or simple ROT13 as a “masking” technique for sensitive data, mark as Non-Compliant.

8. Audit Logging of Unmasking Events Confirmed

Verification Criteria: Every instance of a user viewing unmasked data or an administrator changing masking rules is recorded in an immutable audit log.

Required Evidence: SIEM logs or application audit trails showing “Data Unmasked” events with associated User IDs and timestamps.

Pass/Fail Test: If a privileged user can view unmasked data without a corresponding entry being generated in the security audit logs, mark as Non-Compliant.

9. Customer Service Screen Redaction Verified

Verification Criteria: UI elements used by customer-facing staff automatically redact sensitive fields unless specific verification steps are completed.

Required Evidence: Visual demonstration of the CRM or ERP system showing redaction of sensitive fields during a standard session.

Pass/Fail Test: If sensitive data is visible on-screen to employees while they are in public-facing environments or shared workspaces, mark as Non-Compliant.

10. Periodic Masking Effectiveness Reviews Recorded

Verification Criteria: Management or Security teams perform regular checks to ensure that masking rules remain effective after system updates or schema changes.

Required Evidence: Quarterly Vulnerability Assessment reports or Internal Audit logs specifically testing for data exposure in masked fields.

Pass/Fail Test: If a database schema change has occurred but the masking rules were not re-validated to ensure continued coverage, mark as Non-Compliant.

About the author