The Connected GRC Data Model: The Records Every Program Needs

Connected GRC does not start with dashboards.

It starts with records.

Risks.
Obligations.
Policies.
Controls.
Evidence.
Tests.
Issues.
Remediation plans.
Vendors.
Contracts.
Assets.
Incidents.
Audit findings.
Regulatory inquiries.
Business services.
Decisions.

Those records already exist in most organizations.

The problem is that they often exist in different places.

The risk register is in one tool.
The control matrix is in another.
Evidence sits in shared folders.
Audit findings sit in audit software.
Vendor reviews sit in spreadsheets.
Regulatory changes sit with legal or compliance.
Incidents sit in tickets.
Privacy assessments sit in privacy files.
Cyber vulnerabilities sit in security tools.
Business continuity plans sit in documents.
Executive dashboards are built manually.

The organization may have the data.

But it does not have the model.

That is why Connected GRC depends on a clear data model.

A Connected GRC data model is not just a database schema. It is the operating structure that shows how governance, risk, compliance, audit, resilience, privacy, cyber, third-party risk, AI governance, and ESG records fit together.

It helps the organization answer practical questions:

• Which risks are affected by this control failure?
• Which obligations does this control support?
• Which evidence proves the control operated?
• Which issue was opened when the control failed?
• Which remediation plan proves the fix worked?
• Which vendor supports this critical service?
• Which incident changed the risk view?
• Which policy maps to this obligation?
• Which audit finding affects this risk?
• Which dashboard should show this decision?

Without a data model, GRC becomes a collection of workflows.

With a data model, GRC becomes connected.

What is a Connected GRC data model?

A Connected GRC data model is the structured set of records, fields, relationships, owners, statuses, and workflows that links risks, obligations, policies, controls, evidence, tests, issues, vendors, incidents, assets, audits, resilience, privacy, AI governance, ESG, and reporting into one operating model.

It defines:

• what records exist
• who owns each record
• which fields matter
• which records connect to each other
• which workflows update those records
• which evidence supports them
• which issues are created when something fails
• which dashboards report on them
• which decisions leaders need to make

A weak GRC model stores information.

A strong GRC model creates traceability.

That traceability is what makes Connected GRC useful.

OCEG’s definition of GRC emphasizes integrated capabilities that help organizations achieve objectives, address uncertainty, and act with integrity. A Connected GRC data model is the practical structure that makes those integrated capabilities visible and usable.  

Why the data model matters

The data model matters because most GRC pain is relationship pain.

The control exists, but it is not linked to the risk.
The evidence exists, but it is not linked to the control.
The issue exists, but it is not linked to the failed test.
The vendor exists, but it is not linked to the critical service.
The incident exists, but it is not linked to the root cause.
The obligation exists, but it is not linked to a policy or control.
The audit finding exists, but it is not linked to remediation evidence.
The dashboard exists, but it is not linked to source records.

When relationships are missing, teams spend time reconstructing context.

That creates:

• duplicate evidence requests
• duplicate controls
• inconsistent risk ratings
• manual reporting
• weak audit trails
• late remediation
• unclear ownership
• poor dashboard trust
• repeat findings
• slow regulatory response
• fragmented executive reporting

The data model is what prevents that.

It gives the organization a shared structure for how GRC work connects.

The core Connected GRC records

Every organization will have its own terminology.

But most Connected GRC programs need a version of these records:

These records do not need to be perfect on day one.

But the program needs to know which ones matter and how they relate.

The minimum viable Connected GRC data model

A 90-day implementation should not attempt to build every record at once.

Start with a minimum viable model.

For most programs, the minimum model is:

That model can support many first-phase workflows:

• SOC 2 readiness
• SOX controls
• compliance testing
• internal audit remediation
• evidence management
• issue management
• control libraries
• policy-to-control mapping

Then the model can expand into:

• vendors
• contracts
• assets
• incidents
• regulatory inquiries
• operational resilience
• privacy
• AI governance
• ESG
• enterprise risk reporting

Start small.

But design for connection.

Record 1: Objective

A risk has more meaning when it connects to an objective.

Objectives may include:

• grow revenue
• maintain customer trust
• protect customer data
• maintain financial reporting integrity
• deliver critical services
• meet regulatory obligations
• improve operational efficiency
• maintain cyber resilience
• manage vendor dependency
• adopt AI responsibly
• support ESG disclosure readiness
• protect employee safety

COSO’s ERM framework emphasizes integrating risk with strategy and performance, which is why objectives belong in the data model. Risks should not float in isolation; they should connect to what the organization is trying to achieve.  

A connected objective record should include:

• objective name
• owner
• business unit
• linked risks
• risk appetite
• KRIs
• controls or mitigations
• issues
• decisions needed

Objective records help leaders understand risk in business language.

Record 2: Risk

The risk record is one of the most important records in Connected GRC.

A risk record should show:

• risk name
• risk description
• risk category
• owner
• business objective affected
• inherent risk
• controls or mitigations
• residual risk
• risk appetite or tolerance
• KRIs
• related issues
• related incidents
• related vendors
• related assets
• related obligations
• mitigation plan
• decision needed

A risk record should not be only a heatmap entry.

It should connect to the operating facts that influence risk:

• failed controls
• overdue issues
• incidents
• vendor findings
• vulnerabilities
• audit findings
• regulatory changes
• evidence gaps
• accepted risks

A risk rating based only on opinion will become stale.

A risk rating informed by connected records becomes useful.

Record 3: Obligation

An obligation is something the organization must do.

Obligations can come from:

• law
• regulation
• regulatory guidance
• contract
• customer commitment
• framework
• internal policy
• board decision
• consent order
• audit commitment
• standard
• industry requirement

A connected obligation record should include:

• obligation source
• requirement text
• jurisdiction or scope
• affected entity
• affected business process
• affected policy
• mapped control
• evidence requirement
• owner
• due date or frequency
• regulatory change source
• inquiry relevance
• issue history

Obligations matter because they create work.

If an obligation is not connected to a policy, control, evidence, owner, or issue workflow, it is difficult to manage.

SmartSuite’s Compliance Management page describes centralizing frameworks, controls, evidence, policies, and obligations, and linking compliance requirements to controls, assessments, and remediation actions.  

That is exactly how obligations should work in the data model.

Record 4: Policy

A policy defines an internal expectation.

Policy records should include:

• policy name
• policy owner
• version
• status
• effective date
• review date
• approval history
• audience
• linked obligations
• linked risks
• linked procedures
• linked controls
• attestations
• exceptions
• related issues
• evidence

Policies should not be disconnected documents.

A policy should answer:

• What requirement does it support?
• What risk does it address?
• Which controls make it real?
• Who has attested to it?
• Which exceptions exist?
• Which issues show the policy is not working?

If the policy is not linked to controls, evidence, and issues, it may be well written but operationally weak.

Record 5: Procedure

A procedure explains how work is done.

Procedure records should include:

• procedure name
• owner
• related policy
• process steps
• roles
• systems used
• evidence generated
• related controls
• exceptions
• review date
• change history
• issues

Procedures are important because controls often operate inside procedures.

For example:

• vendor onboarding procedure
• access review procedure
• incident response procedure
• privacy assessment procedure
• regulatory change procedure
• issue remediation procedure
• AI use-case review procedure
• business continuity testing procedure

The procedure tells people how to perform the work.

The control proves the work happened or managed risk.

Connected GRC should preserve both.

Record 6: Control

The control record is the bridge between risk, obligation, policy, evidence, testing, and assurance.

A connected control record should include:

• control ID
• control name
• control objective
• control description
• control owner
• control performer
• control reviewer
• control frequency
• control type
• related risk
• related obligation
• related policy
• related procedure
• framework mappings
• evidence requirement
• test procedure
• last test result
• open issues
• remediation status
• audit relevance

Controls should be authoritative.

Avoid creating duplicate controls for every framework.

Instead, create common controls where the control objective is shared, then map those controls to multiple frameworks, obligations, policies, and audits.

SmartSuite’s Compliance Management page specifically describes mapping controls once and reusing them across multiple frameworks to reduce redundant work.  

That is the core of the Connected GRC control model.

Record 7: Evidence

