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

72 practiced

Create a technical and evidentiary approach to prove data deletion across primary stores, caches, search indexes, third-party processors, backups, and analytics pipelines to satisfy GDPR erasure requests. Include acceptance criteria, verification steps, automated checks, and the audit artifacts you'd produce.

Sample Answer

Clarify scope & constraints:- Define “personal data” fields, identifiers (userID, email, PII), retention rules, legal holds, RTO/RPO, SLAs for erasure (e.g., 30 days).- Inventory systems: primary stores, caches, search indexes, ETL sinks, analytics warehouses, backups, third-parties (processors/sub-processors) and data flows.

Technical approach (per surface):- Primary stores (SQL/NoSQL): implement soft-delete flag + physical purge job. Use deletion-id / erasure-token propagated through services. For immediate GDPR erasure, mark and queue for physical delete; cascade FK/relations; remove encryption keys for crypto-shredding where possible.- Caches (Redis, CDNs): invalidate keys by deletion-id; set short TTLs and force flushes for keys that map to affected user; use versioned cache keys to prevent resurrection.- Search indexes (Elasticsearch): maintain userID-document mapping; issue delete-by-query with refresh/refresh_interval=0, then verify index segments; mark tombstone if eventual consistency.- Analytics pipelines & data lakes: prevent future ingestion via filter on deletion-id; backfill pseudonymization or remove using CDC-driven jobs; use transformation jobs to drop records and rebuild aggregates if required.- Backups: record retention policy; for backups beyond retention window rely on retention expiry. For immediate proof, log backup sets containing data, tag them, and if backup is immutable, record expected availability until expiry; if supported, delete from object store and rotate encryption keys (crypto-shredding).- Third-party processors: contractual deletion API/SLAs; call their erase endpoint, record request ID; if no API, rely on contract + attestations.- Message queues: purge or skip by marking message metadata; ensure compaction topics respect tombstones.

Evidence, verification & acceptance criteria:- Acceptance criteria: 1. No replicas of personal data remain in searchable/operational stores accessible to product functionality. 2. Downstream analytics and search do not contain identifiable records beyond an agreed retention window or are pseudonymized. 3. Third-parties acknowledge deletion within contractual SLA or provide attestation. 4. Audit trail proves deletion requests, processing, and verification.- Verification steps: - Automated end-to-end workflow: submit erasure request -> generate deletion-id -> track propagation state machine across systems. - For each system: run deterministic queries (signed queries) that must return zero results for userID/deletion-id within SLA. - For near-real-time systems (cache/search): confirm immediate invalidation and run re-index/read tests. - For backups: produce manifest of backed-up snapshots and retention expiry; if crypto-shredding, show key destruction event. - For third-parties: store API response + SLA timestamp; if attestation, store signed certificate.

Automated checks:- Erasure orchestration service that: - Emits events for each subsystem; waits for ack/verification codes. - Runs verification queries via read-only verification accounts and compares results to expected zero counts. - Schedules periodic re-verification after retention windows (e.g., 7/30/90 days). - Triggers alerts if any system returns data or no ack. - Uses signed logs (WORM) and hashes for integrity.

Audit artifacts to produce:- Deletion request record: request ID, requester identity, timestamp, lawful basis.- Deletion propagation ledger: per-system events with timestamps, operator/service, and verification result.- Verification reports: query text, parameters, signed results (counts, sample redaction), execution timestamp.- Backup manifest: list of snapshots that contained data, retention expiry dates, actions taken (delete/retain), crypto-shredding key destruction proof (KMS logs).- Third-party attestations & API responses (signed).- System snapshots (hashes) showing zero results; screenshots or logs for UI driven systems if relevant.- Final erasure certificate for the user: request ID, summary of systems cleaned, timestamps, contact for disputes.

Operational & design considerations:- Design for idempotent, observable erasure flows with unique deletion-id.- Use encryption + key-rotation as a complement where physical deletion impossible.- Maintain a legal-hold override path and clear escalation for conflict with other laws.- Regular audits and penetration tests to ensure no indirect re-identification from aggregates.

Example verification query (conceptual):- “SELECT count(*) FROM orders WHERE user_id = :user AND is_deleted = false;” result must be 0. Store signed result.

This design balances technical deletion, legal constraints, and provable auditability via automated orchestration, deterministic verification, and tamper-evident artifacts.

MediumSystem Design

76 practiced

Design an auditability-first architecture to support GDPR obligations: maintain a record of processing activities (Article 30) and support timely responses to Data Subject Requests (access, rectification, erasure). Include data flow diagrams, logging strategy, retention rules, and workflow automation for responding to DSRs.

Sample Answer

Requirements & constraints:- Maintain Article 30 Record of Processing Activities (RoPA): who, purpose, categories, transfers, legal basis, retention.- Support Data Subject Requests (DSRs): access, rectification, erasure within statutory timelines.- Auditability-first: immutable logs, tamper-evidence, full provenance.- Scale to millions of subjects, low-latency responses, secure.

