ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
A RAID log is the single sheet that tells you what could go wrong on a project, what
you are taking on trust, what has already gone wrong, and what you are waiting on from somebody else.
Four registers most organisations keep separately, in one place, reviewed together — which is
exactly why it works.
RAID stands for Risks, Assumptions, Issues and Dependencies. Each is a distinct thing, and the
discipline of the log is refusing to blur them:
| Element | Definition | The test |
|---|---|---|
| Risk | Something that might happen and would affect the project | Has not happened yet |
| Assumption | Something taken as true without proof, that the plan relies on | Unverified, and would hurt if false |
| Issue | Something that has already happened and needs resolving | Certain, and here now |
| Dependency | Something you need from outside the team, or that others need from you | Owned by someone else |
Some organisations extend it to RAIDD or RAIDAD, adding decisions and actions. That is a reasonable
variation — the value is in having one reviewed artefact, not in the exact letters.
Risk versus issue. A risk that has occurred is no longer a risk; it is an issue, and it needs a
different response. Teams that leave materialised risks sitting in the risk register with a rising
probability score are describing the past as though it were the future, and the log stops being a
management tool.
The second most-abused row is the assumption. Assumptions are where projects hide the things nobody
wants to confirm — that the third party will deliver on time, that the data is clean, that the
business will be available for testing. Written down, each one becomes a question somebody can go and
answer. Left unwritten, they become the post-mortem.
The mechanics matter less than the cadence. The most common failure is not a badly structured log
— it is a well-structured one that was populated at initiation and never opened again.
The RAID log is not a standalone artefact. Its top risks belong in the
project initiation document at
baseline and in every status report thereafter. Its dependencies drive the schedule. Its issues feed
change control when they turn out to need scope or budget movement. And at the end, the log is the
raw material for lessons learned —
which of these did we see coming, and which did we not?
For risk method specifically, ISO 31000
supplies a consistent vocabulary if your organisation wants project risk to be comparable with
enterprise risk. That comparability is usually what a PMO is really asking for when it standardises
the scoring scale.
The RAID log, and the 35 templates around it.
The Project Management Toolkit ships 390+ editable MS Office templates. The risk, issue and change set alone includes a RAID log, a combined RAIDAD tracker with daily log, risk registers in Excel and Word, a risk scoring matrix, risk and issue heatmaps, a risk breakdown structure, issue registers and the change request and change log forms that materialised issues feed into.
Most logs fail on the writing, not the structure. Compare these two risk entries:
Weak: “Resource availability — medium — monitor.”
Usable: “If the two named integration developers are pulled onto the billing
migration in October, the interface build slips past the November gate. Probability 4, impact 4.
Owner: delivery lead. Action: confirm allocation with the resourcing manager in writing by 15
September. Fallback: contractor already scoped at £X per day.”
The second one can be acted on by somebody who was not in the room. That is the standard —
every entry should be legible to a stranger, because in six months, that is who will be reading it.
The same applies to closure. An entry closed with “resolved” tells you nothing. An
entry closed with what was done, by whom and on what date is evidence, and it is what makes the log
worth mining at the end of the project.
Risks get attention because they are frightening and issues get attention because they are loud.
Dependencies get a column and a shrug — and they cause more slippage than either, because they
sit outside the project manager’s control by definition.
A usable dependency entry names four things: what is needed, who owes it, the date it is needed by,
and what happens if it arrives late. That last field is the one almost always missing, and it is the
one that turns a dependency from a note into a plan. “Data migration cannot start; two-week
slip to the November gate; fallback is to load the subset manually at a cost of eight days” is
actionable. “Waiting on Finance” is not.
Two habits make dependency management work. First, confirm the date with the other party in
writing rather than assuming it — a dependency date the supplier has never seen is an
assumption wearing a dependency’s clothes. Second, track your outbound dependencies too.
Other people are depending on you, and discovering that at the point you miss the date is how project
managers acquire reputations.
Most organisations score probability and impact on a 1–5 scale and multiply them. That is
fine, provided everybody understands the number is a sorting aid rather than a measurement. A risk
scored 12 is not demonstrably worse than one scored 10; both are in the same band and should get the
same level of attention.
The value of scoring is consistency, not accuracy. Define what each point on the scale means —
in money, in days, in reputational terms — and write those definitions on the sheet where people
scoring risks will see them. Without that, two project managers will score the same risk differently
and a portfolio heatmap becomes meaningless.
Beware the mid-table cluster. When most entries land on 3 by 3, nobody is making a judgement. A
useful log has a small number of high scores that genuinely worry people and a long tail that does
not.
What does RAID stand for?
Risks, Assumptions, Issues and Dependencies. Some organisations extend it to include decisions and
actions, giving RAIDD or RAIDAD.
Is a RAID log the same as a risk register?
No. The risk register is one quarter of it. The point of the RAID log is that the four are reviewed
together, because an untested assumption and an unowned dependency sink as many projects as risks
do.
How often should it be reviewed?
Weekly for an active delivery, in a standing agenda item. Anything less frequent and materialised
risks sit as risks, and dependency dates pass unnoticed.
Who owns the RAID log?
The project manager owns the log; individuals own the lines. Those are different things, and
conflating them is why entries go stale.
Should closed items be deleted?
Never. Closed entries with dates and outcomes are the audit trail, and they are the most useful input
into lessons learned at closure.
A RAID log is not a sophisticated instrument. It is four columns, an owner per line, a next action
with a date, and a standing slot in the weekly meeting. What makes it work is that those four
categories force different questions, and reviewing them together stops a project from being
blindsided by the quiet one. Set the scoring definitions once, write every entry so a stranger could
act on it, never delete a closed line, and the log will still be earning its keep at closure when you
need to explain what you saw coming and what you did not.
All of these are covered by the Project Management Toolkit, or start with the free ISO templates.
August 31, 2026
August 31, 2026
August 31, 2026
August 31, 2026
August 31, 2026