Home›Blog›What to include in a risk register, and where each field comes from
FundamentalsBeginner
Published September 13, 2026 · By Vincent KENNEL
What to include in a risk register, and where each field comes from
Every risk register carries different columns, and nobody can say which text prescribes them. This article traces each field back to the referential that asks for it, and to the moment in the process when it gets filled.
In brief
A risk register records a project's identified risks and controls the process that handles them. It fills in layers: each step of the process deposits its own fields, from the identifier and the description through to the review dates. No standard in force fixes that list, and the format is declared in the risk management plan.
At a gate review the risk register is asked for, and it arrives. Its columns are never quite the ones carried by the last project, and nobody in the room can say which text prescribes any of them. The question has an answer. It is not the one that most published lists suggest.
What a risk register is
Two reference definitions, and the older one is the more demanding. ISO Guide 73:2009, a text since withdrawn, defined the risk register at clause 3.8.2.4 as a record of information about identified risks. Godfrey, writing for CIRIA in 1996, had already gone further: the register is "a means of recording and controlling the risk management process". The second verb is the one that matters. A register is not an inventory of what has been found, it is the instrument through which the process is controlled.
The most specialised referential is the least prescriptive. The Standard for Risk Management in Portfolios, Programs, and Projects, first edition, 2019, calls the register "a repository in which outputs of risk management processes are recorded". The term appears five times across 194 pages, and no list of fields is given anywhere in them.
The name is not the object, and four independent referentials say so. ISO Guide 73:2009, again a withdrawn text, noted that "the term 'risk log' is sometimes used instead of 'risk register'". The PMBOK Guide, seventh edition, 2021, states at 4.6 that "the terms log and register are sometimes used interchangeably". The APM Body of Knowledge, eighth edition, 2025, records the register as "used interchangeably with 'risk log' and 'risk repository'". NF ISO 21502:2021 leaves it open at 7.8.2, where the record of risks "can be referred to as a 'risk register', 'risk log' or any other term used within an organization". The common belief that a register and a log are two different objects does not survive the texts.
One boundary with a neighbouring subject. The PMBOK Guide, sixth edition, 2017, separates at 11.2.3.2 the register, which carries individual risks, from the risk report, which carries overall project risk and the synthesis made of it. That distinction is not developed in this article.
What it contains, and when each field is filled
The principle was stated once, in 2004, and it is rarely shown. The PMBOK Guide, third edition, 2004, put it at 11.2.3.1: "the risk register ultimately contains the outcomes of the other risk management processes as they are conducted". A register does not get filled in one sitting. It widens. Each step of the process deposits its own fields, and that is why published lists differ from one another: they photograph the object at different moments.
No standard in force fixes the list of fields, and each referential proposes its own. Four readings establish it. ISO 31073:2022, the vocabulary in force, does not carry the term at all. ISO 31000:2018 never uses it across its twenty-four pages. NF ISO 21502:2021 names it only in a note. The 2019 PMI standard gives it a single glossary sentence.
The most telling measurement sits inside one standard. NF ISO 21502:2021 gives, at 7.9.2, the complete content of the issue register: a title or name, the type of issue, the date it was identified, the description, the priority, the impact summary, the actions to be taken and the current status. Clause 7.8, on risks, gives none.
Identification, which adds identity, description and ownership
The PMBOK Guide, sixth edition, 2017, lists at 11.2.3.1 three entries required at the end of risk identification and eight optional ones, "depending on the risk register format specified in the risk management plan". That conditional clause is the whole point. The format is a parameter declared in the risk management plan and decided project by project, which is where the idea of a standard set of columns comes apart.
One element belongs to the text rather than to any list of fields: "a structured risk statement may be used to distinguish risks from their cause(s) and their effect(s)".
Godfrey, for CIRIA in 1996, asks for two things as a minimum in Tool Box T2.2, describing the risk that exists and recording the possible reduction actions, and offers ten further items as options. WSDOT, an American state agency, runs a form of fifteen fields at 2-2.3 of its guide of May 2026.
From two as a minimum in 1996 to fifteen in service in 2026, the gap is not a disagreement about substance. It is a difference of context and of maturity. What stays constant across the three is narrower, and more useful: identify, describe, attribute.
Assessment, which adds the criteria and the ranking
Four referentials give four different answers, and the pair repeated everywhere is in the minority.
NF ISO 21502:2021 asks at 7.8.3 for three criteria, probability, consequence and proximity. The same clause notes that consequence can be referred to as impact and probability as likelihood, and it adds a requirement no grid carries: "interrelations and dependencies between individual risks should be assessed".
PRINCE2 7, 2023, asks for four. It keeps proximity, "an estimate of how near in time a risk might occur", and adds velocity, "an estimate of how quickly a risk would have an impact on objectives should it occur".
The PMBOK Guide, sixth edition, 2017, adds a priority ranking and a named owner at 11.3.3.1, and sends low-priority risks to a watch list. ECSS-M-ST-80C, 2008, works on severity, likelihood and a risk index.
The probability and impact pair that general-audience content repeats is therefore a minority position among the referentials. That is a count, not a criticism.
Treatment, which adds the response, its owner and its economics
PRINCE2 7, 2023, is the only text here that separates the risk owner from the risk action owner. That separation settles a frequent confusion: whoever owns a risk is not necessarily whoever carries out the response. The same list records the planned residual probability and impact, which is to say what the response is expected to buy.
NF ISO 21502:2021 names seven measures at 7.8.4: accept, avoid, mitigate, transfer, use contingency, exploit and enhance. The use of contingency appears there as one measure among seven. How a contingency is held, authorised and consumed is a financial mechanism, and it is the subject of a separate article.
Godfrey, for CIRIA in 1996, had already asked in Tool Box T2.2 for the cost of the action, who owns it, when it happens, whether the mitigation is practicable, what risk remains afterwards and what the benefit is worth. From the first template onward, the register carries the economics of the response, and not only the response.
Monitoring, which adds dates
PRINCE2 7, 2023, records when an entry was logged, when it was last reviewed, when its actions fall due, and what has been recorded against it.
Godfrey, for CIRIA in 1996, is the one text here that states a cadence: review the register "at about six month intervals or prior to any major decisions or changes to the project", with the opposite warning attached in the same breath, "paralysis by analysis".
Closure is a coda, and a single referential carries it. The APM Body of Knowledge, eighth edition, 2025, holds that all risks are closed, "when they have occurred or when there is no possibility of them occurring".
Dates are what separate a register that is kept from a list that merely exists.
What qualifies for entry
Entry is a decision, and it is settled against a declared threshold. The Standard for Risk Management in Portfolios, Programs, and Projects, first edition, 2019, defines the risk threshold at 2.1.6 as the "minimum level of risk exposure for a risk to be included in the risk register".
WSDOT turns that into a procedure at 2-3 of its guide of May 2026, in five steps: define what counts as a significant project risk, establish thresholds by setting a minimum cost value and time duration, focus, document, assess. And it attaches a reservation of its own: "low probability, High-impact risks should still be considered significant". A purely quantitative threshold would let through precisely the rare and severe event, and it is the agency itself that says so.
The opposite rule matters as much. PRINCE2 7, 2023, asks reviewers to "review and check whether the risk register includes any entries which are not uncertain". What has already happened has left the register. WSDOT draws the same line in its own words at 2-3: "differentiate Challenges from Risks, not every issue qualifies as a risk event. Risks involve uncertain events or conditions that could impact project objectives. Challenges are known obstacles." What separates a risk from an issue is the subject of a separate article.
An entry is a sentence, not a title. The risk metalanguage of the 2019 PMI standard at X6.2, PRINCE2 7, 2023, and WSDOT at 2-3.1 all give the same shape, a cause then an event then an effect: "as a result of cause, risk may occur, which would lead to effect".
What it is for on a contract project
Signed. ECSS-M-ST-80C, 2008, puts on the risk sheet, in Annex D, the line "Agreed by project management", with a name, a signature and a date. A register that is signed is a register that can be produced.
Two objects, not one table. Two independent traditions state the risk sheet and the summary table explicitly. ECSS-M-ST-80C, 2008, treats the risk register as one sheet per risk, and the table with one line per risk as a second document, the ranked risk log. On the French side, NF X50-115:2017 lists in its annex a risk typology, a risk sheet, a summary table and the follow-up of prevention actions, and the AFITEP proceedings of 29 May 2007 name prioritised risk registers and drafted risk sheets among the outputs of assessment. The British template of 1996 already carried the structure, Godfrey's CIRIA guide giving two distinct tables, one for risk identification and one for risk assessment, each with its own authorship and approval box. The belief that a risk register is a spreadsheet is settled by structure, not by a preference for a tool.
A management deliverable, ranked with the schedule. NF X50-115:2017 lists at 5.1.5, under the name register of threats and opportunities, the project plans, the schedule, that register, the project organisation, the quality plan and the treatment of non-conformities.
Controlled and auditable. Hopkin, in Fundamentals of Risk Management, fourth edition, 2017, notes in chapter 7 that "in some organizations, the risk register is given the status of a controlled document to be used by internal audit as one of the key reference documents", and that "risk control activities should be described in sufficient detail for the controls to be auditable".
Checked at a gate. The OGC Gateway Review handbook, version 2, April 2002, treats the register as an object of gate review, something an external examiner comes to verify: "potential major risks (including strategic, political and legislative risks) should be documented in the risk register".
And the point that applies first. WSDOT asks, for design-build, to "clarify whether risks fall to the owner, contractor, or both". PRINCE2 7, 2023, goes further: "in a commercial context, there may be a need for more than one risk register. Some project risks could be unique to only one party that may have good reasons for not making the risk register visible to the other party." In front of a register on a contract, the first question is whose it is and who sees it, well before which columns it carries.
Whether such a register serves reporting or steering is a distinction of its own, and it is treated in a separate article.
How to read the matrix that goes with it
The size of the grid is a parameter
The PMBOK Guide, sixth edition, 2017, describes at 11.3.2.6 "typically five levels" in a detailed approach and "usually three" in a simple one, puts threats and opportunities on the same matrix, and allows one matrix per objective.
Who fixes the grid is written down. ECSS-M-ST-80C, 2008, has the scheme established per project at 5.2.1.2 f) and h). The PMBOK Guide, sixth edition, 2017, has it fixed by the risk management plan at 11.1.3.1.
And there is a demonstration by example. WSDOT presents the same register first on a two by two matrix and then on a five by five one, at Exhibits 3-6 and 3-7. The matrix is not a universal object. It is a declared parameter.
Reading a cell
ECSS-M-ST-80C, 2008, is the one text here that attaches a prescribed course of action to each band. Severity runs from 1 to 5, negligible, significant, major, critical, catastrophic. Likelihood runs from A to E, minimum, low, medium, high, maximum. The risk index is described as a combination of severity and likelihood, and each band reads as an instruction. At the top, change the baseline or the process, which ECSS words as "unacceptable risk, implement new team process or change baseline". In the middle, aggressively manage. At the bottom, control and monitor, on a risk ECSS calls acceptable.
A cell does not give a mark. It gives a magnitude with a course of action attached. The matrix is there to decide what to do, not to rank.
What the matrix does not carry
Two axes are not the whole appraisal, and the referentials say so themselves. The PMBOK Guide, sixth edition, 2017, states at 11.3.2.6 that beyond two parameters "the probability and impact matrix cannot be used", and sends the reader to a bubble chart whose example crosses detectability, proximity and impact. Three dimensions do not fit in a grid.
Nor is there a standard graduation to fall back on. ECSS-M-ST-80C, 2008, works five by five with letters and numbers, the PMBOK Guide, sixth edition, 2017, offers three levels or five, and WSDOT shows one register on two different grids. A grid is chosen and declared, it is not inherited.
A two-axis matrix is not the whole appraisal. The referentials ask for more than two things, proximity in one case and velocity in another, and a grid has room for two. What does not fit on the axes still has to live somewhere, and that somewhere is the register.
Where the risk register comes from
What follows is a documentary chronology, not an origin. It says which texts carry the term and when, and nothing about when the practice began.
The most striking measurement first. Project and Program Risk Management, edited by Wideman and published by PMI in 1992 as a preliminary issue for trial use and comment, is a volume devoted entirely to project risk and opportunity. The term risk register does not appear in it once. The same count comes back at zero on the 1987 Project Management Body of Knowledge, on Wideman's Framework of 1991, on the eleven pages of the APM mini guide of March 1992, on the PMBOK Guide, 1996 edition, and on Kähkönen's PMI paper of 1997.
The first identified text carrying the term is Williams, in the International Journal of Project Management, volume 12, number 1, pages 17 to 22, 1994. Its own abstract places it in "the mandatory project-definition phase in defence projects". And the same abstract forbids reading it as an origin: "recently, the centrality of the risk register in risk-management infra-structures was noted". The artefact precedes the text that names it.
Two years later, in the same country, a different world. Godfrey's CIRIA guide of 1996 gives the first definition, the first Tool Box and the first templates, in the wake of the Latham report on British construction. Defence procurement on one side, construction on the other, and neither citing PMI. No piece links the two, and this article does not link them either.
Year
Piece
What it shows
1987
Project Management Body of Knowledge, PMI
The term does not appear
1991
Wideman, A Framework for Project and Program Management Integration, PMI, preliminary edition
The term does not appear
1992
Project and Program Risk Management, PMI, preliminary issue
The term does not appear, in a volume devoted to risk
1992
Project Risk Analysis and Management, APM mini guide, March 1992
The term does not appear
1994
Williams, International Journal of Project Management, volume 12, number 1
First identified text carrying the term, in defence projects under contract
1996
Godfrey, CIRIA SP125
First definition, first Tool Box, first templates, in British construction
1996
PMBOK Guide, 1996 edition, PMI
The term does not appear
2000
PMBOK Guide, 2000 edition, 11.5.3.1
Enters as a synonym of the risk response plan, at the end of the process
2002
OGC Gateway Review handbook, version 2
Already an acquired object in British government, used without definition
2004
PMBOK Guide, third edition, 11.2.3.1
Born at identification, and a component of the project management plan
2009
ISO Guide 73, since withdrawn
First and only ISO normative definition
2021
PMBOK Guide, seventh edition, 4.6
Ten occurrences, against 165 in the sixth edition
2022
ISO 31073
The vocabulary in force does not carry the term
The register was born a register of threats. Godfrey's guide of 1996 defines risk in the commonplace way, as the chance of an adverse event, with no opportunity in it. Every later referential named here takes opportunity in.
And the curve explains the lists. In 2000 the register enters the PMBOK Guide as a synonym of the risk response plan, born at the end of the process. In 2004 the third edition has it born at identification and made a component of the project management plan. The seventh edition, 2021, carries it among the artefacts, with ten occurrences against 165 in the sixth edition, 2017. Published lists differ because they were written at different points on that curve.
In short
Three questions settle a register faster than any column count, and they come in this order.
Whose register is this, and who sees it. On a contract, ownership and visibility come before content.
Which text prescribes each of its columns, with its edition, and where that choice is written down. The last part has a fixed answer, the risk management plan, and a column that cannot be traced to a text is a column nobody can defend in review.
When was each line last reviewed. A register without dates is a list.
None of the three requires a standard that does not exist.
Stop guessing. See the real impact.
Frequently asked questions
Q.Is a risk register mandatory?
It depends on the referential. No ISO risk management standard in force names it: neither ISO 31000:2018 nor ISO 31073:2022 carries the term. NF X50-115:2017 treats it instead as a management deliverable.
Q.What is the difference between a risk register and a risk management plan?
The plan declares, the register records. The PMBOK Guide, sixth edition, 2017, makes the format of the columns a parameter written into the risk management plan, declared project by project.
References
AFITEP - Hervé Courtot - Le management des risques dans les projets - Pratiques et tendances - Journée du 29 mai 2007
AFNOR - NF X50-115 - Management de projet et de programme, présentation générale - Décembre 2017
AFNOR - NF ISO 21502:2021 - Recommandations sur le management de projet - Juin 2021
APM - APM Body of Knowledge - 8th edition, 2025
APM - Project Risk Analysis and Management (mini guide APM) - March 1992, republished January 2000
International Journal of Project Management - Terry M. Williams - Using the risk register to integrate risk management in project definition - vol. 12, no. 1, p. 17-22, 1994
ISO - ISO 31000:2018 - Management du risque, lignes directrices - 2nd edition, 2018
ISO - ISO 31073:2022 - Risk management - Vocabulary - 1st edition, 2022
ISO - ISO Guide 73:2009 - Management du risque, vocabulaire - 1st edition, 2009
Kogan Page - Paul Hopkin - Fundamentals of Risk Management: Understanding, Evaluating and Implementing Effective Risk Management - 4th edition, 2017
Office of Government Commerce - OGC Gateway Review handbook, gates 0, 4 and 5 - Version 2, April 2002
PMI - Kalle Kähkönen - A Framework for Applying Various Project Risk Management Methods and Tools - 1997
PMI - R. Max Wideman - Project and Program Risk Management: A Guide to Managing Project Risks and Opportunities - Preliminary Issue for Trial Use and Comment, 1992
PMI - Project Management Body of Knowledge - 1987
PMI - R. Max Wideman - A Framework for Project and Program Management Integration - Preliminary Edition for Trial Use and Comment, 1991
PMI - The Standard for Risk Management in Portfolios, Programs, and Projects - 1st edition, 2019
PMI - A Guide to the Project Management Body of Knowledge (PMBOK Guide) - 2000 Edition - 2000
PMI - A Guide to the Project Management Body of Knowledge (PMBOK Guide) - 1996 Edition - 1996
PMI - A Guide to the Project Management Body of Knowledge (PMBOK Guide) - Third Edition - 2004
PMI - A Guide to the Project Management Body of Knowledge (PMBOK Guide) - 7th Edition - 2021
PMI - A Guide to the Project Management Body of Knowledge (PMBOK Guide) - 6th Edition - 2017
WSDOT - Guide for Project Risk Management and Risk-Based Estimating - May 2026
