DSAR & Incident Response Flows

Two operational flows a reviewer will ask about: how data-subject rights requests will be handled, and how incidents are handled. Statuses are recorded honestly: the DSAR process is not started (PRIV-05) — the erasure machinery it relies on is implemented (PRIV-04); the incident-response playbook is drafted but not yet exercised, so SEC-13 stays not started until a tabletop is run.

DSAR handling flow

Derived from registers/dsar-log.md and policies/privacy-and-retention-policy.md. Request contents are Tier 2 (restricted store); the repo keeps only a non-identifying index to prove statutory clocks are met.

flowchart TB
  %% source: registers/dsar-log.md, policies/privacy-and-retention-policy.md
  intake["Intake channel — TODO (TBD, ties to support intake)"] --> verify["Identity verification before fulfilment"]
  verify --> clock["Statutory clock starts: 1 month<br/>(extendable to 3 for complex requests)"]
  clock --> type{"Request type<br/>(Art 15–21)"}
  type --> access["Access"]
  type --> rect["Rectification"]
  type --> port["Portability"]
  type --> restrict["Restriction"]
  type --> object["Objection<br/>(incl. profiling)"]
  type --> erase["Erasure"]

  erase --> softdel["DELETE-path: soft delete<br/>+ revoke all sessions"]
  softdel --> grace["Erasure grace window<br/>(default 7d, counsel C4)"]
  grace --> purge["Worker hard delete<br/>+ FK cascades over the personal graph"]
  purge --> events["Cascades pseudonymized app_events<br/>(actor-linked rows)"]
  purge -. "does NOT delete —<br/>anonymization boundary (ML-07)" .-> ml["Anonymous ML snapshots"]

  access --> close["Fulfil + record non-identifying index row<br/>in dsar-log (contents → Tier 2 restricted store)"]
  rect --> close
  port --> close
  restrict --> close
  object --> close
  events --> close

Open design items (PRIV-05): the intake channel, the fulfilment tooling for access/rectification/portability, and the restricted-store location — all TODO, tracked in the register.

Incident response flow

Derived from procedures/incident-response-playbook.md (supports policies/incident-response-policy.md, control SEC-13). Invoke on suspected unauthorized access, a personal-data breach, a lost/compromised device, an exposed secret, or a safety incident from the product's online→offline nature. When unsure, invoke.

flowchart TB
  %% source: procedures/incident-response-playbook.md
  trigger["Trigger: unauthorized access · data breach ·<br/>lost device · exposed secret · safety incident"] --> declare["1 · Declare & assign<br/>DIR = incident commander; scribe; start timeline —<br/>72-hour ICO clock starts at awareness"]
  declare --> triage{"2 · Triage severity"}
  triage -->|"SEV1 — active breach /<br/>data exposure / safety threat"| contain
  triage -->|"SEV2 — contained /<br/>limited impact"| contain
  triage -->|"SEV3 — minor /<br/>near-miss"| contain
  contain["3 · Contain: revoke sessions, rotate secrets,<br/>remove access; safety → sever matching/messaging path"] --> erad["4 · Eradicate root cause<br/>fix lands via change process"]
  erad --> assess{"5 · Breach-notification duty?<br/>(COUNSEL)"}
  assess -->|"likely risk to individuals"| ico["Notify ICO within 72h (Art 33)"]
  assess -->|"high risk to individuals"| subjects["Notify data subjects<br/>without undue delay (Art 34)"]
  assess -->|"no duty"| recover
  ico --> recover
  subjects --> recover
  recover["6 · Recover from verified backup;<br/>reconcile restore vs erasure/retention"] --> pm["7 · Blameless post-mortem<br/>(restricted / Tier 2)"]
  pm --> update["8 · Update data room: non-identifying entry in<br/>incident-log + affected control rows + READINESS"]

Sev	Meaning	Examples
SEV1	Active breach / data exposure / safety threat	Personal data exfiltrated; credible stalking via a location leak; live auth bypass
SEV2	Contained or limited-impact security event	Single leaked credential, rotated before use; isolated authz bug, no data accessed
SEV3	Minor / near-miss	Secret caught by scan pre-merge; low-risk misconfig

Proximity/travel data raises the likelihood of "high risk" — the notification assessment leans conservative by design. A tabletop exercise (leaked credential; presence-data exposure) is required before private beta.