How to Create a Project Risk Register: A Practical Example
Seven steps to a register people actually use, a complete worked example, and one risk followed from identification through to escalation.
Quick answer
A project risk register records things that might go wrong, what would happen if they did, what is already in place to prevent or limit them, what further action is planned, and who is watching each one. It is a working document rather than a planning formality, which means it has to be reviewed as the project changes. A register written once and never reopened does nothing at all.
BSB40920 Certificate IV in Project Management Practice
Delivered by Vanguard Business Education (RTO 91219)
- Price: $1,970 AUD course fee, paid as 2 monthly payments of $985, or from $85 a fortnight on a payment plan (plans total $1,970 to $2,210)
- Payment plans: 2 monthly payments of $985 ($1,970 total), 3 monthly payments of $684 ($2,052 total), 6 monthly payments of $358 ($2,148 total), or 26 fortnightly payments of $85 ($2,210 total)
- Duration: self-paced, up to 12 months to complete
- Delivery: 100% online, self-paced, with qualified trainer support
- Included: qualified trainer support, all learning resources, assessments and SmartCoach™ learning assistance
- Entry requirements: no formal entry requirements
- RPL available: yes, Recognition of Prior Learning and credit transfer may apply
- Nationally recognised: yes, AQF Level 4
Enrol or find out more about the BSB40920 Certificate IV in Project Management Practice
Key takeaways
- A risk might happen. An issue already has. They need different responses.
- Vague entries cannot be acted on. Write the cause, the event and the effect.
- Rate against the controls you already have, and label any post-action rating as anticipated.
- Every risk needs one named owner. “The team” is not an owner.
- A trigger turns a register from a list into something that tells you when to act.
What is a project risk register?
A single list of the things that could affect your project, with enough detail attached that someone could act on each one.
Its practical purpose is not to prove you thought about risk. It is to make uncertainty visible early enough to do something cheap about it, rather than something expensive about it later. Spotting in week one that your only trained operator takes leave in week six costs a conversation. Spotting it in week six costs the schedule.
For a small project this is five or six lines you look at weekly. It does not need software, a methodology or a committee.
What is the difference between a risk and an issue?
A risk might happen. An issue already has.
| Risk | Issue |
|---|---|
| The supplier might miss the delivery date | The supplier has confirmed a two week delay |
| Attendance might fall short of the target | RSVPs closed at 14 against a target of 25 |
The distinction matters because the response differs. A risk is managed: you reduce its likelihood, limit its consequence, or decide to accept it and watch. An issue is resolved, usually by someone with more authority and usually with less time available.
When a risk occurs it becomes an issue. Note that in the register, so the record shows what was foreseen and what happened, rather than quietly deleting the line.
The seven steps
Step 1: Identify risks against the plan
Work through the project plan rather than brainstorming in the abstract. Go along the tasks, the dependencies, the people, the suppliers, the costs and the assumptions, asking what would have to go wrong for each one to fail.
Assumptions are the richest source. Every assumption is a risk that has not been written down yet. Involve the people doing the work, because they know where it breaks.
Step 2: Write a specific risk statement
Three parts: the cause, the uncertain event and the potential effect.
Useful: “Because two of six staff are rostered on client work during the training week, they may miss training, which would delay go-live.”
The second version tells you who to talk to and what to do. The first tells you nothing, and a register full of first versions is why registers get abandoned.
Step 3: Assess likelihood and consequence
Use whatever scale your organisation has agreed. If there isn’t one, a simple three point scale is enough for a small project, provided you write down what each level means. Consistency across entries matters far more than how sophisticated the scale is.
Step 4: Record existing controls and further responses
Separate what is already in place from what is still proposed. A control that exists today reduces your exposure now. A control someone intends to implement next month does not, and conflating the two is how registers end up describing a project that is safer than the real one.
A response either reduces the likelihood of the event, or limits the consequence if it happens. Knowing which one you are attempting is useful.
Step 5: Assign ownership and dates
One named person per risk, responsible for watching it. If an action is planned, name who is doing it and by when. Risks owned by “everyone” are watched by no one.
Step 6: Identify triggers and escalation points
A trigger is the observable thing that tells you to act. “RSVPs below 20 by Day 15” is a trigger. “Keep an eye on attendance” is not.
Decide in advance what would need a decision from someone more senior, and say so. That way the escalation happens because a threshold was crossed, not because someone finally panicked.
Step 7: Review and update
Set a review rhythm and keep it. At each review: close risks that have passed, update ratings where controls have been implemented and shown to work, add new risks the project has created, and move anything that has occurred into issues.
Worked example: a small customer event
The same fictional project used in our planning and budget guides: a four-partner accounting firm running a one hour information session for around 40 invited small business clients. Register as at Day 8, just after invitations were sent.
| ID | Cause, event and consequence | Likelihood | Consequence | Priority |
|---|---|---|---|---|
| R1 | Because the venue holds provisional bookings, the room may be released before final confirmation, meaning the session would need rescheduling and invitations reissuing | Low | High | Medium |
| R2 | Because the caterer is being booked at short notice, they may be unable to confirm final numbers in time, meaning catering would need to be arranged elsewhere at higher cost | Medium | Medium | Medium |
| R3 | Because the topic is narrow and clients are busy at this time of year, attendance may fall below 25, meaning the session’s purpose would not be met | Medium | High | High |
| R4 | Because the AV equipment is hired and untested in the venue, it may fail on the day, meaning the presentation could not be shown as planned | Low | Medium | Low |
| R5 | Because only one person is preparing and delivering the content, illness or a client emergency may make them unavailable, meaning the session would be postponed | Low | High | Medium |
| ID | Existing controls | Further action | Owner | Trigger or review date |
|---|---|---|---|---|
| R1 | Written booking confirmation received Day 3 | Reconfirm with venue one week before the session | Practice manager | Day 15 |
| R2 | Caterer has provided a written quote and holds the date | Identify one alternative caterer who could cover 30 at short notice | Practice manager | Trigger: caterer has not confirmed by Day 19 |
| R3 | Invitations sent to 40 clients Day 8, with a response date | Send a reminder to non-responders; prepare a second invitation list if needed | Practice manager | Trigger: fewer than 20 RSVPs by Day 15 |
| R4 | Hire includes same-day replacement | Test equipment in the venue during the rehearsal; bring printed slides as backup | Senior accountant | Day 12, at rehearsal |
| R5 | Content and slides stored centrally, not on one laptop | Brief a second partner well enough to deliver the session if required | Managing partner | Day 18 |
Ratings reflect the existing controls only. Where a further action would change a rating, that rating is anticipated until the action has been implemented and reviewed.
One risk, from identification to escalation
Follow R3, low attendance, because it shows what a register is for.
At the Day 15 review the practice manager does not simply note that numbers are low. The trigger was set in advance, it has been crossed, and that was agreed to mean a decision is needed rather than more waiting. The register says who makes it.
The managing partner decides to extend invitations to 20 clients in an adjacent segment, accepting that RSVPs will now close later and that catering numbers will be confirmed closer to the date. R3 stays open with its likelihood revised, and a new risk is added covering the compressed catering timeline. By Day 19 attendance has reached 28.
Common mistakes to avoid
- Vague descriptions. “Supplier issues”, “staff availability”, “budget”. Nobody can act on a category.
- Inconsistent ratings. Rating one risk against existing controls and the next against hoped-for ones makes the priorities meaningless.
- Missing owners. Every risk needs one name. Not two, not a team.
- Proposed controls treated as done. The most dangerous of the five, because the register then describes a project safer than the one you have.
- Never reviewed. Written during planning to satisfy a requirement, never opened again. Exposure changes as the project moves.
- Too many entries. Thirty risks is a document. Six is a tool. Record what could genuinely affect the project.
Create your first register
Use the structure from the worked example: ID, cause and event and consequence, likelihood, consequence, priority, existing controls, further action, owner, trigger or review date. Two tables if it is easier to read, sharing the same IDs.
- Open your project plan and go through the tasks, dependencies, suppliers, people, costs and assumptions.
- Write five or six risks as cause, event and effect. Resist the urge to list twenty.
- Define your likelihood and consequence levels in writing before you rate anything.
- Rate each risk against the controls that exist today.
- Add further actions where a risk warrants it, with a name and a date.
- Set a trigger for anything you would otherwise just worry about.
- Put a weekly review in the calendar and keep it.
A register does not remove risk. Things will still go wrong on a project with a good register. What changes is that you find out earlier, you have already decided what to do, and someone has already agreed who decides.
This sits alongside the project plan and schedule and the budget tracker for the same example project.
Frequently asked questions
What is a project risk register?
A risk register records uncertain events that could affect a project, what would happen if they occurred, what is already in place to prevent or limit them, what further action is planned, and who is watching each one. Its purpose is to support decisions during the project, which means it only works if it is reviewed.
What is the difference between a risk and an issue?
A risk might happen. An issue already has. The supplier might miss the delivery date is a risk; the supplier has confirmed a two week delay is an issue. When a risk occurs it becomes an issue and moves out of planning and into action, which is a different response and often a different person.
How do you write a good risk statement?
Include the cause, the uncertain event and the potential effect. Staff problems is not a risk statement because nobody can act on it. Two of six staff are rostered on client work during the training week, so they may miss training, which would delay go-live is something you can do something about.
How do you rate project risks?
Use whatever scale your organisation has agreed, applied consistently. If you have none, a simple three point scale for likelihood and consequence is enough for a small project, provided you define what each level means in writing. Consistency between entries matters more than the sophistication of the scale.
How often should a risk register be reviewed?
At a regular rhythm matched to the project, and whenever something significant changes. For a short project a weekly look is usually right. A register written once and never reopened is the most common failure, because exposure changes as the work progresses and completed actions should change the ratings.
Practise this on a full project
Risk identification, assessment and treatment are part of the practical work in the Certificate IV, assessed on a register you build and defend rather than questions you answer.
Ask About the CourseSee the units and assessments on the BSB40920 Certificate IV in Project Management Practice course page.
