Microsoft Planner RAID Log: Risks & Issues
Microsoft Planner

Microsoft Planner RAID Log: Risks & Issues

Quick answer: Microsoft Planner has no native RAID structure in either edition: no dedicated risk or issue field type, no severity scale, no mitigation field. Teams end up doing risk and issue tracking in a bucket labeled "Risks," a color label, or a checklist item, which works for a single plan until someone needs to see every open risk with an owner and a due date at once. This post assumes you already know what RAID means (for the fuller definitions, see What Is RAID in Project Management?) and focuses on the practical part: what a real risk and issue record needs, what Planner can and can't do natively, and how to run one against live Planner plans.

RAID, briefly

A risk is something that might happen and would hurt the project if it did. An issue is something that has already happened and needs resolving. An action is a task assigned to move a risk, issue, or decision forward. A decision is a choice made and recorded so nobody re-litigates it three sprints later. That's the whole vocabulary. For worked definitions, examples, and the case for keeping a RAID log at all, see What Is RAID in Project Management?. The rest of this post is about running one against Microsoft Planner specifically.

What a real RAID record needs

Whatever tool holds it, a risk or issue record that actually gets used, not just filled in once and ignored, needs five things:

  • An owner: one named person accountable for it, not "the team."
  • A severity or priority rating, so a dozen open risks can be triaged in the order that matters.
  • A due date for the next action, not just a vague "monitor."
  • A mitigation or response plan: what's being done about it, in enough detail that someone other than the owner could pick it up.
  • A status that changes as the record moves, from open to escalated to mitigated to closed, with enough history to show how it got there.

Miss any one of these and the register degrades into a list nobody trusts. A risk with no owner gets nobody's attention. A risk with no due date sits at "monitoring" forever. This is also, not coincidentally, close to the field set PMO risk management best practices recommend for any project-level risk register, Planner or otherwise.

Doing this natively in Microsoft Planner

Planner gives you real building blocks, and it's worth being precise about what each one is actually for before deciding it's not enough.

1. A bucket named "Risks." The most common workaround: create a bucket alongside your normal work buckets and drop risk tasks into it. This gets you a visual grouping and nothing else: no severity field, no mitigation history, and the risk task competes for attention with every delivery task on the same board.

2. A label or category tag. Planner Plan 1 includes color labels, which can mark a task as "Risk" or "Issue" at a glance. Useful for scanning a single board; not useful for triage, because labels carry no severity scale and there's no way to filter "high severity, past due" across plans.

3. A checklist item inside a task. Sometimes risks live as sub-items on a delivery task: "confirm vendor SLA" as a checklist line. This buries the risk inside task completion rather than tracking it as its own record with its own owner and status.

4. A custom field, on Premium. Planner Plan 1 already includes Timeline, People view, sprints, dependencies, and custom fields, which is more structure than most teams use. On Planner Premium (Plan 3 or Plan 5), a custom field for severity gets a single plan closer to a real register, but there is still no purpose-built risk or issue record type in any edition, and a custom field on one plan doesn't carry over to the next plan.

That last point is the real ceiling. Planner Premium ships native Portfolios that roll several Premium plans into one shared, read-only view, genuinely useful for seeing task status across plans. But Microsoft documents that Portfolios exclude Basic plans and require a Plan 3 or Plan 5 licence, and a Portfolio aggregates tasks, not risk records. However you tag a risk inside a single plan, it stays inside that plan.

One risk, start to resolution

Here's what a single escalated risk looks like tracked as a proper record, from the day it's raised to the day it closes:

Date raisedDescriptionOwnerSeverityDue dateMitigationStatus
Mar 3SSO vendor has not confirmed the integration test window; go-live depends on it.Dana R.MediumMar 14Escalate to vendor account manager; request written test-window commitment.Open
Mar 14Vendor missed the committed test window.Dana R.HighMar 21Weekly sync with vendor added; backup manual-provisioning plan drafted as fallback.Escalated
Mar 21Vendor confirms a new test window; manual-provisioning fallback held in reserve.Dana R.MediumMar 28Monitor test results; fallback plan stays documented but unused.Mitigated
Mar 28Integration test passed; SSO live in staging.Dana R.LowN/ANone required.Closed

Notice what makes this useful: severity moves as the situation changes, the due date is always the date of the next action rather than the project deadline, and the mitigation column tells the next reader what's actually being done, not just that "risk is being monitored." None of that survives inside a Planner bucket or checklist item; it survives because the record itself, not the task board, is the source of truth.

Where a change log fits in

Change requests sit next to RAID logs conceptually: a formally requested change is a decision waiting to be made, and approving one often creates new risks and actions of its own. It's a natural adjacent capability, and it's coming: a lightweight change log is planned as a later addition alongside the current risk and issue records, not something available today. If you're evaluating a RAID setup against Planner now, plan around risks, issues, actions, and decisions as the working set, and treat change tracking as a capability to revisit later rather than a gap to solve for immediately.

PPM Express for Microsoft Planner

PPM Express for Microsoft Planner connects your active Planner plans in one tenant, with a maintained cross-plan portfolio view. On the RAID side specifically, that means owned risk and issue records with severity, due date, mitigation, and status, sitting alongside the plans they came from rather than buried in a bucket. Cross-portfolio governance — approval workflows, escalation routing, or sign-off chains that span multiple portfolios — is a separate capability for organizations managing risk across several PMOs' worth of portfolios. For a team that just wants risks and issues tracked properly, with an owner and a due date, against real Planner plans, this covers the whole job.

Frequently asked questions

Does Microsoft Planner have a built-in risk register? No. Neither Planner Plan 1 nor Planner Premium includes a dedicated risk or issue field type. Teams improvise with a bucket, a label, or (on Premium) a custom field, none of which is a purpose-built record with severity, mitigation, and status history.

Can I track RAID logs across multiple Planner plans? Not with fields inside Planner itself. A bucket or label lives inside one plan, and Planner Premium Portfolios roll up tasks, not risk records, and require a Plan 3 or Plan 5 licence. Seeing risks and issues across plans in one place needs a layer above the plans.

What's the difference between a risk and an issue? A risk hasn't happened yet: it's a possibility with a probability and an impact. An issue has already happened and needs resolving now. See What Is RAID in Project Management? for the fuller breakdown, including actions and decisions.

Does Planner Premium's Portfolios feature solve this? Only partly. Portfolios give you a shared, read-only rollup of tasks across several Premium plans, which is genuinely useful for status visibility. But Microsoft documents that Basic plans are excluded and a Plan 3 or Plan 5 licence is required, and a Portfolio still aggregates tasks rather than holding risk data.

Is there a change log in PPM Express for Microsoft Planner? Not yet. A lightweight change log is planned as a later addition. PPM Express for Microsoft Planner currently covers risk, issue, action, and decision records with owners, severity, due dates, mitigation, and status.

What do I need to run a basic RAID log against Planner? Just a connected plan. Owned records with severity, due date, mitigation, and status are part of PPM Express for Microsoft Planner. Cross-portfolio governance and approval workflows are a separate capability for organizations managing risk across several PMOs' worth of portfolios.

If your RAID records are scattered one plan at a time (a bucket here, a label there), with no way to see every open risk and issue across your Planner plans at once, PPM Express for Microsoft Planner gives you one register for all of them: owned risk and issue records, with severity and due dates, connected across your Planner plans. No pressure to switch everything over. Connect a plan and see what one shared register looks like next to what you're already running in Planner.