BLOG

By David Chernitzky, Co-Founder and CEO, Armour Cybersecurity  |  Serving organizations across Canada, the US, and beyond  |  Last updated August 18, 2026

Quick answer: A security risk register is a structured document that captures every material security risk the organization faces, scores each risk for likelihood and impact, documents the controls in place to mitigate it, identifies the owner accountable for managing it, and tracks the residual risk that remains after mitigation. Most organizations that have risk registers produced them for a specific audit and have not updated them since. A risk register that is not maintained, not reviewed by leadership, and not connected to actual risk decisions is not a governance tool; it is a document that creates the appearance of risk management without providing any of the substance.

Key Takeaways

• A risk register is a living document, not a point-in-time deliverable. Its value is directly proportional to how current it is. A risk register updated annually at audit time reflects the risk profile of twelve months ago; one reviewed quarterly and updated when material changes occur reflects the risk profile of today.
• Risk scoring combines likelihood and impact into a risk rating. Likelihood estimates how probable the risk event is given the current control environment. Impact estimates the business consequence if the risk event occurs. The product of likelihood and impact produces a risk score that allows risks to be ranked and prioritized, directing limited remediation resources to the highest-risk items first.
• Every risk in the register needs an owner: a named individual who is accountable for the risk’s status, responsible for maintaining the accuracy of its entry, and empowered to escalate when the risk exceeds acceptable thresholds. Risk registers without owners are documents; risk registers with owners are governance controls.
• The risk register must distinguish between inherent risk (the risk before any controls are applied) and residual risk (the risk that remains after existing controls are taken into account). Leadership decisions about risk acceptance should be made at the residual risk level, with documented approval for any residual risk that exceeds the organization’s risk appetite.
• ISO 27001 requires a documented information security risk assessment and risk treatment process. SOC 2 CC3.2 requires that the organization identifies risks to the achievement of its objectives and analyzes them as the basis for how they should be managed. A well-maintained risk register is one of the primary pieces of evidence both frameworks require.

Why Most Risk Registers Do Not Work

The most common failure of organizational risk registers is that they were built for an audit and not for the organization. A consultant comes in, conducts a risk assessment against the applicable framework, produces a register formatted to satisfy the framework’s documentation requirements, and delivers it to the client. The client stores it in a shared drive. It is presented to the auditor at the next assessment, at which point the auditor notes that the register has not been updated in 18 months and that several of the risks listed have changed materially since the assessment was conducted.

This failure has a predictable cause: the risk register was designed as a deliverable rather than as an operational tool. It was not connected to the people who manage the underlying controls, was not reviewed by the leadership team who should be making risk decisions based on it, and was not integrated into the governance cadence that would keep it current. A risk register that nobody reviews between audits provides no governance value during the period between audits, which is the period when the risks it describes are actually evolving. This is why the register belongs inside a live governance, risk and compliance program rather than sitting on its own as a standalone file.

The Core Elements of a Working Risk Register

Asset inventory and criticality

The starting point of a risk register is knowing what assets the organization has and which ones matter most. Information assets, including customer data, financial records, intellectual property, and operational systems, are the primary focus of an information security risk register. Each asset should be identified, described, and assigned a criticality rating that reflects the business impact if the asset were compromised, made unavailable, or disclosed without authorization. The criticality rating drives the priority of risk assessment: high-criticality assets warrant deeper risk analysis and more intensive controls than low-criticality ones. Asset inventory is also an ongoing activity: new systems, new data stores, and new integrations create new assets that need to be assessed and registered.

Threat and vulnerability identification

For each critical asset, the risk register captures the threats that could compromise it and the vulnerabilities that those threats could exploit. Threats are the potential events that could cause harm: ransomware attack, insider data theft, accidental disclosure, third-party breach, denial of service, or physical access by unauthorized individuals. Vulnerabilities are the weaknesses in the environment that make those threats more likely to succeed: unpatched software, weak authentication, inadequate access controls, misconfigured cloud storage, or the absence of encryption on sensitive data. The combination of a credible threat and an exploitable vulnerability defines a risk that should be evaluated and registered.

Threat identification should be grounded in the actual threat landscape relevant to the organization’s industry and size, not a generic list of possible threats that treats ransomware and nation-state espionage as equally relevant for a fifty-person professional services firm. Threat intelligence, sector-specific incident data, and the organization’s own incident history are useful inputs to a realistic threat assessment.

