KRIs for governance, risk, and compliance

GRC sits at the intersection of three functions that usually run in separate lanes: governance (how decisions get made and who is accountable), risk management (what gets accepted, mitigated, or transferred), and compliance (what obligations exist and how they are evidenced). The signal gets sharp when those three are connected and stays dull when they are not.

The KRIs in this domain behave differently from technical control KRIs. They do not read endpoint coverage or detection latency. They measure program health: whether the risk register has been touched since last quarter, whether policies are current, whether compliance obligations are being tracked before an audit surfaces the gap, and whether risk acceptances are owned by the right level of the organization. These are the signals auditors, regulators, and audit committees use to judge whether a security program is real or performative. If you are still standing up the underlying measurement, start with how to build a KRI program and the consolidated KRI reference library.

The technical domains are covered in the sibling guides: enterprise risk portfolio KRIs, human security KRIs, and security operations KRIs. This guide is the process layer that sits underneath all of them.

KRI inventory

1. Risk register currency and quality

What to measure. The percentage of risks in the register reviewed within the defined review cycle, the percentage owned by someone other than the security team, and the percentage carrying a documented treatment decision (accept, mitigate, transfer, avoid) with a current status.

Why it matters. A register that has not been reviewed since last quarter’s assessment is a historical document, not a risk management tool. A register where every risk is owned by the security team has no accountability distributed into the business. And a register full of “mitigate” decisions with no active action is accepted risk that nobody acknowledged.

Derivation sources:

• GRC platform (ServiceNow GRC, Archer, OneTrust, LogicGate, Draxis): risk record last_modified dates, owner fields, and treatment status.
• Risk register in Excel or SharePoint (common in smaller programs): manual audit of last-review dates and owner attribution.
• Business unit leaders: confirmation of ownership of risks attributed to them.
• Meeting records: risk committee or steering committee agendas showing register reviews.

How to calculate. Currency = (risks reviewed within defined cycle) ÷ (total risks) × 100. Business ownership = (risks with a non-security-team owner) ÷ (total risks) × 100. Treatment quality = (risks with a treatment decision, current status, and review date) ÷ (total risks) × 100.

Status	Criteria
Green	Over 90% reviewed in last cycle; over 60% with a business owner; 100% with a treatment decision and status.
Amber	70–89% current, or majority security-owned with no business accountability.
Red	Under 70% current, or no formal review process, or treatment decisions undocumented.

2. Policy framework currency

What to measure. The percentage of security policies reviewed and approved within their defined cycle (typically annually), the percentage with a documented owner, and the percentage of employees with access to the current policy set.

Why it matters. Outdated policies create two problems. They may not reflect current architecture or regulatory requirements, and they provide a weak foundation for enforcement and audit. Auditors pull policy dates. Regulators ask about review cadence. A policy approved in 2021 and untouched since is a liability in 2026.

Derivation sources:

• Document management system (SharePoint, Confluence, Google Drive): policy version history, review and approval dates, and owner metadata.
• GRC platform: policy management module with review cycle tracking.
• HR or LMS: policy acknowledgment and distribution records.
• Policy framework inventory: master list of required policies versus existing policies for gap analysis.

How to calculate. Currency = (policies reviewed or approved within last 12 months) ÷ (total policies) × 100. Coverage = (required policies documented) ÷ (total required policies in the framework standard) × 100. Distribution = (employees with access to the current policy version) ÷ (total employees) × 100.

Status	Criteria
Green	Over 95% reviewed in last 12 months; 100% with a documented owner; policy distribution tracked.
Amber	80–94% current, or owners undocumented for some policies.
Red	Under 80% current, or material policies (AUP, IR, data handling) over 24 months without review.

3. Compliance obligation tracking completeness

What to measure. The percentage of known regulatory and contractual obligations (SOC 2 controls, PCI DSS requirements, HIPAA safeguards, GDPR articles, SEC Cyber Rules, customer security requirements) with a documented owner, current status, and a linked evidence artifact.

Why it matters. Compliance obligations do not send reminders. Organizations that do not actively track their obligation set discover gaps during audits, at contract renewals, or when a regulator asks. This KRI measures whether you have operational visibility into your full posture before someone else finds the gaps for you.

Derivation sources:

• GRC platform: compliance obligation library with owner, status, and evidence links.
• Compliance automation platforms (Vanta, Drata, Secureframe, Thoropass): control status and evidence collection.
• Contract management system: customer security requirements in MSAs and SaaS agreements.
• External counsel or DPO: regulatory obligation inventory by jurisdiction.
• Audit management system: open findings and remediation status from the last cycle.

