Information security risk assessment
Plain-language summary
Defining one repeatable method for finding, analysing and ranking information security risks — with written criteria for what is acceptable and how assessments are done — and applying it so that two people assessing the same risk get comparable results.
What the clause is really asking
This is the engine of the standard, and the most common source of Stage 1 findings. The clause requires a defined process with written risk criteria: the risk acceptance criteria (what level of risk the organisation will live with) and the criteria for performing assessments (scales for likelihood and consequence, how they combine, when the assessment is repeated). The process must produce consistent, valid and comparable results every time it is run — the test of a method, not a brainstorm. It must find the risks of information inside the scope losing its confidentiality, integrity or availability, and name a risk owner for each; weigh the possible consequences and the realistic likelihood to arrive at a level of risk; and then compare those levels with the criteria and rank the risks for treatment. The 2022 edition does not require an asset-threat-vulnerability method — scenario or event-based approaches are equally acceptable — but whichever you choose must be written down and followed. Documented information about the process must be retained. POPIA s19 asks the same question in legal language: identify all reasonably foreseeable internal and external risks to personal information.
What auditors look for
Auditors start with the method, not the register: show me the criteria, the scales, the acceptance threshold and who approved them. Then they test repeatability by picking two risks and asking how the scores were arrived at — if the answer is 'judgement', the method is not working. They check every risk has a named owner who knows they own it, that risks cover confidentiality, integrity and availability and not only cyber-attack, that the register reflects the actual scope (the cloud service and the payroll bureau should appear), and that the assessment was repeated at planned intervals and after significant change. A register copied from a template, with the same risks every organisation has, is spotted in minutes.
Typical evidence
Documented risk assessment methodology with acceptance criteria and assessment criteria; the risk register showing identification, analysis (likelihood, consequence, level) and evaluation for each risk; a named owner per risk; dated evidence of repeat assessments; approval of the criteria by management; links from risks to the context, assets and requirements that gave rise to them.
How to comply — recommendations
Write a two-page method first: a 1–5 likelihood scale with worded anchors, a 1–5 consequence scale covering confidentiality, integrity and availability impacts (financial, legal, operational, reputational), a 5×5 matrix, and the acceptance threshold — say, anything 10 and above must be treated. Choose asset-based or scenario-based and stick to it. Run the first assessment as workshops with the process owners, not as an IT desk exercise, and capture the reasoning behind each score so it can be repeated. Name the owner as you log each risk. Set the review cadence (annually and on significant change) in the method and diarise it. The Risk Assessment and SoA Toolkit on the Templates page builds exactly this.
Common nonconformities
No documented risk methodology, or criteria that do not include risk acceptance; scores that cannot be explained or reproduced; risks without owners; register limited to technical threats and ignoring integrity and availability, people, suppliers and physical risks; register not covering the full scope; assessment never repeated or not repeated after major change; template risks with no connection to the organisation.
Related clauses
ISO 27001 6.1.1, 6.1.3, 8.2 (performing the assessment), 5.3 (risk owners), 9.3.2 (results as review input); Annex A 5.7 (threat intelligence), 5.9 (asset inventory feeds the assessment); ISO/IEC 27005 (guidance on information security risk management); ISO 9001 6.1; POPIA s19(2)(a) (identify reasonably foreseeable risks).
Resources for this clause
- ArticleISO/IEC 27001:2022 explained for people who already run ISO 9001: what is the same, what is new, and how to get certified
- ArticleThe Statement of Applicability, explained — what ISO/IEC 27001 clause 6.1.3 requires, the four ways an SoA fails Stage 1, and how to build one from the risk register
- Toolkit · $39Risk & SoA ToolkitScore your information security risks on a documented method, pick the Annex A controls that treat them, and the Statement of Applicability writes its own first draft — every justification citing the risks behind it.
- Free downloadISO 27001 Gap Analysis ChecklistWhere you stand against ISO/IEC 27001:2022 in one afternoon — the 30 management-system requirements and all 93 Annex A controls, scored, with owners, dates and a readiness figure that calculates itself.
- Free masterclass · ~27 minISO 27001 MasterclassYou already know four fifths of ISO 27001. Here is the other fifth — the risk method, the SoA, the 93 controls, the evidence rhythm, POPIA, and a 44-week path.
- Free appAudit ManagerPlan the programme, anchor each finding to its clause and drive the NC to closure.
Get the free ISO 27001:2022 Gap Analysis Checklist
Free, instant download. We'll only email you the occasional practical quality update — no spam, unsubscribe anytime.
Qlause provides interpretive guidance only and is not a substitute for the standard. Refer to your licensed copy of the relevant standard for the authoritative text.