Key risk indicators (KRIs): examples, thresholds and automated monitoring

A bank's supplier questionnaire asks how you monitor the risks to the service you sell it. Your honest answer is a spreadsheet someone rebuilt the week before the last audit.

Key risk indicators (KRIs) are measurable, forward-looking signals, each with an owner and thresholds set from your risk appetite, that warn before a risk breaches tolerance. A KPI reports performance; a KRI warns. For a tech supplier, KRIs show auditors, the board and customers that risk is watched continuously, and the best ones come from systems you already run.

This guide is for CTOs, security leads, compliance leads and founders at UK B2B tech firms of 25 to 150 people that sell to financial services, insurance or the public sector. It shows how to choose a handful of KRIs, set green, amber and red thresholds from your appetite and your customer contracts, collect them automatically, and reuse the same data as SOC 2 and ISO 27001 evidence.

What are key risk indicators, and how do they differ from KPIs?

Key risk indicators are metrics that tell you a specific risk is growing before it turns into an incident or a missed commitment. Each is tied to a named risk, has an owner and carries thresholds. A KPI measures how well something performed. A KRI measures how close you are to the edge of what you agreed to tolerate.

The Institute of Operational Risk's sound practice guidance on KRIs describes them as tools that help line managers, senior management and boards monitor the level of risk taking. For the board, they show whether the firm is operating within its risk appetite.

The difference matters because the same number can be either. Uptime last month is a KPI. Uptime trending towards the floor in your customer contract, with an owner who has to act at a set point, is a KRI. GRC programme metrics and compliance KPIs are a separate subject; this page stays with risk.

What makes a good key risk indicator?

A good KRI is leading, measurable, owned, thresholded and tied to a named risk in your register. Leading means it moves before the harm happens. Measurable means a system produces it, not an opinion. Owned means one named person acts when it changes. Thresholded means green, amber and red are agreed in advance.

Test each candidate against five questions:

1. Which risk does it watch? Name the entry in your risk register. An indicator with no risk behind it is just a metric.
2. Does it move before the harm? Accounts without multi-factor authentication rise before an account takeover. The count of takeovers rises after it.
3. Can a system produce it? If a person has to judge the value each month, it will drift and nobody will trust it.
4. Who acts when it turns amber? One name, not a team.
5. What happens at red? The escalation route and the decision it forces should be written down before the threshold is ever crossed.

Keep the set small. Five to ten KRIs that people act on are worth more than forty that nobody reads. The scale is our recommendation, not a rule from any standard.

How do you choose key risk indicators for a SaaS business?

Start from your top risks, not from the data you have. Take the five to ten highest-rated risks in your register, and for each ask which signal in your existing tooling would move first if that risk were getting worse. That signal is your candidate KRI. Then give it an owner, a source and a refresh frequency.

For a 25 to 150 person SaaS supplier, those signals already sit in a short list of systems: the identity provider, the cloud platform's configuration and logging, vulnerability scanning and patching, backup tooling, the ticketing system, the HR system and the supplier register. You rarely need a new tool to start. You need to decide what to read from the ones you run.

Write each KRI down as a one-line record: the risk it watches, the measure, the data source, the owner, the refresh frequency, and the three thresholds. Your risk assessment method, the part of ISO 27001 covered by clause 6.1, is where the list of risks comes from. If you follow ISO 31000, the same logic applies.

How do you set KRI thresholds?

Set KRI thresholds from two places: your own risk appetite and your customer commitments. Appetite tells you where amber and red sit for risks only you carry. Contracts tell you where they sit for risks your customers share, because the service level or notification window you signed is the limit. Red should trigger before that limit, not at it.

From risk appetite. Your appetite statement says how much of each kind of risk the business will accept. Translate each statement into a number for the KRI that watches it. The UK government's Cyber Governance Code of Practice, published in April 2025, asks boards to define a cyber risk appetite (action A3). Its action E2 asks them to require formal reporting at least quarterly, with suitable metrics and agreed tolerances for each, based on that appetite. The Code is written for medium and large organisations, and says smaller ones should seek to apply its principles.

A risk management policy is where appetite and risk criteria are written down, so it is the natural home for the threshold rules. Our risk management policy template gives you the structure.

From customer contracts. Regulated customers write measurable commitments into supplier contracts, such as availability levels, recovery times and incident notification windows. Those commitments become your hardest thresholds:

• EU financial-entity customers. The EU's Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554) applies to financial entities in the EU and is not UK law; its contract rules reach you through your customers' contracts. Article 30 sets what their ICT contracts must contain. For services supporting critical or important functions, that includes full service level descriptions with precise quantitative and qualitative performance targets, so the customer can monitor the service and act when levels are not met. It also includes a right to monitor your performance on an ongoing basis.
• UK banks and insurers. The PRA's supervisory statement SS2/21 applies to PRA-regulated firms such as banks, building societies and Solvency II insurers. It expects their written agreements for material outsourcing to set agreed service levels with qualitative and quantitative performance criteria that allow timely monitoring (paragraph 6.4). It also expects firms to define the KPIs and key risk indicators which, if breached, may trigger an exit (paragraph 10.17).

