The Connected GRC Data Model: A Plain-English Guide for Risk and Compliance Teams

A Connected GRC program does not start with a dashboard.

It starts with a data model.

That may sound technical.

It does not have to be.

A data model is simply the way the organization defines the records it uses and how those records relate to each other.

In GRC, those records are familiar:

Risks.
Controls.
Policies.
Obligations.
Evidence.
Issues.
Incidents.
Vendors.
Contracts.
Audits.
Findings.
Regulatory changes.
Regulatory inquiries.
Assets.
Business processes.
Critical services.
Remediation plans.

Most risk and compliance teams already work with these records.

The problem is that the records are often disconnected.

A risk sits in one tool.
A control sits in another.
Evidence sits in a folder.
An audit finding sits in a workpaper.
A vendor issue sits in a procurement tracker.
A privacy assessment sits with legal.
A cyber incident sits in a security tool.
A regulatory change sits in a compliance spreadsheet.

The records exist.

But the story is hard to connect.

A Connected GRC data model fixes that.

It gives risk, compliance, audit, security, privacy, third-party risk, resilience, AI governance, ESG, SOX, and business teams a shared way to understand how GRC work fits together.

The goal is not to create a technical diagram for architects.

The goal is to help teams answer practical questions:

• What risk does this control reduce?
• Which obligation does this policy support?
• What evidence proves this control worked?
• Which issue was created when testing failed?
• Which vendor supports this critical service?
• Which incident changed the risk view?
• Which audit finding requires validated remediation?
• Which dashboard should show the decision needed?

That is the purpose of the Connected GRC data model.

It turns disconnected records into a working program.

What is a Connected GRC data model?

A Connected GRC data model is the shared structure that defines the core GRC records — risks, controls, obligations, policies, evidence, issues, vendors, incidents, audits, assets, services, and remediation — and how those records connect to support ownership, proof, assurance, and decisions.

A simple way to think about it:

• Records are the nouns.
• Workflows are the verbs.
• Relationships are the meaning.

For example:

• Risk is a record.
• Control is a record.
• Evidence is a record.
• Testing is a workflow.
• Remediation is a workflow.
• The relationship between risk, control, evidence, testing, and remediation is what makes the program useful.

A GRC tool can store records.

A Connected GRC data model explains how those records work together.

That distinction matters.

A risk register by itself is not a data model.
A control library by itself is not a data model.
An evidence folder by itself is not a data model.
An audit finding tracker by itself is not a data model.

The model is the connection between them.

Why risk and compliance teams should care about the data model

The data model determines whether the program can answer the questions leaders actually ask.

If the data model is weak, teams spend time reconciling spreadsheets, rebuilding evidence, chasing owners, and explaining why dashboards do not match.

If the data model is strong, teams can see:

• which risks are tied to which objectives
• which obligations are mapped to policies and controls
• which controls have evidence
• which evidence has been accepted
• which tests failed
• which issues remain open
• which remediation is overdue
• which vendors affect critical services
• which incidents changed the risk view
• which audit findings need validation
• which decisions need escalation

This is why Connected GRC is not only a software conversation.

OCEG frames GRC as integrated capabilities that help an organization achieve objectives, address uncertainty, and act with integrity. A data model is one of the practical ways that integration becomes real.  

The data model is not back-office plumbing.

It shapes how the organization manages risk.

The simple version: twelve core records

Most Connected GRC programs need a core set of records.

You can add more over time, but these are the foundation.

That is the plain-English version.

A Connected GRC data model links these records so the organization can move from risk identification to control, evidence, testing, remediation, assurance, and reporting.

The full version: the connected GRC object map

As the program matures, the model usually expands.

That may look like a lot.

But the idea is simple:

Each record should connect to the records needed to answer the next practical question.

1. Objective → Risk

The first relationship is objective to risk.

A risk should not float in the abstract.

It should connect to something the organization is trying to achieve.

Examples:

• grow revenue
• protect customer trust
• maintain service availability
• meet regulatory obligations
• protect sensitive data
• deliver financial reporting confidence
• maintain operational resilience
• govern AI use
• meet ESG disclosure commitments
• manage third-party dependency

COSO’s ERM framework emphasizes integrating risk with strategy and performance, which is why a Connected GRC data model should begin by connecting risks to business objectives.  

A risk record should answer:

• What objective could this risk affect?
• Who owns the objective?
• Who owns the risk?
• What is the current risk rating?
• What is the appetite threshold?
• What changed recently?
• What controls reduce the risk?
• What issues remain open?

A risk without objective context is harder to prioritize.

