2. Foundations

This module builds the conceptual toolkit you need before choosing any anonymization technique. It covers how to classify the data you're working with, the spectrum of privacy treatments available, who attacks anonymized data and how, and how to measure whether your protections actually work.

---

Personal data and identifiers

Direct identifiers, quasi-identifiers, sensitive attributes

From an anonymization perspective, each field in a dataset is either non-identifying (requires no treatment — e.g., record type, network technology, billing plan category) or falls into one of three risk-carrying categories. Correctly classifying each field is the first step in any engagement — the category determines which technique applies and how much risk the field carries.

Direct identifiers are values that uniquely identify a person on their own: name, email address, national ID, phone number (MSISDN in telco), IBAN or credit card number (fintech), customer account ID (e-commerce). Removing or transforming these is necessary but not sufficient for anonymization.

Quasi-identifiers (also called indirect identifiers) do not identify a person individually, but in combination can narrow down to a single individual. Classic examples: ZIP code + date of birth + gender uniquely identifies 87% of the US population (Sweeney, 2000). In telco: cell tower ID, call timestamp, call duration, handset type. In e-commerce: purchase timestamp, product category, delivery address postal code, device fingerprint. In fintech: transaction amount, merchant category code, transaction timestamp, branch location. These are the fields that make anonymization hard — they look innocuous individually but form a behavioral fingerprint when combined.

Sensitive attributes are the values an attacker wants to learn about an individual: medical diagnosis, salary, call content, browsing history. In fintech: account balance, credit score, loan default status. In e-commerce: purchase details, wishlist contents, price sensitivity tier. These are the target of an attack, not the mechanism of it. If an attacker uses quasi-identifiers to isolate a specific person's record, the sensitive attributes are what they learn.

Category	Definition	Examples (telco)	Examples (other verticals)	Anonymization treatment
Direct identifier	Uniquely identifies an individual on its own	MSISDN, IMSI, IMEI, customer name	IBAN, credit card number, customer account ID, email	Must be removed, hashed, tokenized, or encrypted
Quasi-identifier	Identifies in combination with other fields	Cell tower ID, call timestamp, call duration, handset model	Transaction amount + timestamp, merchant category, delivery postal code, device fingerprint, IP address	Must be generalized, suppressed, or perturbed
Sensitive attribute	Value the attacker wants to learn	Call content, browsing history, churn score	Account balance, credit score, loan default, purchase details, wishlist contents	Must not be inferable from quasi-identifiers

The critical engineering insight: most real-world re-identification attacks succeed through quasi-identifiers, not through failures in direct identifier removal. A telco MSISDN can be perfectly tokenized, but if cell tower sequences and call timestamps remain at full granularity, the subscriber is still identifiable. Likewise, an e-commerce customer ID can be hashed, but if order timestamps, product categories, and delivery postal codes remain intact, a purchase history of 3–4 orders is often enough to single out a shopper. In fintech, even after account numbers are tokenized, the pattern of transaction amounts, merchant categories, and timestamps forms a spending fingerprint. Module 03 covers the techniques for treating each category; this module focuses on recognizing what you're dealing with.

PII in different regulatory contexts

What counts as "personal data" varies by jurisdiction, and the differences affect which fields require anonymization treatment.

GDPR (EU/EEA) uses the broadest definition: any information relating to an identified or identifiable natural person. This explicitly includes online identifiers (IP addresses, cookie IDs), location data, and pseudonymized data where re-identification is possible. If there is any reasonable means of linking data back to a person — including by combining it with other datasets — it is personal data.

CCPA/CPRA (California) covers information that "identifies, relates to, describes, is reasonably capable of being associated with, or could reasonably be linked" to a consumer or household. Notably, it extends to household-level data, not just individuals, and covers inferences drawn from personal information.

LGPD (Brazil) mirrors GDPR closely: personal data is information related to an identified or identifiable natural person, including sensitive data categories (racial origin, religious belief, health, biometric data).

