A guide to choosing what to measure, defining it so it holds up, and reporting it to the people who act on it.
There aren't a ton of great resources on developing metrics, measurements, and indicators in the information security domain. That's why I originally wrote The Security Metrics Workbook, which distills some of the things I've learned on selecting and implementing metrics within a security program. This guide is an extension of that work: a continually evolving and updated reference on figuring out what to measure in relation to information security.
Before defining a metric, ask why you are measuring it and what decision it supports. That intent is what separates a useful metric from dashboard clutter. In practice, most security metrics serve one (or more) of three functions.
Track progress toward defined goals, so leadership can see whether investments and strategic initiatives are delivering the outcomes the organization expects.
Detect changes in exposure and emerging threats. They act as early warnings, giving teams time to prepare and respond before meaningful loss occurs.
Assess how safeguards are performing and what they are worth. Operational and actionable, they drive how controls get tuned and improved.
The same metric can serve any of the three. The number does not change, your intent does, which is why two organizations can track an identical measure for entirely different reasons.
Performance Indicators, which track progress toward defined goals, operate at three levels: Strategic, Functional, and Operational. Each level answers to a different audience, and together they connect the work a team does day to day back to the outcomes the enterprise cares about.
Enterprise outcomes set by executives.
Department-level goals that support strategic outcomes.
Team-level measures that track progress toward higher-level goals.
| Level | Example metric |
|---|---|
| Strategic | Reduce mean time to respond by 25 percent year over year. |
| Functional | Automate 60 percent of incident triage activities. |
| Operational | Percentage of alerts automatically classified by tooling. |
Risk Indicators, which serve as early warnings by measuring changes in exposure and emerging threats, can be broken into three primary types: Source Indicators, Event Indicators, and Impact Indicators.
Underlying conditions or weaknesses that create exposure.
Patterns that increase the likelihood of an adverse event.
Signals related to the magnitude of loss if an event occurs.
| Type | Example signals |
|---|---|
| Source | Privileged accounts without MFA, unsupported systems, orphaned cloud assets. |
| Event | Spikes in authentication failures, rising phishing click-through rates. |
| Impact | Concentration of critical assets, single points of failure in infrastructure. |
Control Indicators, which assess how safeguards are performing and what they are worth, can be broken into four types: Implementation, Effectiveness, Efficiency, and Impact. Each of these four types of control indicators measure a different aspect of the control, and in concert provide a holisitic view of the control's performance.
Measures tangible outcomes of security controls on risk posture, business performance, etc.
Assess how quickly a control produces useful feedback and how rapidly detected issues are addressed.
Assess whether controls that have been put in place are successfully achieving the desired outcome.
Establish coverage by confirming the existence and deployment status of controls.
| Type | Example metric |
|---|---|
| Implementation | Percent of privileged accounts with MFA enabled. |
| Effectiveness | Percent of phishing emails blocked before reaching the inbox. |
| Efficiency | Mean time to detect, and percent of vulnerabilities remediated within SLA. |
| Impact | Reduction in high-risk vulnerabilities over time. |
Metrics collected ad hoc tend to reflect whatever data was easiest to reach. A development process does the opposite: it turns the complexity of your environment into a defensible set of metrics that reflect your own goals, risks, and operating realities. It breaks into three deliberate stages.
Identify and catalog candidate metrics, working from governance documents, stated goals and objectives, and interviews with the stakeholders who will use them.
Narrow that catalog to the metrics worth formally implementing, weighing the value each one delivers against the effort required to produce it.
Define the surviving metrics properly and assign ownership, so each has a stated purpose, a calculation, a frequency, a data source, and a named owner.
The three stages are a loop, not a project. As goals shift, systems change, and stakeholders come and go, you run the cycle again and the metric set moves with the program rather than falling behind it.
Discovery is where the candidate list comes from. It works by weaving together three sources: the written rules, the stated priorities, and the lived reality of the people doing the work. Each catches something the others miss.
Policies, standards, and procedures record what the organization has already committed to. They are among the richest sources of candidates, because every obligation implies something someone is expected to meet.
Stated business goals show what leadership is actually trying to achieve. Anchoring to them keeps the metric set pointed at outcomes rather than at whatever activity happens to be easy to count.
Conversations surface what documents and goals cannot. Teams hold very different views of what matters, and people who see their concerns reflected early tend to champion the program rather than resist it.
Used together, the three map the space of what could be measured. The output of discovery is a concrete candidate metric list, which is the raw material prioritization works on.
Discovery gives you raw ideas. Prioritization prunes them into a set your program can actually sustain. Some candidates are valuable but hard to measure; others are easy to measure but tell you nothing. Track everything and you drown in data without driving outcomes.
The goal is to systematically narrow the candidate list down to the metrics that balance value against the effort of producing them.
Despite the abundance of security data, not every metric is worth tracking. Some provide clear insights at minimal cost, while others drain resources without driving meaningful outcomes. The matrix balances that trade-off, sorting candidates into four quadrants.
The metrics to immediately forget. They require significant resources to implement yet provide little value in return, dominating your team's time with little to show for it.
These require strategic thinking and prioritization. They provide value but demand significant resources to implement; quantitative risk analysis such as the FAIR model often falls here. Assess whether their value is greater than their effort, and whether you have the resources to implement them.
An easy trap to fall into, but they should also be forgotten. They provide little value while being cheap to collect. Metrics ultimately need to be actionable, and just because something is easy to measure does not mean it should be.
Your no-brainer metrics: easy and efficient to collect, and genuinely valuable to the program. These should make up the bulk of your security metrics. A good metric is not only valuable but easy and cheap to produce.
If a metric does not provide value to the security program, collecting it is a net negative, which is why both low-value quadrants are treated the same way regardless of what they cost.
With value and effort defined, the funnel is what actually moves candidates through. Every candidate is judged on value first, because effort is only worth calculating for something that would earn its place. What survives is then split by effort.
Low value metrics leave the funnel entirely. Of what remains, the low effort ones are straightforward inclusions, and the high effort ones are carried selectively, weighed against the resources you actually have.
By this point you have made a series of decisions: purpose statements, targets, calculations, data sources, frequencies. Documentation is where those decisions stop living in someone's head and become something the program can be held to.
Every metric needs a single named owner. Without one, a metric has no accountability, and nobody has the standing to act when it signals a problem. Ownership splits into two roles that are easy to confuse.
Owns the mechanics. They make sure the data gets pulled, the numbers are validated, definitions stay consistent, and updates happen on schedule. They may delegate the work, but the quality of the measurement is theirs.
Owns the meaning. They interpret results, explain trends, escalate concerns, and decide what happens next, including adjusting plans or resourcing in response to what the metric shows.
The cleanest model assigns one person to both roles, so the person reading the number is the same person who can act on it.
Where the documentation lives matters less than that it exists. Word documents in SharePoint, Markdown under version control, an Excel table, or a tool like Notion all work, provided the system meets three requirements.
One authoritative place where each metric is defined, so there is never a question of which version is current.
A clear way to log and review changes over time. Even a simple version table inside the document counts.
The record is updated whenever something changes. Documentation that drifts from reality is worse than none.
At a minimum, each metric should carry a unique ID, a title, its purpose, its metric function, an owner, the calculation, the data sources behind it, the measurement frequency, and its target.