How to Use Realistic-Looking Data Without Exposing the Real Thing
ISO 27001 Control 8.11 Data masking is about one simple idea:
People often need to see data to do their jobs – but they don’t always need to see the real data.
Control 8.11 expects you to protect sensitive information (especially personal data) by masking, tokenising or anonymising it, so that only those with a genuine need ever see the original values.
Done well, data masking lets you:
- Use realistic data in testing, training and analytics
- Reduce the risk of data breaches and fraud
- Meet legal and regulatory requirements around PII and confidential data
This guide walks through what ISO 27001 Control 8.11 expects, and how to design practical, usable data masking that doesn’t break your systems.
What ISO 27001 Control 8.11 Actually Requires
In plain English, ISO 27001 Control 8.11 – Data masking expects you to:
- Identify where sensitive data is used in ways that don’t need the “real” values (e.g. test systems, demos, analytics, training, support).
- Apply data masking or pseudonymisation so that those environments don’t expose live data unnecessarily.
- Make sure access to unmasked (real) data is restricted to people and systems that genuinely need it.
- Use masking methods that are appropriate to the data type, risk and business use.
- Ensure masked data can’t be easily reversed or re-identified without proper authorisation.
It’s closely tied to:
- Your data classification
- Access control (who can see unmasked data)
- Privacy and PII protection (e.g. GDPR, PCI DSS, health data)
The aim: minimise exposure of real data wherever possible, especially outside production.
Step 1 – Decide When ISO 27001 Data Masking Should Apply
Start by identifying where you currently use real data but don’t strictly need it.
Typical candidates for ISO 27001 Control 8.11:
- Test and development environments
– Dev teams using production database copies for troubleshooting or testing.
– QA teams running performance or integration tests. - Training and demos
– Screens or systems used to show processes to new staff, customers or partners.
– Demo tenants or “sandbox” environments. - Analytics and reporting
– BI and data warehouse environments where analysts don’t need named individuals.
– External or partner reporting where aggregated or masked data would do. - Support and operations
– Customer service tools where agents only need partial details (e.g. last 4 digits).
For each case, ask:
- Do users really need the exact, identifiable data?
- Could they do the job just as well with masked or pseudonymised values?
Anywhere the answer to (2) is “yes” is a prime candidate for ISO 27001 Control 8.11 data masking.
Step 2 – Build Data Masking into Your Access and Classification Model
Data masking under ISO 27001 Control 8.11 should sit on top of data classification and access control, not replace them.
You should:
- Classify sensitive data
– Identify which fields and data sets contain PII, financial data, credentials, health data, confidential business data, etc.
– Mark those as requiring masking in non-production by default. - Tie masking to roles
– Only certain roles should ever see unmasked data (e.g. limited production support, privacy office, specific business owners).
– Everyone else sees masked or pseudonymised values by default. - Align with RBAC
– Link “can see unmasked data” to specific roles and permissions.
– Ensure access reviews explicitly check who can see unmasked data. - Define de-masking rules
– When is it acceptable to unmask data?
– Who can approve it and how is it logged?
ISO 27001 Control 8.11 is much easier to demonstrate if you can show a clear relationship between classification → masking → who sees what.
Step 3 – Choose the Right Data Masking Techniques
Different scenarios need different techniques. You’ll probably use a mix.
Common options for ISO 27001 Control 8.11:
- Redaction / nulling
– Completely blank or hide values (e.g. show “********” for passwords).
– Good when you don’t need any value at all, just the fact something exists. - Partial masking
– Show only part of the value, e.g.:- “•••• •••• •••• 1234” for card numbers
- “J*** D**” for names
– Useful for customer support and identity verification.
- Data substitution
– Replace real values with fake but realistic ones (e.g. names, addresses, phone numbers).
– Great for test environments where format and realism matter. - Number/date variation
– Shift dates, add/subtract ranges from amounts, or band figures while keeping logical relationships.
– Useful for analytics and reporting where exact values aren’t needed. - Tokenisation
– Replace the real value with a token; store the mapping securely elsewhere.
– Common for cardholder data and other high-risk identifiers. - Hashing
– One-way transform (e.g. hashing an ID or email) for matching and uniqueness without revealing the original value.
– Suitable where you need to detect duplicates or joins but not see the real field. - Encryption (with controlled decryption)
– Not strictly “masking” by itself, but can support masking behaviour if decryption is restricted to certain roles or systems.
The key for ISO 27001 Control 8.11: for each data type and use case, you can explain what masking technique you use, and why it’s appropriate.
Step 4 – Protect PII Through Masking, Pseudonymisation and Anonymisation
For personal data, ISO 27001 Control 8.11 aligns strongly with privacy laws like GDPR.
Good practice includes:
- Use pseudonymisation by default for non-production
– Replace direct identifiers (names, emails, IDs) with pseudonyms or tokens.
– Store the mapping in a tightly controlled, separate system. - Consider indirect identifiers
– Combination of fields (postcode + date of birth + gender) can still identify a person.
– Mask or band these too (e.g. age ranges, regional areas rather than exact postcodes). - Only keep what you need
– If a use case doesn’t genuinely require individual-level data, use fully anonymised, aggregated or synthetic data instead. - Monitor re-identification risk
– Periodically test whether your masked data could be linked back to individuals using other datasets or simple guesswork. - Restrict access to real PII
– Make access to unmasked PII a conscious exception, not the default.
For an auditor, evidence that you’re using data masking to reduce the spread of PII across environments is a strong demonstration of ISO 27001 Control 8.11 in action.
Step 5 – Implement Data Masking in Enterprise Systems
ISO 27001 Control 8.11 expects masking to be systematically applied, not manual and ad hoc.
Practical steps:
- Databases and data warehouses
– Use built-in masking or views to present masked data to non-privileged accounts.
– Apply masking rules to key columns (names, IDs, contact details, financials). - Applications and APIs
– Implement masking at the application layer for UI and API responses, based on role/permissions.
– Make sure logs don’t undo your good work by storing unmasked values. - Test and dev environments
– Mask data before it leaves production – e.g. masked export or ETL job.
– Don’t allow raw production database copies to be used in lower environments. - Cloud and SaaS
– Use provider tools and features for field-level masking where available.
– Ensure masked data is used in lower environments and shared tenants. - Unstructured data
– Consider tools or patterns for masking sensitive data in documents, reports and logs (e.g. redaction, pattern-based masking for card numbers or IDs).
You want to get to a point where data masking under ISO 27001 Control 8.11 is built into the way systems are designed and deployed, not a bolt-on added later.
Step 6 – Compliance and Industry-Specific Requirements
Data masking is often specifically referenced or implied in other standards and regulations. ISO 27001 Control 8.11 will commonly support:
- PCI DSS
– Masking PANs (card numbers) when displayed; limiting access to full unmasked data. - GDPR and other privacy laws
– Pseudonymisation and minimisation of personal data in non-production and analytics environments. - Sector-specific rules
– Health data (e.g. patient identifiers), financial transaction data, children’s data, etc.
To keep ISO 27001 Control 8.11 on the right side of compliance:
- Map which masking rules support which regulatory requirements.
- Keep documentation of masking controls for high-risk data (cardholder, health, special-category personal data).
- Make sure masking is included in data protection impact assessments (DPIAs) where relevant.
Step 7 – Monitor, Test and Improve Your Data Masking
Like any control, data masking under ISO 27001 Control 8.11 isn’t “set and forget”.
You should:
- Test masking regularly
– Confirm that users and roles that should see masked data do, and those that must see unmasked data still can.
– Check that masked datasets can’t easily be reversed or re-identified. - Audit access to unmasked data
– Log and review who accesses unmasked fields, especially in non-production or analytics tools.
– Treat suspicious access patterns as potential incidents. - Review rules when systems or regulations change
– New fields, new integrations, new data sources – all may need updated masking.
– Update masking policies when new privacy or industry requirements arise. - Train staff
– Help developers, analysts, and support teams understand:- Why data masking matters
- When they should use masked test data instead of asking for “a copy of production”
- What to do if they see unmasked data where they don’t expect it
This ongoing operation is what convinces an auditor that ISO 27001 Control 8.11 is active and effective, not just something you’ve written in a policy.
Quick Implementation Checklist for ISO 27001 Control 8.11
Use this to assess where you are with data masking:
- ISO 27001 Control 8.11 (Data masking) is covered in a specific policy or standard.
- You’ve identified systems and use cases where real data isn’t actually needed (test, dev, training, analytics).
- Sensitive data fields (especially PII and financial data) are classified and flagged for masking in non-production.
- Appropriate masking techniques (substitution, tokenisation, redaction, partial masking, etc.) are defined for key data types.
- Access to unmasked data is restricted to specific roles, with regular access reviews.
- Test and dev environments use masked or pseudonymised data, not raw production copies.
- Data masking is implemented across databases, applications, APIs and relevant cloud services.
- Masking helps you meet relevant regulatory requirements (PCI, GDPR, sector rules).
- Access to unmasked data is logged and monitored, and masking rules are tested periodically.
- Staff who handle data (dev, test, analytics, support) are trained on when and how to use masked data.
Bringing It All Together
ISO 27001 Control 8.11 – Data masking – is about recognising that the safest data is the data that can’t identify anyone even if it leaks.
If you:
- Know where sensitive data is used outside production,
- Systematically replace it with masked or pseudonymised versions, and
- Strictly limit who can see the real thing,
you’ll dramatically reduce the impact of a breach in test, analytics or shared environments – and you’ll have a clear, credible story to tell an auditor about how you meet ISO 27001 Control 8.11 for data masking.
Explore the ISO 27001 Controls