Conducting a risk analysis: methods and worked example

Risk management · methods and example

An perform a risk analysis do it in four steps: determine what you are protecting, identify what can go wrong, estimate how bad that would be, and decide what to do about it. The method you choose determines how useful the outcome will be. Below you will read which methods exist, which one suits your organization, what a completed analysis looks like, and what standards and laws specifically require regarding this.

What is a risk analysis?

A risk assessment is a structured evaluation of what can go wrong with the assets that have value for your organization, how likely that is, and what the consequences would be. The outcome is an ordered list of risks with a level, an owner, and a decision: accept, mitigate, transfer, or avoid. In standard compliance language, this is called a risk assessment.

The analysis itself is one step in a larger cycle. Before it is determining your scope and your criteria, after it is risk treatment and assurance. Without that cycle, an analysis yields a snapshot that will no longer be accurate within a year.

What methods are there to conduct a risk assessment?

The methods fall into three families: qualitative (you score on scales such as low, medium, and high), quantitative (you calculate in euros and probabilities), and semi-quantitative (you attach numerical ranges to a qualitative scale). In addition, there are techniques that expose a specific type of risk. The international catalog of techniques for risk management summarizes forty-one of them alone.

The business impact analysis is the method most frequently confused with a risk analysis. It looks at the consequences of downtime, regardless of the cause, and yields recovery times. How to approach that is in our article about the Business Impact Analysis.

Older methods like CRAMM and SPRINT can still be found in documentation, but they have largely been abandoned in Dutch practice. If you work at a municipality, the in-depth risk analysis is relevant: it determines which measures you need on top of the baseline.

Which method fits your organization?

Choose qualitative if you need a complete picture and have limited historical data. That applies to the vast majority of organizations and is sufficient for certification. Switch to semi-quantitative as soon as management asks what a score of “high” means in terms of money. Reserve fully quantitative calculations for a handful of risks involving a major investment.

Combining is allowed and is often wise. A qualitative analysis across the entire breadth, supplemented by a scenario analysis for the two or three risks that can truly impact your organization, provides more direction than a single method for everything.

One caveat with the familiar probability-impact matrix: you are multiplying two rankings together, and the product of that is arithmetically questionable. It works in practice as long as you strictly define the scale steps. Therefore, establish that “high” impact means, for example, more than a hundred thousand in damage or more than a day of downtime. How you build those scales and plot the scores is described in our explanation of a create a risk matrix.

Conducting a risk analysis: the six-step process

Performing a risk analysis is done in six steps: establishing scope and criteria, inventorying what has value, identifying threats and vulnerabilities, estimating probability and impact, determining the treatment, and having the residual risks accepted. That order is the same for every method; what differs is the depth per step.

1. Determine scope and criteria. Establish which processes, systems, and locations are included, what scale you are using, and from which level a risk is unacceptable. You determine these acceptance criteria before you start scoring, not afterward.
2. Make an inventory of what has value. Map your information, systems, suppliers, and the business functions that depend on them. Without this overview, you will systematically miss the risks in the supply chain.
3. Identify threats and vulnerabilities. Per valuable object: what can happen and which vulnerability makes that possible. Use a fixed threat list here, so that two colleagues arrive at the same result.
4. Estimate probability and impact. Score according to your own scale and note why you are giving that score. During an audit, that justification is more important than the figure itself.
5. Determine the treatment. Per risk, you choose to avoid, reduce, transfer, or accept it, with a measure, an owner, and a deadline. What remains after the measure is the residual risk.
6. Let accept and plan the repetition. Residual risks exceeding your criteria go to management for an explicit decision. Set a date for the next review immediately.

If you are working specifically toward certification, this aligns with the step-by-step plan in our explanation of the ISO 27001 risk assessment and on the ISO 27001 Checklist.

Example: what does a completed risk analysis look like?

Below is an elaborated fragment for a service provider with a customer portal, about one hundred employees, and a hosted environment. Five rows from the risk register, from threat to residual risk and owner. This is what it looks like once you have gone through the six steps above.

Two things make this fragment audit-proof. Every risk has an owner with a mandate, meaning someone who can actually implement the measure. And every residual risk is a decision: if anything remains above your acceptance criterion, executive management signs off on it. In this example, all residual risks are at medium or lower, which aligns with a criterion that does not permit high risks.

