ISO 27001 practical guide
ISO 27001 Risk Assessment Example
An ISO 27001 risk assessment should apply repeatable criteria to realistic scenarios, assign accountable owners and produce results suitable for treatment decisions. The method may use qualitative or quantitative scales, but it must generate consistent, comparable and reviewable outcomes.
- Search intent
- Translate an information-security scenario into a consistent assessed risk record.
- Guide area
- Risk
- Review status
- Practitioner reviewed
What this means in practice
Risk records should describe a plausible cause-and-impact pathway. A label such as “cyberattack—high” is too vague to support treatment or testing.
Inherent and residual risk concepts can be useful where defined consistently, but terminology alone does not improve the assessment. Explain which controls are assumed at each stage and how residual conclusions are supported.
Step-by-step implementation
- Step 1. Define scope, risk identification method, likelihood and consequence criteria.
- Step 2. Set evaluation and acceptance thresholds before scoring individual scenarios.
- Step 3. Identify relevant assets, processes, threats, weaknesses and business consequences.
- Step 4. Describe existing controls and assess their actual condition.
- Step 5. Assign likelihood and consequence using available evidence and defined criteria.
- Step 6. Name the risk owner and compare the result with acceptance criteria.
- Step 7. Select treatment, avoidance, sharing or informed retention and define reassessment triggers.
What to prepare
- approved risk methodology and criteria
- asset, service and dependency context
- incident, vulnerability, audit and threat information
- existing-control evidence
- risk owners and acceptance authority
Documents, records and evidence
| Area or field | Example | Why it matters |
|---|---|---|
| Scenario | Compromised administrator account enables unauthorized production access | Specific event and consequence |
| Asset/process | Production cloud platform and customer service | Business context |
| Threat and weakness | Credential theft; weak privileged-session controls | Cause pathway |
| Existing controls | MFA, restricted admin roles and centralized logging | Current controls, not planned controls |
| Assessment | Possible likelihood; major confidentiality and availability impact | Defined criteria applied |
| Decision | Reduce through PAM workflow and stronger alerting; platform owner accountable | Treatment and ownership |
Residual-risk decision
After stronger authentication and privileged-session monitoring are implemented, the owner reassesses likelihood using access-review and alert-testing evidence. Residual risk is approved only if it falls within defined acceptance criteria; otherwise additional action remains in the treatment plan.
What an auditor will look for
- A documented method used consistently across the ISMS scope.
- Criteria defined before and applied to the sampled risks.
- Owners who understand scenarios, treatment and residual decisions.
- Reassessment after material change, incidents or weak control performance.
An auditor may select different samples or follow unexpected evidence. Prepare authoritative records and owners who can explain normal operation, exceptions and improvement rather than rehearsed answers.
Common mistakes
- Scoring assets without describing risk scenarios.
- Changing criteria to make results appear acceptable.
- Assuming planned controls already reduce current risk.
- Assigning every risk to the security manager regardless of business ownership.
Practical checklist
- □ Risk criteria and acceptance thresholds are approved.
- □ Scenarios describe cause, event and business impact.
- □ Existing controls are supported by current evidence.
- □ Likelihood and consequence follow defined scales.
- □ Every risk has an accountable owner and decision.
- □ Treatment and residual-risk conclusions are traceable.
Frequently asked questions
Does ISO 27001 require a 5x5 matrix?
No. Choose a method that produces consistent, comparable and useful results for your context.
Must we calculate inherent risk?
Not necessarily. If used, define it and explain which controls are excluded from the assessment.
How often should risks be reassessed?
Set planned reviews and event-driven triggers based on change, incidents, performance and context.
Continue through the practical guide library
Use the topic hub to connect this task with related implementation, risk, governance, evidence and audit-preparation guidance.