How to calculate. (Obligations with owner, current status, and linked evidence) ÷ (total tracked obligations) × 100.

Status	Criteria
Green	Over 95% fully documented; evidence refreshed within 90 days; automated collection for major controls.
Amber	80–94%, or evidence stale (over 6 months), or new regulatory requirements not yet mapped.
Red	Under 80%, or major framework obligations (SOC 2, PCI DSS) with undocumented control ownership, or no tracking system.

4. Audit finding remediation rate

What to measure. The percentage of findings from internal audits, external audits, regulatory examinations, and penetration tests remediated within their committed timeline, and the average days overdue for open findings.

Why it matters. Findings that do not get remediated become evidence of a dysfunctional program. Repeat findings, the same issue appearing in consecutive audits, are the clearest signal of a program that documents problems without fixing them. Remediation rate is the outcome metric that validates the whole audit program.

Derivation sources:

• GRC platform or audit management system: finding tracking with committed and actual completion dates.
• Internal audit reports: finding inventory, severity, owner, and committed remediation date.
• External audit reports (SOC 2, ISO 27001, PCI QSA): post-audit remediation tracking.
• Regulatory examination management: findings from OCC, HHS OCR, FTC, SEC, or state regulators with remediation tracking.
• Penetration test finding tracker: open and closed findings by severity and age.

How to calculate. (Findings remediated by committed date) ÷ (total findings with a past commitment date) × 100. Repeat finding rate = (findings appearing in consecutive audit cycles) ÷ (total findings in latest cycle) × 100.

Status	Criteria
Green	Over 90% remediated on time; zero repeat findings in the same control area; critical findings closed within 30 days.
Amber	75–89%, or 1–2 repeat findings with documented root cause analysis.
Red	Under 75%, or critical findings open over 60 days, or repeat findings without root cause, or findings not tracked post-audit.

5. Risk acceptance governance quality

What to measure. The percentage of formal risk acceptances (decisions to accept rather than mitigate a known risk) that include a documented rationale, an appropriate approval authority (not self-approved by the security team), a defined acceptance period, and a scheduled review date.

Why it matters. Risk acceptance is a governance decision, not a security decision. When the security team accepts risk on behalf of the organization without business sign-off, it takes on accountability it should not own. Well-governed acceptances are transparent, time-bounded, and owned at the right level.

Derivation sources:

• GRC platform: risk acceptance records with approval history and expiry dates.
• Risk register: treatment decisions marked accept, audited for completeness of required fields.
• Executive and audit committee records: evidence of business leader sign-off on material acceptances.
• Exception management system: policy exceptions with approval and expiry tracking.

How to calculate. (Risk acceptances with all four required elements: rationale, appropriate approver, defined period, review date) ÷ (total risk acceptances) × 100.

Status	Criteria
Green	100% fully documented; all material acceptances approved by the appropriate business stakeholder; expiry dates enforced.
Amber	80–99%, or the security team self-approving low-risk acceptances without business visibility.
Red	Under 80%, or material acceptances without appropriate business approval, or no expiry dates.

6. Third-party risk program coverage

What to measure. The percentage of active vendors with data access or critical system dependencies that have been assessed within the defined cycle, carry a current risk rating, and have a documented owner accountable for vendor risk decisions.

Why it matters. Regulators (OCC, SEC, FFIEC, HHS) expect documented third-party risk programs with oversight for material vendors, and auditors and audit committees look for the same. Coverage gaps mean unassessed risk in your vendor portfolio, which is accepted risk that nobody accepted. For the supporting vendor signals, see the third-party risk intelligence guide.

Derivation sources:

• Third-party risk management platform (ProcessUnity, Prevalent, OneTrust, Draxis TPRM): vendor inventory with tier classification, assessment dates, and current ratings.
• Procurement system: vendor contract database, cross-referenced against the TPRM platform for coverage.
• Legal and contract management: data processing agreements (DPAs) and security requirements in vendor contracts.
• Business unit input: business-critical vendors not in centralized tracking (shadow vendor risk).

How to calculate. (Tier 1 vendors assessed in last 12 months) ÷ (total Tier 1 vendors) × 100. (Tier 2 vendors assessed in last 24 months) ÷ (total Tier 2 vendors) × 100.

