GRC metrics are the measurements that show whether a governance, risk, and compliance program is working. They track how well controls hold up, how quickly risks are found and fixed, and how reliably an organization meets its obligations, and together they signal how mature the program has become. The right handful, tracked consistently, turns a subjective sense that things are fine into evidence you can put in front of a board, an auditor, or a customer running a security review.
The twelve metrics below are split evenly across the three parts of GRC, with four for governance, four for risk management, and four for compliance. Each entry covers what the metric measures, how to calculate it, and how to improve it. Track the ones that match where your program is today, and add the rest as it matures.
1. Board engagement and oversight
Board engagement and oversight measures how actively senior leadership takes part in the GRC program. Governance is harder to quantify than risk or compliance, but leadership involvement is one of the clearest signals that governance is real rather than a formality. The metric usually combines several inputs, including attendance at board and committee meetings, the number of senior leaders directly involved in the program, the hours leaders commit to it, and how often security and governance topics appear on the board agenda.
Strong numbers here tend to pull the rest of the program along, since a board that treats governance as a standing priority funds it and holds owners accountable. Weak numbers are an early warning that GRC is being delegated and forgotten. Tracking the trend over several quarters matters more than any single meeting, because engagement that only spikes before an audit is not real oversight.
How to calculate this metric
Combine a few inputs into a simple scorecard rather than chasing one number. Track attendance as meetings attended divided by meetings held, count the senior leaders with a direct role in the program, total the leadership hours committed, and record how many board agendas in the period included a governance or security item. Review the set together each quarter so a dip in one shows up against the others.
How to improve this metric
Put governance and security on the board agenda as a recurring item rather than an occasional one, so oversight is built into the calendar. Give leaders a short, plain summary of program status ahead of each meeting so their time is spent on decisions, not briefings. Name a specific executive sponsor who owns the program's relationship with the board. Tie a few leadership objectives to GRC outcomes so involvement is expected rather than volunteered, and report the engagement trend back to the board so they can see their own participation.
2. Policy acceptance rate
Policy acceptance rate is the share of employees who have formally read and acknowledged the policies that apply to them. It tells you whether the rules the organization has written are actually reaching the people expected to follow them. A low rate means policies exist on paper but not in practice, which is a gap an auditor and an attacker can both exploit.
Acceptance is a floor rather than a ceiling, since acknowledging a policy is not the same as understanding it, but it is a necessary first step and an easy one to measure. Tracking it by policy and by team shows where acknowledgment is lagging, often among new hires or contractors who slipped through onboarding. Pairing it with policy violations and exceptions gives a fuller picture of whether the rules are both seen and followed.
How to calculate this metric
Divide the number of employees who have accepted a given policy by the number required to accept it, then express it as a percentage. Run it per policy and roll the results into an overall figure, drawing the data from the system where acknowledgments are captured. Segment by team and start date so you can see where acceptance is slipping.
How to improve this metric
Fold policy acknowledgment into onboarding and into every material policy update so no one is missed at the start or left on an old version. Automate reminders to anyone with an outstanding acknowledgment rather than tracking them down by hand. Keep policies short and readable, since walls of text lower both acceptance and understanding. Tie acknowledgment to system access where it makes sense, and re-run acceptance whenever a policy changes in a way that affects how people work.
3. Security training completion rate
This metric is the percentage of required employees who completed mandatory security and compliance training by its deadline. Written as the inverse of incomplete training, it measures whether the workforce is being equipped to follow the policies the organization has set. It is a governance and a people metric at once, since untrained staff are among the most common ways controls fail.
Completion on its own can mislead, so read it next to pass rates and, where you can, phishing simulation results. A full completion rate sitting beside a high simulation failure rate means people clicked through the training without absorbing it. Breaking the number down by department surfaces the teams that need a different approach rather than another reminder.
How to calculate this metric
Divide the number of employees who completed and passed training by the deadline by the total number required to take it, shown as a percentage. Source both figures from your HR or learning system, and run the number per campaign and per department rather than as a single company-wide total. Track the pass rate alongside completion so the metric reflects understanding and not only attendance.
How to improve this metric
Make enrollment and deadlines automatic through your learning system so no one has to be chased. Keep sessions short and role-specific, since a finance team and an engineering team face different risks. Tie completion to a visible consequence, such as access reviews, so the deadline carries weight. Reinforce the material with periodic simulations rather than a single annual event, and follow up individually with repeat non-completers instead of emailing the whole company again.
{{cta_withimage8="/cta-blocks"}}
4. GRC program cost
GRC program cost is the total spend required to run the program, including tooling, headcount, external audits, and the staff time spent on governance, risk, and compliance work. It is a governance metric because it forces the program to justify itself in the same terms as any other part of the business. Measured well, it turns a vague sense that compliance is expensive into a number leaders can weigh against the risk it reduces.
The point of tracking cost is not simply to cut it but to understand it. A rising cost paired with faster audits and fewer findings is money well spent, while a rising cost with flat outcomes signals waste or manual work that should be automated. Watching cost per framework or cost per audit over time shows whether the program is getting more efficient as it grows.
How to calculate this metric
Add up the direct and indirect costs of the program over the period, including software, salaries and the fraction of time non-GRC staff spend on compliance, audit fees, and any remediation spend. Divide the total by a meaningful unit, such as per framework maintained or per audit completed, to make it comparable over time. Keep the categories consistent between periods so the trend reflects real change.
How to improve this metric
Automate the manual, repeatable work first, since evidence collection and status tracking by hand are usually the largest hidden cost. Reuse controls and evidence across frameworks so a single piece of work satisfies several obligations at once. Retire tools and tasks that no longer reduce meaningful risk. Benchmark cost against outcomes rather than against a target number, and revisit the biggest line items each year to confirm they still earn their place.
5. Risk coverage versus risk exposure
Risk coverage versus exposure compares how much of your known risk surface is under active management against the total risk you have identified. It answers a blunt question. Of everything you know could hurt you, how much are you actually doing something about it. A low ratio means risks are being logged and then left to sit.
This metric keeps a risk register honest as part of a working risk management strategy. It is easy to fill a register with hundreds of entries and feel productive, but coverage shows whether those entries have owners, treatments, and monitoring, or whether they are just a list. Tracking it over time also reveals whether new risks are being brought under management as fast as they are discovered.
How to calculate this metric
Divide the number of identified risks that have an owner, a treatment, and active monitoring by the total number of risks in your register, then express it as a percentage. Weight the calculation toward high and critical risks if you want a sharper read on the exposure that matters most. The inputs come straight from the risk register, so its accuracy sets a ceiling on what this number can tell you.
How to improve this metric
Assign an owner and a treatment plan to every risk the moment it enters the register, not in a later cleanup. Prioritize by impact so the highest-severity risks are covered first when resources are tight. Set a threshold, such as full coverage of all high and critical risks, and report against it. Link risks, controls, and monitoring so coverage updates itself as controls come online, and review the uncovered risks at every risk committee meeting.
6. Proactive versus reactive risk ratio
This metric splits your risk activity into work you initiated and work you were forced into, then sets one against the other. Proactive work includes assessments, control testing, and threat modeling done before anything goes wrong. Reactive work is everything triggered by an incident, an audit finding, or a customer complaint.
A program dominated by reaction is always a step behind, spending its budget on cleanup rather than prevention. Shifting the ratio toward proactive work is one of the clearest markers of a maturing program. The number will never reach pure prevention, since incidents happen, but a steady move in that direction shows the program is getting ahead of its risks instead of chasing them.
How to calculate this metric
Tag each risk activity as proactive or reactive, then divide the proactive activities by the total, or express the two sides as a ratio. Proactive covers scheduled assessments, control tests, and threat modeling, while reactive covers anything an incident, finding, or complaint set off. Capture the tag when the work is logged so the split is recorded rather than reconstructed later.
How to improve this metric
Schedule proactive activities as recurring commitments, including regular risk assessments, control tests, and tabletop exercises, so they are not the first thing dropped when the team gets busy. Track how each hour of risk work was triggered so the ratio is measured rather than guessed. Feed lessons from every incident back into proactive controls so the same issue does not return as reactive work. Protect a fixed share of the team's time for prevention, and report the ratio to leadership so the shift stays a priority.
7. Average remediation time for identified risks
Average remediation time, often called mean time to remediate, is how long it takes on average to close a risk or finding once it has been identified, measured from discovery to confirmed fix. It captures speed, and speed is what limits how long an open weakness can be exploited. It is one of the most watched risk metrics because it maps directly to real exposure.
A single average can hide a lot, so track remediation time for critical and high-severity items separately from the rest. A program that closes low-severity findings quickly but lets critical ones linger has an average that looks fine and a real risk that is not. Watching the trend also tells you whether your remediation capacity is keeping pace as the volume of findings grows.
How to calculate this metric
For every risk closed in the period, measure the days from discovery to confirmed fix, then take the average across them. Calculate it separately for each severity tier, since a blended average hides slow critical fixes behind fast low-risk ones. Pull the timestamps from your ticketing system or risk register so the start and end points are consistent across teams.
How to improve this metric
Set remediation targets tied to severity, with a tight window for critical items and a longer one for low-risk ones, and route each risk automatically to the team that owns the fix. Remove the manual handoffs where findings sit in an inbox waiting to be assigned. Give owners the context they need, including affected systems and suggested fixes, so they are not starting from scratch. Escalate anything that breaches its target, and study recurring slow spots to find the process bottleneck rather than blaming individual teams.
8. Critical findings in risk assessments
This metric counts the critical and high-severity findings surfaced by your risk assessments over a period. Unlike a speed or coverage measure, it tracks the raw volume of serious problems your assessments are turning up, which says something about both your risk environment and the depth of those assessments. A sudden spike or a long-running high count both deserve attention.
The number is most useful read in context. A rising count is not automatically bad, since better assessments find more of what was always there, but a rising count with slow remediation is a clear warning. Tracking where critical findings cluster, by system, team, or vendor, points you toward the parts of the organization that carry the most concentrated risk.
How to calculate this metric
Count the findings rated critical or high across all risk assessments completed in the period, using a consistent severity scale so the number means the same thing each time. Break the count down by source, such as internal systems, vendors, or specific business units, to see where serious risk concentrates. Track it alongside remediation time so volume is always read next to how fast those findings are being closed.
How to improve this metric
Standardize how findings are scored so severity is applied the same way across every assessment and team. Route critical findings straight into remediation with a named owner rather than letting them wait for a report. Use recurring critical findings to target the root causes that keep generating them, whether that is a fragile system or a weak vendor. Increase assessment frequency for the highest-risk areas, and review the critical-finding trend with leadership so the serious items get visibility.
9. Control implementation rate
Control implementation rate is the share of required controls that are in place and operating as intended against a given framework or law. It is a foundational compliance metric because it maps directly to audit readiness. A high rate means most of what an auditor will ask for already works, while a low rate means gaps that tend to surface at the worst possible time.
The phrase operating as intended matters here. A control that exists on paper but has never been tested does not count, so this metric should draw on control test results rather than a checklist of good intentions. Reading it per framework shows exactly where you stand against each obligation your compliance program has taken on.
How to calculate this metric
Divide the number of required controls that are in place and passing their tests by the total number of controls the framework or law requires, shown as a percentage. Base the numerator on control test results rather than a checklist, so a control only counts once it is confirmed to work. Calculate it per framework, such as SOC 2 or ISO 27001, to see where each obligation stands on its own.
How to improve this metric
Map every required control to an owner and a piece of monitoring so its status is always current rather than rediscovered during audit prep. Test controls continuously instead of once a year, so a control that drifts out of place is caught early. Prioritize the controls shared across multiple frameworks, since fixing one lifts several compliance scores at once. GRC automation can pull control status directly from your systems, which keeps this rate live and removes the manual evidence chase that slows most teams down.
10. Critical audit findings
This metric counts the critical findings raised during internal and external audits over a period. Audit findings are the formal record of where your program fell short of a requirement, and the critical ones are those an auditor considers serious enough to flag prominently. The count is a direct read on how much distance sits between your controls and the standards a GRC audit holds you to.
A high or rising number of critical audit findings signals controls that are missing, failing, or poorly evidenced. The findings that repeat from one audit to the next carry the most weight, since they suggest earlier fixes treated the symptom rather than the cause. Tracking findings by control and by owner points you at the processes that keep falling short.
How to calculate this metric
Count the findings an audit rates critical, keeping internal and external audits separate so each is read on its own terms. Track the share of those findings that also appeared in a prior audit, since repeat findings are the more damaging signal. Record which control and owner each finding maps to so the count leads straight to a fix rather than a report.
How to improve this metric
Treat every critical finding with a root cause analysis so the underlying process is corrected, not just the instance the auditor caught. Add monitoring to previously failed controls so drift is detected before the next audit rather than during it. Close the gap between audits by testing your own controls on the same standard an auditor would use. Verify closed findings weeks later to confirm the fix held, and bring the repeat-finding trend to control owners so the pattern gets management attention.
11. Mean time to detect a compliance gap
This metric measures how long, on average, a compliance gap goes unnoticed before someone catches it. A gap might be a control that has failed, a policy that no longer matches a regulation, or a system that fell out of scope, and the longer it stays hidden the more exposure it creates. Short detection times are the mark of a program that monitors continuously rather than checking in once a year.
Detection time is easy to overlook because a gap you have not found does not show up on any dashboard, which is exactly why it deserves attention. A program that only discovers gaps during the annual audit is running blind for most of the year. Measuring detection time forces the organization to treat monitoring as an ongoing responsibility and rewards the investment in it.
How to calculate this metric
For each compliance gap found in the period, estimate the time between when it first appeared and when it was detected, then average across them. Anchor the start point in evidence where you can, such as a configuration change date or a control's last passing test, so the estimate is grounded rather than guessed. Report the average alongside the longest single detection time, since one gap that hid for months matters more than a healthy average.
How to improve this metric
Move from point-in-time checks to continuous control monitoring so gaps surface as they happen rather than at audit time. Set automated alerts on the controls most likely to drift, and tie them to a named owner who acts on them. Widen monitoring to cover new systems and vendors as they come online, since blind spots are where gaps hide longest. Review the slowest detections to find where visibility is missing, and close those gaps in coverage first.
12. Compliance framework coverage
Compliance framework coverage tracks how many frameworks, standards, and laws your organization has committed to and successfully maintains, such as SOC 2, ISO 27001, HIPAA, or GDPR. It reflects both the breadth of your obligations and your ability to keep meeting them at once. For many companies the number grows as they enter new markets and win larger customers, each of whom brings new requirements.
Coverage is a double-edged number, since more frameworks open more revenue but also stretch the same team across more obligations. The goal is not the highest possible count but a set you can maintain without letting any single framework slip. Tracking coverage alongside control implementation rate shows whether growth in scope is outrunning your capacity to support it.
How to calculate this metric
Count the frameworks, standards, and laws your organization actively maintains in good standing, separating the ones fully in place from those still being implemented. Weigh the count against how much control overlap they share, since ten frameworks built on a common control set are lighter to carry than five unrelated ones. Review the list whenever a new market or customer requirement adds an obligation.
How to improve this metric
Build on a shared control foundation so each new framework reuses evidence and controls you already maintain rather than starting fresh. Map the overlap between frameworks so a single control satisfies as many requirements as possible. Add new frameworks deliberately, with the capacity to maintain them, rather than collecting certifications you cannot keep current. Automate cross-framework evidence collection so breadth does not translate into proportionally more manual work.
How to measure GRC maturity
The purpose of measuring your GRC program is to understand where you can make improvements to mature it. OCEG (Open Compliance and Ethics Group) is a global authority on GRC and coined the term and concept of GRC.
OCEG’s GRC maturity model was developed in 2016 as a way to classify how sophisticated a GRC program is and help organizations make incremental progress. This framework is structured into five levels, starting from the foundational to the most advanced:
- Level 1 - Initial: At this level, there are minimal GRC activities and those that do exist are siloed
- Level 2 - Managed: At this level, GRC efforts become more strategic yet remain somewhat informal and disjointed
- Level 3 - Consistent: At this level, there is a unified framework that leads to consistent and formally managed practices across the organization
- Level 4 - Measured: At this level, there is a harmonized approach to GRC with measurable, data-driven outcomes and process automation
- Level 5 - Optimizing: At this level, there is a state of continuous improvement and real-time, risk-first decision making across the company. This is the ideal state where your GRC program is scalable and future-proofed to withstand organizational changes
OCEG’s maturity model not only serves as a roadmap for developing a robust GRC program but also as a benchmark against which organizations can measure their progress. By evaluating your GRC maturity against this model, you can assess where your program stands today, what it may be lacking, and how you can improve it moving forward.
Uplevel your GRC maturity
No program tracks all twelve of these metrics from day one, and it should not try to. The right starting set depends on where your program sits today, so an early-stage team is better served by getting policy acceptance and control implementation measured at all, while a mature team earns its level by watching remediation time, detection speed, and the balance of proactive to reactive work. The value is not in how many metrics sit on a dashboard but in whether each one changes a decision.
What matters most over time is consistency. A metric calculated the same way every quarter, from a reliable source, tells you something true about the direction of the program, while one that shifts its definition to look good tells you nothing. Read together, these numbers do more than report status, since they show how mature the program has become and point to the next thing worth fixing, which turns measurement from an audit chore into a roadmap.
The hard part of all of this is the data. Collecting control status across dozens of systems, gathering evidence before every audit, and keeping a risk register current by hand is where most programs stall, and it is the work Vanta removes. Vanta's Agentic Trust Platform continuously collects evidence, monitors your controls, and brings governance, risk, and compliance into a single view, so the metrics in this guide are produced as a byproduct of running the program rather than a reporting project of their own. The Vanta AI Agent goes further, drafting policies, surfacing program gaps, and taking the first pass at security questionnaires so your team spends its time improving the numbers instead of gathering them. See how Vanta turns these metrics into a live view of your program by booking a demo.
{{cta_simple7="/cta-blocks"}}
Implementing a GRC program
12 GRC metrics compliance teams should track and improve
Looking to upgrade to continuous, automated GRC and get visibility across your entire program?
GRC metrics are the measurements that show whether a governance, risk, and compliance program is working. They track how well controls hold up, how quickly risks are found and fixed, and how reliably an organization meets its obligations, and together they signal how mature the program has become. The right handful, tracked consistently, turns a subjective sense that things are fine into evidence you can put in front of a board, an auditor, or a customer running a security review.
The twelve metrics below are split evenly across the three parts of GRC, with four for governance, four for risk management, and four for compliance. Each entry covers what the metric measures, how to calculate it, and how to improve it. Track the ones that match where your program is today, and add the rest as it matures.
1. Board engagement and oversight
Board engagement and oversight measures how actively senior leadership takes part in the GRC program. Governance is harder to quantify than risk or compliance, but leadership involvement is one of the clearest signals that governance is real rather than a formality. The metric usually combines several inputs, including attendance at board and committee meetings, the number of senior leaders directly involved in the program, the hours leaders commit to it, and how often security and governance topics appear on the board agenda.
Strong numbers here tend to pull the rest of the program along, since a board that treats governance as a standing priority funds it and holds owners accountable. Weak numbers are an early warning that GRC is being delegated and forgotten. Tracking the trend over several quarters matters more than any single meeting, because engagement that only spikes before an audit is not real oversight.
How to calculate this metric
Combine a few inputs into a simple scorecard rather than chasing one number. Track attendance as meetings attended divided by meetings held, count the senior leaders with a direct role in the program, total the leadership hours committed, and record how many board agendas in the period included a governance or security item. Review the set together each quarter so a dip in one shows up against the others.
How to improve this metric
Put governance and security on the board agenda as a recurring item rather than an occasional one, so oversight is built into the calendar. Give leaders a short, plain summary of program status ahead of each meeting so their time is spent on decisions, not briefings. Name a specific executive sponsor who owns the program's relationship with the board. Tie a few leadership objectives to GRC outcomes so involvement is expected rather than volunteered, and report the engagement trend back to the board so they can see their own participation.
2. Policy acceptance rate
Policy acceptance rate is the share of employees who have formally read and acknowledged the policies that apply to them. It tells you whether the rules the organization has written are actually reaching the people expected to follow them. A low rate means policies exist on paper but not in practice, which is a gap an auditor and an attacker can both exploit.
Acceptance is a floor rather than a ceiling, since acknowledging a policy is not the same as understanding it, but it is a necessary first step and an easy one to measure. Tracking it by policy and by team shows where acknowledgment is lagging, often among new hires or contractors who slipped through onboarding. Pairing it with policy violations and exceptions gives a fuller picture of whether the rules are both seen and followed.
How to calculate this metric
Divide the number of employees who have accepted a given policy by the number required to accept it, then express it as a percentage. Run it per policy and roll the results into an overall figure, drawing the data from the system where acknowledgments are captured. Segment by team and start date so you can see where acceptance is slipping.
How to improve this metric
Fold policy acknowledgment into onboarding and into every material policy update so no one is missed at the start or left on an old version. Automate reminders to anyone with an outstanding acknowledgment rather than tracking them down by hand. Keep policies short and readable, since walls of text lower both acceptance and understanding. Tie acknowledgment to system access where it makes sense, and re-run acceptance whenever a policy changes in a way that affects how people work.
3. Security training completion rate
This metric is the percentage of required employees who completed mandatory security and compliance training by its deadline. Written as the inverse of incomplete training, it measures whether the workforce is being equipped to follow the policies the organization has set. It is a governance and a people metric at once, since untrained staff are among the most common ways controls fail.
Completion on its own can mislead, so read it next to pass rates and, where you can, phishing simulation results. A full completion rate sitting beside a high simulation failure rate means people clicked through the training without absorbing it. Breaking the number down by department surfaces the teams that need a different approach rather than another reminder.
How to calculate this metric
Divide the number of employees who completed and passed training by the deadline by the total number required to take it, shown as a percentage. Source both figures from your HR or learning system, and run the number per campaign and per department rather than as a single company-wide total. Track the pass rate alongside completion so the metric reflects understanding and not only attendance.
How to improve this metric
Make enrollment and deadlines automatic through your learning system so no one has to be chased. Keep sessions short and role-specific, since a finance team and an engineering team face different risks. Tie completion to a visible consequence, such as access reviews, so the deadline carries weight. Reinforce the material with periodic simulations rather than a single annual event, and follow up individually with repeat non-completers instead of emailing the whole company again.
{{cta_withimage8="/cta-blocks"}}
4. GRC program cost
GRC program cost is the total spend required to run the program, including tooling, headcount, external audits, and the staff time spent on governance, risk, and compliance work. It is a governance metric because it forces the program to justify itself in the same terms as any other part of the business. Measured well, it turns a vague sense that compliance is expensive into a number leaders can weigh against the risk it reduces.
The point of tracking cost is not simply to cut it but to understand it. A rising cost paired with faster audits and fewer findings is money well spent, while a rising cost with flat outcomes signals waste or manual work that should be automated. Watching cost per framework or cost per audit over time shows whether the program is getting more efficient as it grows.
How to calculate this metric
Add up the direct and indirect costs of the program over the period, including software, salaries and the fraction of time non-GRC staff spend on compliance, audit fees, and any remediation spend. Divide the total by a meaningful unit, such as per framework maintained or per audit completed, to make it comparable over time. Keep the categories consistent between periods so the trend reflects real change.
How to improve this metric
Automate the manual, repeatable work first, since evidence collection and status tracking by hand are usually the largest hidden cost. Reuse controls and evidence across frameworks so a single piece of work satisfies several obligations at once. Retire tools and tasks that no longer reduce meaningful risk. Benchmark cost against outcomes rather than against a target number, and revisit the biggest line items each year to confirm they still earn their place.
5. Risk coverage versus risk exposure
Risk coverage versus exposure compares how much of your known risk surface is under active management against the total risk you have identified. It answers a blunt question. Of everything you know could hurt you, how much are you actually doing something about it. A low ratio means risks are being logged and then left to sit.
This metric keeps a risk register honest as part of a working risk management strategy. It is easy to fill a register with hundreds of entries and feel productive, but coverage shows whether those entries have owners, treatments, and monitoring, or whether they are just a list. Tracking it over time also reveals whether new risks are being brought under management as fast as they are discovered.
How to calculate this metric
Divide the number of identified risks that have an owner, a treatment, and active monitoring by the total number of risks in your register, then express it as a percentage. Weight the calculation toward high and critical risks if you want a sharper read on the exposure that matters most. The inputs come straight from the risk register, so its accuracy sets a ceiling on what this number can tell you.
How to improve this metric
Assign an owner and a treatment plan to every risk the moment it enters the register, not in a later cleanup. Prioritize by impact so the highest-severity risks are covered first when resources are tight. Set a threshold, such as full coverage of all high and critical risks, and report against it. Link risks, controls, and monitoring so coverage updates itself as controls come online, and review the uncovered risks at every risk committee meeting.
6. Proactive versus reactive risk ratio
This metric splits your risk activity into work you initiated and work you were forced into, then sets one against the other. Proactive work includes assessments, control testing, and threat modeling done before anything goes wrong. Reactive work is everything triggered by an incident, an audit finding, or a customer complaint.
A program dominated by reaction is always a step behind, spending its budget on cleanup rather than prevention. Shifting the ratio toward proactive work is one of the clearest markers of a maturing program. The number will never reach pure prevention, since incidents happen, but a steady move in that direction shows the program is getting ahead of its risks instead of chasing them.
How to calculate this metric
Tag each risk activity as proactive or reactive, then divide the proactive activities by the total, or express the two sides as a ratio. Proactive covers scheduled assessments, control tests, and threat modeling, while reactive covers anything an incident, finding, or complaint set off. Capture the tag when the work is logged so the split is recorded rather than reconstructed later.
How to improve this metric
Schedule proactive activities as recurring commitments, including regular risk assessments, control tests, and tabletop exercises, so they are not the first thing dropped when the team gets busy. Track how each hour of risk work was triggered so the ratio is measured rather than guessed. Feed lessons from every incident back into proactive controls so the same issue does not return as reactive work. Protect a fixed share of the team's time for prevention, and report the ratio to leadership so the shift stays a priority.
7. Average remediation time for identified risks
Average remediation time, often called mean time to remediate, is how long it takes on average to close a risk or finding once it has been identified, measured from discovery to confirmed fix. It captures speed, and speed is what limits how long an open weakness can be exploited. It is one of the most watched risk metrics because it maps directly to real exposure.
A single average can hide a lot, so track remediation time for critical and high-severity items separately from the rest. A program that closes low-severity findings quickly but lets critical ones linger has an average that looks fine and a real risk that is not. Watching the trend also tells you whether your remediation capacity is keeping pace as the volume of findings grows.
How to calculate this metric
For every risk closed in the period, measure the days from discovery to confirmed fix, then take the average across them. Calculate it separately for each severity tier, since a blended average hides slow critical fixes behind fast low-risk ones. Pull the timestamps from your ticketing system or risk register so the start and end points are consistent across teams.
How to improve this metric
Set remediation targets tied to severity, with a tight window for critical items and a longer one for low-risk ones, and route each risk automatically to the team that owns the fix. Remove the manual handoffs where findings sit in an inbox waiting to be assigned. Give owners the context they need, including affected systems and suggested fixes, so they are not starting from scratch. Escalate anything that breaches its target, and study recurring slow spots to find the process bottleneck rather than blaming individual teams.
8. Critical findings in risk assessments
This metric counts the critical and high-severity findings surfaced by your risk assessments over a period. Unlike a speed or coverage measure, it tracks the raw volume of serious problems your assessments are turning up, which says something about both your risk environment and the depth of those assessments. A sudden spike or a long-running high count both deserve attention.
The number is most useful read in context. A rising count is not automatically bad, since better assessments find more of what was always there, but a rising count with slow remediation is a clear warning. Tracking where critical findings cluster, by system, team, or vendor, points you toward the parts of the organization that carry the most concentrated risk.
How to calculate this metric
Count the findings rated critical or high across all risk assessments completed in the period, using a consistent severity scale so the number means the same thing each time. Break the count down by source, such as internal systems, vendors, or specific business units, to see where serious risk concentrates. Track it alongside remediation time so volume is always read next to how fast those findings are being closed.
How to improve this metric
Standardize how findings are scored so severity is applied the same way across every assessment and team. Route critical findings straight into remediation with a named owner rather than letting them wait for a report. Use recurring critical findings to target the root causes that keep generating them, whether that is a fragile system or a weak vendor. Increase assessment frequency for the highest-risk areas, and review the critical-finding trend with leadership so the serious items get visibility.
9. Control implementation rate
Control implementation rate is the share of required controls that are in place and operating as intended against a given framework or law. It is a foundational compliance metric because it maps directly to audit readiness. A high rate means most of what an auditor will ask for already works, while a low rate means gaps that tend to surface at the worst possible time.
The phrase operating as intended matters here. A control that exists on paper but has never been tested does not count, so this metric should draw on control test results rather than a checklist of good intentions. Reading it per framework shows exactly where you stand against each obligation your compliance program has taken on.
How to calculate this metric
Divide the number of required controls that are in place and passing their tests by the total number of controls the framework or law requires, shown as a percentage. Base the numerator on control test results rather than a checklist, so a control only counts once it is confirmed to work. Calculate it per framework, such as SOC 2 or ISO 27001, to see where each obligation stands on its own.
How to improve this metric
Map every required control to an owner and a piece of monitoring so its status is always current rather than rediscovered during audit prep. Test controls continuously instead of once a year, so a control that drifts out of place is caught early. Prioritize the controls shared across multiple frameworks, since fixing one lifts several compliance scores at once. GRC automation can pull control status directly from your systems, which keeps this rate live and removes the manual evidence chase that slows most teams down.
10. Critical audit findings
This metric counts the critical findings raised during internal and external audits over a period. Audit findings are the formal record of where your program fell short of a requirement, and the critical ones are those an auditor considers serious enough to flag prominently. The count is a direct read on how much distance sits between your controls and the standards a GRC audit holds you to.
A high or rising number of critical audit findings signals controls that are missing, failing, or poorly evidenced. The findings that repeat from one audit to the next carry the most weight, since they suggest earlier fixes treated the symptom rather than the cause. Tracking findings by control and by owner points you at the processes that keep falling short.
How to calculate this metric
Count the findings an audit rates critical, keeping internal and external audits separate so each is read on its own terms. Track the share of those findings that also appeared in a prior audit, since repeat findings are the more damaging signal. Record which control and owner each finding maps to so the count leads straight to a fix rather than a report.
How to improve this metric
Treat every critical finding with a root cause analysis so the underlying process is corrected, not just the instance the auditor caught. Add monitoring to previously failed controls so drift is detected before the next audit rather than during it. Close the gap between audits by testing your own controls on the same standard an auditor would use. Verify closed findings weeks later to confirm the fix held, and bring the repeat-finding trend to control owners so the pattern gets management attention.
11. Mean time to detect a compliance gap
This metric measures how long, on average, a compliance gap goes unnoticed before someone catches it. A gap might be a control that has failed, a policy that no longer matches a regulation, or a system that fell out of scope, and the longer it stays hidden the more exposure it creates. Short detection times are the mark of a program that monitors continuously rather than checking in once a year.
Detection time is easy to overlook because a gap you have not found does not show up on any dashboard, which is exactly why it deserves attention. A program that only discovers gaps during the annual audit is running blind for most of the year. Measuring detection time forces the organization to treat monitoring as an ongoing responsibility and rewards the investment in it.
How to calculate this metric
For each compliance gap found in the period, estimate the time between when it first appeared and when it was detected, then average across them. Anchor the start point in evidence where you can, such as a configuration change date or a control's last passing test, so the estimate is grounded rather than guessed. Report the average alongside the longest single detection time, since one gap that hid for months matters more than a healthy average.
How to improve this metric
Move from point-in-time checks to continuous control monitoring so gaps surface as they happen rather than at audit time. Set automated alerts on the controls most likely to drift, and tie them to a named owner who acts on them. Widen monitoring to cover new systems and vendors as they come online, since blind spots are where gaps hide longest. Review the slowest detections to find where visibility is missing, and close those gaps in coverage first.
12. Compliance framework coverage
Compliance framework coverage tracks how many frameworks, standards, and laws your organization has committed to and successfully maintains, such as SOC 2, ISO 27001, HIPAA, or GDPR. It reflects both the breadth of your obligations and your ability to keep meeting them at once. For many companies the number grows as they enter new markets and win larger customers, each of whom brings new requirements.
Coverage is a double-edged number, since more frameworks open more revenue but also stretch the same team across more obligations. The goal is not the highest possible count but a set you can maintain without letting any single framework slip. Tracking coverage alongside control implementation rate shows whether growth in scope is outrunning your capacity to support it.
How to calculate this metric
Count the frameworks, standards, and laws your organization actively maintains in good standing, separating the ones fully in place from those still being implemented. Weigh the count against how much control overlap they share, since ten frameworks built on a common control set are lighter to carry than five unrelated ones. Review the list whenever a new market or customer requirement adds an obligation.
How to improve this metric
Build on a shared control foundation so each new framework reuses evidence and controls you already maintain rather than starting fresh. Map the overlap between frameworks so a single control satisfies as many requirements as possible. Add new frameworks deliberately, with the capacity to maintain them, rather than collecting certifications you cannot keep current. Automate cross-framework evidence collection so breadth does not translate into proportionally more manual work.
How to measure GRC maturity
The purpose of measuring your GRC program is to understand where you can make improvements to mature it. OCEG (Open Compliance and Ethics Group) is a global authority on GRC and coined the term and concept of GRC.
OCEG’s GRC maturity model was developed in 2016 as a way to classify how sophisticated a GRC program is and help organizations make incremental progress. This framework is structured into five levels, starting from the foundational to the most advanced:
- Level 1 - Initial: At this level, there are minimal GRC activities and those that do exist are siloed
- Level 2 - Managed: At this level, GRC efforts become more strategic yet remain somewhat informal and disjointed
- Level 3 - Consistent: At this level, there is a unified framework that leads to consistent and formally managed practices across the organization
- Level 4 - Measured: At this level, there is a harmonized approach to GRC with measurable, data-driven outcomes and process automation
- Level 5 - Optimizing: At this level, there is a state of continuous improvement and real-time, risk-first decision making across the company. This is the ideal state where your GRC program is scalable and future-proofed to withstand organizational changes
OCEG’s maturity model not only serves as a roadmap for developing a robust GRC program but also as a benchmark against which organizations can measure their progress. By evaluating your GRC maturity against this model, you can assess where your program stands today, what it may be lacking, and how you can improve it moving forward.
Uplevel your GRC maturity
No program tracks all twelve of these metrics from day one, and it should not try to. The right starting set depends on where your program sits today, so an early-stage team is better served by getting policy acceptance and control implementation measured at all, while a mature team earns its level by watching remediation time, detection speed, and the balance of proactive to reactive work. The value is not in how many metrics sit on a dashboard but in whether each one changes a decision.
What matters most over time is consistency. A metric calculated the same way every quarter, from a reliable source, tells you something true about the direction of the program, while one that shifts its definition to look good tells you nothing. Read together, these numbers do more than report status, since they show how mature the program has become and point to the next thing worth fixing, which turns measurement from an audit chore into a roadmap.
The hard part of all of this is the data. Collecting control status across dozens of systems, gathering evidence before every audit, and keeping a risk register current by hand is where most programs stall, and it is the work Vanta removes. Vanta's Agentic Trust Platform continuously collects evidence, monitors your controls, and brings governance, risk, and compliance into a single view, so the metrics in this guide are produced as a byproduct of running the program rather than a reporting project of their own. The Vanta AI Agent goes further, drafting policies, surfacing program gaps, and taking the first pass at security questionnaires so your team spends its time improving the numbers instead of gathering them. See how Vanta turns these metrics into a live view of your program by booking a demo.
{{cta_simple7="/cta-blocks"}}
| Role: | GRC responsibilities: |
|---|---|
| Board of directors | Central to the overarching GRC strategy, this group sets the direction for the compliance strategy. They determine which standards and regulations are necessary for compliance and align the GRC strategy with business objectives. |
| Chief financial officer | Primary responsibility for the success of the GRC program and for reporting results to the board. |
| Operations managers from relevant departments | This group owns processes. They are responsible for the success and direction of risk management and compliance within their departments. |
| Representatives from relevant departments | These are the activity owners. These team members are responsible for carrying out specific compliance and risk management tasks within their departments and for integrating these tasks into their workflows. |
| Contract managers from relevant department | These team members are responsible for managing interactions with vendors and other third parties in their department to ensure all risk management and compliance measures are being taken. |
| Chief information security officer (CISO) | Defines the organization’s information security policy, designs risk and vulnerability assessments, and develops information security policies. |
| Data protection officer (DPO) or legal counsel | Develops goals for data privacy based on legal regulations and other compliance needs, designs and implements privacy policies and practices, and assesses these practices for effectiveness. |
| GRC lead | Responsible for overseeing the execution of the GRC program in collaboration with the executive team as well as maintaining the organization’s library of security controls. |
| Cybersecurity analyst(s) | Implements and monitors cybersecurity measures that are in line with the GRC program and business objectives. |
| Compliance analyst(s) | Monitors the organization’s compliance with all regulations and standards necessary, identifies any compliance gaps, and works to mitigate them. |
| Risk analyst(s) | Carries out the risk management program for the organization and serves as a resource for risk management across various departments, including identifying, mitigating, and monitoring risks. |
| IT security specialist(s) | Implements security controls within the IT system in coordination with the cybersecurity analyst(s). |
Explore more GRC articles
Introduction to GRC
Implementing a GRC program
Optimizing a GRC program
Governance
Risk
Compliance
Continuous control monitoring
Get started with GRC
Start your GRC journey with these related resources.
What is GRC Engineering? A fresh take on an old space
Watch on-demand to hear from Lovable and Vanta and learn what modern GRC actually looks like when it is done right.
%20.png)
How to build an enduring security program as your company grows
Join Vanta's CISO, Jadee Hanson, and seasoned security leaders at company's big and small to discuss building and maintaining an efficient and high performing security program.
Growing pains: How to evolve and scale inherited security processes
Manual processes and siloed tools can slow you down. Get our tactical guide to building a scalable, resilient security program.
