ICO Anonymisation Guidance: How UK Businesses Can Anonymise Data Under GDPR

If you run a small business, you’ve probably had this moment: you want to use your customer or staff data to improve things (reporting, analytics, product development), but you don’t want to create extra GDPR risk.

That’s exactly where ICO anonymisation guidance comes in. The UK Information Commissioner’s Office (ICO) has published guidance to help organisations understand what “anonymised data” really means, when it’s genuinely outside data protection law, and how to approach anonymisation in a sensible, risk-based way.

In this guide, we’ll walk you through practical steps your business can take to anonymise personal data under the UK GDPR and the Data Protection Act 2018, without getting lost in legal jargon.

Important: This article is general information, not legal advice. If you need advice on your specific situation, get professional advice.

What Does ICO Anonymisation Mean For UK GDPR Compliance?

When people look up ICO anonymisation, they’re usually looking for one thing: clarity on when data stops being “personal data”.

Under the UK GDPR, personal data is information relating to an identified or identifiable individual. If someone can be identified directly (like by name) or indirectly (like by a combination of details), it’s personal data and the UK GDPR applies.

Anonymisation is the process of transforming data so that individuals are not identifiable (and can’t be re-identified) by anyone who is reasonably likely to access the data.

The key practical point from the ICO’s approach is this:

• It’s not enough to remove obvious identifiers (like names and email addresses).
• You need to consider whether someone could re-identify the person using other information (including information they might already have, or could obtain).

If your dataset is truly anonymised, then (in most cases) it will fall outside the UK GDPR because it’s no longer “personal data”. That can be hugely helpful for small businesses doing:

• trend reporting and business intelligence
• data sharing with partners (where appropriate)
• testing and development in a safer way
• longer-term retention for statistical purposes

But there’s a catch: if your “anonymised” data can still be linked back to people, you’re still in GDPR territory (and potentially facing compliance risk you didn’t plan for).

Why Anonymisation Matters (And When It’s Worth Doing)

Anonymisation can be a smart move, but it’s not always necessary and it’s not always easy. From a small business perspective, it’s usually worth considering when you’re trying to balance two competing needs:

• You want to use data to make better decisions (and maybe share insights internally or externally).
• You want to minimise legal risk if that data includes customers, users, or employees.

Common Small Business Use Cases

Here are some scenarios where anonymisation can be especially useful:

• Customer analytics: understanding average spend, product returns, or churn rates without storing identifiable customer records in reporting tools.
• Marketing performance: analysing campaign results without exporting identifiable mailing lists to multiple platforms.
• HR reporting: tracking absence trends, staff turnover, or training outcomes without circulating identifiable HR data internally.
• Product testing: using anonymised datasets in dev/test environments rather than copying live production data.

Why This Helps Your GDPR Position

When done properly, anonymisation can reduce:

• your exposure if data is accidentally disclosed
• the amount of personal data you need to retain “just in case”
• the risk created by unnecessary access (internally or via third parties)

It can also support “privacy by design” thinking, which is a theme running through the UK GDPR.

That said, anonymisation shouldn’t be treated as a magic shield. If you share a dataset thinking it’s anonymised, but it isn’t, you could still be dealing with personal data and the usual compliance obligations. Having a practical plan for handling incidents (including decision-making and timelines) matters, which is why many businesses keep a Data Breach Response Plan in place.

Anonymisation Vs Pseudonymisation: The Difference That Trips Businesses Up

This is one of the most important parts of the ICO anonymisation conversation, because many organisations think they’ve anonymised data when they’ve actually pseudonymised it.

Pseudonymisation (Still Personal Data)

Pseudonymisation usually means replacing identifiers with something else (like a customer ID number) while keeping the ability to re-identify someone (for example, by looking up the ID in a separate system).

Examples include:

• replacing names with unique IDs but retaining a “key” that maps IDs back to names
• hashing email addresses where the hash can still be matched or reversed in practice
• masking a phone number but keeping enough digits to link records

