How Is a Risk Register Created (and Kept Alive)?

A risk register is created by pulling raw risks out of the plan and the delivery team, writing each one as a cause, event and effect, assessing likelihood and impact against whatever scale your organisation already uses, naming one owner per risk, and agreeing a response with a date. That takes an hour. Keeping it current is the part that fails.

This guide covers building a register from scratch, what a basic one looks like, how a RAID log differs from a risk log, who maintains it, and whether anything obliges you to keep one. It is written for whoever has been handed the register and told to look after it.

How is a risk register created?

A risk register is created in one working session, not written up alone afterwards. The steps below are the version most commonly taught and used, in roughly this order.

1. Decide who reads it. A register for a steering group holds eight to fifteen live risks in business language. A register for the delivery team can hold forty in technical detail. Deciding this first stops the argument about granularity later.
2. Harvest before you meet. Every assumption and dependency in the plan is a candidate risk. So is every lesson from the last project of this shape, and every date you agreed without evidence.
3. Run the identification session with silent writing first. Give people five minutes to write risks on their own, then read them out. If you start with open discussion, the first speaker sets the frame and the quiet specialist never mentions the thing that actually sinks you.
4. Write each risk properly. A single noun such as “resourcing” is not a risk. The three-part risk statement covering cause, event and effect is what makes a row reviewable by someone who was not in the room.
5. Score likelihood and impact. Use the scale your organisation already uses, whether that is high, medium and low or a numeric range. There is no universal standard here, and the score’s only job is to sort the list. Ten minutes arguing whether an impact is a three or a four is ten minutes not spent on the response.
6. Name one owner per risk. A person, not a team and not a department. Two names on a row means nobody is watching it.
7. Agree a response and a next action. The common set is avoid, reduce, transfer or accept. Each row then needs one concrete next action with a date, because a response type on its own commits nobody to anything.
8. Set the review trigger before you leave the room. Which meeting, which date, who chairs it. This is the step that gets skipped, and it is the reason most of what follows in this article exists.

Steps three and six carry most of the quality. Teams that already plan in Slack or Microsoft Teams can run that session in Projan, which pulls the existing project plan in as context, asks each named owner what their first action would be, and exports the agreed actions to tools like Jira or Asana.

What does a basic risk register look like?

A basic risk register is a table with one row per risk and about six columns, sorted so the worst risk is at the top. Here is a fragment of a real-shaped one.

ID	Risk	L/I	Owner	Next action and date	Status
R-04	Supplier response times are running at two weeks, so the test environment may not be ready for user acceptance testing, pushing go-live back by a fortnight	H/H	Priya Shah	Escalate to supplier account director, 22 Aug	Open
R-07	Only one engineer knows the payments integration, so any absence in September would stop release work	M/H	Tom Reilly	Pair a second engineer through the next two tickets, 5 Sep	Open
R-11	Updated accessibility guidance may be published before launch, so three templates could need late rework	L/M	Dani Okafor	Confirm publication date at the September review	Accepted

Notice what makes those rows usable. Each one says what would go wrong and why, so a director who has never attended a project meeting can read it cold. Each has one name. Each has an action with a date, which is the only column that changes between reviews and therefore the only one that proves the register is alive.

Six columns is enough for most projects. If you want the full argument about which fields earn their place, the fields to include in a simple risk register and the ones to skip covers it. The short version is that a column nobody fills in makes the register look neglected even when it is not.

What are the three components of a risk register?

No standard defines three components, and anyone presenting a canonical three has made it up. What is true is that a register strips down to three things, and losing any of them makes the document decorative.

1. The risk, written so a stranger can assess it. Cause, uncertain event, effect on the project. This is the component people skimp on, and it is why so many registers read as a list of anxieties.
2. An assessment that ranks it against the others. Likelihood and impact, on any consistent scale. The purpose is ordering, not precision. You need to know which four rows matter this month.
3. A response with a named owner and a dated next action. Without this the register records worry rather than work.

Dates, categories, residual scores and links to mitigating actions are all useful additions. They are not what makes the difference between a register that changes behaviour and one that gets attached to a status pack unread.

How do you keep a risk register updated?

Keep a risk register updated by attaching its review to a meeting that already happens, giving it an audience who will ask about specific rows, and making the closing of a risk as routine as the opening of one.

Most registers are built in a good workshop and dead inside a month. The cause is almost always the same two omissions. There is no trigger, so review depends on somebody remembering. And there is no audience, so remembering has no consequence. Nobody opens a document because it exists. They open it because on Thursday morning someone senior is going to ask what has changed on row seven.

What works in practice:

