ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
An ISO 27001 risk register is the working record of your information security risks, their scores, owners and treatment decisions, and it is the first document most auditors ask to see. The standard never uses the phrase, but it requires documented results of risk assessment and treatment, and a register is the practical way to hold them.
This guide sets out the fields to include, how to keep the register consistent with your risk assessment methodology, and how to link it to treatment, residual risk and review. For the enterprise-wide equivalent, see our note on the enterprise risk register.
Free gap assessment
Where do you actually stand against ISO 27001?
Score every management system clause and all 93 Annex A controls, free, and get a prioritised gap list back.
Run the free ISO 27001 gap assessment → or View premium report sample
Clause 6.1.2 requires you to retain documented information about the risk assessment process, and clause 8.2 requires you to retain the results. Clause 6.1.3 adds the risk treatment plan and owner acceptance of residual risk. A register brings all of that into one place and makes it searchable.
Free ISO 27001 risk assessment
Which of your risks sit above your appetite line?
Set your own risk criteria, pick from 61 information security risk scenarios, rate likelihood and impact, and decide how to treat each one. You get a heat map, a process score and the findings an auditor would raise, free.
Run the free risk assessment → or View premium report sample
You can confirm the exact wording in your licensed copy of the standard, listed at ISO/IEC 27001:2022 on iso.org.
Keep the layout simple enough that owners will read it. At minimum, record a unique ID, the asset or process, the threat, the vulnerability, the impact on confidentiality, integrity and availability, the inherent score, the treatment option, the controls, the residual score, the owner and the review date.
The table below shows a compact layout. Add columns only when someone will use the information; every extra field is another thing to keep current.
The register can list assets with their threats or it can list scenarios. Both satisfy the 2022 edition of the standard, which no longer requires an asset-based method. Our guides on asset-based assessment and scenario-based assessment compare them.
Pick one and apply it consistently. Mixed styles in a single register make scores hard to compare.
| Field | Purpose | Example |
|---|---|---|
| Risk ID | Unique reference | IS-014 |
| Asset or process | What is exposed | Customer database |
| Threat and vulnerability | How harm could occur | Credential theft, weak MFA coverage |
| Inherent score | Before controls | 20 |
| Treatment and controls | Chosen response | Modify: enforce MFA, monitoring |
| Residual score | After controls | 8 |
| Owner and dates | Accountability | Head of IT, reviewed March |
Calibrate scoring with a short workshop where assessors score the same three sample risks independently and compare results. Large differences show where definitions need tightening.
Use the scales in your criteria without exception. If likelihood is rated one to five in the methodology, it must be one to five in the register. Provide short definitions for each level so two assessors would land on the same number.
The guide to risk criteria explains how to write those scales and tie them to appetite.
Each risk above threshold needs a treatment decision: modify, avoid, share or retain. Record the choice, the controls, the action owner and the due date. Then link the row to the risk treatment plan and to the relevant Annex A controls in the Statement of Applicability.
This traceability is what auditors test when they follow a risk from identification to control.
The register should point outward. Each row can reference the asset inventory entry, the relevant Annex A controls, incident tickets, supplier records and audit findings. These links let you answer questions quickly, such as which risks are affected when a supplier fails or which controls protect a given asset. They also help when you update the Statement of Applicability, because you can see which risks depend on each control. A short reference column is often enough, so long as identifiers are stable.
Add residual likelihood, impact and score, plus the approver and date. Owners must approve residual risk under clause 6.1.3, so a register without approvals is incomplete. See the guide to residual risk for scoring after treatment and the note on risk acceptance for approvals.
New owners need a brief walkthrough: how scores are set, what they are expected to confirm, and when reviews happen. A one-page guide and a fifteen-minute session are usually enough, and they prevent the common problem of owners approving rows they have not read.
Every row needs a named individual with the authority to decide, not a team alias. Owners confirm scores, approve treatment and answer auditor questions. The guide to the risk owner role covers responsibilities in more detail.
Run a short internal check a month before certification or surveillance audits. Pick five risks at random and trace each from description to score, treatment, control evidence, residual score and owner approval. Check that dates are current, that scales match the methodology and that no row is missing an owner. Fix gaps and note what changed. Doing this yourself turns the audit sample from a surprise into a routine confirmation, and it reveals whether the register is genuinely used or merely maintained for show.
Also confirm that the register agrees with the treatment plan and the Statement of Applicability; mismatches between those three documents are among the most common findings.
A register is only useful while it reflects current conditions. Set a review cycle, add triggers for incidents and major changes, and keep a version history. The article on the risk review shows how to plan this.
Show the last-reviewed date on the register itself so anyone can see how fresh it is.
A few habits improve usability.
A good description names the cause, the event and the consequence in one sentence. Compare “phishing” with “a finance employee is tricked into disclosing credentials, allowing fraudulent payment instructions and loss of payment data”. The second version tells the owner what to prevent, lets assessors score likelihood and impact sensibly, and points to relevant controls such as multi-factor authentication and payment verification. Aim for one scenario per row. When a row bundles several causes, split it, because a combined score hides which control matters most.
Keep language plain. Owners outside security should understand the row without a glossary.
Registers fail in predictable ways: vague risk descriptions such as “data breach”, scores that never change, missing owners, treatment actions without dates, and copied example risks that do not match the business. Write each risk as a specific cause and consequence, for example loss of customer records through compromised administrator credentials.
Treat the register as controlled documented information under clause 7.5 of the standard. Store it in one location, restrict edit rights to the security team and named owners, and record who changed what and when. Keep dated snapshots at each review so you can show how scores moved. Avoid emailing copies that drift out of date, because two versions of the register invite disagreement in front of an auditor. If you use a spreadsheet, protect formulas and lock the scale definitions so nobody edits them by accident.
Management review needs summaries, not rows. Report the number of risks by rating, the top risks, overdue actions and exceptions. A risk heat map drawn from the register communicates positions quickly.
Small teams can run a register in a spreadsheet for years. As the number of risks, owners and linked records grows, consider a governance tool with workflow, reminders and audit trails. Whatever platform you pick, migrate the structure first, keep the ID scheme and preserve history so trends remain visible. Do not migrate poor data unchanged; use the move as a chance to remove duplicates and rewrite vague descriptions.
If you would rather not build the register from scratch, the ISO 27001 Risk Assessment Report and Workbook provides a structured report and workbook with scoring, treatment mapping and approval fields. Whichever route you take, keep one master register and one version of the truth.
The standard requires documented results of risk assessment and treatment. A register is the usual way to meet that, though it is not named in the text.
Yes. A well-controlled spreadsheet with version history and restricted editing satisfies many organizations, and dedicated tools become useful as volume grows.
Enough to cover your scope with specific, meaningful scenarios. Quality matters more than volume, and dozens to a few hundred is typical.
The information security lead usually maintains it, while owners confirm their own rows.
They trace a few risks from assessment through treatment, control operation and approval, and check dates and owners.
September 30, 2026
