Privacy-Enhancing Technologies and Anonymization Questions

Technical safeguards that reduce identifiability: anonymization, pseudonymization, tokenization, differential privacy, and related privacy-enhancing technologies. Covers the difference between anonymized and pseudonymized data, re-identification risk, and when each technique is appropriate. Includes evaluating the privacy-utility tradeoff of a given technical control.

HardTechnical

33 practiced

Design a GDPR-compliant retention and anonymization process for BI datasets that contain PII. Address pseudonymization and tokenization strategies, reversible vs irreversible approaches, key management, access controls, audit logging, retention schedules, impact on analytics utility, and tooling you would use.

Sample Answer

Requirements & constraints:- Minimize exposure of PII while preserving analytics utility for BI: aggregated trends, cohorts, conversion funnels.- Comply with GDPR: lawfulness, purpose limitation, data minimisation, storage limitation, integrity/confidentiality, subject rights (access, rectification, erasure, portability).

High-level approach:- Ingest raw data into a secure raw zone; immediately pseudonymize/tokenize PII before moving to BI-ready zones. Retain reversible mapping only where legally justified and tightly controlled; otherwise use irreversible anonymization for long-term retention.

Pseudonymization vs tokenization:- Pseudonymization: replace identifiers with deterministic hashed IDs (HMAC-SHA256 with secret key) when you need linkability across datasets but not subject identity. Deterministic allows joins; use per-environment salt to prevent rainbow attacks.- Tokenization (reversible): use a token vault (HSM-backed or cloud KMS + secure DB) to map tokens ↔ cleartext. Use only for workflows requiring re-identification (legal requests, support). Access to vault strictly controlled and audited.- Irreversible anonymization: for datasets intended for long-term analytics where re-identification is not needed, apply aggregation, k-anonymity or differential privacy (noise injection) to prevent singling-out.

Key management:- Use cloud KMS/HSM (AWS KMS, Azure Key Vault, Google Cloud KMS) with CMKs. Rotate keys on a schedule (e.g., annually), support key versioning and scheduled re-encryption of small datasets. Store key usage policies, enforce least privilege via IAM roles and key policies.

Access controls & segmentation:- Principle of least privilege (role-based access). BI analysts get access only to pseudonymized BI tables; only Data Stewards and an approved process can request re-identification.- Network-level protections, VPCs, private endpoints to BI tools. Row- and column-level security in DBs (e.g., Snowflake policies, BigQuery authorized views, Redshift IAM).- Masking at query-time for sensitive fields for ad-hoc queries.

Audit logging & monitoring:- Log all access to token vaults, key usage, re-identification requests, data exports, and dashboard downloads. Centralize logs (SIEM) and retain per compliance policy. Alerts for anomalous access patterns.

Retention schedules:- Define retention per data category and business purpose; enforce automated purge workflows. Example: raw PII retention = 30 days; pseudonymized BI dataset = 2 years; anonymized aggregated summaries = 7 years. Implement time-based table partitioning + lifecycle jobs (airflow) to delete or irreversibly anonymize on schedule.- Automate subject rights: erasure requests trigger removal from raw and pseudonymized stores and flag tokens in vault; for irreversible anonymized datasets, document inability to restore.

Impact on analytics utility:- Deterministic pseudonymization preserves user-level analytics (cohorting, LTV) while protecting identity.- Irreversible anonymization reduces granularity — mitigate by using larger cohorts, synthetic data, or differential privacy calibration to balance utility/privacy.- Maintain metadata describing transformations so analysts understand limits.

Tooling stack (examples):- Storage/warehouse: Snowflake / BigQuery / Redshift- Orchestration: Airflow- Token vault / KMS: AWS KMS + AWS CloudHSM or Vault by HashiCorp (with HSM)- Data transformation: dbt (transformations include HMAC, masking)- BI: Looker/Power BI/Tableau with row/column-level security, certified datasets- Monitoring/logging: Splunk/Datadog, Cloud Audit Logs- Privacy tools: Google DP library or OpenDP for differential privacy; ARX/Amnesia for k-anonymity analysis

Operational controls & governance:- Data classification policy, approved transformation catalog, periodic privacy impact assessments (DPIA).- Formal re-identification request workflow with approvals, timeboxed access, audit trails.- Regular privacy/secure-coding training for BI team.

Trade-offs:- Reversible tokens increase risk surface; limit lifetime and access.- Deterministic hashing risks linkage attacks if keys leaked; mitigate via KMS, rotation, salts.- Differential privacy reduces accuracy; tune epsilon for business needs.

This design balances GDPR compliance, operational practicality for BI, and retains analytical value while minimizing re-identification risk.

HardSystem Design

34 practiced

Technical: Provide an approach to anonymize or pseudonymize user identifiers in datasets used for exploratory dashboards without breaking cohort or retention analyses. Discuss hashing, salt management, reversible vs irreversible approaches, and how to allow authorized teams to re-identify when required for support.

Sample Answer