1. Bolt the review onto an existing meeting. A standing thirty-minute risk meeting gets cancelled by week four. Ten minutes inside the weekly delivery meeting survives, because the meeting was happening anyway.
2. Review by exception. Read the top five, plus anything whose status or score changed since last time. Reading all forty in order is how attendance dies.
3. Have one senior person ask about a named row. Not “any risks?”, which reliably produces silence, but “R-07, what happened with the pairing?”. Rotate which row so nobody games it.
4. Close risks out loud. Give the reason (it happened, the window passed, we accepted it) and move it to a closed section rather than deleting it. A register that only ever grows stops being read, because the reader cannot tell which rows still matter.
5. Promote risks that have occurred. Once a risk has happened it is an issue and needs a recovery plan, not a mitigation. Leaving it in the risk list flatters the numbers and delays the response.
6. Re-read the register after any change of shape. A slipped date, a scope change, a supplier swap or a person leaving should each trigger a pass through the existing rows. New risks appear less often than existing risks change score.
7. Check the owners still work here. Owner turnover is the quietest way a register goes stale. Every row whose owner has moved on is effectively unowned.
8. Let risks be added between reviews. If new rows only appear at the review, people are storing them up, and the risks that matter tend to arrive on a Tuesday afternoon.

There is a fast diagnostic for a dying register: sort it by last-updated date. Anything that has not moved in three months is usually one of two things. It has already happened and become an issue nobody wanted to declare. Or it was never a risk, just a permanent condition of the work, in which case it belongs in your assumptions and should stop consuming review time. Either way the row is not doing the job it was written for.

What is the difference between a RAID log and a risk log?

A risk log tracks one thing, what might go wrong. A RAID log tracks four: risks, assumptions, issues and dependencies. The risk log is a section of the RAID log rather than a competitor to it.

	Risk log	RAID log
What it holds	Uncertain future events only	Risks, assumptions, issues and dependencies
Time frame	Future	Past, present and future in one document
What creates a row	Something that might happen	Something you assumed, something that went wrong, something you are waiting on, or something that might happen
Common failure	Grows without ever closing	The assumptions section is written once and never revisited
Suits	Small projects, and programmes where risk reporting is contractual	Projects with cross-team dependencies and a lot of unvalidated assumptions

The D is contested. Some organisations read it as decisions, some as dependencies, and a few teams swap the A for actions. None of those is wrong, but a log whose letters are undefined produces four columns of the same content. Write the definitions at the top of the document. If you are still choosing between formats, which tracker you actually need compares them against a RACI matrix.

The practical case for a RAID log is that assumptions and dependencies are where most risks come from anyway. Recording them in the same file means the risk conversation starts from the things you have already admitted you do not know.

Who is responsible for maintaining a risk register?

The project manager maintains the register as a document, but each row is maintained by its named owner. Those two jobs are routinely confused, which is how a project manager ends up guessing at updates for risks they cannot influence.

The sponsor sits above both. They are accountable for whether the current risk position is acceptable, which means they should be reading the register rather than receiving a summary of it. Where a risk crosses into another team’s territory, ownership sits with the person who can act, not the person who spotted it. Roles, accountability and handoffs on the risk register and RAID log works through the boundaries, including what happens at project close.

Is a risk register a legal requirement?

For most projects, no. There is no general legal duty in the UK to keep a project risk register, and nothing obliges a marketing campaign or a software release to maintain one.

Adjacent duties often force something equivalent. Employers must assess health and safety risks to workers and record the significant findings once they employ five or more people. Organisations processing personal data in high-risk ways must carry out a data protection impact assessment. Larger charities report on risk management in the trustees’ annual report. Regulated sectors, public bodies and listed companies carry their own requirements, usually about the organisation’s risks rather than any single project’s.

In practice the binding requirement is contractual rather than statutory. Funding agreements, framework contracts and public sector procurement routinely specify a risk register, a review frequency and a reporting format. Check the contract before you check the law. This is general guidance and not legal advice, so where a duty might apply, get it confirmed by someone qualified.

Frequently asked questions

What is another name for a risk register? Risk log is the most common alternative and means the same thing. You will also see risk repository, risk schedule, and RAID log where risks sit alongside assumptions, issues and dependencies. Risk matrix is used loosely as a synonym but properly refers to the grid of likelihood against impact, which is a scoring aid rather than the list itself.

Who is responsible for the RAID log? The project manager keeps the document, but each section has a different real owner. Assumptions belong to whoever made them and should be validated by that person. Issues belong to whoever is fixing them. Dependencies belong to whoever is waiting on the other team. If every line in all four sections names the project manager, nobody outside the role is engaged.

What is the difference between a risk and an issue? A risk might happen and an issue already has. The test is tense, not severity. If the supplier is late today, that is an issue and it needs a recovery plan. If the supplier might be late in October, that is a risk and it needs a mitigation. Keeping the two in separate lists stops the register filling with problems that need action now.

Should a small project bother with a risk register? Yes, but keep it to a handful of rows in whatever document you already use. Five real risks with named owners beat a forty-row template nobody opens. The value on a small project comes from having said the uncomfortable things out loud and written down who is watching each one, not from the format of the file.

Where should a risk register live: a spreadsheet or a project tool? A spreadsheet is fine and is what most teams use. Project tools give you history, notifications and an audit trail, which matter when the register is contractual or when several people update it. Whichever you pick, keep one copy. Registers pasted into status packs quietly become forks, and then two versions disagree about what is open.

Creating a register is an hour of structured conversation and a solved problem. Whether it is still worth reading in November comes down to two decisions made on the day you build it: which existing meeting reviews it, and who will ask about a named row. The rest is formatting.