Dashboard

What goes in an IT risk dashboard in Metabase?

An IT risk dashboard turns the risk register into analytics: a likelihood-by-impact matrix, treatment status, overdue mitigations by owner, and whether the register is shrinking or quietly growing. It's built for governance — the risk committee and audit — and sits between the IT compliance dashboard below it and the executive rollup above it. Metabase builds it from a GRC export or a risks table in your warehouse.

For: CIOs, risk committees, and internal audit. Grain: one row per risk, plus one per mitigation task. Refresh: daily sync; monthly risk-review cadence.

What does an IT risk dashboard look like?

Here’s the layout this guide builds. The register headline — open, critical, overdue, accepted, median age — opens the page; exposure comes next, with the risk matrix, the severity mix, and the trend that shows whether the register is growing faster than it closes; treatment and accountability sit at the bottom, ending in the top-risks table the monthly review walks through.

IT risk dashboard in Metabase showing a likelihood-impact risk matrix, severity trend, treatment status, and overdue mitigations by owner.
An example IT risk dashboard in Metabase, built from a risk register in a GRC tool or warehouse table. Figures are illustrative.

Which cards belong on an IT risk dashboard?

The eight below answer the four questions a risk committee actually asks: where is the exposure, is it growing, what are we doing about it, and who is late?

  • Risk matrix — open-risk counts by likelihood and impact (pivot table with conditional formatting)
  • Open risks by severity — critical through low, with the total (donut)
  • Risks by treatment status — mitigate, accept, transfer, avoid, and untriaged (row)
  • Open risks by severity over time — is the register growing, and in which band (stacked bar)
  • New vs. closed risks per month — intake against closure velocity (bar)
  • Open risks and overdue mitigations by owner — accountability in one chart (row)
  • Median risk age — how long the register holds a risk (number)
  • Top open risks by residual score — the worklist, with owner, treatment, and mitigation due date (table)

What data does the dashboard need?

  • A risks table — risk_id, title, likelihood, impact, severity, treatment, owner, opened_at, closed_at, status.
  • Fixed five-level scales for likelihood and impact, stored as values from a controlled list — the matrix is only as honest as these columns.
  • A mitigations table with risk_id, due_at, completed_at, and owner, for the overdue cards.
  • Acceptance records — acceptor, rationale, review_at — so “accepted” risks carry an expiry like any other treatment.
  • A monthly snapshot of open-risk counts by severity (or reliable opened_at/closed_at stamps) to draw the register trend.

How do you build it?

  1. Get the register into the warehouse: GRC platforms export via API, and a spreadsheet register uploads directly to Metabase — normalize likelihood, impact, treatment, and owner to controlled values first.
  2. Build the matrix as a query grouped by likelihood and impact, shown as a pivoted table with conditional formatting — the heat-map read is the point.
  3. Model “overdue mitigation” once (due_at past, completed_at null) and reuse it in the KPI, the by-owner chart, and the top-risks table so the numbers always agree.
  4. Create the trend from monthly snapshots of open risks by severity — the register table alone can’t tell you what April looked like once rows close.
  5. Add filters for business unit, risk owner, and date range, and subscribe the risk committee to a monthly digest timed to land before the review meeting.

Example card SQL

Risk matrix cells with overdue mitigations and age PostgreSQL
SELECT
r.likelihood,
r.impact,
COUNT(*)                                              AS open_risks,
COUNT(*) FILTER (WHERE r.severity = 'critical')       AS critical,
COUNT(*) FILTER (WHERE r.treatment = 'untriaged')     AS untriaged,
COUNT(*) FILTER (
  WHERE m.due_at < now() AND m.completed_at IS NULL
)                                                     AS overdue_mitigations,
ROUND(AVG(
  EXTRACT(day FROM now() - r.opened_at)
))                                                    AS avg_age_days
FROM risks r
LEFT JOIN mitigations m USING (risk_id)
WHERE r.status = 'open'
GROUP BY r.likelihood, r.impact
ORDER BY
array_position(
  ARRAY['almost_certain','likely','possible','unlikely','rare'],
  r.likelihood
),
array_position(
  ARRAY['minimal','minor','moderate','major','severe'],
  r.impact
);

Metrics

Integrations

Dashboards

FAQ

What is an IT risk dashboard, and who is it for?
It's analytics on the risk register: how many risks are open, where they sit on the likelihood-by-impact matrix, what treatment each has, and whether mitigations are landing on time. The audience is governance — the CIO, the risk committee, internal audit — not the analysts running detections; that operational view lives in a SOC dashboard. A good test of the difference: this dashboard should change your investment decisions quarterly, not your response decisions today.
Our register is a spreadsheet. How do we get to a dashboard?
Upload it — but normalize three things first, because they decide whether the charts mean anything. Likelihood and impact must come from fixed scales (five levels each, defined in words), not free text; every risk needs an owner from a controlled list; and treatment must be one of a closed set — mitigate, accept, transfer, avoid, untriaged. With those columns clean, a risks table plus a mitigations table with due dates gives you every card on this page. GRC tools export the same shape when you outgrow the sheet.
Should the risk matrix be qualitative buckets or quantitative scores?
Start with the qualitative 5×5 — counts of risks per likelihood-and-impact cell. It's honest about the precision you actually have, every stakeholder can read it, and movement between cells is a meaningful event. Quantitative scoring (annualized loss expectancy, Monte Carlo) is worth it only once treatment decisions genuinely hinge on ranking risks that share a cell. The failure mode to avoid is pseudo-quantification: multiplying two guessed 1–5 numbers into a "score of 12" adds arithmetic, not information, and invites false confidence in a ranking the inputs can't support.
What should "accepted" require before it appears on the dashboard?
A named acceptor senior enough to own the consequence, a written rationale, and a review date — acceptance is a decision that expires, not a bucket for risks nobody wants to fund. On the dashboard, chart accepted risks with their review dates and flag any acceptance past review, exactly as you'd flag an overdue mitigation. It's also worth splitting "accepted" from "untriaged" ruthlessly: a register where untriaged risks quietly drift into accepted is telling auditors that acceptance means neglect with paperwork.
How do we stop the register from going stale?
Chart the failure modes. New-versus-closed per month shows whether the register only ever grows; an untriaged count older than 30 days shows intake without decisions; overdue mitigations by owner turns follow-through into a named list; and median risk age rising quarter over quarter is the clearest staleness signal there is. Then give the dashboard a meeting: a monthly risk review that walks the overdue and untriaged cards. A register that no recurring meeting reads will be stale within two quarters no matter how good the dashboard is.
Should vulnerability scan data feed the risk register?
As aggregates, not rows. Ten thousand findings from your scanner belong in a vulnerability management dashboard with SLAs and remediation velocity — copying them into the register drowns the twenty risks leadership actually needs to discuss. What crosses over is a pattern worth governing: "patching consistently misses SLA on internet-facing systems" is a register entry whose mitigation is funding and process, and metrics like open critical vulnerabilities become the evidence behind its trend.
What does the executive version of this dashboard look like?
Shorter horizon, fewer numbers, more narrative. A cybersecurity executive dashboard rolls this register up into a risk-score trend, top-five risks with treatment status, and program milestones — alongside incidents, SLA attainment, and spend. Keep the two connected but separate: the register dashboard is where risk owners work, the executive one is where the board reads, and the worst outcome is a single dashboard that serves neither because it tries to do both.