Read that last point from the supplier's side. A regulated customer may already hold indicators about you that would start its exit plan. Your own KRIs should turn red well before theirs do.

The thresholds below show how we suggest structuring the bands. The numbers are illustrative GRCMANA guidance, not requirements from any standard or regulator; set yours from your own appetite and contracts.

Which key risk indicators should a SaaS supplier track?

The key risk indicators that matter most for a SaaS supplier watch six areas: access and identity, vulnerabilities and patching, availability and backup, third parties and sub-processors, people, and incidents. Most can be collected automatically from tools you already run. The examples and thresholds below are illustrative GRCMANA guidance to adapt, not benchmarks.

How should KRIs be collected, refreshed and escalated?

Collect each KRI from its source system on a schedule, refresh it at least as often as the risk can change, and escalate on breach through a route agreed in advance. Automated collection keeps the figures current and the history intact. The governance layer, owners, thresholds and escalation, is what turns those figures into risk management rather than a dashboard.

Collection. Where the source system can export the figure, take it automatically and keep every reading with its date. NIST defines information security continuous monitoring as maintaining ongoing awareness of information security, vulnerabilities and threats to support organisational risk management decisions. Automated KRIs are the risk-facing part of that awareness. Where a figure still needs a person, such as a supplier review, record who supplied it and when.

Refresh frequency. Match the cadence to how fast the risk moves. Identity and vulnerability indicators can change daily, so we suggest reading them daily or weekly. Supplier and training indicators change more slowly, so monthly is usually enough. Report to the board on its own cadence, which the Cyber Governance Code puts at least quarterly.

Escalation. Write the route down before you need it. Amber goes to the owner, who records what they will do and by when. Red goes to a named executive, who records the decision: fix, accept the risk for a stated period, or change the threshold with a reason.

KRIs watch risks; continuous control monitoring tests whether individual controls work. The two share data sources and often share tooling, but they answer different questions, and both are worth having.

How should you report key risk indicators to the board, investors and customers?

Report KRIs as trends, not snapshots. A single red reading tells the board little; a line moving from green to amber over three months tells it where attention is needed. Show each KRI's current band, its direction over recent periods and the action taken on every amber or red, so the reader sees both the risk and the response.

For the board and investors, a one-page view works: each KRI, its band, its trend and the decision recorded on any breach. Tie each one back to the appetite statement the board agreed, so the conversation is about tolerance, not raw numbers.

For regulated customers, KRIs answer the monitoring questions in due diligence and service reviews. Share the trend for the indicators that touch their service, such as availability against SLA and incident triage times, and say what happened when one went amber. A trust centre can publish the summary for prospects, while the detail stays in service reviews under contract.

Be selective about what leaves the building. Customers need evidence that you watch the risks to their service, not your full register.

How do KRIs double as SOC 2 and ISO 27001 evidence?

KRIs collected automatically, with dated readings and recorded actions on every breach, are ready-made monitoring evidence. For SOC 2, they support the monitoring activities in the CC4 series of the Trust Services Criteria. For ISO 27001, they help meet clause 9.1, which asks what you monitor and measure, how and when, and who evaluates the results.

SOC 2. The CC4 series covers checking that controls work and dealing with what does not, and the CC3 series covers risk assessment. Our Trust Services Criteria guide explains each series. A KRI history with escalations shows the auditor that monitoring happened throughout the Type 2 period, not just before fieldwork.

ISO 27001. Clause 9.1 needs decisions on what is monitored, the methods, the timing and who analyses and evaluates the results. A KRI record, with its owner, source, frequency and thresholds, answers most of those decisions on paper. The evaluation, a person judging what the readings mean, still has to be recorded. Our clause 9.1 guide covers what auditors sample.

One dataset now serves the auditor, the board and the customer. That is the point of engineering it once.

What are the common mistakes with key risk indicators?

The common mistakes are labelling lagging metrics as KRIs, tracking too many indicators, setting thresholds that trigger no action, and collecting figures by hand so they go stale before the audit. Each one leaves you with numbers that look like monitoring but cannot warn you of anything in time to act.

• Lagging metrics labelled as KRIs. Counts of past incidents, audit findings closed and policies approved describe the past. Keep them as KPIs and find the signal that moves first: an indicator that turns red after the breach is a report, not a warning.
• Too many indicators. A long list spreads attention thin, and the important amber gets lost among forty others.
• Thresholds nobody acts on. If red has no owner, no escalation route and no recorded decision, the indicator is a chart, not a control.
• Manual collection. Figures assembled by hand before each audit or customer review are out of date the day after, and the gaps between readings are exactly where the auditor will look.
• Thresholds set without the contract. If your SLA or notification window is tighter than your red band, the customer will see the breach before you do.

If the number is rebuilt by hand before each audit, it was never monitoring.

Frequently asked questions