Techniques Reference

Per-technique reference cards for the eight core anonymization and pseudonymization techniques. Each card uses consistent fields for quick comparison. Restructured from Module 03 for lookup during technique selection and client conversations.

Abbreviations used throughout: SDP = Sensitive Data Protection (GCP's PII detection and transformation service); HMAC = keyed-hash message authentication code; FPE = format-preserving encryption; DDM = dynamic data masking (BigQuery policy tags); ARX = open-source structural anonymization tool; CDR = Call Detail Record; MSISDN = subscriber phone number (Mobile Station International Subscriber Directory Number).

For the privacy models applied on top of techniques, see the privacy models reference. For GCP tool implementations, see the tooling reference. For where techniques fit in the zone architecture, see architecture patterns.

Decision tree: which technique do I need?

Key: Reversible techniques (FPE, deterministic encryption, tokenization) = pseudonymization — still personal data under GDPR. One-way pseudonymization (HMAC) preserves joins but cannot re-identify. Information-destroying techniques (generalization, suppression) with formal privacy models = structural anonymization. Aggregate/synthetic outputs with DP = strongest privacy guarantee.

---

Comparison matrix

All techniques side-by-side — use this for quick comparison, then jump to the detailed card.

Technique	Reversible	GDPR status	Utility preserved	Join capability	GCP service	Best for
Suppression / redaction	No	Anonymization	Low	N/A	SDP RedactConfig	Fields with no analytical value
Generalization	No	Anonymization (if k-anonymous)	Medium	Reduced	SDP BucketingConfig; ARX	Quasi-identifiers in tabular data
Plain hashing	No (but attackable)	Not effective pseudonymization	Medium	Yes	— (no GCP service; use discouraged)	Avoid — vulnerable to dictionary attacks
HMAC-keyed hash	No (without key)	Pseudonymization	High	Yes (same key)	SDP CryptoHashConfig; Cloud KMS	Direct identifier pseudonymization
Tokenization (vaulted)	Yes (vault)	Pseudonymization	High	Yes (same vault)	Custom on Cloud SQL/Spanner	High-security identifier replacement (random, stateful)
Deterministic encryption (AES-SIV)	Yes (key)	Pseudonymization	High	Yes (same key)	SDP CryptoDeterministicConfig	Reversible pseudonymization without format constraints (stateless)
FPE	Yes (key)	Pseudonymization	Very high	Yes (same key)	SDP CryptoReplaceFfxFpeConfig	Legacy system compatibility (format-preserving)
Static masking	No	Depends on technique	Medium	Preserved (ref. consistency)	Custom Dataflow/Spark; Delphix	Non-production environments
Dynamic masking	N/A	Personal data	High	N/A	BigQuery DDM + policy tags	Role-based access control
Perturbation / noise	No	Anonymization (if DP)	Medium	No	BigQuery DIFFERENTIAL_PRIVACY; Privacy on Beam	Numerical fields, aggregates
Synthetic data	No	Not personal data (if no memorization)	High (statistical)	No	Gretel (SaaS); SDV (OSS); Vertex AI	ML training, dev/test, data sharing

---

Card 1: Suppression and redaction

Field	Detail
Mechanism	Remove data entirely (suppression) or replace with placeholder — null, ***, [REDACTED]
Reversibility	No
Privacy guarantee	Complete for the suppressed field — no value exists to attack. Does not protect the record if other quasi-identifiers remain untreated.
GDPR status	Anonymization
Utility impact	Total loss for the suppressed field
GCP service	BigQuery DDM (nullify/default-value masking rules); SDP RedactConfig
When to use	Field's privacy risk outweighs its analytical value; free-text fields (support notes, delivery instructions); pure direct identifiers with no downstream use; outlier records that cannot be generalized without creating singletons
When NOT to use	When the field has analytical value; when quasi-identifiers remain untreated (suppressing direct IDs alone is insufficient)
Key risk	Over-suppression destroys utility. Under-suppression — suppressing only direct IDs while leaving behavioral patterns intact — is "the most consistently broken approach in the field"

---

Card 2: Generalization and aggregation

Field	Detail
Mechanism	Reduce data granularity so multiple records share the same attribute values, creating equivalence classes
Reversibility	No
Privacy guarantee	Prevents singling out if equivalence classes are large enough (foundation of k-anonymity)
GDPR status	Anonymization (if k-anonymous with sufficient k)
Utility impact	Medium — reduces analytical resolution proportional to generalization level
GCP service	SDP BucketingConfig, DateShiftConfig, TimePartConfig; ARX for optimized generalization hierarchies
When to use	Quasi-identifier treatment in tabular data; when k-anonymity framework applies; when reduced-granularity analytics is sufficient
When NOT to use	When record-level precision is required; when fields have very high cardinality and all generalization levels destroy utility; not for direct identifiers (use pseudonymization)
Key risk	Over-generalization destroys utility. Under-generalization leaves individuals identifiable. Location data is particularly resistant — even coarsened spatio-temporal data retains high re-ID potential. A grid square with one subscriber at 3 AM is effectively a direct identifier.

Common generalization patterns

Original value	Generalized value	Context
Birthdate (1987-03-15)	Birth year (1987) or age band (35–39)	All verticals
Street address	District or postal code prefix	Retail, finance, energy
GPS coordinate	Grid square (100m²–1km²)	Telco, energy
Cell tower ID	Cell cluster (5–10 towers)	Telco CDRs
Timestamp (14:23:07)	Hour bucket (14:00–15:00)	All verticals
Transaction amount (€47.83)	Range bucket (€25–€50)	Finance, retail
Call duration (3m42s)	Category (1–5 min)	Telco CDRs
Smart meter reading (15-min)	Hourly or daily aggregate	Energy/utilities

---

Card 3: Hashing (plain, salted, HMAC)

Field	Detail
Mechanism	Cryptographic hash maps input to fixed-length digest. Plain: SHA-256(input). Salted: SHA-256(input‖salt). HMAC: HMAC-SHA256(key, input) — standardized keyed-hash construction.
Reversibility	No (computationally irreversible) — but plain hashing of finite-domain inputs is trivially reversible via dictionary attack
Privacy guarantee	Plain: NONE for finite-domain inputs. HMAC: resistant to precomputation attacks as long as key is secret.
GDPR status	HMAC: pseudonymization. Plain/salted hashing of finite-domain identifiers: not effective pseudonymization (enumerable — see comparison matrix above).
Utility impact	High utility preserved — deterministic output enables joins and aggregations
GCP service	SDP CryptoHashConfig (SHA-256); BigQuery DDM SHA-256 masking rule; Cloud KMS for HMAC key management
When to use	HMAC-SHA256 with Cloud KMS: the standard production pattern for identifier pseudonymization when join capability is needed and re-identification is not required
When NOT to use	Plain hashing: never for finite-domain identifiers. Salted: when cross-dataset joins are needed. HMAC: when re-identification/detokenization is required (use FPE or tokenization).
Key risk	Plain hashing is "equivalent to cleartext for any attacker who can enumerate the input domain"

Hash variant comparison

Property	Plain SHA-256	Salted SHA-256	HMAC-SHA256
Dictionary attack resistant	No	Prevents precomputed rainbow tables, but if the salt is known (standard practice), finite domains are still enumerable per salt	Yes — key must remain secret
Cross-dataset joins	Yes	No (different salts)	Yes (same key)
Consistency	Yes	Per-salt	Per-key
Key management required	No	Per-salt	Yes — centralized
Recommended for production	No	Situational	Yes

Dictionary attack enumeration times

Identifier	Domain size	Enumeration time
MSISDN	~10⁸	Minutes
IBAN	~10⁹–10¹⁰	Hours
Credit card (per BIN)	~10⁶	Seconds
IPv4	~4.3×10⁹	Hours
SSN	~10⁹	Minutes

---

Card 4: Tokenization (vaulted and vaultless)

Field	Detail
Mechanism	Replace sensitive value with random or algorithmically derived token with no mathematical relationship to original. Vaulted: secure database maps originals → tokens. Vaultless: derived cryptographically (typically FPE-based).
Reversibility	Yes — via vault lookup (vaulted) or via key (vaultless)
Privacy guarantee	Randomized vaulted tokens reveal nothing about the original without vault access. Deterministic tokens (including FPE-based vaultless) preserve equality — same input produces the same token — enabling linkability without key access.
GDPR status	Pseudonymization
Utility impact	High — consistent tokens preserve join capability and referential integrity
GCP service	SDP CryptoReplaceFfxFpeConfig (vaultless/FPE-based); custom vault implementations on Cloud SQL/Spanner
When to use	When re-identification/detokenization is required AND maximum security needed; PCI-DSS mandated scenarios; reversible pseudonymization for operational processes
When NOT to use	High-throughput pipelines where vault latency is unacceptable (consider HMAC); when irreversibility is preferred
Key risk	Vaulted: vault becomes single point of failure + performance bottleneck at scale. Vaultless: reintroduces key management as security dependency.

Vaulted vs. vaultless comparison

Property	Vaulted	Vaultless (FPE-based)
Security model	Vault compromise = full exposure	Key compromise = full exposure
Latency	Vault lookup per operation	Crypto operation (fast)
Scalability	Vault becomes bottleneck at scale	Scales with compute
Reversibility	Via vault	Via key
Infrastructure	High-availability database	KMS/HSM
PCI-DSS scope	Full reduction (random token)	Partial (depends on assessment)

---

Card 5: Format-preserving encryption (FPE)

Field	Detail
Mechanism	Encrypts data while maintaining original value's length, character set, and structure. A 15-digit MSISDN encrypts to another 15-digit numeric string. Uses NIST FF1 algorithm (AES-based Feistel network, 10 rounds).
Reversibility	Yes — anyone with the encryption key can decrypt
Privacy guarantee	Encrypted value does not reveal the plaintext without key. However, deterministic output exposes equality and frequency patterns (same plaintext = same ciphertext), and the preserved format reveals length and alphabet. Linkability is preserved without decryption.
GDPR status	Pseudonymization (reversible → still personal data)
Utility impact	Very high — preserves format, length, character set; passes downstream validation
GCP service	SDP CryptoReplaceFfxFpeConfig (AES-FFX mode); Cloud KMS for key management
When to use	Format compatibility is a hard constraint — legacy system integration, schema migration avoidance, phased rollouts
When NOT to use	Greenfield architectures (HMAC is simpler and avoids reversibility surface); small-domain fields (< 1M possible values); fields where deterministic linkability is unacceptable
Key risks	Format leakage (encrypted MSISDN starting with +36 reveals country — always encrypt entire value). Small-domain vulnerability (FF1 minimum domain = 1,000,000 values). Does not preserve checksums (Luhn, IBAN check digits) — downstream validation may fail.

FF1 reference

Property	Detail
Rounds	10
Minimum domain size	1,000,000 values (Rev. 1 draft)
Tweak size	Arbitrary length
GCP support	CryptoReplaceFfxFpeConfig (AES-FFX mode)
Note	FF3-1 removed from NIST SP 800-38G Rev. 1 (2025 draft); FF1 is the only retained algorithm

---

Card 6: Data masking (static and dynamic)

Field	Detail
Mechanism	Static (SDM): permanently transforms a copy of production data using per-field transformations. Dynamic (DDM): masks values at query time based on caller's identity/role; stored data unchanged.
Reversibility	SDM: No. DDM: N/A — original data never modified.
Privacy guarantee	SDM: depends on component techniques. DDM: none — it's access control, not a privacy transformation.
GDPR status	SDM: depends on techniques used. DDM: still personal data.
Utility impact	SDM: medium — preserves schema, types, distributions, referential integrity. DDM: high — different users see different masking levels.
GCP service	DDM: BigQuery via policy tags + masking rules (SHA256, Nullify, Default Value, Last 4 Characters) with Fine-Grained Reader / Masked Reader roles. SDM: custom Dataflow/Spark pipelines or commercial tools (Delphix, Informatica).
When to use	SDM: non-production environments (dev/test/staging), data sharing. DDM: role-based access control within production — data scientists get full detail, business analysts get masked view. Common: DDM on Zone 1 for access control, SDM for exports.
When NOT to use	DDM alone is never sufficient for anonymization claims. SDM: when reversibility is required.
Key risk	DDM is frequently mistaken for anonymization. "We mask the data" may mean only that certain roles see masked values while data at rest is fully identifiable. SDM without referential consistency breaks foreign key relationships.

SDM field transformation patterns

Field type	Masking approach	Example
Name	Realistic substitution	"Maria Kovács" → "Anna Tóth"
Email	Domain-preserving substitution	maria@example.com → user4821@example.com
Phone	Random replacement or FPE	"+36 30 123 4567" → "+36 30 847 9213"
Address	Street/number randomization, postal code preserved	"Váci út 33" → "Andrássy út 78"
Date of birth	Date shifting (± random days)	"1987-03-15" → "1987-06-22"
Account balance	Proportional noise or range bucketing	"€12,847.33" → "€13,100.00"
Foreign key	Consistent substitution across all tables	"CUST-0042" → "CUST-7819" (same everywhere)

---

Card 7: Perturbation and noise injection

Field	Detail
Mechanism	Adds controlled randomness (typically Laplace or Gaussian noise) to data values. Individual records become unreliable; population-level statistics are preserved (noise is symmetric, mean zero).
Reversibility	No
Privacy guarantee	Individual values unreliable. With DP framework: formal mathematical guarantee. Standalone: "rough privacy improvement" without quantifiable guarantee.
GDPR status	Anonymization if within a DP framework; otherwise depends on noise calibration
Utility impact	Medium — individual record values unreliable; aggregate statistics converge to true values for large groups
GCP service	BigQuery DIFFERENTIAL_PRIVACY clause (calibrated noise on aggregate queries); Privacy on Beam / PipelineDP for batch pipelines
When to use	Within a DP framework for formal guarantees on external sharing and regulatory compliance. Standalone for internal use cases where approximate privacy improvement is acceptable.
When NOT to use	Standalone for external data sharing, regulatory compliance claims, or formal privacy guarantees. Not for categorical/text fields.
Key risk	Standalone perturbation cannot answer "how much noise is enough" or "how privacy degrades across multiple queries." Spatial perturbation with too-small radius — consistent nighttime location still reveals home address. Without composition tracking, repeated queries erode privacy.

---

Card 8: Synthetic data generation

Field	Detail
Mechanism	Creates entirely artificial records preserving statistical properties (distributions, correlations, relationships) of original dataset. No record in output corresponds to any real person.
Reversibility	No
Privacy guarantee	If no memorization: output contains no real individuals. With DP-SGD training: formal guarantee that no individual record influenced output beyond bounded amount.
GDPR status	Not personal data — IF no model memorization (must be validated)
Utility impact	High at the statistical level (distributions, correlations preserved); individual records are fictional
GCP service	No native GCP service. Gretel (SaaS, has DP mode). SDV (open-source — tabular, relational, time-series). Custom training via Vertex AI.
When to use	ML training requiring record-level data; dev/test environments with realistic-looking data; external data sharing where record-level output is required
When NOT to use	When exact record-level fidelity is critical; when training data is too small for the model to learn distributions rather than memorize; when formal guarantees are needed without DP-SGD quality cost (consider k-anonymity)
Key risk	Model memorization — if the generative model memorizes training records (especially outliers or small datasets), synthetic output may contain near-exact copies of real individuals. Must validate with privacy testing: SDV includes disclosure-risk and attribute-inference metrics; for a full membership inference attack (can an attacker determine if a specific record was in the training data?), implement the train/holdout attack-model approach from Module 12.

Validation requirements

Check	What it tests	Tool
Membership inference test	Can an attacker determine if a specific record was in the training data?	Custom train/holdout attack model (see Module 12); SDV's built-in metrics cover disclosure risk and attribute inference but not full MIA
Distribution comparison	Do synthetic distributions match original?	Statistical tests (KS test, chi-squared)
Correlation preservation	Are inter-column relationships preserved?	Correlation matrix comparison
Fairness / representation	Does synthetic data preserve or amplify bias?	Per-subgroup distribution analysis (required for EU AI Act compliance)

---

Technique application by vertical

Telco CDR pipeline

Field	Technique	Rationale
MSISDN, IMSI	HMAC-SHA256	Pseudonymize direct IDs; preserve joins
IMEI	HMAC or suppression	Device ID; no join requirement in most analytics
Cell tower ID	Generalization (tower → cluster)	Reduce location precision
Call timestamp	Temporal bucketing (→ hourly)	Prevent trajectory reconstruction
Call duration	Range bucketing	Reduce behavioral specificity
SMS/call content	Full suppression	Extreme sensitivity, no analytical value
Aggregate outputs	Differential privacy	Formal guarantee for external stats

Retail / e-commerce

Field	Technique	Rationale
Customer ID	HMAC or deterministic encryption	Cross-domain joins
PAN (payment card)	Tokenization (PCI-DSS)	Scope reduction
SKUs / products	Category generalization	Reduce basket uniqueness
Addresses	Postal prefix only	Location QI treatment
Clickstream	DP aggregation	Behavioral patterns

Financial services

Field	Technique	Rationale
Account numbers	Tokenization or HMAC	Pseudonymize; original retained under AML
Transaction amounts	Range bucketing	Reduce precision for analytical zone
Merchants	MCC category generalization	Reduce transaction uniqueness
Fraud statistics	Differential privacy	Cross-institutional sharing

Energy / utilities

Field	Technique	Rationale
Meter IDs	HMAC	Pseudonymize
Consumption readings	Temporal aggregation (15-min → hourly)	Counter NILM inference
Location	Grid square generalization	Reduce precision
Demand forecasting output	Synthetic data generation	Aggregate patterns without individual data