Data Subject Rights — Regulatory Procedure
1. Purpose and relationship to existing documents
This document is the regulatory counterpart to PRO-09 (Tier 2, pending per PLAN.md §4): PRO-09 will document the operational *how* — the exact steps someone follows to fulfil a request; this document states the regulatory *what* — which right, which article, and what is actually implemented today, so a request handler and an auditor read the same ground truth from two angles. It formalizes dsgvo-data-flow.md §7, which already lists implementation status per right at a similar level of detail; the addition here is the explicit GDPR/revDSG article mapping and a sharper distinction between "real code exists" and "manual process only."
revDSG note: revDSG does not mirror GDPR's article-by-article rights structure one-for-one — the closest functional equivalents are cited below (broadly Art. 25–32 nDSG: right to information, data communication/portability, and the general claims provision covering correction, deletion, and restriction). This mapping reflects DPO judgment, not a certified legal crosswalk; confirm with counsel before relying on the revDSG column for a Swiss-subject request.
2. Rights table
| Right | GDPR Art. | revDSG equivalent | Implementation status |
|---|---|---|---|
| Access | 15 | Art. 25 (Auskunftsrecht) | Real code, admin/compliance-triggered. buildGdprExport() (apps/web/lib/admin/gdpr-export.ts:14-42) pulls subscribers, user_active_mandate, onboarding_profile, subscriber_roles, web_push_subscriptions, and up to 500 audit_log rows by userId. Not self-service — no /account export button exists yet. |
| Rectification | 16 | Art. 32 (Berichtigung, as part of the general claims provision) | Self-service. /account/* (dsgvo-data-flow.md §7). |
| Erasure | 17 | Art. 32 (Löschung/Vernichtung, as part of the general claims provision) | Real code, admin/compliance-triggered. eraseSubscriberData() (apps/web/app/(admin)/subscribers/actions.ts:85-160), gated by requireComplianceActor(). Hard-deletes web_push_subscriptions, onboarding_profile, user_active_mandate, subscriber_roles; anonymizes the subscribers row in place rather than deleting it — see PRIV-11 for the full retention/deletion breakdown and the deliberate Art. 17 vs. Art. 5(1)(c) tension this creates with audit_log. |
| Restriction | 18 | Art. 32 (Einschränkung, as part of the general claims provision) | Manual only. No code path exists to flag a record as "processing restricted" — handled ad hoc by the DPO on request (dsgvo-data-flow.md §7). |
| Portability | 20 | Art. 28 (Recht auf Herausgabe oder Übermittlung der Daten) | Planned, not built. NDJSON export is scoped for Phase B (dsgvo-data-flow.md §7, §8); no code exists today. |
| Objection | 21 | Art. 32 (Widerspruch, as part of the general claims provision) | Real, working, self-service. /account/unsubscribe plus the email unsubscribe link on every broadcast (dsgvo-data-flow.md §5, §7). |
| Automated individual decision-making | 22 | No direct equivalent; general prohibition-style protection is narrower in revDSG than GDPR Art. 22 | Not applicable. Signals are 1:N editorial content with no per-subscriber automated decision — same reasoning as PRIV-07's DPIA-screening determination (§3(a) of that document). This status should be re-checked at the same Phase C trigger PRIV-07 §6 names (suitability engine), since a profile-driven recommendation is exactly the kind of automated decision Art. 22 addresses. |
3. Request handling — who, where, how fast
- Contact point:
[email protected](dsgvo-data-flow.md§1, confirmed live infacts.md
"Entity"). All inbound data-subject requests route here regardless of which right is invoked.
- Who executes: the DPO (Antonios) owns the request and its legal sufficiency; where a right has
real code (access, erasure), the technical execution is performed by whoever holds the compliance role — today, in practice, Toby, per the RACI split already documented in GOV-03 §2.
- Timelines: GDPR Art. 12(3) sets a baseline of one month from receipt, extendable by two
further months for complex or numerous requests (with the data subject informed of the extension within the first month). revDSG does not set a fixed statutory deadline for most rights — Art. 25 access requests are generally expected to be answered "within a reasonable time," commonly read in practice as around 30 days, but this is a practice norm, not a hard statutory clock; verify with counsel before quoting a specific number to a Swiss data subject.
- Verification of identity: not formally documented today. Requests via
[email protected]
should be matched against the account email on file before any export or erasure action is taken — this is a gap PRO-09 should close with a concrete step, not something this document resolves.
4. The honest gap — self-service
Access and erasure both have real, working code paths — but both are admin/compliance-triggered, not self-service. There is no /account export button and no /account delete button today. This matches dsgvo-data-flow.md's own framing (§7: "Mid-term: Export-Endpoint auf /account"; §8 frames self-service portability as a Phase B item). Stating this plainly here rather than implying a self-service capability that doesn't exist: every access or erasure request today requires a human (the DPO or a compliance-role holder) to run the process manually, via the admin actions described in §2.
5. Review
Reviewed whenever PRO-09 is written or updated (the two documents should stay in lockstep), and otherwise annually alongside the other Tier 3 privacy documents.