How to Build a Connected GRC Operating Committee

Why do many committees produce one disconnected picture?

Many organizations already have risk committees, compliance committees, audit committees, cyber governance meetings, privacy councils, third-party risk forums, AI governance boards, operational resilience working groups, SOX steering committees, and policy review meetings.

The problem is that these groups often operate separately.

One committee discusses cyber risk.
Another discusses enterprise risk.
Another reviews compliance issues.
Another tracks audit findings.
Another reviews vendor risk.
Another manages privacy assessments.
Another oversees AI use cases.
Another handles operational resilience and business continuity.
Another prepares board reporting.

Each meeting may be useful.

But if the records, dashboards, issues, risks, and decisions are disconnected, leaders still struggle to answer:

• What changed?
• What matters most?
• Which risks are outside appetite?
• Which controls are failing?
• Which issues are overdue?
• Which vendors create exposure?
• Which incidents changed the risk view?
• Which evidence is missing?
• Which regulatory changes require action?
• Which decisions need escalation?
• Who owns the next step?

What is a Connected GRC Operating Committee?

A Connected GRC Operating Committee is a cross-functional governance group responsible for coordinating the operating model, decision rights, priorities, dashboards, issue escalation, remediation follow-through, evidence readiness, risk visibility, and cross-domain execution of a Connected GRC program.

A good GRC operating committee should help answer:

• Which GRC work matters most right now?
• Which risks are outside appetite or tolerance?
• Which controls, evidence, issues, vendors, incidents, or audits need escalation?
• Which decisions are blocked?
• Which cross-functional workflows are not working?
• Which teams are duplicating work?
• Which issues are overdue or not validated?
• Which dashboards are too noisy or missing decision context?
• Which domains need to be connected next?
• Which executive or board items require escalation?
• Which operating model changes are needed?

A weak committee reviews activity.

A strong committee makes decisions and removes friction.

That is the difference.

Why does Connected GRC need an operating committee?

Connected GRC crosses functional boundaries.

Enterprise risk may own the risk register.
Compliance may own obligations and testing.
Audit may own assurance and findings.
Cyber may own threats, incidents, and vulnerabilities.
Privacy may own data protection risk.
Third-party risk may own vendor risk.
Legal may own regulatory interpretation and contracts.
Resilience may own critical services and continuity planning.
Finance may own SOX and financial controls.
AI governance may own model and use-case review.
Business owners may own the actual risks and controls.

No single function can make the program connected by itself.

A Connected GRC operating committee gives these groups a shared place to:

• agree on priorities
• align definitions
• review cross-domain risks
• resolve ownership gaps
• coordinate evidence and testing
• escalate overdue remediation
• standardize dashboards
• approve workflow changes
• manage implementation phases
• prepare executive and board reporting

OCEG’s framing of GRC as an integrated collection of capabilities is useful here because a Connected GRC operating committee is the mechanism that keeps those capabilities working together rather than drifting back into silos.  

What should the committee not be?

Before building the committee, define what it is not.

A Connected GRC operating committee is not:

• a replacement for the board
• a replacement for the audit committee
• a substitute for risk ownership
• a status meeting for every GRC task
• a forum where every domain reports every metric
• a place to bypass first-line accountability
• a place where internal audit becomes management
• a committee that approves every low-risk item
• a meeting with no decision rights
• a dashboard review with no action

The committee should not absorb work that belongs to risk owners, control owners, issue owners, or domain teams.

It should coordinate, prioritize, escalate, and decide where cross-functional alignment is needed.

That is the operating role.

How does the operating committee differ from a board committee?

A Connected GRC operating committee is different from a board committee.

The operating committee should feed the board or executive risk committee.

It should not try to become the board.

How does the operating committee differ from a working group?

A working group is usually task-focused.

A committee is decision-focused.

A Connected GRC program may need both.

For example, a controls-and-evidence working group may design the evidence workflow.

