What is a risk register?

A risk register is a central record of an organisation’s current risks and the information needed to manage them. For cybersecurity, it is where each risk is written down once, given an owner, rated, and linked to the decision made about it: treat it, accept it, transfer it or avoid it.

NIST’s glossary gives two definitions that fit this use. One describes a risk register as “a repository of risk information including the data understood about risks over time”. The other describes it as “a central record of current risks, and related information, for a given scope or organization”, noting that current risks include both accepted risks and risks with a planned mitigation path.

What goes in a risk register

NIST has published guidance on this. Its Interagency Report 8286 Rev. 1, published in December 2025 and superseding the original 2020 version, includes guidance on the use of risk registers to set out cybersecurity risk, and supplies a risk register schema and template as supporting material. The report is about connecting cybersecurity risk to enterprise risk management so that risk information can be rolled up to the enterprise level.

The fields vary between organisations, but a practical register for a small or mid-sized client usually has:

• A unique reference and a clear title. Describe the risk as something that could happen, such as “an unmanaged laptop is lost with client data on it”.
• Scope. The system, supplier, site or service the risk relates to.
• An owner. A named person inside the client who can make the decision.
• Likelihood and impact. Use a simple, consistent scale agreed with the client.
• The current rating, and any existing controls.
• The decision. Treat, accept, transfer or avoid, with the reason.
• Treatment actions, dates and status.
• The review date.

Keep the record short. A register that people can read is more useful than one that tries to capture everything.

Why it matters

The UK National Cyber Security Centre says that improving business outcomes should be the primary driver for cyber security risk management, and that it favours meaningful risk management that illuminates the real cyber risks. A register is how that happens in practice: it puts the real risks and the decisions about them in one place that leadership can read.

It also connects other work. NIST’s Cybersecurity Framework 2.0 lists a risk register as one example of the prioritised action plan that follows a gap analysis. The Saudi NCA’s Essential Cybersecurity Controls ask for a documented risk management methodology and say risk assessments are carried out at specific points such as the early stage of technology projects and before major infrastructure changes. Different frameworks use different words, but they ask for the same thing: a record of risks and decisions.

How an MSP or vCISO delivers it

Maintaining a register is a recurring service, not a one-off document.

1. Agree the method. Choose the scale, the rating matrix and the decision options with the client, and write them down.
2. Seed the register. Start from the gap assessment findings, supplier reviews and incidents.
3. Assign owners. Every risk needs a client-side owner. If no one will own it, escalate to leadership.
4. Review on a cadence. Agree a review cadence with the client, since the right rhythm depends on their risk profile and how fast things change.
5. Report decisions, not lists. Show which risks are rising, which were accepted and which need a decision. The board reporting guide covers one approach.
6. Link it to the controls. Show which controls reduce each risk, which also helps with ISO 27001 and similar frameworks, as described in the Statement of Applicability guide.

To start one, use the free risk register template, which includes a scoring method and a CSV download.

For how this sits inside a retained engagement, see the first 90 days playbook and the NIST CSF guide.

Common mistakes

• Using the register as a to-do list. Tasks belong in an action tracker. The register records risks and decisions.
• Writing risks as vague topics. “Ransomware” is a subject. A risk is a specific event with a consequence.
• Leaving owners blank or assigning everything to IT. The business owns business risk.
• Rating everything as high. If every item is high, the register cannot guide priorities.
• Accepting risk without a record. An accepted risk should have a named approver and a review date.
• Never reviewing it. A register that is not updated after changes and incidents gradually stops describing reality.
• Keeping it in a private file. Use one shared version, with a history of changes.

Where GetCybr fits

If you maintain risk registers for several clients, GetCybr is a platform for keeping each client’s register, owners, linked controls and review dates in one place, and for reporting from it. It does not decide which risks a client should accept, and that judgement stays with the client and the vCISO. You can see how the platform supports this on the GRC platform page.

Sources

• NIST Computer Security Resource Center, Glossary: risk register. Source for both definitions quoted above.
• NIST Computer Security Resource Center, IR 8286 Rev. 1, Integrating Cybersecurity and Enterprise Risk Management, December 2025. Source for the risk register guidance and supplemental template.
• NIST, The NIST Cybersecurity Framework (CSF) 2.0, February 2024. The CSF page links to the full document (NIST CSWP 29), which is the source for the risk register example in the gap analysis step.
• UK National Cyber Security Centre, Risk management guidance. Source for the statements on business outcomes and meaningful risk management.
• National Cybersecurity Authority (Saudi Arabia), Essential Cybersecurity Controls (ECC). The linked ECC-2:2024 document is the source for the risk management subdomain.