Cyber risk management: from assessment to decision

A risk assessment tells a company where it is exposed and how badly. Risk management is what the company does with that knowledge. The distinction is not academic. An assessment is a snapshot taken at one moment, while management is the continuous process of deciding what to do, applying controls, and checking whether the risk has actually gone down. A company that stops at the assessment owns a document, not security. The document ages, the threats move on, and the gap between what the spreadsheet says and what is true on the network widens every quarter.

For a regulated company this gap is a direct liability. ISO/IEC 27001, the NIS2 Directive (EU) 2022/2555, and the DORA Regulation (EU) 2022/2554 all assume risk is managed as a living process with named owners, defined treatment decisions, and evidence that the cycle repeats. Auditors and supervisors do not want to see a one-time report. They want to see a register that changes, decisions that get reviewed, and a board that is engaged. This post explains how to run risk as an ongoing process rather than an annual formality.¹

This is part of our security program overview. We run risk management end to end through governance, risk, and compliance.

A one-off assessment is not risk management

A risk assessment answers one question: where are we exposed and how much? Risk management answers a harder one: what will we do about it, and did it work? Without the second question, an assessment is a list of problems nobody resolves. The list gets filed, the project moves on, and the next assessment a year later finds most of the same items still open.

Continuous risk management turns that static list into decisions, tasks, owners, and measurable progress. The difference shows up in behaviour. A managed risk has a treatment decision, a person responsible, a deadline, and a review date. An assessed-only risk has a severity rating and nothing else. Over a year the managed risk either closes or gets formally re-accepted with a reason, while the assessed-only risk simply rots in a spreadsheet until the next audit reopens it.

The mechanism that makes management continuous is the feedback loop. You apply a control, you check whether the residual risk fell to the level you expected, and you feed that result back into the next assessment. ISO/IEC 27005 describes this as an iterative process of risk identification, analysis, evaluation, and treatment that repeats on a defined cadence.¹ The cadence is the point. Risk that is reviewed once is not managed, it is photographed.

The four ways to treat a risk

Once a risk is identified and rated, a company chooses one of four treatment options for it. The choice is a business decision, not a technical default, and it should be recorded with a reason. ISO/IEC 27005 and ISO 31000 frame these as the standard set of risk treatment options.¹

Most risks are mitigated, but the other three options matter just as much. Transfer does not make the risk disappear, it shares the loss, and a contract or insurance policy with exclusions can leave you holding more than you think. Avoidance is the cleanest option when an activity has no real business value. Acceptance is legitimate, but only when it is explicit: a named decision-maker, a recorded rationale, and a date to revisit it. Silent acceptance, where a risk is simply ignored, is the failure mode that audits punish.

Risk appetite and risk tolerance

You cannot decide how to treat a risk without knowing how much risk the company is willing to carry. That is what risk appetite and risk tolerance define, and the board owns both. Risk appetite is the broad level of risk the organisation is prepared to accept in pursuit of its goals. Risk tolerance is the specific, measurable boundary for a given risk category, the point past which a risk must be escalated or treated rather than accepted.

A worked example makes the difference clear. A bank's appetite statement might say it has a low tolerance for any risk that threatens customer funds or regulatory standing. The tolerance that flows from it is concrete: no unpatched critical vulnerability on an internet-facing system may stay open longer than seven days. Appetite is the philosophy, tolerance is the threshold a risk owner can actually measure against. Without these, every treatment decision becomes an argument, because there is no agreed line between acceptable and unacceptable. NIST's Cybersecurity Framework treats setting risk appetite and tolerance as a governance function the leadership performs, not a technical one IT performs.²

The risk register and risk owners

The central tool of risk management is the risk register. It is the single list of every identified risk with, at minimum, a description, a likelihood and impact rating, the treatment decision, the named owner, the residual risk after treatment, the deadline, and the review date. The register is not bureaucracy for its own sake. It is where the current state and the progress are visible to everyone who needs to see them, and it is the first artefact an ISO/IEC 27001 or DORA auditor asks for.

The most important field is the owner. Every risk needs one named person who is accountable for the treatment decision, not a department or a committee. A risk owned by everyone is owned by no one. The owner is usually a business leader who controls the budget and the activity that creates the risk, not the security team that identified it. The security function maintains the register and challenges the decisions, but the owner carries the call to mitigate, transfer, avoid, or accept.