Evidence proves that a control, activity, decision, remediation action, or obligation was performed.

Evidence records should include:

• evidence name
• evidence type
• evidence owner
• provider
• reviewer
• control supported
• obligation supported
• period covered
• source system
• submission date
• review date
• acceptance status
• rejection reason
• expiration date, if relevant
• linked test
• linked issue
• linked audit request
• linked regulatory inquiry

Evidence is not just a file.

It is a record with context.

A screenshot without period, owner, control, and reviewer context is weak.

A connected evidence record can answer:

• What does this prove?
• Which control does it support?
• Which obligation does it satisfy?
• Who provided it?
• Who reviewed it?
• Was it accepted?
• Can it be reused?
• Which audit or inquiry relied on it?

That is the difference between evidence storage and evidence management.

Record 8: Assessment or Test

Assessments and tests evaluate something.

They may evaluate:

• risk
• control effectiveness
• compliance status
• vendor risk
• privacy impact
• AI risk
• resilience readiness
• policy attestation
• issue closure
• audit readiness
• regulatory compliance

A connected assessment or test record should include:

• assessment type
• scope
• owner
• reviewer
• related risk
• related control
• related obligation
• evidence reviewed
• test procedure
• period covered
• result
• exceptions
• issue created
• retest requirement
• conclusion
• approval

Testing is where evidence becomes a conclusion.

A test should not be separated from the evidence reviewed or the issue created when the test fails.

Connected GRC links all three.

Record 9: Issue

An issue is a gap that needs action.

Issues can come from:

• failed control test
• audit finding
• regulatory inquiry
• incident
• vendor review
• privacy assessment
• AI review
• vulnerability management
• business continuity exercise
• crisis after-action review
• ESG assurance review
• SOX deficiency
• SOC 2 exception
• policy exception
• regulatory change impact

A connected issue record should include:

• issue title
• issue source
• description
• affected risk
• affected control
• affected obligation
• affected policy
• affected vendor
• affected asset or service
• owner
• severity
• root cause
• due date
• remediation plan
• evidence required
• validation method
• status
• closure decision
• residual risk impact

Issues are the backbone of Connected GRC because they turn findings into action.

An issue should not live only in an audit report, email thread, ticket, or spreadsheet.

It should connect to the source, owner, remediation plan, evidence, validation, and dashboard.

Record 10: Remediation Plan

A remediation plan explains how an issue will be fixed.

A remediation record should include:

• issue
• remediation owner
• action plan
• milestones
• due date
• dependencies
• evidence required
• validation owner
• validation method
• retest requirement
• closure evidence
• closure approval
• residual risk decision

Remediation is not complete because someone says it is complete.

The data model should separate:

• remediation planned
• remediation in progress
• remediation completed
• evidence submitted
• validation pending
• validation passed
• validation failed
• closed
• risk accepted

This prevents premature closure.

It also helps dashboards show remediation quality, not just closure rate.

Record 11: Incident

An incident is an event that affects or threatens operations, systems, data, vendors, facilities, controls, services, or compliance.

Incident records should include:

• incident type
• date reported
• reporter
• owner
• severity
• affected service
• affected asset
• affected vendor
• affected data
• affected control
• response tasks
• evidence
• root cause
• privacy review status
• legal review status
• crisis activation status
• business continuity activation status
• issue created
• remediation plan
• closure decision

NIST CSF 2.0 organizes cybersecurity outcomes across Govern, Identify, Protect, Detect, Respond, and Recover, and its Respond and Recover functions directly connect incident management, mitigation, reporting, communication, and recovery.  

That structure reinforces the broader Connected GRC point: incidents should not be isolated events. They should feed controls, issues, remediation, resilience, and risk reporting.

Record 12: Vendor or Third Party

A vendor or third-party record represents an external party that provides goods, services, systems, data processing, technology, operational support, or other dependency.

Vendor records should include:

• vendor name
• service description
• business owner
• vendor manager
• procurement owner
• contract owner
• risk tier
• criticality
• data access
• system access
• AI involvement
• resilience impact
• privacy review status
• cyber review status
• financial review status
• contract status
• evidence
• incidents
• issues
• renewal date
• offboarding requirements

