Performing a risk assessment: methods, models and tools

What is a risk assessment?

A risk assessment (also called risk analysis) is the structured process in which you map out what can go wrong in your organisation, how probable that is, and how large the damage would be if that risk remains ignored and leaves an impact. Based on that, you decide what to do about it.

The end result is not a report that disappears into a drawer. The outcome of a risk assessment determines which controls you implement, who is responsible for them, and how you demonstrate that you are managing risks.

Almost every compliance framework requires it. ISO 27001 makes it explicitly mandatory in clause 6.1. The risk assessment is the foundation for the entire information security approach. NIS2 states that organisations must identify and manage risks. DORA demands the same for financial institutions. Finally, GDPR calls for a risk-based approach to the protection of personal data.

It is also not a one-off exercise. Risks change as your organisation changes: new systems, new suppliers, new employees, new policies. A risk assessment needs a review cadence, at least annually.

Risk = likelihood x impact

The most widely used model is also the simplest: risk is the combination of how probable something is and how serious the consequences are.

Risk = likelihood × impact

If you work with a scale of 1 to 5 for both, this produces a risk score between 1 and 25. High-scoring risks are the first ones you address. Low-scoring risks you may consciously accept.

2 concepts you will encounter in every serious risk assessment:

Inherent risk is the risk before you have put any measure in place. It is the starting point. You determine how large the risk is in a situation without any compensating controls.

Residual risk is the risk that remains after you have implemented measures. No measure eliminates a risk completely: there is always a remainder. You compare that residual risk with your organisation's risk appetite.

Risk appetite is the level of risk that management is willing to accept. This is a governance decision, not a technical one. Without a defined risk appetite, you do not know what to accept and what to address.

Once you have identified and assessed a risk, you have 4 treatment options:

• Mitigate - implement a control that reduces the likelihood or impact
• Accept - consciously document and accept the risk, because it falls within the risk appetite
• Transfer - place the risk with a third party, through insurance or a contract
• Avoid - stop the activity that causes the risk

Methods and models

There is no single correct way to perform a risk assessment. The approach you choose depends on the size of your organisation, the available data, and the purpose of the assessment.

Qualitative risk assessment

With a qualitative approach, you assess risks on a scale (low/medium/high, or 1 to 5) based on thoroughly analyzed judgement. You do not need hard statistical data. A team of subject matter experts discusses the risks and assigns scores based on knowledge and experience.

This is the most commonly used approach for small and medium-sized organisations. It is quicker to set up, easier to explain to non-technical stakeholders, and works well when you are doing a risk assessment for the first time. The limitation is that the scores are subjective, meaning two teams can assess the same risk differently.

Quantitative risk assessment

With a quantitative approach, you express risks in monetary terms. The expected loss value is the probability of an incident multiplied by the financial impact.

This is more precise, but requires reliable data on incident frequency and financial damage. Larger organisations with mature security functions use this for decisions about major investments. For many organisations, a fully quantitative approach is too complex to start with.

A hybrid approach (qualitative for breadth, quantitative for high-scoring risks) is common in practice.

Methodologies

The description of risk assessment above stems from a well-known methodology that the Tidal Control platform follows: IRAMv2 (Information Risk Assessment Methodology), a structured approach developed by the Information Security Forum (ISF). In practice this means that for each risk you first establish the inherent risk, the situation without any controls, and then the residual risk, what remains once you have implemented controls. The difference between the two shows how much a control actually delivers.

For anyone carrying out a risk assessment for ISO 27001, this fits seamlessly. The standard requires a documented, repeatable approach in which you assess and treat risks, and the inherent/residual model gives that structure. You demonstrate not only which risks you have identified, but also that your controls measurably bring the risk down to a level that falls within your risk appetite. Exactly what an auditor wants to see.

Risk assessment step by step

A risk assessment does not have to start out complicated. The steps below serve as a foundation, whether you are working from ISO 27001, NIS2 or an internal quality process.

Step 1 - Define the scope. What is and is not included in the assessment? Which systems, processes, departments or locations are you covering? A clear scope prevents the assessment from expanding endlessly, and also gives you a solid basis during audits.

Step 2 - Identify your assets. What do you need to protect? Think about data and crown jewels (customer data, financial records, intellectual property), systems (servers, applications, networks), processes (order fulfilment, HR processes) and people (employees, suppliers).

Step 3 - Identify threats and vulnerabilities. What can go wrong? For each asset, you look at which threats are relevant. Think of a data breach, system outage, human error, supplier failure, or a ransomware attack. Vulnerabilities are the weak spots that give a threat the opportunity to cause damage.

