Data masking
Purpose
Use data masking to limit exposure of sensitive data including PII and meet legal and contractual requirements.
How to meet this control
In short: Use data masking per policy and business requirements.
- Step 01Identify the sensitive fields, especially PII, that require masking and record the rule applied to each
- Step 02Apply dynamic data masking in the database or application so users see only the minimum data their role needs, for example masked card numbers or partial identifiers
- Step 03Generate masked or synthetic copies when refreshing non-production environments so test and development never hold raw production PII
- Step 04Use pseudonymisation or hashing with salting where data must be linked but not directly identifying, and verify re-identification is not feasible
- Step 05Tie masking rules to the access control policy so unmasking requires explicit authorisation and is logged
- Step 06Review masking coverage when new sensitive datasets or fields are introduced
Tip: Mask/tokenise sensitive fields in non-production environments.
What ISO 27002 says to cover
Reference points from the ISO/IEC 27002:2022 guidance for this control. Use them to check the steps above cover everything relevant to you.
- ›Apply masking in line with the access control policy and applicable legislation
- ›Use masking, pseudonymisation or anonymisation to hide or disconnect PII from identities
- ›Verify that anonymised data cannot be re-identified through other available data
- ›Apply techniques such as encryption, nulling characters, substitution or hashing
- ›Design queries and masks to show users only the minimum data they need
- ›Allow record-level obfuscation so certain entries can be hidden from specific roles
- ›Consider masking strength, access controls on processed data, and usage agreements
- ›Prohibit re-combining masked data to re-identify individuals and always salt hashes
Audit evidence to keep
- - Inventory of sensitive fields with the masking technique applied to each
- - Dynamic data masking configuration in the database or application
- - Evidence that non-production environments use masked or synthetic data
- - Access control and logging showing who can view unmasked data
- - Re-identification risk assessment for anonymised datasets
Common mistakes
- - Writing a policy but not operating the process
- - Keeping evidence in personal folders where auditors cannot trace it
- - Letting exceptions stay open with no owner or expiry date
Owner, cadence, and proof
Assign one accountable owner for A.8.11. Review this control at least annually, after related incidents, and whenever the underlying process, supplier, system, office, or legal obligation changes. The control is audit-ready when the owner can show the policy or procedure, the latest operating evidence, the latest review, and any open exceptions with due dates.
Policy templates for this control
Use these starting documents to turn the control into evidence. Adapt each template to your scope, systems, legal obligations and actual operating process.