Direct definition
What is an ISO 27001 risk register?
A risk register is a practical record of information security risk assessment and treatment results. It turns scenarios into consistent decisions by recording what could happen, what is affected, the evaluation against defined criteria, the chosen treatment, ownership, linked controls and the risk that remains.
Describe
Asset · event · consequence
Assess
Criteria · likelihood · impact
Treat
Decision · actions · controls
Own
Residual risk · approval · review
Purpose: support prioritisation and accountable treatment over time. ISO/IEC 27001 requires documented risk assessment and treatment results, but it does not prescribe a file named “risk register”, these columns or a five-by-five matrix.
Example method · not an ISO formula
Read the scores only after reading the criteria
The downloadable example multiplies likelihood from 1–5 by impact from 1–5. Scores 1–4 are Low, 5–9 are Medium and 10–25 are High. That makes the example internally readable; it does not make the model suitable for your organisation.
| Likelihood ↓ Impact → | Impact 1 | Impact 2 | Impact 3 | Impact 4 | Impact 5 |
|---|---|---|---|---|---|
| Likelihood 1 | 1Low | 2Low | 3Low | 4Low | 5Medium |
| Likelihood 2 | 2Low | 4Low | 6Medium | 8Medium | 10High |
| Likelihood 3 | 3Low | 6Medium | 9Medium | 12High | 15High |
| Likelihood 4 | 4Low | 8Medium | 12High | 16High | 20High |
| Likelihood 5 | 5Medium | 10High | 15High | 20High | 25High |
Rows run from likelihood 1 at the top to likelihood 5 at the bottom; columns run from impact 1 to 5. Before adopting a matrix, define the evidence and time horizon represented by each value and check whether multiplication produces decisions that match your risk appetite.
Visual preview · fictional worked example
See how treatment changes the risk view
Paperbark Payroll is a fictional 100-person Australian B2B SaaS provider using Microsoft 365 and Azure. The full file contains 18 worked scenarios plus blank rows. The ratings, controls, roles and business assumptions are examples, not observations about a real organisation.
Phishing compromises a staff account that can access customer data.
Example treatment: Phishing-resistant MFA, Conditional Access and targeted awareness exercises.
Fictional risk owner: Security Lead
Inherent
High16Residual
Medium6An Azure regional outage interrupts the service beyond the fictional four-hour recovery target.
Example treatment: Two-region recovery design, quarterly failover tests and owned recovery targets.
Fictional risk owner: CTO
Inherent
High10Residual
Low4A sub-processor breach affects customer data for which the organisation remains accountable.
Example treatment: Security schedules, evidence review and a contractual incident-notification requirement.
Fictional risk owner: Security Lead
Inherent
High12Residual
Medium8A departed employee retains access after their employment ends.
Example treatment: HR-triggered deprovisioning, a defined completion target and periodic access reviews.
Fictional risk owner: IT Lead
Inherent
High12Residual
Low4An unauthorised person enters the fictional Melbourne office.
Example treatment: Logged swipe-card entry, escorted visitors and clear-desk expectations.
Fictional risk owner: Office Manager
Inherent
Low4Residual
Low2Five rows are previewed here. The downloadable register contains all 18 worked scenarios, treatment decisions, owners and linked Annex A controls. A lower score is an assessment claim that needs evidence; the arithmetic alone does not prove a treatment works.
Decision trace
Follow one risk from scenario to review
01
Scenario
Event and consequence
02
Criteria
Evidence and scales
03
Evaluation
Priority against threshold
04
Treatment
Decision, action and control
05
Residual
Remaining risk and approval
06
Review
Change, incident and cadence
The register should also connect to the Statement of Applicability. A treatment can select one or more controls; the SoA explains why those controls are necessary, whether they are implemented and where their operating evidence is governed.
Adaptation instructions
Build your register from your method, not this data
- Start with the ISMS scope and the information, services, people, technologies, suppliers and locations on which its objectives depend.
- Define the assessment method before scoring anything: risk criteria, likelihood and consequence scales, rating bands, acceptance thresholds and who can approve residual risk.
- Write scenario-based risks. State what could happen, how it could happen, what is affected and the plausible consequence to an information security objective.
- Assess each risk consistently using current evidence. If you use inherent and residual scores, define exactly which controls each view includes.
- Choose a treatment, assign an accountable risk owner and identify action owners, due dates, resources and the controls intended to change the risk.
- Reassess the residual risk after treatment and obtain the required owner approval for the treatment plan and acceptance of remaining risk.
- Connect selected controls to the Statement of Applicability, then review risks after material change, incidents, control failures and on the planned ISMS cadence.
Common mistakes
Where a register becomes scoring theatre
Writing “cyber attack — high”
A label does not explain the asset, event, vulnerability or consequence. Write a scenario that another person can assess and challenge.
Using undefined one-to-five scales
Define what every likelihood and impact value means. Otherwise identical evidence can produce different scores depending on who attends the workshop.
Treating this five-by-five matrix as an ISO rule
It is the fictional example’s chosen method. ISO 27001 requires a consistent process and criteria but does not prescribe this formula or these rating bands.
Scoring residual risk before treatment operates
Planned controls are not operating evidence. Keep the current residual position distinct from a target residual score expected after actions are complete.
Assigning every risk to the security team
The owner needs authority over the affected objective and treatment decision. Technology, HR, legal, product and executive owners may each own risks.
Assuming residual risk becomes zero
Controls usually change likelihood or consequence; they rarely remove all uncertainty. Record and approve what remains against defined acceptance criteria.
Leaving the register frozen for the audit
Risk assessment must respond to planned intervals and significant change. A polished file with stale inputs is not a functioning risk process.
Breaking the link to the SoA
Treatments should trace to selected controls, and the Statement of Applicability should explain why those controls are necessary for the defined scope.
Version, author and review status
- Resource version
- 1.0
- Published
- 2 September 2026
- Author
- Aegentra Academy
- Standards basis
- ISO/IEC 27001:2022, Amendment 1:2024 and ISO/IEC 27005:2022
- Substantive reviewer
- Harry Sidhu · Director and Principal Consultant, Aegentra
- Substantive review date
- 2 September 2026
Substantively reviewed for source accuracy, risk-treatment logic, limitations and download parity. Source links were checked when this version was prepared; standards status and source availability can change.
Limitations and use boundary
- This is Aegentra-authored educational material, not official PECB course material and not a reproduction of ISO/IEC 27001, ISO/IEC 27005 or ISO 31000.
- The worked organisation, assets, risks, controls, scores, owners and treatment claims are fictional. They are not evidence about Aegentra or any client.
- The scoring model is illustrative. ISO/IEC 27001 does not prescribe this matrix, these rating bands or a universal definition of inherent risk.
- The example does not replace organisation-specific threat context, legal advice, risk-owner approval, internal audit or certification-body assessment.
- A register is only one record in a risk process. Completing rows does not prove that treatments operate, residual risks are accepted or the ISMS conforms.
Sources and learning pathways
The explanations above are plain-English paraphrases. Use the published standards for authoritative requirements and terminology, and define a method that fits your organisation's decision context.
- [1]ISO/IEC 27001:2022 — Information security management systems — Requirements
Official ISO edition page for the requirements standard that governs the ISMS risk process and retained results.
- [2]ISO/IEC 27001:2022/Amd 1:2024 — Climate action changes
Official amendment page for the current climate-action additions to organisational context.
- [3]ISO/IEC 27005:2022 — Guidance on managing information security risks
Official ISO page for information security risk management guidance that supports ISO/IEC 27001.
- [4]ISO 31000 — Risk management
Official ISO overview of risk principles, framework and process. ISO 31000 is guidance, not an organisational certification standard.
FAQs
ISO/IEC 27001 requires a defined information security risk assessment and treatment process and retained documented information about their results. It does not prescribe a file called a “risk register” or a fixed set of columns. A register is a practical way to keep the required decisions traceable and current.
No. The five-by-five likelihood and impact method on this page belongs to the fictional example. Your organisation must define criteria that produce consistent, valid and comparable results and align with its decision-making needs.
No. Use the structure as a prompt, then assess scenarios using your own scope, assets, threat context, existing controls, evidence, consequence thresholds and risk acceptance authority. A copied score is not an assessment result.