Risk Assessment under ISO 27005: Method, Criteria, Evidence

Risk assessment under ISO 27005 follows four steps: set criteria, identify risks, estimate likelihood and impact, then choose one of four treatment options. BSI-Standard 200-3 names exactly these four options: avoid, reduce, transfer, accept. KaitoSec maps this workflow in its risk register, from setting criteria through to documented sign-off.

What is a risk assessment under ISO 27005, and what does it do for the ISMS?

A risk assessment under ISO 27005 identifies, analyzes, and evaluates information security risks before an organization decides how to handle them. ISO/IEC 27005:2022 provides the guidance for this but doesn't itself mandate anything: the obligation to carry out a risk assessment sits in ISO/IEC 27001, Clause 6.1.2 and 8.2, which 27005 fills out methodologically.

Anyone new to the field tends to confuse the two standards. ISO/IEC 27005 is guidance, not a set of requirements: it describes a method but doesn't check anything an auditor could tick off. Certification applies only to ISO 27001, specifically its Clause 6.1.2 and 8.2 on risk assessment.

Saying "we follow 27005" describes a way of working, not a piece of evidence. There is simply no such thing as certification against ISO/IEC 27005, no matter how rigorously a company applies the method.

The current version is ISO/IEC 27005:2022, the standard's fourth edition. It was published in October 2022, runs to 62 pages, and was developed by technical committee ISO/IEC JTC 1/SC 27; it supersedes the previous edition, ISO/IEC 27005:2018 (ISO). In substance, the standard applies ISO 31000's general risk management principles to the information security context, rather than inventing its own risk logic.

The assessment itself isn't an end in itself: it provides the basis for the Statement of Applicability (SoA) required under ISO/IEC 27001, Clause 6.1.3 (more on that later). This is exactly where tools like KaitoSec come in: in the risk register, risks stay directly linked to assets, requirements, and controls through a shared data model, instead of sitting orphaned in a standalone spreadsheet.

What steps make up the ISO 27005 risk assessment process?

