# Cyber Risk Register Template (With Example) > Source: https://lscs.io/cyber-risk-register-template/ > A cyber risk register template with the 13 columns you need, a worked example, risk statement tips, scoring limits and how to keep it reviewed. A cyber risk register is a table that records each information security risk your organisation faces, who owns it, how serious it is before and after controls, and what you have decided to do about it, by when. A usable template needs 13 columns: ID, asset or scope, risk statement, owner, likelihood, impact, inherent score, existing controls, treatment option, residual score, due date, status and review date. Below you will find that template, a worked example for a fictional firm, and the practical habits (good risk statements, honest scoring and a review cycle) that stop a register from turning into a spreadsheet nobody opens. If you are new to the idea, start with our free lesson [What is a risk register and how to use one](https://lscs.io/learn/grc/what-is-a-risk-register/), then come back here for the hands-on version. ### The 13 columns and what goes in each Use this as your header row, and keep these definitions next to it so everyone fills it in the same way. | Column | What to record | Practical tip | | --- | --- | --- | | ID | A unique reference, such as R-014 | Never reuse an ID, even after a risk is closed. | | Asset / scope | The system, information, process or supplier at risk | Be specific: “payroll data in the HR system”, not “IT”. | | Risk statement | Cause, event and consequence in one or two sentences | See the formula in the next section. | | Owner | One named person with authority to act on the risk | A person, not a team or department. | | Likelihood | Rating on your agreed scale (for example 1 to 5) | Write the scale definitions down once and reuse them. | | Impact | Rating on your agreed scale (for example 1 to 5) | Anchor each level to money, downtime or harm. | | Inherent score | Likelihood combined with impact before controls | Shows why the controls matter. | | Existing controls | Controls already in place and working | Only list controls you could show evidence for. | | Treatment option | Avoid, treat, transfer/share or accept, plus the planned action | Record the reason, especially for acceptance. | | Residual score | The score expected once treatment is complete | Re-score when the work is actually done. | | Due date | When the treatment action will be complete | A real date, not “Q2” or “ongoing”. | | Status | Open, in progress, accepted, closed | Keep the list of statuses short and fixed. | | Review date | When the owner will next look at the entry | Higher risks get shorter intervals. | This matches what established guidance expects. NIST’s notional cybersecurity risk register template includes an ID, a risk description, likelihood, impact, an exposure rating, a risk response type, a risk owner and a status, and NIST notes that a register “may contain many more (or fewer) fields” depending on your risk strategy. Keep the register itself as a summary: NIST suggests putting detailed analysis, assumptions and decisions in a separate risk detail record linked to each entry. ### How to write a risk statement people can act on The risk statement is where many registers go wrong. “Ransomware” or “Phishing” is a topic, not a risk. A good statement names three things: - **Cause:** the threat or weakness that makes the event possible. - **Event:** what could actually happen. - **Consequence:** the effect on the business, in terms a director would recognise. A simple formula: _Because [cause], [event] could happen, resulting in [consequence]._ For example: “Because supplier bank detail changes are accepted by email without a call-back check, a criminal impersonating a supplier could have a payment redirected to their own account, resulting in direct financial loss.” NIST describes the same idea as a risk scenario that covers “the source of uncertainty, any predisposing conditions, the resources affected, and the anticipated result”. The NCSC adds a point worth borrowing: tell decision makers how certain you are, because a statement without that “would communicate to decision makers that you are completely certain that a risk would be realised as you describe.” Test each entry: could the owner name one action that would change it? If not, rewrite it. ### Scoring: likelihood, impact and their limits Many registers use a qualitative or semi-quantitative scale. A typical example is likelihood from 1 (rare) to 5 (almost certain) and impact from 1 (negligible) to 5 (severe), multiplied to give a score from 1 to 25, then banded into low, medium and high. ISO/IEC 27005:2022 defines the result, the level of risk, as the significance of a risk “expressed in terms of the combination of consequences and their likelihood”. Score twice. The **inherent** score describes the risk with no controls; NIST describes inherent risk as “risk conditions that would exist without any organizational interventions”. The **residual** score is what ISO/IEC 27005 calls “risk remaining after risk treatment”. The gap between the two shows what your controls are worth. Know the limits of the method: - **The numbers are labels, not measurements.** A score of 12 is not twice as bad as a score of 6. Treat scores as a way to rank risks, not to calculate losses. - **Matrices can mislead.** The NCSC warns that “whilst matrices are easy to use, they can lead to errors and miscommunication of risk if not used carefully”, and advises that you “carefully communicate the meaning of your scales and any labels used.” - **Different people score differently.** Define each level in writing and score as a group, not alone. - **Quantitative methods exist.** NIST IR 8286r1 describes quantitative analysis, where likelihood and impact are expressed as probabilities and monetary values, and says “quantitative methods are preferred”, while accepting they “may not always be possible in certain contexts.” A 5×5 scale is a sensible starting point, not the end state. ### Treatment options: choosing the right language Frameworks use slightly different words for the same four choices. Pick one set, define it, and use it consistently. | Plain choice | NCSC | NIST IR 8286r1 | ISO/IEC 27005:2022 | | --- | --- | --- | --- | | Stop the activity | Avoid | Avoid | Avoiding the risk | | Add or improve controls | Treat / mitigate | Mitigate | Removing the risk source, changing the likelihood, changing the consequences | | Pass part of it to another party | Transfer | Transfer | Sharing the risk (risk transfer is a form of risk sharing) | | Live with it, knowingly | Accept | Accept | Retaining the risk by informed decision | ISO/IEC 27005 adapts the general principles of ISO 31000 to information security, so its vocabulary will look familiar to anyone who knows ISO 31000:2018. Three points from these sources matter in practice: - **Transfer rarely transfers everything.** The NCSC notes that cyber insurance “only deals with the financial impacts of a risk being realised”; reputational, legal and regulatory impacts still need managing. - **Acceptance is a decision, not a shrug.** ISO/IEC 27005 defines risk acceptance as an “informed decision to take a particular risk” and states that accepted risks “are subject to monitoring and review.” Record who accepted it, why, and until when. - **Treatments create new risks.** NIST gives the example of multi-factor authentication reducing an access risk while introducing a risk of decreased productivity. Check whether a treatment needs its own entry. ### Worked example: a fictional 40-person firm **Illustrative only.** The organisation, risks, scores and dates below are invented to show how the columns work together. Imagine a 40-person professional services firm that uses Microsoft 365, an ageing on-premises file server and an outsourced payroll provider. Scores use a 1 to 5 scale for likelihood (L) and impact (I), multiplied. | Column | R-01 | R-02 | R-03 | R-04 | | --- | --- | --- | --- | --- | | Asset / scope | Supplier payments process | On-premises file server | Whole IT estate | Outsourced payroll service | | Risk statement | Because bank detail changes are accepted by email without a call-back, a criminal posing as a supplier could redirect a payment, causing direct financial loss. | Because the server runs an operating system that no longer receives security updates, an attacker on the network could exploit a known flaw to encrypt or steal client files, halting work and causing a personal data breach. | Because a ransomware incident would need specialist response and recovery the firm does not have in house, recovery costs could exceed what the firm can absorb. | Because payroll depends on one provider, an outage in the days before payday could delay staff pay. | | Owner | Finance Director | Operations Director | Managing Director | HR Manager | | Likelihood / impact | L4 / I4 | L3 / I5 | L3 / I4 | L2 / I3 | | Inherent score | 16 (high) | 15 (high) | 12 (medium) | 6 (low) | | Existing controls | MFA on email; annual awareness training | Firewall; nightly backup | Offline backups; endpoint protection | Supplier service levels in contract | | Treatment option | Treat: mandatory call-back to a known number for any bank detail change; second approver above an agreed threshold | Avoid: migrate files to existing cloud storage and decommission the server | Transfer: cyber insurance covering incident response costs (reputational impact remains with the firm) | Accept: within appetite; manual fallback payment process documented | | Residual score | 8 (L2 / I4) | Risk closed once server is decommissioned | 8 (L2 / I4) | 6 (accepted) | | Due date | 31 Jan 2027 | 31 Mar 2027 | 28 Feb 2027 | Not applicable | | Status | In progress | Open | In progress | Accepted by Managing Director until next review | | Review date | Monthly | Monthly | Quarterly | Quarterly | In a real register, the owner column holds a person’s name, not a job title. ### Keeping the register alive A register is only useful if it changes when the business does. The NCSC’s advice is to “regularly review your risks” and to “revisit your risk assessments when something significant changes”, such as a new threat, new technology or a change in how a system is used. In practice that means: - **A cadence by score.** For example, owners review high risks monthly and the rest quarterly. The NCSC and NIST guidance cited here does not set a fixed interval; NIST says your risk programme should “specify the frequency and methods” for monitoring risk responses. Choose yours, write it down and keep to it. - **Event-driven reviews.** A new supplier, an office move, a cloud migration or an incident should trigger a review of the affected entries straight away. - **Accepted risks have an expiry.** Put a review date on every acceptance, so it is reconsidered rather than forgotten. - **Archive deliberately.** NIST suggests organisations “consider an annual review of risks to archive risks”, and also check the archive for risks that have re-emerged. #### Reporting to management Boards do not want the full register. The NCSC says the board “should get the information they need, in a format that they understand, at the time they need it to enable decision-making.” A one-page summary usually covers it: - The top five to ten risks by residual score, each with its owner. - What has moved since the last report, and why. - Treatment actions that are overdue. - Risks above appetite that need a decision: fund the treatment, or formally accept. ### Learn to build and run a register with LSCS Our free [12-session GRC course](https://lscs.io/learn/grc/) covers the fundamentals, including [conducting a cyber risk assessment](https://lscs.io/learn/grc/how-to-conduct-a-cyber-risk-assessment/). If you want mentor-led practice, the [LSCS GRC Mentorship programme](https://lscs.io/grc-mentorship-course-details/) (6 months, £150/month) includes sessions on creating a first risk register from an Excel template and simulating a quarterly risk committee review. Contact us for dates. ### Frequently asked questions #### What should a cyber risk register include? At minimum: a unique ID, the asset or scope, a risk statement, a named owner, likelihood and impact ratings, inherent and residual scores, existing controls, the treatment decision, a due date, a status and a review date. #### What is the difference between inherent and residual risk? Inherent risk is the level of risk with no controls in place. Residual risk is the risk remaining after treatment. Recording both shows how much your controls actually reduce risk. #### What are the four risk treatment options? Avoid, treat (mitigate), transfer and accept. ISO/IEC 27005:2022 uses broader wording, such as sharing and retaining the risk, but the choices map closely to these four. #### How often should a risk register be reviewed? The NCSC and NIST guidance cited in this article does not set a fixed interval. One practical approach is monthly for high risks and quarterly for the rest, plus an immediate review whenever something significant changes, as the NCSC recommends. #### Can I use a spreadsheet for a risk register? Yes. A spreadsheet works well for many organisations. What matters is consistent definitions, named owners and a review cycle that is actually followed; a GRC tool helps mainly at larger scale. ### References - ISO (2022). _ISO/IEC 27005:2022 Information security, cybersecurity and privacy protection: Guidance on managing information security risks_ . [https://www.iso.org/standard/80585.html](https://www.iso.org/standard/80585.html) - ISO (2022). _ISO/IEC 27005:2022, clause 3 Terms and definitions (Online Browsing Platform preview)_ . [https://www.iso.org/obp/ui/en/#iso:std:iso-iec:27005:ed-4:v1:en](https://www.iso.org/obp/ui/en/#iso:std:iso-iec:27005:ed-4:v1:en) - ISO (2018). _ISO 31000:2018 Risk management: Guidelines_ . [https://www.iso.org/standard/65694.html](https://www.iso.org/standard/65694.html) - NIST (2025). _NIST IR 8286r1: Integrating Cybersecurity and Enterprise Risk Management (ERM)_ . [https://doi.org/10.6028/NIST.IR.8286r1](https://doi.org/10.6028/NIST.IR.8286r1) - NCSC (2021). _10 Steps to Cyber Security: Risk management_ . [https://www.ncsc.gov.uk/collection/10-steps/risk-management](https://www.ncsc.gov.uk/collection/10-steps/risk-management) - NCSC (2023). _Risk management: A basic risk assessment and management method_ . [https://www.ncsc.gov.uk/collection/risk-management/a-basic-risk-assessment-and-management-method](https://www.ncsc.gov.uk/collection/risk-management/a-basic-risk-assessment-and-management-method) - NCSC (2023). _Risk management: The fundamentals and basics of cyber risk_ . [https://www.ncsc.gov.uk/collection/risk-management/the-fundamentals-and-basics-of-cyber-risk](https://www.ncsc.gov.uk/collection/risk-management/the-fundamentals-and-basics-of-cyber-risk) ### Start Learning With LSCS [OUR COURSES](https://lscs.io/our-courses/) [ALL POSTS](https://lscs.io/blogs/)