Identity Health Dashboards: What to Monitor and Why
The lightweight identity health dashboards I build to maintain audit readiness and catch IAM drift before it becomes a compliance finding.
If you only look at your identity systems when an auditor asks, you’re already behind. Here’s what I monitor continuously and how I keep it lightweight.
The Five Signals
Every identity health dashboard I build tracks five things: orphaned accounts (accounts with no owner in HRIS), stale accounts (no login in 90 days), over-privileged accounts (admin access that doesn’t match role), MFA coverage gaps, and SSO bypass usage. These five signals catch 90% of identity drift.
Keep It Simple
You don’t need a SIEM for this. A scheduled script that queries Okta’s API, compares against HRIS data, and writes results to a shared dashboard is enough. I’ve built these with Python + a simple web frontend, and with Okta Workflows pushing to a Google Sheet. The tool doesn’t matter; the discipline of checking daily does.
Audit Readiness as a Byproduct
When SOC 2 auditors ask “how do you ensure terminated employees lose access?”, I don’t scramble to pull evidence. I show them the dashboard with 12 months of daily snapshots showing time-to-deprovision metrics. The audit becomes a formality because the controls are visibly operational.
The Runbook Connection
Each dashboard signal has a linked runbook. Orphaned account detected → runbook to investigate, confirm with HR, and remediate. Over-privileged account → runbook to verify with the user’s manager and adjust. This closes the loop between detection and action, which is what auditors actually care about.
Written by Alex Davenport
alexdavenport.dev