Handle a DSAR (subject access request)

A Data Subject Access Request (GDPR Article 15) asks what personal data you hold on a person. In ScaiLog you answer it with one command: ScaiLog finds every entry for the subject, decrypts their PI under the subject's own key, and returns a single signed report. This needs the dpo capability.

Run the DSAR#

Use the subject id you emitted logs under. The CLI prints the report as JSON, or writes it to a file with --out.

1
2

scailog dsar usr_8842 --out dsar.json
# => DSAR report written to dsar.json (1 entries)

By default the CLI targets the tenant default; pass --tenant <id> for another tenant. The equivalent API call is:

1
2
3
4
5

POST /v1/dsar
Authorization: Bearer <dpo-capable key>
Content-Type: application/json

{ "tenant": "default", "subject": "usr_8842" }

What the report contains#

The report is a JSON document describing everything ScaiLog collected for the subject. The top level carries the provenance you need to answer the request and to prove the answer is complete.

Each element of entries includes event_id, ts, service, call_site_id, level, the plaintext message, the plain fields, and two PI-specific keys:

• pi_values — the decrypted PI values for that entry, keyed by field name.
• pi_categories_collected — for every PI field the entry ever carried, its pi_type and the policy action applied, e.g. "email": "direct_identifier:encrypt". This records what category of PI was collected even for fields that were dropped or redacted (and therefore have no value to return).

An entry also carries tombstoned: true if it belongs to an already-erased subject.

PI decrypts per subject#

pi_values is populated by decrypting each encrypted field with the subject's own data-encryption key (DEK). ScaiLog only decrypts fields whose policy action was encrypt and only while the subject's key still exists — so a DSAR is the sanctioned way to read PI back, and it stops working the moment the subject is erased. Fields that were redacted, dropped, or keept appear in pi_categories_collected but contribute no ciphertext to decrypt.

Verify the report#

The report is signed with the server's active Ed25519 report key, and the signature block embeds that key's key_id and public key — so old reports stay verifiable even after the signing key is rotated. To check a report you were handed, verify it offline against the server's published keys:

1
2

scailog report-key verify dsar.json
# => signature valid — signed by a published report key (key_id …)

scailog report-key show lists the published keys (active and retired), which the verifier fetches from GET /v1/report-keys. Retired keys stay published, so a report signed months ago still verifies after one or more rotations.