Give every security metric a short definition card covering its name, the question it answers, its formula, data source, owner, review cadence, thresholds and the action it triggers. Most disputes about numbers are really disputes about definitions that were never written down.
Why cards beat tribal knowledge
Metrics drift. Someone changes a filter, a scanner is replaced, a team renames a severity. Six months later the chart has a kink and nobody knows why. A card makes the definition visible and gives you a place to log changes.
The template
Copy this into any wiki page:
- Name. Short and specific. "Open reachable criticals past SLA", not "Vulnerability health".
- Question it answers. One sentence in plain words.
- Formula. Numerator, denominator, unit, time window.
- Inclusions and exclusions. Which assets, which severities, which environments.
- Clock rules. When timing starts and stops. Link to your SLA policy.
- Data source. The system of record, and how often it refreshes.
- Owner. A named role, not a team alias.
- Cadence. How often it is reviewed, and in which meeting.
- Thresholds. What counts as green, amber, red, and why those lines.
- Action. What happens when it turns red.
- Counter metric. The number that would reveal gaming.
- Change log. Date and reason for every definition change.
A worked example
Name: Internet facing services with an exploited vulnerability open.
Question: Are any of our public services running something attackers are using right now?
Formula: Count of services reachable from the internet with at least one open finding that appears in a known exploited list, divided by total internet facing services. Weekly snapshot.
Source: Asset inventory joined with the vulnerability findings export.
Owner: Head of platform engineering.
Threshold: Any non zero count is red.
Action: Open an incident ticket, apply a mitigation within one working day, schedule the fix.
Counter metric: Number of services removed from the internet facing list in the last 30 days, to spot services hidden from scope.
Keep the card honest
Review cards twice a year. Remove any metric whose action line has not been used. Merge near duplicates. A smaller set that people trust beats a long list nobody quite believes.
Use cards in the review meeting
Start each metric discussion by reading the question line aloud. It sounds silly and it keeps the conversation on decisions rather than on chart shapes. If nobody can say what to do when the number moves, mark it for removal.
See also the vanity metric checklist.
Start with the five that matter
You do not need cards for every number on day one. Write them for the five metrics that appear most often in leadership reports. Doing this once usually exposes hidden disagreements, such as two teams counting different environments as production. Settle those and note the decision in the change log.
When someone proposes a new metric, require a draft card first. If the proposer cannot fill in the action line, that is a useful answer in itself, and it saves a chart nobody will use.
Quick check
Who should own a metric card?
The person who can change the outcome, usually an engineering or platform lead, with security as the reviewer.
Where should the cards live?
Next to the dashboard they describe, so a viewer is one click from the definition.
Last reviewed: 19 October 2026.
