Learn how GRC analysts monitor risk exposure, develop meaningful Key Risk Indicators (KRIs), recognise emerging threats and prepare risk reports that support management decisions.
Completing a risk assessment does not mean the risk management process is finished.
An organisation may identify a critical cybersecurity risk, implement additional controls and conclude that the remaining exposure is acceptable. Three months later, circumstances may have changed.
A previously effective control may no longer operate as expected. A supplier may experience repeated service outages. A critical vulnerability may remain unresolved, or a new business activity may increase the potential consequences of an existing risk.
If these changes are not monitored, management may continue relying on an outdated assessment.
Risk monitoring is the process of tracking risk exposure, relevant indicators, control performance and changes in business circumstances to determine whether existing risk decisions remain appropriate.
For a GRC analyst, this means more than updating a spreadsheet. It involves collecting reliable information, recognising important changes, challenging assumptions and communicating risks to the people responsible for making decisions.
In this guide, we will examine how organisations monitor risk, establish meaningful Key Risk Indicators (KRIs) and prepare management reports that support effective decisions.
Risk assessments represent an evaluation at a particular point in time.
Even where a risk has been formally accepted or treated, its exposure can change.
Consider a financial services business that relies on an external payment processor.
During its initial assessment, the organisation determines that the likelihood of prolonged disruption is low because the supplier has demonstrated strong availability and recovery arrangements.
Six months later, the supplier experiences repeated outages and misses several service commitments.
The original assessment may no longer reflect the current situation.
Monitoring helps the organisation identify this deterioration and determine whether it needs to reassess the risk, introduce additional controls, escalate the exposure or reconsider its dependency on the supplier.
Risk monitoring supports five important activities:
An effective monitoring process should answer three questions:
A Key Risk Indicator (KRI) is a measure used to provide information about changes in risk exposure or conditions that may influence that exposure.
KRIs help organisations identify emerging concerns before they develop into more serious problems.
For example, an organisation might monitor the percentage of critical vulnerabilities that have exceeded their approved remediation deadlines.
An increasing percentage could indicate that exposure is growing, controls are becoming less effective or remediation capacity is insufficient.
Other examples include:
| Risk area | Example KRI | What it may indicate |
|---|---|---|
| Cybersecurity | Percentage of overdue critical vulnerabilities | Increasing exposure to exploitation |
| Third-party risk | Number of critical suppliers with unresolved high-risk findings | Growing supplier-related exposure |
| Operational resilience | Cumulative unplanned downtime of a critical service | Deteriorating service resilience |
| Identity and access | Number of overdue privileged-access reviews | Increased possibility of inappropriate access remaining undetected |
| Financial risk | Forecast loss exposure relative to approved limits | Potential breach of financial risk appetite |
| Compliance | Number of overdue high-severity compliance actions | Unresolved compliance exposure |
A KRI does not necessarily prove that a risk event will occur.
It provides information that should be interpreted in the context of the underlying risk, current controls, business objectives and other available evidence.
KRIs may be leading or lagging.
Leading indicators provide information about conditions that could increase the likelihood or impact of a future event.
Examples include a growing number of overdue security patches or an increasing concentration of services with one supplier.
Lagging indicators reflect outcomes or events that have already occurred.
Examples include actual service downtime, confirmed security incidents or realised financial losses.
Both can be useful.
Leading indicators can support early intervention, while lagging indicators provide evidence of outcomes and may reveal weaknesses in earlier assumptions.
However, the same measure can serve different purposes depending on how an organisation uses it. Labels are less important than understanding what the measure tells management.
GRC analysts often encounter three categories of indicators.
KRIs provide information about risk exposure or relevant conditions.
Example: Percentage of critical internet-facing vulnerabilities that exceed the remediation deadline.
KPIs measure performance against a defined objective.
Example: Percentage of scheduled vulnerability scans completed on time.
KCIs measure whether a particular control is operating or performing as expected.
Example: Percentage of privileged accounts covered by enforced phishing-resistant multifactor authentication.
These measures can overlap.
For example, the percentage of overdue access reviews might be treated as a control performance measure or as an indicator of access-related risk, depending on its purpose.
| Indicator | Example | Primary question |
|---|---|---|
| KRI | Overdue critical vulnerabilities | Is risk exposure increasing? |
| KPI | Vulnerability scans completed on schedule | Are we achieving our operational objective? |
| KCI | Critical assets covered by authenticated scanning | Is the control operating as intended? |
A useful dashboard may combine these measures.
The important point is to avoid confusing good operational performance with low risk.
A team might complete every scheduled vulnerability scan while still having several critical vulnerabilities that remain unremediated.
The KPI would appear healthy, but the underlying exposure could remain unacceptable.
Not every available metric deserves to become a KRI.
A meaningful indicator should have a clear relationship with a defined risk and help someone decide whether further action is necessary.
Start with a documented risk statement.
Example:
A critical third-party payment processor may experience prolonged service disruption, resulting in failed customer transactions, financial losses and reputational damage.
The indicator should relate to this specific exposure.
Relevant conditions could include:
For the example above, the organisation might select:
Monthly cumulative unplanned downtime of the critical payment service.
This measures actual service disruption and helps management determine whether its approved tolerance is being approached or exceeded.
The measure must be consistent and reproducible.
For example:
Monthly downtime = Sum of qualifying unplanned service interruptions during the calendar month.
The organisation must define which services are in scope, what counts as an interruption, how partial outages are handled and which data source is authoritative.
Without these definitions, two teams could report different results for the same period.
Using the organisation's approved tolerance framework, it might define:
| Monthly downtime | Status | Action |
|---|---|---|
| Less than 2 hours | Normal | Continue monitoring |
| 2 to less than 3 hours | Warning | Investigate the trend |
| 3 to 4 hours | Escalation | Notify the designated risk authority |
| More than 4 hours | Breach | Initiate formal breach management |
These limits are fictional organisational examples, not universal industry requirements.
Every indicator should have a designated person or team responsible for collecting and validating the underlying information.
There should also be a clearly identified risk owner responsible for the business risk and resulting decisions.
The GRC analyst may coordinate reporting and challenge the evidence, but does not automatically own the risk itself.
Some indicators need daily monitoring, while others may be suitable for weekly, monthly or quarterly review.
Frequency should reflect the speed at which exposure can change and the time available to intervene.
A critical operational resilience measure may need near-real-time monitoring, while a strategic concentration-risk indicator might be reviewed monthly.
Consider Meridian Financial Services, a fictional UK financial technology company.
The organisation has identified the following risk:
Critical vulnerabilities affecting internet-facing production systems may be exploited, resulting in unauthorised access, customer service disruption and potential financial loss.
The approved policy requires validated critical vulnerabilities within the defined scope to be remediated within seven calendar days unless an authorised exception applies.
The GRC team monitors the percentage of critical vulnerabilities that are overdue.
KRI: Percentage of validated critical vulnerabilities past the approved remediation deadline.
Formula:
Overdue percentage = (Overdue critical vulnerabilities ÷ Total open validated critical vulnerabilities in scope) × 100
For this example, overdue exceptions remain included in the numerator, even where an exception has been approved. The exception status is reported separately to maintain visibility of the exposure.
The organisation has defined these illustrative KRI thresholds:
| Overdue percentage | KRI status |
|---|---|
| Less than 10% | Normal |
| 10% to less than 20% | Warning |
| 20% or more | Escalation |
| Month | Open critical vulnerabilities | Overdue | Overdue percentage |
|---|---|---|---|
| January | 20 | 1 | 5% |
| February | 25 | 3 | 12% |
| March | 30 | 9 | 30% |
The monitoring results show deterioration.
January is within the normal KRI band.
February reaches the warning band.
March exceeds the escalation threshold.
However, the analyst should not conclude that the overall cyber risk has increased by exactly 25 percentage points. The KRI measures overdue vulnerability proportions, not the probability of a cyber incident.
The analyst should examine the underlying vulnerabilities, affected assets, exploitability, business criticality and existing controls.
Before reporting, the analyst should establish:
An increase in detected vulnerabilities could result partly from improved discovery. It should not automatically be interpreted as an identical increase in underlying risk.
The analyst should notify the relevant risk owner and follow the approved escalation procedure.
Management may need to prioritise remediation, allocate additional resources, evaluate compensating controls or reassess residual risk.
If individual vulnerabilities have breached their seven-day remediation deadline, those breaches must be handled under the organisation's policy, regardless of the aggregate KRI's status.
This distinction matters:
A portfolio-level indicator is not a substitute for managing individual risks and control exceptions.
An indicator's current value is useful, but its trend may be equally important.
Consider two departments:
| Department | Current overdue rate | Previous month |
|---|---|---|
| Department A | 12% | 28% |
| Department B | 12% | 4% |
Both departments currently have the same overdue rate.
However, Department A is improving while Department B is deteriorating.
The appropriate management response may differ.
A GRC analyst should consider:
One reporting period should rarely be treated as sufficient evidence of a sustained trend.
Changes in the data collection process, scope or reporting population can also create misleading comparisons.
KRIs are only one part of risk monitoring.
Organisations also need to monitor whether agreed risk treatments are being implemented.
A treatment tracker might include:
| Field | Example |
|---|---|
| Risk reference | CYB-014 |
| Treatment | Implement phishing-resistant MFA for privileged accounts |
| Risk owner | Head of Technology |
| Action owner | Identity and Access Management Lead |
| Target date | 30 November |
| Progress | Implementation underway |
| Evidence required | Configuration export and coverage test |
| Current residual risk | High |
| Target risk | Moderate |
| Next review | 15 November |
The target risk is not the current residual risk.
Until the control is implemented and its effectiveness has been evaluated, the anticipated reduction should not be represented as already achieved.
An action marked complete in a project tracker does not automatically demonstrate that the control works.
For instance, a team might report that MFA deployment is complete, but subsequent verification could identify service accounts or privileged identities that are not properly protected.
The GRC analyst should request appropriate evidence and coordinate reassessment before recommending closure.
Risk reporting should enable decisions rather than simply reproduce the contents of a risk register.
An executive does not necessarily need every technical detail associated with a vulnerability.
They need to understand the business exposure, why it matters, whether it is within appetite and which decisions require their attention.
A useful report generally addresses five questions:
Organisation: Meridian Financial Services (fictional)
Reporting period: March
Overall observation: Vulnerability remediation performance has deteriorated, increasing concern about internet-facing systems.
| Reporting item | Position |
|---|---|
| Critical vulnerability KRI | 30% overdue, exceeding the 20% escalation threshold |
| Previous position | 12% overdue in February |
| Primary concern | Delayed remediation on internet-facing production systems |
| Risk owner | Head of Technology |
| Treatment status | Additional remediation capacity proposed |
| Required decision | Approve a prioritised remediation plan and confirm accountable owners |
The percentage of overdue critical vulnerabilities increased from 12% in February to 30% in March, exceeding the approved escalation threshold of 20%. The Technology team is reviewing affected systems and remediation delays. Management is requested to approve the proposed prioritisation plan and confirm interim risk controls. The GRC team will track progress and report the updated exposure at the next review.
This is more useful than simply reporting that nine vulnerabilities are overdue.
The statement explains the movement, the governance implication and the decision needed.
It does not claim that a cyber incident has occurred or assign a specific probability of compromise without supporting analysis.
Dashboards can help management identify changes quickly.
However, a dashboard should not become a collection of attractive charts without meaningful interpretation.
A practical GRC dashboard may include:
Risk exposure: Risks by category, severity, owner and appetite status.
Risk movement: Risks increasing or decreasing since the previous reporting period.
KRIs: Current values, approved thresholds and trends.
Treatment performance: Actions overdue, completed or awaiting verification.
Exceptions and breaches: Current tolerance breaches, approved exceptions and outstanding management decisions.
Risk ownership: Risks without assigned owners or overdue review dates.
Where possible, every important dashboard indicator should link back to underlying evidence or a source record.
A red indicator should tell management what needs attention, not simply create alarm.
Routine risk reporting and formal escalation are related but different activities.
Routine reports provide periodic visibility of risk.
Escalation draws timely attention to an issue that requires intervention, additional authority or urgent decision-making.
Suppose an organisation produces monthly risk reports, but a critical supplier unexpectedly experiences an outage that exceeds the approved tolerance.
The GRC analyst should not simply wait until the next monthly report.
The breach must be escalated according to the organisation's requirements.
Examples of escalation triggers include:
Some circumstances may also trigger incident response, legal or regulatory processes. These should not be delayed by the ordinary reporting cycle.
Monitoring works best when responsibilities are clear.
| Role | Typical responsibility |
|---|---|
| Risk owner | Accountable for the business risk and management decisions |
| Control owner | Maintains and provides evidence of control operation |
| Treatment action owner | Implements assigned remediation activities |
| GRC analyst | Consolidates data, challenges evidence, monitors trends and facilitates reporting |
| Risk committee | Reviews significant exposures and decisions within its authority |
| Board or governing body | Oversees material enterprise risks and approved risk appetite |
The exact distribution of responsibilities depends on the organisation's governance framework.
A GRC analyst may identify and escalate unacceptable exposure, but should not independently accept a material business risk without delegated authority.
A large number of indicators can make important changes harder to recognise.
Select metrics that have a clear relationship with risks and decisions.
Monitoring thresholds should be documented and approved through the appropriate governance process.
An analyst should not independently change a threshold merely to improve dashboard results.
A value of 15% may be improving or deteriorating. Without history and context, management cannot interpret it reliably.
An acceptable KRI value does not establish that every related risk is controlled.
Individual exceptions, control failures and material incidents still require attention.
Incomplete asset inventories, duplicated records and inconsistent reporting periods can undermine the reliability of a metric.
Implementation status and control effectiveness are not the same thing.
Management reports should explain why a risk matters, the options available and what decision or action is required.
You are a GRC analyst at a fictional healthcare technology company.
The organisation monitors overdue critical vulnerability remediation.
Its approved KRI thresholds are:
At the end of the reporting period, 8 of 32 open validated critical vulnerabilities are overdue.
The previous period's overdue rate was 12%.
Your task:
Current overdue rate = (8 ÷ 32) × 100 = 25%.
The current position exceeds the 20% escalation threshold.
Exposure, as measured by this KRI, has deteriorated by 13 percentage points from the previous period.
The analyst should verify the accuracy of the vulnerability inventory, examine the affected systems, review approved exceptions and identify remediation delays.
Example management report:
The overdue critical vulnerability rate has increased from 12% to 25%, exceeding the approved 20% escalation threshold. Eight of 32 open critical vulnerabilities are past their remediation deadlines. The Technology team should validate affected assets, review existing controls and identify the reasons for delayed remediation. Management is requested to confirm prioritised remediation actions, accountable owners and interim measures for any vulnerabilities that cannot be immediately resolved. Progress should be reviewed at the next agreed escalation checkpoint.
This exercise demonstrates the difference between presenting data and communicating a risk-management decision.
Before completing a periodic risk review, confirm:
Risk management does not end when a risk is assessed or a treatment decision is made.
Risk monitoring helps organisations determine whether their assumptions, controls and management decisions remain appropriate.
KRIs provide information about changing exposure, but their usefulness depends on clear definitions, reliable data and meaningful links to business risks.
KPIs, KCIs and KRIs can complement one another, although they answer different management questions.
Effective risk reporting goes beyond presenting scores and charts. It explains exposure, trends, thresholds, business impact and decisions.
For GRC analysts, the objective is to help the organisation recognise significant changes early and respond through appropriate governance arrangements.
A useful risk report should not leave management asking, "So what?"
It should explain what has changed, why it matters and what needs to happen next.
Next, explore the ERM Toolkit Quick-Start Guide to see how risk records, treatment plans, monitoring information and reporting dashboards work together in practice.
You can also revisit Risk Appetite vs Risk Tolerance and Risk Treatment Strategies to strengthen your understanding of how monitored exposure informs management decisions.