Three fields are deliberately left out of this excerpt and do belong in your own register: the assessment date, the scale used, and the justification per score. Precisely those three are missing in most registers we encounter.

What do ISO 27001, NEN 7510, the Cyber Security Act, and DORA require?

None of these frameworks prescribe a specific method. They do require you to choose a method, document it, apply it consistently, and periodically review the outcome. That is why a custom-built analysis in Excel will easily pass an audit, as long as the underlying approach has been described.

Separate guidance exists for the substantive implementation. In the Netherlands, the European adoption of ISO 27005 has been the applicable version since August 2024, replacing the 2022 edition. The generic framework above it is ISO 31000, of which a third edition is currently in development. Both are guiding and non-certifiable, so you never demonstrate compliance with them.

If you fall under multiple frameworks, you do not need to create multiple analyses. One register with a column indicating which framework affects each risk works better. What the duty of care means for your organization can be read on our page about NIS2 and the Cybersecurity Act; for the financial sector, the approach is in the DORA checklist and for healthcare in the NEN 7510 checklist.

What does an auditor request for your risk analysis?

An auditor rarely verifies the scores themselves. The question is whether your approach is traceable and whether the outcome leads to anything. In practice, these seven documents determine whether that succeeds.

The fifth rule is where things go wrong most often. In a good setup, every risk can be traced back to at least one control measure, and every measure in the Statement of Applicability can be traced back to a risk. If that two-way link is missing, the auditor cannot verify your choices and a finding will follow, even if the measures themselves are in order. How that chain affects certification can be read on our page about ISO 27001 Certification.

Frequently Asked Questions

What is a risk analysis?

A risk analysis is a structured assessment of what can go wrong with valuable information, systems, or processes, how likely that is, and what the consequences are. The outcome is an ordered list of risks with a level, an owner, and a decision on treatment. In standard terminology, this is called a risk assessment.

What is the difference between a risk analysis and a RI&E (Risk Inventory and Evaluation)?

A risk assessment and evaluation (RI&E) is the legally required occupational health and safety analysis regarding the safety and health of employees, complete with an action plan. Under the Working Conditions Act, every employer is required to have one. An information security risk analysis focuses on the confidentiality, integrity, and availability of information. They have different purposes and do not replace each other.

Which risk analysis method does ISO 27001 require?

ISO 27001 does not prescribe a method. The standard requires that you define and apply a risk assessment process, with documented acceptance criteria, named risk owners, and outcomes that are consistent and comparable upon repetition. A qualitative analysis in a spreadsheet is sufficient, as long as the methodology is described and demonstrably used consistently.

How often do you need to repeat a risk assessment?

At least annually is the standard practice, as well as upon any significant change in your organization, systems, or threat landscape, and following a serious incident. For parts of the digital sector and for financial institutions, an annual review is explicitly mandated in European regulations. Schedule the date immediately upon completing the analysis.

What is residual risk and who accepts it?

The residual risk is what remains after you have taken measures. You compare that with your acceptance criteria. If it remains below that, registration by the risk owner is sufficient. If it exceeds it, management must explicitly and demonstrably sign off on it. That documentation is one of the first things an auditor requests.

Should I work qualitatively or quantitatively?

For most organizations, a qualitative analysis suffices, and that is enough for certification. Quantitative calculation requires reliable data on frequencies and losses, and is primarily worthwhile for major investment decisions. A workable intermediate form is semi-quantitative: you attach a range in euros or downtime hours to each scale step.

What is the difference between a risk analysis and a risk matrix?

The risk analysis is the entire process, from scope and criteria to treatment and acceptance. The risk matrix is one tool within that process: a grid in which you plot probability against impact to prioritize risks. You can perform a full analysis without a matrix, but a matrix without an underlying analysis means nothing.

Who is the risk owner?

The risk owner is the person with the mandate to make decisions regarding that risk and implement the measure. This is typically the process or system owner. The security officer guides the analysis and does not take over that ownership. ISO 27001 explicitly requires you to designate an owner for each risk, and an auditor verifies whether that person is also aware of the role.