Data Anonymization Guide

This is a working guide to data anonymization: the standards that define it in the US, EU and UK, and a step-by-step walk-through of actually anonymizing a user across a real SaaS stack.

This is not legal advice. I am an engineer, not an attorney. Whether a given technique satisfies a given law for your data is a determination for qualified legal counsel. What follows is a technical summary of the published standards to make that conversation with counsel faster and better informed.

Everything below is based on research done on October 16, 2026. This area is moving quickly: one of the key EU documents is still a draft under public consultation as I write this, so expect details to change and verify against the primary sources linked at the bottom before relying on any of it.

Anonymization vs. Pseudonymization

The legal stakes sit in this distinction, so it comes first.

Anonymized data can no longer be linked to an individual by any means reasonably likely to be used. Under GDPR, truly anonymized data is no longer personal data at all, and the regulation stops applying to it. That is why the bar is set deliberately high.

Pseudonymized data has had direct identifiers replaced with tokens or keys, but re-identification remains possible for whoever holds the key. Under GDPR it is still personal data, full stop. Pseudonymization is a risk-reduction measure and a useful one, but it does not take you out of scope.

The most common mistake I see in web and analytics work is treating hashing as anonymization. A SHA-256 hash of an email address is pseudonymization: anyone with a list of candidate emails can hash them and match. Regulators on both sides of the Atlantic have been explicit on this point.

HIPAA De-identification (US Health Data)

For data covered by HIPAA, the Privacy Rule’s de-identification standard is satisfied by exactly two methods defined by HHS:

Expert Determination. A person with appropriate statistical and scientific knowledge applies accepted methods and documents a determination that the risk of re-identification is very small. The expert’s documentation is the compliance artifact.

Safe Harbor. The mechanical route: remove all 18 enumerated identifier categories (names, geographic subdivisions smaller than a state, all date elements except year, phone numbers, email addresses, SSNs, medical record numbers, IP addresses, biometric identifiers, full-face photos, and so on), and have no actual knowledge that the remaining data could identify an individual. Note that IP addresses are on the list, which surprises teams who think of them as technical metadata rather than health data identifiers.

Safe Harbor is simpler to execute and audit; Expert Determination preserves more analytic value. Which one fits is a question for counsel and depends on what the data needs to do afterward.

NIST SP 800-188 (US General Guidance)

NIST Special Publication 800-188, “De-Identifying Government Data Sets,” was finalized September 14, 2023, authored by NIST and US Census Bureau experts. It is written for government data but has become the de facto US technical reference for everyone else.

Its useful contribution is covering the full spectrum in one document: traditional de-identification (suppression, generalization, swapping), the quasi-identifier problem, k-anonymity and its refinements, and formal privacy methods, principally differential privacy, which the Census Bureau itself adopted for the 2020 census. It is also clear-eyed about the limits of traditional techniques, documenting re-identification attacks that defeated naive de-identification.

EDPB Anonymisation Guidelines (EU, Draft)

The European Data Protection Board adopted Guidelines 02/2026 on anonymisation on July 7, 2026 for public consultation, with the consultation open until October 30, 2026. This is the first update to EU-level anonymisation guidance since the Article 29 Working Party’s 2014 opinion, which the field has outgrown badly (the 2014 document predates widespread machine learning re-identification research). A readable analysis of the draft is available from William Fry.

The practical takeaway while it remains a draft: the EU bar for “anonymous” stays high, assessed against all means reasonably likely to be used for re-identification, including by third parties, and accounting for technological development. If your EU data strategy depends on claiming anonymization, this document is the one to watch, and the final version may differ from the draft.

EDPB Pseudonymisation Guidelines (EU)

The EDPB published separate guidelines on pseudonymisation on January 16, 2025 (summary from Greenberg Traurig). Two points worth knowing from an implementation standpoint:

Pseudonymized data remains personal data even if the holder cannot re-identify it themselves, as long as anyone reasonably could. And done properly, with keys held separately under their own access controls, pseudonymization counts as a technical and organizational measure that supports security obligations and can support legitimate-interest arguments. It earns you risk reduction, not an exit from the regulation.

