DSAR console — building Article 15 bundles

For admins

DSAR console

When a parent, member of staff, governor or pupil submits a UK GDPR Article 15 subject access request, the Designated Protection Officer (DPO) opens this page, enters the subject’s email, and lets Keystone walk every module that might hold personal data about them. The result is a single JSON bundle ready for review and download.

Find it under Governance → DSAR console (or /agent/governance/dsar).

What the bundle contains

Each module that stores personal data registers a contributor that returns its slice of the bundle. Today five sections ship:

Section	What’s in it
People — staff record	Full export of the Person record: demographics, employment, line manager, documents, qualifications, emergency contacts, confidential notes (if your role permits), NI number. Wraps the existing GDPR Article 15+20 export action.
Helpdesk — tickets and replies	Every ticket the subject filed or was assigned to, plus every reply (public or private) authored by them.
Governance — policy acknowledgements	Every ack the subject has recorded against published policies, with policy reference, version, and acknowledged-at timestamp.
SCR — engagement checks	Every KCSIE check (DBS, identity, RtW, prohibition, S128, references, qualifications) recorded against the subject’s Person record, plus attachment IDs.
Audit log — events about / by the subject	Last 12 months of audit-log rows where the subject is the auditable target (rows about them) or the actor (actions they took). Older entries available via CLI on request.

If a module returns nothing, the section still renders with a note explaining why — that’s important for the audit trail (the DPO can prove every module was searched).

Per-section permission gating

A DPO without a particular module’s permission gets the bundle with that section omitted, rather than a partial render. The page works normally; the audit row records the section count actually returned. The full permission set for a “complete” bundle is:

people::admin
helpdesk::admin
governance::admin
scr::admin
platform::audit::view

Any user with governance::dpo can open the console (it’s the DPO permission). Sections they’re not entitled to are simply not built.

Reviewing the bundle

Click Build bundle. Each section appears as a card with the record count and the JSON preview. Free-text fields (ticket descriptions, reply bodies) are returned verbatim — if a field mentions an unrelated third party, the DPO must redact it before sending. We don’t try to auto-redact: an inadvertent redaction would be a worse failure mode than over-disclosure to the subject themselves.

Once the bundle looks right, click Download JSON for a streaming download. Filename pattern: dsar-<email>-<timestamp>.json.

The audit trail

Every export records a tamper-signed audit row with:

event = 'dsar.export'
tags = 'dsar,gdpr'
user_id = the actor (the DPO who clicked Build)
new_values.subject_email, subject_person_id, subject_user_id, workspace_id, section_count

Filter the audit log by event=dsar.export to populate your statutory DSAR register — there is one row per build, including drafts. The HMAC signature means anyone tampering with the audit row will be caught by php artisan audit:verify.

CLI escape hatch

For incident response, scripted bundling, or when the admin UI is unavailable, use the CLI:

php artisan dsar:export jane.smith@example.com \
    --as=dpo@trust.example \
    --output=jane-bundle.json

--as is required so the audit row reflects who performed the export. On a single-tenant install the workspace is auto-resolved; on multi-tenant operations pass --workspace=<uuid>.