Risk management: the approach, the roles and the IT case

Risk management is how an organisation spots what could stop it from reaching its objectives, decides what it accepts, treats the rest and monitors everything over time. It covers every kind of risk, financial, legal, operational, reputational, and increasingly IT risks, which NIS 2 and DORA now require management to steer. Here is the approach, risk appetite, the split of roles, and what changes when the risk is IT-related.

ISO 31000 defines risk as the effect of uncertainty on objectives. Two ideas follow from this very short definition. A risk only exists in relation to an objective: delivering on time, staying solvent, protecting customer data. And an effect can be negative or positive: risk management also helps seize opportunities, not just avoid losses.

Risk management refers to the coordinated activities that direct and control the organisation with regard to risk. So it is not just a list of risks: it includes criteria set by management, decisions, owners, monitoring and reporting. Across a whole company, it is called enterprise risk management (ERM).

It should not be confused with risk analysis, which is only one step: identifying and estimating the risks of a given scope. Risk management then decides what to do about them and makes sure decisions are carried out. Together with governance and compliance, it forms the “R” in GRC.

Two general frameworks dominate, supplemented by methods specific to each field:

• ISO 31000:2018 provides guidelines for any organisation: principles, a framework and a process. It is not certifiable.
• COSO ERM, published in 2017 as “Integrating with Strategy and Performance” by COSO, the body behind the internal control framework of the same name, stresses the link between risk, strategy and performance. It is widely used by listed groups.
• Specialised methods apply the same logic to one field: ISO 27005 and EBIOS Risk Manager for information security, ISO 22301 for business continuity.

The role of the person who runs the system, its duties and place in the organisation are covered in our article on the risk manager.

1. Set the context and criteria. Which objectives, which scope, which stakeholders? Which severity and likelihood scales, and what level of risk does management accept? These criteria must be the same across all fields, or risks cannot be compared.
2. Identify risks. Workshops with business teams, reviews of past incidents, audits, contracts and regulatory watch. Each risk is described by a cause, an event and a consequence for an objective.
3. Analyse. Estimate the severity of consequences and the likelihood of the event, taking existing controls into account. Combining the two gives a level, placed on a risk matrix.
4. Evaluate. Compare each level with the criteria set at the start: is the risk acceptable, or is action needed? This is where risk appetite comes in.
5. Treat. For each risk to treat, choose an option: reduce it with controls, share it (contract, insurance), avoid it by giving up the activity, or retain it through an informed decision. ISO 31000 also mentions deliberately taking risk to pursue an opportunity.
6. Monitor and report. Check that controls are implemented and effective, reassess when the context changes, report to management. The resulting residual risk must be formally accepted by the risk owner.

According to ISO 31000, two activities accompany every step: communication and consultation with stakeholders, and recording of results. The diagram below shows the core of the approach on four risks of a services company.

Risk appetite is the amount and type of risk an organisation is willing to pursue or retain to achieve its objectives. ISO's risk management vocabulary has defined it this way since Guide 73 of 2009, since replaced by ISO 31073, and COSO makes it a core part of strategy. It is not a single number: a bank may have a strong appetite for credit risk, which is its business, and almost none for leaks of customer data.

In practice, it translates into three things:

• a statement from management, a few sentences per major risk category (“we accept no interruption of more than 24 hours to our customer services”);
• thresholds on the risk matrix, separating what is acceptable, what requires treatment and what requires a management decision;
• indicators that warn when you get close: number of risks above the threshold, overdue controls, incidents.

Without an explicit appetite, each team sets its own limit, and management discovers during an incident a risk nobody decided to keep. Recent texts point the same way: DORA requires a resilience strategy, approved by the management body, that sets the tolerance level for information and communication technology (ICT) risk in line with the entity's risk appetite, and NIS 2 requires it to approve cybersecurity risk management measures.

Risk management seldom fails for lack of method; it fails for lack of owners. The Three Lines Model of the Institute of Internal Auditors (IIA), updated in July 2020 to replace the “three lines of defense” model, is the benchmark for most organisations:

The 2020 model stresses cooperation rather than defence, and internal audit's independence from management. The financial sector has written it into law: Article 6 of DORA requires ICT risk management, control and internal audit functions to be kept separate, following the three lines model or an equivalent internal model, and Article 5 gives the management body ultimate responsibility for that risk. In a small company, one person often holds several roles; what matters is that every risk has a named owner, and that whoever manages a risk is not the only one judging whether it is well managed.

IT risk management applies the same approach to information technology. The scope is wider than cybersecurity alone:

• attacks: ransomware, phishing, data theft, compromise of an administrator account;
• failures: data centre outage, human error, an update that blocks production;
• third parties: failure or compromise of a hosting provider, software vendor or managed service provider (see third-party risk management);
• obsolescence and technical debt: unsupported systems, scarce skills;
• projects: new applications, cloud migrations, use of artificial intelligence.

Specialised methods

These risks call for dedicated methods. ISO 27005 adapts the ISO 31000 process to information security. EBIOS Risk Manager, ANSSI's method (guide in French), starts from business assets and the most likely attack scenarios. Security needs are rated for availability, integrity, confidentiality and traceability (CIAP). Penetration tests and audits then check that controls hold.

New obligations

IT risk management is no longer just good practice. Article 21 of NIS 2 requires essential and important entities to take cybersecurity risk management measures based on an all-hazards approach, and Article 20 makes management accountable for them (see our NIS 2 article). DORA requires the financial sector to maintain a comprehensive, documented ICT risk management framework, described in our DORA guide chapter (in French).

One frame for all risks

The trap is to handle IT risk separately, in a vocabulary management does not read. The guide published in 2019 by ANSSI and AMRAE, the French association of risk and insurance managers, says it plainly: digital risk is a business risk, to be steered at the highest level. In practice, use the same severity scales as other risks, express consequences as business impact (production stopped, customers lost, penalties), and feed the main scenarios into the company's risk map. Business process mapping helps make that link between systems and activities.

• The risk register: one risk per line, with its description, owner, inherent and residual ratings, controls and their deadlines.
• The matrix and the map: the risk matrix places each risk by severity and likelihood; the risk map gives management the overall picture.
• The treatment plan: the controls decided, their owners and deadlines, tracked through to completion.
• Indicators: number of risks above appetite, share of overdue controls, accepted risks whose decision is due for review, incidents matched against identified risks. Our article on the security dashboard gives examples for the cyber side.

In a spreadsheet, these elements live apart and quickly fall out of step: the control moves forward, but the risk level stays where it was last year.

• An annual inventory. A list redone each year for the audit committee, unrelated to decisions taken in between.
• Different scales across teams. The CISO's “critical” is not the CFO's “critical”, and nothing can be compared.
• Risks without owners, or assigned to the risk function rather than the business that carries them.
• Poorly worded risks: “cybersecurity” is not a risk; “ransomware stops production for a week” is.
• Implicit acceptance: a high risk left untreated, with no written decision or review date.
• IT risk kept apart, in technical jargon, missing from the company's risk map.