Security metrics lose credibility the moment two teams report different numbers for the same measure, and that almost always traces back to a missing definition rather than bad data. This template gives you a single, cross-domain security metrics dictionary: one record per metric with its formula, data source, owner, frequency, target and thresholds, plus the rules for adding, changing and retiring entries. It includes 22 worked definitions across governance, identity, vulnerability, detection and response, awareness, third-party and resilience that you can adopt or replace. It is for security programme managers, GRC teams and the metric owners who supply the numbers. The domain KPI guides explain which metrics to choose; this dictionary is where the agreed definitions live.
How to use this template
- Replace text in square brackets, such as [Organisation], [Metrics Owner], [95%] and [the CMDB], with your own roles, systems and values.
- Keep the dictionary as one controlled register (spreadsheet, GRC tool or wiki table) with the fields in section 4. This page is the policy and the starter content; the register is the living copy.
- Every metric shown on a dashboard, board pack or audit response must cite its dictionary ID (for example MET-IAM-02). If it has no ID, it is not an official metric.
- The worked definitions in section 7 are starting points. Targets and thresholds are placeholders: set them from your own baseline and risk appetite, not from another organisation's numbers.
- Choosing metrics is covered in the Security Metrics and KPIs Programme Guide. This template does not repeat that selection guidance.
1. Purpose
This document establishes the [Organisation] security metrics dictionary as the single authoritative source for the definition of every security metric used in management reporting, risk reporting, audit evidence and supplier reporting. Its purpose is that any metric can be recalculated by someone other than its owner from the same source data and get the same result, that changes to definitions are controlled and visible, and that trends are not broken silently.
2. Scope
This dictionary applies to:
- All security key performance indicators (KPIs), key risk indicators (KRIs) and operational measures reported outside the team that produces them, including board, executive committee, risk committee and regulator reporting.
- Metrics produced by internal teams, managed security service providers and tools on behalf of [Organisation].
- Metrics used as evidence for ISO/IEC 27001 clause 9.1 monitoring and measurement, NIST CSF 2.0 GV.OV-03 performance review, contractual service levels and cyber insurance questionnaires.
Team-internal working measures that are never reported upward are out of scope, but should be promoted into the dictionary before they appear in any external report.
3. Roles and responsibilities
| Role | Responsibilities |
|---|---|
| [CISO] | Owns the dictionary, approves new metrics for board reporting, approves target changes for KRIs. |
| [Metrics Owner] (programme or GRC lead) | Maintains the register, runs quarterly review, checks that published figures cite a valid ID, keeps the change log. |
| Metric owners | Named individual per metric, accountable for calculation, data quality, commentary and remediation when thresholds are breached. |
| Data stewards | Own the source systems (CMDB, identity provider, scanner, SIEM, LMS); confirm extract logic and notify the metric owner of source changes. |
| Internal audit | Tests a sample of metrics each year for reproducibility against the dictionary. |
| Report consumers | Request new metrics through the change process in section 6 rather than asking teams for ad hoc numbers. |
4. Dictionary record structure
Each metric must have one record containing all mandatory fields below. NIST SP 800-55 Vol. 1 recommends documenting a measure's data source, formula, responsible parties and collection frequency; the remaining fields make the record usable for reporting and audit.
| Field | Mandatory | What to record |
|---|---|---|
| Metric ID | Yes | MET-[domain]-[number], never reused after retirement. |
| Name | Yes | Short, unambiguous name as it appears on reports. |
| Question answered | Yes | The decision or risk question the metric informs, in one sentence. |
| Type | Yes | Implementation, effectiveness, efficiency or impact (the four measure types in NIST SP 800-55); KPI or KRI. |
| Formula | Yes | Numerator, denominator and unit, with every term defined. State inclusions and exclusions. |
| Data source | Yes | System, report or query name and the field used. Link to the stored query where possible. |
| Population | Yes | What is counted (for example "production servers in the CMDB with status Live"). |
| Frequency and as-of point | Yes | How often it is calculated and the snapshot moment (for example "monthly, last business day 23:59 UTC"). |
| Owner and data steward | Yes | Named people, not teams. |
| Target | Yes | The level the organisation is aiming for and by when. |
| Thresholds | Yes | Green, amber, red boundaries; for KRIs, the tolerance that triggers escalation. |
| Direction | Yes | Whether higher or lower is better. |
| Audience | Yes | Board, executive, risk committee, operational. |
| Framework reference | No | Control or outcome it evidences (for example CSF 2.0 or SP 800-53 ID). |
| Known limitations | Yes | Data gaps, coverage limits and how they could mislead. |
| Version and change log | Yes | Version number, date, approver and what changed. |
5. Data quality and calculation rules
- MET-5.1 Reproducibility. A metric must be calculable by a second person from the dictionary record and the source data alone. Calculations must use stored, version-controlled queries, not manual spreadsheet edits.
- MET-5.2 Quantitative where reported. Metrics reported to the board or used as KRIs must be quantitative. Qualitative ratings may support commentary but must not be presented as measurements.
- MET-5.3 Defined populations. Percentages must always state the denominator. A coverage metric must also report the size of the population, so that a shrinking inventory cannot improve the percentage.
- MET-5.4 Consistent time reference. All metrics in one report must share the same as-of date, and time-based measures (mean time to detect, remediate or revoke) must define the start and stop events precisely.
- MET-5.5 Medians for durations. Duration metrics should be reported as a median with the 90th percentile, because a small number of long outliers distorts a mean.
- MET-5.6 Data confidence. Each published value must carry a data confidence rating of [High, Medium, Low] set by the metric owner, with the reason recorded when it is not High.
- MET-5.7 Protect metric data. Source extracts and dashboards must be access controlled, because they reveal unpatched systems and control gaps. Board-level aggregates may be shared more widely than system-level detail.
6. Change control, review and retirement
- MET-6.1 New metrics. Requests for new metrics must state the question answered, intended audience and source. The [Metrics Owner] checks for an existing metric that already answers it before creating one.
- MET-6.2 Definition changes. Changes to formula, population or source create a new version. The first report after the change must show the old and new values side by side for at least [one] reporting period, or restate history, and flag the break in trend.
- MET-6.3 Target changes. Target and threshold changes for KRIs require [CISO] approval and must be recorded with the reason. Targets must not be lowered to turn a red metric green without that approval.
- MET-6.4 Quarterly review. The [Metrics Owner] reviews the dictionary at least [quarterly] for ownership, data confidence and relevance, and after significant incidents or organisational change.
- MET-6.5 Retirement. Metrics that no longer inform a decision, or whose target has been met for [four] consecutive quarters with no residual risk, should be retired or moved to operational monitoring. Retired IDs stay in the register marked Retired.
- MET-6.6 Audit. Internal audit samples at least [five] reported metrics each year and recalculates them from the dictionary record.
7. Worked metric definitions
The definitions below show the expected level of precision. Each table lists the core fields; add the remaining mandatory fields from section 4 in your register. Owners are role placeholders.
7.1 Governance and asset coverage
| ID and name | Formula | Source | Owner | Frequency | Target / threshold |
|---|---|---|---|---|---|
| MET-GOV-01 Asset inventory coverage | Devices seen on the network or in cloud accounts that are recorded in the CMDB ÷ all devices seen, as % | Network discovery, cloud asset inventory, [the CMDB] | [IT Asset Manager] | Monthly | [98%]; red below [90%] |
| MET-GOV-02 Policy exceptions overdue | Count of approved security exceptions past their expiry date and not renewed | [Exception register] | [GRC Lead] | Monthly | [0]; red above [5] |
| MET-GOV-03 Risk treatment on time | Risk treatment actions closed by due date ÷ actions due in period, as % | [Risk register] | [Risk Manager] | Quarterly | [90%]; red below [75%] |
7.2 Identity and access
| ID and name | Formula | Source | Owner | Frequency | Target / threshold |
|---|---|---|---|---|---|
| MET-IAM-01 Phishing-resistant MFA coverage | Active workforce accounts with a phishing-resistant method enforced ÷ active workforce accounts, as % | [Identity provider] authentication methods report | [IAM Lead] | Monthly | [95%]; red below [80%] |
| MET-IAM-02 Leaver access removal time | Median and P90 hours from HR termination timestamp to disablement of the primary account | [HR system], [identity provider] audit log | [IAM Lead] | Monthly | Median [4 h]; red if P90 above [24 h] |
| MET-IAM-03 Privileged accounts vaulted | Privileged human accounts under PAM session control ÷ all privileged human accounts, as % | [PAM platform], directory group export | [PAM Lead] | Monthly | [100%]; red below [95%] |
| MET-IAM-04 Non-human identities with owner | Service accounts, API keys and workload identities with a named human owner ÷ all inventoried NHIs, as % | [NHI inventory] | [NHI Programme Owner] | Monthly | [95%]; red below [80%] |
| MET-IAM-05 Access review completion | Access certifications completed by deadline ÷ certifications due, as % | [IGA platform] | [IGA Lead] | Per campaign | [100%]; red below [90%] |
For identity metric selection and the wider set, see the Identity Security Metrics Guide.
7.3 Vulnerability management
| ID and name | Formula | Source | Owner | Frequency | Target / threshold |
|---|---|---|---|---|---|
| MET-VUL-01 Scan coverage | In-scope assets with an authenticated scan in the last [7 days] ÷ in-scope assets in the CMDB, as % | [Scanner], [the CMDB] | [Vulnerability Manager] | Weekly | [95%]; red below [85%] |
| MET-VUL-02 Known exploited vulnerabilities overdue | Open findings matching the CISA KEV catalog past the internal due date of [14 days] | [Scanner] joined to CISA KEV feed | [Vulnerability Manager] | Weekly | [0]; red above [0] on internet-facing assets |
| MET-VUL-03 Critical remediation time | Median and P90 days from first detection to verified fix for critical findings closed in period | [Scanner] finding history | [Vulnerability Manager] | Monthly | Median [7 days]; red if P90 above [30 days] |
| MET-VUL-04 Unsupported software | Production assets running end-of-support operating systems or applications without an approved exception | [Software inventory] | [Infrastructure Lead] | Monthly | [0]; red above [10] |
See the Vulnerability Management Metrics guide.
7.4 Detection and response
| ID and name | Formula | Source | Owner | Frequency | Target / threshold |
|---|---|---|---|---|---|
| MET-SOC-01 Log source coverage | Critical assets sending required logs to the SIEM in the last [24 h] ÷ critical assets, as % | [SIEM] source health, [the CMDB] criticality | [SOC Manager] | Weekly | [98%]; red below [90%] |
| MET-SOC-02 Mean time to detect (as median) | Median hours from earliest evidence of malicious activity to incident declaration, for confirmed incidents closed in period | [Case management] | [SOC Manager] | Quarterly | [Baseline minus 20%] |
| MET-SOC-03 Time to contain | Median hours from incident declaration to containment action recorded, for severity [1-2] incidents | [Case management] | [IR Lead] | Quarterly | Median [4 h]; red above [24 h] |
| MET-SOC-04 Detection coverage of priority techniques | Priority ATT&CK techniques with a tested detection ÷ priority techniques in the threat profile, as % | [Detection repository], purple team results | [Detection Engineering Lead] | Quarterly | [80%]; red below [60%] |
Start and stop events for detection and response times are easy to define inconsistently; see MTTD vs MTTR and the Security Operations Metrics Guide.
7.5 People, third parties and resilience
| ID and name | Formula | Source | Owner | Frequency | Target / threshold |
|---|---|---|---|---|---|
| MET-AWR-01 Phishing report rate | Simulated phishing emails reported by recipients ÷ simulated emails delivered, as % | [Phishing simulation platform] | [Awareness Lead] | Per campaign | [60%]; red below [30%] |
| MET-AWR-02 Mandatory training completion | Staff completing required security training within [30 days] of assignment ÷ staff assigned, as % | [LMS] | [Awareness Lead] | Monthly | [95%]; red below [85%] |
| MET-TPR-01 Critical suppliers assessed | Critical suppliers with a security assessment completed in the last [12 months] ÷ critical suppliers, as % | [TPRM platform] | [Third-Party Risk Lead] | Quarterly | [100%]; red below [90%] |
| MET-RES-01 Backup restore test success | Critical systems with a successful documented restore test in the last [6 months] ÷ critical systems, as % | [Backup platform], test records | [Infrastructure Lead] | Quarterly | [100%]; red below [90%] |
| MET-RES-02 Immutable backup coverage | Critical systems with an offline or immutable backup copy ÷ critical systems, as % | [Backup platform] | [Infrastructure Lead] | Quarterly | [100%]; red below [95%] |
| MET-RES-03 Incident plan exercised | Days since the last exercise of the incident response plan with executive participation | [Exercise records] | [IR Lead] | Quarterly | Below [365]; red above [365] |
8. Exceptions and approval
A metric may be reported without a complete dictionary record only once, marked Provisional, while the record is completed within [30 days]. This document is reviewed at least annually by the [Metrics Owner] and approved by the [CISO]. Version: [1.0]. Approved: [date]. Next review: [date].
Implementation guidance
Where to start.
- Collect every security number reported to the board, executive and risk committees in the last two reporting cycles. This is your initial population; most organisations find duplicates with different definitions.
- Write a full section 4 record for each, starting with the board metrics, and assign a named owner and data steward.
- Recalculate each metric independently from the record (MET-5.1). Fix the definition, not the number, where results differ.
- Publish the next board report with dictionary IDs on every figure and a data confidence rating (MET-5.6).
- Run the first quarterly review (MET-6.4) and retire metrics that answer no decision question.
Testing and rollback. Run old and new definitions in parallel for one period before switching (MET-6.2). If a new definition proves unreliable, revert to the prior version, which remains in the change log, and mark the affected period's confidence as Low.
Small and large organisations. A small organisation can run the dictionary as one spreadsheet tab with 8 to 12 metrics, typically MET-GOV-01, MET-IAM-01, MET-IAM-02, MET-VUL-02, MET-AWR-02 and MET-RES-01. Large organisations should hold it in a GRC platform, link each record to its stored query, and federate ownership by business unit while keeping one formula per metric ID.
Common failure patterns.
- Coverage without population: reporting 99% patched while the inventory has quietly dropped a third of the estate. MET-5.3 prevents this.
- Means for durations: one stale ticket moves a mean remediation time by days; MET-5.5 requires median and P90.
- Silent redefinition: a tool change alters the scanner's severity scale and the trend line jumps. MET-6.2 forces a visible break.
- Team-named owners: "IT Ops" owns nothing in practice; name a person.
- Measuring activity, not outcome: counts of alerts or scans run say little about risk. Pair each with an effectiveness or impact measure, as NIST SP 800-55 describes.
Measuring the dictionary itself. Track the percentage of reported figures citing a valid dictionary ID, the percentage of records with a named owner and High data confidence, the number of audit recalculation mismatches, and the count of definition changes per quarter.
| Dictionary practice | Framework reference |
|---|---|
| Defined measures of performance | NIST SP 800-53 Rev. 5 PM-6 Measures of Performance |
| Ongoing monitoring feeding the metrics | NIST SP 800-53 Rev. 5 CA-7 Continuous Monitoring; PM-31 Continuous Monitoring Strategy |
| Performance review and adjustment | NIST CSF 2.0 GV.OV-03; improvement from evaluations ID.IM-01 |
| Monitoring, measurement, analysis and evaluation | ISO/IEC 27001 clause 9.1, with guidance in ISO/IEC 27004:2016 |
| Measure types, data sources and programme workflow | NIST SP 800-55 Vol. 1 and Vol. 2 |
Sources. This template draws on NIST SP 800-55 Vol. 1 Measurement Guide for Information Security: Identifying and Selecting Measures and Vol. 2 Developing an Information Security Measurement Program (both final, December 2024), ISO/IEC 27004:2016 Monitoring, measurement, analysis and evaluation (a revision is at draft stage), NIST Cybersecurity Framework 2.0, NIST SP 800-53 Rev. 5 and the CISA Known Exploited Vulnerabilities Catalog. For turning the dictionary into board reporting, see the Board Cyber Risk Reporting Guide and the Key Risk Indicators for Cyber Risk Guide.
Related NHI Mgmt Group resources: Security Metrics and KPIs Programme Guide · Measuring security control effectiveness · ISO/IEC 27003 and 27004 Guide · Board Cyber Report Template