What is a risk register?

A risk register is a record of decisions, and the columns that hold the decisions are the ones that go unfilled. Everything up to the score gets filled in. Then the row stops: nobody is named against it, no response is chosen, and there is no date it comes back.

Two published definitions sit behind the term, and one document quotes both. NIST IR 8286r1, Integrating Cybersecurity and Enterprise Risk Management, takes the long one from the United States Office of Management and Budget's Circular A-11, where a risk register is "a repository of risk information including the data understood about risks over time". It takes the short one from ISO: "a record of information about identified risks". NIST then adds the instruction that matters more than either definition, which is that a register should be folded into whatever risk management method an organisation already runs.

Check the edition before citing NIST on this. IR 8286r1 was published on 18 December 2025 and withdrew the October 2020 original in its entirety, so a page pointing at the 2020 document is citing a withdrawn one.

Why a risk register matters

A register gets asked for in five situations, and each one asks a different question of it. A certification audit asks whether the criteria were set before the scoring and whether every entry has a named owner. A customer security review asks whether the risks that customer cares about appear on it at all. A board or audit committee paper asks which risks sit above the line leadership drew. An insurance renewal asks what the organisation knew and when. And the day after an incident, somebody asks whether this was known, and who decided to live with it. Each of those questions lands on a different part of the record.

Without a register, the answer to that last question is a memory and a search of a chat history, produced in the worst week of the year. The register exists so that "we knew and we accepted it" is a record with a name and a date on it.

The standards position is worth stating plainly, because the pages ranking for this term mostly leave it out: of the seven read in September 2026, one cited a standard at all, and the edition it cited had been withdrawn. ISO/IEC 27001:2022 is a certification standard, and its clauses bind an organisation that holds or seeks the certificate. Clause 6.1.2 requires that organisation to set risk criteria including acceptance criteria, to ensure repeated assessments produce consistent, valid and comparable results, to identify risks to the confidentiality, integrity and availability of information and to identify the risk owners, to analyse consequences and likelihood, and to evaluate the results against the criteria. Clause 8.2 requires assessments at planned intervals or when significant changes are proposed or occur, with documented information of the results retained. Neither clause says "risk register". The register is the artefact nearly everyone builds to satisfy them, and it is a choice of form.

NIST publishes the template and does not require it: SP 800-30 Rev. 1 and SP 800-37 Rev. 2, the two documents most often waved at a register, never use the phrase, and both are guidance.

The Australian Signals Directorate's Information security manual (the ISM) never uses it either. The ISM is advice from ASD, and it becomes an obligation through the Protective Security Policy Framework, a contract, a state policy or a direction. What it asks of the organisations it reaches is that acceptance is a named person's act. In Australian Government practice an authorising officer accepts the security risks of operating a system, may attach constraints such as limited functionality or an expiry date, and may revoke the authorisation when the risks are no longer acceptable; for non-classified through SECRET systems that officer is the Chief Information Security Officer (CISO) or their delegate. An obligation can require everything a register holds without ever naming one.

The last argument for building it properly is that a good register travels. NIST runs entries upward: a system register feeds an organisation register, which feeds an enterprise risk register and the profile drawn from it. A register that cannot roll up serves one team. One that can is a governance instrument, because the board and the engineer then read the same entries at different resolutions.

The entry itself does not change on the way up. What changes is how much of it each level reads.

How a risk register works, step by step

NIST defines risk as a measure of the extent to which an entity is threatened by a potential circumstance or event, and makes it a function of the adverse impacts if the event occurs and the likelihood that it occurs. A register entry is one such measure, written down, with a decision attached to it.

The sequence starts with criteria, not with a risk. Every later argument, about whether a score is fair or whether something can be accepted, is an argument about criteria that were never written down. Clause 6.1.2 (a) puts them first for that reason.

Three of those steps carry the weight, and each has a published source behind it.

The response types are the first. NIST names four for negative risk and states what each commits you to. Accept means carrying the risk within tolerance, with monitoring only. Transfer means sharing part of the consequence with another party, usually through insurance or a contract, with the caveat NIST attaches: some consequences, "like the loss of customer trust", cannot be transferred to anybody. Mitigate means reducing the threat, the vulnerability or the impact until what remains is acceptable. Avoid means ensuring the risk cannot occur, at the price of the opportunity that went with it. NIST carries matching types for positive risk, the upside case, and almost no security register uses them.

Appetite and tolerance are the second, and they do different jobs.

