ServiceNow Governance, Risk and Compliance KPIs and Metrics That Matter

GRC measures are about coverage, effectiveness and accountability rather than volume: how much of the risk universe is recorded and monitored, whether tested controls actually work, how many duty-separation rules are violated, whether staff attest to policies, and whether audit findings close on time or come back the next year. Each metric below gives the count to take and how to read it, followed by guidance on baselines, definitions that different people calculate the same way, and metrics that improve for the wrong reason.

Risk and Control Metrics

Risk Universe Coverage

Count of identified organisational risks (threats to objectives) that are recorded and actively monitored in the platform, expressed as a share of total business objectives. An organisation without complete risk inventory cannot claim control. Calculate the total count of business objectives and the count of risks linked to each. Gaps reveal blind spots and inform risk assessment prioritisation. High coverage does not guarantee effective risk management, but low coverage guarantees it is incomplete.

Control Effectiveness Rating

Count of controls rated as effective (operating as designed and achieving their control objective) based on recent testing, expressed as a share of all controls tested. Controls are effective, partially effective, or ineffective. A control rated ineffective means risk is not mitigated; immediate remediation is required. Effectiveness ratings depend on periodic testing or self-assessment, typically annual. Track trends; improving effectiveness indicates maturing governance.

Segregation of Duties Violations

Count of user role assignments that violate your SOD policy (for example, request approver and request fulfiller in the same user). This metric is often automated; the platform can identify policy violations and flag them for remediation. High violation counts signal onboarding shortcuts or incomplete access governance.

Compliance and Audit Metrics

Policy Compliance Attestation Rate

Count of employees who have read, understood, and attested to key policies within the required window, expressed as a share of all employees. Policies commonly include security, data handling, conduct, and regulatory requirements. A low attestation rate means either distribution failed or employees are not taking it seriously. Track by department; low rates in specific teams warrant investigation.

Audit Findings Closure Rate

Count of audit findings that are closed within agreed remediation timelines, expressed as a share of all findings. Track findings from internal audit, external audit, and regulatory inspections. A finding closed on time with evidence reduces risk and demonstrates effective management. Late closures signal either weak remediation effort or optimistic timelines. Calculate closure rate by finding age bucket to spot delays early.

Repeat Finding Rate

Count of audit findings in the current cycle that address the same underlying issue auditors found in prior years. Repeat findings are a red flag; they indicate that remediation was incomplete or temporary. If a finding repeats, the root cause was not addressed. Use this metric to pressure faster and more thorough remediation.

Regulatory and Compliance Metrics

Regulatory Requirement Mapping Coverage

Count of regulatory requirements applicable to your organisation that are documented and linked to controls and policies in the platform, expressed as a share of all known requirements. Regulatory requirements stem from frameworks like ISO 27001, HIPAA, PCI DSS, or SOX, depending on your industry and jurisdiction. Coverage ensures nothing falls through cracks. Gaps require design of new controls or process changes.

Regulatory Inspection Readiness

Count of evidence and documentation required for a regulatory inspection that is current and accessible in the platform, expressed as a share of total evidence requirements. This is a readiness metric. Six months before an audit or inspection, calculate this rate. It tells you where to accelerate evidence collection and testing.

Incident and Exception Metrics

Policy Exception Request Volume and Approval Rate

Count of requests to deviate from policy and count that are approved versus denied. A high denial rate may indicate policy is too strict or poorly designed. A high approval rate may indicate weak governance. Both extremes warrant review. Track exceptions by category and reason to identify systemic conflicts.

Incident Detection Latency

Average time from when a compliance incident occurs to when it is detected and reported. This metric is difficult to calculate precisely because detection time depends on the type of incident. For incidents with clear detection points (failed access log audits, policy violation alerts), measure from occurrence to alert. For others, use estimation based on incident type. Faster detection enables faster response.

Calculation and Ownership

Most GRC metrics pull from the Risk, Control, Policy, and Audit modules in the GRC suite. Calculate monthly or quarterly and present to governance committees. Assign one business owner to each metric; that owner is accountable for explaining trends and driving improvement.

