Governance and Operations Reference
Checklists, RACI, monitoring signals, incident response, and decision frameworks for anonymization governance and operations. Restructured from Module 09 and Module 10 for quick lookup during engagement setup and ongoing operations.
Abbreviations used throughout: SDP = Sensitive Data Protection; HMAC = keyed-hash message authentication code; FPE = format-preserving encryption; DDM = dynamic data masking; ARX = open-source structural anonymization tool; MSISDN = subscriber phone number; IMSI = SIM card identifier; IMEI = device identifier.
Quick navigationโ
| I need to... | Jump to |
|---|---|
| Set up a new anonymization project | Pre-anonymization checklist |
| Decide whether to anonymize or process with safeguards | Anonymize vs. safeguards decision framework |
| Write or review an anonymization policy | Anonymization policy โ uses the policy template |
| Classify data by sensitivity | Classification taxonomy |
| Define who owns what | RACI matrix |
| Set up pipeline monitoring | Monitoring signals + Alert tiers |
| Check key rotation schedule | Key rotation schedule |
| Respond to a privacy incident | Incident response |
| Track lineage and audit trails | Lineage and audit trail |
| Prepare for a regulator audit | Audit readiness checklist |
| Run ongoing pipeline ops checks | Pipeline operations checklist |
Pre-anonymization checklistโ
Before starting an anonymization project:
- Data inventory completed โ all systems touching PII identified; fields classified (direct/quasi/sensitive)
- Regulatory landscape mapped โ applicable regulations, lawful bases, jurisdictional complications documented (see industry reference ยง vertical quick reference for regulation-by-vertical overview)
- Current-state assessment done โ existing anonymization approach documented; gaps identified against the 12-mistake diagnostic checklist
- Use cases mapped to zones โ each data consumer mapped to the appropriate zone (0โ3) based on threat model (see architecture patterns)
- Techniques selected per field โ approved technique assigned to each field based on classification tier and zone target (see techniques reference)
- Key management designed โ KEK/DEK hierarchy, protection level, rotation policy, crypto-shredding approach decided (see architecture patterns ยง key management)
- Anonymization policy drafted โ using the policy template; covers all 7 policy areas below
- RACI agreed โ classification, technique selection, implementation, key management, risk assessment roles assigned (see RACI matrix)
- Stakeholders aligned โ DPO, legal, engineering, data owners, security all briefed and in agreement
- Success criteria defined โ target k-values, ฮต budgets, risk thresholds, acceptance criteria for privacy testing
For smaller teams: the minimum viable pre-project checklist is items 1 (data inventory โ even a spreadsheet), 3 (current-state assessment), 7 (a 2-page policy), and 10 (success criteria). The remaining items scale with the team and regulatory exposure.
Anonymization policy โ 7 areasโ
Start from the anonymization policy template, which provides ready-to-adapt content for each area.
| Area | What it defines | Owner |
|---|---|---|
| Scope | Covered datasets, systems, data flows; exclusions | Data governance lead |
| Classification scheme | Sensitivity tiers + assignment criteria | Data governance lead + stewards (DPO advises) |
| Approved techniques | Sanctioned techniques per tier and use case | Data engineering + security |
| Zone mapping | Which data zone each dataset belongs to | Data architecture |
| Retention rules | Duration per zone (raw: days; pseudo: per classification; anon: indefinite if anonymous) | Legal + data governance |
| Exception handling | Request process, approval, tracking, time-boxing | CDO/CPO (DPO advises) |
| Review cadence | Annual minimum + triggered reviews (regulatory changes, incidents, architecture changes) | DPO + data governance lead |
A 2-page internal wiki page covering: which fields are PII, which technique applies to each, and who approves exceptions. Formal exception handling and triggered reviews are acceptable to skip if the team is small enough that decisions are made in conversation. See Module 09 ยง Scaling down for the full lightweight alternative.
Classification taxonomyโ
| Tier | Data types (telco examples) | Anonymization requirement | Access scope |
|---|---|---|---|
| Critical | Raw MSISDN, IMSI, IMEI, subscriber name, billing address | Pseudonymized or redacted before leaving raw zone | Break-glass only |
| High | IP address, precise location (cell ID), call content, SMS text | Pseudonymized Zone 1; generalized/suppressed Zone 2 | Data engineering (masked for analysts) |
| Medium | Call duration, data volume, service type, device model | Bucketed or generalized in Zone 2 | Analysts with DDM |
| Low | Cell cluster ID (post-generalization), time bucket, aggregated counts | No further transformation needed | Broad internal |
| Public | Network coverage maps, aggregate stats with DP | Safe for external sharing | Unrestricted |
Collapse to three tiers (High / Medium / Low). Manual classification in a spreadsheet. SDP inspection jobs on-demand for validation. What matters is that every data field the pipeline touches has an assigned tier.
RACI matrixโ
| 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 (business) | DPO, analytics | Security |
| Pipeline implementation | Data engineering | DE lead | Security, DPO | Data owners |
| Key rotation schedule | Security/platform | CISO | DE, DPO | Data owners |
| Re-ID risk assessment | Security/privacy | CDO/CPO | DPO, DE, legal | Analytics consumers |
| External data sharing approval | Data owner | CDO/CPO | DPO, legal | Analytics consumers |
| DPIA execution | Privacy/legal | CDO/CPO | DPO, DE, security | Data owners |
| Incident response | Security | CISO/CDO | DPO, legal, DE | Executive, affected subjects |
Collapse to two roles: (1) one person owns the pipeline, classification, and monitoring โ makes and documents the technical decisions; (2) a second controller-side person (CTO, founder) reviews privacy classification and approves external sharing. If the org has a DPO (or uses DPO-as-a-service, available from ~โฌ200/month), the DPO advises both roles but doesn't own the approval.
Anonymize vs. safeguards decision frameworkโ
Technical safeguards (when processing personal data without anonymization)โ
| Safeguard | Mitigates | GCP implementation |
|---|---|---|
| VPC Service Controls | Data exfiltration | VPC-SC perimeters |
| Data regionality | Cross-border transfer risk | BigQuery dataset location, regional endpoints |
| No-training guarantees | Model memorization | Google CDPA, Vertex AI settings |
| Purpose limitation | Scope creep | IAM roles, authorized views, policy tags |
| Audit logging | Accountability gap | Cloud Audit Logs (Admin Activity + Data Access) |
| Retention controls | Data accumulation | Table expiration, GCS lifecycle rules |
| Pseudonymization | Re-identification risk | SDP transforms (HMAC, det. enc.) |
Minimum safeguards for a small team: IAM with least-privilege + BigQuery Data Access audit logs (on by default) + data regionality (EU). Add VPC-SC when complexity grows or principal count exceeds what's manageable by manual review.
Monitoring signalsโ
| Signal | What it catches | Detection method | Severity |
|---|---|---|---|
| Schema drift | New PII column bypassing transforms | Compare incoming schema vs SDP template field list | Critical |
| Transform failure rate | Records where anonymization failed | Count failed vs successful per batch; alert on non-zero for Critical/High | Critical |
| Output PII leakage | Raw PII in output (silent transform failure) | SDP inspection on output dataset; exclude FPE fields | Critical |
| Volume anomaly | Pipeline failure or upstream change | Statistical comparison vs historical counts (> 2ฯ deviation) | High |
| Key expiration | Key approaching rotation deadline | KMS metadata vs policy cryptoperiod | High |
| Privacy budget consumption | DP epsilon approaching exhaustion | Track cumulative epsilon vs allocated budget | High |
| SDP match rate change | Upstream content changed | Track InfoType findings ratio over time (> 10% deviation) | Medium |
| Re-ID risk drift | Anonymized output becoming less anonymous | Periodic ARX risk scoring on Zone 2 | Medium |
Alert tiersโ
| Tier | Trigger | Response | Channel |
|---|---|---|---|
| P1 โ Page | Schema drift; transform failure on Critical/High; key destruction outside DSAR | Immediate investigation; pipeline may auto-halt | PagerDuty / on-call |
| P2 โ Ticket | Volume anomaly > 2ฯ; key rotation overdue; SDP match rate deviation > 10% | Next business day | Jira / ticketing |
| P3 โ Dashboard | DP budget trending; re-ID risk increasing; new Medium findings | Weekly governance review | Looker dashboard |
Key rotation scheduleโ
| Key type | Typical rotation | Automation | Impact |
|---|---|---|---|
| KEK | 90 days (CIS default) | Cloud KMS automatic rotation | Non-disruptive; old versions still unwrap existing DEKs |
| DEK (pseudonymization) | 6โ12 months | Coordinated migration; re-encrypt entire pseudo zone | Disruptive โ breaks joins until re-pseudonymized |
| HMAC key | Rarely | Manual; all downstream must switch simultaneously | Permanent continuity break; deliberate lifecycle event only |
Incident responseโ
Containment (first 4 hours)โ
- Revoke access to affected dataset (remove IAM bindings)
- Suspend data sharing agreements relying on compromised anonymization
- If key compromise: create NEW CryptoKey (not just rotate version); rotate compromised credentials; revoke pipeline access to old key
- Notify external recipients to suspend use
- Preserve evidence โ don't modify affected data
- After migration verified: disable old key versions, schedule destruction
Assessment (first 24 hours)โ
- Is data personal under GDPR? If any individual identifiable โ yes
- How many individuals affected? Scope drives notification obligations
- Does this qualify as Art. 33 breach? Distinguish never-truly-anonymous vs identifiability-changed
Remediation (days to weeks)โ
- Re-anonymize with stronger parameters
- Rotate keys if HMAC/FPE compromise
- Update SDP template; conduct fresh DPIA
- Update data recipient contracts
Breach notification thresholdsโ
| Threshold | Obligation | Timeline |
|---|---|---|
| Unlikely to result in risk | Document internally only | No external notification |
| Likely to result in risk | Notify supervisory authority (Art. 33) | Within 72 hours |
| Likely to result in HIGH risk | Notify authority AND individuals (Art. 34) | 72h (authority); without undue delay (individuals) |
Post-incident root causes and preventive controlsโ
| Root cause | Preventive control |
|---|---|
| Insufficient generalization | Re-ID risk testing before release; higher k values |
| Unsalted hashing | HMAC with secret key; never plain hash for finite domains |
| Quasi-identifier undercount | Comprehensive QI analysis; linkage testing |
| Key/vault compromise | HSM-backed keys; separation of key admin/use roles; access logging |
| Schema drift | Schema validation at ingestion; pipeline halt on unknown fields |
| Temporal accumulation | DP budget tracking across releases |
Lineage and audit trailโ
Run-level metadataโ
| Field | Source | Purpose |
|---|---|---|
| Pipeline run ID | Dataflow job ID | Links records to execution |
| SDP template ID | Template resource path | Identifies transform config (mutable โ use config hash) |
| KMS key version | Key ring/key/version | Proves which key encrypted |
| Input source | Pub/Sub topic, GCS path, source table | Data provenance |
| Output destination | BigQuery table | Where data landed |
| Record count (in/out/failed) | Pipeline counters | Completeness check |
| Timestamp range | Processing window | Scopes audit period |
| Transform configuration hash | SHA-256 of serialized template | Detects config drift |
Note: Knowledge Catalog retains lineage data for only 30 days โ export to permanent store for audit compliance.
Crypto-shredding operational workflowโ
The workflow below covers the per-subject DEK architecture (Approach B in the architecture patterns reference). For other erasure strategies: shared-key HMAC requires physical record deletion across all zones; same-table AEAD keysets (Approach A) require nullifying the keyset column on every affected row.
DSAR received โ Look up subject's wrapped DEK โ Delete DEK record โ Log deletion + start recovery countdown โ After BigQuery time-travel (2โ7d) + fail-safe (7d) expire โ Update ROPA to irrecoverable
BigQuery DEK store: Recovery window is 9โ14 days total (time-travel 2โ7d + fail-safe 7d). Don't log erasure as complete until both windows expire. Other DEK stores (Firestore, Bigtable, Redis-backed durable store): recovery and backup retention windows differ โ base erasure completion on the selected store's configured PITR and backup retention, not the BigQuery defaults.
Audit readiness checklistโ
Before a regulator inquiry or scheduled audit:
- ROPA includes anonymization entries (technique, parameters, privacy model)
- Re-identification risk assessment completed and dated (ARX prosecutor/journalist/marketer risk)
- Pipeline run metadata with SDP template version and KMS key version logged
- Cloud KMS audit logs enabled and exported to long-term storage
- Data Access logs enabled on raw and pseudonymized BigQuery datasets
- DPIA completed for high-risk processing
- Knowledge Catalog aspects on all anonymized assets (or equivalent metadata)
- Lineage graph available per anonymized dataset
- Anonymization policy document current and version-controlled โ see policy template
- Key rotation log showing compliance with policy cryptoperiods
- Incident response plan documented and tested
- RACI documented and communicated to all roles
Pipeline operations checklistโ
Ongoing operational checks for a running anonymization pipeline:
- Monitoring signals configured and alerting (all 8 signals in monitoring signals)
- SDP discovery running continuously; new findings triaged within SLA
- Key rotation on schedule (KEK: 90d, DEK: 6โ12mo โ see key rotation schedule)
- Privacy budget tracked for DP outputs; not approaching exhaustion
- Re-ID risk assessment on Zone 2 output โ quarterly or after schema/data changes
- Schema validation at ingestion โ unknown fields halt pipeline or route to quarantine
- Lineage metadata exported to permanent store (not relying on 30-day Knowledge Catalog retention)
- SDP API quotas monitored โ approaching limits trigger scaling or architecture change
- Cost tracking โ SDP inspection + transformation costs reviewed monthly