Template: Anonymization Policy

This is a ready-to-adapt example, not a universal standard. It reflects a GCP-native, GDPR-focused data platform — the most common pattern in Aliz engagements — but every client's policy will differ based on their vertical, regulatory context, data architecture, and organizational maturity.

How to use this template:

• Pre-populated content shows realistic example values drawn from the knowledge base (telco CDR as the anchor use case). Replace examples with the client's actual data types, systems, and organizational structure.
• Placeholders in [___ description] markers indicate values that must be filled per engagement — retention periods, team names, thresholds.
• Adaptation guidelines in each section explain what to adjust and why.

See Module 09 — Governance and Compliance for the rationale behind each section, and Module 03 — Techniques and Module 06 — Architecture Patterns for the technical foundations this policy references.

---

1. Purpose and scope

This policy defines how [Organization] classifies, anonymizes, and governs personal data across its data platform. It applies to all datasets containing personal data as defined by GDPR Article 4(1), processed in [production environment / GCP project / on-premises cluster].

In scope:

• All data ingestion pipelines processing records with direct or indirect identifiers
• Data products derived from personal data (analytics tables, ML training sets, partner exports)
• Non-production environments (dev, test, staging) that use production-derived data

Out of scope:

• Aggregate-only reporting tables with no record-level data
• Fully synthetic datasets generated without personal data input
• [___ Add client-specific exclusions]

Policy owner: [___ DPO / Chief Privacy Officer / Head of Data Governance]

Review cadence: Annually, and within 30 days of any regulatory change, data breach, or significant architecture modification.

Adaptation guidelines

• Adjust the regulatory reference (GDPR Article 4(1)) if the client operates under different or additional regulations — CCPA, LGPD, APPI, sector-specific rules like ePrivacy or HIPAA.
• Scope should explicitly name the systems covered (e.g., "all BigQuery datasets in the analytics-prod project") rather than using generic language. Vague scope leads to gaps.
• Review cadence depends on regulatory velocity. Annual is the baseline; clients in rapidly evolving regulatory environments (EU AI Act adoption, sector-specific transpositions) should consider semi-annual reviews.

---

2. Data classification

All data assets must be classified before processing. New datasets are restricted by default until classified and reviewed by a data steward.

Sensitivity tiers

Tier	Definition	Examples	Handling requirement
Critical	Direct identifiers that uniquely identify an individual	[___ MSISDN, IMSI, IMEI, national ID, subscriber name, billing address]	Must be pseudonymized or redacted before leaving the raw zone. Access: break-glass only.
High	Identifiers or quasi-identifiers with high re-identification potential	[___ IP address, precise location, call/message content, device fingerprint]	Pseudonymized in the internal analytics zone; generalized or suppressed in the broad analytics zone. Access: data engineering (masked for analysts).
Medium	Behavioral or contextual attributes that contribute to re-identification in combination	[___ Call duration, data volume, service type, device model, session length]	Bucketed or generalized in the broad analytics zone. Access: analysts via dynamic data masking.
Low	Attributes with negligible re-identification risk after upstream transforms	[___ Cell cluster ID (post-generalization), time bucket, aggregated counts]	No further transformation required. Access: broad internal.
Public	Data cleared for external sharing	[___ Network coverage maps, DP-guaranteed aggregate statistics, synthetic data with privacy validation]	Safe for external distribution. Access: unrestricted.

Classification process

1. Automated discovery. SDP discovery scans all new and modified datasets. Findings are published as Knowledge Catalog aspects and to Security Command Center.
2. Automated enforcement. SDP findings at or above HIGH sensitivity trigger automatic policy tag application and IAM restriction via [___ Cloud Function / Pub/Sub workflow].
3. Steward review. A data steward reviews automated classifications within [___ 5 / 10] business days and confirms or adjusts the tier assignment.
4. Escalation. Datasets that cannot be classified automatically (novel data types, ambiguous context) are escalated to the data governance lead or data owner for manual classification, with DPO consulted.

Adaptation guidelines

• The number of tiers should match the client's complexity. Five tiers work for large data platforms with diverse consumers. Smaller organizations can collapse to three (High / Medium / Low) without losing clarity.
• The examples column is the most important part to customize — it should list the client's actual data types, not generic placeholders. Run SDP discovery on a representative dataset sample during the engagement to populate this concretely.
• Not every client has SDP or Knowledge Catalog. For on-premises or multi-cloud environments, substitute the automated discovery step with Presidio scans or manual profiling, and the policy tag enforcement with Apache Ranger tag-based masking or equivalent.

---

3. Approved anonymization techniques

Technique selection follows the decision framework below. Only approved techniques may be used in production pipelines.

Decision framework

