Risk Treatment Plan

Satisfies ISO/IEC 27001:2022 clause 6.1.3(e) (risk treatment plan). This document takes each of the 9 risks currently in `register/risks.yaml` and turns its treatment value into a concrete, time-bound plan, per the methodology in GOV-04.

All target dates below are proposed by this document and are not committed. None of the seeded register entries carry a review_due or committed date — every timeframe here is a reasonable near-term proposal pending explicit confirmation by the ISMS Owner, not a deadline already agreed. Where a plan says "before next production deploy," treat that as the practical trigger rather than a calendar promise.

RISK-001 — Compliance/infra documentation is stale relative to real production architecture

• Inherent score: 12 (likelihood 4 × impact 3) · Treatment: mitigate
• Target controls: 5.33 (Protection of records), 5.34 (Privacy and protection of PII), 7.5

(Protecting against physical and environmental threats)

• Planned action: Correct the Vercel → Hetzner and Resend → AWS SES references in

dsgvo-data-flow.md and pentest-rfp.md (and the other stale documents named in register/facts.md), and log the correction as a GOV-13 nonconformity entry so the drift itself is on record, not just quietly fixed.

• Proposed target: Q3 2026, before PRIV-01/02/08 are marked approved — those documents cite

dsgvo-data-flow.md directly and shouldn't be approved against a stale source.

• Owner: DPO / Privacy Owner (Antonios), per PLAN.md §6 open decision 3 — Toby (infra

author) is the alternative owner; either works, but an owner needs to be confirmed, not assumed.

RISK-002 — No segregation of duties in code review

• Inherent score: 8 (likelihood 2 × impact 4) · Treatment: mitigate
• Target controls: 5.3 (Segregation of duties), 8.4 (Access to source code)
• Planned action: No calendar date is proposed for this one — the real fix is a second

engineer or a designated second reviewer, and that depends on hiring, not a task with a deadline. The interim compensating action is to keep the CI verify gate mandatory (already true) and to explicitly re-confirm at each quarterly risk review that single-committer status hasn't changed.

• Proposed target: revisit at the next quarterly risk review (GOV-04 §4); convert to a

concrete date only once a second engineer is identified.

• Owner: ISMS Owner (Toby).

RISK-003 — No dependency/SCA vulnerability scanning in CI

• Inherent score: 9 (likelihood 3 × impact 3) · Treatment: mitigate
• Target controls: 5.7 (Threat intelligence), 8.8 (Management of technical vulnerabilities)
• Planned action: Wire pnpm audit (or Dependabot/Renovate) into dos-ci.yml as a required

or at minimum a visible check. This is one of the cheapest gaps in the register to close — no architectural change needed.

• Proposed target: Q3 2026, before the next production deploy that touches dependency

versions.

• Owner: ISMS Owner (Toby).

RISK-004 — Backup exists but restore has never been tested

• Inherent score: 10 (likelihood 2 × impact 5) · Treatment: mitigate
• Target controls: 8.13 (Information backup), 8.14 (Redundancy of information processing

facilities)

• Planned action: Execute the first full Hetzner restore drill per `docs/runbooks/

db-recovery.md's own outstanding checklist item, and log a restore-test report (PRO-07). This is a priority item in PLAN.md`'s Phase 3 procedure ordering precisely because impact is severe (total data loss) even though likelihood is low.

• Proposed target: Q3 2026 — first restore drill logged.
• Owner: ISMS Owner (Toby).

RISK-005 — No MFA for elevated (admin/founder/compliance) roles

• Inherent score: 8 (likelihood 2 × impact 4) · Treatment: mitigate
• Target controls: 8.2 (Privileged access rights), 8.5 (Secure authentication)
• Planned action: Add an MFA requirement for the admin, founder, and compliance roles

specifically — these are the roles with GDPR export/erasure and audit-log read access. The existing OTP flow (email-code, 10-minute expiry, rate-limited) is the base authentication layer this would sit on top of, not a replacement for it.

• Proposed target: Q4 2026 — after the RISK-003/RISK-004 items above, since those are cheaper

and higher-scoring.

• Owner: ISMS Owner (Toby).

RISK-006 — No pentest has ever been executed

• Inherent score: 12 (likelihood 3 × impact 4) · Treatment: mitigate
• Target controls: 5.36 (Compliance with policies, rules and standards for information

security), 8.29 (Security testing in development and acceptance)

• Planned action: Correct pentest-rfp.md's infra-scope section (still says "Vercel EU")

before sending it to any vendor — this depends on RISK-001's correction landing first. Once corrected, send the RFP to the existing 4-vendor EU shortlist and execute against the stated €25k budget cap, with RLS-bypass and audit-log tamper-resistance flagged P0 as already drafted.

• Proposed target: before the pentest RFP is sent — practically, Q4 2026, sequenced after

RISK-001.

• Owner: ISMS Owner (Toby).

RISK-007 — Single point of failure: one Hetzner host, no redundancy

• Inherent score: 8 (likelihood 2 × impact 4) · Treatment: accept — not treated
• Target controls: none (explicitly controls: [] in the register)
• Status: This is the one risk in the register with status: accepted and a residual score

equal to its inherent score (8 = 8, unchanged). It is accepted, not mitigated, and stated as such rather than hidden behind a token control. The rationale: running a single Hetzner host with a manual read-only-mode failover toggle (docs/runbooks/db-recovery.md §3.4) instead of redundant infrastructure is a deliberate pre-seed-stage tradeoff — multi-host redundancy has real operational cost and complexity that isn't justified yet at current scale and team size. This acceptance should be revisited once subscriber volume or partner SLA commitments make an outage materially costlier than the redundancy investment.

• Owner: ISMS Owner (Toby).

RISK-008 — Front-end error visibility gap: no client-side Sentry

• Inherent score: 6 (likelihood 3 × impact 2) · Treatment: mitigate
• Target controls: 8.16 (Monitoring activities)
• Planned action: Add sentry.client.config.ts alongside the existing server-side

instrumentation.ts init, so browser-side JavaScript errors (including security-relevant ones, e.g. a broken auth redirect) are captured instead of going unseen.

• Proposed target: Q3 2026 — before the next production deploy; this is a small, low-risk

change to make.

• Owner: ISMS Owner (Toby).

RISK-009 — New sub-processors added since the last DPA review are untracked

• Inherent score: 9 (likelihood 3 × impact 3) · Treatment: mitigate
• Target controls: 5.19 (Information security in supplier relationships), 5.20 (Addressing

information security within supplier agreements), 5.22 (Monitoring, review and change management of supplier services)

• Planned action: Refresh dsgvo-data-flow.md §10's DPA table to reflect the current

processor list (Hetzner as infra host, AWS SES, and confirm coverage for the push-notification vendors Apple/Google/Expo, none of which were reviewed as of the 2026-05-19 last pass), and establish the quarterly supplier-review cadence dsgvo-data-flow.md already states as a documented procedure (PRO-10) rather than an informal habit.

• Proposed target: Q3 2026, as part of the Phase 4 Privacy tier pass alongside the RISK-001

correction — the two overlap in the same document.

• Owner: DPO / Privacy Owner (Antonios).

Summary

All targets above are proposed and require ISMS Owner confirmation before being treated as committed dates in a future revision of this document.