GRC Program Health Checklist: 25 Questions to Ask This Quarter
A GRC program can look healthy from the outside and still be fragile underneath.
The dashboard is published.
The risk register is updated.
The control library exists.
Evidence requests are moving.
Issues are being tracked.
Audits are in progress.
Vendors are being reviewed.
Policies are being refreshed.
Executives are receiving reports.
But a closer look may reveal a different story.
Risks have stale owners.
Controls are mapped to frameworks but not evidence.
Evidence is submitted but not accepted.
Issues are closed without validation.
Vendors are reviewed but not linked to critical services.
Incidents are closed without root cause.
Dashboards are green but source records are weak.
Risk acceptance is approved by email.
The board sees status but not decisions.
The operating committee reviews metrics but does not remove blockers.
That is why every Connected GRC program needs a recurring health check.
Not a once-a-year maturity assessment.
Not a long transformation diagnostic.
Not a generic audit of the GRC function.
A practical quarterly GRC program health checklist should answer one question:
Can the organization trust its GRC operating model to support decisions?
This checklist is designed for that purpose.
Use it each quarter to test whether your GRC program is connected, owned, evidenced, remediated, monitored, and decision-ready.
What is GRC program health?
GRC program health is the degree to which a governance, risk, compliance, audit, control, evidence, issue, vendor, incident, policy, privacy, AI, resilience, and reporting program is operating with clear ownership, reliable data, connected workflows, defensible evidence, effective remediation, and decision-ready dashboards.
A healthy GRC program can show:
who owns risks, controls, evidence, issues, vendors, and decisions
which risks are outside appetite
which controls are operating
which evidence has been accepted
which issues are overdue
which remediation has been validated
which vendors create material exposure
which incidents changed the risk view
which dashboards are built from reliable source records
which decisions need executive attention
An unhealthy GRC program may still be busy.
But it struggles to show whether the work is reducing risk, improving assurance, or helping leaders make decisions.
OCEG’s definition of GRC is useful here because it frames GRC as integrated capabilities that help the organization reliably achieve objectives, address uncertainty, and act with integrity. That means GRC program health should not be measured only by activity. It should be measured by whether the program helps the organization operate with better visibility, accountability, and evidence.
Who should use this checklist?
This checklist is useful for:
GRC program owners
Chief Risk Officers
Chief Compliance Officers
CISOs
General Counsel
CFOs and SOX leaders
Internal audit leaders
Third-party risk leaders
Privacy leaders
AI governance leaders
Operational resilience leaders
Connected GRC operating committees
Executive risk committees
Board and audit committee reporting teams
The checklist can be used in three ways:
Quarterly program review: Use all 25 questions to assess program health.
Monthly operating committee prep: Use selected questions to prepare agenda items.
Roadmap planning: Use weak answers to prioritize the next 30, 60, or 90 days.
The goal is not to score perfectly.
The goal is to identify where the operating model needs attention.
How to use the checklist
For each question, rate the answer:
| Rating | Meaning |
|---|---|
| Green | The program has reliable records, owners, workflows, evidence, and reporting |
| Yellow | The program has partial coverage, inconsistent data, or manual workarounds |
| Red | The program lacks ownership, evidence, workflow, source-record trust, or decision support |
Then assign:
owner
issue or improvement action
due date
dashboard impact
executive decision needed, if any
Do not let the checklist become another static assessment.
If a question is yellow or red, create an action.
A healthy GRC program uses health checks to improve the operating model.
The 25-Question GRC Program Health Checklist
1. Do material risks have clear owners?
A healthy GRC program can show who owns each material risk.
Risk ownership should not be vague.
“IT,” “Compliance,” or “the business” is not enough for material risks.
The program should show:
risk owner
executive owner, where appropriate
mitigation owner
KRI owner
review date
appetite status
linked controls
linked issues
linked incidents
linked vendors, where relevant
If material risks do not have clear owners, the program has an accountability gap.
Healthy answer: Each material risk has a named owner, current review date, appetite status, mitigation plan, and connected records.
Warning sign: Risks are reviewed in workshops but not owned in the operating model.
2. Can executives see which risks are outside appetite?
Risk appetite should not live only in a board-approved document.
Executives should be able to see:
risks outside appetite
risks approaching tolerance
risks with worsening KRIs
accepted risks nearing expiration
risks with overdue remediation
risks affected by incidents or vendors
decisions needed
If the program cannot quickly show which risks are outside appetite, risk reporting is probably too static.
Healthy answer: Risk appetite status appears in dashboards and is reviewed in the monthly or quarterly GRC review.
Warning sign: Risk ratings exist, but appetite thresholds are not measurable or connected to workflow.
3. Are controls mapped to risks and obligations?
A control library is only useful if controls connect to why they exist.
Controls should map to:
risks
obligations
policies
frameworks
evidence
tests
issues
owners
A control that maps only to a framework row may not be meaningful enough.
A control that maps to a risk, obligation, evidence requirement, and test procedure is much stronger.
Healthy answer: Key controls are mapped to risks, obligations, frameworks, evidence, owners, and test procedures.
Warning sign: The control library has many controls but weak risk or obligation mapping.
4. Are key controls supported by accepted evidence?
Evidence submitted is not the same as evidence accepted.
A healthy program distinguishes:
requested
submitted
under review
accepted
rejected
resubmission required
expired
reused
For key controls, executives should know whether accepted evidence exists for the current period.
Healthy answer: Key controls have accepted evidence, reviewer status, period, scope, and issue linkage where evidence fails.
Warning sign: Dashboards count submitted evidence as complete evidence.
5. Are evidence requirements clear to control owners?
Many evidence problems are not control-owner problems.
They are expectation problems.
A healthy program defines:
what evidence is required
what period it covers
what population it must include
who provides it
who reviews it
what counts as accepted
what causes rejection
If control owners have to guess what evidence is needed, the program will create rework.
Healthy answer: Evidence requirements are documented in the control record and visible before the request is sent.
Warning sign: Evidence requirements are described differently in emails, audit request lists, and testing workpapers.
6. Is evidence being reused responsibly across frameworks?
Evidence reuse is one of the strongest signs of Connected GRC maturity.
But reuse must be governed.
The program should know:
which evidence supports multiple frameworks
whether the evidence period aligns
whether the scope aligns
whether the evidence has been accepted
whether sharing restrictions apply
whether framework-specific notes are needed
SmartSuite’s Compliance Management page describes shared controls, centralized evidence, and real-time dashboards as part of connected compliance workflows. That is the kind of model evidence reuse requires.
Healthy answer: Reusable evidence is linked to controls, frameworks, periods, reviewers, and acceptance status.
Warning sign: Teams reuse files from folders without confirming period, scope, or acceptance.
7. Are issues linked to risks, controls, evidence, and root cause?
An issue tracker is not enough.
Issues should connect to:
source
affected risk
affected control
affected obligation
evidence gap
root cause
owner
remediation plan
due date
validation method
residual risk
dashboard status
If issues are not connected to risks and controls, executives cannot see impact.
If issues are not connected to root cause, the same problems will repeat.
Healthy answer: Issues are connected to source records and categorized by root cause.
Warning sign: Issues are tracked as tasks with owners and dates but no risk, control, or root-cause context.
8. Are high-severity issues overdue?
A healthy GRC program knows which high-severity issues are overdue and why.
The dashboard should show:
issue owner
risk impacted
control impacted
due date
days overdue
remediation status
validation status
escalation path
decision needed
Overdue high-severity issues should not sit quietly in a tracker.
They should appear in the monthly review, executive scorecard, and board reporting where appropriate.
Healthy answer: High-severity overdue issues are visible, escalated, and assigned to accountable owners.
Warning sign: Issue reports show closure counts but do not highlight overdue high-risk items.
9. Are issues closed only after remediation is validated?
Issue closure is one of the most misleading GRC metrics.
A program may show strong closure rates while risk remains unresolved.
A healthy program separates:
remediation planned
remediation in progress
remediation complete
evidence submitted
validation pending
validation passed
validation failed
closed
risk accepted
For material issues, closure should require validation.
Healthy answer: High-risk or material issues cannot close without validation evidence or approved risk acceptance.
Warning sign: Issue owners can mark issues closed without independent review or evidence.
10. Are repeat issues and findings visible?
Repeat issues are risk intelligence.
They show that the program may not be addressing root cause.
A healthy program tracks:
repeat control failures
repeat audit findings
repeat evidence rejections
repeat vendor issues
repeat incidents
repeat policy exceptions
repeat remediation extensions
Repeat issues should be reviewed by the operating committee.
They may indicate:
weak control design
unclear ownership
unrealistic policy
insufficient resources
poor training
weak validation
inadequate automation
Healthy answer: Repeat issues are identified, grouped by root cause, and escalated when needed.
Warning sign: Similar issues appear every cycle but are treated as new problems each time.
11. Are vendors connected to contracts, criticality, evidence, and issues?
Vendor risk should not be a standalone spreadsheet.
A healthy vendor record should show:
business owner
contract owner
risk tier
criticality
service provided
data access
system access
contract
evidence
cyber review
privacy review
business continuity review
open issues
incidents
renewal date
risk acceptance
If a vendor supports a critical service, processes sensitive data, or has system access, that relationship should be visible.
Healthy answer: Critical vendors are linked to contracts, evidence, issues, renewals, services, and risk decisions.
Warning sign: Vendor reviews are complete, but no one can show which vendors support critical services or have open issues before renewal.
12. Are incidents linked to root cause, controls, issues, and remediation?
Incident closure should not be the end of the workflow.
A healthy incident record should connect to:
affected asset
affected business service
affected vendor
affected data
severity
response timeline
legal or privacy review
root cause
failed controls
issues created
remediation
validation
lessons learned
dashboard impact
An incident that does not create learning is a missed opportunity.
Healthy answer: Material incidents are linked to root cause, control impact, remediation, and lessons learned.
Warning sign: Incidents are closed in the ticketing system but do not update risks, controls, or issues.
13. Are regulatory changes converted into operational action?
Regulatory change should not stop at legal interpretation.
A healthy regulatory change workflow should show:
source
impacted obligation
impacted entity or business unit
impacted policy
impacted control
owner
due date
evidence required
issue or action plan
implementation status
dashboard status
Legal interpretation is necessary.
But implementation requires owners, controls, evidence, and follow-up.
Healthy answer: Regulatory changes are mapped to obligations, policies, controls, owners, evidence, and issues.
Warning sign: Regulatory changes are tracked in legal notes but not linked to operational workflow.
14. Are policy exceptions and risk acceptances governed?
A healthy program does not approve exceptions and accepted risks informally.
Policy exceptions should include:
requirement excepted
business justification
risk assessment
approver
conditions
compensating controls
expiration
evidence
issue link
Risk acceptance should include:
risk accepted
residual risk
approver
rationale
evidence
conditions
expiration or review date
monitoring requirement
Accepted risk should appear in dashboards when material.
Healthy answer: Exceptions and accepted risks are time-bound, evidenced, approved, monitored, and dashboarded.
Warning sign: Exceptions and risk acceptances are approved by email and not reviewed again.
15. Are dashboards built from trusted source records?
A dashboard is only as trustworthy as its source data.
A healthy dashboard should have:
defined owner
defined audience
approved source records
refresh cadence
drill-down
threshold logic
data-quality notes
decisions-needed view
If dashboards are manually assembled from spreadsheets, emails, and status meetings, the program should be transparent about that limitation.
Healthy answer: Dashboards drill down to connected source records.
Warning sign: Dashboard colors are debated because teams do not trust the underlying records.
16. Are dashboard metrics tied to decisions?
GRC dashboards should not only report status.
They should support decisions.
A dashboard should show:
risk acceptance requested
remediation extension requested
vendor renewal with open risk
funding needed
policy exception approval
control failure escalation
board reporting item
regulatory response approval
AI use-case decision
operational resilience investment decision
A dashboard without decisions may still be useful.
But a dashboard with decisions becomes a management tool.
Healthy answer: Dashboards show decisions needed, owners, due dates, and evidence.
Warning sign: Dashboards show red, yellow, and green metrics but no clear action.
17. Are roles and responsibilities clear across the Three Lines?
A healthy GRC program preserves role clarity.
Management owns risks, controls, evidence, vendors, and remediation.
Risk and compliance teams define standards, monitor, test, challenge, and coordinate.
Internal audit provides independent assurance.
The IIA’s Three Lines Model reinforces the need for coordination without unnecessary duplication, overlap, or gaps.
Healthy answer: The RACI defines owners, reviewers, approvers, validators, and escalation paths.
Warning sign: Compliance or internal audit becomes the owner of management’s risks, controls, or remediation.
18. Is the GRC operating committee making decisions, not just reviewing status?
A healthy operating committee should resolve cross-functional issues.
It should make or route decisions such as:
risk acceptance
remediation prioritization
vendor approval with open issues
control redesign
policy exception
dashboard threshold change
issue escalation
funding request
board escalation
If the committee only reviews updates, it is not creating enough value.
Healthy answer: The committee maintains a decision log, action log, and escalation path.
Warning sign: The same red items appear every month with no decision or escalation.
19. Can the program explain what changed this quarter?
A quarterly health check should show movement.
Ask:
Which risks increased?
Which risks decreased?
Which controls failed?
Which evidence improved?
Which issues were validated?
Which vendors became more critical?
Which incidents changed risk posture?
Which dashboards became more reliable?
Which old processes were retired?
Which decisions were made?
A healthy program can explain change.
An unhealthy program reports static status.
Healthy answer: The quarterly review highlights movement, causes, actions, and decisions.
Warning sign: Reports look similar each quarter and do not explain what changed.
20. Are top risks connected to KRIs, controls, issues, and incidents?
Enterprise risk should not be isolated from operating data.
A healthy risk record should connect to:
KRIs
controls
evidence
issues
incidents
vendors
mitigation plans
risk acceptance
dashboards
SmartSuite’s Enterprise Risk Management page describes linking risks to controls, issues, remediation actions, KRIs, mitigation plans, and dashboards in a connected workspace.
Healthy answer: Top risks are supported by operating data and reviewed regularly.
Warning sign: Risk ratings are updated through workshops but not tied to controls, issues, or incidents.
21. Are critical services, assets, and vendors connected?
Connected GRC should show operational dependencies.
For critical services, the program should know:
service owner
business process
supporting assets
supporting vendors
data involved
recovery requirements
continuity plans
incident history
open issues
resilience test results
If cyber, vendor, and resilience records are disconnected, management may miss material exposure.
Healthy answer: Critical services are linked to assets, vendors, risks, incidents, and resilience evidence.
Warning sign: Vendor and cyber risks are reported without business service impact.
22. Are AI, privacy, and data risks connected to the broader GRC model?
AI and privacy governance should not live outside Connected GRC.
A healthy program connects:
AI use cases
AI vendors
data used
privacy reviews
cyber reviews
legal reviews
risk tiering
controls
evidence
monitoring
issues
approvals
dashboards
Privacy records should also connect data, processing activities, vendors, incidents, controls, and issues.
Healthy answer: AI and privacy risks are linked to owners, controls, evidence, issues, vendors, and executive reporting.
Warning sign: AI and privacy reviews happen in separate tools or documents with no connection to issue remediation or dashboards.
23. Are old spreadsheets and shadow workflows being retired?
Connected GRC maturity depends on retiring old systems of record.
If old spreadsheets remain active, the program may create duplicate truth.
A quarterly health check should ask:
Which spreadsheets are still active?
Which workflow do they support?
Why have they not been retired?
What source record replaced them?
Who still uses them?
What cutoff date exists?
What risk do they create?
Healthy answer: Legacy trackers are frozen, archived, or retired as connected workflows go live.
Warning sign: The platform exists, but the real work still happens in spreadsheets and email.
24. Is GRC data quality measured and improved?
Data quality is not administrative cleanup.
It is program health.
A healthy program tracks:
records missing owners
stale risk records
controls without evidence requirements
issues closed without validation
vendors without risk tier
incidents without root cause
evidence without period or reviewer
dashboards without drill-down
duplicate records
missing relationships
Data quality should be part of the monthly or quarterly review.
Healthy answer: Data-quality defects are dashboarded, assigned, and remediated.
Warning sign: Leaders distrust reports because source records are stale, incomplete, or inconsistent.
25. Can the program produce one connected risk story for executives and the board?
This is the final test.
A healthy Connected GRC program can produce one coherent risk story.
It can explain:
what changed
what matters
what is outside appetite
what evidence supports the conclusion
what controls are failing
what issues are overdue
what remediation has been validated
what vendors or incidents changed risk
what risks have been accepted
what decisions are needed
what the board should know
If risk, cyber, compliance, audit, vendor, privacy, AI, and resilience teams each produce disconnected reports, the program is not fully connected.
Healthy answer: Executive and board reporting uses connected source records and presents one aligned risk story.
Warning sign: The board receives multiple GRC narratives that do not reconcile.
Summary Checklist Table
Use this summary version in quarterly reviews.
| # | Health Question | Green / Yellow / Red | Owner | Action |
|---|---|---|---|---|
| 1 | Do material risks have clear owners? | |||
| 2 | Can executives see risks outside appetite? | |||
| 3 | Are controls mapped to risks and obligations? | |||
| 4 | Are key controls supported by accepted evidence? | |||
| 5 | Are evidence requirements clear to control owners? | |||
| 6 | Is evidence reused responsibly across frameworks? | |||
| 7 | Are issues linked to risks, controls, evidence, and root cause? | |||
| 8 | Are high-severity issues overdue? | |||
| 9 | Are issues closed only after remediation is validated? | |||
| 10 | Are repeat issues and findings visible? | |||
| 11 | Are vendors connected to contracts, criticality, evidence, and issues? | |||
| 12 | Are incidents linked to root cause, controls, issues, and remediation? | |||
| 13 | Are regulatory changes converted into operational action? | |||
| 14 | Are policy exceptions and risk acceptances governed? | |||
| 15 | Are dashboards built from trusted source records? | |||
| 16 | Are dashboard metrics tied to decisions? | |||
| 17 | Are roles and responsibilities clear across the Three Lines? | |||
| 18 | Is the operating committee making decisions, not just reviewing status? | |||
| 19 | Can the program explain what changed this quarter? | |||
| 20 | Are top risks connected to KRIs, controls, issues, and incidents? | |||
| 21 | Are critical services, assets, and vendors connected? | |||
| 22 | Are AI, privacy, and data risks connected to the broader GRC model? | |||
| 23 | Are old spreadsheets and shadow workflows being retired? | |||
| 24 | Is GRC data quality measured and improved? | |||
| 25 | Can the program produce one connected risk story for executives and the board? |
How to interpret the results
Mostly green
The program is operating with strong connected discipline.
Next step:
optimize dashboards
automate repeat workflows
improve evidence reuse
mature board reporting
refine predictive KRIs
expand into adjacent workflows
Many yellow items
The program has structure but inconsistent execution.
Next step:
prioritize 3 to 5 improvement actions
clean ownership
fix evidence standards
improve issue validation
strengthen dashboard source records
use the operating committee to remove blockers
Several red items
The program may be activity-heavy but not decision-ready.
Next step:
focus on foundational records
define owners
clean statuses
connect risks, controls, evidence, and issues
launch one workflow properly
retire duplicate trackers
rebuild executive reporting around source records
Do not try to fix everything at once.
Pick the highest-value improvement and make it visible.
What to do after the health check
A health check should produce action.
After completing the checklist:
Identify the top five red or yellow areas.
Assign accountable owners.
Create improvement issues or roadmap items.
Define what evidence will prove improvement.
Add the items to the monthly Connected GRC review.
Update dashboards.
Escalate decisions to executives or the operating committee.
Review progress next quarter.
The checklist is only useful if it changes the operating model.
Common mistakes to avoid
Mistake 1: Treating the checklist as a survey
Do not collect answers and stop.
Turn weak answers into actions.
Mistake 2: Scoring everything green because a process exists
A process is not healthy unless it is owned, evidenced, connected, and used.
Mistake 3: Ignoring data quality
Dashboards and reports are only as reliable as the source records.
Mistake 4: Measuring activity instead of health
Controls tested, vendors reviewed, and issues closed are useful metrics, but they do not prove health by themselves.
Mistake 5: Letting the GRC team own every gap
Business owners, control owners, risk owners, vendor owners, and executives must own their parts.
Mistake 6: Not involving internal audit appropriately
Internal audit can provide valuable assurance and insight, but management should own remediation and operational control responsibilities.
Mistake 7: Reviewing the checklist once a year
Program health should be reviewed quarterly, with key exceptions reviewed monthly.
Quarterly GRC Health Review Agenda
Use this agenda with the checklist.
| Time | Topic | Purpose |
|---|---|---|
| 0–10 min | Decisions needed | Address urgent governance decisions first |
| 10–20 min | Risks outside appetite | Review risk movement and appetite exceptions |
| 20–30 min | Controls and evidence | Review failed controls, evidence gaps, and evidence quality |
| 30–40 min | Issues and remediation | Review overdue, repeat, and unvalidated issues |
| 40–50 min | Vendors, incidents, and resilience | Review dependency and operational risk |
| 50–60 min | Data quality and dashboard trust | Review source-record defects |
| 60–70 min | Operating model gaps | Review roles, workflows, and legacy trackers |
| 70–80 min | Actions and owners | Assign actions and decisions |
| 80–90 min | Executive / board items | Confirm escalation and reporting items |
This turns the checklist into a working meeting.
A practical test for your GRC program
Pick one executive GRC dashboard.
Ask whether it can show:
risks outside appetite
key controls without accepted evidence
high-severity issues overdue
issues pending validation
critical vendors with open risk
incidents linked to root cause
accepted risks nearing expiration
policy exceptions
data-quality gaps
decisions needed
source-record drill-down
If it cannot, the program may be reporting GRC activity without enough Connected GRC health.
That is common.
It is also the opportunity.
Final thought
A GRC program is healthy when leaders can trust it.
Trust does not come from a polished dashboard.
It comes from clear ownership, reliable data, connected records, accepted evidence, validated remediation, visible risk appetite, governed exceptions, monitored vendors, linked incidents, and decision-ready reporting.
This checklist helps test whether those foundations are in place.
The goal is not to answer every question perfectly.
The goal is to find the weak points before they become audit surprises, regulatory fire drills, board concerns, vendor failures, cyber incidents, or repeated control breakdowns.
Connected GRC program health is not about having more GRC activity.
It is about having better GRC confidence.
What is owned.
What is proven.
What is broken.
What is fixed.
What is accepted.
What is overdue.
What changed.
What decision is needed.
That is what this checklist should reveal.