The Connected GRC Operating Model: How Risk, Controls, Obligations, Issues, and Evidence Fit Together

A Connected GRC program does not start with software.

It starts with a simple question:

How should risk, compliance, audit, cyber, third-party risk, privacy, SOX, ESG, AI governance, and resilience work together when the same business problem touches all of them?

That question matters because most GRC programs do not fail from lack of activity.

They fail from lack of connection.

The risk team may maintain a risk register. Compliance may manage frameworks and evidence. Internal audit may track findings. Cybersecurity may manage vulnerabilities. Legal may monitor regulatory change. Procurement may assess vendors. Finance may test SOX controls. Resilience teams may manage business continuity plans. Privacy may maintain assessment records. AI governance may be building a model inventory.

Each team may be doing its job.

But if the work is disconnected, leaders still struggle to answer basic questions:

• Which controls protect our most important risks?
• Which obligations apply to which policies and controls?
• Which issues are increasing our exposure?
• Which vendors support critical business services?
• Which audit findings relate to known control weaknesses?
• Which evidence can be reused across multiple frameworks?
• Which incidents point to repeat control failures?
• Which remediation plans are actually reducing risk?

A Connected GRC operating model is designed to answer those questions without forcing teams to rebuild the story manually every quarter.

What is a Connected GRC operating model?

A Connected GRC operating model is the structure that defines how governance, risk, compliance, audit, cyber, legal, privacy, third-party risk, SOX, ESG, AI governance, and resilience teams share data, assign ownership, manage workflows, and report on risk.

It defines how the work fits together.

At a practical level, the operating model answers:

• What are the core records of the GRC program?
• How are those records connected?
• Who owns each record?
• Which workflows create, update, test, validate, or retire those records?
• How does the first line participate?
• How do the second and third lines coordinate?
• How does leadership receive current, reliable reporting?
• How does the organization avoid duplicating work across risk domains?

A tool can support the operating model.

But the tool is not the operating model.

The operating model is the logic of how the program works.

The core idea: GRC is a relationship system

Traditional GRC programs often treat records as separate objects.

There is a risk register. A control library. A policy inventory. An obligation register. An audit plan. A vendor inventory. An issues log. An evidence folder. A business continuity plan. A SOX testing schedule. A privacy assessment. An AI model inventory.

Each record may be useful on its own.

But the value of Connected GRC comes from the relationships between them.

A risk becomes more useful when it connects to controls, issues, assessments, vendors, assets, business processes, and mitigation plans.

A control becomes more useful when it connects to obligations, frameworks, evidence, tests, policies, risks, owners, and findings.

An issue becomes more useful when it connects to the failed control, affected risk, remediation owner, audit finding, vendor, incident, evidence, and executive reporting.

An obligation becomes more useful when it connects to policies, controls, evidence, assessments, regulatory change, and accountability.

Evidence becomes more useful when it can be traced back to the requirement, control, test, owner, reviewer, and reporting need it supports.

This is the shift.

A disconnected GRC program stores records.

A Connected GRC program manages relationships.

The five foundational objects of Connected GRC

Every organization will have its own terminology, but most Connected GRC programs depend on five foundational objects:

1. Risks
2. Controls
3. Obligations
4. Issues
5. Evidence

These five records create the center of gravity for the operating model.

Other records matter too: policies, vendors, assets, incidents, audits, business processes, business units, critical services, tests, assessments, contracts, and remediation plans.

But risks, controls, obligations, issues, and evidence are the connective tissue.

If those five are disconnected, the rest of the program will struggle.

1. Risks: what could affect objectives?

Risk is the starting point because GRC exists to help the organization make better decisions under uncertainty.

A risk record should not be just a line item in a register.

It should explain:

• what could happen
• why it matters
• which objective, process, asset, service, or obligation it affects
• who owns it
• how severe it is
• what controls are in place
• what issues remain open
• what mitigation work is underway
• how the risk is changing over time

This is where Enterprise Risk Management becomes foundational.

A modern ERM workflow should connect risks to business units, processes, controls, assessments, indicators, issues, audit findings, incidents, vendors, and resilience plans.

Without those connections, a risk register can become a static reporting artifact.

With those connections, it becomes a management system.

2. Controls: what reduces or monitors risk?

Controls are where many GRC programs become complicated.

A single control may support many needs:

• regulatory compliance
• SOX testing
• SOC 2 readiness
• cyber risk management
• privacy obligations
• AI governance
• vendor oversight
• internal policy requirements
• operational resilience
• internal audit assurance

In a disconnected program, that same control may be recreated across several frameworks and tested several times by different teams.

That creates duplicate work and inconsistent evidence.

In a Connected GRC operating model, controls are reusable assets.

A control should connect to:

• the risks it mitigates
• the obligations it supports
• the policies it enforces
• the frameworks it maps to
• the tests that validate it
• the evidence that proves it
• the owner responsible for it
• the issues or deficiencies related to it
• the audits or assessments that review it

This is the foundation for a “test once, comply many” model.

It is also why Control Framework & Regulatory Libraries should be treated as a strategic part of the operating model, not just a compliance repository.

3. Obligations: what must the organization do?

Obligations come from many places:

• laws
• regulations
• standards
• contracts
• customer commitments
• internal policies
• board directives
• supervisory expectations
• industry frameworks
• ESG disclosure requirements
• AI governance requirements

A Connected GRC program does not stop at listing obligations.

It connects obligations to the work required to meet them.

An obligation should connect to:

• affected business units
• policies
• controls
• assessments
• evidence
• owners
• vendors
• systems
• regulatory changes
• issues
• audit or assurance activities
• reporting requirements

This matters because obligations are rarely self-contained.

A new regulatory requirement may require a policy update, a control change, a vendor review, a privacy assessment, a training update, an evidence request, and an audit plan adjustment.

If obligations are managed separately from controls and workflows, compliance becomes reactive.

If obligations connect to controls, policies, assessments, and owners, compliance becomes operational.

This is where Regulatory Change Management, Policy Management, Compliance Assessments & Testing, and Regulatory Inquiries become part of the same operating model.

4. Issues: what needs to be fixed?

Issues are where GRC becomes real.

A program can have good policies, strong control documentation, and well-designed assessments. But if issues are not remediated, risk does not improve.

Issues may come from:

• failed control tests
• audit findings
• compliance gaps
• risk assessments
• cyber incidents
• vendor reviews
• privacy assessments
• SOX deficiencies
• resilience exercises
• regulatory inquiries
• customer audits
• AI governance reviews
• ESG data quality reviews

In a disconnected program, each team may track issues differently.

Audit has findings. Compliance has gaps. Security has remediation tickets. SOX has deficiencies. Privacy has actions. Third-party risk has vendor follow-ups. Resilience has plan gaps.

That creates an incomplete picture.

A Connected GRC operating model uses a common issue and remediation pattern.

An issue should connect to:

• the source that identified it
• the affected risk
• the affected control
• the affected obligation or policy
• the owner responsible for remediation
• the due date
• the remediation plan
• the evidence required for closure
• the validation step
• the status visible to leadership

This is why Issues Management is one of the most important products to link from this article.

In many organizations, issues are the practical bridge between assessment and improvement.

5. Evidence: how do we prove the work was done?

Evidence is often treated as an administrative burden.

It should be treated as a trust mechanism.

Evidence supports many parts of GRC:

• control testing
• compliance assessments
• internal audits
• SOX reviews
• SOC 2 audits
• regulatory inquiries
• vendor assessments
• privacy reviews
• AI governance reviews
• ESG reporting
• incident closure
• remediation validation

The problem is that evidence is often requested repeatedly.

A business owner may be asked for the same screenshot, policy, report, ticket, approval, log, contract, or certification by several different teams.

That creates fatigue.

It also increases the risk of inconsistent answers.

A Connected GRC operating model should define how evidence is requested, stored, reviewed, approved, reused, and retired.

Evidence should connect to:

• the control or obligation it supports
• the test or assessment that requested it
• the owner who provided it
• the reviewer who approved it
• the period it covers
• the system or source it came from
• the framework or audit it supports
• any issue created from the review

Evidence is not just documentation.

It is how the organization proves that the control environment is operating as intended.

The Connected GRC data model

A practical Connected GRC data model does not need to be overly complex.

But it does need to be deliberate.

At a minimum, the model should show how the core records relate to each other.

The point is not to connect everything to everything.

The point is to connect the records that create better decisions.

How the workflow should operate

A Connected GRC operating model should make everyday work easier, not just reporting cleaner.

Here is what that looks like in practice.

Example 1: A control fails a test

In a disconnected program:

• The tester notes the failure.
• Evidence is stored in a folder.
• An issue is created somewhere else.
• The control owner is notified by email.
• Risk reporting may not change.
• Audit may or may not see the issue.
• Leadership may only learn about it in a periodic report.

In a Connected GRC program:

• The failed test updates the control status.
• An issue is created from the test result.
• The issue links to the control, risk, obligation, owner, evidence, and framework.
• A remediation task is assigned.
• Due dates and escalation rules are applied.
• Closure evidence is requested.
• The control can be retested.
• Reporting updates from the source data.

The difference is not just automation.

The difference is traceability.

Example 2: A new regulation is published

In a disconnected program:

• Legal reviews the regulation.
• Compliance updates a tracker.
• Policies are reviewed separately.
• Controls are manually mapped.
• Evidence requests are created later.
• Business owners receive several follow-ups.
• Audit may update its plan after the fact.

In a Connected GRC program:

• The regulatory change is logged.
• Affected obligations are identified.
• Related policies and controls are mapped.
• Impact assessments are assigned.
• Issues are opened for gaps.
• Evidence needs are defined.
• Owners receive structured tasks.
• Regulatory inquiries can reference the history of decisions and actions.

This turns regulatory change into managed work.

Example 3: A vendor supports a critical service

In a disconnected program:

• Procurement owns the vendor record.
• Resilience owns the critical service map.
• Security owns the cyber assessment.
• Legal owns the contract.
• Privacy owns the data review.
• Business continuity owns the plan.
• Risk reporting pulls pieces together manually.

In a Connected GRC program:

• The vendor links to the business owner, contract, risk rating, assessment history, controls, issues, incidents, data access, and critical services.
• If the vendor risk changes, the resilience view changes.
• If an incident occurs, the vendor relationship is visible.
• If a control gap is found, remediation is tracked.
• If the contract changes, obligations can be reviewed.

The vendor becomes part of the risk system, not just a procurement record.

Example 4: An AI system is introduced

In a disconnected program:

• Product or engineering starts using an AI system.
• Legal may review terms.
• Privacy may assess data use.
• Security may review access.
• Compliance may ask about policy.
• Risk may not see the use case until later.
• Audit may not know what evidence exists.

In a Connected GRC program:

• The AI system is recorded in an inventory.
• The use case, owner, vendor, data sources, policies, risks, controls, and assessments are linked.
• Required reviews are triggered.
• Issues are created for gaps.
• Evidence is stored against the relevant controls and obligations.
• Leadership can see AI risk in the broader GRC context.

This is why AI Governance should be connected to the broader operating model rather than managed as a separate silo.

Ownership in a Connected GRC operating model

A Connected GRC program needs clear ownership.

Not every record should be owned by the central GRC team.

In fact, one sign of a weak operating model is that the GRC team becomes the owner of everything because no one else is accountable.

A stronger model separates ownership by role.

The central GRC team should not own all risk.

It should define the structure that helps the organization manage risk consistently.

The role of the first, second, and third lines

Connected GRC works best when each line has a clear role.

First line: owns and performs the work

The first line owns business processes, risks, controls, evidence, remediation, and day-to-day execution.

A Connected GRC operating model should make first-line participation simple.

Business owners should know:

• what they own
• what is due
• what evidence is required
• what changed
• which risks or controls are involved
• why the work matters

If the system only makes sense to GRC specialists, adoption will suffer.

Second line: sets standards and provides oversight

The second line includes risk, compliance, privacy, cyber risk, third-party risk, SOX, resilience, AI governance, and similar functions.

It defines taxonomies, frameworks, policies, assessment methods, testing requirements, issue governance, reporting standards, and escalation expectations.

The second line should not only collect information.

It should help the business manage risk better.

Third line: provides independent assurance

Internal audit needs independence, but it also needs visibility.

A Connected GRC operating model allows internal audit to see risks, controls, test results, prior issues, evidence, remediation status, and emerging risk indicators.

That improves audit planning and strengthens assurance.

Internal audit should not have to reconstruct the risk environment from scratch every audit cycle.

Reporting: from status updates to decision support

Reporting is often where GRC programs reveal whether they are truly connected.

Disconnected reporting usually depends on manual collection.

People chase status updates. Teams reconcile spreadsheets. Reports are assembled in slides. Data becomes stale before the meeting.

Connected reporting works differently.

Dashboards and reports should draw from source records.

That means leaders can see:

• top risks and trends
• control effectiveness
• open issues by severity and owner
• overdue remediation
• regulatory change impact
• audit findings and closure status
• vendor risk exposure
• critical services and resilience gaps
• incidents and root causes
• SOX deficiencies
• AI governance status
• privacy risk and open actions
• ESG evidence readiness

The purpose of reporting is not to show that GRC teams are busy.

The purpose is to help leaders make decisions.

Good reporting should answer:

• What changed?
• What matters most?
• Who owns it?
• What decision is needed?
• What happens if we do nothing?
• How confident are we in the data?

The minimum viable Connected GRC operating model

A full Connected GRC program takes time.

But organizations do not need to build everything at once.

A minimum viable operating model should include:

1. A shared taxonomy

Define common language for risks, controls, obligations, issues, severity, likelihood, impact, business units, assets, vendors, and critical services.

2. A control framework

Create a reusable control library that maps to regulations, frameworks, policies, risks, tests, evidence, and issues.

3. A common issue model

Use a shared structure for findings, deficiencies, gaps, exceptions, incidents, and corrective actions.

