Risk analysis is the stage of risk management in which an organization establishes how likely an event is and how serious its consequences would be, taking existing safeguards into account – and from that determines the level of risk. It is carried out in several steps: preparing the scope and criteria, identifying risks, determining likelihood and impact, accounting for controls, calculating the risk level and documenting the results. The outcome then feeds into risk evaluation, which decides whether that level is acceptable.
In this article we show what the risk analysis process looks like in practice: how to prepare for it, how to identify risks, how to determine likelihood and impact, which risk analysis methods can be used, how to account for existing safeguards and how to document the results. The broader context – the risk register, matrix, owners and KRIs – is covered in a separate guide to risk management.
What Is Risk Analysis?
Risk analysis is the process of understanding the nature of risk and determining its level. According to ISO 31000, it involves detailed consideration of uncertainties, risk sources, consequences, likelihood, events, scenarios, and existing controls and their effectiveness. In practice it comes down to a few questions: what could happen, how often, how much would it hurt, and what do we already have in place to prevent it or soften the impact.
The result of the analysis is a risk level for each identified risk – most often expressed as a number or a category (low, medium, high, critical). The later decision about which risks to tackle first rests on it.
Risk analysis is required or expected by many regulatory frameworks. The NIS2 directive, in Article 21, lists risk analysis as the first of ten areas of security measures (details in our article on NIS2 requirements), ISO/IEC 27001 requires a defined risk assessment process and retained documented results, and in the financial sector ICT risk is governed by DORA.
Risk Analysis vs Risk Assessment – What’s the Difference?
Risk assessment is the overall process made up of three stages: risk identification, risk analysis and risk evaluation. Risk analysis is therefore one stage of it – the one that determines the level of risk. Evaluation then compares that level with the criteria for acceptability and decides what happens next.
In everyday language, and often in documents, “risk analysis” is used interchangeably with “risk assessment.” That is why it is worth stating explicitly in the risk policy what the organization means by each term. In this article we follow the ISO 31000 split: risk assessment covers identification, analysis and evaluation. In practice, risk analysis and assessment – establishing the level of risk and deciding what to do about it – are carried out together, on the same data.
How to Prepare a Risk Analysis
The most common reason for weak results is last-minute preparation: nobody agreed the scope, everyone reads the scales differently, and the data is scattered. Before the first workshop, it is worth agreeing six things:
- Scope – what the analysis covers: a business process, a system, an organizational unit, a vendor. A narrower scope gives a more accurate result.
- Purpose and context – why the analysis is being done (a board decision, a KSC/NIS2 requirement, an audit, a customer requirement) and which organizational objectives the risk could threaten.
- Risk criteria – likelihood and impact scales with described levels, plus thresholds: the level from which a risk counts as high and who accepts it.
- The team – the process or asset owner, someone from IT or security, a compliance representative, a risk coordinator. Analysis is done with the people who know the process, not at a desk.
- Input data – business impact analysis (BIA), the asset and process register, incident history, audit and test results, the list of critical vendors, regulatory requirements.
- Schedule and format – when and in what form results are recorded, so they can be compared and updated later.
How to Identify Risks
Identification means finding the risks that could hinder objectives within the agreed scope. The starting point is a causal chain: a risk source (threat) exploits a vulnerability, which leads to an event, which leads to a consequence. Each risk is written as one sentence: event – cause – consequence, so that its likelihood and impact can be assessed.
Sources of information include: workshops with process owners, a review of assets and dependencies (including vendors), incident history, audit and vulnerability test results, and regulatory changes. IEC 31010 (risk assessment techniques) describes dozens of techniques. A few are enough to start with:
BCMLogic expert commentary: the most common mistake at this stage is listing gaps instead of risks, e.g. “no network segmentation.” That is a vulnerability, not an event. Only when it is combined with a source and a consequence (“after compromising one computer, an attacker spreads across the network and encrypts servers”) does it become a risk that can be assessed.
How to Determine Likelihood
Likelihood is the chance that an event will occur within a given period. Before assessing it, the organization should define exactly which event is meant and over what time horizon – “a ransomware attack that successfully encrypts the ERP server within the next 12 months” is something different from “any incident.” IEC 31010 notes that the event whose likelihood is being assessed should be defined clearly and precisely.
The scale is easiest to write down as a frequency. An example (an illustrative scale; each organization adapts it):
Ratings should not rest on gut feeling alone. Useful sources include: the organization’s incident history (how many times something happened and how many times it came close), industry data and threat reports, test and audit results (for example, how many vulnerabilities remain unpatched), and expert opinions gathered in a workshop. In GRC-class systems, likelihood can be linked to the number of incidents affecting a given process or asset.
How to Determine Impact
Impact is the consequence if the risk occurs. Instead of judging it with a single gut estimate, break it into several dimensions, each with described thresholds. The final rating is usually the highest of the dimensions – conservatively, because one serious consequence is enough to make a risk significant. An illustrative scale:
Data for impact assessment is best taken from business impact analysis (BIA): how long the maximum tolerable downtime of the process is, what an hour of downtime costs, and which systems and vendors the process depends on. Without a BIA, impact is usually underestimated for risks that hit critical processes.
How to Calculate the Risk Level
The risk level is most often calculated as the product of likelihood and impact: risk level = likelihood × impact. On a 5×5 scale the result falls between 1 and 25 and is assigned to a category according to thresholds set by the organization, e.g. 1-4 low, 5-9 medium, 10-16 high, 17-25 critical. Results are plotted on a risk matrix.
Which Risk Analysis Methods Can Be Used?
For most organizations a good starting point is the semi-quantitative method, with the quantitative one reserved for a few of the most important risks. An example of a quantitative calculation: if a single loss would be PLN 600k and the event happens on average once every two years (a rate of 0.5 per year), the annualized loss expectancy is PLN 300k.
BCMLogic expert commentary: a product of two ordinal scales is a convention for prioritization, not a measurement. Two different pairs (e.g. 5 × 2 and 2 × 5) give the same result although they describe different risks. That is why, for high-impact risks, it is worth looking not only at the product but at the impact value itself.
How to Account for Existing Safeguards
The level of risk depends on what the organization already does to prevent it or soften its effects. That is why it is analyzed at three levels: inherent risk – without taking controls into account; residual risk – after existing safeguards are considered; and target risk – the level the organization wants to reach once planned actions are in place. Inherent risk shows how much risk the organization “carries” without controls, residual how much really remains today, and target where it wants to get to.
Target risk is a plan, not a fact: until the actions are implemented and verified, the residual assessment applies. After implementation the risk is reassessed, and the result becomes the new residual risk.
In line with IEC 31010, it is worth distinguishing controls that change likelihood, controls that change consequences, and those that change both. For example: a mail filter and training reduce the likelihood of an attack, while backups disconnected from the network don’t reduce the chance of an attack but shorten the downtime after one. For each control, it is worth answering three questions:
- What exactly does it change – likelihood, impact, or both?
- Is it implemented and working – is it a real mechanism or a line in a procedure?
- What evidence of effectiveness do we have – a test, an audit, monitoring results?
A control without evidence of effectiveness should not lower the rating. A sensible rule: an effective, tested control lowers the relevant parameter by one or two levels, a partially effective one by one, and one that is untested or exists only on paper not at all. The rule is worth writing into the methodology so that ratings stay comparable.
How to Document the Results of a Risk Analysis
Documentation is the proof that the analysis was done rigorously and the basis for repeating it. ISO/IEC 27001 requires retaining documented information about the risk assessment process and its results, and an auditor or supervisory authority usually asks not only “what is the result” but “where did it come from.” It is worth recording:
- the scope, purpose and date of the analysis and the participants,
- the scales and criteria used (with the methodology version),
- a description of each risk: event, cause, consequence, related process or asset,
- likelihood and impact – inherent, residual and target – with justification and data sources,
- existing controls and evidence of their effectiveness,
- assumptions and limitations of the analysis,
- the risk owner and next decisions (handover to evaluation and treatment).
Results go into the risk register, where they are reviewed and updated. In a spreadsheet, version drift and missing change history are common; in a GRC system, every change of rating, approval and comment stays in the history. Who is accountable for a given risk is easiest to maintain in an organizational structure with named owners.
Risk Analysis Example
The example below walks through the whole chain: threat → risk → likelihood → impact → control → risk level. It concerns a fictional services company (about 150 employees), an invoicing and settlements process, and an ERP system with a file server. The figures and thresholds are chosen for this article, using the scales shown above.
Now we take existing controls into account. For each, we assess what it changes and what evidence of effectiveness we have:
Rating after controls. The filter, training and EDR together lower likelihood by one level: from 4 to 3. We don’t lower it further because two of the three controls are only partially effective and there is no segmentation. Offline backups with a tested restore of about 20 hours shorten the downtime to the 4-24 h band, so impact drops from 5 to 4.
Dashed frame: inherent risk (4 × 5 = 20). Solid frame: residual risk (3 × 4 = 12). Dotted frame: target risk (2 × 4 = 8). Thresholds: 1-4 low, 5-9 medium, 10-16 high, 17-25 critical.
Conclusion of the analysis. The controls lowered the risk from 20 to 12, but residual risk is still high – above the threshold the organization can accept without a board decision. The analysis ends here with the result being handed to evaluation. The natural directions for treatment, which follow from the gaps in the controls table: implementing network segmentation, limiting account privileges and rehearsing the restore scenario. Segmentation limits how far an attack can spread, so the planned actions are meant to bring the risk to its target level: likelihood 2, impact 4, i.e. level 8 (medium) – within what the risk owner can accept without a board decision. After implementation the risk is reassessed, and if the target has been met, target risk becomes the new residual risk.
Common Mistakes in Risk Analysis
- Risks described as gaps – “no segmentation” instead of an event, cause and consequence.
- Scales without definitions – “medium impact” means something different to each participant, so ratings aren’t comparable.
- Assuming a control works – lowering a rating because of a safeguard that was never tested.
- No split between inherent and residual risk – it isn’t visible how much risk the controls are “holding” and what happens if one fails.
- No target risk – a treatment plan with no defined level it should bring the risk down to, so nobody knows when it is “done.”
- Impact assessed without a BIA – downtime and costs estimated off the cuff, usually too low.
- Analysis without justification – a bare result with no data sources or assumptions, which can’t be defended before an auditor.
- A one-off analysis – done once “for the audit,” with no update after incidents and changes.
FAQ
What is the difference between risk analysis and risk assessment?
Risk assessment is the whole process: identification, analysis and evaluation. Risk analysis is its middle stage – it establishes likelihood, impact and the risk level. Evaluation then compares that level with the criteria for acceptability.
How often should a risk analysis be repeated?
ISO 31000 doesn’t prescribe a frequency. In practice many organizations update the analysis cyclically (quarterly or annually, depending on the risk) and after any significant incident, process change, new vendor or regulatory change. It is worth writing the frequency into the policy and sticking to it.
Which risk analysis method should I choose?
For most organizations a good starting point is the semi-quantitative method (scales 1-5, level = likelihood × impact). For the few most important risks, add a quantitative analysis where data exists. The method is chosen to fit the available data and decision needs, not the other way round.
Who should take part in a risk analysis?
The process or asset owner, someone from IT or security, a compliance representative and the risk coordinator who runs the methodology. Analysis is done with the people who know the process, not only in the risk department.
Is risk analysis mandatory?
It follows from many requirements: Article 21 of the NIS2 directive (and, in Poland, the KSC act), ISO/IEC 27001 and, in the financial sector, DORA all expect documented risk management, of which analysis is part. ISO 31000 itself is guidance, not a legal obligation.
What is the difference between inherent, residual and target risk?
Inherent risk is the level of risk without taking controls into account. Residual risk is the level after existing safeguards are considered – it is the residual risk that undergoes evaluation and a decision to accept it or treat it further. Target risk is the level the organization wants to reach once planned actions are implemented; it sets the goal of the treatment plan.
Summary
Risk analysis isn’t a one-off exercise of filling in a table – it is a repeatable way of arriving at a risk level: a clear scope and scales, well-described risks, likelihood and impact based on data, honestly assessed controls and documentation that can be defended. The biggest gain comes from separating inherent, residual and target risk and not assuming a control works until there is evidence that it does.
Read Also
- Risk Management in Organizations – A Complete Guide
- NIS2 2026 – Who Does the New Law Apply To and What Obligations Does It Impose?
- GRC – What Is Governance, Risk & Compliance and How Does It Work in Practice?
- NIS2 – Requirements and Obligations for Organizations. What Must Be Implemented?
See What This Could Look Like for Your Organization
If your organization runs risk analysis in spreadsheets and is looking for a single, consistent methodology with a register, owners and an audit trail, it’s worth seeing what this looks like on a GRC platform. BCMLogic Solutions helps financial and technology companies manage operational risk, business continuity and regulatory compliance – in line with ISO 22301, ISO 27001 and requirements such as DORA and NIS2/KSC.