High-level architecture (ASCII):Client / API Gateway -> AuthZ (OAuth2/OIDC) -> Service Mesh | v Orchestration Layer (DSR Workflow Engine) | ----------------------------------------------------------- | | | | RoPA DB App Services Personal Data Stores Audit Log (WORM)(Postgres) (microservices) (encrypted S3 / RDBMS) (append-only, e.g., AWS QLDB/CloudTrail+S3+Glue) | v Search/Index (PII index with tokenization, reversible only to KMS)

Data flow & components:- Ingestion: App Services validate & classify personal data via PDP (policy engine) and tag records with persistent pseudonyms (subject-id) and metadata stored in RoPA DB.- Storage: Personal data at rest encrypted with per-tenant keys in KMS; sensitive fields tokenized. Metadata and processing purposes in RoPA.- Audit logging: Every processing event (collect, share, rectify, erase, access) writes a signed, timestamped record to Audit Log (WORM). Use SHA256 chains + log signatures for tamper-evidence. Retain immutable copies in cold storage.- Indexing: PII Index maps subject identifiers to storage locations; access controlled, encrypted, and logged.

Logging strategy:- Structured audit events (JSON schema) including actor, action, resource, purpose, legal basis, TTL, correlation-id, timestamps, hash pointer to previous log.- Stream to append-only store (AWS QLDB / Azure Confidential Ledger / on-premise blockchain) + replicate to immutable S3 with Object Lock (governance/compliance).- Logs protected with HSM-backed keys, retention policy separate from data retention.

Retention & retention rules:- RoPA entries kept for audit (min 5 years or per regulator); audit logs retained as required (e.g., 7 years) in immutable storage.- Personal data retention enforced by retention TTL in metadata; background jobs check TTLs and perform ERASURE workflows: soft-delete (logical) then purge after legal holds expire.- Legal hold flagging: DSRs or investigations set legal-hold preventing purge; all holds recorded in RoPA and audit log.

DSR automation workflow:1. Intake: Multi-channel request intake (portal/API/email) -> verify identity via AuthN & step-up if needed -> create DSR ticket (in Workflow Engine).2. Discovery: Workflow queries PII Index and services for subject-id; issues asynchronous data collection jobs to services; each service returns dataset + signed metadata of provenance.3. Review & Enrichment: Automated redaction engine masks third-party personal data; risk scoring flags complex requests requiring manual review.4. Action: Depending on DSR type: - Access: assemble packaged data (machine-readable + human-readable), sign package, log delivery. - Rectification: forward change events to owning services; changes produce audit entries and versioned records. - Erasure: initiate erase job: mark logical delete, scrub indexes, rotate encryption keys for data shards if physical irrecoverability required; log proof of erasure (hash of previous state + erasure token).5. Closure: Notify data subject, record RoPA update, record SLA timestamps, escalate if deadlines missed.

Security & privacy-by-design:- Principle of least privilege, attribute-based access control (ABAC) tied to PDP.- Zero-trust networking, mTLS between services, strong key management (KMS/HSM).- Pseudonymization by default; reversible only with KMS keys; separation of metadata and PII.- Penetration testing, automated privacy impact assessments (PIA) pipeline.

Scalability & availability:- Microservices autoscale; Workflow Engine stateless with durable task queue (Kafka).- Index sharding for fast subject lookups; cache with short TTL and encrypted.- Use eventual consistency for discovery but ensure strong consistency for erasure acknowledgment.

Trade-offs & notes:- Immutable audit stores increase cost and complexity but provide strong evidentiary guarantees.- Tokenization + reversible keys balances operational needs vs exposure; key compromise risk managed by HSM, rotation, and compartmentalization.- Erasure proof can be achieved via cryptographic key destruction (crypto-shredding) when regulatory context allows.

Metrics & SLAs:- Time-to-acknowledge DSR, time-to-complete, % automated completions, audit integrity checks, number of legal holds.

This architecture gives end-to-end auditability, provable tamper-evidence, automated DSR handling, and configurable retention compliant with GDPR while balancing operational needs.

MediumTechnical

130 practiced

A financial client requires end-to-end data governance for ML to comply with GDPR: data lineage, PII classification and handling, retention policies, consent management, and right-to-be-forgotten requests. As a Solutions Architect, outline a practical implementation plan, key tooling choices, and how to ensure models remain auditable and compliant when retraining or serving predictions.

Sample Answer

Situation / goal: The client must implement end-to-end ML data governance to satisfy GDPR—covering lineage, PII classification & handling, retention, consent management, and right-to-be-forgotten—while keeping models auditable through retraining and serving.

