Deep-dive · Operate 4.4
Access is the inverse of deletion: a fan-in problem. You collect from every service, dedupe, redact other people, and deliver machine-readable data securely, all inside one month. Scroll to run a request through the pipeline.
The deadline runs from when the request is received, not when you finish verifying. One month, extendable to three for genuinely complex requests, but only if you tell the subject why within the first month.
Disclosing to the wrong person is itself a breach. Re-authenticate with step-up MFA for active users, use out-of-band checks for ex-customers. But over-verification is also a violation: document the standard in the runbook.
Mirror the deletion fan-out: every service exposes GET /dsar/{subjectId} returning its holdings
as structured JSON. The data catalog lists which services must answer. Manual collection ("Sarah will pull it
together") is the single most common cause of late DSARs.
A coordinator pulls from each service, dedupes by canonical subject ID, and produces a single artifact with metadata: source system, retention basis, recipients.
A request for user A may surface messages mentioning user B. Redact other people's data before delivery (Art. 15(4)). And remember derived data: profiles, segments, ML feature values and agent notes are all in scope, not just what the user gave you.
JSON is the default; CSV per entity type is fine for portability under Art. 20. A pure PDF is access-only, not portable, so provide both for clarity.
Encrypted archive, a signed download URL with a short TTL, or an MFA-gated portal. An email attachment is not appropriate. Deliver within the 30 days, having tracked the whole pipeline against the deadline.