Singapore PDPA covers data about an individual who can be identified from that data or from that data combined with other information the organization has access to. Anonymized data falls outside scope. Notable: unauthorized re-identification of anonymized data is a criminal offense (up to SGD 5,000 fine and 2 years imprisonment). The APPA Anonymization Guide (June 2025) provides a five-step anonymization process including k-anonymity risk assessment.

Indonesia UU PDP (Law No. 27/2022, fully enforceable since October 2024) is GDPR-inspired: personal data is data about identified or identifiable individuals. However, the law does not explicitly address anonymization or pseudonymization — implementing regulations are still being finalized and the Data Protection Authority is not yet operational. Treat with caution; design for GDPR-level standards when building for Indonesian clients.

Swiss FADP (nDSG) (in force since 1 September 2023) aligns closely with GDPR. Pseudonymized data is covered if re-identification is possible with reasonable effort. For Swiss financial institutions, the FADP operates alongside banking secrecy (Art. 47) and FINMA circulars — see the FINMA overlay in the data classification section below.

Aspect	GDPR	CCPA/CPRA	Swiss FADP + FINMA	LGPD	Singapore PDPA	Indonesia UU PDP
IP address is PII	Yes (explicit)	Yes	Yes	Yes	Yes (if identifying)	Yes (if identifying)
Device ID is PII	Yes	Yes	Yes	Yes	Yes (if identifying)	Yes (if identifying)
Pseudonymized data is PII	Yes — still personal data	Depends on re-identification capability	Yes — and may also be bank client data under Art. 47	Yes	Yes — if re-identification possible	Not explicitly addressed
Anonymized data is PII	No — exits scope	No — exits scope	No — exits both FADP and banking secrecy scope	No — exits scope	No — exits scope	Not explicitly addressed
Household-level data	Not explicitly PII	Yes — PII	Not explicitly PII	Not explicitly PII	Not explicitly PII	Not explicitly PII
Inferred data	Depends on identifiability	Yes — explicitly PII	Depends on identifiability	Depends on identifiability	Depends on identifiability	Not explicitly addressed
Criminal penalties for breach	No — administrative fines	No — civil penalties	Yes — up to 3 years imprisonment (Art. 47); FADP fines up to CHF 250,000 on individuals	No — administrative fines	Yes — re-identification is criminal (up to 2 years)	Yes — up to 6 years imprisonment, IDR 6B fine (varies by offense; corporate fines can be higher)

Engineer takeaway

When working with multinational clients or cross-border data flows, design for the strictest applicable standard. In practice, this usually means GDPR's broad definition — unless Swiss financial data is involved, where banking secrecy adds criminal-law severity on top. For APAC deployments, note that Singapore explicitly criminalizes re-identification of anonymized data, and Indonesia's framework is still maturing — default to GDPR-level standards when local guidance is incomplete.

Data classification as the first step

Before choosing any anonymization technique, map every field in the dataset to its identifier category and sensitivity level. This classification drives all downstream decisions.

A practical classification process for a client engagement:

1. Inventory all fields in the target dataset(s). For a telco CDR table, this might be 20–40 fields. For an e-commerce order/event table, 15–30. For a fintech transaction ledger, 20–50.
2. Classify each field as direct identifier, quasi-identifier, or sensitive attribute. Some fields are context-dependent: an IP address is personal data under GDPR (Recital 30), but whether it acts as a direct or quasi-identifier depends on context — behind carrier-grade NAT it may be shared by thousands of users simultaneously.
3. Assess combination risk. Individual quasi-identifiers may seem harmless, but the combination of cell tower + timestamp + duration (telco), or amount + merchant + timestamp (fintech), or product + delivery postal code + order time (e-commerce) may be uniquely identifying. The number of distinct combinations in the dataset is a proxy for uniqueness risk — if a field combination has many unique values relative to the dataset size, it is a re-identification vector.
4. Document the classification with the rationale for each field. This becomes the input to technique selection (Module 03) and the basis for the client's data protection impact assessment (DPIA).

