Risk register: the four owners of every risk

Your Sunday briefing · Risk series

"IT" is not a risk owner. Last Sunday, we suggested writing ten scenarios that would stop the business, then putting next to each one the name of the person who answers for it today. If you did the exercise, the "owner" column probably has three flaws: gaps, department names instead of people's names, and the same name on almost every line.

That is not a lack of rigour. The question was simply too short. "Who answers for it?" actually covers four different jobs, which organizations often hand to the same person, or to nobody. This week, we pull them apart.

One word, four jobs

The standards speak of a single "risk owner": the person with the accountability and authority to manage the risk. ISO/IEC 27001 requires one to be assigned to every identified risk, and it is that owner who approves the treatment plan and accepts the residual risk. The definition is right. But in a real organization, the person with the authority to say "we accept this" is almost never the one applying the patches, nor the one watching the indicators every week, nor the one presenting the file to the board.

Hence four roles, which we suggest naming separately for each scenario:

1. The one who accepts. A member of leadership with budget authority over the affected process. They choose the treatment (reduce, transfer, avoid or accept), sign off on the level of residual risk they are prepared to carry, and decide how much money goes into it. This is the owner in the standards' sense.
2. The one who treats. The person who executes the plan: the patches, the segmentation, the revised contract, the restore exercise. They have deadlines and report progress to the one who accepts.
3. The one who watches. The person who tracks the scenario's indicators and raises the alarm when they move: exposure that reappears, a threat now targeting your sector, a supplier whose rating drops. They do not have to fix anything; they have to see, and to say.
4. The one who reports. The person who presents the scenario to the executive committee or the board, with its level, its trend and the decisions expected of them. Often the head of security or risk, and that is no accident: they translate the work of the other three into the language of the people who decide.

Public frameworks describe the same separation under other names. The Institute of Internal Auditors' Three Lines Model, revised in July 2020, gives the management of risk to first-line roles, expertise, monitoring and challenge to second-line roles, and independent assurance to internal audit, under the ultimate accountability of the governing body to stakeholders. The NIST Cybersecurity Framework 2.0, published in February 2024, makes it a category of its Govern function: organizational leadership is responsible and accountable for cybersecurity risk (GV.RR-01), and roles, responsibilities and authorities related to that risk are established, communicated, understood and enforced (GV.RR-02). For federally regulated financial institutions, OSFI Guideline B-13 asks senior management to assign responsibility for technology and cyber risk to senior officers. None of these texts says "IT takes care of it."

One scenario, four names

Take the first scenario from last Sunday: a ransomware group encrypts the ERP and its backups; invoicing and shipping stop for ten days, and our two largest customers apply their late-delivery penalties.

• Accepts: the VP of Operations. It is her process that stops, her customers who apply penalties, her budget that pays for recovery. She decides whether a possible ten-day outage is acceptable, or whether to fund isolated backups and a restore exercise to bring that number down to three.
• Treats: the IT director. He rolls out offline backups, segments the ERP, hardens administrator access and runs the restore test, with a date for each step.
• Watches: the security lead. He tracks the exposure of the ERP and its remote access, the ransomware groups active in your sector and the date of the last successful restore test. If any of those indicators moves, he tells the VP before the next committee, not after.
• Reports: the CISO, to the audit committee, every quarter: the scenario's level, what changed, what remains open and the decision expected.

In a small business, two of these names may be the same person. That is fine as long as two specific roles stay separate, the ones in the trap below.

Four ways to get the column wrong

IT owns everything. This is the most common flaw, and it is understandable: IT sees the vulnerabilities, so it gets the risks. But IT has neither the authority to decide that a ten-day outage is acceptable nor the budget to prevent it. The result: it accepts by default risks that are not its own, or it asks for budget without being able to speak to the business consequence. IT is very often the one who treats. It is rarely the one who accepts.

A department instead of a person. "Finance", "Operations", "Security". A department does not sign, does not appear before the committee and does not get the call at 3 a.m. If the cell holds a department name, it is empty.

The one who treats also accepts. When the same person executes the plan and judges whether the remaining risk is acceptable, they are grading their own work. Nobody challenges the moment "enough" becomes "good enough." That is precisely the separation the Three Lines Model protects: whoever manages the risk is not whoever challenges it. In a small organization, these are the two roles to give to two different people, even if one of them also does the watching.

Nobody accepts. The scenario has been rated "high" for eighteen months, everyone knows it, and no decision has been made. That is not an accepted risk: it is an abandoned one. An accepted risk carries a signature, a date and a review deadline. Without them, the register line describes a worry, not a decision.

The matrix, on one page

Add four columns to your list of scenarios, and a fifth for the date the acceptance must be reviewed. Three example lines:

• Ransomware on the ERP. Accepts: the VP of Operations. Treats: the IT director. Watches: the security lead. Reports: the CISO, to the audit committee. Review: March 2027.
• Payment fraud. Accepts: the CFO. Treats: the controller. Watches: the security lead. Reports: the CISO, to the audit committee. Review: January 2027.
• Critical SaaS supplier outage. Accepts: the VP of Sales. Treats: the procurement lead. Watches: the supplier risk lead. Reports: the CISO, to the executive committee. Review: December 2026.

The job titles are examples; in your register, they are people's names. Three rules are enough to keep it honest. One person's name per cell, never a department. The "accepts" column holds only members of leadership who have a budget. And every acceptance has a review date: a risk accepted in 2026 is not accepted forever, because the threat, the exposure and the business all change.

This week's test: thirty minutes, four columns

Go back to your ten scenarios from last Sunday. Bring together the same three people, finance, operations and IT, and set the timer to thirty minutes.

1. For each scenario, fill in the four columns with people's names. Not the people who should, the people who do today. Leave empty what is empty.
2. Add the date of the last acceptance decision, if there is one.
3. Count.

Four results should worry you. An empty "accepts" column on more than half the lines: leadership has not yet taken ownership of its register. The same name in the "accepts" and "treats" columns: nobody is challenging the level of remaining risk. The IT director in the "accepts" column of more than three scenarios: IT is carrying business decisions that are not its own. No acceptance dates at all: your risks are not accepted, they are tolerated without anyone having decided so.

What you should have by next Sunday

One page. Your ten scenarios, four people's names per line, the gaps clearly visible, and for every scenario already accepted, a review date. The gaps are not a failure: each one is a conversation to have with a member of leadership this week, and that conversation is what turns a spreadsheet into a register.

Where FortaRisks fits

The four roles do not need the same screen. Forta Cockpit is the view for those who accept and those who report: every risk carries its inherent and residual level, the treatment chosen under ISO 27005 (accept, reduce, transfer, avoid), and a dated acceptance that reopens on its own when it expires. Forta Actions is the view for those who treat: a short queue of actions, each with an owner, an urgency and a deadline, which closes itself when the signal disappears. In between, those who watch see the other modules' signals come to them without having to look. To put names against your first scenarios with an expert, the risk prioritization session starts from your assets, your controls and your findings.

Next Sunday: exposure, what attackers see first. Before reading your register, an attacker reads your attack surface. How to connect it to your scenarios, and to the person who watches them.

Sources: ISO, ISO/IEC 27001:2022, information security management systems · ISO, ISO/IEC 27005:2022, guidance on managing information security risks · The Institute of Internal Auditors, The IIA's Three Lines Model (July 2020) · NIST, Cybersecurity Framework 2.0 (CSWP 29), GV.RR category · OSFI, Guideline B-13, Technology and Cyber Risk Management