The operating committee approves the standard, resolves ownership conflicts, and decides which framework or business unit comes next.

The Connected GRC Operating Committee charter

Every committee needs a charter.

A practical charter should define:

• purpose
• scope
• decision rights
• membership
• roles
• meeting cadence
• agenda
• quorum or approval rules
• escalation path
• dashboard package
• action tracking
• relationship to executive and board governance
• relationship to internal audit
• review cycle

The charter does not need to be long.

But it should be clear.

A weak charter says:

“The committee will review GRC matters.”

A stronger charter says:

“The committee will coordinate the Connected GRC operating model, prioritize cross-functional risk and compliance work, review risk appetite and tolerance exceptions, escalate material issues, approve shared control and evidence standards, monitor remediation validation, and prepare decision-ready reporting for executive governance.”

That is actionable.

What is the committee’s core mandate?

The committee’s mandate should focus on seven things.

1. Prioritization

Decide which GRC work matters most based on risk, obligations, deadlines, business impact, and decisions needed.

2. Operating model alignment

Keep definitions, ownership, workflows, and data relationships consistent across domains.

3. Issue escalation

Review overdue, high-severity, repeat, or unvalidated issues.

4. Evidence and control coordination

Reduce duplicate evidence requests and align common controls across frameworks.

5. Cross-domain risk visibility

Connect cyber, privacy, vendor, resilience, AI, compliance, audit, and enterprise risk.

6. Dashboard governance

Make sure dashboards support decisions instead of creating noise.

7. Executive and board readiness

Prepare the items that need escalation, approval, funding, risk acceptance, or oversight.

If the committee is not doing at least some of these, it may be a status meeting rather than an operating committee.

Who should be on the committee?

Membership should be cross-functional but not too large.

A typical Connected GRC operating committee may include:

• CRO or risk leader
• CCO or compliance leader
• internal audit leader
• CISO or cyber risk leader
• privacy leader
• general counsel or legal representative
• third-party risk leader
• procurement or vendor management leader
• operational resilience / business continuity leader
• finance / SOX leader
• AI governance leader
• ESG or sustainability leader, where relevant
• business operations leader
• GRC platform / program owner
• data or reporting owner

The committee should include people who can make decisions.

If every representative needs to “take it back to their team,” the committee will be slow.

It is fine to have delegates.

But the delegates need authority.

Internal audit’s role

Internal audit can participate, but its role should be clear.

Internal audit should not own management’s remediation.
Internal audit should not become the committee’s operator.
Internal audit should not approve management controls as if it owns them.

Internal audit can provide:

• assurance perspective
• finding trends
• root-cause themes
• evidence-quality observations
• remediation validation status
• control weakness patterns
• audit plan insight
• advisory input, where appropriate

The IIA’s Three Lines Model clarifies how governing bodies, management, and internal audit work together to support strong governance and risk management, while preserving internal audit’s independent assurance role.  

That distinction matters.

Internal audit can help the committee learn.

Management still owns action.

First-line and second-line responsibilities

The committee should not blur accountability.

Business and operational leaders own risks, controls, processes, vendors, services, and remediation.

Second-line functions such as risk, compliance, privacy, security governance, and third-party risk provide frameworks, oversight, challenge, monitoring, and guidance.

Internal audit provides independent assurance.

A Connected GRC operating committee should make these responsibilities visible.

Examples:

The committee should reinforce accountability.

Not dilute it.

Which decision rights should the committee hold?

A committee without decision rights becomes a discussion forum.

Define what the committee can decide.

Possible decision rights include:

• approve GRC workflow standards
• approve shared control and evidence standards
• approve prioritization rules
• approve dashboard definitions
• approve implementation phase sequencing
• approve issue escalation thresholds
• approve remediation extension criteria
• approve risk acceptance routing
• approve cross-functional ownership resolution
• recommend executive funding decisions
• escalate board-level or executive-level risk items

Also define what the committee cannot decide.

For example:

• It may not accept risk above defined thresholds.
• It may not override legal requirements.
• It may not close audit findings without validation.
• It may not approve high-risk AI use without required reviews.
• It may not approve vendor exceptions beyond authority limits.
• It may not change board-approved risk appetite.

Decision rights should align with the organization’s authority model.

If decision rights are unclear, the committee will either overreach or become ineffective.

The standing agenda

A Connected GRC operating committee should use a consistent agenda.

A practical agenda might include:

1. Decisions needed
2. Risk appetite or tolerance exceptions
3. High-priority issues and overdue remediation
4. Evidence, control, or audit readiness concerns
5. Vendor, cyber, privacy, AI, or resilience escalations
6. Major incidents and lessons learned
7. Regulatory change and inquiry readiness
8. Dashboard review and metric changes
9. Operating model decisions
10. Actions, owners, and next meeting priorities

Notice what comes first: decisions.

Not updates.

A committee that starts with updates often runs out of time before decisions.

Start with decisions.

Then use dashboards to support them.

The dashboard package

The committee should review one connected dashboard package, not ten disconnected reports.

The package should include:

The dashboard should not show everything.

It should show what needs attention.

SmartSuite’s ERM page describes centralized risk registers, assessments, controls, KRIs, mitigation plans, and real-time dashboards, while its Compliance Management page describes connecting controls, evidence, policies, risks, issues, assessments, and remediation. Those are the source-record relationships a committee dashboard should rely on.  

Make “decisions needed” the first dashboard

The most important committee dashboard is the “decisions needed” view.

It should show:

• decision type
• owner
• due date
• recommendation
• risk impact
• evidence
• alternatives
• consequence of delay
• approval authority
• status

Decision examples include:

• approve remediation extension
• approve funding request
• escalate vendor renewal risk
• accept residual risk
• pause AI use case
• approve policy exception
• escalate regulatory response
• approve control standard
• prioritize issue remediation
• decide whether to notify executives or board

A decision-ready committee is more valuable than a status-heavy committee.

The dashboard should help the committee decide what to do next.

What must be escalated to the committee?

The committee should define what must be escalated.

Escalation criteria may include:

• risk outside appetite
• high-severity issue overdue
• repeat audit finding
• failed validation
• key control failure
• SOX deficiency risk
• SOC 2 readiness risk
• rejected evidence for critical control
• critical vendor renewal with unresolved issue
• vendor incident affecting critical service
• privacy incident involving sensitive data
• AI use case involving sensitive data without approval
• vulnerability affecting critical asset beyond SLA
• operational resilience impact tolerance threatened
• regulatory inquiry at risk of delay
• crisis after-action item overdue

Escalation rules prevent surprises.

They also prevent every item from being escalated.

The committee should focus on what exceeds thresholds, blocks decisions, or affects material risk.

How often should the committee meet?

The right cadence depends on maturity and urgency.

A practical structure:

A monthly committee is often enough once the model is stable.

During the first 90 days of implementation, biweekly may be better.

If the committee meets weekly forever, it may be doing operational work that belongs elsewhere.

If it meets quarterly only, it may not be close enough to manage cross-functional execution.

The committee action log

Every meeting should produce an action log.

The action log should include:

• action
• owner
• due date
• related risk
• related issue
• related control
• related vendor
• related evidence
• decision needed
• status
• closure evidence

Do not rely on meeting notes alone.

Actions should connect to source records.

If the committee assigns an action to remediate a vendor issue, the action should connect to the vendor record and issue record.

If the committee approves a control standard, the decision should connect to the control framework.

If the committee escalates a privacy issue, the action should connect to the privacy risk record.

That is Connected GRC.

Committee outputs

A useful committee produces clear outputs.

Examples include:

• approved priorities
• resolved ownership gaps
• escalated high-risk issues
• approved operating standards
• remediation decisions
• risk acceptance recommendations
• dashboard changes
• evidence standards
• control mapping decisions
• vendor escalation decisions
• incident follow-up decisions
• executive or board reporting items
• implementation roadmap updates

