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

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, 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) 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.

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) 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 walks the evidence chain an auditor samples. ISO/IEC 27004 gives guidance on building the measures themselves.

Open nonconformities and overdue corrective actions also feed clause 10.2 on 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. 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 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