GDPR Principles and Compliance Questions

The General Data Protection Regulation in depth: the six lawful bases, data subject rights, accountability and records obligations, DPO requirements, and enforcement and fines. Covers how GDPR principles translate into concrete engineering and product controls. Includes controller and processor obligations and demonstrating compliance.

HardTechnical

88 practiced

Summarize key GDPR obligations relevant to machine learning systems: lawful basis, data minimization, purpose limitation, right to erasure, and the right to meaningful information about automated decision-making. For each obligation propose concrete engineering controls, processes, and documentation to ensure compliance in ML pipelines.

Sample Answer

Lawful basis — summary: ML processing must have a lawful ground (consent, contract, legitimate interest, legal obligation, vital interest, public task). Engineering controls/processes:- Controls: Consent capture & provenance system; purpose-tagged data store; consent enforcement middleware that blocks training/inference when consent absent/withdrawn.- Processes: Data intake validation, periodic consent audits, DPIA before new models.- Docs: Consent registry, DPIA, lawful-basis decision log and risk assessment.

Data minimization — summary: Only collect and retain data strictly necessary for the model’s purpose.- Controls: Feature gating, schema-level PII flags, differential privacy/noise injection, sampling & downsampling pipelines; retention TTLs enforced by data lifecycle automation.- Processes: Feature-importance review before including attributes, model input review checklist, periodic dataset pruning.- Docs: Data minimization justification per dataset, feature selection audit trail, retention policy.

Purpose limitation — summary: Use data only for declared purposes.- Controls: Purpose tags enforced by access control (RBAC + attribute-based checks), dataset labels that block cross-purpose joins, model registry with purpose metadata.- Processes: Approval workflow for new uses, re-DPIA for purpose changes, separation of environments (dev/test/prod).- Docs: Purpose declaration, use-case approvals, change logs.

Right to erasure — summary: Individuals can request deletion of their personal data.- Controls: Subject access API that supports forget requests; pseudonymization keys and reversible mapping where needed; model retraining automation to remove affected records or use unlearning techniques (e.g., influence functions, scrubbing).- Processes: SLA-backed erasure workflow, verification & propagation to feature stores, backups, and derived artifacts; risk analysis when full deletion impacts model integrity.- Docs: Erasure procedure, audit trail of requests and actions, model impact reports.

Right to meaningful information about automated decision-making — summary: Individuals must get understandable info about logic, significance, and consequences.- Controls: Explainability tooling integrated into inference (SHAP, LIME, counterfactuals); versioned model cards and datasheets; inference-level logging to reproduce decisions.- Processes: Generate consumer-friendly explanations, human-review escalation for high-risk decisions, periodic user-testing of explanations.- Docs: Model card (purpose, data, performance, limitations), explanation templates, logging & reproducibility playbook.

Cross-cutting governance:- Implement DPIAs for high-risk systems, a model governance board, continuous monitoring (concept drift, fairness, privacy leakage), automated compliance tests in CI/CD, retention and access logs, and incident playbooks.- Keep clear ownership: data steward, ML engineer, privacy officer. Together these controls, processes, and documentation form demonstrable compliance for audits.

HardTechnical

85 practiced

You are responsible for validating that a training pipeline complies with GDPR: detect PII in datasets, ensure deletion requests remove data from feature stores and backups, and measure privacy guarantees if applying DP-SGD. Describe tests, tooling, and auditing steps you would implement to provide verifiable compliance.

Sample Answer

Requirements clarification:- Detect PII in training datasets (structured + unstructured).- Ensure deletion requests remove data from feature stores, model training artifacts, and backups.- If using DP-SGD, measure and record privacy guarantees (ε, δ) per training run.- Produce verifiable audit trail for regulators.

Testing strategy (unit → integration → system):1. PII-detection tests- Unit: run deterministic detectors on synthetic records containing labelled PII variants (emails, names, national IDs, free-text leaks). Assert recall/precision thresholds.- Integration: scan full dataset with multi-engine approach (regex + ML NER + semantic models). Compare/merge results; flag conflicts for manual review.- Tools: Microsoft Presidio / Google DLP / AWS Macie + spaCy / HuggingFace NER ensembles; custom classifiers for domain-specific PII.