FINMA overlay for Swiss financial institutions: In Swiss finance engagements, the standard direct/quasi/sensitive classification must be extended with FINMA's two additional categories. Bank client data covers all information protected by banking secrecy — this includes direct identifiers but also extends to account balances, transaction details, and any information about a banking relationship that could identify the client. Critical data (FINMA Circular 2023/1) are data requiring heightened protection based on the institution's risk profile, assessed across confidentiality, integrity, and availability. A field might be a quasi-identifier under the standard classification but qualify as bank client data under FINMA — for example, a transaction amount combined with a date and branch location may not directly identify a client in isolation, but falls under banking secrecy because it describes a banking relationship. The practical effect: fields that would receive moderate treatment (generalization, bucketing) under a pure data-protection analysis may require stronger controls (encryption, pseudonymization with keys held in an external HSM via Cloud EKM) to satisfy banking secrecy obligations.

Deep dive

Context-dependent classification

Some fields change category depending on the dataset context and the auxiliary information available to an attacker:

• Age is a quasi-identifier in most datasets, but in a dataset of centenarians in a small town, it becomes effectively a direct identifier.
• Job title is usually a quasi-identifier, but "CEO of [specific company]" is a direct identifier.
• Cell tower ID is a quasi-identifier for a single CDR, but a sequence of cell towers over a day is a quasi-identifier with near-direct-identifier strength (4 spatio-temporal points identify 95% of individuals).
• IP address is personal data under GDPR (Recital 30), but not automatically a direct identifier. Behind carrier-grade NAT (common in mobile networks), a single IP may be shared by thousands of subscribers — making it a weak quasi-identifier in practice, even though it remains legally classified as personal data.

The classification should reflect the worst realistic case, not the average case. If a field can serve as a direct identifier for some subset of the data, treat it accordingly.

---

The anonymization spectrum

Privacy transformations are not binary. They form a spectrum from fully identifiable raw data to entirely artificial synthetic data, with each level offering different tradeoffs between privacy, utility, and regulatory status.

Two properties matter most at every level:

• Reversibility — can you get the original value back? If yes (via a key, mapping table, or vault), the data is pseudonymized, not anonymized — regardless of how scrambled it looks.
• Linkability — can you tell that two records belong to the same person? If the same input always produces the same output (e.g., a phone number always maps to the same token), records are linkable across tables. Good for analytics, bad for privacy.

Level	What happens to the data	Can you reverse it?	Can you link records?	Can you join across datasets?	GDPR status
Raw	Nothing — original production data	N/A	Fully	Yes	Personal data — full obligations
Pseudonymized	Direct identifiers replaced with substitutes (tokens, hashes, encrypted values); a key or mapping can restore originals	Yes — with key/mapping	Yes — same input → same output	Yes	Personal data — full obligations (Art. 4(5))
De-identified	Identifiers replaced and quasi-identifiers coarsened (e.g., exact age → age range, precise location → region)	Partially — identifiers may be reversible, but coarsened fields are not	Reduced — coarsening breaks some links	Limited	Context-dependent — may still be personal data if residual risk exists
Anonymized	No individual identifiable by any reasonable means	No	Eliminated or negligible	No	Not personal data (Recital 26) — exits GDPR scope entirely
Synthetic	Entirely artificial records generated by statistical models trained on the original; no real person's data exists in the output	No — no real values to recover	No — no real individuals	No	Not personal data — exits scope (if generation doesn't memorize training records)

A few things to note:

• GDPR draws a binary line. Data is either personal data (full obligations) or anonymized (no obligations). The levels in between — pseudonymized and de-identified — are still personal data. There is no "partially regulated" middle ground.
• Linkability and utility go together. Destroying linkability strengthens privacy but eliminates join capability — you cannot track a subscriber's journey (telco), compute customer lifetime value (e-commerce), or link transactions for fraud scoring (fintech). Module 06 shows how data zones let different levels coexist for different use cases.
• The anonymization bar is context-dependent. The same dataset might qualify as anonymized when shared with a party that has no auxiliary data, but only as de-identified when shared with a party that could cross-reference it. Assessments must consider the specific sharing scenario. The EDPB Guidelines 02/2026 provide the three-criteria test (introduced in Module 01): no record isolation, no linkage, no inference.