Likelihood and impact scoring

Risk scoring converts the qualitative assessment of threat and vulnerability into a quantitative rating that allows risks to be ranked and compared. Likelihood scoring estimates the probability that the risk event will occur within a defined time period (typically one year) given the current control environment. A simple three-level or five-level scale is more practical than a pseudo-precise numerical scale that creates false precision: low (the event is unlikely given current controls), medium (the event could plausibly occur), and high (the event is likely or has occurred before) provides enough differentiation to drive prioritization without requiring unwarranted precision in the estimates.

Impact scoring estimates the business consequence if the risk event occurs. Impact dimensions typically include financial impact (the direct cost of the incident response, regulatory fines, litigation, and business disruption), reputational impact (the effect on customer trust, brand, and market position), operational impact (the disruption to business operations and service delivery), and regulatory impact (the compliance and enforcement consequences). For each risk, the impact score reflects the worst-case realistic outcome at the asset’s criticality level. The combined likelihood-impact score produces the risk rating that determines where the risk sits in the prioritized register.

Current controls and residual risk

The risk register must document not only the identified risk but the controls currently in place to mitigate it, and the residual risk that remains after those controls are applied. The inherent risk, the risk before any controls, is typically high for most significant threats. The key question for governance is whether the controls reduce the residual risk to a level within the organization’s risk appetite. A ransomware threat against production systems has high inherent risk for most organizations. If the organization has deployed EDR across all endpoints, maintains immutable offsite backups, has implemented network segmentation that limits lateral movement, and has a tested incident response plan, the residual risk is materially lower than the inherent risk. An independent cyber posture assessment is one of the cleanest ways to establish where those controls are actually effective. The risk register captures both the inherent and residual scores, with the controls listed, giving leadership a clear view of where controls are effective and where gaps remain.

Risk ownership and treatment decisions

Every risk entry in the register needs a named owner: the individual who is accountable for the risk’s status, responsible for ensuring that the documented controls are actually operating, and empowered to escalate when the risk exceeds acceptable thresholds. Risk owners are typically not the CISO or IT director for every risk; they are the business owners of the assets and processes at risk. The owner of the customer data risk may be the Chief Privacy Officer. The owner of the payment processing risk may be the CFO. The owner of the production system availability risk may be the CTO. Assigning risks to owners who have operational authority over the relevant assets and processes is what makes the risk register an operational tool rather than a consulting artefact.

Treatment decisions document how the organization has decided to address each risk: mitigate (implement or improve controls), accept (acknowledge the risk and document the approval at the appropriate level), transfer (shift the financial consequence through insurance or contractual indemnity), or avoid (discontinue the activity that creates the risk). Accepted risks require documented approval from the appropriate authority level based on the risk score: low residual risks may be accepted by the risk owner, higher residual risks require escalation to the CISO or executive team, and risks that exceed the organization’s defined risk appetite threshold require board or audit committee visibility. Armour Cybersecurity builds risk registers with this governance layer integrated from the start, so the register produces not just a list of risks but a documented decision trail for every one of them.

Maintaining the Risk Register Over Time

The maintenance cadence for a risk register should match the pace at which the organization’s risk environment changes. Quarterly review is appropriate for most mid-market organizations: sufficient to catch material changes in the threat landscape, control environment, or regulatory requirements without creating an unsustainable documentation burden. Specific events should trigger an unscheduled review: a security incident, a significant infrastructure change, the addition of a new high-criticality system, a change in regulatory requirements, or the departure of a key risk owner.

The quarterly review process should cover the accuracy of existing entries (have any risks changed in likelihood, impact, or control status since the last review), the completeness of the register (have any new risks emerged that are not yet captured), the status of treatment actions (are remediation activities on track, or do resource or timeline challenges require escalation), and the currency of risk ownership (have any risk owners changed roles in a way that requires reassignment). A thirty to sixty minute governance committee review on a quarterly cadence is sufficient to maintain a well-structured register for a mid-market organization. This review cadence is the point at which the risk register stops being a document and becomes a functioning risk register GRC control, feeding the board reporting and treatment decisions the governance program is built to produce.

