ISO 27001 risk assessment and treatment under clause 6.1
By Sam Rivera, Founder, SentinelPanda · April 7, 2026 · 3 min read · ISO 27001
A good ISMS is a chain of decisions: identify risks, evaluate them, treat them, and document the result. Clause 6.1 is where that chain is built, and where most certification findings start.
What clause 6.1 actually requires
- A defined risk assessment process that produces consistent, valid, and comparable results.
- Identified information security risks — what could go wrong, to which information assets, and under what conditions.
- Analysed and evaluated risks against documented acceptance criteria.
- A risk treatment plan that selects options (modify, share, retain, avoid) for each risk above the acceptance threshold.
- A Statement of Applicability that, for every Annex A control, records whether it applies, why, and its implementation status.
- Documented residual risks accepted by risk owners with appropriate authority.
Choose a methodology that survives scrutiny
The standard does not mandate a specific methodology. The most common choices are: a qualitative likelihood-by-impact matrix (3x3 or 5x5), a semi-quantitative model with weighted factors, or a fully quantitative approach using historical loss data. For a first certification, qualitative is almost always the right call — it is auditable, repeatable, and produces decisions quickly.
What matters is that the methodology is written down, applied consistently, and produces decisions that the risk owner can defend. Auditors look for method, run history, and decisions — not for sophistication.
Identifying risks
Risk identification starts from assets (the information, systems, and processes you depend on) and threats (what could compromise them), and arrives at scenarios — concrete pairings of asset, threat, and consequence. "Customer database is exfiltrated through compromised admin credentials" is a scenario. "Cyber attack" is not.
Run the workshop with people who actually operate the systems. Risk registers built only from a security team backroom miss the operational risks that the engineers, support staff, and finance team see every day.
Evaluation against acceptance criteria
For every identified risk, score it against the chosen scale and compare to the written acceptance criteria. Risks below the threshold are formally accepted by the risk owner. Risks above the threshold enter the treatment plan with one of four options: modify (apply controls to reduce it), share (transfer through insurance or contract), retain (accept with risk owner sign-off), or avoid (stop the activity that creates it).
Most ISMS programs over-rely on the modify option. There are risks that should be avoided (sunset the legacy product) or shared (cyber insurance, customer-side controls) — making that choice explicit is part of the discipline of clause 6.1.
Treatment plan → SoA
Each control selected to treat a risk shows up on the Statement of Applicability. That is the connection between clause 6.1 and Annex A: the SoA is not a checklist, it is the output of the risk treatment plan. Controls marked applicable need a written justification ("treats risk R-014") and an implementation status; controls marked not applicable need an explanation that an auditor can read without context.
A common failure is an SoA that does not trace cleanly back to risks — every control is applicable "because the standard says so." That is the wrong answer; the right answer is "because it treats risk X to asset Y."
Where programs drift
- Risk register written once and never re-run, despite the methodology saying "annually or on significant change."
- Risk owners that are not senior enough to actually accept risk.
- Treatment plan with no due dates and no owner.
- SoA that does not match the controls implemented in reality.
- Acceptance criteria that are missing or so loose every risk falls below them.