Cybersecurity risk frameworks for financial institutions

Most regulated fintech operators we work with run two or three cybersecurity risk frameworks in parallel and don’t know it. NIST CSF on the technology side. ISO 27005 because the auditor expects it. FAIR because the board wants currency. And now DORA, requiring its own ICT-specific framing.

Each framework has a job. None of them want to be the only one. And running four parallel registers is how you end up with three different versions of the same risk and a board that can’t make decisions.

What each framework actually does

NIST Cybersecurity Framework (CSF)

A capability framework. Five functions (Identify, Protect, Detect, Respond, Recover) × dozens of categories. Strong at: telling you what controls you should have. Weak at: telling you which risks matter most.

Use it as your control inventory. Map every control you operate to a CSF subcategory. The gaps tell you what’s missing.

ISO 27005

A risk-management process framework. Tells you how to identify, analyse, evaluate, and treat risks in a structured cycle. Strong at: giving you a defensible audit trail. Weak at: prioritisation under constraint.

Use it as your process spine. Your risk register should follow ISO 27005’s structure regardless of what other frameworks you bolt on.

FAIR (Factor Analysis of Information Risk)

A quantitative risk-modelling framework. Translates risks into loss distributions in monetary terms. Strong at: giving the board numbers they can compare to other capital decisions. Weak at: covering hard-to-quantify scenarios (reputational, regulatory).

Use it for your top 5-10 risks where quantification helps prioritise spend. Not for the long tail.

DORA ICT risk-management framework (Articles 5-15)

The ICT-specific overlay required by EU regulation from January 2025. Tells you what an ICT risk-management framework must contain (governance, identification, protection, detection, response, recovery, learning, communication). Strong at: regulator alignment. Weak at: it won’t tell you anything you don’t already know if you’ve done NIST CSF

• ISO 27005 + FAIR honestly.

Use it as your regulator-facing wrapper. The substance lives in the other three; DORA tells you how to package it.

The composition that works

┌──────────────────────────────────────────────┐
│  DORA framework wrapper                      │
│  (regulator-facing structure + reporting)    │
│  ┌────────────────────────────────────────┐  │
│  │  ISO 27005 process spine               │  │
│  │  (risk register + cycle + treatment)   │  │
│  │  ┌──────────────────────────────────┐  │  │
│  │  │  NIST CSF control inventory      │  │  │
│  │  │  (what controls operate)         │  │  │
│  │  └──────────────────────────────────┘  │  │
│  │  ┌──────────────────────────────────┐  │  │
│  │  │  FAIR quant overlay              │  │  │
│  │  │  (top 5-10 risks in £)           │  │  │
│  │  └──────────────────────────────────┘  │  │
│  └────────────────────────────────────────┘  │
└──────────────────────────────────────────────┘

One register. Multiple lenses. Each lens contributes a column to the register entry — not a separate register.

The minimum viable risk register

Eight columns:

1. ID — short, stable
2. Title — one line, board-readable
3. Category — taxonomy you defined once and stick to
4. Description — 3 sentences max: what could happen, why it matters, what we’re doing about it
5. Likelihood × impact — ISO 27005 5×5 grid for everything
6. FAIR-quantified loss range — populated for top 5-10; blank otherwise
7. NIST CSF subcategories — control mapping (which controls currently address this risk)
8. Treatment status — accepted / mitigated / transferred / avoided
   • owner + due date

If your register has 25+ columns, you’re tracking too much per entry. The metadata should be in the audit trail, not the register row.

What goes wrong

Three failure modes from regulated fintech engagements (anonymised):

Failure 1 — three parallel registers

Compliance team’s ISO register. Engineering’s threat-model register. Procurement’s third-party register. Each entry exists in two places with different IDs. Fix: pick one source of truth (typically the ISO spine); other systems reference it.

Failure 2 — FAIR adopted enterprise-wide

Every risk gets quantified. The team spends 30% of its time arguing about loss distributions. Fix: FAIR for top 5-10 only. Use it where it helps; skip where it doesn’t.

Failure 3 — NIST CSF maturity score driving the agenda

The team chases CSF maturity scores instead of risk reduction. Fix: maturity is a leading indicator at best. The lagging indicator is incidents avoided. Track both.

How to know you’re getting it right

Three signals:

• Risk register entry count is stable — under 50 active entries for a typical mid-sized fintech. If it’s 200, you’re tracking the wrong things or not closing what you should.
• Quarterly board paper writes itself — top 5-10 risks plus deltas since last quarter. If the paper takes a week to write, the underlying register is wrong shape.
• Auditor questions decrease — over successive cycles. If they’re going up, the register isn’t being updated as the firm changes.

What to do tomorrow morning

Pick one framework you already partially use. Write down, in one paragraph, what job it does for you. Then ask: is anything in this job not being done by another framework you also use?

If yes — keep that framework for that job. If no — retire it. You’ll have one fewer parallel register to reconcile.

---

This article is part of our DORA readiness pillar. For hands-on help reconciling your risk frameworks, see our GRC and audit readiness service.