A vendor record should connect to:

• contracts
• assessments
• evidence
• issues
• incidents
• business services
• data
• systems
• renewals
• offboarding tasks

Third-party risk becomes difficult when vendor records are disconnected from contracts, evidence, issues, incidents, and business-service dependencies.

The data model should connect them from the start.

Record 13: Contract

A contract defines rights, obligations, protections, service commitments, and risk controls.

Contract records should include:

• contract name
• counterparty
• entity
• business owner
• contract owner
• effective date
• renewal date
• termination date
• obligations
• SLAs
• security terms
• privacy terms
• incident notification terms
• audit rights
• continuity obligations
• AI data-use terms
• ESG or supplier conduct terms
• exceptions
• related vendor
• related issues
• evidence
• renewal decision

A contract should not sit apart from GRC.

It should connect to the vendor, obligations, issues, risk reviews, evidence, incidents, renewals, and offboarding.

A contract is one of the most important operating records in third-party risk.

Record 14: Asset

An asset may be a system, application, data store, facility, AI system, database, integration, device, physical location, or service-supporting resource.

Asset records should include:

• asset name
• asset type
• owner
• technical owner
• business owner
• data owner
• criticality
• business services supported
• business processes supported
• data processed
• vendors involved
• controls
• vulnerabilities
• incidents
• recovery plan
• privacy relevance
• SOX or SOC 2 relevance
• AI relevance
• issues

NIST CSF 2.0’s Identify function emphasizes understanding assets such as data, hardware, software, systems, facilities, services, people, and suppliers so organizations can prioritize cybersecurity risk efforts.  

That same principle applies to Connected GRC.

The asset record is where cyber, resilience, privacy, SOX, SOC 2, vendor risk, and incident response often meet.

Record 15: Business Service or Business Process

A business service or process record connects GRC to what the organization actually does.

Business process records should include:

• process name
• process owner
• business unit
• service supported
• criticality
• BIA status
• recovery objective
• systems required
• vendors required
• data required
• facilities required
• controls
• incidents
• issues
• continuity plan
• evidence

Business service records should include:

• service name
• service owner
• impact tolerance, where relevant
• customers or stakeholders affected
• supporting processes
• supporting assets
• supporting vendors
• data dependencies
• continuity plans
• incidents
• issues
• scenario tests
• evidence

This record is critical for operational resilience.

It is also useful for cyber, privacy, vendor, audit, and executive reporting.

A risk is easier to understand when it connects to the business service it affects.

Record 16: BIA, Continuity Plan, and Scenario Test

Operational resilience and business continuity need their own records, but they should connect to the broader model.

BIA record

• process
• owner
• impact over time
• RTO
• RPO
• dependencies
• vendors
• systems
• data
• facilities
• people
• issues
• approval

Continuity plan record

• process or service
• owner
• activation criteria
• recovery steps
• roles
• workarounds
• required assets
• required vendors
• test history
• issues
• evidence

Scenario test record

• service
• scenario
• impact tolerance
• dependencies tested
• participants
• result
• gaps
• issues
• remediation
• retest

These records connect resilience to incidents, vendors, assets, controls, issues, and dashboards.

Without those connections, resilience readiness becomes hard to prove.

Record 17: Audit Finding

An audit finding should not be isolated from the rest of GRC.

Audit finding records should include:

• audit engagement
• finding title
• finding description
• affected risk
• affected control
• affected evidence
• severity
• root cause
• management response
• action plan
• owner
• due date
• remediation evidence
• validation method
• closure approval
• audit committee relevance

Internal audit findings should update the control record, issue register, risk view, and remediation dashboard.

A finding that stays only in an audit report loses value.

A finding connected to risk, control, evidence, and remediation creates assurance value.

Record 18: Regulatory Inquiry

Regulatory inquiries need structured records.

A regulatory inquiry record should include:

• inquiry name
• regulator or authority
• entity
• request date
• response deadline
• obligation involved
• owner
• response item
• evidence needed
• reviewer
• approver
• submission status
• commitments made
• issues created
• follow-up actions
• closure evidence

This record should connect to:

• obligations
• policies
• controls
• evidence
• issues
• audits
• incidents
• vendors
• legal review
• executive reporting

A regulatory inquiry should not trigger a frantic search.

The data model should already connect evidence to obligations and controls.

Record 19: Decision

A decision record is often overlooked.

But it is one of the most valuable records in Connected GRC.

Decision records may include:

• risk acceptance
• issue closure
• remediation extension
• vendor approval
• vendor renewal
• policy exception
• control exception
• AI use-case approval
• crisis decision
• board decision
• executive funding approval
• regulatory response approval
• audit finding closure

A decision record should include:

• decision type
• decision owner
• approver
• date
• rationale
• evidence reviewed
• affected risk
• affected issue
• affected vendor
• affected control
• conditions
• expiration date, if relevant
• follow-up actions

Dashboards should not only show status.

They should show decisions needed and decisions made.

That is how reporting becomes actionable.

Record 20: Dashboard

A dashboard is not a source record.

It is a view of source records.

Dashboard records or dashboard definitions should include:

• audience
• purpose
• source records
• metrics
• thresholds
• owners
• filters
• refresh cadence
• drill-down links
• decisions needed

Dashboards should be role-specific.

Examples:

• executive risk dashboard
• evidence readiness dashboard
• issue remediation dashboard
• vendor risk dashboard
• control health dashboard
• audit finding dashboard
• resilience readiness dashboard
• privacy risk dashboard
• AI governance dashboard
• cyber risk dashboard

SmartSuite’s Compliance Management page describes live dashboards, real-time KPIs, executive-ready reports, and linked controls, evidence, policies, risks, issues, and activities for audit-ready traceability.  

That is the right principle.

A dashboard should not be a manually assembled report.

It should be a role-specific view of connected source data.

The core relationship map

A Connected GRC data model should support these core relationships:

These relationships are more important than the number of records.

A program with fewer records but strong relationships will outperform a program with many disconnected records.

The fields every record needs

Every record does not need the same fields.

But most Connected GRC records need a few common fields.

Ownership, status, and relationships are the most important.

Without those, records become static data.

With those, records become workflow.

Status values matter

Status fields look simple.

They are not.

Status values define workflow.

For example, an issue status might include:

• new
• triaged
• assigned
• remediation in progress
• evidence submitted
• validation pending
• validation failed
• risk accepted
• closed

Evidence status might include:

• requested
• submitted
• under review
• accepted
• rejected
• expired
• reused

Vendor status might include:

• intake
• risk tiering
• due diligence
• contract review
• approved
• approved with conditions
• active
• renewal review
• offboarding
• retired

Do not use vague statuses like “in progress” everywhere.

Status should tell users what happens next.

Ownership matters even more

The data model should make ownership visible.

Common owner fields include:

• risk owner
• control owner
• evidence owner
• issue owner
• remediation owner
• vendor owner
• contract owner
• policy owner
• asset owner
• service owner
• incident owner
• audit owner
• decision owner

A record without an owner is a future delay.

A dashboard without ownership is only a report.

Connected GRC should always answer:

Who owns this?

Build around workflows, not modules

A common mistake is to design the data model around modules:

• risk module
• compliance module
• audit module
• vendor module
• incident module
• privacy module
• AI module
• resilience module

Modules can be useful for navigation.

But the data model should be built around workflows and relationships.

For example:

• A vendor issue may affect cyber risk, privacy risk, operational resilience, contract renewal, and audit reporting.
• A cyber incident may affect privacy, SOX, vendor management, resilience, and enterprise risk.
• A policy update may affect controls, attestations, evidence, and regulatory change.
• A failed control may affect SOC 2, SOX, internal audit, issue remediation, and risk appetite.

If the data model is too module-centric, those relationships break.

Connected GRC should let issues, evidence, controls, vendors, incidents, and risks move across domains.

Start with the records that create value fastest

Do not try to implement every record first.

Start with the records that solve the first workflow.

If starting with controls and evidence

Start with:

• control
• framework requirement
• evidence
• test
• issue
• remediation
• owner
• dashboard

If starting with third-party risk

Start with:

• vendor
• intake
• assessment
• evidence
• contract
• issue
• renewal
• dashboard

If starting with ERM dashboards

Start with:

• objective
• risk
• KRI
• issue
• incident
• control
• decision
• dashboard

If starting with operational resilience

Start with:

• business service
• business process
• BIA
• asset
• vendor
• incident
• issue
• continuity plan
• dashboard

If starting with AI governance

Start with:

• AI use case
• AI system
• business owner
• data
• vendor
• assessment
• control
• evidence
• issue
• monitoring
• dashboard

The data model should expand along the workflow.

Not randomly.

The implementation sequence

A practical data model implementation sequence looks like this:

Step 1: Define the first workflow

Examples:

• evidence collection
• issue remediation
• vendor onboarding
• risk dashboard
• AI intake
• resilience mapping

Step 2: Identify records needed

List the record types required for the workflow.

Step 3: Define relationships

Show how records link.

For example:

• control → evidence → test → issue → remediation → validation

Step 4: Define required fields

Keep fields minimal.

Step 5: Assign ownership

Every record needs an owner.

Step 6: Load priority records

Do not load everything.

Step 7: Build workflow statuses

Statuses should drive action.

Step 8: Build dashboards

Use source records, not manual reports.

Step 9: Test with real users

Use real records and real evidence.

Step 10: Expand

Add adjacent records and workflows.

Common mistakes to avoid

Mistake 1: Treating the data model as a database project

The data model is not only technical.

It is an operating model for risk, compliance, evidence, issues, and decisions.

Mistake 2: Starting with too many records

Start with the records needed for the first workflow.

Add more when the program is ready.

Mistake 3: Creating records without relationships

Disconnected records recreate the same problem in a new system.

Relationships are the value.

Mistake 4: Missing ownership fields

Records without owners become reporting clutter.

Ownership is required for accountability.

Mistake 5: Overloading records with unused fields

Too many fields slow adoption.

Use required fields for workflow and reporting.

Mistake 6: Confusing dashboards with source records

Dashboards are views.

They are only useful if source records are clean and connected.

Mistake 7: Ignoring data hygiene

Records become stale.

Create review cycles, required fields, ownership checks, duplicate record cleanup, and dashboard reviews.

A practical test for your GRC data model

Pick one issue.

Then ask whether your current model can quickly show:

• issue source
• affected risk
• affected control
• affected obligation
• affected evidence
• owner
• root cause
• remediation plan
• evidence required
• validation status
• related audit finding
• related incident
• related vendor
• related policy
• residual risk impact
• dashboard status
• decision needed

Then pick one control.

Ask whether the model can show:

• risk it manages
• obligation it supports
• policy it maps to
• evidence required
• latest test result
• open issues
• remediation history
• frameworks mapped
• audit relevance
• owner
• dashboard status

Then pick one vendor.

Ask whether the model can show:

• business owner
• contract
• services provided
• risk tier
• data access
• system access
• evidence
• open issues
• incidents
• renewal date
• critical service dependency
• offboarding requirements

If answering these questions requires several tools, spreadsheets, emails, and meetings, the data model is not connected enough.

That is common.

It is also the opportunity.

Final thought

Connected GRC is only as strong as its data model.

The data model does not need to be complicated.

But it does need to be connected.

Risks should connect to objectives.
Obligations should connect to policies.
Policies should connect to controls.
Controls should connect to evidence.
Evidence should connect to tests.
Tests should connect to issues.
Issues should connect to remediation.
Remediation should connect to validation.
Incidents should connect to root cause.
Vendors should connect to contracts.
Assets should connect to services.
Audit findings should connect to management action plans.
Regulatory inquiries should connect to evidence.
Dashboards should connect to decisions.

That is the core of the Connected GRC data model.

It turns GRC from disconnected records into a working system.

It helps teams reduce duplicate work.

It helps leaders see what matters.

It helps auditors and regulators follow the evidence trail.

It helps control owners understand accountability.

It helps risk owners see what is changing.

It helps executives make decisions with better context.

That is why every Connected GRC program needs a clear data model.

Not because data modeling is the goal.

Because connected records are what make connected governance possible.