Client Engagement Reference
Lookup reference for anonymization engagements — from the first presales call through delivery. Restructured from Module 13 for quick access during meetings and engagement planning.
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; DP = differential privacy.
How to use this module: Follow the engagement flow top-to-bottom. Recognize the client's scenario → run discovery → build the business case → plan the phased roadmap → map deliverables. Each section links to the next step.
Recognize the scenario
The client's opening statement tells you which playbook to reach for. Match what you hear to the right scenario, then jump to its card in the scenario playbook.
| When you hear... | They mean... | Scenario |
|---|---|---|
| "We want to unlock our data for analytics" / "Our data scientists can't access the data they need" | Valuable data locked behind access restrictions. Want broader internal use without per-use-case approvals. | "We need to anonymize for analytics / ML" |
| "We're migrating to the cloud" / "We need to handle PII in our GCP landing zone" | Migration is the primary initiative; anonymization surfaced during planning. Client needs guidance. | "We're migrating to GCP" |
| "We need to share data with a partner" / "A regulator wants aggregate data" | A third party wants access to the client's data. Highest-bar scenario. | "We want to share data with third parties" |
| "We have pseudonymization but I'm not sure it's adequate" / "It's a lookup table" | Legacy dictionary-based system. Only direct identifier substitution; quasi-identifiers untouched. | "Our current anonymization is a lookup table" |
| "The DPA sent us a letter" / "We have an audit coming up" | Regulator asking questions. They need documentation, evidence, and defensible answers. | "We need to prove compliance" |
| Multiple drivers / unclear | Don't force a scenario — run full discovery first. | Discovery checklist |
Next step: Whichever scenario you land on, run through the discovery checklist before making any recommendation.
Discovery checklist
Run through these five questions before making any recommendation. Can be covered in a 30-minute scoping call or a two-day workshop — the depth varies, the questions don't.
| # | Question | What you're looking for | Red flags | If you see the red flag... |
|---|---|---|---|---|
| 1 | What data do you have, and where does it live? | Systems touching PII, field classification (direct/quasi/sensitive), data flows between systems | No complete data inventory; PII in logging/staging/dev environments nobody remembers | Run SDP discovery on GCP environments to accelerate inventory. Flag untracked PII as a Phase 0 quick win — it's the highest risk they don't know about. |
| 2 | What regulations apply? | GDPR, ePrivacy, sector-specific (AMLD, telecom law), jurisdictional complications | No documented lawful basis; "consent" that doesn't meet GDPR standard; "it's anonymized so GDPR doesn't apply" | Challenge the claim directly — see risks-and-failures mistake #1. Map regulations using the industry reference § vertical quick reference. |
| 3 | What have you already done? | Current anonymization approach, key/dictionary storage, access controls, rotation policy, QI treatment | Dictionary-based pseudonymization; unsalted hashing; no structural anonymization of quasi-identifiers | Walk through the 12-mistake diagnostic checklist — most legacy systems exhibit 3–5 of these patterns. |
| 4 | What do you need the data for? | Use cases mapped to data zones: operational (Zone 0), internal analytics (Zone 1–2), external sharing (Zone 3) | Single "anonymized" dataset serving all purposes; no differentiation by use case or threat model | Explain the zone model — see architecture patterns. A single dataset for all purposes is mistake #12. |
| 5 | What's the timeline, and what's driving it? | Regulatory deadline, business opportunity, modernization initiative; internal sponsor; budget authority | No clear sponsor; compliance deadline without budget | A deadline without a sponsor means the project will stall. Identify who has budget authority before scoping the technical work. |
Discovery outputs
| Output | Contents | Feeds into |
|---|---|---|
| Data flow and classification map | Source → transformation → destination, PII tier per field | Architecture recommendation |
| Gap analysis | Current state vs. target state mapped to four-zone architecture; highest-risk gaps | Prioritized roadmap |
| Regulatory and lawful basis summary | Applicable regulations, lawful basis per data flow, documentation gaps | Technical and governance recommendations |
| Prioritized remediation roadmap | Sequenced by risk severity × implementation complexity; quick wins first | Phased delivery plan |
Next step: Use discovery outputs to build the business case, then plan the phased roadmap.
Scenario playbook
Each scenario card gives you: what the client actually means, where to start, what to ask, what to recommend, and the quickest win. After identifying the scenario, always run discovery before committing to an approach.
"We need to anonymize for analytics / ML"
| Dimension | Detail |
|---|---|
| What they actually mean | Valuable data locked behind access restrictions or regulatory constraints. Want broader internal use without per-use-case approvals or DPIAs. |
| Where to start | Four-zone architecture — client typically has Zones 0–1 but nothing beyond. |
| Key questions to ask | What analytical fidelity is required? Aggregates or record-level? How many distinct use cases? Internal only or external sharing? |
| Recommended approach | Zone 2: k-anonymity + l-diversity on generalized dataset for internal BI. Zone 3: DP via Privacy on Beam / PipelineDP / BigQuery DIFFERENTIAL_PRIVACY for external aggregates. For ML training requiring record-level data: synthetic data (Gretel in DP mode for formal guarantees; SDV with membership inference testing). ARX for batch structural anonymization. |
| Central design conversation | Privacy-utility trade-off — what fidelity loss is acceptable for the analytics use case? |
| Typical deliverables | Architecture recommendation, technique one-pager |
| Quick win | Add BigQuery policy tags + DDM rules to most sensitive columns for immediate access differentiation |
"We're migrating to GCP"
| Dimension | Detail |
|---|---|
| What they actually mean | Migration is the primary initiative; anonymization surfaced as a requirement during planning. Client may not have a strong opinion — they need guidance. |
| Where to start | Landing zone design — opportunity to build anonymization correctly from the start. |
| Key questions to ask | Migration timeline? Which datasets contain PII, migrating first or last? Existing anonymization being migrated, or greenfield? GCP services already in scope? |
| Recommended approach | Embed anonymization into data ingestion from day one. SDP de-identification templates in Dataflow, BigQuery policy tags + DDM, Cloud KMS. Four-zone architecture built into the landing zone. |
| Migration-specific note | On-prem Hadoop clients: Apache Ranger → BigQuery column-level security migration path (see Module 05). |
| Typical deliverables | Architecture recommendation (part of landing zone design), anonymization policy |
| Quick win | Enable SDP discovery on the first migrated datasets to catch unclassified PII immediately |
"We want to share data with third parties"
| Dimension | Detail |
|---|---|
| What they actually mean | A partner, regulator, or researcher wants access. Highest-bar scenario — strongest guarantees required. |
| Where to start | Zone 3 of the architecture. Conservative threat model: unknown attacker capabilities, unknown auxiliary data, no access controls on recipient's side. |
| Key questions to ask | Who is the recipient, and what will they do with the data? What fidelity — records, aggregates, or statistical properties? One-time or ongoing? Data clean room an option? |
| Recommended approach | Aggregates → DP. Record-level for ML → DP-trained synthetic data (Gretel in DP mode for formal guarantees; non-DP generators like SDV require full membership inference testing before external release and do not qualify for Zone 3). Joint analysis → BigQuery Data Clean Rooms. Highly sensitive processing without raw data exchange → Confidential Space (TEE-based computation safeguard — protects data during processing but outputs may still be personal data; pair with DP or synthetic data for anonymized outputs). |
| Critical risk | Composition risk if sharing is ongoing — track cumulative privacy budget across releases. |
| Typical deliverables | Architecture recommendation, technique one-pager, regulatory briefing (recipient's jurisdiction) |
| Quick win | Run ARX risk analysis on current "anonymized" output — the prosecutor risk number is powerful evidence |
"Our current anonymization is a lookup table"
| Dimension | Detail |
|---|---|
| What they actually mean | Legacy dictionary-based pseudonymization — flat file or database mapping identifiers to pseudonyms. Only direct identifier substitution; quasi-identifiers untouched; dictionary is a single point of failure. |
| Where to start | The 12-mistake diagnostic checklist. This scenario maps directly to the progression from dictionary substitution to layered privacy. |
| Key questions to ask | How is the dictionary stored and who has access? Key rotation policy? Blast radius if compromised? Quasi-identifiers addressed at all? Re-identification risk ever measured? |
| Recommended approach | Phase 1: replace dictionary with keyed HMAC or FPE via SDP + Cloud KMS (highest-risk, lowest-effort fix). Phase 2: add structural anonymization (k-anonymity on quasi-identifiers). Phase 3: add DP on aggregate outputs for external sharing. |
| Typical deliverables | Gap analysis, phased modernization roadmap, architecture recommendation |
| Quick win | Replace unsalted hashing with keyed HMAC via Cloud KMS — immediate risk reduction. Note: HMAC produces different pseudonyms than the old hashes, so downstream joins and consumers need coordinated backfill or dual-read migration (see architecture patterns § key rotation). |
"We need to prove compliance"
| Dimension | Detail |
|---|---|
| What they actually mean | DPA inquiry, scheduled audit, or proactive compliance demonstration. They need documentation, evidence, and defensible answers. |
| Where to start | Governance framework + operational evidence. See the audit readiness checklist. |
| Key questions to ask | What has the regulator specifically asked for? What documentation exists? Is there a DPO or privacy lead owning the response? Timeline? |
| What regulators ask for | Anonymization policy, ROPA, DPIAs for high-risk processing, re-identification risk assessment evidence, audit trails (who accessed what), key management documentation. |
| Recommended approach | Start with documentation gaps. Anonymization policy template as starting point. Technical evidence: Cloud Audit Logs, ARX risk analysis for quantified re-identification risk, SDP discovery for continuous classification evidence. Goal: defensible paper trail. |
| Typical deliverables | Anonymization policy, regulatory briefing, risk assessment report |
| Quick win | Document the anonymization policy using the template — immediate governance evidence even before technical improvements |
Next step: Use the scenario's recommended approach to build the business case for the client's stakeholders.
Business case building blocks
Value framing by stakeholder
| Stakeholder | Frame anonymization as... | Key argument |
|---|---|---|
| CDO / Head of Data | Data platform enabler | Anonymized datasets unlock cross-team analytics without per-use-case access approvals — data becomes a platform asset, not a locked resource |
| CTO / VP Engineering | Technical risk reduction | Replaces ad-hoc PII handling with systematic architecture — reduces operational burden and incident blast radius |
| CFO / Finance | Revenue enabler + risk mitigation | Enables data monetization, partner sharing, and data products. Reduces regulatory fine exposure and audit costs |
| DPO / Legal | Compliance enabler | Documented policy, measured risk, audit trails. Moves from "we think it's compliant" to "here is the evidence" |
| CISO / Security | Attack surface reduction | Proper anonymization reduces breach blast radius — structurally anonymized data in Zone 2+ significantly limits re-identification risk even if exfiltrated (bounded by k-anonymity parameters and threat model) |
Quick wins vs. strategic investment
| Quick wins (days to weeks) | Strategic investment (quarters) |
|---|---|
| Add BigQuery policy tags + DDM rules to most sensitive columns | Implement full four-zone architecture with SDP pipelines |
| Replace unsalted hashing with keyed HMAC via Cloud KMS | Add structural anonymization (k-anonymity) to analytics zone |
| Enable SDP discovery to detect unclassified PII | Build DP-guaranteed output pipelines for external sharing |
| Document the anonymization policy (use template) | Establish governance roles, RACI, periodic review cadence |
| Run ARX risk analysis on current "anonymized" output | Implement automated privacy testing in the pipeline |
Quick wins reduce the highest-risk gaps immediately and build internal credibility for the larger program. A risk analysis showing prosecutor risk of 15% on the current "anonymized" dataset is a powerful argument for strategic investment.
Next step: Translate the business case into a phased implementation roadmap.
Phased implementation roadmap
Default phasing for a legacy-system modernization. Adapt the entry point and sequencing to the client's scenario.
| Phase | Scope | Duration | Key deliverable |
|---|---|---|---|
| 0 — Discovery + quick wins | Discovery process, gap analysis, immediate fixes (policy tags, DDM rules, HMAC replacement) | 2–4 weeks | Gap analysis + measurable risk reduction |
| 1 — Foundation | Core pipeline (SDP templates, Cloud KMS, BigQuery zones, policy tags, IAM), SDP discovery, Cloud Audit Logs, anonymization policy | 1–2 months | Functioning Zone 0 → Zone 1 pipeline |
| 2 — Structural anonymization | Zone 2: k-anonymity + l-diversity, generalization hierarchies, ARX or equivalent, automated privacy checks (PII scanning, k-threshold assertions, drift detection) | 1–2 months | Zone 2 dataset for broad internal analytics |
| 3 — External outputs + DP | Zone 3: DP on aggregates (Privacy on Beam / PipelineDP / BigQuery DP), DP-trained synthetic data for ML (non-DP synthetic requires full MIA validation and does not qualify for Zone 3), DP budget tracking | 1–2 months | Formally private output channel |
| 4 — Governance + operations | RACI matrix, re-assessment cadence, re-identification risk testing schedule, incident response procedures | Ongoing (parallel to 1–3) | Mature governance framework |
Adapting the phasing by scenario
| Scenario | Adaptation |
|---|---|
| GCP migration | Embed Phases 0–1 into landing zone design |
| Data sharing | Prioritize Phase 3 delivery (partner deadline drives timeline), but build a minimum Phase 0–1 foundation first — DP aggregation requires Zone 1 (pseudonymized) data as input |
| Compliance | Start with Phase 4 (documentation + policy); address Phases 1–3 in parallel |
| Analytics/ML | Standard phasing; Phase 2 is the primary value delivery |
| Legacy modernization | Standard phasing; Phase 1 is the highest-risk fix |
Next step: For each phase, identify which deliverables the client needs.
Deliverable mapping
| Client need | Deliverable type | Template | Primary KB modules for LLM drafting |
|---|---|---|---|
| Understand a specific technique | Technique one-pager | one-pager-technique | 03, 05; supporting: 04, 07 |
| Understand a regulation's implications | Regulatory briefing | one-pager-regulatory | 01, 02; supporting: 11 |
| Proposed anonymization architecture | Architecture recommendation | one-pager-architecture | 06, 05; supporting: 07, 10, 11 |
| Formal organizational policy | Anonymization policy | anonymization-policy | 09; supporting: 10, 06 |
| Current state vs. target state | Gap analysis | No template — follows discovery outputs | 02, 06, 12 |
| Measured re-identification risk | Risk assessment report | ARX output + narrative summary | 02, 12; supporting: 04 |
| Phased delivery plan | Modernization roadmap | Use phased roadmap as skeleton | 06, 07, 11; supporting: 03, 12 |
Quality checklist for client-facing deliverables
Before any anonymization deliverable goes to a client:
- All regulatory statements verified against current regulation text (not just KB content)
- GCP service names, configurations, and pricing are current (cloud services evolve)
- Technique recommendations match the client's actual data types and use cases (verify against the techniques reference)
- Architecture diagrams reflect the client's specific GCP environment (not generic)
- Risk quantification uses the client's data, not generic examples
- Anonymization claims are justified — no unsupported "this is anonymized" assertions
- Audience-appropriate tone — technical detail for engineers, business framing for executives
- Quick wins are genuinely achievable in the stated timeframe for this client
- Template adaptation guidance (:::tip[Adapt] blocks) has been replaced with client-specific content
LLM-assisted drafting quick reference
Use the full knowledge base as LLM context for drafting client deliverables. Load all learning path modules (01–13), the glossary, and the relevant template. See Module 13 § Using this knowledge base as LLM context for the full workflow.
Key rules:
- Use an approved enterprise LLM environment — no raw client PII, credentials, or confidential architecture in prompts
- Provide sanitized context: the client's vertical and data types, not actual identifiers or production configs
- Point the LLM to the relevant template as the output structure
- Every factual claim must be verified by the engineer before the deliverable reaches the client