Implementing ISO 27001 Annex A 8.11 is a critical privacy control that involves data masking, pseudonymization, and obfuscation techniques to limit PII exposure. By applying Dynamic Data Masking (DDM) at the database layer and sanitizing API responses, organizations ensure confidentiality and minimize the risk of unauthorized data disclosure during processing or testing.
ISO 27001 Annex A Data Masking Implementation Checklist
Use this implementation checklist to achieve compliance with ISO 27001 Annex A 8.11. Data masking is a technical control enforced at the database and application layer, not a promise made in a privacy policy document.
1. Perform Column-Level PII Discovery
Control Requirement: Identify sensitive data that requires masking in accordance with legal and business requirements.
Required Implementation Step: Run a schema scan script on your production databases to identify columns containing PII (e.g., SocialSecurityNumber, CreditCard, EmailAddress). Create a technical register mapping specific database tables and columns to their required masking logic (e.g., “Show last 4 digits only”).
Minimum Requirement: You cannot mask what you have not technically located; manual guessing is insufficient.
2. Implement Dynamic Data Masking (DDM) at the Database Layer
Control Requirement: Limit the exposure of sensitive data to authorised users only.
Required Implementation Step: Apply masking rules directly in the SQL engine (e.g., MS SQL Server MASKED WITH (FUNCTION = 'partial(2, "X", 2)')). This ensures that even if the application logic fails, a standard SELECT * query returns masked data to the DBA or support engineer.
Minimum Requirement: Masking must exist at the data source, not just the user interface.
3. Enforce Static Data Masking (SDM) for Non-Production Environments
Control Requirement: Protect production data used in test and development systems.
Required Implementation Step: Configure your ETL (Extract, Transform, Load) pipelines to irreversibly scramble or pseudonymise data before it lands in a Dev, Test, or Staging environment. Developers must never have access to live, unmasked customer PII for testing purposes.
Minimum Requirement: Production data in a Dev environment is a major non-conformity.
4. Configure Application-Layer Obfuscation
Control Requirement: Present data in a way that minimises risk of visual shoulder-surfing.
Required Implementation Step: Update front-end code to render sensitive fields with asterisk characters (e.g., ****-****-****-1234) by default. Ensure the “Show Password/Data” toggle is disabled or requires a specific re-authentication event (Step-Up Auth) to activate.
Minimum Requirement: Default views must always be masked.
5. Sanitise API JSON Responses
Control Requirement: Prevent data leakage through backend calls.
Required Implementation Step: Inspect the raw JSON payloads sent by your API. Often, the UI masks the data, but the browser “Network” tab reveals the full unmasked string. Filter the API output on the server side to send only the masked values to the client.
Minimum Requirement: The browser client must never receive the raw data if it is not meant to display it.
6. Define Role-Based Unmasking Permissions
Control Requirement: Grant access to unmasked data on a strictly need-to-know basis.
Required Implementation Step: Create a specific Active Directory or Database security group (e.g., Sec_Unmask_Finance). Grant the UNMASK permission only to this group. Review the membership of this group monthly; standard Customer Support agents rarely need full unmasking rights.
Minimum Requirement: “Admin” does not equal “Unrestricted View”; separate these privileges.
7. Implement Pseudonymisation for Analytics
Control Requirement: Enable data analysis without exposing individual identities.
Required Implementation Step: Replace direct identifiers (Names, IDs) with deterministic tokens or hashes (e.g., SHA-256) in data warehouses used by Business Intelligence (BI) teams. This allows analysts to track trends (e.g., “User A bought Item B”) without knowing who User A is.
Minimum Requirement: Data Scientists should not require raw PII to build models.
8. Configure “Unmasking” Audit Logs
Control Requirement: Monitor and investigate access to revealed data.
Required Implementation Step: Configure your SIEM or database audit logs to trigger an event specifically when the UNMASK command is executed or when a user accesses a clear-text view of a highly sensitive table. Alert on bulk unmasking events (e.g., >50 records).
Minimum Requirement: You must know exactly who viewed the raw credit card number and when.
9. Handle Export and Reporting Output
Control Requirement: Maintain masking controls in downloaded files.
Required Implementation Step: Test the “Export to CSV/Excel” function in your applications. Ensure the export logic respects the user’s masking permissions. A common vulnerability is that the screen shows ****, but the CSV download contains the full number.
Minimum Requirement: Exports must mirror the screen’s masking rules.
10. Validate Irreversibility
Control Requirement: Ensure masked data cannot be easily reversed.
Required Implementation Step: Conduct a specific penetration test or internal review where you attempt to reverse-engineer the masked data (e.g., guessing the credit card number based on the last 4 digits and BIN). Ensure the entropy is sufficient to prevent brute-force re-identification.
Minimum Requirement: Simple Base64 encoding is NOT masking; it must be irreversible or access-controlled.
ISO 27001 Annex A 8.11 SaaS / GRC Platform Implementation Failure Checklist
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| Database Masking (DDM) | GRC tool asks: “Is data masking used?” (Yes/No). | You clicked “Yes” because the UI shows stars. However, the database admin has full SELECT * access to all customer records. |
| Non-Production Data | “We have a policy that says we don’t use live data.” | Developers copied the production DB to the Dev server to “debug an issue” and forgot to delete it. Now your test environment is a breach risk. |
| API Leakage | “The website shows asterisks.” | A hacker presses F12, looks at the Network tab, and sees the full Social Security Number in the JSON response payload. |
| Export Vulnerability | “Reports are secure.” | The “Download CSV” button bypasses the front-end masking logic, delivering a spreadsheet full of raw PII to any junior analyst. |
| Encryption vs Masking | “The database is encrypted at rest.” | Encryption protects the disk drive; Masking protects the screen. If you only encrypt, an authorised user still sees everything. |
| Unmasking Logs | “We log logins.” | You know User A logged in, but you have no record that they unmasked and viewed the passport scans of 50 VIP clients. |
| Third-Party Sharing | “We have a DPA.” | You send an Excel file to a marketing agency via email. You masked the names but left the Email and Phone columns wide open. |
DO IT YOURSELF ISO 27001
STOP SPANKING £10,000s on CONSULTANTS and ISMS ONLINE PLATFORMS
About the author
