We live in a world where data is the new oil, but unlike oil, you can’t just store it in a barrel and forget about it. If you are handling Personal Identifiable Information (PII), financial records, or sensitive health data, you are holding a ticking time bomb. One wrong move, one exposed database, and you are facing fines, reputational damage, and a very unhappy auditor.
This is where ISO 27001:2022 Annex A 8.11 comes in. It is the control dedicated to Data Masking. It sounds technical, perhaps even a bit spy-like, but in reality, it is a straightforward concept: if people don’t need to see the data, hide it from them.
Table of contents
What is Annex A 8.11?
In the official standard, this control is listed under the “Technological Controls” category. Its purpose is to limit the exposure of sensitive data by masking it in accordance with the organisation’s access control policy. Essentially, it acts as a second layer of defence. Even if someone has access to a system, do they really need to see the full credit card number? Probably not.
Step 1: Know Your Data (Classification)
You cannot mask what you don’t know exists. Before you buy expensive tools or write complex scripts, you need to look at your data inventory. This links directly back to Annex A 5.12 (Classification of Information).
You need to identify which data fields are sensitive. This usually includes:
- PII: Names, addresses, National Insurance/Social Security numbers.
- Financial Data: Credit card numbers (PAN), bank account details.
- Health Data: Medical records, patient IDs.
- Authentication Data: Passwords (which should technically be hashed, a form of masking).
Step 2: Define Your Rules (The Policy)
Once you know what to mask, you need to decide who gets to see the unmasked version. This is not a decision for the IT guy to make on a Tuesday afternoon; it’s a business decision.
You need to create a Data Masking Policy (often part of your Access Control Policy). This document should outline:
- Which roles can see raw data (e.g., Senior Payroll Officers).
- Which roles see masked data (e.g., Customer Support Agents seeing “************1234”).
- Which techniques you will use (more on that in a moment).
If you are struggling to write this from scratch, Hightable.io offers comprehensive ISO 27001 toolkits that include topic-specific policy templates for data masking. Using a pre-written structure can ensure you don’t miss the specific requirements an auditor looks for.
Step 3: Choose Your Weapon (Masking Techniques)
Not all masking is created equal. Depending on your needs, you will choose different methods. The standard broadly groups these into a few categories:
1. Anonymisation
This is the nuclear option. You strip the data of all identifiers so that the individual can never be re-identified. This is great for creating datasets for marketing analysis or selling aggregate data, but useless if you need to actually process a specific customer’s order.
2. Pseudonymisation
Here, you replace the identifying data with a pseudonym (like a code or token). The key difference is that it can be reversed if you have the “key.” This is perfect for internal processes where you want to protect data from general staff but still need to link records in the background.
3. Dynamic Data Masking
This happens in real-time. The data sits in your database fully readable, but when a user queries it, the system checks their permissions and masks the result on the fly. For example, a call centre agent screens might show “Hello, Mr S****h” instead of “Smith”.
4. Static Data Masking
This is crucial for non-production environments. You take a copy of your live database, scrub it clean by permanently masking sensitive fields, and then move it to your test or development environment. Never use live PII in a test environment. It is one of the fastest ways to fail an audit.
Step 4: Implement the Controls
Now you put the technology in place. This might involve:
- Database Features: Many modern databases (like SQL Server or Oracle) have built-in dynamic masking features you just need to turn on.
- Application Logic: Coding your web apps to replace characters with asterisks before displaying them on the screen.
- Tokenisation Services: Using third-party services to replace sensitive data (like credit card numbers) with non-sensitive tokens.
Step 5: Log and Monitor
Just like with every other control in ISO 27001, if you didn’t log it, it didn’t happen. You should monitor access to unmasked data. If a user who normally looks at 10 records a day suddenly views 5,000 unmasked records, your monitoring system (Annex A 8.16) should be screaming at you.
DO IT YOURSELF
STOP SPANKING £10,000s on CONSULTANTS and ISMS ONLINE PLATFORMS
Common Pitfalls to Avoid
- Over-masking: If you mask everything, your staff can’t do their jobs. If a delivery driver can’t see the address, the package doesn’t get delivered. Balance security with utility.
- Weak Algorithms: Don’t just “scramble” letters randomly if it can be easily reversed. Using “Base64 encoding” is not masking; it’s just wearing a fake moustache.
- Ignoring Unstructured Data: It’s easy to mask a database column. It’s much harder to mask a PDF scanned document or a free-text notes field where a user typed a credit card number. Train your staff not to put sensitive data in unstructured fields.
What Will the Auditor Look For?
When the audit day arrives, be prepared to show:
- Your Policy: A document defining your masking rules.
- Evidence of Implementation: Show them a screen where data is masked for a standard user.
- Test Records: Proof that you periodically check if the masking is working.
- Access Reviews: Evidence that you check who has the right to see unmasked data.
Conclusion
Implementing ISO 27001 Annex A 8.11 isn’t just about ticking a compliance box. It’s about minimizing the blast radius of a breach. If a hacker gets into a database where everything is masked or tokenized, they steal useless gibberish instead of your customers’ lives.
Start small, focus on your most toxic data first, and ensure you have the documentation to back it up. If the paperwork feels overwhelming, remember that resources like Hightable.io exist to help you structure your compliance journey effectively.
About the author
Stuart Barker is a veteran practitioner with over 30 years of experience in systems security and risk management.
Holding an MSc in Software and Systems Security, Stuart combines academic rigor with extensive operational experience. His background includes over a decade leading Data Governance for General Electric (GE) across Europe, as well as founding and exiting a successful cyber security consultancy.
As a qualified ISO 27001 Lead Auditor and Lead Implementer, Stuart possesses distinct insight into the specific evidence standards required by certification bodies. He has successfully guided hundreds of organizations – from high-growth technology startups to enterprise financial institutions – through the audit lifecycle.
His toolkits represents the distillation of that field experience into a standardised framework. They move beyond theoretical compliance, providing a pragmatic, auditor-verified methodology designed to satisfy ISO/IEC 27001:2022 while minimising operational friction.
