Risk assessment: how to run one step by step

An information security risk assessment is the structured process of working out what a company has to protect, what could go wrong, and how much it would cost if it did. It answers three plain questions in order: what valuable things do we own, what threatens them and where are we weak, and how bad would it be if a threat landed. The output is not a feeling about security. It is a ranked list of risks, each rated by how likely it is and how much damage it would do, that tells leadership where money and attention will reduce exposure the most.

For a regulated company this is the foundation everything else rests on. Without it, security spend is guesswork. A company buys a tool because a vendor sold it, or because a peer was breached, and ends up well defended against problems it never had while the real exposure sits untouched. A risk assessment replaces that guesswork with evidence. It is also the first thing an auditor asks for, because ISO/IEC 27001, the NIS2 Directive (EU) 2022/2555, and the DORA Regulation (EU) 2022/2554 all build their requirements on top of a documented assessment. Get the assessment right and the rest of the program has somewhere to stand.

This is part of our security program overview. We run risk assessments through governance, risk, and compliance.

What a risk assessment actually measures

The single most important idea is that a risk is not a threat. A threat is something that can cause harm, such as ransomware, a malicious insider, or a flooded data centre. A risk is the combination of how likely that threat is to be realized against you and how much it would hurt your specific company if it were.¹ Two organisations can face the identical threat and carry completely different risk, because one has the asset exposed to the internet with no backups and the other has it segmented and recoverable.

That distinction is what makes an assessment useful. A list of threats tells you nothing about where to spend. A list of risks, each scored by likelihood and impact, tells you exactly what to fix first. It also keeps the assessment honest. A scary-sounding threat with near-zero likelihood and trivial impact should rank below a mundane one that is both probable and expensive. The job of the assessment is to surface that ordering, not to catalogue every conceivable bad thing.

The methodology that underpins this is well established. NIST SP 800-30 frames risk assessment as identifying threat sources and events, vulnerabilities, likelihood, and impact, then determining risk as a function of likelihood and impact.¹ ISO/IEC 27005 describes the same logic as an iterative cycle of risk identification, analysis, and evaluation that feeds risk treatment.² You do not need to invent a method. You need to apply a recognised one consistently.

The steps of a risk assessment

An assessment follows a recognizable sequence. Each step feeds the next, and skipping one breaks the result. The point of the sequence is to move from a broad inventory to a small, defensible set of prioritized decisions.¹

1. 01
   Inventory your assets

   Identify what you protect: the data, systems, processes, and people that matter. You cannot assess a risk to an asset you have not listed, and an incomplete inventory is the most common reason real exposure gets missed.
2. 02
   Identify threats and vulnerabilities

   For each asset, ask what threatens it and where it is weak. A threat without a matching vulnerability is not yet a risk, and a vulnerability nobody can reach may not matter much.
3. 03
   Assess likelihood and impact

   Rate how likely each risk is to occur and how large the damage would be across confidentiality, integrity, availability, finances, and regulatory standing.
4. 04
   Determine the risk level

   Combine likelihood and impact into a single rating so risks can be compared and ranked against one another on the same scale.
5. 05
   Propose treatment

   For each risk, recommend whether to reduce it with controls, transfer it, accept it, or avoid it, and hand that decision to the risk owner.

The assessment ends at the recommendation. Acting on it, applying controls, assigning owners, and checking whether the risk actually fell, is risk management, the continuous process that consumes the assessment as its starting point. The two are often confused, but the distinction matters: the assessment is a snapshot, management is the film that follows.

How to determine the risk level

The standard tool for turning likelihood and impact into a single rating is a risk matrix. It plots one against the other and reads off a level where they meet. It does not need to be elaborate. A three-by-three or even a two-by-two grid with low, medium, and high is enough to rank risks in a way the whole company understands. The goal is consistent comparison, not false precision, and a simple matrix everyone trusts beats a complex one nobody believes.

Read the matrix as a heat map. The risks in the top-right corner, high impact and high likelihood, are where you act first. The bottom-left, low and low, are usually candidates for acceptance. The value is that two assessors using the same matrix reach roughly the same answer, which is what makes the output defensible to an auditor or a board. A rating with no agreed scale behind it is just an opinion.

Qualitative versus quantitative approaches

There are two broad ways to score risk, and most companies use a mix. A qualitative approach uses descriptive scales: low, medium, high, or a one-to-five rating. It is fast, easy to run with the people who know the business, and good enough to prioritize the vast majority of risks. Its weakness is that high is not a number, so two people may rate the same risk differently and you cannot add risks together or compare them to a budget directly.

