KRIs and threshold setting: making indicators that actually trigger action

A Key Risk Indicator is a measurable signal that tells you whether a risk is materializing — early enough that you can act before it does. The defining property of a useful KRI is leading-ness. A metric that confirms a risk has materialized after the fact is a lag indicator; a metric that signals the risk is becoming likely is a leading indicator. Some programs track both, but the KRIs that earn their place are the leading ones.

A KRI also has a defined threshold: a value at which the indicator triggers a formal escalation. Without a threshold, the KRI is being watched but isn't producing decisions. "We track this metric monthly" is observation; "when this metric crosses 15%, the sponsor is automatically notified" is a KRI.

The combination of leading-ness and threshold is what distinguishes a KRI from a generic operational metric. Plenty of useful metrics aren't KRIs — patient satisfaction is a KPI, hospital census is an operational signal, hand hygiene compliance is an audit metric. KRIs sit specifically in the risk-anticipation space.

Why KRIs fail in practice

The most common KRI failure mode is choosing metrics that are easy to measure rather than predictive of the risk. Activity metrics — "vendor risk assessments completed," "training sessions delivered," "policies reviewed" — are easy to count but rarely predict whether the underlying risk is materializing. They measure the program's effort, not the risk's behavior.

The second failure mode is threshold setting. Thresholds picked round-numbered without analytical basis — "we'll alert at 80%" — get revised upward whenever they fire, until they no longer trigger. A KRI that has been raised three times to keep it from triggering is no longer a KRI; it's a metric that the organization has decided not to act on.

The third failure mode is escalation that doesn't escalate. The threshold fires, the sponsor receives a notification, the response is "we'll keep an eye on it." Documentation of inaction is not escalation. KRI threshold crossings should produce decisions: intensify mitigation, accept higher residual risk for a defined period, or revise the threshold with explicit rationale.

Designing a KRI is the act of finding a measurable signal whose movement precedes the risk's materialization with enough lead time for response. This is harder than it sounds, and the design step is where most ERM programs invest the least effort relative to its value.

The four design tests

1. 1Predictive — does the metric's movement actually precede the risk's materialization? "Critical security patches overdue past the agreed window" can rise well before a breach. "Number of cybersecurity incidents this quarter" arrives after the fact.
2. 2Measurable with available data — can the organization actually compute this metric on a defined cadence using data it has access to? KRIs designed against data the organization can't reliably collect produce indicators that go uncalculated.
3. 3Sensitive enough to move before crisis — a metric whose values stay flat for years and then jump 50% in the month a risk materializes isn't a leading indicator. A useful KRI shows graduated movement that crosses the threshold before the risk is irreversible.
4. 4Actionable — when the threshold is crossed, can the organization actually do something? A KRI signaling a risk that the organization has no capacity to mitigate produces frustrated escalations. KRIs should be tied to mitigation levers the organization can pull.

Activity vs outcome

A common KRI design mistake is choosing a metric that measures the program's activity rather than the risk's behavior. Examples in healthcare ERM:

• Activity (weak): "Number of vendor risk assessments completed this quarter." Tells you the program is working; tells you nothing about whether vendor risk is materializing.
• Outcome (strong): "Percentage of critical vendors with current risk assessment, documented mitigation plan, and active KRI monitoring." Tells you whether the population is covered; movement signals whether coverage is decaying.
• Activity (weak): "Hours of cybersecurity training delivered." Tells you about delivery; tells you nothing about workforce vulnerability.
• Outcome (strong): "Phishing simulation click rate, trended monthly with role-specific breakdowns." Tells you about the workforce's actual susceptibility; movement signals whether training is working or whether attack patterns have evolved past it.

The activity version is almost always easier to design and measure. The outcome version is almost always more useful. Programs that default to activity KRIs accumulate metrics that the program produces about itself rather than about the risks it's supposed to be managing.

Healthcare KRI examples by risk domain

Illustrative starting points, grouped by ASHRM's ERM domains. Each still needs a threshold, a data owner and a response plan.

• Human capital (nurse staffing): agency and travel nurse hours as a share of total nursing hours, or first-year RN turnover, trended monthly by unit.
• Clinical and patient safety (missed results): share of critical results acknowledged by the ordering clinician within the agreed window.
• Technology (clinical system outage): share of critical systems with a recovery test in the past 12 months, and critical patches overdue.
• Operational (workplace violence): reported assaults and threats on staff per month in high-risk departments, alongside the share of staff current on de-escalation training.
• Legal and regulatory (credentialing): providers within 30 days of a credential or privilege expiring without a renewal in progress.

The threshold-setting question

The right threshold is the value at which the risk becomes likely to materialize within the organization's response window. "Response window" is the time the organization needs between threshold crossing and risk materialization to actually mount a meaningful response. If the response window is 30 days and the metric typically moves from "normal" to "crisis" in 10 days, the threshold needs to be set at a value the metric crosses with at least 30 days of margin.

Setting thresholds without considering response window produces alerts that arrive too late to act on. A threshold that fires the day before the risk materializes is informationally interesting and operationally useless.

The two-threshold model

Many useful KRIs benefit from two thresholds: a watch threshold and an action threshold. The watch threshold raises attention — the sponsor monitors the metric more frequently, additional context is gathered, contingency planning is reviewed. The action threshold triggers formal escalation — the response decision must be made within a defined timeframe; the Risk Committee is notified; mitigation is intensified, or the risk is formally escalated for higher-level acceptance.

The two-threshold model lets the program respond proportionally rather than treating every threshold crossing as a crisis or every metric movement as routine. It also gives the sponsor a structured opportunity to intervene before the action threshold triggers, potentially preventing escalation entirely.

Avoiding threshold inflation

Thresholds get raised over time when the organization isn't prepared to act on them. A threshold fires; the response is to question whether the threshold was set right; the threshold is moved up; the metric is now "compliant" again. Repeat enough times and the threshold no longer represents anything.

The fix is documenting threshold rationale at design time. "We set the threshold at 12% based on benchmark data showing values above 10% have preceded events at peer institutions" is defensible. "We set it at 12% because it seemed reasonable" is an invitation to revise upward whenever it's tested.

When a threshold is genuinely set wrong — too sensitive, producing repeated false alarms — revise it deliberately, with documented analysis of why the original was wrong and what the new threshold is anchored to. Threshold revision should be a documented governance event, not a quiet adjustment to clear an inconvenient alert.

Escalation that escalates

When a KRI threshold is crossed, the response should be a documented decision within a timeframe agreed in advance (48–72 hours is a common choice for action thresholds). The decision options:

• Intensify mitigation. The current mitigation isn't moving the risk fast enough; additional resources, scope, or urgency are applied.
• Accept temporarily elevated residual risk for a defined period. The risk has moved above where mitigation can hold it; the organization formally accepts the elevated state for a specified duration with conditions for revisiting.
• Escalate to higher governance. The risk's behavior is outside what the current mitigation framework can handle; Risk Committee or board attention is required.
• Revise the threshold with documented analysis. The threshold was set wrong; this is being acknowledged and the threshold is being moved with rationale (not because it triggered).

What is not a valid response: "We noted the threshold crossing and will continue to monitor." That is documentation of inaction, and it's the response that converts KRIs from decision triggers to data-collection rituals.