ICO Anonymisation Guidance (UK)

The UK’s Information Commissioner’s Office published its anonymisation guidance on March 28, 2025 (analysis from RPC). It covers effectiveness assessment, pseudonymisation, accountability and governance measures, and includes worked case studies.

The ICO’s framing is more pragmatic than the EU draft: it uses a “spectrum of identifiability” and asks whether re-identification is reasonably likely in context, rather than demanding theoretical impossibility. For UK-facing work this makes documented risk assessment the central artifact: you are expected to show your reasoning, not just your output.

Technique Reference

The techniques these standards evaluate, in rough order of strength:

  • Masking / suppression: removing or blanking identifier fields. Necessary but never sufficient on its own.
  • Generalization: reducing precision (full birthdate to birth year, zip code to state).
  • Pseudonymization / tokenization: identifiers swapped for keys held separately. Reversible by design.
  • k-anonymity: every record matches at least k-1 others on quasi-identifiers, so no one is unique on the linkable fields.
  • l-diversity and t-closeness: refinements fixing k-anonymity’s weakness when everyone in a group shares the same sensitive value.
  • Differential privacy: calibrated statistical noise with a mathematical guarantee that results barely change whether any individual is in the dataset. The only technique here with a formal proof behind it, and the direction NIST SP 800-188 points for high-assurance use.
  • Synthetic data: artificial records modeling the statistics of the real dataset. Strength depends entirely on how the generator was built and whether it memorized real records.

When You Actually Need This

The standards above get applied in a handful of recurring situations:

  • Deletion and erasure requests. A CCPA/CPRA or GDPR request arrives and you need to remove a person from every system, while keeping the aggregate numbers your business reports on.
  • Churned account cleanup. A retention policy that anonymizes accounts N months after cancellation, so your warehouse keeps its history without carrying identifiable ex-customers indefinitely.
  • Analytics and data warehouses. Keeping product and marketing analytics usable without them being a secondary copy of your user table.
  • Staging and test environments. Developers need realistic data; they do not need real customers. This is where production copies quietly become the biggest exposure in the company.
  • Vendor and partner sharing. Sending data to an agency, a researcher, or an ML team under the claim that it is “anonymized,” a claim the standards above exist to test.

Scenario: SaaS Product with Web and Mobile Apps

The worked example: a SaaS product with a marketing site at www.appname.com, the product at app.appname.com, and iOS and Android apps. All of them share centralized user authentication, which means one user ID is the join key across every system. A deletion request (or your churn-anonymization policy) fires for one user. Here is the walk-through.

Step 1: Map Where the User Exists

You cannot anonymize what you have not inventoried, and this list is longer than most teams expect. For this architecture it typically means:

  • Auth provider: the central user record (email, name, password hash, OAuth links), the user ID everything else references
  • Production database: profile fields, user-generated content, billing contact details, team memberships
  • Data warehouse: event tables keyed on user ID, replicated from production and from the apps
  • Web analytics: GA4 on www and app subdomains, with the user ID passed for cross-device stitching
  • Mobile analytics: Firebase (or equivalent) on both apps, holding the same user ID plus device-level identifiers
  • Ad platforms: hashed-email audiences uploaded to Google, Meta, LinkedIn
  • Email/CRM: the marketing platform and sales CRM, each with their own copy of the contact
  • Support desk: tickets with the user’s email and whatever they pasted into them
  • Server and CDN logs: IP addresses and user IDs in request logs across all properties
  • Backups: every snapshot of the production database taken while the user existed
  • Payment processor: Stripe or similar, holding card and invoice history

If you maintain a Record of Processing Activities, this step is a lookup. If you do not, building this map is the real project, and it is reusable for every future request.

Step 2: Verify the Request and Freeze the Account

Authenticate that the requester controls the account (a signed-in request or email confirmation loop), log the request with a reference ID, and disable the account so no new data accumulates mid-process. Both CCPA and GDPR run on deadlines (45 days and one month respectively, extendable), so the clock starts here and the reference ID anchors your paper trail.

Step 3: Delete or Anonymize, System by System

