ISO 27001 risk assessment: risks that name an asset, a threat and a consequence

An ISO 27001 risk assessment identifies what could compromise the confidentiality, integrity or availability of information in scope, evaluates how likely and how damaging each is, and decides what to do about it. Everything downstream — the controls selected, the statement of applicability, the treatment plan — is derived from it, which is why a weak assessment produces a weak management system regardless of how much documentation follows.

The standard does not prescribe a method. It requires that the method be defined, repeatable and produce consistent results — meaning two people assessing the same risk should land in roughly the same place, and next year’s assessment should be comparable to this one.

Writing an ISO 27001 risk assessment row that can be treated

A usable risk names three things: the asset or process at stake, the threat or event, and the consequence. "Customer data" is not a risk. "Customer records are exposed because a departing employee retains access to the CRM, leading to a notifiable breach" is one — and it implies its control and its evidence without further discussion.

• Asset-based: start from information assets, then ask what threatens each. Thorough, slow, and prone to producing enormous inventories.
• Scenario-based: start from plausible events — ransomware, supplier outage, insider misuse, lost device — and trace what they would affect. Faster and easier to keep current.
• Most organisations do better with scenarios, provided the scenarios cover the asset types in scope.

Scoring without pretending to precision

1. Define the likelihood and impact scales in words, with examples, before scoring anything.
2. Score inherent risk — before controls — so the value of a control is visible.
3. Record the existing controls and score residual risk after them.
4. Compare residual risk to a risk acceptance criterion agreed by management, not by the person doing the assessment.
5. Decide treatment: modify, avoid, share or accept — and record who accepted anything accepted.
6. Feed the selected controls into the statement of applicability.

Five-by-five matrices invite false precision. What matters is that everything above the acceptance line has a treatment with an owner and a date, and that everything below it was seen and accepted by someone with the authority to accept it. A risk marked 12 rather than 9 changes nothing if both sit above the line.

The parts people skip

Risk acceptance is routinely done implicitly: the risk sits in the register untreated, and nobody signs anything. Auditors ask who accepted it. Similarly, the assessment is often performed once and then referenced for three years, while the business changes underneath it.

Supplier risk is the other consistent gap. Information held by a processor is still in scope, and its risks belong in the same assessment rather than in a separate vendor spreadsheet nobody reads.

A risk assessment is a table with a long life: dozens of rows, several assessors, an annual comparison, and an auditor asking what it said last cycle. Ettex Sheets keeps the assessment and its scoring with version history, so the movement between cycles — new risks, retired ones, changed scores — is visible rather than reconstructed, and each row can point at the evidence for the control it relies on.

The security assessment is one of several the same organisation has to keep current, and they are usually written by different people who never compare them. A fire risk assessment covers the physical premises those systems sit in, and an information asset register underpins both — you cannot assess the risk to something nobody has listed.