The ISO 27005 risk assessment process follows four phases: risk identification, risk analysis, risk evaluation in the narrower sense, and risk treatment. ISO 27005 takes this structure unchanged from ISO 31000:2009 (Clause 5.4, "Risk Assessment," plus Clause 5.5, "Risk Treatment," per BSI-Standard 200-3's cross-reference in Chapter 9.4) and adapts it to the information security context, without defining any new phases.

Risk identification captures assets, threats, and vulnerabilities and maps them to each other: the foundation every later judgment builds on. New compared with the 2018 edition, ISO/IEC 27005:2022 distinguishes two approaches here: an event-based one that starts from realistic attack or failure scenarios, and an asset-based one that examines assets, threats, and vulnerabilities in detail; the two can be used independently or to complement each other. Risk analysis estimates the likelihood and the possible impact for each identified risk and combines both values into a risk level.

Risk evaluation compares this risk level against previously defined acceptance criteria; the result is a priority order for which risks need to be treated first. Risk treatment selects a treatment option for each prioritized risk: avoidance, reduction, transfer, or acceptance. How these options work in detail is covered in its own section further down.

One role distinction matters here and is often blurred: the risk owner is accountable for a single risk and proposes the treatment option, while approving the resulting residual risk sits with top management. That's a separate decision, covered further on, and the two roles should stay clearly separated in practice.

ISO 27005 deliberately keeps these four phases process-neutral: the standard prescribes no particular scale, no fixed number of levels, and no specific matrix. Which assessment method and which rating scheme to use is left to the organization. One concrete, German-language implementation of this logic is BSI-Standard 200-3 ("Risk Analysis Based on IT-Grundschutz"), which in its annex, Chapter 9.4, maps the four ISO 31000 phases directly onto its own Chapters 4, 5.1, 5.2, and 6 (BSI, Version 1.0, October 2017, pp. 51–52).

Two activities run continuously across all four phases: communication and consultation with stakeholders, and monitoring and review of the judgments made. ISO 27005 doesn't describe a process you run through once and tick off: it describes an ongoing cycle of assessment, treatment, communication, and review.

What criteria do you define before the assessment?

Before the first assessment, you set risk acceptance criteria: at what combination of likelihood and impact a risk counts as tolerable. Setting these criteria corresponds to the upstream phase in ISO 31000:2018, Clause 6.3, "Scope, context and criteria," which precedes the actual assessment and treatment phases in Clause 6.4 and 6.5. BSI-Standard 200-3 recommends using no more than five categories per dimension and aligning them with the relevant departments, so that two people arrive at the same result.

On the KaitoSec platform, this assessment maps onto a configurable scale: technically, almost any level of granularity is possible. That still leaves open how many levels make sense and how they should be defined in substance: the criteria themselves are organization-specific, not laid down by any standard.

BSI 200-3 states in Chapter 5.1 that every organization can define both the number of levels and the criteria itself. There is no fixed scheme an organization has to follow. The standard describes a recommendation, not an obligation.

Specifically, BSI 200-3 suggests using no more than five categories per dimension, and provides an example with four levels per dimension (Tables 8 and 9): rare, medium, frequent, and very frequent for likelihood, and negligible, limited, considerable, and existential for impact.

The standard itself makes clear this is an illustration, not a mandatory scheme: in practice, the majority of users actually work with just two categories per dimension, such as "limited" and "considerable." The four-level example matrix is really the upper bound of granularity, not the norm.

Who ultimately sets these criteria isn't a purely methodological question. The acceptance threshold determines which risk an organization is willing to carry. That decision belongs with management and is covered in more depth in the next section.

How are likelihood and impact combined into a risk value?

Likelihood and impact combine in a matrix to produce the risk value: BSI-Standard 200-3 combines four likelihood levels with four impact levels into four risk categories (low, medium, high, very high). The higher both values, the higher the category. The exact mapping is left to each organization to define.

The logic behind it is simple: one axis carries likelihood, the other carries impact. At the intersection of the two sits the risk category. BSI-Standard 200-3 itself defines four levels for both axes: rare, medium, frequent, and very frequent for likelihood, and negligible, limited, considerable, and existential for impact. In Chapter 5.2 (Table 10), the standard derives four risk categories from these.

"Low" means the existing controls provide adequate protection; in practice, the risk is usually accepted and monitored. At "medium," the existing controls may no longer be sufficient. "High" and "very high" mark cases where existing protection falls short; "very high" risks are rarely accepted in practice.

This four-by-four matrix is a BSI example, not a requirement of ISO 27005 itself. BSI-Standard 200-3 states explicitly in Chapter 5.2 that the matrix is only meant to illustrate examples and should be adapted to the organization's own needs. Anyone who needs different categories, scale levels, or weightings isn't deviating from the standard: they're using exactly the latitude ISO 27005 methodically allows for.

A constructed example illustrates this in practice: a mid-sized IT services provider with around 120 employees is assessing the threat "failure of the central file server." Based on its own outage statistics and experience, the company rates the likelihood as "medium," which under the BSI categorization corresponds to an event occurring somewhere between once every five years and once a year. The impact is rated "considerable," because an outage would take down several departments for hours. In the example matrix, this combination results in the risk category "medium."

Working with categories rather than numbers, as in this case, is the norm in practice, not the exception. A quantitative risk assessment would require extensive, reliable data; in the fast-moving world of information security, most organizations don't have that (BSI-Standard 200-3, Chapter 5.1). Qualitative ratings aren't a compromise here: they're the more realistic basis for decisions.

The table below shows the result for all 16 combinations of likelihood and impact. The pattern is easy to remember: from the corner "rare times negligible" to the corner "very frequent times existential," the category rises in both directions.

Impact / Likelihood	rare	medium	frequent	very frequent
negligible	low	low	low	low
limited	low	low	medium	high
considerable	medium	medium	high	very high
existential	medium	high	very high	very high

Example matrix, not normative. Source: BSI-Standard 200-3, Chapter 5.2.

What treatment options exist, and how do you choose between them?

For risks above the acceptance threshold, there are four treatment options: avoid, reduce, transfer, or accept. BSI-Standard 200-3 requires a reasoned decision between these four options for every threat rated risk category "medium" or higher, along with top management involvement as soon as costs or damages could result.

BSI-Standard 200-3 describes the four options in Chapter 6.1 as follows:

Avoidance eliminates the risk source by restructuring the affected process or information domain. This pays off above all when effective countermeasures would be disproportionately expensive and giving up the risky activity is the simpler solution.

Reduction, or modification, is the most common choice: you implement additional security controls that specifically counter the threat, without giving up the process itself.

Transfer or sharing shifts the risk to another party, for example through insurance or outsourcing. What matters here is how the contract is drafted: only clearly defined liability and service boundaries turn a transfer into a real risk reduction for your own organization.

Acceptance means top management documents the remaining residual risk in a traceable way and signs off on it. BSI-Standard 200-3 envisions this ideally only for risks in category "low," though in practice acceptance is also possible beyond that when the cost of countermeasures exceeds the value being protected.

How firmly this decision escalates upward, the standard makes unambiguously clear.

"The residual risk must then be submitted to top management for approval."

— BSI-Standard 200-3, Chapter 6.1, p. 34 (translated from the German original)

Let's pick up the example from the previous section again: the failure of a central file server, rated risk category "medium." It's exactly from this category upward that BSI-Standard 200-3 requires a reasoned decision between the four options. Rather than accepting the risk, the organization here would typically go for reduction, for example through redundant server infrastructure that eliminates the single point of failure. That lowers the risk category, but doesn't remove it entirely; the remaining residual risk still needs a documented decision.

That these four terms aren't some academic construct also shows outside the BSI context: on its product page for risk management, KaitoSec uses exactly the same four-way split: "Accept, mitigate, transfer, or avoid." The terminology matches the standard because it follows the standard, not the other way around.

Option	Short description	Typical trigger	Who decides
Avoidance	Eliminate the risk source through restructuring	Countermeasures would be disproportionately expensive	Top management
Reduction/modification	Implement additional security controls	The threat needs to be specifically mitigated	Risk owner, with sign-off
Transfer/sharing	Shift the risk to an insurer or service provider	Third-party risk can be secured contractually	Top management, when the contract is signed
Acceptance	Document and approve the residual risk	Risk is low, or countermeasures are disproportionate	Top management

Are protection requirements the same as risk under ISO 27005?

No. Protection requirements and risk are different concepts: determining protection requirements assesses the possible damage if protection goals (confidentiality, integrity, availability) are compromised, regardless of whether and how likely a threat is to materialize. Risk assessment under ISO 27005 additionally factors in exactly these threats and their likelihood.

An example makes the difference tangible. A target object can have high protection requirements for confidentiality because a data loss would have serious consequences, for instance a customer database containing special categories of personal data. That still says nothing about how likely such a loss is, through which attack path it might occur, or which existing controls already intercept it.

Only the risk assessment asks these questions: which threat is even realistically applicable to this target object, how high is the probability of occurrence, and what risk results from impact and probability together. High protection requirements therefore don't automatically translate into high risk: if there's no plausible threat, the risk stays low. Conversely, a target object with moderate protection requirements can carry high risk if a vulnerability is concretely exploitable.

For ISMS practice, this yields a clear order: determining protection requirements answers "what is valuable or critical," while risk assessment answers "what can actually happen, how likely is it, and what follows from that." That's why determining protection requirements typically comes before risk assessment in the workflow. For how the determination of protection requirements is scoped and defined in IT-Grundschutz, see the glossary entry on protection requirements.

BSI terminology reflects this same split: in IT-Grundschutz, the first step is called determination of protection requirements under BSI-Standard 200-2, and the second, for elevated or very high protection requirements, is risk analysis under BSI-Standard 200-3. So the order isn't just terminological; it's built into the methodology itself.

How do you document the risk assessment for audit evidence?

For audit evidence, you document three outcomes: the complete threat and risk register with its ratings, the treatment decision made for each risk along with its rationale, and top management's approval of the remaining residual risk. ISO 27001, Clause 6.1.3, adds a further requirement on top of that: the Statement of Applicability (SoA).

These three building blocks form the audit trail an auditor works through. The threat and risk register shows which risks were identified, how likelihood and impact were rated, and what risk level resulted from that. The treatment decision with rationale lists, for every risk, the option chosen (avoid, reduce, transfer, or accept) together with the reasoning behind that particular choice.

And top management's approval of the residual risk records the fact that, after treatment, there's practically always something left over: BSI-Standard 200-3 requires in Chapter 6.1 (pp. 33–37) that this approval be "documented in a traceable way." A verbal sign-off doesn't meet that bar.

Only once all three building blocks exist and reinforce one another will an auditor accept the risk assessment as complete. If, say, the rationale for a treatment decision is missing, that creates an evidence gap, even if the underlying risk assessment is substantively correct.

The treatment decisions are, at the same time, the input for the Statement of Applicability: any additional security requirements arising from risk treatment feed directly into the SoA, per ISO 27001, Clause 6.1.3. Without that feedback loop, the SoA stays incomplete, even if the risk assessment itself produced clean results.

A one-off document isn't enough. ISO 27001 requires, in Clause 8.2, a risk assessment "at planned intervals" and additionally whenever significant changes occur; the standard itself doesn't prescribe a fixed calendar interval. BSI-Standard 200-3 adds to this, in Chapter 6.2, the concept of "risks under observation": risks that are currently acceptable but could foreseeably increase are flagged separately instead of being lost from view. For how an internal audit under ISO 27001 works in practice, and how this evidence gets checked, see the knowledge article on internal audits.

How does an ISMS tool support ongoing risk assessment?

An ISMS tool doesn't replace the expert judgment behind likelihood and impact. That stays the job of the relevant departments and top management. What it does is structure the process: risks stay linked to assets, requirements, and controls, and a change to a control automatically updates the risks it affects.

This distinction is more than a footnote: mistaking software selection for a better risk assessment leads to disappointment with the actual task. The quality of an assessment depends on how well the relevant department judges the threat landscape and its impact, and no software delivers that. What a tool can deliver is something else: it keeps the assessment consistent, current, and traceably linked, while assets, controls, and responsibilities keep changing day to day.

In concrete terms: instead of maintaining spreadsheets of probability and impact values by hand and tracking links between them manually, a tool like this maps the assessment model in a structured way. KaitoSec's risk management module, for instance, works with a configurable scale for probability and impact that adapts to your own methodology. Inherent risk and residual risk are documented side by side, so the effect of a treatment decision stays visible without overwriting the original assessment.

For treatment itself, the same four familiar options are available, each with a rationale, a sign-off, and an assigned owner. These are details an auditor asks for anyway.

The real difference from a spreadsheet lies in the data model behind it: risks aren't isolated but linked to assets, processes, suppliers, controls, and recovery plans. If a control, for example, is moved from "planned" to "implemented," that's reflected in the linked risk, because both are connected through the shared data model. That changes nothing about the technical judgment itself, but it does change who has to manually maintain the links between an assessment and a control.

Anyone who wants to map their own risk assessment onto KaitoSec can walk through it using their own example in a demo call.

Do I have to follow ISO 27005 to get ISO 27001 certified?

No. ISO 27001 requires a risk assessment in Clause 6.1.2 and 8.2 but doesn't prescribe a particular methodology for it. ISO/IEC 27005 provides the matching guidance and is, in practice, the standard route, because it's built precisely for 27001. Auditors check the result (a traceable, consistent assessment), not literal compliance with 27005.

How often does the risk assessment need to be updated?

ISO 27001 doesn't name a fixed calendar interval; instead it speaks of "planned intervals" and triggers such as significant changes. BSI-Standard 200-3 adds to this, in Chapter 6.2, the concept of risks under observation: risks that are currently acceptable but foreseeably rising are flagged and reassessed at the next review, rather than being left unattended between review dates.

What's the difference between inherent risk and residual risk?

Inherent risk, also called gross risk, describes the assessment without any security controls in place. Residual risk, the net risk, is the assessment after the chosen treatment option has been implemented. Neither ISO/IEC 27001 nor ISO 31000 requires a separate assessment of inherent risk as a mandatory step. It's an optional concept that makes the effect of controls visible, not a normative intermediate step.

What role does top management play in risk treatment?

A decisive one. BSI-Standard 200-3 requires, in so many words, that the residual risk be "submitted to top management for approval" as soon as the treatment decision could result in significant costs or damages, regardless of which of the four treatment options was chosen. That approval is part of the audit evidence, not just an internal formality.

Is an ISO 27005 risk assessment also relevant for NIS2?

Yes, indirectly. The NIS2 Directive requires essential and important entities to implement technical, operational, and organizational risk management measures for information security, but doesn't prescribe a particular methodology for doing so. ISO/IEC 27005 is one of the recognized methodologies organizations use to meet that requirement in practice, alongside other established risk management approaches.

Does ISMS software replace the expert risk assessment?

No. Judging likelihood and impact remains a technical and business decision made by the people responsible and by top management. Software like KaitoSec structures that decision and links it to assets, requirements, and controls, but it doesn't make the judgment on the organization's behalf.