Auth provider. Delete credentials and OAuth links. If foreign keys elsewhere require the user row to survive, tombstone it: replace the email with deleted-user-{random}@invalid.example, null every profile field, keep only the ID. The ID alone identifies nobody once everything it joins to is cleaned.

Production database. Null or randomize identifying fields, generalize what you keep for business reporting (country instead of address, signup month instead of birthdate if you ever held one). User-generated content is a judgment call for counsel: delete it, or reattribute it to an anonymous placeholder the way large platforms do.

Data warehouse. The trap is here. Do not “anonymize” by hashing the user ID: a hash of an ID you still hold elsewhere is pseudonymization, and anyone with the original can re-link it. Either delete the user’s event rows outright, or rotate them to a freshly generated random ID with no mathematical relationship to the original, and destroy the mapping once rotation completes. After rotation, check the quasi-identifier problem: if the remaining columns (plan type, company size, city, signup date) single out one account, generalize those too. This is exactly what k-anonymity thinking is for.

GA4 and Firebase. Use the user deletion APIs. GA4 takes a deletion request keyed on the user ID; Firebase has the equivalent for app instances. Delete the user ID associations on both platforms, covering web and both mobile apps. Note the apps also carry device-scoped identifiers (IDFA/GAID, app instance IDs, push tokens): delete the push tokens from your own systems and include the device identifiers in the platform deletion calls where supported.

Ad platforms. Remove the user from Customer Match and custom audience lists via each platform’s removal API, and regenerate any static audience files so the next upload does not resurrect them.

Email/CRM and support desk. Delete the contact and redact or delete tickets. One deliberate exception, agreed with counsel: most organizations retain a suppression entry so a deleted user is never emailed again. That suppression record is personal data kept under a documented legal basis, not an oversight.

Logs and backups. Nobody scrubs individual users out of CDN logs and encrypted snapshots, and the regulators’ guidance accommodates this: keep retention short (30 to 90 days for logs, a defined expiry for backups), document that deleted data ages out with them, and ensure your restore procedure re-applies deletions if an old snapshot ever comes back to life.

Payment processor. Invoice and transaction records are exempt from deletion under tax and fraud-prevention obligations. Document the exemption rather than pretending the data is gone.

Step 4: Record What You Did

Close the loop with an entry in a deletion log: request ID, dates, every system touched, what was deleted versus anonymized versus retained under exemption, and who executed it. Under the ICO’s guidance this documented reasoning is effectively the deliverable, and it is what counsel shows a regulator if the request is ever audited. Confirm completion to the requester.

What “Anonymized” Means When You’re Done

The user’s remaining footprint is: event rows under a random unlinked ID, aggregate numbers, exempt financial records, a suppression entry, and log lines that expire on schedule. Nothing left can be tied back to the person by means reasonably likely to be used, which is the test every framework above applies. That claim is now defensible because each step is documented.

Scenario: Production Data in Staging

The shorter second case, because it is the most common quiet violation: a copy of production running on staging.appname.com with the whole user table in it. The fix is a sanitization script that runs as part of every staging refresh: replace names and emails with generated fakes, null payment and address fields, rotate user IDs, and truncate high-risk tables (support tickets, messages) entirely. Synthetic or faked data preserves referential integrity for developers while removing the real people; WP-CLI, Laravel seeders, or a SQL pass after import all work. The standard to hold it to is simple: a staging breach should be a non-event.

Implementation Notes for Web & Analytics Data

Where this lands for the marketing and analytics stacks I work on:

  • IP addresses are personal data in the EU and UK, and a HIPAA Safe Harbor identifier. Truncation at the edge helps but is generalization, not anonymization.
  • Hashed emails sent to ad platforms are pseudonymous, which is exactly why the platforms can match them. Treat uploads to Meta, Google and LinkedIn as disclosures of personal data governed by consent, not as anonymized transfers.
  • Aggregated analytics can still leak when segments get small. A report filtered to one zip code and one job title can be an identification. Minimum cell-size thresholds are the standard mitigation.
  • Retention is the cheapest anonymization. Data you deleted on schedule is data you never have to defend. Most analytics questions don’t need user-level data older than 14 months, which is also GA4’s default.

Sources