48.9k Log in Get started
Dashboard

What goes in an IT security dashboard in Metabase?

An IT security dashboard tracks the hygiene of the IT estate — patch latency, endpoint protection coverage, MFA adoption, phishing-test results, and privileged accounts — rather than live threats. It answers "are we hard to attack?", while a SOC dashboard answers "are we being attacked?". Metabase builds it from your MDM, EDR, and identity-provider data synced to a warehouse.

For: IT managers, security engineers, and sysadmins. Grain: one row per device (or account) per day. Refresh: daily sync from MDM, EDR, and IdP — this is hygiene, not detection.

What does an IT security dashboard look like?

Here’s the layout this guide builds. Estate-wide hygiene numbers sit at the top so the weekly review starts from one row; patching and endpoint protection come next because unpatched, unprotected machines are the likeliest way in; identity and people risk — MFA, phishing results, privileged accounts — close the page because they change slowest and need the most follow-through.

IT security dashboard in Metabase showing patch SLA compliance, endpoint coverage, MFA adoption, phishing results, and privileged accounts.
An example IT security dashboard in Metabase, built from MDM, EDR, and identity-provider data. Figures are illustrative.

Which cards belong on an IT security dashboard?

The eight below cover the three ways an estate quietly gets soft: machines that aren’t patched, machines that aren’t protected, and people who aren’t behind MFA or are being successfully phished.

  • Patch SLA compliance — % of critical patches installed within 14 days (gauge)
  • Median patch latency by platform — days from release to install (bar)
  • Endpoint protection coverage — EDR agents installed vs. device inventory (progress)
  • End-of-life OS devices — machines on operating systems no longer receiving updates (row)
  • MFA adoption — % of accounts with MFA enrolled, against the target (line)
  • Phishing simulations — click rate vs. report rate per campaign (combo)
  • Privileged accounts by system — domain, cloud, database, and break-glass admins (bar)
  • Devices missing critical patches — the worklist, with owner group and patch age (table)

What data does the dashboard need?

  • A devices table from your MDM — device_id, platform, os_version, owner_group, retired_at — as the estate’s denominator.
  • patches and patch_installs — patch, severity, released_at, and per-device installed_at — for latency and SLA math.
  • An EDR agent inventory (agent_installs with device_id, last_seen_at) to compute protection coverage against the same denominator.
  • IdP exports: users with mfa_enrolled and factor type, plus admin-group memberships for the privileged-account count.
  • Phishing-simulation results per campaign — delivered, clicked, reported, and the recipient’s department.

How do you build it?

  1. Sync MDM, EDR, and IdP data into your warehouse daily, each with a load timestamp — most of these tools export to a warehouse directly or via their API.
  2. Reconcile the device inventories first: match MDM devices to EDR agents on serial number or hostname, and decide which system is the denominator. Coverage percentages are meaningless until the denominators agree.
  3. Build one model per domain — patch status, endpoint coverage, identity — so every card computes “compliant” the same way, then save one question per card on top.
  4. Compute patch latency per patch-device pair (release date to install date), and materialize the median and the 14-day SLA percentage by platform.
  5. Add filters for platform, department, and date range, then subscribe the IT channel to a weekly snapshot — the table of devices missing critical patches is the worklist.

Example card SQL

Patch latency and 14-day SLA compliance by platform PostgreSQL 
WITH latest_patch AS (
SELECT
  d.device_id,
  d.platform,
  p.patch_id,
  p.released_at,
  pi.installed_at,
  EXTRACT(day FROM pi.installed_at - p.released_at) AS days_to_patch
FROM devices d
JOIN patches p
  ON p.platform = d.platform
 AND p.severity = 'critical'
 AND p.released_at >= now() - interval '90 days'
LEFT JOIN patch_installs pi
  ON pi.device_id = d.device_id
 AND pi.patch_id = p.patch_id
WHERE d.retired_at IS NULL
)
SELECT
platform,
COUNT(DISTINCT device_id)                              AS endpoints,
PERCENTILE_CONT(0.5)
  WITHIN GROUP (ORDER BY days_to_patch)                AS median_patch_latency_days,
