Data Subject Rights and Request Handling Questions

Operationalizing individual rights: access, rectification, erasure, portability, restriction, and objection requests. Covers identity verification, response timelines, locating data across systems to fulfill a request, and handling edge cases and exemptions. Includes designing systems that can execute deletion and export reliably at scale.

HardTechnical

104 practiced

Scenario: Apple must comply with GDPR/CCPA while improving a cloud-backed ML service used by its apps. Propose a compliance-aware data pipeline that supports user data deletion and rectification requests without severely degrading model quality. Include techniques like soft deletes, data lineage, selective retraining, and federated retraining, and explain how to ensure model auditability.

Sample Answer

Requirements & constraints:- Must honor GDPR/CCPA: right to erasure, rectification, portability, audit.- Minimal model-quality degradation and acceptable latency for updates.- Scalable for Apple-scale data, privacy-preserving.

High-level architecture:- Ingest → Raw Data Lake (encrypted, tenant-tagged) → Data Provenance & Lineage Store → Feature Store (materialized features with origin pointers) → Training Orchestrator → Model Registry & Audit Ledger → Serving.

Key components and behaviors:1. Data lineage & provenance- Every data record gets immutable metadata: user_id_hash, consent_flags, source, timestamp, dataset_id, and a provenance_id.- Lineage store (graph DB) links features and model training runs to provenance_ids; used to compute affected models when a record changes.

2. Soft deletes + rectification- Soft delete marks provenance_id as "deleted" and records deletion_time; rectification creates a new record with linkage to original.- Physical purge happens asynchronously after legal TTL (or immediate if requested): purge scheduler consults lineage to identify derived artifacts.

3. Selective retraining- Use the lineage store to compute which training examples and features included a deleted/rectified record; mark affected model versions.- For minor impact (small influence score via influence functions or Shapley/value-attribution), apply targeted fine-tuning on affected layers or delta-updates rather than full retrain.- Maintain shadow retraining jobs to evaluate drift from deletions before promoting.

4. Federated retraining & minimization- For sensitive or high-volume user data, prefer on-device federated learning: local updates, secure aggregation, differential privacy noise, and only send model deltas.- Combine federated deltas with server-side selective retraining to reduce need to store raw personal data centrally.

5. Data valuation & priority- Score records by influence on model (per-run), recency, and consent; prioritize retraining for high-impact deletions.

6. Model auditability & compliance evidence- Immutable audit ledger (WORM) logs: data ingestion events, consent changes, delete/rectify requests, lineage mappings, training run IDs, model binary hashes, evaluation metrics, and promotion events.- Model registry stores model artifacts, training code, hyperparameters, dataset snapshot references (not necessarily raw PII), and a list of provenance_ids or dataset-level signatures.- Provide explainability artifacts (feature importances) per model version to demonstrate why a deletion affected outputs.- Expose an API for compliance: given user_id_hash, return evidence of removal/rectification (timestamps, models affected, retrain status) and allow portability.

Privacy & security controls:- Encrypt data at rest and in transit; zero-knowledge hashing/pseudonymization for IDs; key management with least privilege.- Differential privacy and secure aggregation for federated updates.- Access controls and approval workflow for any physical purge.

Operational flow for a deletion request:1. User requests deletion → Authenticated request logged in audit ledger.2. Mark provenance_ids as deleted in lineage store (soft delete), block future ingestion/usage.3. Compute affected features/models via lineage graph; compute influence scores.4. If high impact: trigger retrain/fine-tune job (or initiate federated update), run shadow evaluation, then promote new model version; log everything.5. After legal windows and backups accounted, trigger physical purge (scrub storage, update audit logs).

Trade-offs:- Immediate full retraining ensures strongest compliance but is costly and may hurt availability; selective retraining + influence scoring balances cost and model quality.- Federated retraining reduces central storage of PII but increases complexity and requires secure aggregation/infrastructure.

Why this works:- Lineage enables precise identification of affected artifacts so deletions are surgical, reducing unnecessary retrains.- Soft deletes provide reversible steps for rectification and a clear audit trail.- Selective retraining and federated methods minimize quality impact and central PII retention.- Immutable audit ledger + model registry provide verifiable evidence for regulators and users.

Unlock Full Question Bank

Get access to hundreds of Data Subject Rights and Request Handling interview questions and detailed answers.

Join thousands of developers preparing for their dream job.