GDPR — privacy policy URL, consent, DSR fulfillment

Preconditions

• Tenant has a privacy policy URL configured (mandatory for public events; events without one fail to publish).
• Tenant has a Data Protection Officer (DPO) email configured (used in DSR communications).
• Privacy policy versioning is enabled — every published version has a content hash + effective_at timestamp.
• R2 (or equivalent) storage is available for DSR export bundles.

Happy path

Public consent at registration

1. Public registration modal renders the consent block.

   Below the standard form, a consent block: "I have read and agree to the [privacy policy] and consent to being contacted about this event." The link opens the tenant's privacy-policy URL in a new tab. The checkbox is NOT pre-checked.

2. Submit captures consent evidence.

   Successful registration writes a consent_records row with: registration_id, policy_version_hash, policy_effective_at, ip_address (truncated last octet for v4 / last 80 bits for v6 — privacy-preserving), user_agent, consent_text_at_time (literally what the customer saw), captured_at timestamp.

3. Confirmation email includes the privacy policy link.

   Consistent footer link to the privacy policy. Customer can revisit the policy version they consented to via a stable per-consent URL ("/p/policy/[version-hash]").

DSR — export request

1. Customer submits a DSR via /privacy/request public form (or via DPO email).

   Request form: customer's email, DSR type (export | delete | rectify), explanation. Server emails a verification link; customer must click within 7 days. Verification confirms the email belongs to the requester (anti-fraud).

2. Tenant operator sees the DSR in the privacy queue.

   Admin → Privacy → DSR Queue. Each request shows: type, requester email, verification status, age (countdown to the 30-day GDPR SLA), and an "Open" CTA. Operator can acknowledge, request more info from the requester, or proceed.

3. Export job runs.

   Background job (using ui-async-job-tracker contract) collects all records keyed to the requester's email: contact records, registrations across events, consent records, email events (sent/delivered/opened/clicked/bounced — where retained), check-in events, file uploads (R2 URLs). Bundles into a JSON + CSV pair, plus a human-readable HTML summary.

4. Bundle delivered.

   Bundle archived to R2 with a 7-day signed URL. Customer receives email with the URL + decryption hint (customer's verification token doubles as the symmetric key — bundle is encrypted at rest in R2). Audit log row written with operator_id, dsr_id, completed_at.

DSR — delete request

1. Operator confirms delete via type-to-confirm + DPO countersign.

   Delete is irreversible. Confirmation requires (1) operator types the customer's email + their own initials, (2) DPO co-signs (a second admin clicks "Approve" via a separate UI accessed via emailed link). Two-eyes principle prevents accidental + malicious-insider deletion.

2. Cascade delete runs.

   Background job deletes: contact records, registrations, consent records, email events, check-in events, custom-field answers, uploaded files. Each table's deletion is recorded in a per-DSR ledger.

3. Audit log tombstone.

   After cascade, the customer's audit log entries are NOT deleted (audit must be immutable for compliance). Instead, identifying fields are tombstoned: email → "deleted-{dsr-id}@privacy.local", name → "Deleted Customer", IP → null. Each tombstoned audit entry has a reference to the DSR ID so traceability is preserved without identity.

Failure modes

Stable test attributes

Agent test plan

- consent-not-prechecked: render registration modal, consent-checkbox.checked=false
- consent-required-for-submit: submit without checking, 422 CONSENT_NOT_AFFIRMATIVE
- consent-evidence-stored: successful registration writes consent_records with policy_version_hash + ip + user_agent
- policy-link-server-rendered: rendered href is tenant config, NOT URL/cookie/form param
- publish-blocked-without-policy-url: stub tenant without URL, publish returns 422 PRIVACY_POLICY_MISSING
- consent-record-policy-version-survives-policy-update: register at v2, update policy to v3, assert old consent_records.policy_version_hash=v2
- dsr-verification-required: submit DSR, response says "check email", no data action yet
- dsr-verification-token-replay: dispatch verify 2x, 2nd returns 410
- dsr-verification-forgery: forge token, response 404
- dsr-30-day-sla-warning-at-25: stub aged DSR, alert fires
- dsr-30-day-escalation-at-30: stub aged DSR at 30 days, escalation alert
- dsr-export-job-creates-bundle: verified export DSR, ui-async-job-tracker visible, R2 bundle exists
- dsr-delete-requires-cosign: operator submit, dsr-dpo-cosign-pending visible, DSR not yet executing
- dsr-delete-rejects-same-user-cosign: same user attempts cosign, 403 SAME_USER_TWO_EYES
- dsr-delete-cascade-success: cosigned delete, all dependent tables empty for that customer
- dsr-delete-cascade-partial-failure: stub R2 deletion fail, DSR.status=partial_failure
- dsr-delete-tombstones-audit: post-delete, audit log entries have tombstoned email + dsr_id
- dsr-cross-tenant-no-leak: customer with no data at tenant B submits DSR, response is "no data found"
- consent-revocation-via-delete: revoke consent → DSR delete → per-customer data gone, aggregate count unchanged
- policy-config-allow-list: invalid URL (http or off-allow-list domain) returns policy-config-error
- audit-log-dsr-events: every DSR state transition writes an audit log row
- pii-not-in-console: console-clean asserts no email-shaped string from registration