Data Masking and Anonymisation: What GDPR and ISO 27001 Actually Require

Neither GDPR nor ISO 27001 contains a sentence that says “you must mask your data.” Yet a regulator can fine you for not doing it, and an auditor can raise a nonconformity if you skip it. That gap, between what the frameworks literally say and what they functionally demand, is where most compliance teams come unstuck. This article sets out what each framework actually requires, where the two overlap, where they diverge, and how to build a masking programme that satisfies both without duplicating effort.

Understanding the Regulatory Landscape for Data Masking

GDPR and ISO 27001 exist for different reasons, and that difference shapes everything that follows. GDPR is law. It is a binding regulation with extraterritorial reach, enforced by data protection authorities that can issue fines of up to 4% of global annual turnover. ISO 27001 is a voluntary management-system standard. No organisation is legally compelled to certify against it, and an auditor cannot fine you, only withhold or withdraw a certificate.

The two get conflated because they describe the same activities using overlapping vocabulary. Both care about confidentiality. Both reference pseudonymisation. Both expect a risk-based approach. But GDPR is concerned with the rights of the individuals whose data you hold, while ISO 27001 is concerned with whether your information security management system functions as designed. A single control can satisfy one framework and not the other.

On the GDPR side, the provisions that bear on masking are Article 5 (the data minimisation and the integrity-and-confidentiality principles), Article 25 (data protection by design and by default), Article 32 (security of processing), and the Article 4(5) definition of pseudonymisation. Recital 26 draws the boundary of the regulation itself by explaining when data is genuinely anonymous and therefore out of scope. On the ISO side, the relevant control is Annex A 8.11, Data masking, introduced in the 2022 revision of the standard. It is the first time data masking has appeared as a named, formal control in ISO 27001, even though older standards such as PCI DSS have treated it as core for decades.

What GDPR Actually Requires Regarding Data Masking and Anonymisation

Does GDPR Mandate Data Masking? The Honest Answer

No. The phrase data masking does not appear in the GDPR at all. What the regulation does is name pseudonymisation and encryption, in Article 32(1)(a), as examples of appropriate technical measures. The wording is doing real work here: the list is introduced with “inter alia as appropriate,” which means these measures are illustrative, not compulsory in every case. GDPR does not order you to mask. It orders you to secure, and then leaves you to justify how you did it.

Article 32 and the “Appropriate Technical Measures” Standard

Article 32 requires controllers and processors to implement measures that ensure a level of security appropriate to the risk, taking into account the state of the art, the cost of implementation, and the nature, scope, context, and purposes of processing. There is no checklist. The standard is deliberately elastic so the same sentence can govern a national hospital and a corner shop.

Elastic does not mean lenient. Article 32 is the provision cited most often in breach enforcement. When a breach happens, the first question a regulator asks is whether the security measures were appropriate. If they were, the breach is misfortune. If they were not, it is negligence, and the inadequacy is sanctioned separately from the breach itself. The UK Information Commissioner’s Office guidance on data security is explicit that pseudonymisation is one of the example measures organisations are expected to weigh.

Pseudonymisation and Anonymisation Under GDPR

Pseudonymisation is defined in Article 4(5): processing personal data so it can no longer be attributed to a specific person without additional information, provided that additional information is kept separately and protected. The crucial point, stated in Recital 26 and reaffirmed in the EDPB’s Guidelines 01/2025 on pseudonymisation, is that pseudonymised data remains personal data. It stays fully within the scope of GDPR. Pseudonymisation reduces risk; it does not remove the obligation.

Anonymisation is different in kind. Recital 26 states that the regulation does not apply to data rendered anonymous in such a way that the data subject is no longer identifiable. Truly anonymous data falls outside GDPR entirely. But the bar is far higher than most organisations assume. The test, drawn from the former Article 29 Working Party’s Opinion 05/2014, asks whether anyone can still single out an individual, link records across datasets, or infer information about a person. If any of those remains reasonably possible, the data is not anonymous. It is pseudonymous, and GDPR still applies.

Why GDPR Punishes Weak Justifications Even Without Prescribing Controls

Because Article 32 has no checklist, the obligation is not “use control X” but “be able to defend the controls you chose.” Regulators have repeatedly penalised organisations not for the absence of a specific tool, but for the absence of a documented, risk-based rationale. If you process special category data in a test environment using live records and cannot show why you judged that acceptable, the weak justification is itself the finding. The accountability principle in Article 5(2) means the burden of proof sits with you.

What ISO 27001 Actually Requires Regarding Data Masking

Annex A 8.11 Explained: Purpose, Scope and Ownership