---

Threat models and adversaries

Anonymization is a defense against a specific attacker. Without defining who you're defending against and what capabilities they have, you cannot evaluate whether your protections are sufficient.

Who attacks and what they bring

Re-identification is not hypothetical. A researcher at MIT showed that 4 credit card transactions — just store and approximate date, no amounts — uniquely identify 90% of people in a national dataset. NYC taxi trips were de-anonymized because someone hashed medallion numbers without a salt, and paparazzi photos with timestamps revealed which celebrities rode in which cabs. The AOL search logs incident started when a journalist pattern-matched "anonymized" queries to a specific 62-year-old woman in Georgia from her searches alone.

The attackers range from competitors mining anonymized data for commercial intelligence, through data brokers who cross-reference even weak quasi-identifiers with their existing profiles, to insiders who have legitimate access to pseudonymized data and misuse it. Researchers and journalists regularly prove anonymization claims false as a public service. And if a re-identification key exists anywhere in your architecture, law enforcement can subpoena it — an architecture decision with legal consequences.

What makes an attacker effective is the combination of background knowledge (what they already know about a target — home location, workplace, habits), auxiliary datasets (voter rolls, social media, previous breaches to cross-reference against), and computational resources (reversing unsalted hashes of all phone numbers or IBANs in a national numbering space takes minutes on commodity hardware).

Prosecutor, journalist, and marketer models

Three standard adversary profiles used in risk assessment tools (including ARX) to evaluate re-identification risk:

Model	Goal	Tolerates false positives	Risk metric	Use for
Prosecutor	Find a specific person's record	No	P(correct identification of target)	Sensitive data, high-risk sharing
Journalist	Re-identify anyone to prove the data isn't safe	No	Expected # of re-identifiable records	Public data releases, regulatory audits
Marketer	Re-identify as many as commercially useful	Yes	Proportion of dataset re-identifiable	Data broker, advertising scenarios

When a client asks "is our data safe?" — the answer depends on which model they're defending against. The prosecutor model sets the strictest bar. Module 12 covers real-world cases illustrating each adversary model.

Deep dive

The evolving adversary landscape

Adversary capabilities grow over time: new breaches add auxiliary data (data safely anonymized in 2020 may be re-identifiable in 2026), ML-based attacks enable probabilistic re-identification without exact matches, membership inference can detect whether a specific individual was in a synthetic model's training data, and multiple "safe" releases about the same population can collectively break privacy thresholds (composition attacks — covered in Module 04). GDPR's "reasonably likely means" test is forward-looking: assessments should account for plausible near-future capabilities, not just today's.

---

Measuring privacy

Re-identification risk

Re-identification risk is the probability that an attacker can link a record back to the person it represents. Quantifying this — rather than relying on intuition — is what separates engineering-grade anonymization from "we removed the names."

The core idea is uniqueness: how many records in the dataset share the same quasi-identifier values? If a record's combination of age range, postal code, and gender appears in 50 records total, an attacker who knows someone is in that group has a 1-in-50 chance of picking the right one. If that combination is unique in the dataset, and the attacker has auxiliary data to confirm the match, identification becomes straightforward.

This is the intuition behind k-anonymity (covered in depth in Module 04): ensure every record is indistinguishable from at least k−1 others on its quasi-identifiers. A dataset with k=50 means every person "hides in a crowd" of at least 50. Common starting points: k ≥ 5 as a minimum, k ≥ 11 for public releases. For differential privacy, ε ≤ 1.0 is a frequently cited reference point for external sharing, but the actual guarantee depends on additional parameters (δ, sensitivity, composition budget) — Module 04 covers this in depth. Tools like ARX compute these metrics automatically (Module 05).

The utility–privacy tradeoff

