Cyber Risk Register Template: How to Build One and Actually Use It

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, 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.

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.

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.

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:

1. The top five to ten risks by residual score, each with its owner.
2. What has moved since the last report, and why.
3. Treatment actions that are overdue.
4. 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 covers the fundamentals, including conducting a cyber risk assessment. If you want mentor-led practice, the LSCS GRC Mentorship programme (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
• 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
• ISO (2018). ISO 31000:2018 Risk management: Guidelines. 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
• NCSC (2021). 10 Steps to Cyber Security: 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
• 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