Skip to content
Getting Digital

Risk Register

Also: project risk register, risk log, risk owner, risk response, issue log

A risk register is the project's living list of things that might happen and would matter, each with an estimate of likelihood and impact, a planned response, an owner and a review date.

Assessment. A register is measured by the decisions taken from it, and a register nobody has decided anything from is a list of worries with a table around it. Every line needs an owner who can act and a response somebody has funded; if a risk has neither, it is not being managed, it is being watched.

A risk is something that has not happened and might, and would affect the project if it did. The register captures each one with enough structure to act on: what it is, what would trigger it, how likely it seems and how much it would hurt, what the project will do about it, who is responsible for doing that, and when the entry will next be looked at. The estimates are rough and the ranking they produce is still the most useful thing in the document, because attention is finite and the register says where to spend it.

ResponseWhat it means on a projectExample
AvoidChange the plan so the risk cannot occurDrop the untested technology from the design
MitigateAct now to lower likelihood or impactRun a pilot before the full rollout
TransferMove the consequence to someone elseFixed-price contract, insurance, a penalty clause
AcceptDecide to live with it, and say soRecord the owner and the trigger that would change the decision
EscalateIt belongs above the projectTake it to the sponsor or the programme, and record that you did
  • One owner per line, and the owner is a person who can act, not a team or a role.
  • A trigger, so the owner knows what to watch for and when the risk has become an issue.
  • A funded response, because a mitigation without budget or time is a wish.
  • A review date, because likelihood changes as the project moves and a register reviewed only at the start describes a project that no longer exists.
  • A separate issue log, for things that have already happened; a register that mixes risks and issues is managing neither.

The entry-level certificates ask for the vocabulary and the response types; the professional ones test what a manager does when a risk on the register materialises, which is to move it to the issue log, execute the planned response, and tell the people the register said to tell. PRINCE2 makes the register a mandated product and the review a fixed step in each stage; PMI's body of knowledge treats risk as a performance domain running through the whole project. Both agree that the document is worthless unless it changes what somebody does.

In practice

A software project's register has sixty entries, each rated red, amber or green, and the steering group receives a count of reds each month. Nobody can say what the project is doing about any of them. The manager rewrites the register to twelve entries with a person's name on each, a response the sponsor has funded, and a date. One entry, the key supplier's delivery slipping, has a trigger, a missed milestone, a response, a second supplier on standby at a stated cost, and an owner, the procurement lead. When the milestone is missed the owner activates the standby the same day. The old register would have turned the entry from amber to red.

The test of a useful entry

Cover the likelihood and impact columns and read the line. If it still says who will do what, when, and what would trigger it, the entry is managing a risk. If all that is left is a description and a colour, it is describing one.

Often confused with

Security Risk Assessment
A security risk assessment ranks threats to an organisation's systems and decides what to protect. A project risk register lists what might derail one project and what will be done about it. Same likelihood-and-impact logic, different scope and different owners.
Critical Path
The critical path shows which activities cannot slip without consequence. The register records what might make them slip. A risk against a critical activity outranks the same risk against one with float, and the two documents are read together.
Change Control
Change control handles requests to alter the baseline. A risk that materialises often triggers a change request, but the register manages uncertainty and change control manages decisions; they are adjacent processes, not the same one.

Key takeaways

  • →A risk has not happened yet; an issue has. Keep two lists.
  • →Every line needs an owner who can act, a funded response and a review date.
  • →Judge the register by decisions taken from it, not by the count of reds.

Related concepts

Where this concept sits in the field

Certifications that test this

Vendor exams whose syllabus covers this concept: facts, cost and a preparation path on each page.

FAQ

How many risks should a register hold?
As many as have a named owner and a funded response, and no more. Twelve managed risks are worth more than sixty rated ones. Long registers are a sign that rating has replaced deciding.
Risk or issue: which list?
A risk might happen; an issue has. When a risk materialises it becomes an issue, moves to the issue log, and its planned response is executed. Keeping the two apart is what lets the register stay about the future.
Who owns a risk?
The person best placed to act on its response, who is frequently not the project manager. A supplier risk belongs to procurement, a technical risk to the lead engineer, a stakeholder risk to the sponsor. The manager owns the register, not every line in it.

Sources

The primary text this definition rests on. Read it before relying on this one.

  • Project Management Institute, The Standard for Risk Management in Portfolios, Programs, and Projects (2019)
  • PeopleCert, Managing Successful Projects with PRINCE2, 7th Edition (2023)
  • ISO 31000, Risk management, Guidelines (2018)

Last reviewed 13 September 2026 · Getting Digital