- The operating practices already running, since a metric can only measure work that exists
- Read access to the systems of record — identity provider, inventory, backup logs — each metric draws from
- The leadership meeting or report where the numbers will actually be looked at
ATL-007REGISTEREDITORIAL REVIEW COMPLETE
Security Metrics and KPI Register
A register of the handful of numbers leadership actually watches — each metric with a formula, a system-of-record data source, a directional target, a collection frequency, and an owner — so 'are we getting better?' is answered by trend lines instead of impressions.
Using this artifact
Purpose, inputs, and completion
Purpose. Practices that operate produce numbers, and the numbers are how a small organization knows its security work is real rather than remembered. This register defines the few metrics worth collecting — formula, source, target, owner — and gives their values a place to accumulate into trends. It is the difference between 'we do backups' and 'our last successful restore test was 21 days ago and the number has never exceeded 45'.
When to use it. Pick a handful of metrics tied to the practices you actually run, define each one against a system of record, and collect on the stated schedule even in busy months — an interrupted trend is the first sign the underlying practice is slipping too. Put the numbers in front of leadership at a standing meeting, and prune the register quarterly: a metric nobody acts on is cost, not insight.
- Start with three to five metrics tied to decisions leadership actually makes; a short register collected beats a long one abandoned.
- Define each metric as a formula against a named system of record, so two people collecting it get the same number.
- Set directional targets — rising toward, falling toward, never above — rather than arbitrary point goals.
- Assign one owner per metric who collects on schedule and logs the value, and review the register quarterly for metrics that have stopped earning their collection cost.
Keeping it honest
Evidence, validation, and failure modes
- A dated register of defined metrics with owners, sources, and targets
- A collection log whose history demonstrates ongoing monitoring rather than a one-time snapshot
- Trend records that ground leadership security discussions in numbers
- Ask two different people to collect the same metric independently from its stated source; materially different numbers mean the definition, not the people, needs fixing.
- Check each metric's last-collected date against its stated frequency; any metric two cycles behind is decorative and should be fixed or retired.
What looks done but is not
- Vanity metrics — counts of blocked emails and scanned packets — that always look impressive and never inform a single decision.
- Metrics defined against someone's recollection ('about 90% of laptops') instead of a system of record, so the trend measures optimism.
- A register that only ever grows: nobody retires dead metrics, collection burden climbs, and eventually the whole register quietly stops.
Mapped relationships
Practices and requirements this artifact relates to
Brilliant at the Basics practices
NIST SP 800-171 Rev. 2
NIST SP 800-171 Rev. 3
Relationships are mapped support, not equivalence: completing this artifact documents work relevant to these requirements and does not by itself address any of them. Retention: Retain collected values for at least two years; the trend is the evidence, and a trend needs history.
Full document
Preview — exactly what prints
REGISTER · GOVERNANCE & PROGRAM MANAGEMENTv1.0 · REVIEWED 2026-08-06
Security Metrics and KPI Register
Brilliant at the Basics Resource Center · brilliantatthebasics.us · published by inDirectIT, Inc.
Independent educational material. Not affiliated with, sponsored by, approved by, or endorsed by the U.S. Department of War. Does not establish compliance, certification, or contractual standing.
Purpose
Practices that operate produce numbers, and the numbers are how a small organization knows its security work is real rather than remembered. This register defines the few metrics worth collecting — formula, source, target, owner — and gives their values a place to accumulate into trends. It is the difference between 'we do backups' and 'our last successful restore test was 21 days ago and the number has never exceeded 45'.
How to use it
Pick a handful of metrics tied to the practices you actually run, define each one against a system of record, and collect on the stated schedule even in busy months — an interrupted trend is the first sign the underlying practice is slipping too. Put the numbers in front of leadership at a standing meeting, and prune the register quarterly: a metric nobody acts on is cost, not insight.
How to use this register
Each row defines one metric; the collection log below accumulates its values. The register answers 'what do we measure and why'; the log answers 'what is the number and which way is it moving'. Both matter — a reviewer reads the register for design and the log for proof of operation.
Directional targets beat point targets
'Rising toward 100%' and 'never older than 90 days' survive contact with reality better than '95% by Q3'. A directional target keeps the conversation on the trend — the thing that actually indicates whether the practice is operating — instead of on negotiating the number.
The register
The working table. The example rows are drawn from practice operating metrics; keep the ones that fit your environment and replace the rest.
Rows beginning EXAMPLE: show the expected shape — replace them with your own.
| Metric | Definition / formula | Data source | Target (directional) | Frequency | Owner | Current value | Trend | Last collected |
|---|---|---|---|---|---|---|---|---|
| EXAMPLE: Phishing-resistant MFA coverage — tier 1 accounts | Accounts with phishing-resistant MFA enforced ÷ total tier 1 accounts | Identity provider policy report | Rising toward 100% | Monthly | Identity admin | |||
| EXAMPLE: Restore-test age | Days since the last successful restore test of a critical system | Backup runbook log | Falling; never above 90 | Monthly | IT leader | |||
| EXAMPLE: Unknown-device count | Devices seen on the network but absent from the asset inventory | Discovery scan reconciled against inventory | Falling toward zero | Weekly | IT leader | |||
Choosing metrics worth collecting
- Name the decision each metric informs
- If no plausible number would change anyone's behavior, the metric is decoration.
- Draw from a system of record, never from recollection
- A report someone can re-run beats an estimate someone once made.
- Prefer metrics that can get worse
- A number that only rises — total training sessions ever held — is a odometer, not an instrument.
- One named owner per metric
- Cap the register at what will actually be collected in a bad month
- Five collected metrics outperform fifteen aspirational ones.
Collection and review rhythm
Values land here on schedule; the quarterly review prunes and adjusts the register itself.
Collection log
| Metric | Collection date | Value | Collected by | Notes (anomalies, definition changes) |
|---|---|---|---|---|
Bring the trends — not just the latest values — to a standing leadership meeting. At the quarterly register review, ask of each metric: did anyone act on this since last quarter? Two consecutive 'no's is the retirement criterion, and retiring a dead metric is program hygiene, not failure.
Document control, version history, and approval
An artifact without an owner, a review date, and an approval trail is a snapshot, not a record. Complete this section before the document is used, and update it at every review.
| Field | Entry |
|---|---|
| Document owner (named person) | |
| Suggested owner role | IT leader |
| Approval authority | Executive sponsor |
| Review frequency | Each metric collected at its own stated frequency; the register itself reviewed quarterly, retiring any metric that no longer informs a decision |
| Next scheduled review | |
| Storage location of the completed document | |
| Retention | Retain collected values for at least two years; the trend is the evidence, and a trend needs history. |
Version history
| Version | Date | Author | Summary of change | Approved by |
|---|---|---|---|---|
Review and approval
| Reviewed by | Role | Date | Signature / initials |
|---|---|---|---|
Complete this offline — and mind what you write down
Fill this in inside your own environment, not on any public website or unapproved cloud tool. A completed copy may reveal your security posture: never include CUI, export-controlled data, credentials or keys, unremediated vulnerability details, network diagrams, or customer-sensitive information beyond what the artifact strictly needs, and store the completed document with the same care as the systems it describes.
What completing this artifact does and does not do
This is independent educational material. Completing it documents your work and produces records a reviewer can examine — it does not, by itself, implement a safeguard, satisfy any NIST SP 800-171 requirement, establish compliance with DFARS or CMMC, or replace your own analysis within your defined system boundary. Requirement references are mapped relationships, not equivalence claims. Tailor every section to your technical, operational, contractual, regulatory, and safety requirements.