---
title: "GRC metrics: the KPIs that show your compliance programme is working, and how to collect them automatically"
canonical: https://www.grcmana.io/vault/grc-engineering/grc-metrics
published: 2024-03-15
updated: 2026-10-21
author: "Harry West"
framework: "GRC Engineering"
control: "Guide GRC metrics: the KPIs that show your compliance programme is working, and how to collect them automatically"
journeyStage: intermediate
---

# GRC metrics: the KPIs that show your compliance programme is working, and how to collect them automatically

## Key takeaways

GRC metrics are the measures that show whether governance, risk and compliance activities are working. A firm running ISO 27001 and SOC 2 needs about ten KPIs, each with an owner, a data source, a target and a refresh rate. Collected automatically from systems the firm already runs, they give a live view of control health and audit readiness and evidence ISO 27001 clause 9.1 and SOC 2 CC4.1.

- **Measure documentation** — NIST SP 800-55 Volume 1 suggests recording each measure's goal, formula, target, data source, collection and reporting frequency, and the people who own, collect and review its data.
- **Types of measure** — NIST SP 800-55 separates implementation measures, which show a control's progress, from effectiveness, efficiency and impact measures: how well and how fast controls work, and their business value.
- **Manual and automated monitoring** — NIST SP 800-137 says organisation-wide monitoring cannot run efficiently on manual or automated processes alone, and controls that resist automation still need regular assessment.
- **ISO 27001 clause 9.1** — Clause 9.1 requires a firm to decide what it monitors and measures, the methods, when and by whom, and when the results are analysed and evaluated.

An investor asks whether the security programme is working. An enterprise customer asks for proof that you stay compliant between audits. Your answer is a spreadsheet someone rebuilt last quarter, and nobody is sure the numbers are still true.

This guide is for heads of security, compliance leads and CTOs at UK B2B tech firms running ISO 27001 and SOC 2. It sets out a short set of GRC metrics, each with a definition, data source, owner, target and refresh rate, and shows how to collect them automatically from the systems you already run.

## What are GRC metrics?

GRC metrics are the measures that show whether your governance, risk and compliance activities are working. Key performance indicators (KPIs) track how well the programme performs, while key risk indicators (KRIs) warn that a risk is growing. The useful ones are few, owned, drawn from systems and collected without anyone rebuilding a spreadsheet.

Most lists of GRC KPIs run to twenty or thirty items with no source, owner or target. That is a catalogue, not a measurement programme.

A firm of 25 to 250 people needs around ten. Each one should answer a question someone senior will actually ask: are our controls working, will the next audit hold surprises, and can we prove it to a customer this week?

