Risk Management and Risk Analysis

Grip on Risk, Not on Hope

Cybersecurity is not a technical sidetrack here, but part of continuity, liability, and reputation.

For Risk Management and Risk Analysis, governance only works with measurable goals, clear escalation, and timely decisions.

This way, this topic becomes not a periodic discussion, but a governable part of regular business operations.

Immediate measures (15 minutes)

• Assign ownership, decision lines, and escalation for this topic.
• Translate measures into KPI/KRI and executive reporting.
• Schedule periodic review with a clear deadline and responsible party.

Why this matters

The core of Risk Management and Risk Analysis is risk reduction in practice. Technical context supports the choice of measures, but implementation and assurance are central.

Risk, threat, vulnerability: the basics

Before we continue, three concepts that are often used interchangeably but mean fundamentally different things.

A threat is something that can cause damage. A hacker. Ransomware. A fire. A disgruntled employee. A flooding basement. Threats exist independently of your organization -- you cannot eliminate them, only strengthen your defense against them.

A vulnerability is a weakness that a threat can exploit. A system that has not been patched. An employee who has not received training. A server room without fire protection. A backup that has never been tested. Vulnerabilities you can address.

A risk is the combination of threat and vulnerability, multiplied by the potential impact. It is the likelihood that something goes wrong, times the damage when it does.

An example: the threat is ransomware. The vulnerability is that your backups are not stored offline. The risk is that during a ransomware attack, all your data -- including the backups -- gets encrypted, causing your business operations to come to a complete halt. The impact: days or weeks of lost revenue, reputational damage, potential fines.

Simply put: a threat is the burglar. A vulnerability is the open window. The risk is what happens when the burglar finds that open window.

Why risk analysis is an executive responsibility

Risk analysis is not a technical exercise that you outsource to the IT department. It is a strategic activity that determines where you deploy your limited resources. And that is quintessentially an executive decision.

Every organization has a limited budget for security. You cannot protect everything against everything at once. Risk analysis helps you make choices: which risks are the greatest, which measures have the most impact, and which risks do you consciously accept?

That last point -- risk acceptance -- is perhaps the most important executive decision. If you decide not to mitigate a certain risk, that must be a conscious, documented choice. Not an unknowing omission. The difference between "we know this risk and accept it after consideration" and "we did not know this risk existed" is the difference between governance and negligence.

Under NIS2, the board is explicitly responsible for approving the risk management measures and overseeing their implementation. It is no longer sufficient to say that the IT department handles it. In the previous chapter on board responsibility, you can read why cybersecurity belongs at the executive level -- risk analysis is the instrument with which you concretely fulfill that responsibility.

Risk analysis frameworks: ISO 27005 and NIST

There are multiple established frameworks for conducting risk analyses. The two most commonly used are ISO 27005 and the NIST Risk Management Framework. As an executive, you do not need to know every detail, but it helps to understand which approach your organization follows.

ISO 27005

ISO 27005 is the international standard for information security risk management and directly aligns with ISO 27001 (the information security management system). The process consists of five steps:

1. Establish context -- what is the scope, what are the criteria for risk acceptance?
2. Risk identification -- what threats, vulnerabilities, and assets are there?
3. Risk analysis -- how likely is it and what is the impact?
4. Risk evaluation -- which risks are acceptable and which are not?
5. Risk treatment -- which measures do we take, and which risks do we accept, avoid, or transfer?

NIST Risk Management Framework (RMF)

The NIST framework from the United States follows a similar cycle but places more emphasis on continuous monitoring:

1. Prepare -- prepare organization and context
2. Categorize -- classify systems based on impact
3. Select -- select appropriate security measures
4. Implement -- implement measures
5. Assess -- evaluate effectiveness
6. Authorize -- formal approval by management
7. Monitor -- continuous monitoring and adjustment

Which framework to choose?

Criterion	ISO 27005	NIST RMF
Best for	European organizations, ISO 27001 certification	Organizations working with US government/standards
Approach	Risk-oriented, flexible	More structured, step-by-step
Integration	Fits into ISO 27001 ISMS	Fits into NIST Cybersecurity Framework
Complexity	Medium	Higher, more documentation required
NIS2 alignment	Direct, explicitly designed for EU context	Indirect, but substantively applicable

Practical advice: for most Dutch organizations, ISO 27005 is the logical choice, especially if you are already working with or moving toward ISO 27001. The NIST framework is valuable as a reference but not necessary if you already follow an ISO approach.

Risk appetite and risk acceptance

Risk appetite is the amount of risk that an organization is willing to take to achieve its goals. This differs per organization and per sector. A startup that prioritizes speed above all else accepts different risks than a bank that manages the savings of millions of people.

As the board, you must explicitly establish the risk appetite. That sounds abstract, but it comes down to concrete questions:

• How much financial loss can we absorb from a cyber incident before it threatens our survival?
• How many hours of downtime are acceptable for our critical systems?
• What level of data loss can we tolerate?
• How much reputational damage can we absorb?