If the committee produces only meeting minutes, it is not enough.

It should produce decisions and connected actions.

The first 90 days of a GRC Operating Committee

A practical 90-day launch can look like this.

Days 1–15: Define the committee

• name executive sponsor
• define purpose
• draft charter
• identify members
• define decision rights
• agree cadence
• define relationship to board / executive risk committee

Days 16–30: Build the first dashboard package

• decisions needed
• top risks
• high-severity issues
• overdue remediation
• evidence gaps
• critical vendor escalations
• audit findings
• implementation roadmap

Days 31–45: Run the first committee meeting

• approve charter
• confirm decision rights
• review first dashboard
• identify top five decisions
• assign actions
• agree escalation thresholds

Days 46–60: Connect actions to source records

• link decisions to risks, issues, controls, vendors, or evidence
• clean owner fields
• define action log
• refine dashboard views

Days 61–75: Use the committee to unblock work

• resolve ownership gaps
• approve evidence standards
• escalate overdue high-risk issues
• prioritize next Connected GRC workflow

Days 76–90: Review effectiveness

• what decisions were made?
• what issues were unblocked?
• what dashboards were useful?
• what metrics changed?
• what should be removed from the agenda?
• what should be escalated to executives or board?
• what is phase two?

By Day 90, the committee should be making decisions, not just meeting.

The committee charter template

Use a simple structure.

Purpose

Coordinate the Connected GRC operating model and ensure cross-functional risk, compliance, control, evidence, issue, vendor, incident, resilience, privacy, AI, audit, and reporting workflows are aligned and decision-ready.

Scope

Enterprise risks, compliance obligations, controls, evidence, issues, audit findings, third-party risk, cyber risk, privacy risk, operational resilience, AI governance, regulatory change, and executive reporting.

Responsibilities

• prioritize cross-functional GRC work
• review risk appetite and tolerance exceptions
• monitor high-severity issues
• review evidence and audit readiness gaps
• approve shared control and evidence standards
• resolve ownership gaps
• review regulatory and incident escalations
• prepare executive and board reporting items
• approve Connected GRC roadmap priorities

Decision rights

Define what the committee can approve, recommend, or escalate.

Membership

List required functions and named owners.

Cadence

Monthly, with biweekly meetings during implementation or high-risk periods.

Inputs

Dashboards, issue reports, risk appetite exceptions, control health, evidence readiness, vendor escalations, incident summaries, audit finding trends, regulatory change status.

Outputs

Decisions, action log, escalations, dashboard changes, roadmap updates, executive-ready reporting.

That is enough.

The charter should be usable.

Not decorative.

How do you keep the committee from becoming a status meeting?

Use these rules:

1. Start with decisions needed.
2. Limit dashboard review to exceptions.
3. Do not let every function report everything.
4. Require pre-read materials.
5. Assign owners before the meeting ends.
6. Link actions to source records.
7. Track overdue actions publicly.
8. Remove agenda items that do not drive decisions.
9. Review committee effectiveness quarterly.
10. Escalate items only when criteria are met.

Status can be reviewed asynchronously.

Committee time should be used for judgment, tradeoffs, escalation, and alignment.

How the committee supports prioritization

The committee should be the place where cross-functional prioritization happens.

For example:

• Should the team focus first on SOX evidence gaps or vendor renewal risk?
• Should a cyber vulnerability be escalated because it affects a critical service?
• Should a privacy review block an AI launch?
• Should an overdue audit finding change the enterprise risk rating?
• Should a regulatory inquiry response take priority over a planned control test?
• Should a critical vendor renewal proceed with open issues?
• Should an operational resilience gap require executive funding?

These are not always domain-only decisions.

They require cross-functional judgment.

That is why the operating committee exists.

How the committee supports evidence and controls

The committee should approve common standards for evidence and controls.