A register also needs to distinguish inherent risk from residual risk. Inherent risk is the exposure before any controls. Residual risk is what remains after the chosen treatment. Tracking both shows whether a control actually moved the needle and gives the board a defensible basis for accepting what is left. A register that records only a single rating hides whether the controls are working at all.

The monitoring and review cycle

Risk management is not a linear project that finishes. It is a cycle that repeats on a defined cadence, and the monitoring step is where most programs are weakest. Applying a control feels like progress, but the risk is only managed once you have confirmed the residual exposure fell to the level you expected.¹

1. 01
   Assess

   Identify and rate risks through a structured risk assessment, recording likelihood, impact, and inherent rating.
2. 02
   Decide

   For each risk, the owner chooses to mitigate, transfer, avoid, or accept it, and records the rationale against the company's risk appetite.
3. 03
   Apply

   Put the agreed controls in place, assign the owner and a deadline, and link the control to the risk it addresses.
4. 04
   Monitor

   Track whether controls operate as intended and whether the residual risk matches the target. Use metrics and key risk indicators, not opinion.
5. 05
   Review and report

   On a set cadence, refresh the register, re-evaluate accepted risks, and report status and trends to management and the board.
6. 06
   Repeat

   Feed new threats, incidents, audit findings, and business changes back into the next assessment so the cycle stays current.

The cadence depends on the risk. Critical risks and accepted risks need review at least quarterly, while a full reassessment usually runs annually or whenever a significant change happens, such as a major system launch, a merger, or a serious incident. Events should also trigger an off-cycle review. A breach, a new threat intelligence report, or a failed control test all mean the register may be out of date and decisions need revisiting.

Linking risk to business goals

Risk management is useless if it runs in a corner away from the business. The point of rating and treating risks is to protect the things the company is trying to achieve, so every significant risk should connect to a business objective: a revenue stream, a regulatory licence, a customer commitment, or an operational service. When risk is framed this way, the board can weigh a security investment against the value it protects rather than treating it as an open-ended cost.

This framing also fixes prioritisation. A vulnerability scanner produces hundreds of findings with no sense of which ones matter. Tying risk to business impact answers that. The exposure that threatens a system processing customer payments outranks the one on an internal wiki, even if the raw technical severity is identical. Risk that is anchored to business goals is risk the company can actually make decisions about, and it keeps security spend defensible to people who do not read CVE numbers.

The board's role and the regulatory tie

Deciding to accept a risk, or to invest in reducing it, is a business decision, so final accountability sits with the board and senior management. Regulators have made this explicit. NIS2 requires management bodies to approve cybersecurity risk-management measures, oversee their implementation, and can hold individuals personally liable for failures. It also obliges board members to undergo training so they can identify risks and assess management practices. Cyber risk is no longer something the board can wave through as an IT matter.

DORA carries the same logic into the financial sector. It places the management body in charge of the digital operational resilience framework, requires it to set and review risk tolerance, and holds it responsible for the institution's ICT risk management. ISO/IEC 27001 reinforces the pattern through its requirement for top management commitment, defined roles, and management review of the information security management system. Across all three, the message is the same: the board sets appetite, approves treatment of major risks, and reviews the program on a cadence.

A risk assessment you do once a year is a photograph; risk management is the film.

How risk management connects to the rest of the program

Risk management is the engine that drives the rest of the security program. The treatment decisions in the register become the controls inside an information security management system, and the residual risk you accept shapes what goes into your ISO 27001 Statement of Applicability. Third parties are one of the largest sources of risk, so vendor risk management feeds directly into the register, especially under DORA's strict third-party ICT requirements.

Risk management also sets the priorities for everything downstream. It decides which systems get a penetration test first, which gaps justify investment in detection and response, and where business continuity planning needs to focus. Done well, it is the single view that lets a leadership team reason about security as a set of business trade-offs rather than a pile of technical findings. For the regulatory detail behind it, see our explainer on the NIS2 Directive.

How Raptoric helps

We set up risk management as a living process: a structured register, clear treatment decisions tied to a defined risk appetite, named owners, and a monitoring and review cycle with reporting the board can actually use. As an independent firm we challenge the decisions rather than rubber-stamp them, and we map the program to ISO/IEC 27001, NIS2, and DORA so it satisfies both the auditor and real security. We deliver this through governance, risk, and compliance. Book a scoping call.