Based on those answers, you define risk criteria: a risk with a potential loss above X euros or a downtime above Y hours is unacceptable and must be mitigated. Risks below that threshold can be consciously accepted.

Four ways to deal with risks

Strategy	What it means	Example
Mitigate	Take measures to reduce the likelihood or impact	Implement multi-factor authentication to reduce the risk of account takeovers. Another example: a robust backup and disaster recovery strategy significantly reduces the impact of ransomware
Avoid	Stop the activity that causes the risk	Stop storing payment data if it is not strictly necessary
Transfer	(Partially) shift the risk to another party	Take out a cyber insurance policy, or outsource processing to a certified party
Accept	Consciously take the risk without additional measures	Document and monitor a low risk with limited impact

Every choice must be documented, including the rationale. "We accept this risk because the cost of mitigation is not proportionate to the potential damage" is a valid executive decision. "We did not know this risk existed" is not.

Quantitative vs. qualitative: two ways to measure risks

There are two main approaches to analyzing risks. Both have their value and in practice most organizations use a combination.

Qualitative analysis

In qualitative analysis, you use descriptive scales to assess likelihood and impact: low, medium, high, or a scale of 1 to 5. This is faster, simpler, and less dependent on precise data. The downside is that it is subjective -- what one person rates as "high," another considers "medium."

Example: you assess the risk of a phishing attack as likelihood "high" and impact "medium," resulting in a risk level of "high."

Quantitative analysis

In quantitative analysis, you express everything in numbers and euros. This makes risks mutually comparable and helps in substantiating investment decisions. The downside is that you need reliable data on the frequency of incidents and their costs -- and that data is not always available.

Two commonly used concepts:

• Single Loss Expectancy (SLE) -- the expected damage from a single incident. For example: a ransomware attack costs an estimated 500,000 euros in recovery time, ransom, and lost revenue.
• Annual Loss Expectancy (ALE) -- the SLE times the estimated frequency per year. If you estimate a 10% annual chance of a ransomware attack, the ALE is 50,000 euros.

The ALE is particularly useful for executive decisions: if the ALE of a risk is 50,000 euros and the measure to mitigate that risk costs 30,000 euros per year, then the investment is financially justified.

Aspect	Qualitative	Quantitative
Speed	Fast, hours to days	Slow, weeks to months
Cost	Low	High (data collection, analysis)
Objectivity	Subjective, dependent on assessors	More objective, based on data
Usefulness for executives	Provides overview and priorities	Substantiates investment decisions
When to use	Initial screening, annual reassessment	Major investment decisions, specific risks

Tip for executives: start with a qualitative analysis to quickly gain an overview. Use quantitative analysis for the risks that weigh heaviest, so you can substantiate investment decisions with numbers. The translation of risks into budget is covered extensively in the chapter on security budget and investing.

The risk register: your living document

A risk register is the central document in which all identified risks are recorded, assessed, and tracked. It is not a one-time report that disappears into a drawer -- it is a living document that is regularly updated.

A good risk register contains per risk at minimum:

Field	Explanation
Risk ID	Unique number for reference
Description	What can go wrong, in understandable language
Threat source	Who or what causes it (hacker, employee, natural disaster)
Vulnerability	Which weakness is being exploited
Likelihood	How probable is it (scale or percentage)
Impact	How severe is it (financial, operational, reputational)
Risk level	Likelihood x Impact, or the position in the risk matrix
Owner	Who is responsible for this risk
Treatment	Mitigate, avoid, transfer, or accept
Measures	Which concrete actions are being taken
Status	Open, in treatment, mitigated, accepted
Date of last review	When was this risk last assessed

The risk register is the instrument through which the board maintains oversight. It makes risks visible, traceable, and discussable. A quarterly report to the board should at minimum contain the top 10 risks, the status of the measures, and any new risks that have been identified.

Common cyber risks: a practical overview

Below is an overview of the most common cyber risks for an average organization, with an indicative assessment of likelihood and impact. Use this as a starting point for your own risk analysis -- the specific scores will differ per organization.

Risk	Likelihood	Impact	Explanation
Ransomware attack	High	Very high	Can bring entire business operations to a halt. Average cost in the Netherlands: 250,000 - 1,000,000 euros
Phishing and credential theft	Very high	High	Most common initial attack vector. Leads to unauthorized access and data theft
Data breach due to human error	High	High	Misaddressed email, unsecured cloud storage, lost device. GDPR notification obligation and potential fines
Supply chain attack	Medium	Very high	Attack via supplier or software update. Difficult to detect, broad impact
Insider threat	Medium	High	Disgruntled or careless employee with access to sensitive systems
DDoS attack	High	Medium	Websites and services unreachable. Direct revenue loss for e-commerce
Unpatched system	Very high	High	Known vulnerabilities that have not been resolved. The number-one cause of preventable incidents
Cloud provider outage	Low	Very high	Rare but with major impact if there is no multi-cloud or on-premises fallback
Physical break-in or theft	Medium	Medium	Theft of equipment with sensitive data. Increased risk with remote work
Insufficient logging and detection	High	High	Not an attack itself, but the inability to detect attacks in a timely manner. Average detection time: 204 days