4. Evidence traceability

Make sure evidence connects to the control, test, assessment, owner, period, and review it supports.

5. Clear ownership

Every major object should have an owner. Every workflow should have an accountable function.

6. Live reporting

Start with a small set of trusted dashboards based on source data.

7. Expansion path

Design each workflow so it can connect to the next one.

That last point is important.

A Connected GRC program should grow by adding relationships, not by creating new silos.

Where to start

The best starting point depends on where the organization feels the most friction.

Start with controls if duplication is the problem

If teams are testing the same control repeatedly across frameworks, start with Control Framework & Regulatory Libraries, Compliance Assessments & Testing, SOX Compliance, and SOC 2 Compliance.

This creates immediate value for compliance, audit, cyber, SOX, and control owners.

Start with issues if remediation is the problem

If findings, exceptions, and corrective actions are scattered across teams, start with Issues Management.

This creates a common way to assign ownership, track due dates, collect closure evidence, and report status.

Start with enterprise risk if leadership lacks visibility

If executives do not have a clear view of top risks, start with Enterprise Risk Management and Risk and Control Self-Assessment.

Then connect risks to controls, issues, assessments, incidents, vendors, and mitigation work.

Start with regulatory change if compliance is reactive

If regulatory change creates manual coordination, start with Regulatory Change Management, Policy Management, Control Framework & Regulatory Libraries, and Compliance Assessments & Testing.

The goal is to connect change to obligations, policies, controls, owners, and evidence.

Start with third-party risk if vendor exposure is unclear

If vendor risk is disconnected from business impact, start with Third Party Risk Management, Vendor Portal, and Contract Lifecycle Management.

Then connect vendors to critical services, controls, incidents, issues, privacy, and resilience.

Start with resilience if readiness is hard to prove

If business continuity plans, BIAs, incidents, and dependencies are disconnected, start with Operational Resilience & Business Continuity, Business Impact Analysis, Enterprise Assets & Structure, Incident Management, and Crisis Management.

The goal is to connect critical services to the assets, vendors, processes, and plans that support them.

Start with AI governance if new risk is moving faster than oversight

If AI usage is expanding without consistent governance, start with AI Governance and CRI AI RMF.

Then connect models to policies, risks, controls, vendors, privacy, evidence, and issues.

Common mistakes to avoid

Mistake 1: Building the data model around departments

Departments matter, but risks move across them.

Build the model around business relationships, not org charts.

Mistake 2: Treating controls as framework-specific records

A control should not be recreated for every framework unless there is a real reason.

Design controls to be reusable, then map them to obligations and frameworks.

Mistake 3: Separating issue management from risk management

Issues are one of the clearest signals of risk.

If issues do not connect to risks and controls, leadership cannot easily see whether exposure is improving.

Mistake 4: Creating dashboards before the data is trusted

Dashboards built on weak data create false confidence.

Start with ownership, definitions, workflow, and evidence quality.

Mistake 5: Overengineering the taxonomy

A taxonomy should create shared meaning.

If it becomes too complex, people will avoid it.

Mistake 6: Making the GRC team the owner of everything

The GRC team should design and govern the model.

The business should own the risks, controls, issues, evidence, and decisions it is responsible for.

Mistake 7: Adding new risk domains as new silos

AI governance, ESG, privacy, cyber, and resilience should not become separate islands.

Each new domain should connect into the broader GRC operating model.

A practical test of your operating model

Choose one important issue.

Then ask whether your GRC program can show:

• which risk it affects
• which control failed
• which obligation, policy, or framework is involved
• which business unit owns the issue
• which evidence supports the finding
• which remediation plan is underway
• which vendor, asset, incident, audit, or assessment is related
• whether the issue affects SOX, privacy, cyber, resilience, or regulatory reporting
• what leadership needs to know
• whether the risk changed after the issue was closed

If the answer requires five systems, multiple spreadsheets, and several meetings, the operating model is not connected enough.

That does not mean the program is failing.

It means the next stage of maturity is clear.

Final thought

A Connected GRC operating model is not about centralizing everything for the sake of control.

It is about making the organization easier to govern.

That means connecting the records, workflows, owners, and evidence that already exist across risk, compliance, audit, cyber, legal, privacy, finance, procurement, ESG, AI governance, and resilience.

The work of GRC will always require judgment.

But judgment improves when people can see the relationships.

Risks connect to controls. Controls connect to obligations. Obligations connect to policies. Tests connect to evidence. Issues connect to remediation. Vendors connect to critical services. Incidents connect to lessons learned. Audit findings connect to assurance. Reports connect to source data.

That is the operating model behind Connected GRC.

And it is what turns GRC from a collection of activities into a system for better decisions.