Everyone implementing ISO 27001 stalls at the same place: clauses 6.1.2 and 6.1.3 require a risk assessment and risk treatment process, with defined criteria and repeatable results — and say nothing about how to build one. That is what ISO/IEC 27005 is for.
The split is deliberate. ISO 27001 is a requirements standard: it says what must exist for certification. ISO 27005 is guidance: it describes one workable path to meeting that requirement. You cannot be certified against 27005, and no auditor will demand that your method match it exactly. What the auditor will demand is that a method exists, is documented, is applied, and produces the same answer when repeated.
What 27001 actually asks for
Before looking at 27005, separate what is mandatory from what is your choice:
- Criteria defined up front. Risk acceptance criteria and criteria for performing assessments must be written before you assess the first risk. Setting the criterion after seeing the result is picking the target after the shot.
- Consistent, comparable results. Two people applying the same method to the same facts should land close together. If the answer changes with whoever fills in the sheet, that is not a method — it is formatted opinion.
- Every risk has an owner. Each identified risk needs someone accountable, and that person must have the authority to accept it. An analyst does not accept business risk.
- Traceability to Annex A. The chosen treatment becomes a control, and the control appears in the Statement of Applicability. That is where risk assessment meets the Annex A checklist.
Notice what is not on that list: a 5×5 matrix, a 1-to-5 scale, a heat map. None of it is required by the standard. Those are market conventions that a lot of people mistake for requirements.
What changed in the 2022 edition
The 2022 revision was not cosmetic. The title became Information security, cybersecurity and privacy protection — Guidance on managing information security risks, reflecting a scope wider than information security in the narrow sense.
- Alignment with ISO 31000. The vocabulary was harmonised with the parent risk-management standard. Impact gave way to consequence — not a synonym swap, but alignment with the language the rest of the organisation already uses for financial and operational risk.
- Risk scenario. The standard introduced the scenario as a sequence or combination of events leading from the initial cause to the unwanted consequence, replacing the older incident scenario.
- Acceptance is no longer a phase. Accepting a risk became a decision taken after treatment, rather than a separate stage of the process.
Check the year on your copy. A good deal of the available summary material still describes the previous edition, and the two texts differ in terminology and in process structure. If your methodology was written from an old summary, it probably uses words the auditor will expect in a different form.
The two identification approaches
This is where 27005 earns its keep, and it is the part almost nobody reads before building the spreadsheet. The standard describes two ways to identify risk, and they need very different inputs.
| Event-based | Asset-based | |
|---|---|---|
| Starting point | What can go wrong for the business | What we have and how it can be attacked |
| Depth | High-level assessment | In-depth assessment |
| Requires | Understanding of the business and its stakeholders | A reliable inventory of assets, threats and vulnerabilities |
| Good for | Starting, prioritising, talking to the board | Detailing what has already been prioritised |
| Fails when | It becomes a list of generic fears with no owner | The inventory is incomplete or out of date |
The event-based approach starts from the consequence: revenue interrupted, a customer database exposed, a regulated service unavailable. It produces few risks, all tied to something the business recognises. The asset-based approach starts from the inventory and works down to threat and vulnerability per asset. It produces far more rows and far more detail.
Which one to use
They are not competitors, they are a sequence. The most common mistake in a first implementation is to start asset-based because it looks more technical and more complete — and to stall three months later with an eight-hundred-row spreadsheet nobody reviews, already out of date on the day it was finished.
The order that works is the reverse: start from events, get to a short list of scenarios the leadership recognises as relevant, and only then descend to asset level for the scenarios that survived prioritisation. Detail is expensive; spend it where it changes a decision.
There is a hidden prerequisite in this. The asset-based approach only works on a reliable inventory. If the organisation does not know which systems exist, who owns each one and what information each one handles, an in-depth assessment will measure a universe that does not match reality — and precision on top of bad data is the worst of both worlds, because it looks like rigour.
What the auditor will ask for
In the end, the risk assessment has to leave four pieces of evidence behind. None of them is the spreadsheet itself:
- The methodology document, with assessment and acceptance criteria defined before the first round.
- The assessment results, with risks identified, analysed and prioritised against those criteria.
- The treatment plan, with a chosen control, an owner and a deadline for every risk treated.
- The formal acceptance of residual risks, signed by someone with the authority to accept them.
An organisation with those four documents consistent with one another passes the audit on a simple methodology. An organisation with a sophisticated spreadsheet and no formal acceptance does not.
Source consulted: ISO/IEC 27005:2022, Information security, cybersecurity and privacy protection — Guidance on managing information security risks. This article is informational; consult the official text of the standard before defining your methodology.