Compliance metrics

Help IDs: compliance.tab.metrics, compliance.metrics.search

The Metrics tab is a two-pane picker. The left pane shows what's in the current profile. The right pane shows the full library of ~90 available metrics. You add and remove metrics with per-row buttons; changes save immediately.

[Image omitted: Metrics tab with the library on the right and picker on the left]

What is a metric

One row of HealthCheck.Metric. Each metric is a single check backed by exactly one stored procedure that reads from the collected Collector.* tables and evaluates a threshold rule.

Two metric families

Every shipped metric falls into one of two naming buckets.

Native Metric* metrics

Minion-authored checks written specifically for the Health Check engine. Examples:

• MetricSysadminCount — sysadmin count vs threshold
• MetricTrustworthy — is the Trustworthy bit on
• MetricSpConfigureSetting — parametric sp_configure check (Ad Hoc Distributed Queries, CLR Enabled, Cross DB Ownership Chaining, xp_cmdshell, …)
• MetricSARenamed — has the sa login been renamed
• MetricLoginDisabled — is sa disabled
• MetricLatestServicePack — is the instance current on patches

These are the productized "opinion" of the tool — one SP per rule.

Microsoft Vulnerability Assessment (VA*) metrics

Direct mappings to the rule IDs SSMS's built-in Vulnerability Assessment produces. Examples:

These are the industry-standard controls — useful when an auditor asks "which CIS control are you measuring here?" You can point at the VA rule number.

MeasureLevel — Instance vs Database

Every metric runs in one of two loops:

• Instance — the SP evaluates once per SQL Server instance. Example: MetricSysadminCount (fleet-wide instance property).
• Database — the SP evaluates once per database on each instance in scope. Example: MetricDatabaseOwner (per-DB property).

A few older metrics have no MeasureLevel declared (empty) because the SP author didn't set it; the UI shows them as blank. They still run, but Instance is the default.

The MeasureLevel drives what "unchecking a system DB in Scope" actually excludes. Instance-level metrics ignore the DB list entirely.

Anatomy of a metric row

[Image omitted: Anatomy of a metric row with the overrides chip]

Each row shows:

• Metric name (main title)
• MeasureLevel — small Instance or Database tag
• Backing SP — mono-font HealthCheck.MetricSysadminCount
• N overrides chip (blue) — appears when this metric has one or more rows on the Thresholds tab for the current profile
• Active / Off button — the IsActive toggle on the profile's ReportMetric row
• ✕ button — unlinks the metric from the profile

"In this profile" pane

The metrics currently linked to the selected profile via HealthCheck.ReportMetric. Sorted alphabetically. When you add a metric it drops into its correct alphabetical position — no scrolling to find your newest addition.

Active / Off

Toggling this flips the IsActive bit on the ReportMetric row without unlinking the metric. Off metrics stay in the profile but are skipped when the profile runs. Use this when you want to temporarily quiet a check — for example during a maintenance window you know will trip it — without losing its config.

Remove (✕)

Deletes the ReportMetric row for that metric. Any MetricThreshold rows for the same (ReportName, MetricID) are left in place — if you re-add the metric later, those overrides come back. If you want a clean slate, delete the threshold rules on the Thresholds tab first.

The "N overrides" chip

When the Thresholds tab has any rows for this metric within the current profile, a blue chip renders next to the metric name showing the count. Hovering the chip explains why it's there.

This lets you see at a glance which metrics have per-server tuning. In a fleet with dozens of profile-metric-server combinations, it's the quickest way to answer "have I already customized this?"

"Available metrics" pane

The full metric library from HealthCheck.Metric, filtered to hide any metric already in the current profile.

Search box

Case-insensitive substring match across:

• Metric name (MetricName)
• Backing SP (ProcName)
• MeasureLevel

Some useful searches:

Add (+)

Links the metric to the profile with IsActive = 1 and appends it to the "In this profile" pane at its alphabetical slot. The picker refreshes and the added metric disappears from Available.

Example configurations

Example — CIS-aligned custom profile

Cloned from CIS Audit, most metrics retained. The client doesn't need TDE checks because encryption is out of scope, so those come out:

Removed from profile: - VA1219 — Transparent data encryption should be enabled - VA1221 — Database Encryption Symmetric Keys should use AES algorithm - VA1222 — Cell-Level Encryption keys should use AES algorithm - VA1224 — Asymmetric keys' length should be at least 2048 bits

Left in profile: - Everything else CIS ships with.

Result: 26 metrics active, four + Add clicks away from restoring the full CIS set if requirements change.

Example — Login-only spot check

Purpose-built minimal profile for a specific compliance requirement.

Metrics linked: - Disable the sa Login Account - Rename the sa Login Account - Sysadmin Count - MUST_CHANGE ON for All SQL Logins - CHECK_EXPIRATION ON for All SQL Logins in Sysadmin - CHECK_POLICY ON for All SQL Logins - Login Auditing for Both failed and successful logins - Weak Password (VA)

Seven metrics. Runs in seconds. Every one has an override chip because sysadmin counts differ per environment.

Common gotchas

• Removing a metric doesn't remove its thresholds. The chip goes away, but the MetricThreshold rows sit there quietly until you delete them or re-add the metric.
• Turning a metric Off is different from Removing it. Off preserves the link and thresholds. Remove deletes the link.
• Available list hides duplicates. If a metric doesn't appear in Available, it's already in the profile. Look at the left pane.
• Search is substring, not regex. sp.*configure won't match; type SpConfigure.

Related: Compliance overview, Compliance thresholds, Compliance backend.