How to build Drata dashboards in Metabase

{
  "mcpServers": {
    "drata": {
      "url": "https://mcp.drata.com/mcp/"
    }
  }
}

# Install the Metabase CLI
npm install -g @metabase/cli

# Log in (opens your browser; requires Metabase v62+)
mb auth login --url https://your-metabase.example.com

# Load a monitoring-test-results export — creates a table AND a model
mb upload csv --file drata-monitoring-test-results.csv --collection root

# Refresh that same table later from a new export
mb upload replace <table-id> --file drata-monitoring-test-results.csv

Create a polished Metabase dashboard for Drata compliance analytics.
Work end to end: get the data into Metabase if it isn't there yet, then build.

Goal: Help security and engineering leaders understand control pass rates, failing controls, personnel compliance, and audit readiness from Drata data.

Step 1 — Find or load the data:
- First, check what already exists in Metabase (search for drata tables and
  models). If durable Drata data is already present — synced from a warehouse
  or uploaded earlier — use it and skip to Step 2.
- If nothing is there, pull a scoped, summarized export with the Drata MCP Server:
  monitoring test results, plus controls, frameworks, personnel.
  Prefer aggregated or entity-grain views over raw events. Write each result to a
  CSV, then load it with the Metabase CLI — run "mb upload csv --file <export>.csv"
  so each upload creates a table and a ready-to-query model. Use "mb upload replace
  <table-id> --file <export>.csv" to refresh an existing table instead of creating
  duplicates.

Step 2 — Inspect before querying:
Do not assume exact table or column names. Inspect available fields, severities,
statuses, timestamps, and whether snapshots or history exist before creating
duration or trend cards.

Important:
- Build on whatever data is present; don't claim Metabase connects natively to
  Drata — it reads a database or CLI-uploaded tables.
- Never try to load raw security telemetry or event firehoses into Metabase; use
  findings, detections, entities, and daily rollups.
- Only compute durations (time to remediate, time to triage, time to detect)
  when the required timestamps exist.
- Exclude test environments and suppressed or accepted-risk items from headline
  cards, and keep them visible in a labeled register instead.
- A single CSV is a point-in-time snapshot: only build trend cards if there is a
  usable date column or multiple periods have been uploaded.

Dashboard title: Drata Compliance Overview

Sections:
1. Executive summary: Pass rate by framework; Failing controls; Tests failing
   >14 days; Personnel compliance; Vendor reviews open.
2. Controls: Pass rate by framework and category; newly failing this week.
3. Remediation: Failing controls by owner and age; time to fix.
4. Personnel: Training completion; MFA adoption; onboarding/offboarding tasks.
5. Trend: Daily snapshot history of pass rate by framework.

Filters: Date range, Severity, Status, Team or owner, Environment or asset group.

Output: Build the dashboard if you have permission; otherwise provide the exact
questions, SQL, model definitions, and layout. Include caveats for any metric
that cannot be calculated from the available data.

Latest test result per control, rolled up per framework.

WITH latest AS (
  SELECT DISTINCT ON (control_id, framework)
    control_id, framework, status
  FROM control_results_daily
  ORDER BY control_id, framework, snapshot_date DESC
)
SELECT
  framework,
  COUNT(*) AS monitored_controls,
  COUNT(*) FILTER (WHERE status = 'passing') AS passing,
  ROUND(
    100.0 * COUNT(*) FILTER (WHERE status = 'passing')
    / NULLIF(COUNT(*), 0), 1
  ) AS pass_rate_pct
FROM latest
GROUP BY framework
ORDER BY pass_rate_pct ASC;

The remediation queue with accountability attached.

WITH history AS (
  SELECT
    control_id,
    framework,
    owner,
    MAX(snapshot_date) FILTER (WHERE status = 'passing') AS last_passed_on,
    MIN(snapshot_date) FILTER (WHERE status = 'failing') AS first_failed_on
  FROM control_results_daily
  WHERE snapshot_date >= CURRENT_DATE - INTERVAL '90 days'
  GROUP BY control_id, framework, owner
  HAVING BOOL_AND(status = 'failing') FILTER (
    WHERE snapshot_date >= CURRENT_DATE - INTERVAL '14 days'
  )
)
SELECT
  control_id,
  framework,
  owner,
  -- The current streak starts the day after the most recent pass, so a
  -- control that failed, was fixed, then broke again isn't aged from the
  -- older failure. Never passed in the window: fall back to first failure.
  COALESCE(last_passed_on + 1, first_failed_on) AS failing_since,
  CURRENT_DATE - COALESCE(last_passed_on + 1, first_failed_on) AS days_failing
FROM history
ORDER BY days_failing DESC;

Training and MFA completion from people records.

SELECT
  department,
  COUNT(*) AS people,
  ROUND(100.0 * COUNT(*) FILTER (WHERE training_complete)
    / NULLIF(COUNT(*), 0), 1) AS training_pct,
  ROUND(100.0 * COUNT(*) FILTER (WHERE mfa_enrolled)
    / NULLIF(COUNT(*), 0), 1) AS mfa_pct
FROM people_compliance
WHERE offboarded_at IS NULL
GROUP BY department
ORDER BY mfa_pct ASC;