Step 4 - Estimate likelihood and impact. Use a consistent scale. For example, 1 to 5 for both likelihood and impact. Multiply the scores for a total score per risk. Make sure the team agrees on the definition of each score on the scale.

Step 5 - Prioritise. Focus on the high-scoring risks first. Not all risks deserve the same attention. A risk matrix helps you quickly see which risks exceed the acceptance threshold.

Step 6 - Choose a treatment. Decide per risk: mitigate, accept, transfer or avoid. For risks you mitigate, select the controls you are going to implement. Explicitly link these controls to the risk they address.

Step 7 - Assign ownership. Every risk needs an owner - someone who is responsible for the treatment and who tracks progress. Risks without an owner are not managed.

Step 8 - Document and schedule reviews. Record everything: the risks, the scores, the chosen treatment, the owners and the controls. Set a review cadence. At least annually, and immediately after significant changes to systems, processes or the threat landscape.

Common mistakes

Most organisations make the same mistakes during their first risk assessment.

Treating the risk assessment as a one-off document. You produce a thorough analysis, archive the file, and never look at it again. Two years later an auditor asks for your most recent risk assessment and you find an outdated document referencing systems that were replaced long ago.

Filling in a template without customising it. Templates are useful as a starting point, but a risk assessment must reflect your organisation. Generic risks without context are of little value to an auditor, or to yourself.

Not assigning ownership. A risk without an owner is not treated. It appears on a list, but nobody feels responsible for the control, the progress or the evidence.

Confusing a risk assessment with a vulnerability scan. The output of a technical scan is input for a risk assessment, not the assessment itself. A vulnerability scan tells you which technical weaknesses exist. The risk assessment looks at the broader context: how likely is exploitation, what are the consequences, and what are you going to do about it?

Never defining risk appetite. If you do not know what your organisation is willing to accept, you cannot decide what to address and what to leave. Risk appetite must be established by management before the assessment begins.

Managing risk with software

Starting a risk assessment in a spreadsheet is perfectly normal. But as soon as you are tracking multiple risks with owners, treatments, linked controls and review dates, a spreadsheet loses its grip.

What you need in a risk tool:

• All risks in one place, with likelihood, impact and risk score
• Ownership per risk recorded and visible
• Links between risks and the controls that address them
• Insight into residual risk after controls are implemented
• Review reminders and an audit trail

Tidal Control has a risk register that centralises exactly this. For each risk you record the likelihood and impact, who the owner is, which treatment was chosen, and which controls are linked. After a control is implemented, you immediately see how the residual risk decreases. The links with controls make it possible to navigate from a risk to the associated measures and vice versa. That turns risk management into an ongoing process, not an annual sprint.

For organisations working from a GRC approach, an integrated platform offers the advantage that risks, controls and frameworks do not live in separate documents but are connected to each other.

Not sure where to start?

Take the free Quickscan and discover in five minutes where your organisation stands and what you can tackle first.

Frequently asked questions about risk assessment

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

In practice, the terms are used interchangeably. Technically, a risk analysis is the part where you estimate likelihood and impact - it is a step within the broader risk assessment. The risk assessment also includes identifying risks and comparing the outcomes with your risk appetite. In many frameworks, the overarching term "risk assessment" is used for the complete process.

How often should I perform a risk assessment?

At least annually. In addition, you should revisit the risk assessment after significant changes: a new IT environment, a merger, a new product, an incident, or a change in regulations. ISO 27001 stipulates that the ISMS - including the risk assessment - is reviewed periodically.

Do I need to do a quantitative or qualitative risk assessment for ISO 27001?

ISO 27001 does not prescribe a method - it only requires that you have a documented, repeatable approach and that you assess risks based on the CIA criteria (confidentiality, integrity, availability). Most organisations implementing ISO 27001 use a qualitative approach, which is sufficient for most auditors as long as the process is consistent and demonstrable.

What is the difference between inherent risk and residual risk?

Inherent risk is the risk before you have put any measures in place. Residual risk is the risk that remains after your measures have been implemented. A good risk assessment shows both: the starting point (inherent) and the end point after treatment (residual). You compare the residual risk with your risk appetite to decide whether it is acceptable.

Who sets the risk appetite?

Risk appetite is a governance decision, so it is established by management or the board. Not just by the IT or compliance department. It is a strategic choice about how much risk the organisation is willing to carry, and that is especially important under NIS2. The role of the risk assessment is to operationalise that risk appetite: for each risk, you determine whether the score falls within or outside the accepted level.