ROUND(
  100.0 * COUNT(*) FILTER (WHERE days_to_patch <= 14)
    / NULLIF(COUNT(*), 0), 1
)                                                      AS pct_within_14_day_sla,
COUNT(*) FILTER (WHERE installed_at IS NULL)           AS installs_still_missing
FROM latest_patch
GROUP BY platform
ORDER BY median_patch_latency_days DESC;

Metrics

MFA adoption rate Mean time to remediate Open critical vulnerabilities Vulnerability SLA compliance

Integrations

Security & compliance analytics CrowdStrike + Metabase Okta + Metabase Tenable + Metabase

Dashboards

Vulnerability management Identity & access analytics SOC IT compliance

FAQ

How is an IT security dashboard different from a SOC dashboard?
Audience and cadence. A SOC dashboard is for analysts triaging alerts in near real time — detections, MTTA, escalations. An IT security dashboard is for the IT and security teams who manage the estate's hygiene: are machines patched, protected, and behind MFA? It changes daily, not by the minute, and its failures are chronic (a platform that patches slowly) rather than acute (an active intrusion). Keeping them separate stops the hygiene view from being ignored as "not on fire."
Where does the data for this dashboard come from?
Four systems, usually: your MDM or patch tool (Intune, Jamf, a Linux config manager) for device inventory and patch state; your EDR — CrowdStrike or SentinelOne — for agent coverage; your identity provider — Okta or Entra — for MFA and privileged accounts; and your phishing-simulation platform for click and report rates. Sync each into a warehouse on its own schedule and join on a device or user key, rather than pointing Metabase at four separate APIs.
How should I measure patch latency?
Per patch per device, as days from the vendor's release date to the install date — then take the median, not the mean. One appliance nobody can reboot will drag a mean into absurdity while the median stays honest. Pair the median with an SLA-compliance percentage (patched within 14 days for critical patches is a common bar) so a platform can't look good by patching most things quickly and leaving a dangerous tail. Un-installed patches need a row too, or your latency only measures the patches that succeeded.
What counts as good MFA adoption, and why does it stall?
Most estates climb quickly to 85–90% and then stall, because the remainder is the hard part: service accounts that can't do interactive MFA, legacy protocols like IMAP that bypass it, and shared or break-glass accounts. Track MFA adoption against a denominator of accounts that should have MFA — and keep a separate, named list of exemptions with owners and expiry dates. An exemption list that only grows is the real red flag, not the 92% headline number.
Is phishing click rate the right people metric?
It's half of it. Click rate tells you who fell for the simulation; report rate tells you whether the SOC would have heard about a real campaign in time to act. A team with a 5% click rate and a 50% report rate is in better shape than one with 3% clicks and 10% reports, because real phishing needs only one click — your defense is how fast the first reporter raises the alarm. Chart both, and break click rate down by department so training goes where the clicks are.
How do I count privileged accounts without an IGA tool?
Enumerate the sources of privilege directly: members of admin groups in your directory, users with admin roles in your IdP, cloud-account admins from your provider's IAM API, and database superusers. Union them into one table keyed by human owner, since one person with four admin accounts is one person of risk, not four. The count matters less than its direction and its review date — a privileged-account list nobody has pruned in a year almost always contains leavers and forgotten service accounts.
How often should the dashboard refresh?
Daily is right for almost all of it. Patch state, agent coverage, and MFA adoption move on a scale of days, and a daily sync from each source system keeps the dashboard trustworthy without burning API quotas. The exception is anything you would page on — an EDR agent mass-uninstall, say — which belongs in your alerting pipeline, not in a BI tool. Set the sync time before the workday starts, and show a "data as of" timestamp so nobody mistakes yesterday's estate for today's.