2. Deletion propagation tests- End-to-end replay: submit a deletion request (subject id), then run automated job that: a) removes entries from raw store, b) removes derived features in feature store (e.g., Tecton/Feast) via lineage, c) invalidates model training shards and derived datasets, d) schedules backup re-write or tombstone marking.- Assertions: verify no row with subject id exists in raw tables, feature tables, and materialized feature views. Use queries and checksums before/after.- Chaos testing: simulate missed runs, partial failures; assert eventual consistency within SLA.

3. Backups and cold storage- Test: enumerate all backup locations (snapshots, object store versions, archival tapes). For each, assert either deletion or cryptographic render (re-encryption with destroyed keys) conforms to retention policy.- Tools: object versioning APIs (S3 versioning + lifecycle policies), immutable logs of key destruction (KMS, Vault).

4. DP-SGD verification- During training, use established libraries (TensorFlow Privacy / Opacus / PyDP) and the Moments Accountant or Renyi accountant to compute cumulative ε for given noise, clipping, sampling rate, and epochs.- Tests: a) Deterministic replay: given seed, reproduce training config and confirm reported ε,δ values match recorded ledger. b) Robustness: vary micro-batch sampling and noise to ensure accounting behaves as expected. c) Membership-inference empirical test: run attack simulation on held-out examples to measure practical risk; ensure below policy threshold.

Auditing & verifiability- Immutable provenance: record every pipeline run, dataset snapshot id (hash), PII-scan report, deletion request id, affected artifact ids, and DP accounting outputs into an append-only ledger (WORM storage / blockchain-like or signed certificates). Use OpenLineage/Marquez for lineage.- Signed attestation: generate cryptographic signatures for each pipeline step (hash of dataset + code + config) stored in audit DB. Keep reproducible CI jobs for re-running.- Access logs: centralize audit logs (CloudTrail-like) for data access and deletion operations; retain per-regulator retention windows.- Third-party & internal audits: periodic review of detection performance metrics, random spot-checks, and legal attestations.

Operational controls & policy- Data minimization: avoid storing raw sensitive fields where possible; tokenize/hash with reversible mapping held in secure vault only when needed.- Retention & key management: define retention policies; for irrevocable deletion, use key destruction patterns to crypto-erase backups.- Monitoring & alerts: pipeline monitors for stale deletion jobs, PII scan regressions, and unexpected increases in membership-inference risk.

Example concrete test list (automated):- PII-scan regression suite (CI): synthetic PII cases → must detect >= 98% recall.- Deletion E2E test: submit subject id → within SLA, queries return zero hits across raw, feature-store, and materialized datasets.- Backup wipe test: create test object → simulate deletion → confirm object versioning and lifecycle removed or key destroyed.- DP accounting test: run small-scale DP-SGD training with logged hyperparams → computed ε must equal recorded ε within tolerance.- Membership-inference smoke: attack success rate ≤ policy threshold.

Why this approach- Layered detection (regex, ML, enrichment) reduces blind spots.- Lineage-driven deletion ensures all derived artifacts are covered.- Immutable, signed audit records make claims verifiable by internal teams or regulators.- DP accounting + empirical risk testing provide both formal guarantees and practical validation.

Key tooling summary- PII detection: Presidio / Google DLP / AWS Macie + spaCy / custom NER- Feature stores: Feast / Tecton; metadata: OpenLineage/Marquez- Backups/versioning: S3 versioning, Delta/Hudi, KMS/Vault- DP libs: TensorFlow Privacy, Opacus, PyDP, OpenDP- CI/testing/audit: Great Expectations, Airflow / Dagster, CloudTrail, immutable audit DB (WORM)

Deliverables for compliance package- PII-scan rule set and model versions + performance metrics- Deletion process doc + automated test runs and SLA proofs- Audit ledger with signed entries per pipeline run (dataset hash, code hash, DP accounting)- Periodic risk assessment reports (membership-inference tests) and third-party audit results.

Unlock Full Question Bank

Get access to hundreds of GDPR Principles and Compliance interview questions and detailed answers.

Join thousands of developers preparing for their dream job.