Pseudonymisation is still useful (and often recommended as a security measure), but it’s still covered by the UK GDPR because re-identification remains possible.

Anonymisation (No Longer Personal Data)

Anonymisation is a stronger standard: re-identification should not be reasonably likely.

The ICO’s guidance is risk-based. In practice, you should consider:

• Who might try to re-identify someone (internal staff, third parties, the public)
• What other information they could combine the dataset with
• How likely re-identification is in the real world
• What harm could result if re-identification happens

This is also why it’s dangerous to “eyeball” anonymisation. A dataset can look anonymous but still be identifiable when combined with other information (especially where you’ve got small sample sizes, niche locations, job titles, or rare characteristics).

How To Anonymise Personal Data: Practical Methods And A Step-By-Step Process

There’s no one-size-fits-all technique. What works for a high-volume eCommerce store may not work for a local clinic or a specialist consultancy with a small client base.

But there is a sensible process you can follow so your anonymisation work is defensible and repeatable.

Step 1: Be Clear About The Purpose (And What You Actually Need)

Start with your goal. Ask:

• What are we trying to analyse or share?
• What fields do we genuinely need?
• Can we remove entire categories of information rather than “masking” them?

This is often where you get quick wins. For example, if you’re creating monthly performance reporting, you usually don’t need names, full addresses, full dates of birth, or free-text notes.

Step 2: Identify Direct And Indirect Identifiers

Direct identifiers are obvious (name, email, phone number). Indirect identifiers are the tricky ones (postcode + job title + age band, or “only one person in the company who does that role”).

In small businesses especially, indirect identifiers can be the main risk because there are fewer people in each category.

Step 3: Apply Anonymisation Techniques (Often In Combination)

Here are common techniques businesses use. In practice, you’ll often combine several.

Data Removal (Deletion / Suppression)

• Remove columns entirely (e.g. email address, phone number).
• Remove rows where the individual would be unique (e.g. the only customer in a region).

Aggregation

• Report totals or averages rather than individual-level records (e.g. “sales by region” rather than “sales by customer”).
• Group categories (e.g. age bands rather than exact ages).

Generalisation

• Replace specific values with broader ones (e.g. “London” instead of a postcode, “Q1 2026” instead of a specific date).

Masking / Redaction

• Remove parts of a value (e.g. showing only the first part of a postcode).

Note: masking on its own is often not enough for true anonymisation if the remaining info still allows identification.

Noise / Perturbation

• Introduce small changes to values to reduce identifiability (more common in statistical datasets).

Step 4: Test Re-Identification Risk (Don’t Skip This)

A practical way to think about anonymisation under ICO guidance is: what would a motivated person be able to do with this dataset?

Testing might include:

• checking for unique combinations (e.g. only one person aged 57 in a tiny location category)
• trying “linkage attacks” internally (can you match it against another dataset you hold?)
• considering what a third party might know (public sources, social media, industry directories)

If you’re using suppliers to process or transform data (for example, analytics platforms, data hosting, or outsourced reporting), make sure the relationship is properly governed. Depending on roles, you may need contracts dealing with processing obligations, like a Data Processing Agreement.

Step 5: Control Access And Stop “Function Creep”

Even if you anonymise well, you can undermine it operationally. For example:

• exporting “anonymised” data into spreadsheets that later get combined with identifiable datasets
• giving broad internal access to datasets that don’t need to be widely available
• copying datasets into tools where you lose control and auditability

This is why internal rules matter. Many businesses formalise how staff use systems, devices, and data through policies like an Acceptable Use Policy.

What Legal And Compliance Steps Should You Take Alongside Anonymisation?

Anonymisation isn’t just a technical exercise. From the ICO’s perspective, it’s also about governance, accountability, and making sure your approach stands up if you ever need to justify it.

1. Keep A Record Of Your Decision-Making

You don’t need a 40-page report, but you should be able to show:

• what data you started with
• why you anonymised it (your purpose)
• which techniques you used
• what testing you did (and the outcome)
• who approved it internally
• how you’ll prevent re-identification going forward

