The Connected GRC Program Charter: Roles, Responsibilities, and Decision Rights

A Connected GRC program does not run on good intentions.

It needs a charter.

Not a decorative document.
Not a generic governance statement.
Not a policy that says “risk and compliance are important.”Not a meeting agenda with a new name.

A real Connected GRC program charter defines how the program works.

It explains what is in scope.
Who owns what.
Who decides what.
Who provides evidence.
Who validates remediation.
Who escalates issues.
Who approves risk acceptance.
Who owns dashboards.
Who resolves conflicts.
Who prepares executive reporting.
Who keeps the operating model connected.

Without a charter, Connected GRC can quickly become another set of disconnected workflows.

Risk has one process.
Compliance has another.
Audit has another.
Cyber has another.
Privacy has another.
Third-party risk has another.
Resilience has another.
AI governance has another.
Each team does important work, but no one owns the connections.

That is the problem a Connected GRC program charter solves.

The charter gives the program a shared operating model.

It turns “we should connect risk and compliance” into practical decisions:

• Which records must be connected?
• Which workflows are governed centrally?
• Which decisions stay with domain owners?
• Which issues require escalation?
• Which evidence standards apply across teams?
• Which dashboards are official?
• Which roles are accountable, consulted, or informed?
• Which governance body resolves disputes?
• Which metrics show program health?

A strong charter does not make GRC slower.

It makes GRC clearer.

What is a Connected GRC program charter?

A Connected GRC program charter is a formal operating document that defines the purpose, scope, governance structure, roles, responsibilities, decision rights, workflows, ownership model, escalation paths, reporting cadence, data expectations, and success measures for a Connected GRC program.

A good charter should answer:

• Why does the Connected GRC program exist?
• What business problems is it solving?
• Which GRC domains are in scope?
• Which workflows are included first?
• Who owns the program?
• Who owns risks, controls, evidence, issues, vendors, policies, incidents, audits, and dashboards?
• What decisions can the program team make?
• What decisions require the operating committee?
• What decisions require executive or board escalation?
• How are conflicts resolved?
• How is risk acceptance governed?
• How is remediation validated?
• How are dashboards approved?
• How is data quality maintained?
• How will program health be measured?

A weak charter describes intent.

A strong charter defines accountability.

That is the difference.

Why a Connected GRC charter matters

Connected GRC touches many teams.

That creates natural friction.

Compliance may want evidence earlier.
Control owners may want fewer requests.
Audit may want stronger remediation validation.
Cyber may want vulnerabilities prioritized by technical severity.
Risk may want priorities based on appetite and business impact.
Procurement may want faster vendor onboarding.
Third-party risk may want deeper due diligence.
Legal may want regulatory language reviewed carefully.
Privacy may want data use assessed before launch.
AI governance may want use cases reviewed before deployment.
Business owners may want decisions made quickly.

Everyone is partly right.

The charter gives the organization a way to make those tradeoffs deliberately.

OCEG’s definition of GRC as integrated capabilities is useful here because integration does not happen by accident. It requires people, processes, information, and decision rights that work together to help the organization achieve objectives, address uncertainty, and act with integrity.  

A Connected GRC charter makes that integration operational.

What happens without a charter

Without a charter, the program usually develops gaps.

Common symptoms include:

• unclear ownership for risks, controls, evidence, or issues
• duplicate control libraries
• duplicate evidence requests
• inconsistent issue severity
• no standard remediation validation process
• unclear risk acceptance authority
• vendor approvals happening before required reviews
• audit findings closed without consistent evidence
• regulatory changes not routed to the right owners
• cyber incidents not connected to enterprise risk
• privacy and AI reviews happening outside the main workflow
• dashboards showing different versions of the truth
• operating committee meetings becoming status updates
• escalation paths unclear
• teams debating decisions repeatedly

The organization may still have a GRC program.

But it does not have a governed operating model.

The charter creates that model.

What the charter should include

A practical Connected GRC program charter should include these sections:

The charter does not need to be long.

It needs to be specific enough to guide decisions.

1. Purpose

The purpose statement should be short and practical.

It should explain what the Connected GRC program is meant to accomplish.

A strong purpose statement might look like this:

The Connected GRC program exists to link risks, obligations, policies, controls, evidence, testing, issues, vendors, incidents, audits, assets, resilience, privacy, AI governance, ESG, and dashboards into shared workflows that improve risk visibility, compliance readiness, remediation accountability, assurance quality, and executive decision-making.

That purpose statement does three things.

It defines the scope.
It explains the operating model.
It connects the program to business value.

