Information security risk assessment: a practical step-by-step guide

The risk assessment is the beating heart of ISO 27001. The standard does not prescribe which measures you must take; instead it obliges you to assess your risks and, on that basis, determine what is needed. Everything that follows — the Statement of Applicability, the risk treatment plan, the chosen Annex A controls — flows from that assessment. Yet this is precisely the component where organisations most often get stuck. This guide shows how to set up a risk assessment that not only passes the audit but genuinely steers.

Risk assessment versus gap analysis

First, a common confusion. A gap analysis compares your current situation against a standard and shows what is missing: do you have a password policy, an incident process, logging? Useful, but it says nothing about risk. A risk assessment starts from the threats facing your organisation and determines which of them are unacceptable. The gap analysis looks at the standard; the risk assessment looks at your actual exposure. For ISO 27001 you need both, but it is the risk assessment that determines which measures are truly relevant.

Step 1: Define your scope and context

A risk assessment without a defined scope becomes boundless. Determine which business units, processes, systems and information flows you will assess. Align with the scope of your management system and the context of the organisation: which legal requirements apply, what do customers expect, which stakeholders are involved? This boundary prevents you from drowning in detail or leaving material risks out of sight.

Step 2: Choose a method — asset-based or scenario-based

There are broadly two approaches. In the asset-based method you first inventory your information assets (systems, data sources, applications) and determine the threats and vulnerabilities for each. This approach is thorough and traceable, but in large organisations it can lead to enormous, hard-to-maintain registers.

In the scenario-based method you reason from threat scenarios: what happens if ransomware strikes, if an employee accidentally shares a customer file, if a supplier is compromised? This approach aligns better with how management views risk and often produces sharper prioritisation. ISO 27001:2022 permits both; the standard prescribes no method, as long as your approach is consistent and repeatable. In practice a combination often works best: scenarios as the starting point, with the key assets mapped beneath them.

Step 3: Assess likelihood and impact

For each risk you determine the likelihood of it occurring and the impact if it does. This is where things often go wrong: without a clear scale, almost everything becomes 'medium'. So define concrete levels. For likelihood, for example: rare (once every several years), possible (annually), likely (several times a year). For impact: anchored in what genuinely affects the organisation — lost revenue, fines, customer loss, reputational damage, failure of critical processes.

Assess impact preferably along the three classic dimensions of information security: confidentiality, integrity and availability. A data breach primarily affects confidentiality; undetected data manipulation affects integrity; a downed system affects availability. Decomposing impact this way prevents you from unintentionally underestimating risks.

Step 4: Calculate and prioritise the risk level

The risk level is typically a combination of likelihood and impact, often shown in a risk matrix. More important than the precise arithmetic score is that you establish a risk acceptance criterion in advance: which level does the organisation accept, and above which threshold is treatment mandatory? This criterion must be set by management, because it is a deliberate choice about risk appetite, not a technical matter.

Step 5: Treat the risks

For each risk above the acceptance threshold you choose a treatment. The standard offers four options: reduce (implement measures), accept (deliberately bear the risk), transfer (for example via insurance or outsourcing) and avoid (cease the risky activity). Most risks are reduced through controls. This creates the direct link with Annex A: the chosen measures form the basis of your Statement of Applicability (SoA), and the full set of treatment decisions is recorded in the risk treatment plan with owners and deadlines.

Importantly, you do not blindly implement all 93 Annex A controls. You implement the controls that address your identified risks, and justify in the SoA which you do and do not apply, and why.

Step 6: Keep the assessment alive

The biggest pitfall is that the risk assessment becomes a one-off document that gathers dust after certification. Risk changes constantly: new systems, new suppliers, new threats, changes in law and regulation. ISO 27001 therefore requires periodic reassessment and revision upon significant changes. We advise at minimum an annual full reassessment, supplemented by a light review at every major change. That keeps the assessment a steering instrument rather than an audit obligation.

Common mistakes

In practice we see a number of recurring mistakes. An overly granular asset inventory that is impossible to maintain. Risk scores without substantiation, making the assessment look subjective. The absence of an explicit acceptance criterion, leaving it unclear what 'too high' means. Risk ownership placed with the security department instead of with the line that actually bears the risk. And finally, an assessment that does not translate into concrete measures — a beautiful matrix with no consequence.

Secure Audit helps organisations set up and perform risk assessments aligned with ISO 27001 that remain practically usable, from method selection to risk treatment plan and SoA. Get in touch for a no-obligation conversation about your situation.