A cyber risk register is the central record through which an organisation documents, tracks, and manages its cybersecurity risks. Done well, it transforms cyber risk from a vague concern that everyone worries about but nobody can precisely articulate into a specific, prioritised, accountable set of items the organisation can actually act on. Done poorly, as a spreadsheet populated once during an annual exercise and left unchanged until the next one, it provides a misleading impression of governance without the substance.
The difference between a useful register and a nominal one is not the template used. It is whether the register reflects the actual risk environment, is kept sufficiently current to support decisions, and is connected to the governance processes that use it.
This guide covers the steps involved, based on the approach described in NIST IR 8286 and widely applied across sectors, with practical guidance on the decisions that most commonly determine quality.
The most important framing for building a cyber risk register is that it is a management tool rather than a documentation exercise. The purpose is not to produce a record demonstrating that cyber risk has been considered. It is to give risk owners, the security function, and the board a current, accurate, prioritised view of where the organisation's most significant cyber vulnerabilities lie and what is being done about them.
A register that serves this purpose will be used regularly and will visibly influence decisions about security investment, remediation priorities, and risk acceptance. A register that is a documentation exercise will be updated annually and consulted when an audit or regulatory review makes it necessary to produce evidence that it exists.
Before identifying any risks, be explicit about what the register covers. A comprehensive cyber risk register covering the whole organisation is the right end state for most organisations but may not be the right starting point. Beginning with the highest-risk areas, systems processing sensitive data, customer-facing applications, critical infrastructure, and core financial systems, produces a register that is genuinely useful sooner than an attempt at comprehensive coverage from the outset produces a register that is too large to maintain.
A cyber risk register that identifies risks without connecting them to specific assets is incomplete. The severity of a cyber risk depends entirely on what it affects: the same vulnerability in a low-criticality internal system and in a customer-facing system processing sensitive financial data represent very different risk levels.
The asset inventory identifies what is being protected and determines the stakes. Every risk in the register should trace back to one or more assets in the inventory.
Assets for cyber risk purposes include hardware (servers, endpoints, networking equipment, and physical security systems); software (operating systems, applications, databases, and development tools); data assets (customer data, financial data, intellectual property, and operational data); network infrastructure (internal networks, cloud environments, and remote access systems); and third-party services and integrations (cloud platforms, SaaS applications, and APIs).
For each asset, record the asset name and type, the business function it supports, the classification of the data it holds or processes (typically ranging from public through to highly confidential), the business owner, the technical owner, and a criticality rating reflecting how severe disruption to the asset would be.
Asset inventories degrade. New services are adopted, systems are decommissioned, and cloud usage grows beyond what is centrally tracked. A discovery process that supplements manual records with automated network scanning, cloud asset discovery tools, and regular review of new procurement and IT change requests maintains accuracy considerably better than annual manual updates.
NIST IR 8286 draws a distinction that is fundamental to well-structured cyber risk identification: a threat is the potential event or agent that could cause harm; a vulnerability is the specific weakness that would allow a threat to materialise.
Ransomware is a threat. An unpatched operating system vulnerability that ransomware exploits is a vulnerability. The combination of threat and vulnerability produces the risk: ransomware could exploit the unpatched vulnerability to encrypt the system. Keeping this distinction clear produces more specific and more actionable risk descriptions than identifying threats alone.
Threat identification should draw on multiple sources rather than relying on general knowledge or internal experience alone. Threat intelligence services specific to the organisation's sector provide information about the techniques and targets of current threat actors. The NCSC's threat reports, ENISA's Threat Landscape, and sector-specific information sharing groups all provide relevant external intelligence. Internal incident history and near-miss data identifies the threats that have already reached this specific organisation. And vulnerability disclosure feeds and patch advisories identify specific weaknesses being exploited in the current threat landscape.
Vulnerability identification draws on vulnerability assessments and penetration testing conducted on the organisation's own systems; vulnerability scan data from automated tools running against networks and endpoints; threat intelligence about specific vulnerabilities being actively exploited; and the organisation's own knowledge of configuration weaknesses, legacy system risks, and control gaps that technical teams are aware of but that may not be formally documented.
A risk described as "data breach risk" or "cyber attack" is not a useful register entry. It cannot be meaningfully assessed, owned, or managed, because it does not specify what could go wrong, how, or with what consequence. The person reading the register cannot determine what controls would address it, cannot assess the likelihood or severity, and cannot track whether it is being managed effectively.
Specific risk descriptions are more work to produce but generate all the value. They allow the risk to be assessed consistently regardless of who is reading the register, controlled by appropriate measures, owned by a specific individual with clear accountability, and tracked over time to determine whether the risk position is improving or deteriorating.
A cause-and-event-and-consequence structure produces the specificity that makes risk descriptions actionable. The cause identifies the threat and vulnerability. The event describes what could happen if the threat exploits the vulnerability. The consequence describes the impact on the organisation.
For example: an unpatched critical vulnerability in the organisation's external-facing web application could be exploited by an external attacker to gain unauthorised access, potentially resulting in exfiltration of customer data, regulatory breach notification obligations, and reputational damage.
This description identifies the vulnerability (unpatched web application), the threat (external attacker exploitation), and the consequences (data exfiltration, regulatory notification, reputational damage). A control assessor knows what to test, a risk owner knows what to manage, and the board knows what it is accepting if the risk is retained.
Likelihood assessment for cyber risk benefits from incorporating threat intelligence rather than relying on historical experience alone. An organisation that has not yet experienced a ransomware attack may have low historical frequency but face high likelihood based on the current prevalence of ransomware in its sector and the vulnerabilities that current threat actors are actively exploiting.
The likelihood scale should be explicitly defined so that all assessors apply the same criteria. A likelihood rated as "high" means the same thing across the organisation only if the definition specifies something like "likely to occur within the next twelve months based on current threat intelligence and vulnerability profile."
Cyber risk impact assessments that focus only on financial loss understate the actual severity for most risk scenarios. A complete impact assessment considers financial consequences including direct costs of incident response, data recovery, regulatory fines, and business interruption; operational consequences including service disruption and degraded capability; regulatory and legal consequences including notification obligations, enforcement action, and litigation; reputational consequences including customer trust, media coverage, and counterparty relationships; and data consequences including the nature, sensitivity, and volume of data affected.
For risks involving personal data, the data protection impact dimension is particularly important because it determines whether regulatory notification obligations are triggered and whether individual harm occurs.
For each identified risk, documenting the controls currently in place and assessing their adequacy is the step that connects the risk register to the control environment. This exercise frequently reveals one of two patterns: controls that are assumed to be in place but are not consistently applied, and risks for which no adequate control exists.
The control mapping should be specific: not "we have information security controls" but "dual approval is required for all database exports of customer records, enforced through system access controls in the data management platform." Vague control descriptions cannot be tested, and controls that cannot be tested are of uncertain effectiveness.
Where control gaps are identified, they should be documented as gap findings in the register with associated remediation actions. The risk register is not only a record of current exposure but a tracking mechanism for the improvements being made to reduce that exposure.
For each risk, the residual risk rating reflects the level of exposure that remains after existing controls are considered. The gap between the inherent risk (before controls) and the residual risk is the claim being made about what the control environment is achieving. Where controls are assessed as adequately designed and operating effectively, a significant reduction from inherent to residual is justified. Where controls are weak or inconsistently applied, the residual risk should be close to the inherent level.
Every risk in the register needs a named owner who is personally accountable for managing it. Risks owned by a team, a committee, or a function without a named individual tend to be managed by nobody, because when a risk belongs to everyone it effectively belongs to no one.
The owner should be a specific individual who has the authority and the relevant knowledge to manage the risk. For technical risks, this is often the system owner or the head of the relevant technology domain. For risks with significant business implications, ownership may sit with a business leader rather than in the IT function.
Every risk requires an explicit treatment decision: mitigate, transfer, avoid, or accept. A risk listed in the register without a treatment decision is not being governed; it is being documented. The treatment decision should be documented alongside the risk, with the reasoning that justifies it.
For accepted risks, the acceptance should be explicit and should go through an appropriate governance process. A significant cyber risk that is accepted without board awareness is not a legitimate governance decision, regardless of whether the accepting party believed it to be within their authority.
NIST IR 8286 emphasises that the register's value depends on its currency: a risk register that was accurate when it was last updated but has not been maintained since is not providing current risk intelligence. The threat landscape changes, the organisation's technology changes, incidents reveal new vulnerabilities, and remediation activities reduce risk levels that should be reflected in the register.
Defined triggers for updates maintain currency without requiring continuous active maintenance. Triggers should include: significant incidents or near-misses that reveal unidentified vulnerabilities or that challenge existing risk assessments; new systems, applications, or services being deployed or procured; significant changes to existing systems including major updates or configuration changes; new threat intelligence indicating increased likelihood for specific risk types; and completion of remediation actions that should reduce residual risk ratings.
A quarterly review cycle provides the minimum structure for maintaining currency, with the trigger-based approach ensuring the register reflects material changes between formal reviews.