Control 8.11 states its purpose plainly: to limit the exposure of sensitive data, including PII, and to comply with legal, statutory, regulatory, and contractual requirements. The detailed implementation guidance sits in ISO 27002:2022, which an auditor uses as the reference for what “good” looks like. The control expects masking to be applied in line with the organisation’s topic-specific policies on access control, and it expects the decision about what to mask to be driven by data use, not just data type. A field is masked because a particular user in a particular context does not need to see it, not simply because it is classified as sensitive.

Is Data Masking Mandatory for ISO 27001 Certification?

Not automatically. Annex A controls are not blanket requirements. The mechanism that decides which controls apply is the Statement of Applicability (SoA). An organisation runs a risk assessment, decides which Annex A controls are relevant, and records in the SoA why each control is included or excluded.

In practice, excluding 8.11 is hard to defend. Almost every organisation holds sensitive data, and almost every organisation has at least one context, a test environment, a support desk, an analytics pipeline, where that data is exposed to people who do not need to see all of it. An auditor will accept a justified exclusion. They will not accept an exclusion that exists because masking was inconvenient.

What Auditors Actually Look for Under Control 8.11

Auditors look for evidence, not intentions. They want a documented data masking policy, proof that it is applied across both production and non-production environments, and a defensible record of exceptions: where unmasked data is used, who approved it, and why. They want the masking policy linked to the access control and information classification policies rather than floating on its own. A policy that exists only on paper, with no configuration or logs behind it, produces a nonconformity.

How ISO 27001:2022 Differs from the 2013 Version on Data Masking

The 2013 version of ISO 27001 had no data masking control at all. The 2022 revision restructured Annex A from 114 controls into 93, grouped under four themes, and introduced 11 new controls. Data masking, 8.11, is one of them, sitting in the Technological theme alongside new controls such as data leakage prevention and information deletion. Its inclusion reflects how far privacy expectations moved between 2013 and 2022, and it brings ISO into line with frameworks where masking has long been standard practice.

Pseudonymisation vs Anonymisation vs Data Masking: The Distinctions That Matter

These three terms are used interchangeably in conversation and should never be used interchangeably in a compliance document. Data masking is the broad umbrella: any technique that replaces, obscures, or removes sensitive values while keeping data usable. Pseudonymisation is a specific, GDPR-defined form of masking in which re-identification remains possible through separately held information. Anonymisation is the irreversible end state, where re-identification is no longer reasonably possible by anyone.

The difference between pseudonymisation and anonymisation is not academic. It is the difference between data that is regulated and data that is not. Misclassify pseudonymised data as anonymous and you have built your processing on the assumption that GDPR does not apply to data that it very clearly does. Every data subject right, every lawful-basis requirement, every breach-notification duty still attaches. As the Spanish data protection authority notes on anonymisation and pseudonymisation, data is only outside GDPR scope when it is objectively impossible to associate it with a person, directly or indirectly, including through datasets available to third parties.

Worth Knowing:  The EDPB’s 2025 guidelines introduced the concept of a “pseudonymisation domain”: the environment within which only pseudonymised data is processed and no one holds the information needed to re-identify. The status of the data can change at the boundary of that domain. A live question, currently before the Court of Justice of the EU, is whether masked data shared with a processor that cannot re-identify anyone counts as personal or anonymous in that processor’s hands. Until it is resolved, treat shared pseudonymised data as personal data.

Does encryption count as data masking under Annex A 8.11? Partly. ISO 27002 lists encryption among the techniques that support 8.11, but encryption and masking solve different problems. Encrypted data is fully recoverable with the key and is typically unreadable to everyone without it. Masking is about selective exposure: showing a support agent the last four digits of a card while hiding the rest. Encryption protects data at rest and in transit; masking governs what an authorised user sees. Under GDPR, encryption is named alongside pseudonymisation in Article 32, but it is not a substitute for it, and it is certainly not anonymisation.

Data Masking Techniques and When Each Is Required

Neither framework prescribes a specific technique. Both expect the technique to match the risk. Four approaches cover most situations.

Static data masking permanently replaces sensitive values in a copy of a dataset. The masked copy is realistic but fictitious, and the original values cannot be recovered from it. This is the standard approach for non-production environments: development, testing, training, and analytics. Because the transformation is irreversible and applied before the data leaves production, it removes the risk at source.

Dynamic data masking masks values in real time, at query, based on the user’s role. The underlying data is untouched; what changes is what each user sees. A support agent sees a masked card number while a fraud analyst sees the full one, from the same database. Dynamic masking suits live operational systems where different users have different legitimate needs.

Tokenisation replaces a sensitive value with a non-sensitive token, with the mapping held in a secure vault. It is widely used in payment processing because it can take systems out of PCI DSS audit scope. Under GDPR, tokenisation is generally a form of pseudonymisation: the token can be reversed through the vault, so the data remains personal data.

