ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
NIST SP 800-55 is the reference for building security indicators that mean something. Published in December 2024 as two volumes replacing the 2008 Revision 1, the Measurement Guide for Information Security sets out four types of measure, a ten-field format for documenting each one, the characteristics that make a measure trustworthy, and — in Volume 2 — how to run a measurement program that survives its first year. Most cybersecurity KPI and KRI programs would be improved by adopting its measure format alone. This guide explains what NIST SP 800-55 contains, the four measure types and when each applies, the documentation fields and why each exists, how measures are prioritized and evaluated, and how to use it alongside the NIST Cybersecurity Framework.
NIST released Volume 1, Identifying and Selecting Measures, and Volume 2, Developing an Information Security Measurement Program, together in December 2024, superseding SP 800-55 Revision 1 of July 2008. Volume 1 covers the development, selection and prioritization of measures, both quantitative and qualitative, with guidance on data analysis and on impact and likelihood modelling. Volume 2 covers the measurement program: roles, the process, and how results feed decisions. Both are voluntary guidance. Neither prescribes a list of measures; they prescribe how to build, document and judge the measures you choose — which is exactly the part most organizations skip.
Section 3.3 of Volume 1 separates measures into four types, and the type decides what a measure can be used for.
| Type | Definition (SP 800-55 Vol. 1) | Typical form | Example | Use it to answer |
|---|---|---|---|---|
| Implementation | Demonstrates the progress of specific controls | Percentage or yes/no | % of systems with an approved system security plan; % of servers on the standard configuration | Is the control deployed? |
| Effectiveness | Evaluates how well implementation processes and controls are working and whether they are meeting desired outcomes | Quantitative, or qualitative yes/no; often several data points | % of phishing simulations reported within an hour; % of critical vulnerabilities remediated within SLA | Is the control working? |
| Efficiency | Examines the timeliness of controls — the speed at which they give useful feedback and how quickly issues are addressed | Time-based, quantitative | Mean time to detect; mean time from patch release to deployment | Is the control fast enough? |
| Impact | Articulates the impact of information security on the organization’s mission, goals and objectives | Currency and business value | Cost savings from the program; costs incurred from events; regulatory fines; business value gained or lost | Is the program worth it? |
The guide is explicit that implementation measures come first and are never fully retired — “they are a record of what exists and what needs improvement” — and that once implementation is complete, the program broadens to effectiveness, efficiency and impact. Effectiveness and efficiency together are called Program Results. The practical reading: an organization reporting only implementation percentages has a coverage dashboard, not a measurement program; the effectiveness and efficiency measures are where security performance is actually seen, and impact measures are what a board can weigh against cost.
Section 3.1.1 of Volume 1 says organizations “document their measures in a standard format to ensure the repeatability of measures development, collection, and reporting activities”, and offers the following fields as a common starting point.
| Field | What it records | Why it matters |
|---|---|---|
| Unique ID | An identifier for tracking and sorting, possibly referencing another source | Measures get renamed; IDs do not |
| Goal | The strategic and/or information security goal the measure supports | Ties the number to something the organization wants |
| Scope | What is in and out of scope | Explains aggregated risk and distinguishes total risk from what is being measured |
| Measure | A numeric statement beginning ‘percentage’, ‘number’, ‘frequency’, ‘average’ or similar | Forces the measure to be a quantity, not a topic |
| Type | Implementation, effectiveness, efficiency or impact | Sets what the measure can be used to conclude |
| Formula | The calculation that yields the number | Two people computing the measure get the same answer |
| Target | A range or bound; a threshold for a satisfactory rating, with interim and final targets where useful | The risk-appetite statement behind the RAG status |
| Implementation evidence | The data elements and questions used to compute and validate the measure, for manual or automated collection | Makes the measure auditable |
| Time-based reference | When the measure was taken; how often data is collected, analysed and reported | Frequency matched to the rate of change; expired data identified |
| Responsible parties | Information owner, collector, and the customer of the measure | Someone owns the number and someone acts on it |
Compare that list with the fields in most KRI spreadsheets — title, value, RAG — and the gap is the reason so many indicators are argued about rather than acted on. A measure record with a formula, a target, an evidence source and a frequency is one that can be recomputed, audited and trended; a title with a colour is an opinion.
Section 3.2 lists characteristics that “collectively define the foundation of robust security measurement”: consistency in methodology and criteria across evaluators; a time-based reference so measures can be compared over time; replicability under identical conditions; and unit-based standardization so datasets are comparable. The guide also spends a chapter on data quality — Table 3 lists data cleaning methods for reducing uncertainty — and on the difference between quantitative measurement and qualitative or semi-quantitative assessment, with a Stevens scale of measurement (nominal, ordinal, interval, ratio) to make clear which arithmetic a measure supports. A maturity score on a 1–5 ordinal scale, for instance, cannot legitimately be averaged; NIST SP 800-55 says why.
Volume 1’s stated purpose includes “the measures prioritization process and how to evaluate measures”. The prioritization logic is that measures compete for collection effort and attention, so each should be judged on its link to a goal, the availability and quality of its data, the cost of collecting it and whether anyone will act on the result. A measure with no customer — nobody who changes a decision when it moves — is retired. The evaluation logic is that measures themselves are reviewed periodically: does the formula still reflect the control, has the target been met so consistently that the measure should be replaced by a more demanding one, has the data source changed. Both processes are what Volume 2 turns into a program cycle.
The two publications fit together without either referencing the other in detail. CSF 2.0 gives 106 subcategory outcomes across six functions; SP 800-55 gives the method for measuring progress toward any of them. In practice each measure’s Goal field cites a CSF subcategory, the Type field says whether it is an implementation measure (is the outcome’s control deployed) or an effectiveness or efficiency measure (does it work, how fast), and the Target field carries the tier or profile the organization is aiming at. Our guide to NIST CSF maturity levels covers the target-setting side; cybersecurity metrics: the four types shows how the measure types appear in practice.
What is NIST SP 800-55?
NIST’s Measurement Guide for Information Security, published December 2024 in two volumes — Volume 1 on identifying and selecting measures, Volume 2 on developing a measurement program — superseding Revision 1 of 2008.
What are the four types of measure?
Implementation (is the control deployed), effectiveness (is it working), efficiency (is it timely) and impact (what is it worth to the mission). Effectiveness and efficiency together are called Program Results.
Does SP 800-55 give a list of recommended metrics?
No. It gives the method: the measure types, a ten-field documentation format, the characteristics of trustworthy measures, and prioritization and evaluation processes. The measures themselves are chosen by the organization against its goals.
Is it mandatory?
It is voluntary guidance. US federal agencies use it in support of FISMA reporting; other organizations adopt it as the reference for KPI and KRI design, often alongside the Cybersecurity Framework.
How does it relate to KRIs and KPIs?
Every KRI or KPI is a measure in SP 800-55 terms. Documenting each in the ten fields — especially type, formula, target and evidence — is the fastest way to make an existing indicator set defensible.
Use NIST SP 800-55 as the specification for your indicators rather than as reading: type every measure, document it in the ten fields, add effectiveness and efficiency measures beside the implementation percentages, respect the scale before doing arithmetic, and retire anything nobody acts on. The result is a measurement program in the guide’s sense — and a set of indicators that will hold up when a board, an auditor or a regulator asks how the number was made.
153 key risk and performance indicators keyed to NIST CSF subcategories, each documented with a calculation formula, reporting frequency, green–amber–red thresholds, evidence required and an owner — the SP 800-55 fields — are in the Excel-based Critical IT and Cybersecurity Indicators templates, or start with the free templates.
September 20, 2026
September 20, 2026
September 19, 2026
September 19, 2026
September 19, 2026