Roles, Responsibilities & Authorities (RACI)

Satisfies ISO/IEC 27001:2022 clause 5.3 (organizational roles, responsibilities and authorities).

1. ISMS roles

Two roles carry ISMS responsibility today, both confirmed with Toby on 2026-08-01 and consistent with existing, independently-established facts (register/facts.md, "Team / access"):

• ISMS Owner + Security Officer — Toby. Accountable for the ISMS as a whole and for the

technical control surface specifically. This matches the operational reality that Toby is the sole committer across all 181 commits in git log and therefore the only person who can actually change the infrastructure, RLS policies, CI gate, or auth code this ISMS governs.

• DPO / Privacy Owner — Antonios Stergatos. Accountable for GDPR/revDSG obligations. This

matches his existing ownership of docs/compliance/dsgvo-data-flow.md (Owner: Antonios) and his README-stated role as owner of the FMA license and DSGVO workstream. He does not appear in git log — his role is compliance and product, not code.

Philipp Sprenger (co-founder, Structuring & Sales) is explicitly not assigned an ISMS role. He owns pilot acquisition and the Phase C structured-wrapper architecture, neither of which carries ISMS accountability today. If that changes — e.g. once Stripe Connect payouts or structured-wrapper issuance goes live under his ownership — this document should be revisited.

No other roles exist. There is no CISO, no security committee, no board to escalate to. Any RACI entry below that would conventionally route to a broader group routes to these two people instead, and that narrowness is stated honestly rather than papered over with invented committees.

2. RACI table

R = Responsible (does the work) · A = Accountable (owns the outcome, signs off) · C = Consulted (input sought before the decision) · I = Informed (told after the fact)

Notes on specific rows:

• Breach notification decision is deliberately split: Toby is Responsible for determining

what technically happened and assembling the facts (this is exactly the shape of the existing docs/runbooks/db-recovery.md §3.3 audit-chain-corruption runbook, which already routes to "counsel notification within 24h" and "DPO note re: GDPR Art. 33"); Antonios is Accountable for the actual notification decision and content because that is a DPO judgment call, not an engineering one.

• Data-subject-request fulfilment already has a real, working technical path

(apps/web/lib/admin/gdpr-export.ts, eraseSubscriberData in apps/web/app/(admin)/subscribers/actions.ts), gated by requireComplianceActor(). Both actions are today executed by whoever holds the compliance role in practice — currently Toby — which means the Responsible/Accountable split above is the target state, not a description of who has physically clicked the button on every past request.

• Supplier / DPA review sits primarily with Antonios because dsgvo-data-flow.md §10 already

tracks DPA links under his ownership; Toby is Consulted because he is the one who actually adds or swaps a vendor in code (e.g. the Resend → AWS SES migration), and that swap is exactly the kind of event that should trigger a DPA review but historically hasn't reliably (see RISK-009).

3. Segregation of duties — an accepted, tracked gap, not a fabricated mitigation

Annex A 5.3 (segregation of duties) is not currently satisfied. For the technical controls this ISMS governs — RLS policies, the CI gate, the audit-log implementation, auth code — Toby is routinely both Accountable and Responsible, because there is no second engineer to hold the Responsible role independently. CODEOWNERS exists in the repo but is fully commented out and routes nothing (register/facts.md); the mandated review at Stratify's current "Tier 1" process level is an automated review run in a fresh context, not a second human reviewer (CONTRIBUTING.md:37-42).

This is stated here as what it is: a real, current gap, tracked as RISK-002 in register/risks.yaml (inherent score 8, treatment: mitigate, status: open). The intent is to introduce a second reviewer once the team grows past one engineer — no date is committed to that yet (see PLAN.md §6, open decision 4). Until then, the compensating factor is that the CI gate (lint, typecheck, tests, secret scan) still runs on every change regardless of reviewer count, and production RLS/audit-log controls are structural rather than code-review-dependent — but neither of those substitutes for an independent human review of *logic*, and this document does not claim they do.

4. Review

This RACI is reviewed whenever an ISMS role changes hands, when the team grows (specifically: when a second engineer or a first hire with any information-security responsibility joins), and otherwise on the same annual cadence as GOV-02.