What Is a RAID Log — and Why Should MSPs Produce One for Every Client?

Most MSP project managers know they should maintain a RAID log. Almost none do — consistently, at least. The work gets done in the PSA. The governance artefact that proves you were on top of risks and dependencies does not.

That gap matters more than most MSPs realise. A RAID log is not bureaucracy for its own sake. It is the document that shows a client — and their board — that you are managing delivery professionally, not just closing tickets.

What a RAID log is (plain English)

RAID stands for Risks, Assumptions, Issues, and Dependencies. It is a single register that captures everything that could affect a project or account — before it becomes a surprise in a QBR or a reason to churn.

• Risks — things that might go wrong (migration overrun, licence expiry, partner sign-off delay).
• Assumptions — what you are assuming to be true (client will provide admin access by Friday, maintenance window approved).
• Issues — things that have already gone wrong or are blocking progress right now.
• Dependencies — work waiting on someone outside your team (vendor, client procurement, third-party integrator).

Enterprise project managers have used RAID logs for decades. MSPs often skip them because the ticket queue feels like enough. It is not. Tickets record activity. A RAID log records judgement — what matters, who owns it, and what happens if it slips.

Why most MSPs do not produce RAID logs

The reason is almost always time, not ignorance.

Building a RAID log from scratch means reading ticket notes, identifying what is a risk versus an issue versus a dependency, assigning owners, scoring impact and probability, and formatting it in a way a client director would actually read. For a single project that can take 45–90 minutes. Multiply that across ten active client accounts and it never happens.

So RAID logs become something you promise in the SOW and produce once, at go-live. Then they rot in SharePoint while the real delivery context lives in HaloPSA or ConnectWise notes that nobody outside the engineering team reads.

Why MSPs should produce them anyway

Three practical reasons:

• Proof of governance. When something goes wrong, a dated RAID log shows you identified the risk early, assigned an owner, and tracked mitigation. That protects you in disputes and renewals.
• Client confidence. Directors do not read ticket histories. They read structured registers. A RAID log in a monthly pack signals that you run projects like a partner, not a break-fix shop.
• Continuity when people leave. When an engineer or account manager moves on, the RAID log preserves what was at risk and what was agreed — not just what was closed.

MSP RAID log template: column structure

A practical MSP RAID log uses these columns:

Example rows derived from PSA ticket and project notes (Northwood Manufacturing, Bridgewater Council, Acme Legal LLP). Probability scored 1–5 where 4 = active escalation or external blocker.

How Handover generates RAID logs automatically

Handover reads ticket and project notes from HaloPSA or ConnectWise and produces a structured RAID log alongside your actions, risks, summary, and client email. Enable the RAID log tab in Settings → Output tabs, run a generation, and the register is built from the same source data your engineers already update.

Each row gets a RAID ID, named owner (from the ticket assignee — not "TBC"), impact description, probability score, status, and due date. Export the full delivery pack to Excel in one click, RAID log included, alongside change logs, stakeholder updates, and the rest of your PM outputs.

The point is not to replace project management judgement. It is to remove the 90-minute formatting exercise that stops RAID logs from existing at all.

Start your free trial and enable RAID log in your output tabs — no separate template to maintain.