ISO 27001 · 12 min read · Updated 2026-07-06
ISO 27001 risk assessment: make decisions reviewable
A practical ISO 27001 risk assessment guide covering criteria, owners, likelihood, impact, treatment and residual risk.
Direct answer
An ISO 27001 risk assessment makes security decisions reviewable. It defines risk criteria, identifies assets and scenarios, scores likelihood and impact, assigns risk owners, chooses treatment options, links risks to controls and records residual risk after treatment.
For SaaS teams, the risk register needs to be readable by leadership and useful to engineering. It should explain the decision, not just produce a score. General information only; this is not legal advice.
What ISO 27001 risk assessment is
- A structured way to decide which information security risks matter.
- A basis for risk treatment and control selection.
- A record that should be reviewed when scope, vendors or systems change.
Define risk criteria
- Agree likelihood and impact levels.
- Define what makes risk acceptable.
- Decide who can accept residual risk.
- Keep criteria stable enough for comparison.
Identify assets, threats and vulnerabilities
- Start with critical systems, data stores and suppliers.
- Write risk scenarios in plain English.
- Avoid vague labels that do not describe impact.
Score likelihood and impact
- Use the agreed criteria.
- Record rationale for high or accepted risks.
- Review scores after incidents or control changes.
Assign risk owners
- Use someone accountable for the system or process.
- Do not assign all risks to security by default.
- Record review responsibilities.
Choose treatment options
- Reduce through controls or remediation.
- Accept with approval and rationale.
- Transfer through contract or insurance where appropriate.
- Avoid by stopping the activity.
Link risks to controls
- Connect treatment to policies, access reviews, vendor reviews or technical controls.
- Track remediation tasks and due dates.
- Keep evidence beside the risk.
Record residual risk
- Score after treatment.
- Record who accepted residual risk.
- Review accepted risks during management review.
Approve and review risks
- Review high risks at least quarterly.
- Review accepted risks before audit or management review.
- Update risks when new products, vendors or incidents occur.
Risk register example
| Area | What to check | Evidence to keep | Owner | Review frequency | Status |
|---|---|---|---|---|---|
| Criteria | Likelihood and impact definitions exist | Risk methodology | ISMS owner | Annually | Not started |
| Scenario | Risk is written clearly | Risk register row | Risk owner | Quarterly | Not started |
| Treatment | Decision is recorded | Treatment note, task | Risk owner | Quarterly | Not started |
| Control | Control evidence supports treatment | Control evidence link | Control owner | Quarterly | Not started |
| Residual | Residual risk is approved | Approval note | Approver | Quarterly | Not started |
| Review | Changes are tracked | Review history | ISMS owner | Quarterly | Not started |
Common mistakes
- Using one-word risks.
- Scoring without criteria.
- Assigning every risk to security.
- Not linking treatment to evidence.
- Forgetting residual risk approval.
How Trustega makes risk decisions reviewable
Trustega connects risk records to owners, treatment tasks, controls and evidence so decisions can be reviewed by leadership, auditors or customers without reconstructing the story from spreadsheets.
Common questions
Is this guide legal or certification advice?
No. This guide is for general information and is not legal advice. Use qualified legal, privacy or audit advisers for formal interpretation and assurance decisions.
Can a small SaaS team use this without a GRC team?
Yes. The workflows are designed for lean teams, but each record still needs a named owner, a review date and evidence that matches the actual scope.