TL;DR

• Most risk dashboards are full of KPIs — metrics that measure what happened — relabeled as KRIs.
• A KRI is only a KRI if it’s tied to a named risk, carries a threshold that triggers action, and is forward-looking enough to give you warning before the loss event.
• Activity metrics (audits completed, transactions processed, vendors reviewed) are not KRIs until you connect them to risk exposure and define what happens when the number moves.
• The four-part test: does this metric identify a specific risk? Does it have a threshold? Does it have an owner? Is it leading (before the problem) rather than lagging (after)?

Walk into almost any risk department and ask to see the KRI dashboard. What you’ll usually find is a well-formatted spreadsheet full of metrics, most of them green, with columns for current value and prior period. What you’ll less often find is a metric that has actually triggered an escalation in the last 12 months — or one where anyone can clearly articulate what specific risk the number is supposed to flag.

The confusion between KRIs and KPIs is one of the most common structural problems in operational risk programs. It’s not just a semantic issue. A dashboard full of KPIs masquerading as KRIs gives you the false confidence of a risk monitoring program without the early warning function that makes it useful.

The Core Distinction

A KPI (Key Performance Indicator) measures whether you achieved something. It’s backward-looking. It tells you how well you did against an objective.

A KRI (Key Risk Indicator) measures the likelihood or magnitude of a risk materializing. It’s forward-looking. It tells you where you’re headed — specifically, whether a risk is growing before it becomes a problem.

The Institute of Internal Auditors and most ERM frameworks agree on the directional distinction: KPIs look back, KRIs look forward. But in practice, the boundary gets blurry fast because many metrics can play both roles depending on how they’re framed.

A useful simplification: a KPI answers “how did we do?” A KRI answers “how much risk are we carrying right now?”

Why the Distinction Matters for Risk Programs

If you’re reporting KPIs under the label “KRIs,” two things break in your risk program.

First, you miss the early warning function. A KPI tells you that compliance training completion was 92% last quarter. That’s a fine performance metric. A KRI asks: what’s the current completion rate among employees in high-risk roles, and has it been declining for three consecutive periods? The second question can surface rising risk before a violation occurs. The first question can’t — it only tells you what already happened.

Second, your escalation logic fails. KPIs typically trigger conversations about accountability and performance improvement. KRIs should trigger risk management responses: increased monitoring, control testing, management discussion, board escalation depending on severity. These are different responses to different types of signals. Confusing the metrics confuses the response.

The Four-Part Test

Before labeling a metric as a KRI, run it through four questions.

1. Does it identify a specific risk? A KRI should answer: if this metric moves in the wrong direction, what specific adverse outcome becomes more likely or more severe? “Transaction processing volume” is a count. “Transaction processing error rate” starts to approach a risk signal — but you still need to connect it to a consequence: increased customer complaints, regulatory violations, financial losses. Without naming the risk, you have a dashboard stat.

2. Does it have a threshold that triggers a defined response? A green/amber/red framework with documented thresholds is the minimum. The threshold needs to be calibrated to the risk — not just set at ±10% from last year’s baseline. And the response needs to be defined: at amber, who gets notified? At red, what happens within what timeframe? See the related post on KRI thresholds for how to set thresholds that don’t create false greens or false reds.

3. Does it have a named owner? Every KRI needs a single accountable owner responsible for monitoring, escalation, and threshold review. Not “the risk team.” A named role. If no one owns the metric, breaches go unnoticed because everyone assumes someone else caught it.

4. Is it leading rather than lagging? A leading indicator gives you signal before the risk materializes. A lagging indicator confirms something that already happened. Both have value, but KRIs should lean leading. If a metric tells you about a loss event after the fact, it’s useful for your loss database — not for your early warning system.

Activity Metrics That Aren’t KRIs (Yet)

The most common error in KRI programs is treating activity metrics — counts of completed tasks — as risk indicators. Here are examples and what it takes to convert them.

”Number of vendor reviews completed this quarter”

As an activity metric: Tells you how many reviews your team did. Fine for workload management.

As a KRI: Tells you what fraction of your high-risk vendors received a review within their required cycle — and whether that fraction is declining. Tied to third-party risk: if high-risk vendor reviews fall behind cycle, your exposure to undiscovered vendor issues rises.

Threshold example: Green: ≥95% of Tier 1 vendors reviewed on schedule. Amber: 85–94%. Red: below 85% or any Tier 1 vendor >30 days past due on review cycle.

”Number of compliance training completions”

As an activity metric: Training completion rate against an HR objective.