Plan (phased, practical):- Phase 0 — Requirements & taxonomy: define data domains, PII types, retention schedules, consent scopes, risk matrix, and SLA for forget requests. Assign data stewards.- Phase 1 — Discovery & classification: run automated PII scanners to tag datasets and create a catalog. Capture schema-level and column-level metadata.- Phase 2 — Lineage & provenance: instrument ingestion, transformation, feature store and training pipelines to emit lineage events and dataset versions.- Phase 3 — Enforcement & consent: enforce access, masking, and retention through policy engine; implement forget workflows that remove or pseudonymize personal data and trigger model retrain/retest.- Phase 4 — Model lifecycle & auditability: register models, store artifacts, record training data snapshots, decisions, and explainability artifacts; automate compliance gates.- Phase 5 — Ops, monitoring & reviews: periodic audits, drift detection, and compliance reports.

Key tooling choices (examples / trade-offs):- Catalog & lineage: Azure Purview / AWS Glue Data Catalog + OpenLineage/Marquez for cross-platform lineage; Databricks Unity Catalog if on Databricks.- PII detection & DLP: Microsoft Purview classification, Google DLP, AWS Macie, or open-source Presidio for custom detectors.- Policy & access enforcement: Privacera / Immuta for fine-grained data access; Open Policy Agent (OPA) + central IAM (Azure AD / AWS IAM / Keycloak).- Storage & versioning: Delta Lake / Apache Hudi / Iceberg for ACID tables and time travel; S3/Blob with lifecycle rules for retention.- Feature store & provenance: Feast or Tecton; ensure features include origin metadata and consent flags.- ML lifecycle & reproducibility: MLflow or Kubeflow Pipelines for experiment tracking; DVC or data versioning tied to object storage snapshots.- Model serving & governance: Seldon/TF Serving + model registry (MLflow Model Registry) + audit logs.- Consent management & workflows: OneTrust or custom consent DB + event stream (Kafka) to propagate revocations.- Auditing & immutable logs: CloudTrail / Azure Monitor / ELK + append-only logs (WORM), signed events for non-repudiation.- Explainability: SHAP / LIME and store explanations per model/version/prediction sample when required.

How to ensure compliance & auditable models:- Immutable provenance: Persist dataset snapshots (or cryptographic hashes + pointers) used for each training run in MLflow; store lineage events (OpenLineage) so you can trace a model back to input files, transformations, and code commit SHAs.- Consent-aware features: Add consent metadata at record level; feature pipelines and training jobs must filter or mask records without required consent. Maintain a consent ledger so queries can check a flag before training/serving.- Right-to-be-forgotten workflow: On a forget request, locate all tables/feature stores via catalog lineage, delete/pseudonymize records, mark affected model versions as "tainted", and trigger automated retraining or produce a documented justification if retrain is deferred. Record all actions in an audit trail.- PII handling: Default to least privilege; apply tokenization/pseudonymization or field-level encryption for stored PII; use dynamic masking for queries and differential access controls in the policy engine.- Retention enforcement: Implement lifecycle policies at storage layer (S3 lifecycle, Azure Blob lifecycle) bound to catalog retention metadata; automatic purge jobs with approvals and audit logs.- Auditing & reporting: Automate generation of compliance reports showing lineage, consent status, retention actions, model training data, and model explanations. Keep signed logs and exportable evidence for regulators.- Test & validation: Include compliance tests in CI/CD pipelines: unit tests for consent filters, integration tests verifying deletion propagation, and reproducibility tests that re-run training from stored artifacts.- Operational controls: Role-based responsibilities (data steward, ML owner), SLAs for forget requests, and regular external compliance reviews/pen tests.

Why this works (reasoning):- Combining catalog+lineage with storage-level versioning ensures traceability without relying on ad-hoc records.- Enforcement via a central policy engine + IAM prevents human error and automates consistent behavior across environments.- Storing training snapshots and signed audit logs yields the evidentiary trail regulators expect; automating retrain/taint workflows preserves model correctness and compliance.- Using managed/cloud-native tools where possible reduces operational burden; open standards (OpenLineage, MLflow) avoid lock-in and enable cross-tool evidence.

Example short workflow (forget request):1) Request received → consent ledger updated; event emitted to Kafka.2) Catalog/lineage resolves all datasets and features containing subject identifiers.3) Automated jobs delete/pseudonymize rows in Delta Lake (time-travel used to ensure previous snapshots are handled per retention policy).4) Mark model versions that used affected data as "requires review"; trigger retrain pipeline using sanitized dataset or record documented exception.5) Append all steps to immutable audit log; notify requester.

Metrics & KPIs:- Time to resolve forget request- Percentage of models with full lineage & training snapshot- Percentage of data with PII classification coverage- Number of access policy violations/blocked accesses- Audit report generation time

This plan balances automation, auditability, and operational feasibility to deliver GDPR-compliant ML while keeping retraining and serving transparent and provable.

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.