This page gives you a copyable ISO 27001 risk register template, worked example rows, and the method you need to keep it audit ready. The structure aligns with the documentation expectations in ISO/IEC 27001 and the risk guidance in ISO/IEC 27005. Copy the fields below into a spreadsheet, populate them using the worked examples as a pattern, then follow the method page steps to score, treat, and sign off your own risks.
TL;DR:
- The risk register should distinguish between risk owners who accept or escalate risks and action owners responsible for implementing treatments.
- Scenarios must be specific cause-event-consequence statements linked to the CIA properties, not vague threats like just “phishing.”
- Scores for likelihood and impact should be based on defined scales with clear evidence, avoiding arbitrary or inconsistent assessments across teams.
- The mapping of risks to controls in Annex A and documenting evidence are essential to pass audits and justify the treatment decisions.
- Regular review, documented sign-offs, and proper evidence storage are critical for maintaining audit readiness and demonstrating proper risk management over time.
Table of Contents
- What an ISO 27001 risk register must record
- Template and worked example rows you can copy into Excel or Google Sheets
- How to build and maintain your register: the method page steps
- Scoring matrix, bands and acceptance line
- Mapping risks to Annex A and documenting the Statement of Applicability
- Audit readiness: maintaining, reviewing and evidencing the register
- Implementer perspective: where templates commonly fail and how to fix them
- How ISMS Calculator helps you move faster
- Sources
- FAQ
What an ISO 27001 risk register must record
A risk register exists to satisfy two clauses at once. Clause 6.1.2 asks you to identify risks to confidentiality, integrity, and availability and to assess their likelihood and impact. Clause 6.1.3 asks you to select treatments and record why you chose them. ISO/IEC 27001 requires documented information showing the results of both activities, which means a spreadsheet with vague notes will not survive an audit conversation.
Each risk scenario should read as a single sentence built from three parts: a cause, an event, and a consequence. “A phishing email tricks an employee into entering credentials, giving an attacker access to the email system” is a scenario. “Phishing” alone is not, because it names a threat without describing what happens or what it affects. Tie each scenario to the CIA property it threatens so scoring stays grounded in something specific rather than a general sense of danger.
The fields below are the minimum a defensible register needs, drawn from the structure CloudSoul recommends for registers that survive audit review.
- Risk ID and scenario: a unique identifier and the cause-event-consequence sentence.
- CIA and asset: which property is threatened and which asset, system, or process is affected.
- Risk owner: the person accountable for the risk decision, distinct from whoever executes a fix.
- Existing controls, likelihood, impact, and risk score: what already reduces the risk and the resulting rating.
- Treatment, actions, action owner, and due date: the chosen response and who is doing the work.
- Residual risk, acceptance, status, and last reviewed date: the score after treatment and who signed off on living with it.
Keep the risk owner and action owner separate. A risk owner decides whether a risk is acceptable or needs more work. An action owner just executes a task, and conflating the two roles is one of the fastest ways to lose accountability when an auditor asks who approved a residual risk.
Template and worked example rows you can copy into Excel or Google Sheets
Set up your spreadsheet with the columns from the previous section, then populate rows using scenarios relevant to your organization. The five examples below cover risks that appear in nearly every ISMS, adjusted for likely inherent scores, treatments, and residual outcomes.
- Phishing leading to credential theft: cause-event-consequence: a phishing email tricks a staff member into entering credentials, letting an attacker access email. CIA: confidentiality. Existing controls: spam filtering, basic staff awareness. Inherent score: likelihood 4, impact 4, score 16 (high). Treatment: reduce, via mandatory phishing simulation training and multifactor authentication on email. Residual score: likelihood 2, impact 4, score 8 (medium). Acceptance: risk owner (IT manager) signs off on residual medium risk pending MFA rollout completion.
- Credential reuse across systems: cause-event-consequence: an employee reuses a personal password on a work system, and a breach of the personal service exposes the work credential. CIA: confidentiality. Existing controls: none formal. Inherent score: likelihood 3, impact 3, score 9 (medium). Treatment: reduce, via a password manager rollout and a no-reuse policy. Residual score: likelihood 2, impact 3, score 6 (medium). Acceptance: pending policy sign-off.
- Supplier data breach: cause-event-consequence: a third-party processor suffers a breach, exposing customer data the organization shared with it. CIA: confidentiality. Existing controls: a signed data processing agreement, no monitoring. Inherent score: likelihood 3, impact 5, score 15 (high). Treatment: reduce and transfer, via supplier security questionnaires, contractual breach notification clauses, and cyber insurance. Residual score: likelihood 2, impact 5, score 10 (high). Acceptance: escalated to executive sign-off given the residual score stays high.
- Cloud service outage: cause-event-consequence: a cloud infrastructure provider suffers an extended outage, halting access to production systems. CIA: availability. Existing controls: single-region deployment. Inherent score: likelihood 2, impact 4, score 8 (medium). Treatment: reduce, via multi-region failover and a documented business continuity plan. Residual score: likelihood 1, impact 4, score 4 (low). Acceptance: accepted by IT manager, reviewed at next annual cycle.
- Unpatched server vulnerability: cause-event-consequence: a known vulnerability in an unpatched server is exploited to gain unauthorized system access. CIA: confidentiality and integrity. Existing controls: quarterly patch cycle. Inherent score: likelihood 3, impact 4, score 12 (high). Treatment: reduce, via a monthly patch cadence and vulnerability scanning. Residual score: likelihood 1, impact 4, score 4 (low). Acceptance: accepted, evidenced by scan reports attached to the action.
The logic behind each score should be traceable, not guessed. Likelihood for the phishing row reflects how often simulated tests catch clicks before training; impact reflects how much of the email system a single compromised account can reach. When you adapt these rows, resist copying the numbers directly: a five-person company with no cloud dependency should score the outage risk differently than a company running customer-facing infrastructure across three regions. Adjust impact for your actual blast radius and likelihood for your actual control maturity, and document that reasoning on the method page so a reviewer can follow it a year later. For more detail on documenting treatment decisions and residual risk evidence, see this guide to ISO 27001 risk treatment.
How to build and maintain your register: the method page steps
A register without a method page is just a list of numbers nobody can defend. Write the method page once, before you score a single risk, and update it whenever your scales or scope change.
- Define scope and risk criteria. Decide what counts as an information security risk for your organization, set your risk appetite in plain language, and draw the acceptance line: the score above which a risk needs treatment rather than simple monitoring.
- Choose time horizons and evidence rules. State whether likelihood represents an annual probability, a per-release window, or another period, and specify what evidence justifies a given likelihood or impact rating rather than leaving it to individual judgment.
- Enumerate assets and write scenario sentences. List the assets, systems, and processes in scope, then write each risk as a cause-event-consequence sentence linked to a specific threat and vulnerability.
- Score inherent risk and select treatment. Rate likelihood and impact using your defined scales, calculate the inherent score, choose a treatment (reduce, transfer, avoid, or accept), and assign an action owner with a due date.
- Reassess residual risk and obtain sign-off. After treatment actions complete, rescore the risk, have the risk owner formally accept the residual level, then version the register and set a review date.
This guide to risk assessment methodology walks through scale definition and time horizon choices in more depth if step 2 feels underspecified. For structured training on setting appetite and acceptance thresholds, a risk management course can help teams new to formal risk frameworks build the vocabulary before they start scoring.
Scoring matrix, bands and acceptance line
A 5x5 likelihood by impact matrix keeps scoring consistent across assessors and gives auditors a transparent method to check your numbers against.
Public worked examples commonly band scores as 1 to 4 low, 5 to 9 medium, and 10 or higher high. Setting the acceptance line at the medium to high boundary, meaning anything scoring 10 or above requires active treatment, is a common and defensible starting point, though your own risk appetite may justify a different cutoff.
Three mistakes undermine matrix-based scoring most often. Assessors use different time horizons for likelihood without realizing it, one thinking in annual terms and another in per-project terms, which makes scores incomparable across the register. Inherent and residual scores get mixed in the same column instead of tracked separately, hiding whether treatment actually worked. And teams multiply numbers without ever writing down what evidence justifies a “3” versus a “4,” turning the whole exercise into arithmetic without grounding. A 5x5 risk matrix template with predefined evidence rules for each cell helps avoid the last problem.
Mapping risks to Annex A and documenting the Statement of Applicability
Annex A is not a checklist to work through top to bottom. It is a reference set of controls that your risk assessment should draw from, not a list every organization implements in full. The auditing practice note on SoA mapping makes clear that auditors expect necessary controls to come from your risk treatment decisions, then be mapped to Annex A identifiers, with any exclusion documented and justified.
The practical process runs in three steps: select the controls your treatment decisions actually require, map each one to its Annex A identifier, and write a short justification for any Annex A control you are marking as not applicable. Failing to complete this mapping, or leaving exclusions unjustified, is a common source of audit nonconformities.
Link each risk register row to its corresponding SoA entry and to the evidence that the control is actually in place, whether that is a policy document, a configuration screenshot, or a test result. This guide to Annex A controls walks through the full control set if you need the identifiers themselves.
Pro Tip: Keep a single column in your register listing the SoA control ID for each treated risk, so an auditor can trace a risk straight to its control and its evidence without cross-referencing two separate documents.
Audit readiness: maintaining, reviewing and evidencing the register
Review your register at least annually, and treat certain events as automatic reassessment triggers rather than waiting for the scheduled cycle: a security incident, a significant architecture change, a new supplier relationship, or news of a breach at an existing supplier.
Auditors look for evidence that the register is a living document, not a one-time exercise completed before certification. Keep these items attached or referenced against each row:
- Approval signatures or sign-off records showing the risk owner accepted the residual risk.
- Action evidence, such as test results, configuration exports, or completion tickets, proving a treatment was actually implemented.
- Meeting minutes from risk review sessions, showing the register was discussed, not just edited.
- Version history, so a reviewer can see what changed between audits and why.
Link each row’s evidence directly rather than describing it in prose: a ticket ID, a shared folder link, or a document reference in the status column saves time during an audit walkthrough and removes any doubt about whether the evidence actually exists.
Implementer perspective: where templates commonly fail and how to fix them
Most registers fail for the same three reasons: no named risk owner, controls and actions blurred into one column, and scenarios vague enough to mean anything. Fix this by piloting with five to ten real risks before rolling the template out organization-wide, checking each row against the worked examples above. Bring in outside help when your scoring disagreements are about definitions, not numbers. If your own team can’t agree what “likely” means, no amount of internal iteration will fix that.
— Martin
How ISMS Calculator helps you move faster
Building a register from scratch takes time you might not have budgeted for. A starting point is a free 2-minute check that flags where your ISMS stands today, and a cost calculator that turns your company size, industry, and maturity level into a tailored implementation estimate with transparent, editable assumptions and model reference comparisons you can validate against.
- Free 2-minute check: a fast readiness signal.
- Cost calculator: real-time, organization-specific estimates.
- Readiness assessment: a maturity view across the four Annex A control themes.
| What you need | ISMS Calculator feature |
|---|---|
| A quick readiness signal | Free 2-minute check |
| A tailored implementation estimate | ISO 27001 Cost Calculator |
| A domain-by-domain maturity view | ISO 27001 Readiness Assessment |
The methodology behind the calculator is fully traceable and versioned, so you can challenge or validate the figures rather than take them on faith. Start with the free readiness check and see where your register gaps line up with your broader implementation plan.
Sources
Key references: ISO/IEC 27001, ISO/IEC 27005, the SoA auditing practice note, and CloudSoul’s template guidance.
FAQ
Can you provide an example of a risk register?
A risk register example typically lists a risk ID, a cause-event-consequence scenario, the CIA property affected, existing controls, likelihood and impact scores, treatment, residual risk, and sign-off status. The worked rows in this guide, such as the phishing and supplier breach scenarios, show how each field gets populated in practice.
How do you do a risk assessment for ISO 27001?
You define your risk criteria and scales first, then identify scenarios tied to specific assets and threats, score their likelihood and impact, and select a treatment for anything above your acceptance line. This process follows ISO/IEC 27001 clauses 6.1.2 and 6.1.3, with ISO/IEC 27005 offering more detailed methodology guidance.
Is a risk register a legal requirement?
A risk register itself is not a separate legal requirement, but ISO/IEC 27001 requires documented evidence of your risk assessment and treatment results if you want certification. Most organizations use a register as the practical way to produce and maintain that documented evidence.
Can you explain ISO 27001 in simple terms?
ISO/IEC 27001 is an international standard that sets out requirements for building and running an information security management system, covering how an organization identifies risks, chooses controls, and proves it is managing them consistently. Certification against the standard signals to customers and partners that those processes have been independently assessed.
What mistakes should I avoid in a risk register?
The most common mistakes are leaving risk scenarios vague, mixing up risk owners with action owners, and blending controls and treatment actions into the same field. Defining clear scales and evidence rules on a separate method page, as described earlier in this guide, prevents most of these issues before they reach an audit.