A risk connected to an objective becomes decision-ready.

2. Risk → Control

The next relationship is risk to control.

This is where risk becomes action.

A risk record should not only describe exposure. It should show what the organization is doing to manage that exposure.

Examples:

A connected risk-to-control relationship helps answer:

• Which controls reduce this risk?
• Which risks lack control coverage?
• Which controls support top risks?
• Which controls failed?
• Which failed controls should change residual risk?
• Which controls need investment?

Without this relationship, residual risk is mostly opinion.

With it, residual risk can reflect control condition.

3. Obligation → Policy → Control

Compliance depends on this chain.

An obligation explains what the organization must do.

A policy translates the obligation into an internal expectation.

A control makes the expectation operational.

For example:

This chain is critical.

If obligations are not connected to policies, policies may not reflect regulatory expectations.

If policies are not connected to controls, policies may not be operational.

If controls are not connected to evidence, compliance is hard to prove.

SmartSuite’s Compliance Management materials describe centralizing controls, evidence, policies, and obligations, and connecting compliance requirements to testing and remediation workflows. That is the type of relationship model a Connected GRC program needs.

4. Control → Evidence

Evidence is where GRC becomes provable.

A control should define the evidence required to show it operated.

A connected evidence record should answer:

• What control does this evidence support?
• What period does it cover?
• Who provided it?
• Who reviewed it?
• Was it accepted?
• Was it rejected?
• Was it used in an audit?
• Was it used in a regulatory inquiry?
• Can it be reused?
• Did it create an issue?

Evidence without a control is just a file.

Evidence connected to a control is proof.

This relationship is one of the most important in the entire data model.

It reduces duplicate evidence requests.

It improves audit readiness.

It makes regulatory response easier.

It helps control owners understand what to provide.

5. Evidence → Test Result

Evidence collection is not the same as testing.

Evidence says:

“Here is what happened.”

Testing asks:

“Does this prove the control worked?”

A test result should connect to:

• control tested
• evidence reviewed
• testing period
• reviewer
• conclusion
• exception
• issue created
• remediation required
• retesting requirement

Example:

A control owner uploads access review evidence.

The reviewer finds that the evidence does not show the full user population.

The test result is not simply “evidence uploaded.”

The test result is “exception identified.”

That exception should create an issue.

This relationship prevents false confidence.

Uploaded evidence is not enough.

Reviewed evidence matters.

6. Test Result → Issue

When a test fails, the result should create action.

That action usually becomes an issue.

An issue record should include:

• source
• affected control
• affected risk
• affected obligation
• affected policy
• owner
• severity
• root cause
• due date
• remediation plan
• closure evidence
• validation requirement
• escalation status

A failed test that does not create an issue is only a note.

A failed test connected to an issue becomes accountable work.

This is where control testing, compliance, audit, and remediation come together.

7. Issue → Remediation → Validation

An issue is not complete when someone changes the status to closed.

A connected data model should separate:

• the issue
• the remediation plan
• the closure evidence
• the validation result

These are different records or at least different parts of the same governed record.

A remediation workflow should answer:

• What will be fixed?
• Who owns it?
• What is the due date?
• What evidence proves completion?
• Who reviews the evidence?
• Who validates closure?
• Does the fix address root cause?
• Does the control need retesting?
• Does residual risk change?

This relationship is critical because many GRC programs fail at remediation.

They identify findings but do not prove the fix worked.

A Connected GRC data model should make validated closure visible.

8. Vendor → Service → Risk

Vendors should not be treated as procurement records only.

A vendor may support a critical service, process sensitive data, provide AI functionality, support financial reporting, host systems, or create operational resilience exposure.

A vendor record should connect to:

• business owner
• contract
• service supported
• data access
• system access
• risk tier
• cyber review
• privacy review
• AI review, where relevant
• ESG or supplier review, where relevant
• incident history
• open issues
• resilience evidence
• renewal decision

This relationship helps answer:

• Which vendors support critical services?
• Which vendors process sensitive data?
• Which vendors have open issues?
• Which vendors were involved in incidents?
• Which vendors affect top risks?
• Which renewals should be conditional on remediation?

Without vendor-to-service mapping, third-party risk is too generic.

With it, vendor risk becomes operational.

9. Asset → Service → Incident

Operational resilience depends on knowing which assets support which services.

An asset may be:

• application
• database
• cloud service
• server
• facility
• endpoint
• identity platform
• API
• network component
• data store
• physical location

An asset should connect to:

• owner
• business process
• critical service
• vendor
• data
• vulnerability
• control
• incident
• recovery expectation
• open issue

