What columns should a RAID log have?
Eleven columns cover most RAID logs: ID, type, description, date raised, owner, probability, impact, score, response and next action, due date, and status. Everything else is optional. Dependencies need a giver and a receiver, assumptions need a validate-by date, and issues need the date they occurred rather than a probability.
One row structure, four record types
A RAID log holds four kinds of record: risks, assumptions, issues and dependencies. Some teams keep four tabs, some keep one tab with a type column and a filter. Either arrangement works, because the row has to answer the same set of questions in all four cases. What is it. Who is dealing with it. How bad is it. What happens next, and by when. When was any of that last true.
Columns exist to answer those questions. A column that does not feed a decision, a report or a filter is a column somebody has to maintain for nothing, and it is usually the first thing to go stale.
The eleven columns
| Column | What it holds | Why it is there |
|---|---|---|
| ID | R-014, I-006, D-021 | So the item can be referred to in minutes and status reports without retyping the description |
| Type | Risk, assumption, issue, dependency | Drives filtering and the counts on the dashboard |
| Description | One or two sentences, in plain language | Someone who was not in the room has to understand it six weeks later |
| Date raised | The date the row was created | Ageing. An issue open for eleven weeks reads differently from one raised yesterday |
| Owner | A named person | The one field that decides whether anything moves |
| Probability | Scale of 1-5, or high/medium/low | Half of the score |
| Impact | Same scale, applied consistently | The other half |
| Score / RAG | Probability multiplied by impact, or a colour derived from it | Sorting. The log is only useful if the top of it is the top of it |
| Response / next action | What is being done, phrased as an action | Distinguishes a managed risk from a logged one |
| Due date | When the next action is expected | Produces the overdue list, which is the only list that gets read under pressure |
| Status | Open, in progress, closed, escalated | Keeps closed items in the log for the audit trail without cluttering the live view |
Two more columns tend to arrive after the log has been running for a month. Last updated exposes rows nobody has touched since they were created, which is a different problem from rows that are overdue. Resolution records what actually happened when an item closed, and it is the field the closure report and the lessons learned log read from later. The longer guide to what goes in a RAID log covers how these behave once the log is a few hundred rows deep.
Fields that only apply to one record type
Trying to force all four types into identical columns is where RAID logs start to feel wrong. Each type carries one or two fields of its own.
- Risks use probability and impact as designed. Some logs also carry a post-mitigation score alongside the raw one, so the register shows whether the response is doing anything.
- Assumptions have no probability. What they have is a validate-by date and a note of what happens if the assumption turns out to be false — usually that it becomes a specific risk or issue. An assumption without a validation date is a risk nobody has scored.
- Issues have already happened, so probability is meaningless. They need a date occurred, a severity, and a target resolution date. Mislabelling one as the other is the most common error in a working log.
- Dependencies need two parties rather than one owner: the team that owes the thing and the team waiting for it. They also need two dates — the date needed and the date committed — because the gap between those is the entire signal.
Columns that get added and then abandoned
A few fields look sensible in the template design and die in week three.
- Cost of impact in currency. Nobody can produce a defensible number for most rows, so the column fills with blanks and round guesses.
- Risk category taxonomy. Twelve categories, of which four are ever used, and two rows out of three land in "other".
- Secondary owner. Reads as shared accountability, works as none.
- Probability as a percentage. A 1-5 scale is already an estimate. Expressing it as 35% implies a precision that is not there.
- Free-text update history in the row. It grows until the cell is unreadable and the row height breaks the print layout. A last-updated date plus a current next action carries the same information.
How the columns get used
The columns are only worth the effort if something reads them. In practice three things do: the weekly review, which sorts by score and then filters to overdue; the status report, which pulls the top few risks and any issue above a severity threshold; and the escalation, which needs the ID, the owner, the impact and the decision being asked for.
That is the test for any column somebody proposes adding. Which of those three reads it. The RAID Log Template (Excel) uses this column set with the scoring and the dashboard already wired up, and the RAID Log & Program Governance Pack extends it with the separate dependency, action and stakeholder trackers a programme ends up needing alongside it.
A note on the risk register
If your organisation already runs a formal risk register with its own required fields, the RAID log usually keeps its own columns and the register receives a subset. Duplicating a full corporate risk taxonomy inside a project log gives you two records to update and one of them will be wrong. RAID log vs risk register sets out where the boundary usually sits.
Questions
Should risks, assumptions, issues and dependencies be on one tab or four?
Either works. One tab with a type column makes sorting and reporting simpler; four tabs make each record type's own fields easier to lay out. The choice matters less than applying the scoring scale consistently.
Do I need both a score and a RAG colour?
Not strictly. The score gives you the sort order and the colour gives you the visual. Most logs derive the colour from the score with a formula so the two can never disagree.
What ID format works best?
A letter for the type and a sequential number, such as R-014 or D-021. Avoid embedding dates or workstream codes in the ID, because items move between workstreams and the ID then lies.
How many columns is too many?
When the row no longer fits on a screen without horizontal scrolling, the log stops being read in reviews. That is a practical ceiling regardless of how useful each individual column looked.