Breach Notification — Regulatory Procedure

1. Purpose and relationship to existing documents

This document is the regulatory/DPO-facing counterpart to PRO-08 (Tier 2, pending per PLAN.md §4 and named in POL-09-incident-management.md §4 as the document that will write the general dual-clock decision tree). PRO-08, once written, will cover incident response mechanics — triage, containment, recovery — for arbitrary incident classes. This document covers the same dual-clock decision specifically from the notification-obligation side: who decides, what must be said, when the clock starts, and when an individual (not just the regulator) must be told.

2. The two clocks

• GDPR Art. 33 — notification to the competent supervisory authority **without undue delay

and, where feasible, not later than 72 hours** after becoming aware of the breach, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons.

• revDSG Art. 24 — notification to the Federal Data Protection and Information Commissioner

(EDÖB) "as soon as possible" (so rasch als möglich), with no fixed deadline — a materially different clock shape from GDPR's, not just a translation of it. Both clocks apply in parallel wherever a breach involves both EEA and Swiss data subjects, which is the normal case given Stratify's dual-track privacy regime (PLAN.md §2).

• A third clock (DORA-equivalent, 4h/24h) becomes live once the FMA Liechtenstein licence lands

(Phase C) — out of scope for this document, tracked as a future addition per POL-09 §4.

3. Who decides notification is required

Per the RACI split already recorded in GOV-03-roles-and-raci.md §2: the ISMS Owner (Toby) is Responsible for determining what technically happened and assembling the facts — this is the same shape as the existing docs/runbooks/db-recovery.md §3.3 audit-chain-corruption runbook, which already routes to "counsel notification within 24h" and a "DPO note re: GDPR Art. 33." The DPO / Privacy Owner (Antonios) is Accountable for the actual notification decision and its content — this is a legal/regulatory judgment, not an engineering one, and stays with the DPO even though the underlying facts are usually assembled by the ISMS Owner first.

In practice: the ISMS Owner triages and assembles facts → consults the DPO with those facts → the DPO decides whether the Art. 33/34 (and Art. 24) thresholds are met and, if so, drafts and sends the notification.

4. What the notification must contain (Art. 33(3))

A GDPR Art. 33 notification to the supervisory authority must describe, at minimum:

1. The nature of the breach, including where possible the categories and approximate number of

data subjects concerned, and the categories and approximate number of personal data records concerned.

1. The name and contact details of the DPO or other contact point where more information can

be obtained — [email protected] for Stratify.

1. The likely consequences of the breach.
2. The measures taken or proposed to address the breach, including, where appropriate,

measures to mitigate its possible adverse effects.

Where not all of this is known within the 72-hour window, GDPR permits phased notification — an initial notification with what is known, followed by further information "without undue delay" as it becomes available. This is worth stating explicitly because Stratify's technical incident posture (§5 below) may well produce a "we know tampering happened" signal before a "we know exactly which subjects were affected" answer — phased notification is the correct response to that gap, not a reason to delay the initial notification past 72 hours.

5. When the clock starts — from awareness, not from the incident

The Art. 33 72-hour clock starts when the controller becomes aware of the breach, not when the breach technically occurred. "Awareness" is generally read as the point at which there is a reasonable degree of certainty that a security incident has occurred and that it involves personal data — not the first vague suspicion, but also not the point at which every detail is confirmed. For Stratify, the most concrete existing trigger for "awareness" is a verifyChain() divergence (see §6) — that is a clear, timestamped, unambiguous awareness event, unlike many other incident classes where "awareness" is fuzzier and should be documented explicitly as a dated log entry the moment it happens, precisely because the clock depends on it.

6. Detection basis — audit-log integrity is a genuinely strong case

A recurring hard question in breach procedures is "how would we even detect this." For one incident class — audit-log tampering — Stratify has a real, non-aspirational answer, not just a procedural commitment:

• The audit_log table is append-only, enforced at the database layer: a Postgres trigger

function (audit_log_no_mutate(), supabase/migrations/0001_init.sql:124-154) raises on BEFORE UPDATE/BEFORE DELETE — this is not app convention, it cannot be bypassed by an application bug (facts.md, "Audit log").

• Every row is chained: hash = SHA-256(prev_hash || canonical(payload)) over a deterministic,

key-sorted JSON event (apps/web/lib/audit/chain.ts:34-39).

• verifyChain() (apps/web/lib/audit/chain.ts:101-137) replays the entire table in pages of

1000 and returns either { ok: true, rows: N } or { ok: false, firstBadId: N } — a concrete, machine-checkable detection signal, not a manual review process.

• This mechanism detects tampering after the fact — chain verification cannot prevent a

compromised service-role key from writing a valid *next* link, since the service-role key is the only bypass of the RLS deny-all-SELECT policy on audit_log and can therefore append legitimately-hashed rows (facts.md, "Existing security controls already operating" table). It is a strong detection control for audit-log integrity specifically, not a general breach-detection system for every incident class.

• A P0 runbook already exists for exactly this scenario: docs/runbooks/db-recovery.md §3.3 —

forensic snapshot, service-role lockdown, counsel notification within 24h, and a DPO note referencing GDPR Art. 33 (see POL-09-incident-management.md §2 for the full six-step breakdown).

For incident classes outside audit-log tampering (a leaked credential, an RLS-bypass discovery, a sub-processor compromise), no equivalent concrete detection mechanism exists today — that gap is named honestly in POL-09-incident-management.md §7 and is PRO-08's job to close, not this document's.

7. Individual notification — Art. 34 threshold

Art. 34 requires notifying affected individuals directly, in addition to the supervisory authority, when the breach is likely to result in a high risk to their rights and freedoms — a higher bar than the Art. 33 authority-notification trigger. Relevant factors: the type of data exposed (financial/account data materially raises the bar above, e.g., a leaked marketing waitlist email), the number of subjects, whether the data was encrypted/pseudonymized in a way that neutralizes the risk, and the likely consequences (financial fraud, identity theft, reputational harm). This is a DPO judgment call made case-by-case; no general threshold table is asserted here beyond the statutory "high risk" standard, since a numeric proxy would misstate the actual legal test.

8. Review

Reviewed whenever PRO-08 is written (the two documents should stay in lockstep on the notification decision tree), and otherwise annually alongside the other Tier 3 privacy documents.