Control 8.11 asks you to hide data so that exposure of sensitive information is limited. It is new in ISO 27001:2022. Decide which data is sensitive, which categories must be masked, who may see masked and unmasked values, and which technique you will use.
What the control expects
The guidance lists five things to do:
- Determine which data is sensitive and which categories need masking.
- Define who may access masked or unmasked data.
- Define the masking technology.
- Set up a process for choosing what to mask and how.
- Make staff aware of why masking is needed, and train them.
Techniques
The guidance names pseudonymisation or anonymisation tools where privacy or other regulations call for masking, encryption, and obfuscation. They differ in what you can recover afterwards:
- Pseudonymisation replaces identifiers but can be reversed with extra information held separately.
- Anonymisation aims to be irreversible.
- Encryption protects data but the data is real once decrypted.
- Obfuscation hides parts of a value, such as showing the last four characters.
Pick by purpose. Support staff may need partial values. A test database may need realistic but fake values.
Where teams meet this control
- Test and staging environments loaded with production copies.
- Support tools that show full customer records.
- Analytics exports.
- Logs that capture request bodies.
The simplest win is to stop copying production data into test. If you must, mask it as part of the copy job and record that the job ran.
Policies that support it
Documents are recommended, not mandatory. The guidance ties masking to an information classification policy, which names sensitive data, an access control policy, which sets who sees what, and a secure development policy, which defines the masking technology. Privacy or pseudonymisation policies can also hold the process.
What the auditor checks
Whether data masking is used in line with your policies, business requirements and applicable law. Bring the classification scheme, a description of what is masked where, role access settings, and a sample of a masked dataset.
A caution on law
Whether a given technique counts as anonymisation under a privacy law is a legal question. Ask your privacy adviser before you describe masked data as anonymous in a customer document.
A starting checklist
- List every environment that holds copies of production data.
- Mark which of them contain personal or confidential values.
- For each, choose remove, mask or keep with restricted access.
- Document the choice and the owner.
- Add a check to the copy job so unmasked data cannot land in test by accident.
Step five is the one that keeps the control working after the first review.
Quick check
Is encryption the same as masking?
The guidance lists encryption as one technique. But encrypted data is real data once decrypted, so masking for test or support use often needs obfuscation or pseudonymisation instead.
Can we exclude this control?
Only with a risk based reason in your Statement of Applicability. Most teams that handle personal data in test or support tools find it applies.
Sources
Last reviewed: 19 October 2026.