The risk matrix: visual prioritization

A risk matrix -- sometimes called a heatmap -- is the simplest way to visually prioritize risks. You place the likelihood on one axis and the impact on the other, and each position in the matrix corresponds to a risk level.

Impact -->   Low         Medium        High        Very high

Very high    Medium      High          Very high   Critical
High         Medium      High          High        Very high
Medium       Low         Medium        High        High
Low          Low         Low           Medium      Medium

^ Likelihood

The rule of thumb: - Critical risks -- mitigate immediately, requires board attention - Very high risks -- mitigate quickly, include in quarterly reporting - High risks -- mitigate systematically, include in annual plan - Medium risks -- mitigate where cost-effective, otherwise accept with documentation - Low risks -- accept and monitor

Note: the risk matrix is a tool, not a goal in itself. The danger is that it becomes a paper exercise where you endlessly debate whether a risk is "medium-high" or "high-medium." The value lies in the conversation it forces, not in the exact positioning.

From analysis to action

A risk analysis that does not lead to action is a waste of time. The value lies not in the report but in the decisions that follow from it. As the board, after a risk analysis you must at minimum go through the following steps:

1. Prioritize the top 5 risks. Which risks pose the greatest threat to the continuity of the organization? Those receive attention and budget first.

2. Assign owners. Each risk has an owner at management level who is responsible for mitigation. Not the IT department as a collective, but a specific person.

3. Establish a treatment plan. Per risk: which measures do we take, when will they be implemented, and how much does it cost? Make it concrete and measurable.

4. Monitor progress. Include the status of the risks in the quarterly report to the board. Has the measure been implemented? Has the risk decreased? Have new risks been added?

5. Repeat the cycle. A risk analysis is not a one-time exercise. Conduct at minimum an annual reassessment, and interim reassessments during significant changes -- a merger, a cloud migration, a new product, an incident at a peer organization.

Common mistakes

Finally, the pitfalls that organizations most frequently fall into with risk management. Do you recognize one or more? Then that is the starting point for improvement.

Mistake	Consequence	Solution
Conducting risk analysis only once	Outdated risk assessment that does not account for new threats	Reassess at minimum annually, and after every significant change
Only including technical risks	Human and process-related risks are overlooked	Involve HR, legal, compliance, and the business in the analysis
Naming risks but not treating them	A nice report without action. The risk remains	Every risk gets an owner and a treatment plan with deadline
Weighing all risks equally	No prioritization, budget gets fragmented	Use a risk matrix and focus on the top 5
Not documenting risk acceptance	In case of an incident, you cannot demonstrate it was a conscious choice	Document every acceptance decision with rationale and board approval
Treating the risk register as a compliance document	The report is created for the auditor, not for the organization	Use the register as a living governance instrument, not as an archive piece

Remember: risk management is not a science. It is not an exact calculation with hard numbers. It is a structured way to think about uncertainty and make sensible decisions about it. And that is precisely what executives do -- or should do.

Summary

Risk management starts with understanding three concepts: a threat is what can cause damage, a vulnerability is the weakness that gets exploited, and a risk is the combination of both multiplied by the impact. Risk analysis is an executive responsibility because it determines where you deploy your limited resources. Use ISO 27005 as a framework if you operate in a European context, and consciously choose your risk appetite -- how much risk is your organization willing to bear? Start with a qualitative analysis for a quick overview and use quantitative methods (SLE, ALE) to substantiate major investment decisions. Record everything in a risk register that is regularly updated and discussed at board level. Prioritize the top 5 risks, assign owners, and ensure that every risk analysis leads to concrete action. A risk analysis in a drawer is worse than no risk analysis at all -- it gives a false sense of security.

Do this this month

• Determine whether a current risk analysis exists that is no older than twelve months
• Ask your CISO or IT manager for the risk register and verify that the top 5 risks are named and assigned an owner
• Have the board establish the risk appetite: what is the maximum acceptable downtime and the maximum acceptable financial loss?
• Verify that every risk acceptance is documented with a rationale and board approval
• Schedule a quarterly report on the status of the most important risks and the progress of mitigating measures
• Verify that your backup and disaster recovery plans have been tested and that recovery times meet the established risk criteria
• Involve not only IT, but also legal, HR, and the business in the next risk analysis
• Have an independent party review the risk analysis if it was conducted internally

Tip: bring the risk register to the next board meeting. Discuss per risk: do we know this, do we consciously accept this, and is there a plan? Every risk without an owner or treatment plan is a blind spot.

Risk management gives you the instruments to steer cybersecurity based on facts instead of gut feeling. But risks do not exist in a vacuum -- they are increasingly framed by European legislation. In the next chapter, NIS2 and European Cyber Legislation, you can read about the legal obligations that you as an executive face and how to prepare for them.

← Previous Cybersecurity as Executive Responsibility Next → NIS2 and European Cyber Legislation