Requirements:- Preserve ability to run cohort/retention analyses (stable pseudonyms across time and datasets).- Protect PII in dashboards for general users.- Allow authorized teams to re-identify for support with strict controls/audit.- Scale to daily ingestion and BI queries.

High-level approach:1. Irreversible pseudonymization for general BI: compute user_id_pseudo = HMAC_SHA256(secret_key, user_id || context) stored in analytics DB. HMAC provides keyed hashing (salt via secret_key) ensuring deterministic stable mapping for cohorts but irreversible without key.2. Salt/key management: use a centrally managed KMS (AWS KMS/GCP KMS). Rotate keys periodically; maintain versioning so old data can still be resolved by retaining older key IDs. Store key metadata, not raw keys, in config service.3. Reversible path for authorized re-identification: keep minimal encrypted mapping table (user_id_pseudo → encrypted_user_id) using envelope encryption (data key encrypted with KMS). Access only via service which enforces RBAC, just-in-time decryption, MFA, and approval workflow. All requests require business justification and are logged.4. Data pipeline: producer → pii stripping service → HMAC pseudonymize → analytics store. Mapping table stored in separate vaulted DB with tighter ACLs and network isolation.5. Audit & governance: full audit trail (who, why, when), automated alerts for bulk re-identification, DSAR workflows.6. Trade-offs:- Irreversible HMAC maximizes privacy but prevents certain support cases unless mapping stored encrypted.- Deterministic mapping necessary for cohorts; don't use per-event random salts.- Key rotation complexity: keep key version per record to allow historical resolution.7. Security best practices:- Least privilege, rotate keys, split duties, encrypt at rest/in transit, anonymize sampled extracts, and include retention/deletion policies.

This design balances analytics utility (stable pseudonyms) with privacy (keyed hashing + encrypted mapping) and controlled re-identification for support.

HardTechnical

45 practiced

Explain how you would implement a privacy-preserving aggregate metric (e.g., daily active users) so that counts below a threshold are redacted or noise-added, while minimizing impact to usefulness for product analytics.

Sample Answer

Requirements & constraints:- Preserve privacy for small counts (redact or obfuscate counts < threshold).- Minimize distortion for analytics (maintain trend fidelity, aggregate accuracy).- Practical for BI stack (SQL, batch/stream ETL, dashboards).- Defend against reconstruction and repeated-query attacks.

Approach (combines deterministic thresholding + differential privacy):1. Pre-aggregation and thresholding - Compute per-entity counts (e.g., unique users per day) in a secure environment. - Apply a minimum threshold k: if raw count < k, either redact (NULL/"<k") or replace with 0 depending on policy. This prevents releasing tiny groups.

2. Add calibrated noise for released counts - Use Laplace (or discrete Geometric for integer counts) noise with parameter calibrated to ε (differential privacy). - For a daily active user (DAU) count, sensitivity = 1 (each user influences one day's count by at most 1). Add Laplace(1/ε). - Choose ε balancing privacy/utility (e.g., ε between 0.1–1 for sensitive data; higher for coarser products).

3. Post-processing for BI usefulness - Clip negative noisy counts to 0. - For dashboards focused on trends, publish smoothed series (e.g., 7-day rolling average) computed after noise to reduce variance. - Provide metadata: ε, k, whether redacted, and expected noise variance so analysts interpret numbers correctly.

Implementation sketch (SQL-like pseudocode):

sql

WITH users_per_day AS (
  SELECT date(event_time) AS day, user_id
  FROM events
  GROUP BY day, user_id
),
raw_counts AS (
  SELECT day, COUNT(user_id) AS dau
  FROM users_per_day
  GROUP BY day
)
SELECT
  day,
  CASE
    WHEN dau < :k THEN NULL
    ELSE G_NOISE_INT(dau, :epsilon)  -- apply discrete geometric/Laplace post-aggregation
  END AS dau_private
FROM raw_counts;

Key trade-offs and protections:- Thresholding prevents releasing tiny groups but can bias small-segment analysis. Mitigate by aggregating (week/month) for small cohorts.- DP noise preserves formal privacy under composition; track cumulative privacy budget for query history and limit interactive queries.- For repeated dashboards, prefer releasing noisy time-series snapshots periodically (batch) rather than allowing arbitrary ad-hoc queries.- Monitor utility metrics (MAE, trend correlation) on synthetic/holdout data to tune ε and k.

Operational considerations:- Implement noise and thresholding in a trusted enclave/ETL layer (not in client-side BI).- Document policies and expose metadata to chart consumers.- Provide analysts with a "privacy sandbox" dataset (higher ε or internal access) for exploration, with strict access control and audit logging.

This hybrid (threshold + DP) yields strong privacy guarantees while keeping aggregated analytics meaningful for product decisions.

Unlock Full Question Bank

Get access to hundreds of Privacy-Enhancing Technologies and Anonymization interview questions and detailed answers.

Join thousands of developers preparing for their dream job.