Frequently Asked Questions

How many risks should be in a security risk register?

There is no correct number, but a risk register that is too short is usually more problematic than one that is too long. A register with five entries for a 200-person organization handling customer financial data is almost certainly incomplete; it is either missing material risks or aggregating distinct risks into entries that are too broad to be actionable. A register with 200 entries for the same organization is probably over-segmented into individual technical vulnerabilities that belong in a vulnerability management tracker rather than a strategic risk register. A well-structured strategic risk register for a mid-market organization typically contains between 20 and 60 entries covering the most material risks across all domains: data protection, system availability, access control, third-party exposure, physical security, compliance, and business continuity.

How do we score risks consistently across different assessors?

Consistent scoring requires a defined scoring rubric, effectively a cybersecurity risk register template for judgment, that maps qualitative descriptions to numerical values for both likelihood and impact. Without a rubric, two assessors evaluating the same risk will assign different scores based on their individual judgment and risk tolerance. The rubric should define what each level of likelihood means in concrete terms: for example, low means the event has not occurred in the past three years and is not a known active threat in the sector; medium means the event has occurred at comparable organizations within the past year; high means the event has occurred at this organization or is a confirmed active threat in the sector. Impact levels should similarly be defined in terms of financial ranges, operational disruption duration, and regulatory consequence categories that allow assessors to apply the scale consistently.

What is the difference between a risk register and a vulnerability register?

A risk register captures strategic and business risks at a level of abstraction appropriate for leadership decision-making. It might contain an entry for the risk of unauthorized access to customer data through compromised credentials, scored for likelihood and impact, with the current controls listed and residual risk documented. A vulnerability register or vulnerability management tracker captures specific technical vulnerabilities identified through scanning, penetration testing, or security advisories: a specific CVE affecting a specific version of a specific product running on a specific server, with severity, asset criticality, remediation status, and target remediation date. Both are governance tools, but they serve different audiences and purposes. The risk register serves executive and governance audiences making strategic decisions; the vulnerability register serves the security operations team managing technical remediation. The two are connected: a persistent pattern of unpatched critical vulnerabilities in the vulnerability register should surface as an elevated risk in the risk register.

Do we need a separate risk register for each compliance framework?

No. A single, well-structured risk register can serve multiple compliance frameworks simultaneously. ISO 27001 requires a documented risk assessment and risk treatment process. SOC 2 requires evidence that the organization identifies and assesses risks affecting the trust services criteria, primarily through the CC3 risk assessment criteria. HIPAA requires a documented security risk analysis. PCI DSS v4.0 replaced the older blanket annual risk assessment with targeted risk analyses tied to specific requirements, and a maintained risk register still provides the foundation those analyses draw on. These requirements all call for risk assessment and documentation; they do not require separate registers with separate formats. The risk register should be structured to capture the information each framework requires, with a mapping that shows which register entries satisfy which framework requirements. The compliance mapping matrix that Armour Cybersecurity produces as part of its GRC engagements performs exactly this cross-framework alignment.

How does the risk register connect to cyber insurance?

The risk register is directly relevant to cyber insurance in two ways. First, it informs the coverage scoping conversation: the risks documented in the register, with their likelihood and impact scores, provide the data foundation for determining what coverage limits and categories are appropriate for the organization’s risk profile. A risk register showing high residual risk of ransomware with a modelled business interruption impact of two weeks of revenue provides the basis for a rational business interruption coverage limit. Second, underwriters are increasingly asking about risk management practices as part of the underwriting questionnaire, and this is where cyber insurance advisory work connects to the register. Organizations that can demonstrate a maintained, leadership-reviewed risk register are providing evidence of a mature governance function that reduces the underwriter’s uncertainty about the organization’s risk management sophistication.

The Bottom Line

A security risk register earns its place only when it is used: reviewed by leadership on a real cadence, owned by the people who run the controls, and connected to the decisions the business actually makes about accepting, mitigating, or transferring risk. Most registers fail because they were built for an auditor and then abandoned. Build it from real assets, score it with a consistent rubric, distinguish inherent from residual risk, and keep it current on a quarterly cadence, and it becomes the single artefact that serves your board, your auditors, and your insurers at once. A structured governance, risk and compliance program is what keeps it alive between audits rather than dusted off the week before one.