Common Pitfalls

Pitfall: Measuring volume (number of risks identified) without measuring effectiveness (count mitigated). Fix: pair volume metrics with quality metrics.

Pitfall: Audit findings that sit open for months because the remediation owner deprioritises them. Fix: automate escalation of overdue findings and make closure rate a manager performance metric.

Pitfall: Policy attestation treated as a checkbox exercise with no consequence for non-attestation. Fix: link attestation completion to payroll or system access; non-attesting employees lose privileges until they do.

Recording a baseline before any target is written

A GRC metric is only as useful as the starting point it is measured from. Before anyone commits to a target, pull the current value of each candidate metric for the last few cycles, even when the history is patchy. A control effectiveness rate of unknown quality tells the committee more about the testing program than about the controls. The first conversation with the risk committee should therefore sort the candidate metrics into two piles: numbers trustworthy enough to set a target against, and numbers that need a data fix before they mean anything.

Writing each metric so two people calculate the same number

Many arguments about a GRC dashboard are really arguments about definitions. Write every metric as a short specification that names the numerator, the denominator, the record type, the status values that qualify, and the date that places a record in a period. The table shows the parts a specification needs and the mistake each one often attracts.

The roles and RACI breakdown is the place to settle who signs each metric specification, so the owner question does not have to be decided in the committee room.

Putting a new metric on the dashboard in order

1. Write the specification and have the named metric owner sign it.
2. Build the calculation as a saved report, then check the report against a sample of records selected and verified by hand.
3. Compare the report with an independent count for one period and investigate every difference before accepting it.
4. Publish the figure with its definition visible beside the number, not behind a link.
5. Review the metric after two cycles and decide whether the target still describes the risk appetite.

When a metric improves for the wrong reason

Any target creates pressure to game the number. A closure rate climbs when findings are reclassified as accepted risk rather than fixed. A repeat-finding rate falls when the same weakness is written up under a new title. An attestation rate rises when acknowledgement becomes a condition of a routine login that people click through. Pair each headline rate with a quality check that samples the records behind it, and ask the owner to explain any sudden change before it reaches the committee. Keeping the underlying risk records accurate is the subject of the operational risk register guide.

Deciding when the metric set has outgrown its purpose

A metric should earn its place by changing a decision. Retire any measure that nobody has acted on for two committee cycles, and add a new one only when a decision is waiting for it. Dashboards that accumulate measures over time bury the few that matter under dozens that do not. Where the source data is still being cleaned, show the metric as pending rather than as a zero, so a gap cannot be read as good news.

Holding back a metric the data cannot support

Some measures are not yet meaningful. A detection latency figure built from incidents where the detection point was never recorded is an estimate presented as a measurement. Where the population is small, one late finding can swing a rate sharply, so show the count beside the rate, or report the trend across a longer window. Reporting the coverage gap itself is sometimes the most honest metric available until the data supports the measure. The risk assessment and control testing service page describes OBLYTECH’s work in this area.

Questions teams ask once the metrics are live

Should a metric be reported as a count or as a rate?

Report the count while the population is small or changing, because a rate built on a handful of items moves too easily to mean much. Once the population is stable, show the rate with its count beside it so the committee can see both the movement and the scale behind it.

Who is allowed to change a metric definition?

The metric owner proposes the change, a second reviewer such as internal audit confirms it, and the change is logged with the date it takes effect. A definition changed without a note can make the trend line hard to read across the change.

Why do two reports disagree on one measure?

Compare the saved reports behind each one. The gap is often a filter, a period anchor or an archived-record rule. Settle the definition, rebuild the weaker view from it, and retire the duplicate so the question does not return.

The controls were redesigned mid-year. Can the old and new values share a trend?

Mark the break in the trend rather than blending the two periods. A redesign changes what the metric measures, so the earlier and later values are not directly comparable, and the committee should be told so.

Where to take the next step

When a committee pack contains numbers nobody can explain, the fix is often in the definitions rather than the charts.