COSO’s ERM framework emphasizes integrating risk with strategy and performance, which is a useful reminder that a GRC charter should not only describe compliance work. It should explain how the program supports better management decisions.  

2. Scope

Scope is where many charters become vague.

A Connected GRC charter should define what is in scope now and what will come later.

Domains in scope

Common domains may include:

• Enterprise Risk Management
• Compliance Management
• Internal Audit Management
• SOX Management
• Cyber & IT Risk
• Third-Party Risk Management
• Privacy Management
• Operational Resilience & Business Continuity
• AI Governance
• ESG & Sustainability Management
• Entity & Corporate Governance
• Regulatory Change
• Regulatory Inquiries
• Policy Management
• Issues Management
• Evidence Management

Workflows in scope

The charter should also define workflows.

Examples:

• risk assessment
• control mapping
• evidence request and review
• compliance testing
• issue remediation
• remediation validation
• vendor intake
• vendor due diligence
• contract review
• vendor renewal risk review
• incident-to-issue workflow
• audit finding remediation
• regulatory change impact assessment
• regulatory inquiry response
• AI use-case intake
• privacy assessment
• resilience scenario testing
• dashboard reporting

Records in scope

The charter should define the official source records.

Examples:

• risk
• obligation
• policy
• control
• evidence
• test
• issue
• remediation plan
• vendor
• contract
• asset
• business service
• incident
• audit finding
• regulatory inquiry
• AI use case
• dashboard
• decision

The scope should be clear enough that teams know where Connected GRC begins and where existing domain processes remain.

3. Operating principles

Operating principles help teams make decisions when the charter does not cover every scenario.

Useful principles include:

One source record where possible

Create one authoritative record for a risk, control, issue, vendor, policy, or evidence item where the objective is shared.

Connect before duplicating

Before creating a new control, issue, evidence request, or dashboard, check whether an existing control can be connected.

Evidence must have context

Evidence should connect to the control, obligation, period, owner, reviewer, test, issue, or inquiry it supports.

Issues must connect to source and remediation

An issue should show where it came from, what it affects, who owns it, what fix is required, and how closure will be validated.

Dashboards should support decisions

Dashboards should show status, exceptions, trends, owners, and decisions needed.

Risk ownership stays with the business

Connected GRC can provide structure and visibility, but business owners still own risks, controls, processes, vendors, and remediation.

Internal audit remains independent

Internal audit can provide insight and assurance, but it should not own management’s remediation work or make management decisions.

The IIA’s Three Lines Model is directly relevant here because it distinguishes management responsibilities from internal audit’s independent assurance role and emphasizes coordination without unnecessary duplication, overlap, or gaps.  

4. Governance structure

The charter should define the governance structure.

A practical Connected GRC governance model may include:

The charter should explain how these groups interact.

For example:

• The Connected GRC Operating Committee escalates material risk, funding, and policy decisions to the executive committee.
• Internal audit reports independently through its established governance channel.
• Domain working groups recommend workflow changes to the operating committee.
• Program management maintains the roadmap, data model, dashboards, and adoption plan.
• Record owners maintain the accuracy and status of their assigned records.

This prevents governance confusion.

5. Roles and responsibilities

The charter should define responsibilities by role.

Executive sponsor

Responsible for:

• approving the program mandate
• resolving cross-functional conflicts
• securing resources
• removing blockers
• escalating to executive governance
• reinforcing adoption

Connected GRC program owner

Responsible for:

• managing the program roadmap
• coordinating workflows
• maintaining the operating model
• aligning stakeholders
• monitoring program health
• preparing operating committee materials

Risk owner

Responsible for:

• owning risk assessment
• maintaining risk status
• reviewing KRIs
• approving mitigation plans
• determining residual risk
• escalating appetite exceptions

Control owner

Responsible for:

• operating the control
• providing evidence
• addressing evidence rejection
• remediating control gaps
• confirming control changes
• supporting testing

Evidence owner

Responsible for:

• submitting evidence on time
• ensuring evidence covers the right period and scope
• responding to reviewer questions
• correcting rejected evidence
• maintaining recurring evidence records

Issue owner

Responsible for:

• owning remediation
• defining corrective action
• providing remediation evidence
• meeting due dates
• supporting validation
• escalating blockers

Vendor owner

Responsible for:

• owning the vendor relationship
• supporting risk review
• maintaining vendor context
• responding to issues
• supporting renewal decisions
• coordinating offboarding

Policy owner

Responsible for:

• maintaining policy content
• linking policy to obligations and controls
• managing reviews and approvals
• supporting attestations
• tracking exceptions

Internal audit

Responsible for:

• providing independent assurance
• identifying findings and themes
• validating remediation where appropriate
• communicating audit results
• preserving independence from management decisions

The IIA’s Three Lines Model states that internal audit’s independence from management helps ensure objective assurance and advice; it also notes that internal audit should not take management decisions or actions for activities where it must provide independent assurance.  

6. Decision rights

Decision rights are the heart of the charter.

They define who can approve, reject, escalate, accept, close, or change something.

A Connected GRC program should define decision rights for at least these areas:

The charter should not leave these decisions informal.

Informal decision rights create rework, confusion, and risk.

7. Risk acceptance

Risk acceptance deserves its own section.

Risk acceptance should never be casual.

The charter should define:

• who can accept risk
• which risks can be accepted at each authority level
• when acceptance requires executive escalation
• how long acceptance remains valid
• what evidence is required
• what compensating controls exist
• what review cadence applies
• how accepted risk appears in dashboards
• when acceptance must be revisited

Risk acceptance should include:

• risk description
• reason for acceptance
• affected control, issue, vendor, asset, or service
• business impact
• residual risk
• approver
• expiration or review date
• conditions
• evidence
• escalation status

A risk acceptance without owner, rationale, and review date is not governance.

It is avoidance.

8. Issue escalation

The charter should define when issues escalate.

Escalation criteria may include:

• high-severity issue overdue
• issue affecting a top enterprise risk
• issue affecting a critical service
• issue tied to SOX, SOC 2, or regulatory readiness
• repeated issue with same root cause
• remediation validation failed
• evidence missing for a key control
• vendor issue blocking renewal
• privacy or AI issue blocking launch
• vulnerability exceeding tolerance
• operational resilience issue threatening impact tolerance
• regulatory inquiry response at risk

The charter should define:

• who escalates
• where the issue escalates
• what information is required
• who decides next action
• what happens if escalation is ignored
• how escalation is documented

Escalation should not depend on who is loudest.

It should depend on criteria.

9. Remediation validation

The charter should define the difference between remediation completion and validation.

Completion means the owner says the corrective action was performed.

Validation means someone confirms the corrective action addressed the issue and root cause.

The charter should define:

• which issues require validation
• who validates
• what evidence is required
• when retesting is required
• when internal audit must validate
• when compliance or risk can validate
• when business owner certification is enough
• how failed validation is handled
• how residual risk is updated

This prevents premature closure.

It also improves program health.

A high issue closure rate is not meaningful if closure is not validated.

10. Evidence standards

The charter should define evidence expectations.

Evidence should include:

• control or obligation supported
• period covered
• scope or population
• owner
• provider
• reviewer
• source system
• submission date
• acceptance status
• rejection reason, if applicable
• issue link, if material
• reuse eligibility
• expiration date, if relevant

The charter should also define:

• what good evidence looks like
• when screenshots are acceptable
• when population evidence is required
• how evidence rejection works
• when rejected evidence creates an issue
• when evidence can be reused
• who approves evidence reuse
• how sensitive evidence is protected

SmartSuite’s Compliance Management page describes automated evidence collection, standardized templates, recurring controls testing, issue and remediation tracking, and data and evidence traceability across controls, policies, risks, issues, and activities.  

Those are exactly the operating expectations a charter should formalize.

11. Control and framework standards

The charter should define how controls are created and managed.

Control standards should include:

• control naming convention
• control owner requirement
• control objective
• control frequency
• related risk
• related obligation
• related policy
• related framework
• evidence requirement
• test procedure
• issue trigger
• review cadence
• retirement process

The charter should also define how controls map to multiple frameworks.

For example:

• SOC 2
• SOX
• ISO 27001
• NIST
• CRI
• privacy regulations
• internal policies
• customer commitments

The goal is to prevent control-library sprawl.

Before creating a new control, teams should ask:

• Does an existing control already satisfy the objective?
• Does the existing control need another mapping?
• Is new evidence required?
• Is the requirement truly different?
• Does the control need to be split?
• Does the control need a new owner?

This supports a test-once, comply-many model without pretending every framework is identical.

12. Data ownership and quality

A Connected GRC charter should define data ownership.

Bad GRC data creates bad decisions.

The charter should define owners for:

• risk data
• control data
• evidence data
• issue data
• vendor data
• contract data
• incident data
• policy data
• asset data
• business service data
• audit finding data
• regulatory inquiry data
• dashboard data

It should also define data quality rules:

• required fields
• review frequency
• ownership updates
• duplicate record handling
• status definitions
• stale record thresholds
• relationship requirements
• dashboard source rules

For example:

• Every issue must have an owner, severity, source, due date, root cause, remediation plan, and validation method.
• Every control must have an owner, evidence requirement, related risk or obligation, and testing frequency.
• Every critical vendor must have a business owner, risk tier, contract, review status, evidence status, and renewal date.
• Every executive dashboard must pull from approved source records.

Data quality should not be an IT-only concern.

It is a GRC governance concern.

13. Dashboard and reporting governance

The charter should define which dashboards are official.

Common dashboards include:

• executive risk dashboard
• program health dashboard
• evidence readiness dashboard
• issue remediation dashboard
• control health dashboard
• audit finding dashboard
• third-party risk dashboard
• cyber risk dashboard
• privacy risk dashboard
• operational resilience dashboard
• AI governance dashboard
• regulatory inquiry dashboard

For each dashboard, define:

• audience
• purpose
• owner
• source records
• refresh cadence
• metrics
• thresholds
• decision-needed section
• escalation rules
• access permissions

A dashboard should not become official because someone built it.

It should become official because it is sourced, governed, and useful.

SmartSuite’s ERM page describes connecting risks to controls, findings, evidence, and remediation with shared dashboards and cross-functional visibility.  

That is the dashboard governance model a charter should reinforce.

14. Operating committee relationship

The charter should define the relationship between the program and the Connected GRC Operating Committee.

The operating committee should typically approve or review:

• program roadmap
• program health scorecard
• cross-functional priorities
• risk appetite exceptions
• issue escalation
• evidence standards
• control standards
• dashboard definitions
• data model changes
• unresolved ownership conflicts
• regulatory or audit readiness risks
• material vendor or resilience escalations
• executive reporting items

The charter should define what the program team can decide without committee approval and what requires committee escalation.

This prevents the operating committee from becoming either too passive or too involved.

15. Domain working groups

The charter should define domain working groups.

Examples:

• Controls and evidence working group
• Issues and remediation working group
• Third-party risk working group
• Regulatory change working group
• Operational resilience working group
• AI governance working group
• Cyber risk working group
• Privacy risk working group
• Dashboard and data quality working group

Working groups should solve specific problems.

They should not become permanent status meetings unless needed.

Each working group should have:

• scope
• owner
• members
• deliverables
• decision limits
• timeline
• escalation path

The operating committee decides.

Working groups build, analyze, and recommend.

16. Three Lines alignment

The charter should explain how the program aligns with the Three Lines Model.

A practical Connected GRC interpretation:

The IIA’s Three Lines Model states that the governing body typically sets direction, delegates responsibility to management, and receives reports on outcomes, risks, and risk management; it also emphasizes regular coordination, collaboration, and communication across roles.  

This is exactly why a Connected GRC charter needs clear roles.

Collaboration is useful only when accountability remains clear.

17. Cyber governance alignment

The charter should define how cyber risk connects to enterprise GRC.

Cyber risk should not sit in a separate technical reporting channel if it affects enterprise objectives, customer trust, resilience, vendors, privacy, SOX, SOC 2, AI governance, or board oversight.

NIST CSF 2.0’s Govern function says cybersecurity risk-management strategy, expectations, and policy should be established, communicated, and monitored; it also identifies roles, responsibilities, authorities, policy, and oversight as part of cybersecurity governance.  

A Connected GRC charter should define:

• how cyber risks map to enterprise risks
• how vulnerabilities connect to assets and services
• how cyber incidents create issues
• how cyber controls map to compliance frameworks
• how cyber evidence supports audits and customer assurance
• how cyber risk appears in executive dashboards
• when cyber risk requires escalation

This makes cyber part of the broader risk operating model.

18. Change management and adoption

A charter should define how the program manages change.

Connected GRC changes how people work.

Control owners may receive new evidence standards.
Vendor owners may use new intake workflows.
Risk owners may need to update risks more frequently.
Compliance teams may need to map obligations differently.
Audit teams may need to link findings to issues.
Executives may receive new dashboards.

The charter should define:

• training approach
• communication cadence
• role-based onboarding
• adoption metrics
• support model
• feedback process
• change approval process
• phased rollout approach

The charter should also make clear that Connected GRC is not only a platform implementation.

It is a working model.

19. Program health metrics

The charter should define how program health is measured.

Program health metrics may include:

• risks with owners
• controls with owners
• controls with accepted evidence
• evidence acceptance rate
• evidence rejection rate
• duplicate evidence requests reduced
• high-severity issues overdue
• issues closed with validation
• repeat findings
• vendors with current evidence
• critical vendors with open high-risk issues
• incidents linked to root cause
• critical services with dependency maps
• dashboards with decisions needed
• operating committee actions closed on time

These metrics should tie directly to the program health scorecard.

A charter without success measures is incomplete.

20. Charter review and maintenance

A charter should not be static.

Review it at least annually, and sooner when major changes occur.

Triggers for review include:

• new regulatory requirements
• new business unit or acquisition
• new GRC domain added
• major audit finding
• major incident
• AI governance expansion
• operational resilience requirement
• material dashboard change
• repeated ownership conflict
• platform or data model change
• board or executive governance change

The charter should include:

• owner
• review cadence
• approval authority
• change log
• version history
• communication plan

A stale charter becomes another document.

A maintained charter becomes the operating model.

Sample Connected GRC Program Charter Outline

Use this structure as a starting point.

1. Purpose

Define why the Connected GRC program exists and what business outcomes it supports.

2. Scope

Define in-scope domains, workflows, records, geographies, entities, business units, and initial phases.

3. Operating principles

Define the rules that guide connected work, ownership, evidence, issue management, dashboards, and risk decisions.

4. Governance structure

Define board, executive, operating committee, working group, and program management relationships.

5. Roles and responsibilities

Define responsibilities for executive sponsor, program owner, risk owners, control owners, evidence owners, issue owners, vendor owners, policy owners, internal audit, and other stakeholders.

6. Decision rights

Define who can approve, reject, escalate, accept, defer, close, or change key records and workflows.

7. Core records and data model

Define official records such as risks, obligations, controls, evidence, issues, vendors, contracts, incidents, audit findings, regulatory inquiries, business services, and dashboards.

8. Workflow standards

Define evidence, testing, issue remediation, vendor review, regulatory change, incident, audit finding, privacy, AI, and resilience workflows.

9. Escalation model

Define escalation criteria, authority, routing, and documentation.

10. Reporting and dashboards

Define official dashboards, source data, cadence, thresholds, and decision-needed views.

11. Program health metrics

Define KPIs and scorecard dimensions.

12. Review and maintenance

Define review cadence, approval, versioning, and change process.

This outline is enough to build a practical charter without turning it into a policy manual.

Common charter mistakes to avoid

Mistake 1: Writing a charter that only describes intent

The charter should define roles, decision rights, records, workflows, escalation, and reporting.

Mistake 2: Leaving decision rights vague

If decision rights are unclear, every difficult issue becomes a meeting debate.

Mistake 3: Confusing governance with ownership

The committee may govern the operating model, but business owners still own risks, controls, vendors, and remediation.

Mistake 4: Letting internal audit own management work

Internal audit can provide assurance and insight, but it should not own management’s risk, control, or remediation responsibilities.

Mistake 5: Ignoring data ownership

Connected GRC depends on clean ownership, status, and relationships.

Data quality needs defined owners.

Mistake 6: Creating too many committees

The charter should simplify governance, not create committee sprawl.

Mistake 7: Treating the charter as a one-time document

Review and update the charter as the program matures.

A practical test for your GRC charter

Ask whether your current charter clearly defines:

• why the program exists
• what domains are in scope
• which workflows are in scope
• who owns the program
• who owns risks
• who owns controls
• who owns evidence
• who owns issues
• who owns vendors
• who owns dashboards
• who approves risk acceptance
• who validates remediation
• who approves evidence standards
• who resolves ownership disputes
• who escalates high-severity issues
• who prepares executive reporting
• how internal audit participates
• what the operating committee decides
• what metrics define program health
• how the charter is reviewed

If the charter cannot answer those questions, the program may still rely too much on informal coordination.

That is common.

It is also the opportunity.

Final thought

A Connected GRC program charter is not paperwork.

It is the operating agreement for how risk, compliance, audit, cyber, privacy, third-party risk, resilience, AI governance, ESG, finance, legal, and business teams work together.

It defines scope.

It defines roles.

It defines decision rights.

It defines ownership.

It defines escalation.

It defines evidence standards.

It defines issue remediation expectations.

It defines dashboards.

It defines program health.

Without that clarity, Connected GRC can become another set of disconnected efforts.

With that clarity, the organization has a shared operating model.

The charter helps teams know who owns the work, who approves decisions, who validates closure, who escalates risk, and how the program proves it is working.

That is the value of a Connected GRC program charter.

It turns Connected GRC from a concept into a governed operating model.