Data Minimization and Retention Questions

Collecting and keeping only what is necessary: data minimization at collection, purpose limitation, and retention scheduling with automated deletion. Covers defining retention periods, enforcing them technically, and defensibly disposing of data. Includes balancing operational or analytics needs against minimization obligations.

HardTechnical

50 practiced

Design logging and metrics practices to satisfy GDPR requirements. Specify what data must be excluded or pseudonymized in logs, retention policies, redaction techniques for ELK/Fluentd pipelines, and a process to remove a data subject's logs on request.

Sample Answer

Requirements & goals:- Preserve auditability and operational telemetry while ensuring personal data (PD) is not exposed & can be erased on request (GDPR Article 5, 17).- Minimize PD in logs; when needed, pseudonymize and allow re-identification only with separate controls.

What to exclude or pseudonymize:- Exclude: full names, email addresses, national IDs, postal addresses, payment card numbers, raw IPs when not essential.- Pseudonymize: user_id, account_id, device_id — replace with reversible tokenization (lookup in a secured vault) only when needed for support; otherwise hash with salt (non-reversible) for analytics.- Keep metadata: event type, timestamps, service, error codes, non-PD metrics.

Retention policies:- Default short retention for raw logs with PD (e.g., 30 days). Aggregated/hashed metrics can be retained longer (1–3 years) with access controls.- Implement tiered retention in ELK: hot (7–30d raw), warm (30–90d aggregated), cold (>=90d aggregated/hashed), and deletion lifecycle tasks.

Redaction techniques for ELK/Fluentd pipelines:- Ingestion filters: use Fluentd/Logstash processors to drop or transform PD fields before indexing.- Regex redaction + JSON path scrubbing: redact known fields, then run sensitive-data detectors (PII regex for emails, CCNs, SSNs). Example: replace with "<REDACTED_EMAIL>" or hashed token.- Pseudonymization plugin: compute HMAC-SHA256 with service-level salt for analytics; for reversible tokenization, call a secure token service that returns a token ID; never store mapping in logs.- Use Elasticsearch ingest pipelines for additional validation and to enforce schema.

Access controls & encryption:- Encrypt logs at rest and in transit. RBAC to restrict access to indices with PD. Audit accesses.

Deletion / Right to erasure process:1. Intake: verify and authenticate DS request via standard identity flow.2. Locate: query tokenization vault to resolve subject's pseudonym/token(s); OR search indices for hashed identifiers.3. Action: - If reversible tokens used: delete mapping in token vault, then run index deletion: delete or update-by-query to remove documents containing token or replace PD fields with "<ERASED>". - If only non-reversible hashes used: no re-identification possible — delete any logs that directly include PD (if any) and document justification.4. Verification: run queries to confirm removal, produce audit record of deletion (metadata only).5. Notification: inform requester with confirmation and retention exceptions (e.g., legal holds).

Operational controls & testing:- CI checks: static rules to prevent PD logging in code (linting, PR checks).- Periodic PII scans on indices; retention lifecycle automation; run test erasure scenarios quarterly.- Logging of deletion actions in separate immutable audit store (contains no PD).

Trade-offs:- Reversible tokens ease support but increase risk; require strict vault security and short retention.- Non-reversible hashes maximize privacy but impede targeted support.

This design balances operational needs with GDPR obligations by minimizing PD in logs, enabling efficient erasure, and enforcing technical and organizational controls.

Unlock Full Question Bank

Get access to hundreds of Data Minimization and Retention interview questions and detailed answers.

Join thousands of developers preparing for their dream job.