Every anonymization technique reduces analytical value — that is the mechanism by which privacy is achieved. The engineering challenge is finding the balance that meets the regulatory bar while keeping the data useful.

What gets lost varies: aggregate statistics shift, ML model accuracy drops, timestamp granularity disappears (breaking real-time fraud detection in fintech, flash-sale analysis in e-commerce, call setup analysis in telco), and join capability vanishes when you stop using deterministic pseudonyms. The same source data often needs different treatments for different consumers:

Consumer	What they need	Typical approach
Internal data science	High granularity, joinable	Pseudonymization + access controls
BI / reporting	Aggregate accuracy	Coarsened quasi-identifiers (e.g., k-anonymity)
External partner	Statistical accuracy	Noise added to query outputs (differential privacy)
Public release	Distribution-level accuracy	Synthetic data with privacy guarantees
Dev/test	Structural fidelity	Static masking or synthetic data

This is why production architectures use data zones (Module 06) — each zone applies the treatment level appropriate to its consumers and threat model.

Why "we removed the names" is never enough

The most common first attempt at anonymization — stripping direct identifiers — is also the most consistently broken. An attacker cross-references the remaining quasi-identifiers against auxiliary data (social media, voter rolls, previous breaches) and links records to identities.

Some noteworthy examples:

Case	What was removed	How re-identification worked
Massachusetts health (1997)	Names and SSNs	3 fields (ZIP + birthdate + gender) linked to public voter roll; governor identified
AOL search logs (2006)	User IDs	Search content itself contained identifying details; journalist matched queries to a specific person
Netflix Prize (2006)	User IDs	8 movie ratings + dates cross-referenced with public IMDB reviews
NYC taxi data (2013)	Medallion numbers (unsalted hash)	All possible medallion numbers hashed and matched; celebrity trips found via paparazzi photos

The pattern: every case assumed removing the identifier was enough, while the structure of the remaining data did the attacker's work.

Deep dive

Uniqueness across verticals

Telco. 4 cell-tower-and-hour data points identify 95% of subscribers (de Montjoye et al., 2013). CDR metadata yields 80%+ re-identification rates from 2 weeks of data. Call graphs (who calls whom) are structural fingerprints even when all identifiers are randomized.

E-commerce. 4 transactions (store + approximate date) identify 90% of individuals, even without amounts (de Montjoye et al., 2015). Product-level order histories are even more distinctive — shopping fingerprints are trivially matchable against loyalty programs or social media wishlists.

Fintech. Transaction ledgers combine high temporal resolution, rich categorical data (merchant codes), and precise amounts. A two-week spending pattern across 10–15 merchants is typically unique. Peer-to-peer payment graphs carry the same structural risk as telco call graphs.

Across all three verticals, identifier substitution alone is insufficient — structural privacy controls (coarsening, noise, or synthetic generation) are required on top.

---

Chapter summary

Concept	Key takeaway
Field classification	Every field is a direct identifier, quasi-identifier, or sensitive attribute. Quasi-identifiers are the primary re-identification risk.
PII scope	GDPR's definition is the broadest and usually the design target. Pseudonymized data is still personal data.
Anonymization spectrum	Five levels from raw to synthetic. The GDPR boundary is binary: personal data or not.
Reversibility & linkability	If any path back to the original exists, it's pseudonymization. If records can be linked to the same individual, linkability remains.
Threat models	Define your adversary (prosecutor/journalist/marketer) before evaluating privacy. Adversary capabilities grow over time.
Re-identification risk	Quantify it (uniqueness metrics, k-anonymity thresholds) — don't rely on intuition.
Utility–privacy tradeoff	Every technique reduces utility. Different use cases need different treatment levels — hence data zones.
"We removed the names"	Never sufficient. Quasi-identifiers and auxiliary data consistently enable re-identification.

Next: Module 03 covers every major anonymization technique in detail — how each works, what it's good for, and where it fails.

---

Created by Claude Opus with ❤️ for the Aliz Data Engineering team.