--- title: "Risk Register vs Heat Map vs RAID Log: Pick the Right Slide" description: Risk register, risk heat map, and RAID log aren't interchangeable slides. Here's which one belongs in front of your steering committee, and when. image: https://www.advis-io.com/hubfs/blog-key-visuals/219-risk-register-vs-raid-log-vs-heat-map.en.kv.png --- [![logo\_transparent-Apr-12-2025-09-23-39-9623-AM-1](https://www.advis-io.com/hubfs/logo_transparent-Apr-12-2025-09-23-39-9623-AM-1.svg)](https://www.advis-io.com/en/?hsLang=en) - [BLOG](https://www.advis-io.com/blog?hsLang=en) - [ABOUT](https://www.advis-io.com/about?hsLang=en) [CREATE SLIDES](https://marketplace.microsoft.com/en-us/product/advisioinc1760912844242.advisio-202604?tab=Overview) Consulting Slides # Risk Register vs Heat Map vs RAID Log: Pick the Right Slide Risk register, risk heat map, and RAID log aren't interchangeable slides. Here's which one belongs in front of your steering committee, and when. [Advisio Editorial](https://www.advis-io.com/en/blog/author/advisio-editorial) Nov 13, 2026 --- It's Monday afternoon, the steering committee deck is due Wednesday, and you've just exported forty rows of open risks out of Jira. Your PM asks for "the risk slide." Your sponsor, on a separate thread, asks where this rolls into "the RAID log." Someone from the PMO mentions you still owe them "the heat map from last month." Three names, and you're starting to suspect they're the same ask wearing different outfits. They're not. **A risk register is the full list with owners and status; a risk heat map is the probability-times-impact picture you put in front of a room that has four minutes; a RAID log is the risk register folded into a broader view that also tracks assumptions, issues already happening, and dependencies you don't control.** Which one goes on the slide depends on who's in the room and what they're there to decide, not on which one you happen to have open. ## Three Documents, Three Different Jobs The confusion is understandable because all three are built from the same raw material — a list of things that could go wrong, each with a probability and a consequence. But "built from the same material" isn't "interchangeable," any more than a financial model and an investor deck are interchangeable just because they share the same numbers. A risk register answers "what's the complete, current picture, and who owns each line." A risk heat map answers "where should this room's attention go in the next sixty seconds." A RAID log answers a wider question entirely: "what, across risks and issues and dependencies and the assumptions we're resting on, could change our plan." Mixing those jobs up is how a register ends up on a steering committee slide looking like a wall of ten-point text, or a heat map gets handed to an auditor who actually needed the full list with dates. ![Diagram showing the risk register as the single source of truth, with the risk heat map and RAID log generated from it as two different output views for two different audiences.](https://www.advis-io.com/hubfs/blog-figures/219-risk-register-vs-raid-log-vs-heat-map-fig1.en.png) Figure: The register holds the data; the heat map and RAID log are two different views generated from it, not separate documents maintained by hand. ## Risk Register: The Full List, With Owners and Status The register is the ledger. Every identified risk gets a row: a description specific enough that someone who wasn't in the identification workshop can still understand it, a probability score, an impact score, a calculated or assigned severity, an owner's name, a mitigation action, a due date, and a status. Nothing here is designed to be glanced at — it's designed to be queried, filtered, and audited. A register with fifteen risks and a register with sixty risks look identical in structure; only the row count changes. That's exactly why a register rarely works as a slide on its own: put sixty rows on a page at a font size anyone can read from the back of a room, and you've built a document, not a slide. Where a register does belong on a slide is the appendix — the place a steering committee can dig into if someone asks "show me the detail on risk 23," without that detail crowding out the three risks the meeting actually needs to discuss. A register that lives only in Jira or Excel and surfaces in a deck only as a filtered extract is doing its job correctly. ## Risk Heat Map: What the Room Should Look At First The heat map takes the same probability and impact scores from the register and plots them on a grid — typically 4x4 or 5x5, probability on one axis, impact on the other — so that severity becomes a position instead of a number you have to read. A risk sitting in the top-right corner needs no further explanation of why it's on the agenda; its location says so. That compression is the entire value of a heat map, and it's also its entire limitation: a heat map tells a room where to look, not what to do about what it's looking at. The mitigation plan, the owner, the due date — all of that still lives in the register, and a heat map that tries to carry that detail too (labels crammed into each cell, a sidebar of action items) has usually also lost the one-glance clarity that was the point of building it. The construction problem most heat map guides skip is what happens once more than six or seven named risks land in the same cell, or near the same coordinates. Labels start overlapping, bubbles pile on top of each other, and the thing that was supposed to be legible from across the room needs a laptop and squinting to read. That's a layout problem specific to heat maps — registers and RAID logs don't have it, because they're tables, not a 2D plot — and it's worth solving before the committee meeting, not during it, because the fix (offsetting bubble positions, grouping nearby risks into a single labeled cluster with a count) takes real iteration once you're past a handful of risks. ## RAID Log: Risk in the Context of Everything Else That's Moving A RAID log keeps the register's risk rows and adds three more categories: Assumptions (what you're planning against that hasn't been confirmed), Issues (risks that already happened and are now live problems), and Dependencies (what your plan needs from outside your direct control, and when). We covered the mechanics of building that four-section slide — how to keep it from collapsing into four equal boxes when one week has eight risks and one dependency — in a [separate walkthrough on constructing a RAID log slide](https://www.advis-io.com/en/blog/raid-log-powerpoint?hsLang=en). The relevant point here is narrower: a RAID log is the right artifact when the room needs project health, not risk detail specifically. A sponsor checking in monthly on "is this program still on track" is better served by one RAID log slide than by a risk register slide plus a separate issues slide plus a separate dependency tracker, because the whole point of RAID is that those four things interact — a dependency slipping is often exactly what turns an assumption into an issue. The trade-off is resolution. Because a RAID log has to fit four categories on one slide, each risk gets less room than it would on a register or in a heat map cell. A RAID log that tries to also carry full mitigation detail per risk usually ends up as the overcrowded slide nobody can read in the room — which is the same failure mode a register has standalone, arrived at from the opposite direction. ## So Which Slide Goes in Front of the Steering Committee? Run a quick case to see how the same underlying data produces three different front-of-room artifacts. A CRM migration project is carrying a risk: "Data migration vendor has not confirmed a go-live date for the test environment; two-week slip would push UAT past the holiday freeze." Probability: medium. Impact: high. In the register, that's one row with an owner (the integration lead), a mitigation ("escalate to vendor PM by Friday, identify backup resourcing"), and a due date. In the heat map, it's a single bubble sitting in the upper-middle band of the grid, next to three or four other risks of similar severity — visible at a glance as one of the handful of things worth discussing today, with no text beyond a short label and a number. In the RAID log, the same risk sits in the Risks quadrant, but now next to a related Dependency line ("vendor's test environment availability — needed by \[date\]") and an Issue that already fired last week ("vendor missed the first environment handoff deadline") — the three lines together tell the sponsor this isn't an isolated risk, it's a pattern with one vendor. That's the actual decision rule: if the room is there to review the complete current state and audit ownership, bring the register (usually as an appendix, not the headline slide). If the room has four minutes and needs to know where to look, bring the heat map. If the room is checking overall program health and the risk doesn't make sense without the issues and dependencies sitting next to it, bring the RAID log. A weekly working-team sync usually wants the register, because the team is close enough to the detail to use it directly. A monthly steering committee usually wants the heat map as the headline, with the register one click away. A RAID log earns its place specifically when risks, issues, and dependencies are tangled together the way the vendor example above shows — which tends to happen more as a program matures and more external parties are involved. **Field note:** on an engagement at a Big Four firm, I watched a program hand the same vendor risk to three different stakeholders in three formats in the same week — register row to the PMO, heat map bubble to the steering committee, RAID log line to the sponsor — and get three different follow-up questions back, each one appropriate to the format. The PMO asked for the updated due date. The steering committee asked why that bubble had moved since last month. The sponsor asked whether the vendor pattern meant it was time to escalate the relationship, not just the risk. None of those three questions would have landed the same way if the risk had shown up in the wrong artifact — the sponsor's question in particular only makes sense once the dependency and the issue are sitting next to the risk, which only the RAID log shows. | Axis | Risk Register | Risk Heat Map | RAID Log | | --- | --- | --- | --- | | Question it answers | What's the complete list, and who owns each line? | Where should attention go right now? | Is the program on track, across everything that's moving? | | Format | Table — rows scale with risk count | 2D grid — severity shown as position | Four-quadrant table — risk is one of four sections | | Best audience | Working team, auditors, PMO | Steering committee, time-boxed exec review | Sponsor or program board tracking overall health | | Typical cadence | Continuous — updated as risks change | Per steering committee meeting, pulled from the register | Weekly or monthly program check-in | | Weak spot | Unreadable as a slide past ~10 rows | No mitigation detail; bubbles overlap past 6-7 risks per cell | Least room per risk of the three — not for deep risk review | ## The Mistake That Breaks All Three: Updating the Picture, Not the List The single most common failure isn't picking the wrong artifact — it's maintaining the heat map or the RAID log slide by hand after the register changes, instead of treating the register as the one place data gets entered and everything else as a view generated from it. A risk gets re-scored in the register on Tuesday; by Thursday's steering committee, the heat map still shows last month's bubble position because nobody remembered to drag it. Multiply that by the fact that a bubble's position on a heat map and a risk's row in a RAID log both have to move every time the underlying register changes, and "update the picture by hand" becomes the thing that quietly drifts out of sync first, usually right before the meeting where accuracy matters most. This is the specific gap [Advisio](https://www.advis-io.com/?hsLang=en) closes for a PowerPoint-native workflow: feed it the current register and it rebuilds the heat map's bubble positions and the RAID log's four sections to match, inside the actual PowerPoint file, so the slide reflects this week's register instead of last month's layout. Whichever slide you're building this week, the underlying discipline is the same: one register as the source of truth, and the register-to-heat-map or register-to-RAID-log step treated as a regeneration, not a manual edit you have to remember to repeat every cycle. ## FAQ ### Is a RAID log just a renamed risk register? No. A RAID log keeps the register's risk rows but adds three categories a register doesn't track at all: assumptions that haven't been confirmed, issues that have already happened (as opposed to risks, which haven't happened yet), and dependencies on things outside the project's direct control. A risk register that's been "renamed" to RAID without adding those three categories isn't actually a RAID log. ### If I already have a RAID log, do I still need a separate heat map? Usually yes, if your audience includes a steering committee or executive review that only has a few minutes. A RAID log's risk quadrant is a table; it doesn't compress severity into a glanceable position the way a 2D heat map does. Programs that present to both a working team and an executive committee often maintain both — RAID log for the team, heat map pulled from the same register for the executive slide. ### How often should each one be updated? The register should update continuously, as risks are identified, re-scored, or closed — it's the source document. The heat map and the RAID log slide should be regenerated from the register immediately before each meeting that uses them, rather than edited independently, which is exactly the step that drifts out of sync when done by hand. ### Which one goes in the appendix versus the main deck? The heat map is almost always the headline slide for a steering committee, because it's built to be read in seconds. The full register belongs in the appendix, referenced by risk number if someone wants the detail behind a specific bubble. A RAID log sits on its own, typically in a program status deck rather than a steering committee pack, since its audience is usually a sponsor or program board tracking overall health rather than a committee reviewing risk specifically. [Consulting Slides](https://www.advis-io.com/en/blog/tag/consulting-slides) [Consulting Skills](https://www.advis-io.com/en/blog/tag/consulting-skills) ## Similar posts ![logo\_white-1](https://www.advis-io.com/hubfs/logo_white-1.svg) Transform your business data into actionable insights with AI-powered analytics. Get consultancy-grade presentations in minutes, not weeks. N&E Building, 6th Floor 1-12-4 Ginza, Chuo-ku Tokyo 104-0061 Japan [contact@advis-io.com](mailto:contact@advisio.com)   - [Blog](https://www.advis-io.com/en/blog) - [About Us](https://www.advis-io.com/en/about?hsLang=en) - [問い合わせ](https://www.advis-io.com/contact?hsLang=en) - [特定商取引法に基づく表記](https://www.advis-io.com/jacommercialtransaction?hsLang=en) - [利用規約](https://www.advis-io.com/terms?hsLang=en) - [プライバシーポリシー](https://www.advis-io.com/privacy-policy?hsLang=en) © 2026 Advisio Inc. All rights reserved. [Powered by Atlas - a B2B SaaS HubSpot theme](https://www.kalungi.com/atlas-hubspot-theme-for-b2b-saas-software) ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Advisio Editorial", "url" : "https://www.advis-io.com/en/blog/author/advisio-editorial" }, "dateModified" : "2026-11-13T05:15:26.894Z", "datePublished" : "2026-11-13T05:15:26.000Z", "headline" : "Risk Register vs Heat Map vs RAID Log: Pick the Right Slide", "image" : [ "https://www.advis-io.com/hubfs/blog-key-visuals/219-risk-register-vs-raid-log-vs-heat-map.en.kv.png" ], "mainEntityOfPage" : { "@id" : "https://www.advis-io.com/en/blog/risk-register-vs-raid-log-vs-heat-map", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://www.advis-io.com/hubfs/logo.svg" }, "name" : "Advisio株式会社" } } ```