The three risk states are the third, and they are where a register quietly breaks. NIST quotes the enterprise risk management framework published by COSO, the Committee of Sponsoring Organizations, for all of them. Inherent risk is "the risk to an entity in the absence of any direct or focused actions by management to alter its severity". Target residual risk is the amount an organisation prefers to assume, knowing what management will do about it. Actual residual risk is "the risk remaining after management has taken action to alter its severity", and it "should be equal to or less than the target residual risk". A register carrying one number per row cannot show what the treatment bought.

The worked example below scores both entries three times. RISK-418, the unpatched appliance, runs 25 inherent, a target residual of 8 and an actual residual of 6, and closes. RISK-419, the missing standby pair, runs 16 inherent against a target residual of 9, and its actual residual of 12 lands three points above both that target and the distributor's technology appetite threshold of 9, which is the distance an acceptance carries.

The fields a register needs

NIST's template names twelve elements, and it is the column set to start from: published, dated, free, and the only widely available one that names its fields. Five more earn their place in practice, and the table marks which is which.

A worked example: an unpatched internet-facing VPN

A 600-person medical device distributor runs a single remote access virtual private network (VPN) appliance, VPN-01, at the edge of its corporate network. Every employee connects through it, and it is the path an offshore support team takes to reach the order management system. There is no standby pair, so any firmware upgrade means an outage.

On 24 July 2026 the vendor publishes an advisory for a pre-authentication remote code execution flaw in the appliance's web portal, with a Common Vulnerabilities and Exposures (CVE) record and a base score of 9.8 on the Common Vulnerability Scoring System (CVSS). Exploitation against internet-facing units of this model is already being reported.

The criteria, which were set long before this. The distributor scores likelihood and impact from 1 to 5 each, multiplies them for an exposure rating out of 25, and publishes a written description of every point on both scales, so a score has to be argued against a sentence. Appetite is a threshold per category: 9 for technology, against an organisation default of 12. The acceptance criterion is one sentence: anything above its category threshold may only be carried under a recorded acceptance from a named person, with conditions and an expiry date, and it is re-read quarterly until it closes or expires.

Two entries, not one. The obvious entry is the unpatched appliance. The second is easy to miss and outlives the first: VPN-01 is a single unit with no standby pair, so any critical advisory waits for an out-of-hours change window. The last two firmware upgrades took eleven days and six days to schedule. A register that records only the first entry loses the second the moment the patch ships, then rediscovers it at the next advisory. Both open in the week the advisory lands, RISK-418 first of the forty-seven open entries and RISK-419 fourth.

The owner. Both entries are owned by Marcus Feng, Head of IT Infrastructure. The security team found the advisory and will score it, but it can neither schedule the outage nor buy a second appliance, and an owner who cannot act is a placeholder. Ana Ruiz, a risk analyst in that team, is the assessor: she scores, challenges and validates, and owns neither entry.

The inherent ratings. RISK-418 reads: if the unpatched pre-authentication flaw in VPN-01's web portal is exploited from the internet, an attacker gains code execution on the appliance and reaches the internal server segment, including the order management database. It scores likelihood 5 and impact 5, an exposure of 25. Likelihood 5 because the flaw is scored 9.8, needs no credentials, sits on an internet-facing port, and is already being used against this model. Impact 5 because that path ends at the order management database.

RISK-419, the missing standby pair, scores likelihood 4 and impact 4, an exposure of 16. The event being rated is an advisory that leaves a live, internet-reachable flaw on VPN-01 for days. Likelihood 4 because the vendor published two advisories rated critical for this product family in the previous eighteen months, and every internet-facing surface on the appliance is in scope for the next one. Impact 4 because the consequence being scored is the exposure window between an advisory and a patch, not the outage: the order management system carries a recovery time objective (RTO) of four hours, and a planned thirty-minute window sits well inside it.

The appetite verdict. Both entries sit above the technology threshold of 9, and nobody argues about it, because the threshold was published before the advisory arrived.

The responses. RISK-418 is mitigated, with three controls. C-301 upgrades the firmware to the fixed release. C-302 removes the appliance's management interface from the internet so it is reachable only from the management network. C-303 separates the VPN termination segment from the server segment, so a compromised appliance reaches a jump host, one step short of the order management database. C-301 removes this vulnerability; C-302 and C-303 reduce what the next one is worth. The work is 24 engineer hours for the upgrade and its out-of-hours window, and another 40 hours of firewall and segmentation change.

RISK-419 is accepted. The standby pair and its licences are a capital purchase, AUD 62,000 budgeted in the financial year beginning 1 July 2027, and no amount of engineering effort moves that this year. Accepting it is the honest answer, and the acceptance is what makes it a governed position instead of a gap.

