---
title: "ISO 27001 Risk Assessment: Method & Register Guide"
description: "How to run an ISO 27001 risk assessment: choose a methodology, assess with risk owners, decide treatments, and build the register auditors actually test."
canonical: https://www.isosecurity.co.uk/resources/iso-27001-risk-assessment
updated: 2026-11-10
---

# ISO 27001 risk assessment, done the way auditors test it

Your risk assessment decides almost everything else in the ISMS: which controls you operate, what your Statement of Applicability says, and where you spend money. Auditors know this, and test whether your methodology is documented, applied consistently, and owned by people who understand the scores.

## What is an ISO 27001 risk assessment?

Document a simple methodology (assets, threats, likelihood, impact, acceptance criteria), assess risks with the people who own them, and record treatment decisions and owners in a register and treatment plan. Let your controls and [Statement of Applicability](/resources/statement-of-applicability) flow from those decisions.

Review it when things change and at least annually. That is the whole requirement, and complexity rarely helps.

## Step 1: How do you agree the methodology?

- **What you are assessing:** information assets, services and processes within scope, and the threats to their confidentiality, integrity and availability.
- **Scales:** defined likelihood and impact levels with plain-language descriptions your managers can apply consistently.
- **Acceptance criteria:** the level of risk the organisation will accept, who may accept it, and what happens above that line.
- **Ownership:** every risk gets a named owner with authority over it.

Write this down before the first workshop. A methodology invented to fit results already produced is obvious to an auditor and undermines the register's credibility.

## Step 2: How do you assess risks with their owners?

Work through the in-scope services and systems with the people responsible for them. For each significant risk, record the asset or process, the threat scenario in plain language, existing controls, likelihood, impact, the resulting level of risk, and the owner.

Disagreement in the room is useful, because it surfaces the assumptions the scoring rests on. Keep the register readable by a new manager: if it needs the author in the room to explain it, it is unfinished.

## Step 3: How do you decide treatment, risk by risk?

| Option           | Meaning                                          | Record                                                            |
| ---------------- | ------------------------------------------------ | ----------------------------------------------------------------- |
| Treat            | Apply controls to reduce likelihood or impact    | Chosen controls (these feed the SoA), owner, target date          |
| Accept           | Live with the risk within your criteria          | Named acceptor at the right level, review date                    |
| Transfer / share | Insurance, or contractual transfer to a supplier | What is covered, what remains with you (something always remains) |
| Avoid            | Stop or change the activity creating the risk    | The decision and who made it                                      |

The treatment plan is the bridge between the register and the work: each treated risk becomes actions, controls and dates. If a treatment has no owner or date, it is a wish, and auditors treat it as such.

## What do auditors test, and where do assessments fail?

- **The methodology is not followed as written.** Scores that contradict the documented scales are the classic finding.
- **Owners who cannot explain their risks.** Interviews expose registers written on their behalf.
- **Risk acceptance above authority.** Significant risks quietly accepted at the wrong level.
- **No link to the SoA or treatment plan.** Controls with no risk behind them, risks with no controls in front of them.
- **A register frozen at implementation.** No review after change or incident; see my guide to [maintaining certification](/resources/how-to-maintain-iso-27001-certification).

## Frequently asked questions about ISO 27001 risk assessment

### What is an ISO 27001 risk assessment?

It is the process the standard uses to drive every other decision: identify information assets and the risks to their confidentiality, integrity and availability, score them against documented criteria, and decide with risk owners whether to treat, accept, transfer or avoid each risk. Record the outcome in a risk register and treatment plan, and let your controls and your Statement of Applicability flow from it.

### What methodology should we use for ISO 27001 risk assessment?

The standard does not prescribe one, so choose a documented methodology that produces consistent, comparable, repeatable results: defined likelihood and impact scales, risk acceptance criteria, and named risk owners. A simple likelihood-by-impact matrix, applied honestly every time, will pass an audit.

### Who should be involved in the risk assessment?

The people who own and understand the work: system and process owners, plus someone with authority to accept residual risk at the appropriate level. Registers written by a consultant in isolation fall apart in one interview, because the owners cannot explain the scores attributed to them.

### How often should the risk assessment be reviewed?

At planned intervals, typically at least annually, and whenever something material changes: a new system, supplier, service, site or a significant incident. Leave dated evidence of what changed, what was rescored and what treatment was agreed.

## Contact

Risk register not convincing you, let alone an auditor? Arrange a readiness discussion: [contact ISO Security](/contact) or email info@isosecurity.co.uk.