Implementing DSAR Orchestration at Scale

Definition
DSAR Orchestration handles user requests for data access, correction, portability, or deletion across all systems within regulatory timeframes.
REQUEST INTAKE AND VERIFICATION
Users submit via web, email, or API. First: verify identity (email/SMS/login) to prevent malicious requests. GDPR requires response within 30 days; CCPA 45 days. Log receipt timestamp for SLA tracking. Route by type: access, deletion, correction, or portability.
DATA DISCOVERY AND MAPPING
Orchestrator queries all sources: databases, feature stores, training sets, logs, vendors. Each implements a standard interface. Maintain a data catalog mapping identifiers to storage—without this, DSARs fail silently.
💡 Key Insight: DSAR requires an identity graph. Users may be email in one system, user_id in another, device_id in a third. Without unified resolution, you cannot find all their data.
EXECUTION AND CONFIRMATION
For deletion: execute in all systems, confirm, retry failures. Handle eventual consistency. For access: aggregate into portable format. Generate confirmation report. Store audit evidence for regulators.
SCALE CONSIDERATIONS
At 100M users, expect 50-500 DSARs daily. Automate everything—manual cannot scale. Batch similar requests. Queue to avoid overwhelming stores. Monitor SLA and alert on approaching deadlines.
⚠️ Key Trade-off: Full automation requires standardized interfaces—significant investment. Many start semi-automated: automated discovery, manual approval, automated execution.

💡 Key Takeaways

✓DSAR requires identity verification, discovery across systems, execution with confirmation

✓Identity graph essential—users have different identifiers across systems

✓At scale: 50-500 DSARs daily for 100M users; automation required

📌 Interview Tips

1Design DSAR: intake, identity resolution, discovery, execution, audit

2Mention SLAs: GDPR 30 days, CCPA 45 days

← Back to Regulatory Compliance (GDPR, CCPA) Overview