This kind of documentation is especially helpful if you later face questions from customers, partners, or regulators.

2. Update Your Privacy Information Where Needed

If you collect personal data, you still need to tell people how you use it. Even if you plan to anonymise later, you should be transparent about that lifecycle.

For many small businesses, this comes back to having a clear Privacy Policy that matches what you actually do in practice (not what a generic template says).

3. Check Whether You Need A DPIA

A Data Protection Impact Assessment (DPIA) is required where processing is likely to result in a high risk to individuals.

Anonymisation can reduce risk, but certain projects might still trigger DPIA thinking, especially if you’re:

• using large-scale datasets
• handling special category data (e.g. health data)
• combining multiple datasets
• using new technology or profiling

If you’re unsure, it’s worth getting advice early. It’s much easier (and cheaper) to design privacy into a project upfront than to re-build it after launch.

4. Make Sure Your Supplier Contracts Match Reality

Small businesses often use third-party tools for CRM, email marketing, analytics, cloud storage, and payments. If personal data flows through those tools, you should be clear on:

• whether the supplier is a processor or a controller (this changes the contract requirements)
• what security measures they use
• where data is stored and accessed
• whether you’re exporting data outside the UK

Where appropriate, having your broader GDPR compliance set up properly can take the stress out of these checks, and many businesses choose a structured approach like a GDPR package rather than patching documents together over time.

5. Train Your Team (Because Most “Anonymisation Failures” Are Human)

A lot of anonymisation issues happen because someone:

• exports too much data “for convenience”
• shares it internally without thinking through who can identify people
• adds a column back in later (“we just needed to check something”)

Clear internal processes, permissions, and training are usually just as important as the anonymisation technique itself.

Common Mistakes Businesses Make With ICO Anonymisation (And How To Avoid Them)

Here are some practical pitfalls we see businesses run into when they’re trying to do the right thing.

Thinking “Removing Names” Equals Anonymisation

It’s a start, but it’s rarely the finish line. People can often be identified through combinations like location + purchase history + job role + dates.

Ignoring Small Sample Sizes

If you only have a handful of customers in a category, anonymisation becomes harder. For example, “customers in a small village who bought a niche product” can be identifying even without names.

Forgetting About Free-Text Fields

Support tickets, notes fields, and form responses often contain names, addresses, or other identifying details. If you’re exporting data for analysis, these fields can quietly reintroduce personal data into an “anonymised” dataset.

Not Considering Future Re-Identification

Anonymisation isn’t just about what’s possible today. If you keep the dataset for years, you should consider whether:

• new datasets might be added later that make linkage easier
• public information could change (making re-identification more feasible)
• your own systems might evolve (increasing internal linkage risk)

Sharing “Anonymised” Data Without Any Controls

Even if the dataset is low-risk, you should think about reasonable contractual and operational controls-especially if you’re sharing it externally. In some cases you may want to use confidentiality clauses, data use restrictions, or at least clear written terms about permitted use and onward sharing.

Key Takeaways

• ICO anonymisation is about making sure individuals are not identifiable in a realistic, risk-based sense - not just removing names and emails.
• Anonymised data is generally outside UK GDPR, but pseudonymised data is still personal data (and still regulated).
• Good anonymisation usually uses a combination of techniques like removal, aggregation, and generalisation, backed by re-identification testing.
• Small businesses should pay extra attention to small datasets, rare categories, and free-text fields, because they increase the risk of re-identification.
• Alongside the technical work, you should have strong governance: records of decisions, supplier contracts (where relevant), staff training, and privacy information that reflects what you actually do.
• If you’re unsure whether your approach is truly anonymisation (or whether your project triggers additional GDPR steps), it’s worth getting advice early so you don’t build on shaky foundations.

If you’d like help reviewing your data handling practices, anonymisation approach, or GDPR documents, you can reach us at 08081347754 or team@sprintlaw.co.uk for a free, no-obligations chat.