Status	Criteria
Green	Over 90% Tier 1 current; over 85% Tier 2 current; all vendors with data access have a DPA or equivalent.
Amber	75–89% Tier 1, or vendor inventory incomplete (known shadow vendors).
Red	Under 75% Tier 1 assessed, or any Tier 1 vendor with data access and no DPA, or no formal vendor tiering.

7. Control testing and evidence currency

What to measure. The percentage of key controls (those mapped to material risks or compliance obligations) with evidence of testing within the defined cycle, and evidence artifacts fresh enough to support the current audit period.

Why it matters. Controls that are documented but not tested are assumptions, not assurances. Evidence that is 18 months old does not demonstrate current effectiveness. This KRI measures whether your control assurance process is keeping pace with your obligation set and your audit calendar.

Derivation sources:

• GRC platform or compliance automation (Vanta): control test dates and evidence artifact upload dates.
• Internal audit workpapers: tested controls per cycle with last-test dates.
• SOC 2 or ISO 27001 audit preparation: evidence freshness as of the audit window start.
• Control owner attestations: self-attestation records with dates.

How to calculate. (Key controls with test evidence fresh within the defined cycle) ÷ (total key controls) × 100. Cycle definition: quarterly for high-criticality controls, semi-annually for medium, annually for low.

Status	Criteria
Green	Over 95% of key controls with current test evidence; automated collection for repeatable controls.
Amber	80–94%, or manual evidence collection creating periodic freshness gaps.
Red	Under 80%, or controls entering the audit window without current evidence, or no defined testing cycle.

8. GRC program maturity trend

What to measure. Year-over-year change in GRC program maturity assessed against a defined scale, covering risk management process quality, compliance coverage, governance structures, and audit program effectiveness.

Why it matters. A GRC program that is not improving drifts toward compliance theater, activity that looks like risk management without producing risk reduction. Maturity trending is the meta-signal that tells leadership whether the GRC investment is building lasting capability or just holding the status quo.

Derivation sources:

• Annual maturity assessment (CMMI for Risk Management, ISACA COBIT maturity, internal maturity model): scored by an internal or external assessor.
• GRC platform metrics year-over-year: register quality, audit finding closure rate, and policy currency are objective maturity signals.
• Regulatory examination outcomes: improvement or regression in examiner findings.
• Audit committee feedback: quality of risk reporting as perceived by governance bodies.

Status	Criteria
Green	Measurable improvement year-over-year on the defined scale, with specific capability gains documented.
Amber	Flat maturity, maintaining current state without regression.
Red	Declining maturity, or no assessment in the last 18 months, or regression in core metrics (audit findings rising, policy currency falling).

Deriving GRC KRIs by source type

From GRC platforms (ServiceNow GRC, Archer, OneTrust, LogicGate)

For the risk register query, filter review_date < TODAY() - review_cycle_days for overdue reviews, and count the owner field to get the business-versus-security ownership split. For the risk acceptance audit, filter treatment = "accept" and check required-field completeness. For control evidence, filter evidence_date < TODAY() - control_cycle_days for stale artifacts. For the audit finding tracker, calculate (findings with resolution_date <= committed_date) ÷ (total past-due findings).

From compliance automation platforms (Vanta, Drata, Secureframe)

Pull control status as an API export of pass, fail, and in-progress status across frameworks, where integration with source systems provides automated evidence. Read evidence freshness from the last_collected_at timestamp per control and flag controls with stale automated collection. Compute framework coverage as controls mapped to SOC 2, ISO 27001, or PCI DSS versus total framework requirements. Watch integration health: connected sources (AWS, GitHub, Okta) with last-sync timestamps, since stale integrations produce stale evidence. The Vanta integration guide covers wiring this into Draxis.

From audit management systems (AuditBoard, Galvanize, TeamMate)

Measure finding age as open finding creation date versus committed remediation date, where overdue is a missed SLA. Detect repeat findings by cross-referencing finding descriptions across consecutive cycles, matching on control area and finding category. Track testing completion as the test plan completion rate per cycle, with tests not yet executed against total in scope.

From document management systems (SharePoint, Confluence)

Read policy review dates from the Modified metadata on policy documents and cross-reference with the defined review cycle. Map policy owners from the document owner field, alerting on policies with no assigned owner or an owner who has left. Capture distribution evidence from policy acknowledgment records and LMS completion data for policy training.

From procurement and contract systems

Measure vendor DPA coverage by exporting active vendor contracts with data access and cross-referencing against DPA or security addendum execution status. Flag contracts with data access but no documented security requirements for contract security clause coverage. Feed the upcoming assessment schedule from contract renewal dates for critical vendors.