A quantitative approach puts money and probability on the risk. It estimates how much a loss event would cost and how often it is expected to happen, producing a figure such as annualised loss expectancy. The strength is that it speaks the language of the board and supports cost-benefit decisions: spend this much on a control to avoid that much expected loss. The weakness is that it depends on data many companies do not have, and a precise-looking number built on guessed inputs is more dangerous than an honest qualitative rating.

In our experience the pragmatic path is to run a qualitative assessment across the whole estate to rank everything, then apply a quantitative model only to the handful of top risks where a large investment decision hangs on the number. That said, the right balance depends on your sector, your data maturity, and what your regulator expects to see.

The risk register and risk owners

The output of the assessment lands in a risk register, the single list of every identified risk. At minimum each entry records a description, the asset affected, the likelihood and impact ratings, the resulting risk level, the proposed treatment, the named owner, and a review date. The register is what turns a one-off study into something the company can actually run against, and it is the first artefact an ISO 27001 or DORA auditor asks to see.

The most important field is the owner. Every significant risk needs one named person accountable for the treatment decision, not a department and not a committee. A risk owned by everyone is owned by no one. The owner is usually the business leader who controls the budget and the activity that creates the risk, not the security team that found it. The security function maintains the register and challenges the decisions, but the owner carries the call to reduce, transfer, accept, or avoid. Without a named owner, a risk has no path to resolution and simply ages in the spreadsheet.

Who runs the assessment and who takes part

A risk assessment is not a job the security team does alone in a room. The security or risk function facilitates it, brings the method, and challenges the ratings, but the substance comes from the people who run the business. Asset owners know what the systems are worth and what would break if they went down. Department heads understand the operational and regulatory impact. IT and engineering know where the technical weaknesses sit. Leaving any of them out produces an assessment that is technically tidy and business-blind.

Senior management has a defined part too, and it is not optional. They set the risk appetite, the level of risk the company is willing to carry, which is the yardstick every treatment decision is measured against. Under NIS2 and DORA, the management body is explicitly accountable for risk-management measures and cannot delegate the responsibility away. A good assessment therefore involves the board at the framing stage and the closing stage, not just as a recipient of a slide once a year.

The link to ISO/IEC 27001, NIS2, and DORA

A risk assessment is not just good practice, it is a regulatory requirement, and the same assessment usually satisfies several obligations at once. ISO/IEC 27001:2022 places risk assessment at the heart of the information security management system: the standard requires a defined risk assessment process whose results drive the selection of Annex A controls and the Statement of Applicability. There is no compliant ISMS without a documented, repeatable assessment underneath it.²

The NIS2 Directive requires essential and important entities to take risk-management measures based on an all-hazards assessment of the risks to their network and information systems, and it makes the management body accountable for those measures. DORA imposes a parallel duty on the financial sector, requiring institutions to identify, classify, and assess ICT risks on a continuous basis as part of their digital operational resilience framework. In all three regimes the assessment is the load-bearing component. For the wider picture, see our explainer on the NIS2 Directive and how it interacts with the ISO 27001 certification path.

How results become a treatment plan

An assessment is only worth the effort if it leads to action. The ranked register is the input to a risk treatment plan, where each significant risk gets one of four decisions, recorded with a reason. Reduce it by applying controls that lower the likelihood or impact. Transfer it, for example through insurance or by moving the workload to a provider that carries the control obligation. Accept it, where the risk is low or reducing it costs more than it is worth, with a documented sign-off. Or avoid it by stopping the risky activity altogether.

The treatment plan converts the assessment into owned tasks with deadlines and review dates, which is where risk management takes over. The plan should also distinguish the residual risk that remains after each control from the inherent risk you started with, so the board can see whether the spend actually moved the needle and can formally accept what is left. An assessment with no treatment plan behind it is a list of problems nobody resolves. The plan is what makes the assessment pay for itself.

An assessment tells you where you are exposed; the treatment plan is the only part that ever reduces the exposure.

How Raptoric helps

We run a risk assessment scoped to your actual assets, threats, and regulatory obligations, then turn it into a prioritized treatment plan with named owners and a register you can keep running. We work through governance, risk, and compliance, and align the result to your ISO 27001, NIS2, or DORA requirements so one assessment carries its weight across several obligations. Book a scoping call.