As a KRI: Completion rate among employees in roles with elevated regulatory risk (AML, fair lending, UDAAP). Tied to compliance risk: declining completion in high-risk roles increases the likelihood of policy violations.

Threshold example: Green: ≥95% completion by deadline. Amber: 90–94%. Red: below 90% or any team with complete non-completion in a required regulatory training.

”Number of audit issues open”

As an activity metric: Workload metric for the audit remediation team.

As a KRI: Percentage of past-due audit findings — especially findings rated “high” or “critical” — as a signal of control environment deterioration. Tied to operational and compliance risk.

Threshold example: Green: no high-rated findings past due. Amber: 1–2 high-rated findings past due ≤30 days. Red: any high-rated finding past due >30 days, or any critical finding past due at all.

A Comparison Table

When the Same Metric Genuinely Plays Both Roles

Some metrics legitimately function as both KPIs and KRIs simultaneously. The key is knowing which role they’re playing for which audience.

Employee turnover rate is a KPI for HR (measure against a retention goal) and a KRI for operational risk (rising turnover in the compliance function increases the risk of regulatory violations as institutional knowledge erodes). The same number feeds two different conversations. The risk team cares whether it’s trending in a way that indicates growing exposure; HR cares whether it’s meeting the talent management target.

Customer complaint volume is a KPI for customer experience (track against service-level standards) and a KRI for regulatory risk (rising complaint rates in specific product categories predict UDAAP scrutiny and CFPB examination focus). The risk team needs complaint data disaggregated by product and issue type; customer experience teams care about total volume and resolution time.

What matters is that you’re explicit about which role a metric plays in each reporting context — and that the thresholds and escalation paths are built for the role it’s actually playing.

Building a Real KRI From an Activity Metric: A Worked Example

Start with a common activity metric: “number of IT incidents per month.”

Step 1 — Name the risk. Increasing IT incidents signals rising operational availability risk and potentially rising cyber risk. The specific risk: an incident spike could indicate systemic control deterioration that precedes a major outage or breach.

Step 2 — Distinguish severity. Aggregate incident counts are noisy. Stratify by severity: P1 (critical, affecting customer-facing systems or core processing), P2 (significant), P3 (minor). Your KRI cares about P1 and P2.

Step 3 — Set a threshold. Green: ≤2 P1 incidents per month, ≤8 P2 incidents per month, no P1 incident exceeding 4-hour resolution. Amber: 3–4 P1 incidents or 9–12 P2 incidents. Red: ≥5 P1 incidents in a month, or any P1 incident exceeding 24 hours without resolution.

Step 4 — Assign an owner. CISO or Chief Technology Officer. Responsible for monitoring, escalation to CRO when amber, Board/Risk Committee notification when red.

Step 5 — Define the escalation. Amber: risk management review within 48 hours, root cause analysis within two weeks. Red: executive notification same day, Board Risk Committee briefing within one week.

Now “number of IT incidents” is a KRI. It’s tied to a named risk, has a calibrated threshold, has an owner, and triggers a defined response. Before you did that work, it was a dashboard stat.

For more examples of KRIs built this way — with named risks, data sources, owners, and threshold guidance — see 40 KRI examples for operational and financial risk teams and the complete KRI guide with 50+ examples by domain.

What Regulators Look For

Under OCC, FDIC, and Federal Reserve supervision, examiners reviewing operational risk programs look for KRIs that are:

• Connected to the institution’s risk appetite — not just general industry metrics, but indicators tied to the specific risks the institution has identified as material
• Carrying documented thresholds with a clear basis for why the threshold is set where it is
• Assigned to named owners with documented responsibilities
• Showing evidence of use — escalation history, management discussions, threshold breaches responded to

A risk dashboard that has never produced an amber or red status in 18 months is not evidence of a well-managed risk program. It’s evidence of thresholds set too loosely or metrics selected to always show green. Examiners distinguish between the two. See also how to build and own a KRI program for the governance structure that makes a KRI program credible under examination.

So What?

The distinction between KRIs and KPIs isn’t academic. It’s the difference between a risk monitoring program that gives you early warning and one that generates comfortable green dashboards until the loss event happens.

Go through your current KRI dashboard and apply the four-part test to each metric: named risk, defined threshold, named owner, leading rather than lagging. Any metric that fails one or more tests is a KPI — or just a dashboard stat — masquerading as a KRI.

The KRI Library (132 Key Risk Indicators) is built with this standard: every indicator includes the risk it measures, the data source, the owner role, a calibrated threshold framework, and the escalation path — so you can implement a real KRI program rather than relabeling the reporting you already have.