All 93 controls · Technological controls
Control 8.11
Data masking
What ISO/IEC 27002:2022 control 8.11 asks for, in our own words, with the five published attribute values, the evidence an auditor asks for and the gaps commonly found. ISO/IEC 27028 is the guidance that explains how to use these values.
What the control asks
Data masking is to be applied as directed by the access control policy, related topic policies and what the business needs, with applicable law taken into account. Purpose: reduce how far sensitive data such as PII is exposed, and meet legal, regulatory and contractual obligations. Guidance: where protecting sensitive data such as PII matters, consider concealing it through masking, pseudonymization or anonymization, which can hide PII, obscure who the PII principals really are or other sensitive details, and break the link between the data and the person or other sensitive information. Verify that pseudonymization or anonymization is adequate; anonymization must address every element of the information, since a person can be identified indirectly through remaining data even when direct identifiers are removed. Other masking techniques include encryption with keys held by authorized users, nulling or deleting characters, varying numbers and dates, substituting values, and replacing values with hashes. When implementing masking consider: showing each user only the minimum data needed through designed queries and masks; obfuscating certain records within a data set where parts of the data are to stay hidden, for example allowing only specific roles to see a patient's records when clinically useful; letting PII principals require that users cannot even tell data has been obfuscated; and legal or regulatory requirements such as masking payment card data in processing or storage. When using these techniques consider the strength suited to how the data will be used, access controls on the processed data, agreements or restrictions on its use, prohibiting combining it with other information to re-identify the PII principal, and tracking who provides and receives it. Other information: anonymization irreversibly prevents direct or indirect identification; pseudonymization substitutes an alias, and whoever knows the algorithm or additional information can re-identify to some degree, so that must be kept separate and protected, though pseudonymized data is often more useful for statistics; masking can be static, dynamic or on-the-fly; hashing PII for anonymization should always be salted to resist enumeration; PII should be kept out of identifiers such as file names and URLs or anonymized there; ISO/IEC 27018 and ISO/IEC 20889 give more.
Purpose in the standard’s terms, in our words: Reduces exposure of sensitive data such as PII and supports legal and contractual compliance.
Attribute values in one line: Preventive; Confidentiality; Protect; Information protection; Protection.
The five attribute values
These are the published values for this control, from ISO/IEC 27002:2022 clause 4.2 and Annex A Table A.1. Where your own value differs, record the difference and the reason in the same row rather than replacing the published value.
| Control type | Preventive |
|---|---|
| Information security properties | Confidentiality |
| Cybersecurity concepts | Protect |
| Operational capabilities | Information protection |
| Security domains | Protection |
Evidence an auditor asks for
The attribute is a claim about how the control behaves. The evidence is what proves it operates. Keep both, and keep them together.
- Policy or standard specifying where masking, pseudonymization or anonymization is required, based on access control policy, business needs and law
- Masking configurations in applications, databases and reports showing minimum necessary data displayed per role
- Verification or re-identification risk assessments demonstrating that anonymization or pseudonymization is adequate
- Protection and separation of pseudonymization keys or additional information
- Evidence of legally required masking, for example of payment card numbers in storage and display
- Agreements restricting use of masked or pseudonymized data sets and prohibiting re-identification, with records of who supplied and received them
Where audits commonly find gaps
- Data labelled as anonymized can be re-identified by combining remaining fields
- Hashes of identifiers are unsalted and easily reversed by enumeration
- Pseudonymization keys are stored alongside the pseudonymized data
- Full production data is visible to all users of support and reporting tools
What ISO/IEC 27028 changes for this control
It carries a single control type, preventive, which sets what the evidence has to prove. It contributes no detect function, so a control set built from this row alone would not show detection. It is one of the eleven controls added in the 2022 edition, so a register carried over from the previous edition may have no row for it.
The guidance expands how the five values are used; it does not change the control or add a requirement. A register that carries the values and the evidence can answer the attribute question for this control without a new document. A register that does not can add the columns at the next SoA version, with an owner and a review date.
Controls that share its values
Source for this page
- ISO/IEC 27002:2022, the control catalogue and Table A.1. The reference record of the 93 controls, their five attribute values, purpose, evidence and gaps. The published standard is at https://www.iso.org/standard/75652.html.
- ISO/IEC 27028, official record. Stage 60.00 under publication, edition 1, committee, abstract and the dated lifecycle. Retrieved 20 October 2026.
Retrieved 2026-10-20. The requirement above is our statement of the clause in our own words; the official text is linked so you can check it.
The attribute kit, USD 799 one off. The 109-row register with all five values, the evidence list, a dated plan and the extension worksheet, as PDF, CSV and XLSX.