Question	If yes	If no
Is the field needed in the output?	Continue	Redact — remove the field entirely
Does anyone need to reverse the pseudonym? (DSAR, law enforcement, customer support)	Continue to format check	Continue to join check
Does the downstream system require format compatibility? (legacy validation, schema constraints)	FPE (NIST FF1) — reversible, format-preserving	Deterministic encryption (AES-SIV) — reversible, not format-preserving
Is join capability needed across datasets?	HMAC keyed hash (same input → same pseudonym with consistent key) — irreversible	Continue
Is individual-level analytical utility required?	k-anonymity + l-diversity via generalization	Differential privacy for aggregate outputs

Approved techniques by tier

Tier	Approved techniques	GCP implementation
Critical	HMAC keyed hash, deterministic encryption (AES-SIV), FPE, redaction	SDP CryptoHashConfig, CryptoDeterministicConfig, CryptoReplaceFfxFpeConfig, RedactConfig
High	Same as Critical, plus generalization, temporal bucketing	SDP transforms + custom Dataflow transforms
Medium	Bucketing, generalization, value replacement	SDP BucketingConfig, custom transforms
Low	No transformation required	N/A
Public (external sharing)	Differential privacy, synthetic data with DP training guarantees or documented disclosure-risk assessment (membership inference, attribute inference, nearest-neighbor distance)	Privacy on Beam, Gretel (DP mode), SDV (with disclosure-risk evaluation)

Prohibited practices

• Unsalted hashing (SHA-256, MD5) of finite-domain identifiers (phone numbers, national IDs)
• Dictionary/lookup-table pseudonymization without cryptographic key management
• Anonymization claims without documented re-identification risk assessment
• Use of production personal data in non-production environments without static data masking or synthetic data substitution

Adaptation guidelines

• The decision framework is a starting point. Clients with legacy systems that cannot handle format changes will lean heavily on FPE; clients without re-identification requirements can simplify to HMAC + redaction only.
• The "prohibited practices" list is where real engagement value lies — it documents hard-won lessons about what doesn't work. Add client-specific prohibitions based on their current practices (e.g., "no use of the existing dictionary-based anonymization system for new pipelines").
• For clients not on GCP, replace the "GCP implementation" column with their platform equivalents (e.g., AWS Macie + Glue for detection/transformation, Azure Purview for classification).

---

4. Data zones and access control

Data is organized into zones with progressively stronger privacy guarantees. Access policies widen as privacy guarantees strengthen.

Zone	Content	Access	Retention
Raw	Unmodified source data with full PII	Ingestion pipelines and break-glass only. VPC-SC enforced.	[___ 7 / 14 / 30] days — kept only for reprocessing
Pseudonymized	Direct identifiers replaced; quasi-identifiers at original granularity	Data engineering (full), analysts (masked via DDM), ML pipelines	[___ 6 / 12 / 24] months, per data classification
Anonymized	Structurally anonymized (k-anonymity) and/or DP aggregate outputs	Broad internal — business users, dashboards	[___ Years / indefinite] (outside GDPR scope if truly anonymous)
External	DP-guaranteed aggregates, synthetic data	Partners, regulators, data monetization	Per sharing agreement

Data flow is unidirectional: raw → pseudonymized → anonymized → external. No reverse path. IAM prevents write access from downstream zones to upstream zones.

Adaptation guidelines

• Three zones (raw / pseudonymized / anonymized) are sufficient for most internal-only architectures. Add the fourth "External" zone only when data leaves the organization — see Module 06 for the rationale.
• Retention periods are the most contentious part of the policy. Engineering wants long retention for debugging; legal wants short retention for risk reduction. Set raw-zone retention as short as operationally feasible (days, not months). Pseudonymized-zone retention depends on the data classification and business requirements.
• Some clients have existing zone-like structures (e.g., "bronze / silver / gold" data tiers) — map the anonymization zones onto the existing model rather than introducing a parallel structure.

---

5. Key management

Key architecture

Key type	Purpose	Protection	Rotation
KEK (key encryption key)	Wraps DEKs via envelope encryption	Cloud KMS, HSM protection level	[___ 90] days, automatic
DEK (data encryption key)	Used directly by pseudonymization transforms	Wrapped by KEK; plaintext only in pipeline memory	[___ 6–12] months, coordinated
HMAC key	Irreversible keyed hashing	Cloud KMS or Secret Manager	Rare — rotation invalidates all existing pseudonyms

Key rotation validation

After each rotation, a validation job must confirm (checks differ by key type):

KEK rotation:

• New KEK version is active and accessible by the pipeline service account
• Wrap/unwrap round-trip of an existing DEK succeeds with the new KEK version
• Validation result is logged to the governance metadata table

DEK rotation:

• New DEK produces valid pseudonymized output on a sample record
• Re-identification of a test record succeeds with the new DEK (for reversible transforms)
• Validation result is logged to the governance metadata table

Crypto-shredding for right to erasure

When per-subject DEKs are in use, right-to-erasure requests (GDPR Article 17) are fulfilled by deleting the subject's wrapped DEK record (not the shared KMS key, which would affect all subjects). This makes the key-protected fields undecryptable; if the record also contains unencrypted quasi-identifiers or groupable deterministic ciphertext, assess whether those residual fields independently identify the subject and supplement with physical deletion or generalization as needed.

1. Look up the data subject's wrapped DEK record in the protected keyset table
2. Delete the DEK record (the backing store's recovery window acts as a safety net against accidental deletion)
3. Assess residual identifiability of remaining unencrypted fields; delete or generalize if needed
4. Log the deletion event to the DSAR case log
5. After the backing store's recovery and fail-safe windows expire (e.g., [___ 14] days for BigQuery), verify the DEK is unrecoverable and confirm erasure of key-protected fields is complete

Adaptation guidelines

• If the client uses HMAC (irreversible) exclusively and has no re-identification requirement, the key management section simplifies significantly — no per-subject DEKs, no crypto-shredding workflow. Right to erasure must then be handled via physical record deletion.
• HSM protection level for KEKs is recommended but adds cost. For clients in non-regulated industries with lower threat profiles, SOFTWARE protection level may be acceptable — document the risk trade-off explicitly.
• Rotation periods depend on regulatory requirements and risk appetite. PCI DSS v4.0.1 (Requirement 3.7.4) requires key retirement at the end of an organization-defined cryptoperiod — it does not prescribe a specific interval, so define one based on NIST SP 800-57 guidance and the data's sensitivity. Match the rotation schedule to the client's compliance obligations.

---

6. Pipeline monitoring

Required monitoring signals

Signal	Alert tier	Response
Schema drift (new field not in SDP template)	P1 — Page	Pipeline halts; investigate and update SDP template
Transform failure on Critical/High field	P1 — Page	Immediate investigation; quarantine failed records
Key destruction outside DSAR workflow	P1 — Page	Verify authorization; potential security incident
Volume anomaly > 2σ from baseline	P2 — Ticket	Next business day investigation
Key rotation overdue	P2 — Ticket	Schedule rotation within [___ 5] business days
SDP match rate deviation > 10%	P2 — Ticket	Investigate upstream data changes
DP budget consumption trending toward limit	P3 — Dashboard	Review in governance meeting
Re-identification risk score increasing	P3 — Dashboard	Review in governance meeting

SDP discovery integration

SDP discovery findings are published to:

• Security Command Center — HIGH/CRITICAL findings generate incidents for triage
• BigQuery — profile history for trend dashboards and audit evidence
• Pub/Sub — threshold-filtered events trigger automated remediation workflows
• Google SecOps — SIEM correlation with other security events

Adaptation guidelines

• The three-tier alert model (Page / Ticket / Dashboard) is a starting point. Adjust to match the client's existing incident management tiers and tooling (PagerDuty, Opsgenie, ServiceNow, etc.).
• Schema drift is the most commonly overlooked signal. If the client's upstream data sources change frequently (common in telco BSS/OSS migrations), make schema validation a hard gate — pipeline halts on any unrecognized field. If upstream schemas are stable, a softer approach (alert + continue, with the unknown field redacted by default) may be more practical.
• Not all clients need all eight signals from day one. Start with the P1 signals (schema drift, transform failure, unauthorized key destruction) and add P2/P3 monitoring as the platform matures.

---

7. Data lineage and audit

Pipeline run metadata

Every anonymization pipeline run must record:

• Pipeline run ID (Dataflow job ID)
• SDP de-identification template ID
• KMS key version used
• Input source and output destination
• Record counts (input / output / failed)
• Processing timestamp range
• Transform configuration hash (SHA-256 of serialized SDP template)

This metadata is stored in [___ governance.anonymization_runs] with [___ 7-year] retention.

Audit readiness

The following artifacts must be current and available for regulatory inquiry:

• Records of Processing Activities (ROPA) with anonymization-specific entries
• Pre- and post-anonymization re-identification risk assessments, dated
• DPIA completed for high-risk processing operations
• Cloud KMS audit logs exported to long-term storage
• Data Access logs enabled on raw and pseudonymized datasets
• Knowledge Catalog aspects attached to all anonymized data assets
• Lineage graph available for each anonymized dataset

Adaptation guidelines

• Metadata retention should match or exceed the client's regulatory retention obligations. 7 years covers most EU financial regulations; adjust for sector-specific requirements (e.g., healthcare records may require longer retention).
• The audit checklist is designed for a DPA inquiry. Walk through it with the client's legal team during the engagement to confirm nothing is missing for their specific regulatory context.
• For clients not yet using Knowledge Catalog, lineage and aspect metadata can be stored in a dedicated BigQuery governance dataset as a simpler alternative. The key is that the metadata exists and is queryable — the specific tooling is secondary.

---

8. Roles and responsibilities

Decision	Responsible	Accountable	Consulted	Informed
Data classification policy	Data steward	CDO / CPO	DPO, legal, engineering	Executive leadership
Technique selection per field	Data engineering	Data owner	DPO, analytics	Security
Pipeline implementation	Data engineering	Engineering lead	Security, DPO	Data owners
Key rotation schedule	Security / platform	CISO	Engineering, DPO	Data owners
Re-identification risk assessment	Security / privacy	CDO / CPO	DPO, engineering, legal	Analytics consumers
External data sharing approval	Data owner	CDO / CPO	DPO, legal	Analytics consumers
DPIA execution	Privacy / legal	CDO / CPO	DPO, engineering, security	Data owners
Incident response	Security	CISO / CDO	DPO, legal, engineering	Executive, affected subjects

Adaptation guidelines

• Map the generic roles (DPO, Data Steward, Data Owner) to the client's actual organizational structure and job titles. Some organizations have a dedicated privacy team; others distribute privacy responsibilities across existing roles.
• Smaller organizations may combine roles — one person may be both data steward and DPO. The RACI still helps by making the accountability explicit even when the same person fills multiple boxes.
• The "Accountable" column is the critical one to validate with the client. Every row must have exactly one accountable party who can make the final call. If accountability is unclear or shared, escalation paths stall.

---

9. Exceptions

All exceptions to this policy must be:

1. Requested in writing with business justification and risk assessment
2. Approved by the CDO / CPO (or delegate for Low/Medium tier exceptions), with DPO consulted
3. Time-boxed — no open-ended exceptions; maximum duration [___ 90] days, renewable
4. Logged in the exception register with approval date, expiry, and conditions
5. Reviewed at each policy review cycle; expired exceptions are closed automatically

Adaptation guidelines

• The exception process is where policies survive contact with reality. Without it, teams route around the policy informally and undocumented exceptions accumulate. Keep the process lightweight enough that people actually use it — a Jira ticket with a template is better than a formal committee review for most exceptions.
• Adjust the approval authority based on risk tier. Low/Medium exceptions can be delegated to a data steward or engineering lead; Critical/High exceptions should require CDO/CPO approval with DPO advisory input.
• The maximum exception duration depends on the client's risk appetite. 90 days with mandatory renewal prevents permanent exceptions from accumulating, but some clients in slower-moving environments may prefer 180 days.

---

10. Incident response

Re-identification event response

Phase	Actions	Timeline
Detection	Identify the re-identification vector (quasi-identifier linkage, key compromise, external disclosure)	Immediate
Containment	Revoke access to affected dataset; suspend data sharing agreements; if key compromise: create a new CryptoKey, revoke pipeline access to the old one, and migrate data via a dedicated migration workload (rotating within the same CryptoKey does not contain the compromise — IAM is per-CryptoKey)	First 4 hours
Assessment	Determine scope (individuals affected), mechanism, and whether this constitutes a GDPR personal data breach	First 24 hours
Notification (authority)	If breach likely to result in risk: notify supervisory authority (Article 33). If unlikely to result in risk: document internally only.	Where feasible, within 72 hours of awareness
Notification (individuals)	If high risk to individuals: notify affected data subjects (Article 34)	Without undue delay
Remediation	Re-anonymize with stronger parameters; update SDP template; rotate keys; conduct fresh DPIA	Days to weeks
Review	Root cause analysis; update policy and monitoring to prevent recurrence	Within 30 days

Adaptation guidelines

• Integrate with the client's existing incident response process rather than creating a parallel one. Most organizations already have a security incident workflow — the anonymization-specific steps (revoke dataset access, assess re-identification scope, determine GDPR breach threshold) plug into the existing framework.
• The 72-hour notification timeline is a GDPR Article 33 target ("where feasible" — delays must be justified). Clients under other regulations may have different timelines (e.g., California SB 446, effective January 2026, introduced 30-day resident notification and AG submission deadlines for breaches affecting 500+ residents). Adjust the timeline column to the client's applicable regulations.
• Tabletop exercises are worth recommending — walk through a hypothetical re-identification scenario with the incident response team before a real one happens. The assessment phase ("is this a GDPR breach?") is where most teams struggle without prior practice.

---

Document history

Version	Date	Author	Change summary
1.0	[___ YYYY-MM-DD]	[___ Author]	Initial policy