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

102 practiced

Design a multi-region compliance plan for user data (e.g., GDPR) stored and processed by microservices while keeping latency low in each region. Discuss data residency, consent, encryption, anonymization, and auditability.

Sample Answer

Requirements & constraints:- Users in multiple jurisdictions with region-specific residency + GDPR rights (consent, right to erasure, data portability), low latency per-region, strong security and auditability.

High-level approach:- Deploy microservices regionally (one primary per region) with a central policy/control plane. Keep user data in-region by default; replicate only where lawful and consented.

Key components:1. Regional API Gateway & Services: handle traffic locally for low latency; enforce region-specific policies.2. Regional Data Stores: store PII/resident data in-region (encrypted at rest). Use read replicas only inside-region.3. Global Control Plane: stores policies, consent records, KMS metadata, and orchestrates cross-region operations (not raw PII).4. Consent & Residency Service: authoritative consent store (records scope, timestamp, legal basis, TTL). Expose APIs for revocation, portability, and audit.5. Key Management: region-local KMS for data keys; use a global KMS metadata service for key lifecycle; cross-region key export only under approved lawful processes.6. Audit & Logging: immutable, tamper-evident audit logs (append-only), shipped to regional SIEM; aggregated, redacted logs to central analytics.

Data residency & replication:- Default: data remains in user's region.- Cross-region replication allowed only if: - User consented (recorded with scope & purpose) - Legal basis exists (contractual/legitimate interest) and DPIA completed - Data minimized and pseudonymized before transfer- Use asynchronous, encrypted message queues for replication; include provenance metadata.

Consent management:- Capture granular consent (purpose, duration, recipients) and surface UIs/APIs to update/revoke.- Tie consent checks into service auth middleware; deny operations if no valid consent.- Log consent events into audit store with hashes to ensure integrity.

Encryption & key strategy:- TLS in transit; AES-256 at rest.- Envelope encryption: application uses data keys encrypted by region-local KMS keys.- Key rotation policy and automated re-encryption jobs regionally controlled.- No plaintext PII into central analytics; use tokenization/hashed identifiers for correlation.

Anonymization & minimization:- Apply pseudonymization for downstream processing (tokenization, salted hashes).- For analytics: apply differential privacy, k-anonymity thresholds, or aggregate only (no row-level PII).- Implement retention rules: automated purge workflows per-region; on erasure request, delete PII and log deletion proof.

Auditability & compliance proof:- Maintain immutable audit trails for data access, consent changes, transfers, and deletion with: - User ID, actor, operation, timestamp, region, purpose, hashed diff of payload- Provide data subject access export endpoints: compile region-local data, package for portability, and record delivery.- Regular compliance reports, DPIAs, and third-party audits. Automated compliance checks in CI/CD (policy-as-code).

Operational controls & trade-offs:- Latency: regional deployments minimize RTT; occasional cross-region lookups incur latency—use async patterns and cache consent tokens locally with short TTL.- Consistency: prefer eventual consistency for cross-region replication to avoid blocking writes; strong local consistency within region.- Complexity vs risk: stricter residency reduces risk but increases operational overhead; adopt phased approach: start with regional isolation, add controlled replication where business-critical.

Testing & validation:- Automated tests: policy unit tests, consent lifecycle tests, encryption/key rotation tests, deletion/portability flows.- Pen tests, compliance audits, synthetic data drills for erasure and breach response.

This plan balances low latency by localizing processing/storage, enforces residency and consent, secures data with envelope encryption & region-local keys, minimizes PII exposure via anonymization, and provides strong, immutable auditability for regulators.

HardTechnical

73 practiced

Describe how API design must adapt to regulatory requirements like GDPR and CCPA: data minimization, purpose limitation, consent capture, the right to be forgotten, data portability, and cross-border data transfer controls. Propose API-level patterns and controls (deletion endpoints, export endpoints, field-level redaction, audit logs) to support compliance.

Sample Answer

Approach: Treat privacy laws as functional requirements. Translate GDPR/CCPA principles into API contracts, data models, and controls so developers, product and legal teams can verify compliance.

API-level patterns and controls- Data minimization & purpose limitation: - Design endpoints that accept/return only required fields. Use explicit field masks and scoped DTOs: GET /users/{id}?fields=name,email - Server-side validation rejects extra PII unless a documented purpose flag is present.- Consent capture & provenance: - POST /consents with purpose, scope, version, timestamp, client_id; return consent_id. Link consent_id to user records and every data collection event. - Expose GET /users/{id}/consents and PATCH /consents/{id}/revoke.- Right to be forgotten (deletion): - Two-tier deletion: POST /users/{id}/delete-request creates deletion job; GET /jobs/{job_id} checks status. - Support soft-delete (anonymize identifiers, mark as deleted) and hard-delete after retention periods or legal hold. Document idempotency and 202 Accepted for async jobs.- Data portability (export): - POST /users/{id}/export?format=json/csv triggers background export, includes linked records and schema mapping; ensure schema versioning and provide download with signed short-lived URL.- Field-level redaction & minimization: - Support query parameter redact=true or role-based field filters; implement per-field encryption or tokenization for sensitive attributes.- Audit logs & provenance: - Immutable, append-only audit events for consent, access, export, delete actions with actor, IP, purpose, timestamp. Provide GET /audit?user_id=... with RBAC and retention aligned to policy.- Cross-border controls: - Tag data residency in records (data_region). On write, validate client allowed regions; GET respects region-based routing or denies if transfer disallowed. Use header X-Data-Region and enforce at API gateway.- Access control & encryption: - Enforce least privilege via OAuth2 scopes (scope=personal_data:read/export). Encrypt data at rest with per-region keys; log key-access.

Implementation considerations- Async jobs for long-running exports/deletes; webhook/callback on completion.- Provide SDK helpers, OpenAPI annotations for privacy metadata (purpose, retention, sensitivity).- Retention and legal hold: backend policy engine that can override deletion if legal_hold=true.- Testing: automated compliance tests (consent flows, delete/export scenarios), fuzz for unexpected fields.- Monitoring & metrics: time-to-complete deletions, pending deletion queue, number of exports, consent coverage.

Trade-offs- Stronger controls add latency and operational complexity; prefer policy-as-code and centralized enforcement (API gateway + policy service) to avoid duplication.

This design makes privacy explicit in APIs, auditable, and automatable while enabling product needs under legal constraints.

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.