ISO 27001 A.8.11 - Data Masking

Requirement

“Data masking shall be used in accordance with the organization’s topic-specific policy on access control and other related topic-specific policies, and business requirements, taking applicable legislation into consideration.”

Plain-language meaning

The organization should hide, replace, tokenize, pseudonymize, or anonymize sensitive data where full visibility is not needed. The goal is to let people or systems use data for legitimate purposes without exposing more sensitive information than necessary.

Data masking is not one technique. It includes temporary masking, pseudonymisation/tokenisation, and anonymisation. The difference is whether the original data still exists and whether it can be recovered.

Why this matters

Sensitive data is often copied into test, analytics, reporting, support, training, and development environments. If full data is visible where it is not needed, the organization increases confidentiality, privacy, fraud, and regulatory risk.

Poor anonymisation is also dangerous. Data that appears anonymous may still be identifiable when combined with other available data.

Implementation guidance

1. Define masking methods

2. Define who can see full data

Roles permitted to view unmasked data should be explicitly defined and linked to business need. Re-combination or re-identification should require authorization, logging, and review.

3. Protect lookup tables and keys

For pseudonymisation/tokenisation, lookup tables, keys, or re-identification mechanisms should be logically and organizationally separated from tokenized data.

4. Manage re-identification risk

Potentially identifiable information should be assessed. Data may not contain names or direct identifiers but may still identify people when combined with location, role, dates, rare attributes, or public information.

5. Delete re-combined data when no longer needed

Where masked or tokenized data is re-combined into full data, that full data should be protected and deleted as soon as the business need ends.

Audit guidance

Auditors should verify:

• masking/anonymisation/pseudonymisation definitions;
• data masking policy or standard;
• business and legal basis for masking decisions;
• roles permitted to view full data;
• re-identification or re-combination process;
• logs/records of re-combination;
• protection and segregation of lookup tables or keys;
• deletion of re-combined data after use;
• assessment of potentially identifiable information;
• demonstrations of masking controls.

Auditors may test whether anonymised data can reasonably be re-identified using other available information.

Evidence examples

Strong evidence

• Masking methods are defined and matched to use cases.
• Roles allowed to view full data are approved.
• Token lookup tables are segregated.
• Re-combination is logged and authorized.
• Potential re-identification is assessed.
• Re-combined data is deleted after use.

Weak evidence

• “Anonymised” data can be re-identified through other fields.
• Lookup table is stored beside tokenized data.
• Developers use production data without masking.
• Full-data access is broad or undefined.
• Re-combination happens without logging.
• Masked exports are retained indefinitely.

Common failures

Exam traps

Related controls and concepts

• A.8 Technological Controls MOC
• A.8.3 Information Access Restriction
• A.8.10 Information Deletion
• A.5.34 Privacy and Protection of PII
• A.5.12 Classification of Information
• A.5.13 Labelling of Information
• A.5.15 Access Control
• PII Inventory and Privacy Requirements Matrix
• Information Classification and Handling Matrix
• Data Masking Standard
• Data Masking Decision Register
• Re-Identification Risk Assessment
• A.8.11 Audit Evidence Pack
• A.8.11 Audit Checklist

KB-ready summary

• Define masking, pseudonymisation/tokenisation, and anonymisation.
• Match masking method to business need and legal requirement.
• Restrict and log access to full data.
• Segregate lookup tables and keys.
• Test whether supposedly anonymous data can be re-identified.

Templates and checklists

• Data Masking Standard
• Data Masking Decision Register
• Re-Identification Risk Assessment
• A.8.11 Audit Checklist