The evidence. Each control names the artefact that proves it: change record CHG-7742 and the appliance version report for C-301, the firewall policy export and an external port scan for C-302, the tested connectivity matrix for C-303. Ana Ruiz reads those artefacts, not the ticket statuses.

The residual ratings and the verdicts. On 11 August 2026 Ana Ruiz validates against that evidence. RISK-418 comes down to likelihood 2 and impact 3, an exposure of 6, under the 8 the treatment plan aimed at and inside the technology threshold, and the entry is closed. RISK-419 comes down to likelihood 3 and impact 4, an exposure of 12, because C-302 has taken the management interface off the internet, so fewer of the advisories that arrive will land on a surface anyone outside can reach. That is still above the threshold of 9, and three points above the target residual the funded standby pair is expected to reach, which is precisely why it takes an acceptance rather than a closure.

Three days later Dan Whitfield, the CISO, accepts RISK-419 with three conditions: any advisory rated critical for VPN-01 is patched in an out-of-hours window within forty-eight hours of publication, on Marcus Feng's authority and without waiting for a change advisory board meeting; the management interface stays off the internet, which is C-302 carried across from the other entry; and the acceptance is re-read at the February 2027 budget checkpoint. The scope is VPN-01 alone. The acceptance expires on 30 June 2027, the day before the standby pair is funded.

From here both entries run on one chronology. RISK-418's lane ends at its closure; RISK-419's runs on through both quarterly reviews to the day the acceptance expires.

The audit walk. Eight months later, in April 2027, an ISO 27001 auditor opens the register and asks three questions. Clause 6.1.2 (c) asks who owns each risk: Marcus Feng on both rows, with Ana Ruiz recorded as the assessor, not the owner. Clause 8.2 asks when each was last assessed and for the documented results: 11 August 2026 for RISK-418, the day it closed, with the validation report behind it, and 14 February 2027 for RISK-419, after quarterly reviews on 14 November 2026 and 14 February 2027, with the next booked for 14 May 2027. The third question only ever gets asked after an incident, and it is answered in a line. Dan Whitfield accepted RISK-419 on 14 August 2026, under three conditions, until 30 June 2027.

Here is the second entry with every field filled, as the auditor opens it.

That record is the one to re-read: above appetite, with no treatment funded, and still defensible, because the acceptance names a person, states what has to stay true, and expires by itself.

The two entries finish in different places, having taken the same route: open, assessed, treated, validated. RISK-418 leaves the register at closed. RISK-419 sits at accepted and runs a loop the closed entry does not: reviewed each quarter, then back to assessment when the acceptance expires on 30 June 2027, or sooner if something significant changes.

Common mistakes

Eight failure modes turn a register into something nobody opens, and they share one root: the register gets treated as a list of worries instead of a record of decisions. Here is RISK-419 written both ways, field for field.

The eight below are the ways a row ends up written as a worry.

1. Entries are written as nouns. "Ransomware" is a category of threat, not a risk. A risk description carries a cause, an event and a consequence, with the threat, the asset, the method and the impact visible in the sentence.
2. Scores are recorded against a scale nobody published. If likelihood 4 means "possible" to one assessor and "expected this quarter" to another, the ranking is noise dressed as arithmetic. Clause 6.1.2 (b) asks that repeated assessments produce consistent, valid and comparable results, which is a requirement about the scale before it is one about the score.
3. Scores get inflated to win attention. A team that works out that only entries above 15 get funded will find everything it cares about scoring 16. The remedy is written descriptions at each point of the scale that make a 5 hard to claim, and an assessor who is not the person asking for the money.
4. A team is named as the owner, or nobody is. NIST keeps the owner, who is accountable for the risk, separate from the risk manager who runs the response day to day. A distribution list is neither, and clause 6.1.2 (c) asks for risk owners by name.
5. The residual score equals the inherent score on every row. When the two numbers never diverge, one of them is not being taken. Record the assessment made before the response and the one made after it, and label which is which.
6. Acceptance is used as a status. "Accepted" in a status column, with no acceptor, no rationale, no conditions and no expiry, is an unresolved risk with better paperwork.
7. Appetite and tolerance are used interchangeably. Appetite is the line leadership drew, in leadership's language; tolerance is the narrower, testable line the work is measured against. Report against the tolerance line, and keep the appetite statement above it, where it explains why the tolerance sits where it does.
8. The register is opened twice a year. Clause 8.2 asks for assessments at planned intervals and when significant changes are proposed or occur, and a register that moves only in audit season describes what the organisation believed in audit season.

A risk register compared with its neighbours

