RACI vs RAID vs Risk Register: Which Do You Need?

RACI and RAID answer different questions. A RACI matrix allocates work and decision rights across roles: who is responsible, accountable, consulted and informed for each task. A RAID log is a running record of risks, assumptions, issues and dependencies. A risk register is one quarter of RAID, kept on its own when risk reporting has a separate audience.

The three get conflated because they all arrive as a spreadsheet with coloured headers, and because a new project manager is often asked for all of them in the same fortnight. This guide covers what each artefact is for, when a RAID log earns its place, what a risk register goes by elsewhere, and how to avoid holding the same risk in two files.

What is RACI vs RAID?

RACI is about allocation. RAID is about uncertainty. A RACI matrix is a grid of tasks against people that exists to stop two people doing the same job while nobody does the third one. A RAID log is a list of things that might go wrong, have already gone wrong, are being taken on trust, or sit outside your control entirely.

Both acronyms get expanded loosely, so here they are in full:

• RACI: Responsible (does the work), Accountable (answers for the outcome, one name only), Consulted (asked before the decision), Informed (told after it).
• RAID: Risks (might happen), Assumptions (believed without evidence), Issues (already happening), Dependencies (something outside the team has to land first).

	RACI matrix	RAID log	Risk register
Question it answers	Who does what, and who decides	What could stop us, and what are we relying on	What could go wrong, how badly, and who is watching it
Shape	Tasks down the side, roles across the top	Four grouped lists, each item dated and owned	One list, scored and reviewed
Time it points at	Now: the current allocation of work	Past, present and future at once	Future, until a risk becomes an issue
Changes when	The team, scope or governance changes	Weekly, throughout delivery	Weekly to monthly, plus after any scope change
Who actually reads it	The delivery team, and anyone unsure who to ask	The project manager and the delivery team	Sponsors, steering groups, sometimes audit
How it fails	Filled in without the people it names	Four lists that grow and never close	Written for reporting rather than for action

None of the three is a standard requirement. Plenty of well run projects use a RACI and no RAID log, or a RAID log and no RACI, and some organisations mandate all three because a governance framework in a shared drive says so. Pick them for what they tell you, not for whether they came with the template you inherited. RACI has its own failure modes, mostly too many people in the C column and more than one name in the A column, and the golden rules for building a matrix that survives contact with a team are worth reading before you draw the grid.

When would you use a RAID log?

Use a RAID log when things get forgotten between meetings and when a meaningful part of what could stop you sits outside your team. It is a memory device for a project with more moving parts than one person can hold, and it is close to useless on a project small enough to keep in your head.

The specific triggers worth watching for:

• Dependencies on other teams or suppliers. The moment your plan contains the phrase “once platform have finished their migration”, you have a dependency that needs a date, an owner and a check-in.
• Assumptions doing structural work. If the budget assumes the client provides content by a fixed date, that belief is holding up the schedule and should be written where the client can see it.
• A handover coming. Whoever takes over needs the reasoning, not only the plan. A RAID log carries the reasoning.
• Governance that asks questions. Steering groups ask what has changed since last month. A log answers that in two minutes; a memory does not.

Skip it when the work is short, the team is one room, and nothing you need is being built by someone else. Adding a RAID log to a three week internal task creates an artefact that gets populated once at kickoff and then quietly abandoned, which is worse than not having one, because everyone assumes it is being maintained.

What is the name of the risk register?

The risk register is also called the risk log, and the two names describe the same document. PRINCE2 uses risk register and keeps a separate issue register for things that have already occurred. Some organisations say risk log, some say risk and issue log, and a fair number of teams just call it the risks tab. The name matters only for one reason: when someone asks you for the risk log and you send them the RAID log, they get four lists when they wanted one.

What goes in it is more contested than what it is called, and the honest answer is fewer columns than most templates offer. If you are building one now, the fields worth keeping and the ones that only ever get filled in once are set out separately. The entry itself matters more than the scoring: a register full of one word risks like “resourcing” cannot be acted on by anyone who did not attend the meeting where it was raised, which is why writing the risk as a cause, an event and an effect does more for a register than any heat map.

Which of the three becomes useful when

Each artefact has a phase where it starts paying for itself and a phase where it is premature. Roughly:

1. Before approval. Assumptions and dependencies matter most here, because the estimate rests on them. A RACI is premature when the team is still a list of job titles.
2. Mobilisation. This is RACI’s moment. You have named people, a scope and a set of decisions that will need making. Build it while the team is assembling, not after the first argument about who signs off design.
3. Early delivery. The RAID log goes live. Assumptions written at approval get tested, and the ones that fail become issues within the first few weeks.
4. Mid delivery. If a steering group or sponsor is reviewing risk monthly, this is where a separate risk register becomes worth the duplication. Before that point, the R section of the RAID log is enough.
5. Closure. The RAID log is the more valuable of the two at the end, because assumptions that turned out to be wrong are the cheapest lesson the next project can buy.

The ordering is not a rule, and projects with heavy external dependencies often need the RAID log before anyone has agreed the RACI. What is consistent is that RACI answers a question you have at the start, and RAID answers a question you keep having.

How to run a RAID log without duplicating the risk register

Pick one of them as the place a risk is written, and make the other a view of it rather than a second copy. Teams that maintain both properly almost always keep the risk register as the master and let the R section of the RAID log point at it, because the register is the one with the audience.

Two arrangements that work:

• Register as master. Risks live in the risk register with full scoring and mitigation detail. The RAID log holds only assumptions, issues and dependencies, and its R column is a reference: risk ID, one line, current status. Nobody edits the same risk twice.
• Log as master. Everything lives in the RAID log. The risk register is produced from it for reporting, by filtering to open risks above a severity threshold. This works when the reporting need is monthly rather than continuous.

What does not work is maintaining both as independent documents and reconciling them before each steering meeting. That reconciliation is unpaid work, it always slips, and the version the sponsor reads ends up being the stale one. Whichever pattern you choose, the harder problem is keeping the thing current at all, which is a question of review rhythm and who is expected to update what rather than of format.

How many of these do you actually need?

Fewer than you have. Most teams carrying all three are maintaining at least one out of obligation, and the obligation is usually to a template rather than to a reader. The test is simple: name the meeting where each document is opened on a screen and someone changes something in it. If no such meeting exists, that tracker is a document, not a control, and its main function is to make an absent stakeholder feel covered.

Run the test honestly and you usually find one artefact doing real work, one being updated the morning before a report, and one that has not been touched since week two. The fix is not better discipline. It is deleting the one nobody reads and putting its two live items into the one people do read.

The other reliable failure is quieter. Both grids get filled in by one person, alone, after the meeting rather than during it, and the names in them are guesses about what colleagues would probably agree to. An accountable name that its owner has not seen is not accountability, it is a spreadsheet cell. Projan runs the planning conversation in Slack or Microsoft Teams and puts the ownership questions to the group while everyone is still in the thread, so the accountable name against a task and the owner against a risk are settled by the people involved rather than typed in afterwards by whoever holds the file.

Frequently asked questions

What is the difference between a RAID log and a RACI? They are not alternatives. A RACI is a static grid of tasks against people that you build once and revise when the team changes. A RAID log is a running record you add to every week. If you can only maintain one, build the RACI first on a project with unclear ownership, and the RAID log first on a project with many external dependencies.

What does the D in RAID stand for? Dependencies: things outside your team that must happen before your work can proceed, such as another team’s release, a supplier delivery or a legal sign off. Some teams read the D as Decisions and the A as Actions instead, which produces a useful log but a different one. Agree which expansion you are using before the first review, because mixed readings produce mixed columns.

Can you keep the RACI and the RAID log in one spreadsheet? Yes, as separate tabs in the same file, and that is often the sensible arrangement on a small project. Keep them as distinct sheets rather than merged columns, because they update on different rhythms. The RACI changes when the team or the scope changes. The RAID log changes weekly, and merging the two means touching the ownership grid every time a risk moves.

Do small projects need any of these? A two person, three week piece of work usually needs neither. What it does need is a named owner for each deliverable and a short written list of what you are relying on other people to do. That list is a RAID log in everything but name. Formal artefacts start earning their keep when the number of people involved exceeds the number who attend the same meeting.

Choose these documents by the question you keep being asked, not by what the governance template contains. If you are constantly clarifying who decides, build the RACI; if you are constantly rediscovering things you already knew, build the RAID log. Anything you cannot name a reader for is not a control, and dropping it costs nothing.