If you hold ISO 27001, these metrics are also how you meet [clause 9.1 on monitoring and measurement](https://www.grcmana.io/vault/iso-27001/clause-9-1-monitoring-measurement-analysis-and-evaluation), which asks you to decide what to measure and to evaluate the results.

## What is the difference between GRC KPIs, KRIs and KCIs?

A KPI measures how well the programme is performing against a goal, such as evidence kept current. A KRI is an early warning that a risk is moving towards your appetite. A key control indicator (KCI) shows whether a specific control is working. Most programme dashboards mix KPIs and KCIs; KRIs belong with the risk register.

The three often get blurred, and the blur causes real problems. A KRI needs a threshold set from your risk appetite, which is a risk management decision. A KPI needs a target set from your programme goals, which is a management decision.

- **KPI:** "Share of policies reviewed on time." It tells you whether the programme is keeping up.
- **KCI:** "Share of automated control tests passing." It tells you whether controls are doing their job.
- **KRI:** "Number of internet-facing systems with an unpatched critical flaw." It tells you exposure is rising.

This page covers KPIs and KCIs. Key risk indicators and the appetite thresholds behind them are a separate subject that belongs with risk management.

## What makes a good GRC metric?

A good GRC metric is tied to a control or objective, has a named owner, comes from a named system, has a target that says what good looks like, and triggers an action when it misses. If any one of those five is missing, the number becomes decoration: people look at it, and nothing changes.

NIST's [Measurement Guide for Information Security (SP 800-55 Volume 1)](https://csrc.nist.gov/pubs/sp/800/55/v1/final) suggests documenting every measure in a standard format. Its fields include a goal, a formula, a target, the data source, how often data is collected and reported, and the people who own, collect and review the data. That is a useful template even outside US federal settings.

We recommend five tests before a metric earns a place on your dashboard:

1. **Tied.** It maps to a named control, clause or programme objective.
2. **Owned.** One person is accountable for the number moving, not just for reporting it.
3. **Sourced.** It comes from a system of record, so two people running it get the same answer.
4. **Thresholded.** It has a target, so a reader can tell good from bad without asking.
5. **Acted on.** A miss opens a ticket or a decision, with a date.

SP 800-55 also separates implementation measures (is the control in place?) from effectiveness, efficiency and impact measures (is it working, how fast, and what does it mean for the business?). Start with implementation, then move up as data matures.

## Which GRC KPIs should a firm running ISO 27001 and SOC 2 track?

A firm running ISO 27001 and SOC 2 should track around ten GRC KPIs across control health, audit readiness, people, third parties, policy, vulnerabilities and commercial assurance. The table gives each one a data source, owner, starting target and refresh rate, and says whether it can be collected automatically. Treat the targets as starting points.

| KPI | What it measures | Data source | Owner | Starting target | Refresh and collection |
| --- | --- | --- | --- | --- | --- |
| Controls passing automated tests | Share of automated control tests that passed at their last run | Cloud configuration, identity provider and endpoint checks, via the GRC tool | Control owners; compliance lead reports | Every critical control passing; each failure ticketed within one working day | Daily, automated |
| Evidence freshness | Share of controls whose latest evidence falls inside its collection interval | Evidence timestamps in the GRC tool | Compliance lead | No control outside its interval | Daily, automated |
| Open nonconformities and audit exceptions | Count of open findings by severity and age | Corrective action register in ticketing or the GRC tool | Compliance lead | No open major findings; minors on an agreed plan | Weekly, automated |
| Overdue corrective actions | Share of corrective actions past their due date | Ticketing system | Action owners; compliance lead reports | None past due without an approved extension | Weekly, automated |
| Security training completion | Share of staff who completed required training within the window | HR system and training platform | People lead | All staff inside the window, new joiners included | Monthly, automated |
| Access reviews completed on time | Share of scheduled access reviews signed off by the due date | Identity provider and ticketing | System owners | Every scheduled review signed off on time | Each review cycle, partly automated |
| Supplier assessments current | Share of critical suppliers assessed within their review interval | Supplier register | Procurement or compliance lead | Every critical supplier current | Monthly, partly automated |
| Policies reviewed on time | Share of policies reviewed and approved by their review date | Policy register or document management system | Policy owners | Every policy inside its review date | Monthly, automated |
| Critical vulnerabilities remediated within SLA | Share of critical findings closed inside your remediation SLA | Vulnerability scanner and ticketing | Engineering lead | Every critical inside SLA | Daily, automated |
| Security questionnaire turnaround | Working days from receipt to return of a customer questionnaire | CRM or the ticketing queue used for requests | Compliance lead with sales | Inside the deal timeline agreed with sales | Monthly, partly automated |

Four of these speak directly to audit readiness: evidence freshness, open nonconformities, overdue corrective actions and controls passing. If those four are green, the next audit should hold few surprises.

Five of the other six show whether the routines behind your controls are running. Training, access reviews, supplier checks, policy reviews and vulnerability remediation can all slip quietly between audits.

Questionnaire turnaround is the commercial line. It is the one leadership understands without explanation, because it is measured in days a deal is waiting.

## How do you collect GRC metrics automatically?

Collect GRC metrics automatically by pulling each one on a schedule from the system that already holds the data, storing every result with its date, and flagging any feed that stops. People then spend their time on evaluation and action, not on assembling a spreadsheet. Some metrics stay partly manual, and that is fine.

NIST's guide to [information security continuous monitoring (SP 800-137)](https://csrc.nist.gov/pubs/sp/800/137/final) is clear on the balance. Organisation-wide monitoring cannot run efficiently on manual processes alone or automated processes alone. Automation can make monitoring more consistent and cost-effective, and controls that cannot be automated still need regular assessment.

We recommend six steps:

1. **Map each KPI to its system of record.** Write down which system holds the raw data: the identity provider, ticketing, cloud configuration, HR system or GRC tool.
2. **Define the query once.** Each KPI gets a fixed formula, such as "closed critical findings inside SLA divided by all critical findings closed this month".
3. **Schedule the pull.** Match the refresh to how fast the number changes. Configuration drifts daily; policy reviews change monthly.
4. **Keep dated snapshots.** Store each result with the date it was taken. Trends, and audit evidence, need history.
5. **Watch the feeds.** A connector that silently stops is worse than no connector, because the dashboard stays green.
6. **Record the evaluation.** A named person reviews the results, decides what they mean and records the actions.

The continuous control monitoring method, with test design and alerting rules for each control, is a deeper subject in its own right. This page covers what to measure and how to feed it.

An automated metric nobody reviews is just a faster way to be wrong.

## What goes on a compliance dashboard?

A compliance dashboard should carry your ten KPIs, each showing its current value, target, trend and owner, with anything off target at the top. Control owners and the compliance lead see it daily, leadership sees a summary view, and every number refreshes from source rather than from someone's manual update.

Keep three views of the same data:

- **Operational view.** Every KPI, every failing control and every overdue action, for the compliance lead and control owners.
- **Leadership view.** The ten KPIs with trend arrows and the items that need a decision.
- **Customer view.** A small, approved subset you can share in a service review or security questionnaire, such as evidence freshness and audit status.

All three should draw on the same snapshots. When the customer view and the leadership view come from different spreadsheets, they will eventually disagree, and someone will notice.

Show the refresh time on every tile. A reader who can see the data is from this morning trusts it; a reader who cannot see a date assumes the worst.

What to report to whom, and how often, is a reporting question rather than a measurement one. This page owns the measures and the feeds.

## How do GRC metrics evidence ISO 27001 clause 9.1 and SOC 2 CC4.1?

GRC metrics evidence ISO 27001 clause 9.1 because the clause requires you to decide what to monitor and measure, how, when and by whom, and to analyse and evaluate the results. They support SOC 2 CC4.1 because that criterion expects ongoing or separate evaluations of whether the components of internal control are present and functioning.

For ISO 27001, the dated snapshots, the documented formula for each KPI and the recorded evaluation together form the evidence. Our [clause 9.1 guide](https://www.grcmana.io/vault/iso-27001/clause-9-1-monitoring-measurement-analysis-and-evaluation) walks the evidence chain an auditor samples. [ISO/IEC 27004](https://www.grcmana.io/vault/iso-27004) gives guidance on building the measures themselves.

Open nonconformities and overdue corrective actions also feed [clause 10.2 on nonconformity and corrective action](https://www.grcmana.io/vault/iso-27001/clause-10-2-nonconformity-and-corrective-action). The same register serves both clauses.

For SOC 2, CC4.1 sits in the monitoring activities group of the AICPA [Trust Services Criteria](https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022). A Type 2 auditor wants to see monitoring operate across the whole report period, which is exactly what dated, automated snapshots show. Our guide to the [SOC 2 Trust Services Criteria](https://www.grcmana.io/vault/soc-2/trust-services-criteria) explains how the criteria fit together.

One set of KPIs, collected once, can serve both audits.

## Can you benchmark GRC KPIs against other firms?

You can benchmark GRC KPIs against other firms only with care, because we know of no authoritative public dataset of GRC KPIs for UK firms of your size. A figure without a stated method, sample and date tells you little. Benchmark against your own trend, your own policy targets and your customers' contract terms instead.

Comparisons between firms also break on definitions. "Controls passing" means nothing until you know how many controls, which tests and how often they run. Two firms reporting the same percentage may be measuring very different things.

Three comparisons are worth making:

- **Your trend.** Is each KPI better than last quarter, and is the improvement holding?
- **Your policy.** If your patching policy sets an SLA, the target is the SLA, not an industry average.
- **Your contracts.** Customer agreements can set notification and remediation terms. Those are the targets your customers will check.

If you do cite an external benchmark, check that it states its method, sample and date. If it does not, leave it out.

## What are the common mistakes with GRC metrics?

The common mistakes with GRC metrics are counting activity instead of outcomes, tracking too many metrics, collecting them by hand until they go stale, and publishing numbers with no owner or no action when they miss. Each one produces a dashboard that looks busy while the programme drifts underneath it.

- **Vanity counts.** "Policies written" or "controls in the library" only ever go up. They say nothing about whether anything works.
- **Too many metrics.** Thirty KPIs means nobody reads any of them. Cut to the ten that answer a real question.
- **Manual collection.** A spreadsheet rebuilt each quarter is out of date the day after it is finished, and it is the first task dropped in a busy month.
- **No owner.** A number everyone reports and nobody owns does not move.
- **No action on a miss.** If a red tile does not open a ticket, people learn to ignore red.
- **Green by default.** A broken data feed that shows the last good value hides the very failure you built the dashboard to catch.

## Frequently asked questions

### How many GRC metrics should a small firm track?

Start with five and grow to about ten. Begin with the four audit-readiness measures (controls passing, evidence freshness, open nonconformities and overdue corrective actions) plus training completion. Add a measure only when someone will own it and act on it.

### Do you need a GRC tool to collect GRC metrics automatically?

No. A GRC tool makes evidence freshness and control tests easier to collect, but most of these KPIs come from systems you already run. A scheduled query against your ticketing system, identity provider and HR system, stored with its date, is a sound start.

### How often should GRC metrics be reviewed?

Match the review to how quickly each number can change and how quickly you would act. Control owners should see failing tests the same day. The compliance lead should review the full set weekly, and leadership should see trends at least monthly.

### What is the difference between GRC metrics and compliance metrics?

Compliance metrics are a subset of GRC metrics. They show whether you are meeting the obligations of a standard, contract or regulation, such as policy reviews, training and audit findings. GRC metrics also cover governance decisions and risk, so for most ISO 27001 and SOC 2 programmes the core set is mainly compliance metrics.

### Can GRC metrics replace an internal audit?

No. Metrics show whether controls appear to be running between audits, while an internal audit tests whether they meet the standard's requirements and whether the metrics themselves are reliable. Good metrics make internal audits faster, because the auditor starts from evidence rather than from questions.