Two more records sit at either end of the register. A threat model is element-level analysis of one design, and it feeds the register wherever a threat cannot be removed by the design and gets accepted instead. A risk profile is the aggregated view leadership reads, and NIST builds it out of the registers underneath it.

Standards and references

NIST IR 8286r1, Integrating Cybersecurity and Enterprise Risk Management (18 December 2025). The most useful free document on this subject. Read Section 2.1 for appetite and tolerance, Figure 4 and Table 1 on page 12 for the template and its elements, Table 2 on page 30 for the four response types, Section 3 for the risk detail record, Section 3.2 for the three risk states, and Section 4 for the roll-up into an enterprise risk profile.

NIST SP 800-30 Rev. 1, Guide for Conducting Risk Assessments (September 2012). Read Chapter 2 for the definition of risk as a function of adverse impact and likelihood, and Chapter 3 for the four-step assessment process.

NIST SP 800-37 Rev. 2, Risk Management Framework for Information Systems and Organizations (December 2018). Read Chapter 3 for the seven steps: Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor. Authorize is where someone accountable accepts what remains, the governance move a register is built to record.

ISO/IEC 27001:2022, clauses 6.1.2, 6.1.3 and 8.2 (October 2022). Clause 6.1.2 and clause 8.2 are the pair a certification auditor reads a register against, and clause 6.1.3 carries the treatment side into the risk treatment plan and the Statement of Applicability. ISO sells its standards instead of publishing them, so the clause wording summarised here comes from dated secondary explainers and should be checked against a licensed copy before anyone quotes it word for word.

ISO 31000:2018, Risk management. Guidelines, and ISO/IEC 27005:2022, Guidance on managing information security risks. ISO 31000 is guidance and is not certifiable, so it obliges nobody by itself. It supplies the common vocabulary, and NIST names it as one of the frameworks that calls an exposure rating a level of risk. Both appear in the ASD ISM's further reading for risk management, alongside IEC 31010:2019, SP 800-30 Rev. 1 and SP 800-37 Rev. 2.

Australian Signals Directorate, Information security manual, September 2026 release. Read "Applying a risk-based approach to cyber security" for the six-step framework, and "Authorise the system" and "Monitor the system" for acceptance as a named officer's act. Its equivalents to a register are the authorisation package, the plan of action and milestones, and the annual report of a system's security status to its authorising officer.

The FAIR Institute, "What is FAIR" (read September 2026). The starting point for quantifying a register entry in money instead of a band, and the pointer to the Open Group standards behind it, O-RT and O-RA.

How Alvor helps

With Alvor, an organisation can run the register as the decision record this guide describes, with the decisions enforced by the product rather than remembered.

Every row carries its owner, the lifecycle stage it is waiting on, and a live verdict against the appetite the organisation set, so the list tells you where to spend the next hour. Appetite is a threshold per risk category plus an organisation default, and a Breaches tab lists what is over the line right now. The scale is the organisation's own: its own likelihood labels, its own impact dimensions and a narrative matrix that says in words what each combination means, carried into the export's Criteria sheet, so two assessors mean the same thing by a 4. The dashboard plots every risk on a heat map against those scales, beside the count above appetite and any review gone overdue.

Inherent and residual scoring are steps in the lifecycle, not a convention someone has to remember. A risk moves through Open, Assess, Investigate, Treat, Remediate, Validate and Close. Assess produces the inherent score. Treat produces the treatment plan with its rationale, timeline and cost, approved by the assessor before work starts. Validate reads the implementation evidence, measures what remains, and ends in a verdict: close, or accept with documented residual exposure.

Acceptance is a typed decision, and not a status field. The requester nominates an acceptor typed Business Owner, System Owner or CISO, only that person can decide, and the decision carries its conditions, its scope and an expiry date. The residual score is snapshotted at the moment of acceptance, so a later re-rating cannot quietly change what was agreed to. History is hash-chained, so the record of who decided what and when is not something a later edit can tidy up.

Rows do not sit on their own. A risk lists the assets it affects, chosen by live asset search at intake, and controls link to risks from the control's own Risks tab, so the treatment and the control are read from the same record. A Compliance finding escalates into the register and keeps the link on both records, and closing that risk marks the linked findings compliant. A design sign-off approved with conditions in Secure by Design creates a risk in the same transaction, a threat that cannot be mitigated is accepted as a risk with an owner and a rationale, and a continuity exercise or debrief finding escalates onto the same register.

The AI Assistant is bring-your-own-model, and it drafts and proposes while a person accepts or rejects every write on an approval card, so no risk is ever accepted or closed by a model.

Alvor runs as a dedicated single-tenant instance in the region you choose, on your own servers, or air-gapped. Risk Management covers the module in full.