DSAR requests: handling data-subject requests in the dashboard

What it's for

A Data Subject Access Request (DSAR) is any formal ask from a visitor to access, delete, correct, or export the personal data you hold on them. Dashboard → Privacy → DSAR (the default tab when you open Privacy) gives you an intake queue, a statutory-deadline tracker, a status workflow, and the tools to actually fulfill the request against your consent records — all in one place, so nothing sits in someone's inbox waiting to become a compliance problem.

Step-by-step: logging a request

1. Go to Dashboard → Privacy (defaults to the DSAR tab).

2. Click New request.

3. Fill in:

   Field	Options
   Request type	Access, Deletion, Rectification, Portability, Opt-out
   Regulation	GDPR, CCPA
   Subject	Any identifier the requester gave you — email, account ID, phone number, etc.

4. Click Add. The request is logged with status received and a due date computed automatically from the regulation's statutory deadline: 30 days for GDPR (Art. 12(3)), 45 days for CCPA.

The subject field deliberately doesn't require an email — use whatever identifier the requester actually gave you, since not every DSAR arrives with an email address attached.

The status workflow

Requests move through a fixed set of statuses, and the dashboard only offers the statuses that are legal next steps from wherever a request currently sits:

Use the Advance dropdown on a request's row to move it forward. Once a request reaches completed or rejected, it's terminal — there's no regression path, by design, so your history stays an honest audit trail of what actually happened.

A request that's past its due date and not yet in a terminal status is flagged Overdue in red directly on the row, and the header shows your total overdue count as a badge — so you can see at a glance whether anything needs immediate attention.

Filtering the queue

Use the search box to filter by subject, and the status filter dropdown to narrow to a specific stage (e.g. everything still received and unverified, or everything in_progress). Both reset the page back to page one so you don't end up staring at an empty page after narrowing the list.

Fulfilling access and deletion requests

Once you've verified the requester's identity through your own process, two extra actions appear on a request's row if you have the subject's consent receipt stamp (the same stamp from the consent log):

• Export data — opens a dialog asking for the site's cbid and the subject's stamp. Clicking Export downloads a JSON file containing every consent record tied to that stamp for that site. Nothing is deleted — this satisfies an access or portability request.

• Erase data — opens a dialog for the same cbid + stamp pair. Clicking Erase permanently performs a crypto-erasure: the subject's user agent and page URL are made permanently unrecoverable. The tamper-evident hash chain stays intact — only the personal fields are destroyed — and this action cannot be undone.

  If crypto-erasure isn't configured on the server (no encryption key set), the dialog tells you so instead of silently doing nothing — you'll see a message asking you to configure COOKIE_CONSENT_KEK before retrying, and the dialog stays open so you don't have to re-enter the values.

Where do you get the cbid and stamp? The cbid is your site's property ID (visible under Dashboard → Properties); the stamp is the consent-receipt ID, which you'd typically already have if the subject supplied it, or can look up via the consent log API.

Important: Crypto-erasure only removes what Cookie Munch encrypted per-subject (user agent, URL) in its own consent log. It does not remove the subject from your CRM, order history, email list, or any other system — DSAR fulfillment for those systems remains your responsibility outside Cookie Munch. Use Preference center if what you actually need is to update standing marketing preferences rather than erase consent-log records.

What the data means

• Overdue is computed purely from the due date and current status — it's a hard deadline check, not a soft reminder, so treat a red row as time-sensitive.

• A request's type and regulation don't change what actions are available in the dashboard today — Export/Erase are gated only by whether you've supplied a valid cbid + stamp, not by the request's declared type. Use your own judgment about which action matches the request (e.g. don't erase in response to a portability request).

Export/compliance value

The DSAR queue is your evidence that requests were handled on time and by the book: every request carries a logged received date, a statutory due date, and an auditable status trail ending in completed or rejected. Combined with the export/erase actions writing directly against the consent log, this is what lets you answer "show me every data-subject request from the last year and how each was resolved" without reconstructing anything from email threads.

Automating intake

If you want DSARs created programmatically (e.g. from a support-desk integration) rather than typed into the dashboard, issue an API key under Dashboard → Developers → API keys with the DSAR scope (dsar:read/dsar:write), and optionally subscribe a webhook to dsar.created / dsar.updated under Dashboard → Developers → Webhooks so your own systems stay in sync with status changes made here.

See also: Consent log · Preference center · Audit export & receipts