An incident should connect to the affected asset and service.

That helps answer:

• Which service was affected?
• Which asset failed?
• Which vendor was involved?
• Which control failed?
• What was the root cause?
• Which issue was created?
• Does the continuity plan need update?
• Does risk need reassessment?

This relationship turns incidents into risk intelligence.

Without it, incidents may be closed without improving resilience.

10. Audit Finding → Issue → Validation

Internal audit findings should not live only in audit reports.

They should connect to the broader issue and remediation model.

The IIA Three Lines Model describes internal audit as providing independent and objective assurance and advice on governance and risk management. In a Connected GRC data model, that assurance is stronger when findings connect to risks, controls, evidence, issues, remediation, and validation.  

An audit finding should connect to:

• audit engagement
• risk
• control
• evidence reviewed
• root cause
• management action plan
• issue
• remediation owner
• due date
• closure evidence
• validation result
• audit committee reporting

This helps answer:

• Which risk did the finding affect?
• Which control failed?
• What is management doing?
• Has remediation been validated?
• Is this a repeat finding?
• Does residual risk change?

A finding that does not connect to remediation is incomplete.

A finding that connects to validated closure creates improvement.

11. Regulatory Change → Obligation → Action

Regulatory change is not useful if it stops at awareness.

A regulatory change should connect to:

• source
• applicability decision
• obligation
• policy
• control
• evidence
• issue
• owner
• testing update
• regulatory inquiry readiness
• reporting

This relationship helps answer:

• What changed?
• Does it apply?
• Which obligations are affected?
• Which policies need updates?
• Which controls need updates?
• Which evidence requirements changed?
• Which issues were opened?
• What is readiness status?

A regulatory change tracker is not enough.

The change must connect to action.

That is why regulatory change belongs in the data model.

12. Regulatory Inquiry → Evidence → Commitment

Regulatory inquiries are another important data relationship.

An inquiry should not be managed as a one-off scramble.

It should connect to:

• regulator
• request item
• obligation
• policy
• control
• evidence
• response
• approval
• issue
• commitment
• remediation
• validation

This helps answer:

• What did the regulator ask?
• What evidence was provided?
• Who approved the response?
• What commitments were made?
• Are those commitments complete?
• Was closure validated?

A regulatory inquiry is not only a document request.

It is a test of whether the data model is connected.

If obligations, policies, controls, evidence, and issues are connected, response becomes easier.

If they are not, response becomes a fire drill.

The data model should support different views

One data model should support many views.

Different teams need different views of the same connected data.

Risk view

• risks
• objectives
• appetite
• controls
• issues
• incidents
• vendors
• audit findings
• decisions

Compliance view

• obligations
• policies
• controls
• evidence
• testing
• regulatory change
• inquiries
• issues

Audit view

• audit universe
• risks
• controls
• evidence
• findings
• management action plans
• validation
• assurance coverage

Business owner view

• owned risks
• owned controls
• evidence due
• issues assigned
• vendors owned
• policies requiring attestation
• decisions needed

Board view

• top risks
• risk movement
• appetite exceptions
• control failures
• overdue remediation
• material incidents
• vendor exposure
• assurance gaps
• decisions needed

The data model stays connected.

The view changes by audience.

That is how a Connected GRC platform should work.

A plain-English example: one control across the model

Considera quarterly access review.

Here is how it connects.

This is the Connected GRC data model in action.

The control is not a standalone record.

It connects risk, compliance, evidence, testing, issue management, audit, remediation, and reporting.

A plain-English example: one vendor across the model

Consider a cloud vendor supporting a customer-facing service.

Again, the value is not the vendor record alone.

The value is the relationships.

A plain-English example: one regulatory change across the model

Consider a new privacy requirement.

This is what it means to connect regulatory change to action.

The minimum viable Connected GRC data model

Organizations do not need to model everything at once.

A practical first version can start with seven records:

1. Risk
2. Control
3. Evidence
4. Issue
5. Owner
6. Vendor
7. Incident

Then add:

1. Obligation
2. Policy
3. Audit finding
4. Regulatory change
5. Critical service

This phased approach works because the model can mature over time.

Do not wait for perfection.

Start with the records that create the most value.

The five relationships to build first

The first version of the data model should focus on five relationships:

These relationships create immediate value.

They reduce duplicate evidence requests.

They improve issue tracking.

They make remediation clearer.

They help leaders understand risk movement.

They help the board see decisions.

After those relationships work, expand the model.

Data quality rules for the model

A Connected GRC data model needs data quality rules.

