How to build and use a project risk register
Build a simple risk register for your NGO project: what to record, how to rate likelihood and impact, four response options and how to keep it alive.
Short answer
A risk register is a table that records each project risk, how likely it is, how much it would hurt, what you will do about it, who owns it and its current status. Build it at project start, rate each risk by likelihood and impact, choose a response, and review it at every team meeting. A register nobody reviews is only a document.
Key points
- Set up the register at project start-up, using risks from your proposal.
- Rate each risk by likelihood and impact.
- Choose a response: accept, avoid, reduce or share.
- Give every risk an owner and a review date.
- Review the register in every team meeting and before donor reports.
What is a project risk register?
A risk register is a living table of what could go wrong, how bad it would be, and what you are doing about it. The Catholic Relief Services (CRS) risk management guide describes it as a tool to document risks and how they are managed, including likelihood, impact, response and monitoring.
It is a team tool, not a form for the donor. The best registers are short, current and used in meetings.
When do you build it?
The CRS guide says the project team should set up a risk register at start-up. It should include risks identified during design that still matter, plus new risks that appeared after the proposal was written. Context changes between a proposal and the first month of work, so update the list.
What columns should a risk register have?
The CRS guide lists key fields. This table adapts them for a small NGO project.
| Field | What to write |
|---|---|
| Risk number and category | A short code and a type (security, funding, staffing, partner, legal, technical) |
| Description | What could happen, and the effect |
| Likelihood | Low, medium or high |
| Impact | Low, medium or high |
| Rating | Combine likelihood and impact |
| Response strategy | Accept, avoid, reduce, or share/transfer |
| Actions | Specific steps, with deadlines |
| Owner | The one person who watches this risk |
| Status | Active, closed, or has happened |
| Review date | When it was last checked |
The guide notes that category systems do not need to be perfect. Finding the risks matters more than sorting them.
How do you build the register, step by step?
- Gather the team. Include programme, finance, MEAL, field staff and partners, for different views.
- List risks. Start with the proposal's risk table. Ask: what could stop us reaching targets, harm people, lose funds or damage trust?
- Describe each risk clearly. Write "Road to Township B closes for three weeks, delaying distribution", not "access".
- Rate likelihood and impact. The CRS guide notes there is no magic formula, just knowledge and experience. A simple 3-by-3 chart is enough.
- Choose a response. See the next section.
- Assign an owner and a deadline for each action.
- Set a review rhythm. Put it on the agenda for your regular meeting.
What are the four response options?
The CRS guide names four ways to treat a risk.
- Accept. You tolerate the risk. This does not mean ignoring it, because it still needs monitoring.
- Avoid. You change or stop the activity to remove the risk.
- Reduce. You lower the likelihood or the impact, and may prepare a backup plan.
- Share or transfer. You pass part of the risk to a party better able to control it, for example through insurance or a contracted service.
The guide adds that every option except acceptance needs resources, so confirm that budget and people are available. Check that actions meet local laws and donor rules. Prepare a contingency plan for the most critical risks.
How do you keep the register alive?
- Review it in every team meeting. Spend ten minutes on the top risks. Our guide on project meetings shows how to keep this short.
- Add new risks as they appear. Field staff are often first to see them.
- Close risks that have passed, and note when.
- Move realised risks to your issue log and update the response.
- Review before each donor report, and use it to explain delays honestly.
- Keep old versions. They show what you knew and when.
What mistakes should you avoid?
- Copying the proposal's risk table and never touching it again.
- Vague risks such as "security situation". Name the specific event and the effect.
- No owners. A risk with no owner is not managed.
- Too many risks. If you list 80, you will review none.
- Writing sensitive details in a widely shared file. In insecure contexts, keep security risks in a restricted version and share a summary.
- Treating the register as a compliance task. It exists to help you act early.
How EMPO can help
EMPO is a trusted, Yangon-based training and consultancy provider and one of Myanmar's leading names in practical NGO training, with 1,200+ people trained and 15 partner organisations. Our Project Management and organisational development support, delivered online or in person across Myanmar in English and Burmese, can help your team build a working risk register. See our services or contact us.
Sources
- Risk Management How-To Guide — Catholic Relief Services, Institutional Strengthening Resources
Questions people ask
How many risks should a register have?
Enough to cover the real threats, but few enough to review in ten minutes. Many small projects keep 10 to 20 active risks.
Should the risk register be shared with donors?
Often yes, in the form your agreement requires. Keep sensitive security details in a restricted version.
What is the difference between a risk and an issue?
A risk might happen. An issue has already happened. When a risk occurs, move it to your issue log and decide the response.