Risk register: name the scenarios that would stop the business

Your Sunday briefing · Risk series

On Tuesday we put forward the sentence this series is built on: your vulnerability backlog is not your risk register. Every Sunday, we will take one piece of that register, the part leadership reads, the board decides on and teams act on. We start with the most important piece, and the one most often skipped: naming what could stop the business.

A backlog and a register answer different questions

A backlog answers: what is vulnerable? It is a list of assets, flaws and scores produced by tools. It is useful, it is long, and it changes every day.

A register answers a different question: what could stop the business, and who answers for it? It is a short list of scenarios, each with a business consequence, an owner and a decision.

Mixing the two produces the same three symptoms in organization after organization:

• Leadership receives thousands of lines and not a single decision to make.
• The team fixes what is rated "critical", not what threatens a process the business lives on.
• The budget follows alert volume, not risk reduction.

What it changes: a board cannot decide on a list of vulnerabilities. It can decide on ten scenarios, as long as they are written in its language.

Start from business processes, not assets

The technical reflex is to start from the inventory: servers, applications, endpoints. You quickly get hundreds of lines and lose the room before money comes up. Start instead from a question any executive understands: which processes, if they stopped for a week, would put the business in trouble?

For most organizations the answer fits in a few verbs: collect revenue, produce or deliver the service, ship, pay, serve customers, meet obligations. It is the same logic as the business impact analysis behind a continuity plan, and that is no accident: the register and continuity look at the same processes, one to decide, the other to hold.

Public methods say the same thing. Since its October 2022 revision, ISO/IEC 27005 describes two complementary ways to identify risk: an event-based approach, which starts from risk sources and their consequences, and an asset-based approach, which works down to the threats and vulnerabilities of each asset. France's EBIOS Risk Manager, published by ANSSI and freely available, devotes two of its five workshops to this step: risk sources, then strategic scenarios. Both agree on the order: first the scenarios that matter to the organization, then the assets that carry them. The backlog comes last, not first.

Anatomy of a scenario

A useful scenario fits in one sentence, and that sentence has four parts:

1. A source: who or what triggers the event. A ransomware group, a fraudster, an employee, a failing supplier, an outage.
2. An event: what happens. Encryption, a diverted payment, a leak, an outage.
3. What is hit: the process first, then the assets behind it.
4. The business consequence: in days of downtime, in dollars, in obligations. A regulatory notification, contractual penalties, a lost customer.

Three versions of the same risk show the difference:

• Too technical: "Exploitation of a VPN vulnerability." That is a backlog line. It says how, not what you lose.
• Too vague: "Cyberattack." Nobody can treat it, size it or be made accountable for it.
• Useful: "A ransomware group encrypts the ERP and its backups; invoicing and shipping stop for ten days, and our two largest customers apply late-delivery penalties." An executive can read it, challenge it and decide on it.

The figures in that example are made up; the method is not. Expressing the consequence in leadership's units is what turns a worry into a decision.

Ten scenarios to start with

Here are ten scenarios most organizations recognize, from SMBs to large enterprises, in any sector. Not all of them are yours: a professional firm has no plant, a municipality does not bid on tenders. Use them as a starting grid, then rewrite them with your own processes, systems and numbers.

1. Ransomware on the core business system: the ERP, customer records or payroll are encrypted; no orders, no invoices, no salaries. See our entry on ransomware.
2. Service stops: a production line, a contact centre or an online platform goes down. The CCQ spent fifteen days without services this summer, and an entire industry with it.
3. Payment fraud: a diverted wire, or a supplier's bank details quietly changed. It is the scenario from our episode on offensive AI: no system is breached, and the money still leaves.
4. Executive mailbox compromise: a leader's account is used to give instructions, read negotiations and set up fraud. This is business email compromise.
5. Personal information leak: customer or employee data gets out. In Quebec this is a confidentiality incident under Law 25, with a register to keep and, where there is a risk of serious injury, notice to the Commission d'accès à l'information and to the people affected.
6. A critical supplier goes down: the hosting provider, the SaaS business application or the subcontractor that carries a process fails, and its outage becomes yours.
7. Intrusion through a provider: a supplier with access to your systems, for maintenance or managed services, becomes the way in. The Master of Malt, Cooksongold and Nepal Stock Exchange incidents all went that way.
8. Loss of a site: an office, plant or warehouse becomes unusable, physically or because its network has to be isolated.
9. Theft of strategic information: bids, plans, price lists, intellectual property. Nothing stops, but a competitor or a buyer now knows too much.
10. Loss of a critical access: admin accounts, cloud identity or the backup console are no longer under your control, or a single person holds the keys.

If your list runs past twenty lines on the first pass, it has turned back into a backlog in disguise. Keep the ten that would hurt most and park the rest.

Three traps

Too technical. The scenario talks about a flaw, a port, a product. It belongs in the backlog. Go one level up: what would that flaw let someone do to which process?

Too vague. "Cyberattack", "data breach", "IT outage". These words cannot be treated, sized or assigned. Add the source, the process and the consequence until someone in the room can disagree with the sentence.

No owner. A scenario without a name next to it is an observation, not a managed risk. And the name must be a person, not a department: "IT" does not make decisions. That is next Sunday's topic, because a risk actually has several owners, and they do different jobs.

This week's test: thirty minutes, three people

Get three people in a room: someone from finance, someone from operations, someone from IT. No more. Set a timer for thirty minutes.

1. Write ten scenarios together, one sentence each, with all four parts: source, event, what is hit, business consequence.
2. Next to each one, write the name of the person who answers for it today. Not who should, who does.
3. Count.

Three results should worry you. Fewer than five scenarios with a named owner: you have a list of fears, not a register yet. Every scenario written by IT: your register speaks technology, and leadership will not see itself in it. No consequence in days or dollars: nobody will be able to choose between two risks, or defend a budget.

What you should have by next Sunday

One page. Ten scenarios written in leadership's language, an "owner" column with its gaps in plain sight, and a rough order of magnitude for each consequence. It is not a complete register yet. It is the part most registers are missing.

Where FortaRisks fits

A register maintained by hand is out of date the day it is published. Forta Cockpit keeps yours current: it fills itself from the platform's signals across 9 risk domains and 52 sub-domains, and every risk carries its inherent and residual level. Your business scenarios stay yours; the platform brings what is actually happening underneath. To see where your organization stands today, the free cyber risk score gives you a reading of your main domains in ten minutes.

Next Sunday: the four owners of every risk. The one who accepts it, the one who treats it, the one who watches it and the one who reports on it, and why mixing them up is the first reason a register goes unread.

Sources: ISO, ISO/IEC 27005:2022, guidance on managing information security risks · ANSSI, the EBIOS Risk Manager method