Simple rules work best.

Risk record rules

• Every top risk has an owner.
• Every top risk has a rating and rationale.
• Every top risk maps to controls or accepted gaps.
• Every top risk shows open high-severity issues.

Control record rules

• Every key control has an owner.
• Every key control has evidence requirements.
• Every key control maps to risk or obligation.
• Every failed control creates an issue when material.

Evidence record rules

• Every evidence record has a period.
• Every evidence record has an owner.
• Every evidence record has a reviewer.
• Every evidence record is accepted, rejected, or pending.

Issue record rules

• Every issue has an owner.
• Every issue has a root cause or root-cause status.
• Every issue has a due date.
• Every material issue has closure evidence.
• Every material issue has validation.

Vendor record rules

• Every critical vendor has a business owner.
• Every critical vendor maps to services.
• Every critical vendor has contract and issue status.
• Every critical vendor has incident history where applicable.

These rules are plain English.

But they make the data model much stronger.

Common data model mistakes to avoid

Mistake 1: Treating the data model as an IT project

The data model is an operating model.

Risk, compliance, audit, security, privacy, resilience, finance, legal, procurement, and business teams should help define it.

Mistake 2: Starting with every possible object

Too many objects too early creates complexity.

Start with the records that answer your most important questions.

Mistake 3: Creating records without relationships

A risk register, control library, and issue tracker are not enough.

The relationships create the value.

Mistake 4: Using different names for the same object

Finding, issue, gap, deficiency, exception, and remediation item may need to relate to one common issue model.

Mistake 5: Ignoring ownership

Every important record needs an owner.

Without ownership, the model becomes documentation.

Mistake 6: Designing only for central GRC teams

Business users need simple views of what they own.

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

Mistake 7: Building dashboards before relationships

Dashboards should come after source records and relationships are reliable.

A dashboard built on weak data creates false confidence.

How to implement the data model in phases

Phase 1: Map one top risk

Pick one top risk and connect it to controls, evidence, issues, incidents, vendors, and audit findings.

Phase 2: Build one control family

Choose a high-demand control family, such as access management, and map controls to obligations, evidence, testing, and issues.

Phase 3: Standardize issue management

Create one issue model across audit, compliance, cyber, privacy, SOX, vendors, ESG, AI, and resilience.

Phase 4: Connect regulatory obligations

Map obligations to policies, controls, evidence, testing, issues, and inquiries.

Phase 5: Connect vendors to services

Map critical vendors to services, contracts, data, incidents, issues, and renewals.

Phase 6: Connect incidents to lessons learned

Map incidents to services, assets, vendors, controls, issues, and risk updates.

Phase 7: Build dashboards

Create dashboards only after relationships are strong enough to support them.

This phased approach avoids overengineering.

It also creates value early.

What good looks like

A disconnected GRC data model sounds like this:

“Risk, compliance, audit, vendors, incidents, and evidence are tracked in different systems. We reconcile them for reporting.”

A Connected GRC data model sounds like this:

“Top risks connect to controls, controls connect to evidence, failed tests create issues, issues connect to remediation and validation, vendors connect to critical services, incidents update risk, and dashboards show decisions needed.”

The second model is more useful.

It does not require every record to live in one place on day one.

It requires the important relationships to be defined and governed.

A practical test for your current data model

Pick one top risk.

Then ask whether your current model can quickly show:

• business objective affected
• risk owner
• risk appetite threshold
• controls that mitigate the risk
• evidence supporting those controls
• latest test results
• failed controls
• open issues
• remediation plans
• closure evidence
• validation status
• incidents related to the risk
• vendors related to the risk
• audit findings related to the risk
• regulatory obligations related to the risk
• decisions needed

If those answers require spreadsheets, email threads, evidence folders, audit files, vendor tools, incident tickets, and meetings, the data model is not connected enough.

That is common.

It is also the opportunity.

Final thought

The Connected GRC data model does not need to be mysterious.

It is simply the structure that explains how the records in your GRC program fit together.

Risks connect to objectives.
Controls connect to risks and obligations.
Evidence connects to controls.
Testing connects to evidence.
Failures connect to issues.
Issues connect to remediation.
Remediation connects to validation.
Vendors connect to services.
Incidents connect to impact.
Audit findings connect to assurance.
Regulatory changes connect to action.
Dashboards connect to decisions.

That is the model.

When the model is weak, teams rebuild the story manually.

When the model is strong, the story is already connected.

That is the practical value of a Connected GRC data model.

It gives risk and compliance teams a shared language for how the program actually works.