Risk Assessment & Treatment Methodology

Satisfies ISO/IEC 27001:2022 clause 6.1.2 (information security risk assessment). This document describes the methodology already in use in `register/risks.yaml` — it formalises an existing practice rather than introducing a new one; the register predates this write-up by design (see register/schema.md).

1. Methodology overview

Risk is scored as likelihood × impact, both on a 1–5 scale, giving an inherent score from 1 to 25.

Likelihood (1–5):

Impact (1–5):

Each risk in the register carries an inherent_score (likelihood × impact before treatment) and, once treatment is applied, a residual_likelihood / residual_impact / residual_score. Risks seeded on 1 August 2026 mostly have residual fields left null — this is an honest reflection that treatment hasn't been executed yet for most of them, not a data-entry gap. RISK-007 is the one exception, where residual equals inherent because the treatment is acceptance, not mitigation (see §4).

2. Treatment options

Every risk is assigned exactly one treatment value:

• accept — the risk is understood and deliberately not treated further, because the cost or

complexity of treatment outweighs the exposure at Stratify's current stage.

• mitigate — one or more Annex A controls are applied to reduce likelihood and/or impact. The

controls field lists the Annex A ids doing the work.

• transfer — risk is shifted to a third party (e.g. via insurance or a contractual allocation

to a supplier). Not currently used in the seeded register, but available.

• avoid — the activity or exposure generating the risk is stopped entirely. Not currently used.

3. Risk acceptance authority

There is no board and no risk committee at Stratify today. Acceptance authority is therefore tied to score, not to a governance body that doesn't exist:

• Inherent or residual score ≤ 8: the ISMS Owner may accept the risk directly, recorded in

risks.yaml with status: accepted and a rationale in the vulnerability/threat fields already present in the register.

• Score > 8: still accepted by the ISMS Owner — there is no one else to delegate it to — but

requires an explicit written acceptance with rationale, not a silent status: accepted flip. This means: a dated note (in the risk's register entry or a linked decision log) stating why the score is being accepted rather than further mitigated, self-accountable but documented, so that the record shows a deliberate decision rather than an oversight. This is a self-accountability mechanism, not a fabricated approval chain — it exists so that if the team grows and a second reviewer or a board is added later, there's a clear, timestamped account of what was accepted and why, rather than an unexplained gap.

In practice today, every risk above score 8 in the seeded register (RISK-001, RISK-004, RISK-006, all scoring 10–12) has treatment: mitigate, not accept — no risk above the threshold has actually been accepted yet, so this higher bar hasn't been exercised. RISK-007 (score 8) is the one accepted risk, and sits exactly at the threshold rather than above it.

4. Review cadence

The risk register is reviewed quarterly, or immediately on discovery of a new risk — e.g. a new sub-processor is added, a new attack surface ships (Stripe Connect payouts at Phase C), or an existing control is found not to work as documented (the backup/restore gap below is exactly this kind of discovery). A quarterly cadence matches the register's own review_due field convention even though none of the seeded entries have a review_due date populated yet — that population is part of turning this from a one-time gap-analysis snapshot into a maintained register, which is a GOV-11/GOV-12-adjacent follow-up, not something this methodology document itself performs.

5. Worked example: RISK-004 (backup exists, restore never tested)

To show the methodology applied end to end, walk through one real entry from the register:

• Threat: a real disaster-recovery event reveals the nightly pg_dump backups are incomplete,

corrupted, or the restore procedure doesn't actually work.

• Vulnerability: docs/runbooks/db-recovery.md's own setup checklist has "restore tested

manually" unchecked, and its decision log's most recent entry is a still-open item for the first full restore drill (register/facts.md, "Backup / disaster recovery").

• Likelihood: 2 (unlikely) — a full disaster-recovery event triggering an actual restore

attempt is not an everyday occurrence on a single, otherwise-stable host.

• Impact: 5 (severe) — if the restore silently doesn't work, the consequence is total,

unrecoverable data loss for a live financial-signal product; there is no fallback beyond this backup.

• Inherent score: 10 (2 × 5).
• Treatment: mitigate, via Annex A 8.13 (Information backup) and 8.14 (Redundancy of

information processing facilities) — concretely, this means executing the first restore drill (PRO-07 in the procedure set) rather than continuing to rely on an untested assumption.

• Residual score: left null in the register today, because the mitigating action (an actual

restore drill) has not yet been executed. Once PRO-07 runs and produces a restore-test report, this entry should be updated with a residual likelihood/impact reflecting whether the drill succeeded — if it did, impact drops meaningfully (a tested restore is a known-working fallback rather than an assumption); if it reveals a gap, the score may not move until that gap is fixed.

• Owner: ISMS Owner (Toby), matching the fact that backup/restore is entirely his

responsibility as the sole infrastructure operator.

This is the pattern every register entry should follow: a concrete threat and vulnerability tied to a cited fact, a score derived from the scale in §1, a treatment naming the Annex A controls doing the work, and — once treatment executes — a residual score showing whether it worked.

6. Relationship to the Statement of Applicability and Risk Treatment Plan

register/risks.yaml and register/controls.yaml are cross-referenced by Annex A control id: a risk's controls field names the controls its treatment relies on, and those controls' status in controls.yaml (not_started / partial / implemented) is the honest signal for whether a risk's treatment is actually in place yet, independent of what the risk register's own status field says. GOV-07 (Risk Treatment Plan) turns each register entry into a concrete, time-bound action using this same methodology.