Examples:

• standard evidence metadata
• evidence acceptance criteria
• evidence reuse rules
• common control naming
• control owner responsibilities
• framework mapping rules
• testing calendar coordination
• issue triggers for failed evidence
• retesting expectations

This is where the committee reduces duplicate evidence requests and fragmented testing.

A committee that does not govern shared control and evidence standards will struggle to keep GRC connected.

How the committee supports issue remediation

The committee should review issue quality, not just issue count.

Useful views include:

• high-severity issues overdue
• issues pending validation
• repeat issues
• issues by root cause
• issues affecting top risks
• issues affecting critical services
• issues affecting multiple frameworks
• issues requiring risk acceptance
• issues requiring executive funding
• issues with unclear ownership

The committee should ask:

• Is remediation on track?
• Is the fix evidenced?
• Has validation occurred?
• Is this issue repeating?
• Does residual risk remain?
• Does leadership need to decide?

This improves remediation discipline.

It also prevents “closed” from meaning “no longer visible.”

How the committee supports executive reporting

The operating committee should prepare executive-ready reporting.

Executive reporting should include:

• top risks
• appetite exceptions
• major issue escalations
• failed key controls
• material evidence gaps
• repeat findings
• critical vendor exposure
• major incidents
• resilience gaps
• AI governance exceptions
• regulatory inquiries
• decisions needed

The committee should decide what goes up.

Not every metric should be escalated.

The committee should also make sure executive reporting uses consistent source data.

This prevents each domain from sending different versions of risk status to leadership.

Common mistakes to avoid

Mistake 1: Creating a committee with no decision rights

If the committee cannot decide or escalate, it becomes a status meeting.

Mistake 2: Inviting too many people

Large committees become updates, not decisions.

Keep membership focused on accountable leaders.

Mistake 3: Starting with dashboards instead of mandate

Dashboards support decisions.

They do not define the committee’s purpose.

Mistake 4: Letting internal audit own management action

Internal audit can provide assurance and insight, but management owns risk, controls, and remediation.

Mistake 5: Reviewing every metric

The committee should review exceptions, thresholds, decisions, and escalations.

Not every data point.

Mistake 6: Failing to connect actions to source records

Actions should link to risks, controls, evidence, issues, vendors, incidents, or policies.

Otherwise the committee creates another disconnected tracker.

Mistake 7: Not reviewing committee effectiveness

A committee can become stale.

Review whether it is making decisions, reducing friction, and improving connected execution.

A practical test for your GRC Operating Committee

Ask whether your current committee can quickly show:

• its formal purpose
• its decision rights
• its members and authority
• its relationship to executive and board governance
• its standing dashboard package
• its escalation criteria
• its action log
• open decisions
• high-severity issues
• overdue remediation
• evidence gaps
• failed controls
• critical vendor escalations
• major incidents
• risk appetite exceptions
• regulatory inquiry risks
• operational resilience gaps
• AI governance exceptions
• what decisions were made last meeting
• what changed because of those decisions

If the committee cannot answer those questions, it may not be operating as a Connected GRC committee.

That is common.

It is also the opportunity.

Final thought

A Connected GRC operating committee should not be another meeting.

It should be the mechanism that keeps the GRC operating model connected.

It helps risk, compliance, audit, cyber, privacy, third-party risk, resilience, legal, finance, AI governance, ESG, and business leaders work from the same facts.

It connects risks to controls.
Controls to evidence.
Evidence to testing.
Testing to issues.
Issues to remediation.
Vendors to contracts.
Incidents to root cause.
Services to resilience.
Dashboards to decisions.

The committee’s job is to make sure those connections produce action.

Not just visibility.

That means clear mandate, right membership, defined decision rights, strong dashboards, escalation criteria, action tracking, and disciplined follow-through.

That is how to build a Connected GRC operating committee.

Not a committee that talks about GRC.

A committee that makes Connected GRC work.