Cryptographic hashing and irreversible redaction sit at the strict end. A properly salted hash or a hard redaction destroys the original value. These techniques can support anonymisation, but only if reversal is genuinely infeasible. An unsalted hash of a known, finite value set, a list of national ID numbers, for example, is often trivially reversible and counts as pseudonymisation, not anonymisation.

Can production data be used in test environments if it is masked? Yes, and this is one of the strongest practical reasons masking exists. Using raw production data in a test environment is among the most common Article 32 failings and a frequent ISO audit finding. Properly static-masked data resolves it: the test environment gets realistic, structurally valid data, and no real personal data is ever exposed to developers, testers, or contractors.

Where GDPR and ISO 27001 Overlap on Data Masking Obligations

The overlap is real and worth exploiting. ISO 27001 Annex A 8.11 and GDPR Article 32 point in the same direction: limit the exposure of sensitive data through appropriate technical measures, selected on the basis of risk. An organisation that implements 8.11 well is, in substance, doing a large part of what Article 32 expects.

But ISO 27001 certification does not guarantee GDPR compliance, and treating it as if it does is a mistake. ISO 27001 certifies that your information security management system works. GDPR compliance is a legal question about lawful basis, data subject rights, transparency, international transfers, and retention, most of which sit outside the scope of an ISO audit.

The good news is that a single body of evidence serves both frameworks. A data masking policy, a data classification scheme, access control records, masking configuration, and exception logs satisfy an ISO auditor and support an Article 32 defence at the same time. Build the evidence once, use it twice. Where the two frameworks genuinely diverge: ISO 27001 will accept a documented, risk-based exclusion of a control, whereas GDPR does not allow you to exclude individuals’ rights. The frameworks overlap on the security mechanism, not on the legal obligation behind it.

Implementing Data Masking to Satisfy Both GDPR and ISO 27001

A programme that serves both frameworks follows a recognisable path.

Step 1: Identify and classify the data. You cannot mask what you have not found. Map where personal and special category data lives, including the copies in test systems, backups, and analytics stores, and classify it so masking decisions follow classification rather than guesswork.

Step 2: Formalise the policy. Write a data masking policy that names the techniques, the environments they apply to, the roles permitted to access unmasked data, and the exception process. Link it to your access control and classification policies so it is not an orphan document. This single policy is the spine of both your SoA evidence and your Article 32 file.

Step 3: Implement static masking for non-production environments. Every environment that does not need real data, development, test, training, should run on statically masked data. This closes the single most common gap in both frameworks.

Step 4: Deploy dynamic masking for operational access. In live systems, mask at query time by role, so operational staff see only what their task genuinely requires.

Step 5: Restrict access through granular IAM controls. Masking and access control reinforce each other. Define who may see unmasked data, enforce least privilege, and require documented approval for exceptions.

Step 6: Establish centralised logging, monitoring and audit trails. Log access to unmasked data, masking policy changes, and exception approvals. Auditors ask for this evidence directly, and after a breach it is what demonstrates your measures were operating, not merely documented.

Common Mistakes Organisations Make With Data Masking Compliance

The first mistake is treating masking as optional because neither framework names it as mandatory. The logic is technically correct and practically wrong. Both frameworks make masking effectively unavoidable for anyone holding sensitive data and running non-production environments.

The second is confusing encryption with anonymisation. Encrypted data is recoverable and remains personal data; anonymised data is not. A team that encrypts a test database and calls it anonymised has not taken that data out of GDPR scope.

The third is applying masking inconsistently. Masking the customer table but not the linked orders table, or masking the test environment but not the analytics copy, leaves real data exposed through the gap. Auditors and regulators both look for consistency across systems.

The fourth is failing to document the risk-based justification. Both frameworks rest on the idea that you choose controls deliberately and can explain the choice. A masking programme with no written rationale for what is masked, what is not, and why, fails the test even when the technical implementation is sound.

Sector-Specific Considerations for Data Masking Compliance

Financial services carry the heaviest overlay. Beyond GDPR and ISO 27001, payment data falls under PCI DSS, which has required masking, showing only the first six and last four digits of a card number, for years. Financial regulators also expect tight control over who can see account and transaction data, which makes dynamic masking by role close to a baseline expectation rather than an enhancement.

Healthcare handles special category data under Article 9, which raises the bar on every security decision. Patient records used for research, system testing, or secondary analysis should be masked or properly pseudonymised, and the EDPB’s pseudonymisation guidance leans on medical-data examples precisely because the sector’s re-identification risk is high. The smaller the population in a dataset, the easier re-identification becomes, which makes genuine anonymisation harder than it looks.

E-commerce and retail face the challenge of scale. Large customer bases, high transaction volumes, and sprawling pipelines feeding marketing, analytics, and support mean sensitive data is copied widely. The practical answer is to mask early and consistently: statically masked data in every non-production pipeline, dynamic masking in customer-facing tools, so that growth in data volume does not quietly become growth in exposure.