How to Connect Regulatory Obligations to Policies, Controls, and Evidence

Regulatory obligations are not useful if they only live in a tracker.

A requirement can be identified.
Reviewed.
Interpreted.
Logged.
Tagged.
Assigned a status.
Added to a dashboard.

But none of that proves the organization is ready.

The real work starts after the obligation is identified.

What policy translates the obligation into an internal rule?
What control makes the rule operational?
Who owns the control?
What evidence proves the control worked?
How is the control tested?
What happens if evidence is missing?
What issue is created if the control fails?
How does the organization prove remediation?
What response would be provided during an audit or regulatory inquiry?

That is the obligation-to-policy-to-control-to-evidence chain.

It is one of the most important relationships in a Connected GRC program.

Without it, compliance teams manage requirements.
With it, organizations manage compliance.

What does it mean to connect regulatory obligations to policies, controls, and evidence?

Connecting regulatory obligations to policies, controls, and evidence means translating external requirements into internal expectations, operational controls, proof, testing, issue remediation, and reporting.

A connected obligation should answer:

• What regulation, standard, contract, or commitment created the obligation?
• Does the obligation apply to us?
• Which business units, products, services, systems, vendors, or regions are affected?
• Which policy or procedure translates the obligation into internal expectations?
• Which controls satisfy or enforce the obligation?
• Who owns those controls?
• What evidence proves the controls operated?
• How is evidence reviewed?
• How are controls tested?
• What issues exist?
• What remediation is underway?
• What would we provide during an audit, exam, or regulatory inquiry?

A disconnected obligation tells you what the organization may need to do.

A connected obligation shows what the organization is doing about it.

That is the difference.

Why obligation mapping matters

Obligation mapping is where compliance becomes operational.

A regulation may be written in broad language. A policy may turn that language into internal expectations. A control may turn expectations into repeatable work. Evidence may prove the work happened. Testing may show whether the work was effective. Issues may track what failed. Remediation may fix the gap.

This is why GRC cannot be treated as a collection of isolated records. OCEG’s definition of GRC emphasizes integrated capabilities that help an organization achieve objectives, address uncertainty, and act with integrity. Obligation mapping is one of the places where that integration becomes practical.  

A connected obligation helps teams avoid common problems:

• policies that are not tied to regulatory requirements
• controls that do not clearly support obligations
• evidence that exists but does not prove compliance
• regulatory changes that do not trigger control updates
• inquiries that require manual evidence reconstruction
• issue remediation that does not close the compliance gap
• dashboards that show compliance activity but not readiness

Obligations should not be treated as legal references only.

They should become working records.

The obligation connection map

A regulatory obligation should connect to the internal records that make it actionable.

The obligation itself is only the starting point.

The connections are what make it governable.

1. Start with the source of the obligation

Every obligation needs a source.

The source may be:

• law
• regulation
• regulator guidance
• supervisory expectation
• enforcement trend
• industry standard
• contract
• customer commitment
• data-processing agreement
• internal policy
• board directive
• certification framework
• ESG disclosure requirement
• AI governance requirement
• cyber requirement
• privacy requirement
• SOX or financial reporting requirement

A connected obligation record should include:

• source name
• jurisdiction
• regulator or authority
• section or citation
• effective date
• applicability date
• obligation owner
• interpretation owner
• affected business areas
• current status
• related regulatory change
• supporting evidence

This matters because obligations are often challenged later.

A regulator, auditor, customer, executive, or internal reviewer may ask:

“Why did we determine this applies, and what did we do about it?”

The source record should preserve that trail.

2. Separate the obligation from the regulation

A regulation is usually larger than an obligation.

One regulation may create many obligations.

For example, a regulation may require:

• governance oversight
• risk assessment
• policy updates
• customer notice
• incident reporting
• record retention
• vendor oversight
• control testing
• employee training
• board reporting
• evidence retention

Each obligation should be translated into a clear internal requirement.

A weak obligation record says:

“Comply with data protection requirements.”

A stronger obligation record says:

“High-risk processing activities must be assessed before launch, with documented privacy review, business owner approval, control requirements, and retained evidence.”

The second version can be mapped to policies, controls, evidence, testing, and issues.

The first version cannot.

Obligations should be specific enough to operationalize.

3. Document applicability and rationale

Not every external requirement applies to every organization, entity, product, region, or process.

Applicability should be documented.

A connected applicability review should answer:

• Does this obligation apply?
• Why or why not?
• Which legal entities are affected?
• Which business units are affected?
• Which products or services are affected?
• Which processes are affected?
• Which systems are affected?
• Which vendors are affected?
• Which regions are affected?
• Who made the decision?
• What evidence supports the decision?
• When should the decision be reviewed?

Applicability decisions should not live only in email or legal notes.

They are compliance records.

If the organization later needs to explain why it did or did not implement a requirement, the applicability rationale matters.

4. Connect obligations to business impact

Obligations become real when they affect operations.

A regulatory obligation may affect:

• customer onboarding
• vendor onboarding
• product launch
• data processing
• AI use
• financial reporting
• cyber incident response
• privacy incident response
• business continuity planning
• ESG reporting
• employee training
• contract language
• access management
• reporting processes
• board materials
• customer communications

A connected obligation should show the business impact.

Useful fields include:

• affected business unit
• affected process
• affected product or service
• affected system
• affected data
• affected vendor
• affected contract
• affected control
• affected policy
• affected reporting requirement
• affected evidence requirement

This is where many compliance programs break down.

They identify the obligation but do not connect it to the business process that must change.

Connected GRC closes that gap.

5. Map obligations to policies

Policies translate obligations into internal expectations.

A policy should answer:

• What does the organization expect?
• Who must follow it?
• Which roles are responsible?
• What activities are required?
• What exceptions are allowed?
• What approvals are needed?
• What evidence must be retained?
• What happens if the policy is not followed?

The DOJ’s 2024 compliance-program guidance asks whether policies and procedures are designed, updated for emerging risks, accessible, operationally integrated, and reinforced through internal control systems. That is the right standard for obligation-to-policy mapping: a policy should not only exist; it should be current, practical, communicated, and tied to controls.  

A connected policy mapping should show:

• obligation
• policy name
• policy section
• policy owner
• version
• effective date
• approval history
• audience
• attestation requirement
• training requirement
• related controls
• related issues
• related regulatory changes

A policy should not be mapped loosely.

If a policy supports an obligation, the relevant section should be clear.

Example: obligation to policy

Obligation: The organization must maintain appropriate controls over access to systems containing sensitive information.

Policy: Access Management Policy.

Policy section: Access reviews must be performed periodically by system owners for systems containing sensitive or regulated data.

Connected records: Access review control, evidence requirement, testing procedure, issue workflow, training, regulatory inquiry evidence.

This is how the obligation becomes an internal rule.

6. Map policies to procedures

Policies often define what must happen.

Procedures explain how it happens.

This distinction matters.

A policy may say:

“Access to sensitive systems must be reviewed periodically.”

A procedure should explain:

• which systems are in scope
• who generates the access report
• how the population is validated
• who reviews access
• how exceptions are documented
• how exceptions are remediated
• where evidence is stored
• when the review is due
• who escalates overdue reviews

A connected procedure record should show:

• related policy
• related obligation
• business process
• procedure owner
• control supported
• evidence created
• issue path
• last review date
• version history

Policies without procedures may be hard to follow.

Procedures without policy context may be hard to govern.

Connected GRC links both.

7. Map obligations and policies to controls

Controls are where obligations and policies become operating discipline.

A control may:

• prevent noncompliance
• detect a gap
• correct a problem
• monitor an obligation
• document review
• enforce approval
• produce evidence
• trigger escalation
• support audit or inquiry response

A connected control record should include:

• control objective
• related obligation
• related policy
• control owner
• performer
• reviewer
• frequency
• evidence requirement
• test method
• framework mappings
• issue path
• remediation requirement
• validation requirement

SmartSuite’s Compliance Management materials describe centralizing policies, regulatory obligations, control libraries, testing activities, and evidence in one connected workspace, and linking compliance requirements to controls, assessments, and remediation actions. That is the operating model obligation mapping should support.  

The control is the bridge between the written rule and proof.

Example: policy to control

Policy statement: High-risk vendors must complete security and privacy review before contract approval.

Control: Vendor intake workflow routes high-risk vendors to cyber and privacy reviewers before contract execution.

Evidence: Completed security review, completed privacy review, risk rating, reviewer approvals, open issues, contract approval record.

Issue path: Missing review creates a vendor onboarding issue and blocks or conditions approval.

That is a connected obligation-to-policy-to-control workflow.

8. Define evidence requirements for each control

Evidence proves that the control operated.

A control without evidence is hard to defend.

Evidence requirements should be specific.

They should include:

• evidence type
• source system
• required period
• evidence owner
• reviewer
• acceptable format
• required fields
• approval requirement
• completeness criteria
• accuracy criteria
• retention requirement
• reuse rules

Examples of evidence include:

• approval records
• access review reports
• exception logs
• remediation evidence
• policy approval history
• attestation logs
• training records
• vendor certifications
• contract clauses
• risk assessment records
• privacy assessment records
• incident timelines
• system change tickets
• ESG source data
• AI governance approvals
• SOX testing evidence
• audit validation records

Evidence should connect to the control, not sit in a generic folder.

A file without context is storage.

A file connected to an obligation, policy, control, period, owner, and reviewer is evidence.

9. Connect evidence to testing

Evidence collection is not the same as testing.

Testing evaluates whether the evidence supports the control and whether the control operated as intended.

A connected testing record should include:

• control tested
• obligation supported
• policy supported
• evidence reviewed
• test period
• test procedure
• reviewer
• conclusion
• exception
• issue created
• remediation requirement
• retesting requirement

This matters because evidence may be incomplete.

A control owner may upload evidence, but the reviewer may find that:

• the wrong period was covered
• population was incomplete
• approval was missing
• exceptions were not remediated
• the evidence did not match the control
• the control was performed late
• the control was not performed at all

Testing turns evidence into a conclusion.

That conclusion should feed issue management and reporting.

10. Connect failed tests to issues

If a test fails, the obligation may not be fully supported.

A failed test should create an issue when material.

The issue should connect to:

• obligation
• policy
• control
• evidence
• test result
• root cause
• owner
• due date
• remediation plan
• closure evidence
• validation requirement
• residual risk impact

A weak issue says:

“Control failed.”

A stronger issue says:

“The access review control supporting the Access Management Policy and data protection obligation failed because the evidence did not include the full user population. The system owner must update report parameters, rerun the review, document exception remediation, and submit evidence for retesting.”

The second issue can be remediated.

The first issue only describes a problem.

Connected GRC should turn failed tests into work.

11. Connect issues to remediation and validation

A compliance issue is not closed because someone updates the status.

It is closed when the organization can show:

• the root cause was addressed
• remediation was completed
• evidence was provided
• evidence was reviewed
• retesting occurred where needed
• closure was validated
• residual risk was updated where relevant

A connected remediation record should include:

• remediation owner
• action plan
• milestones
• dependencies
• due date
• closure evidence
• validation owner
• validation result
• escalation status
• risk impact

This is especially important for regulatory obligations.

A regulator may ask not only whether a gap was identified, but whether it was fixed.

The evidence trail should already exist.

12. Connect obligations to regulatory change

Regulatory obligations are not static.

They change.

A new regulatory update may:

• create new obligations
• change existing obligations
• retire obligations
• change evidence expectations
• require new controls
• require policy updates
• affect vendors
• affect systems
• affect reporting
• create remediation work

A connected regulatory change workflow should show:

• regulatory update
• applicability review
• affected obligations
• affected policies
• affected controls
• affected evidence
• affected testing
• issues created
• owners assigned
• readiness status

Regulatory change should not be a separate tracker.

It should update the obligation-to-policy-to-control-to-evidence chain.

That is how change becomes action.

13. Connect obligations to regulatory inquiries

Regulators often ask for proof that obligations are implemented.

A connected inquiry workflow should be able to pull:

• obligation
• source
• applicability decision
• policy
• control
• evidence
• testing result
• issue history
• remediation status
• approvals
• prior responses

A regulatory inquiry should not require the team to rebuild the compliance story from scratch.

The story should already exist in connected records.

For example:

Request: Provide evidence that high-risk vendors are reviewed before onboarding.

A connected response can show:

• applicable obligation
• vendor management policy
• high-risk vendor intake control
• evidence of completed reviews
• testing results
• issues for incomplete reviews
• remediation status
• response approval history

That is much stronger than sending a policy and hoping it is enough.

14. Connect obligations across domains

Obligations do not live only in compliance.

They touch many domains.

Privacy

Obligations may connect to data inventories, DPIAs, DSAR workflows, breach response, vendor terms, retention, and evidence.

Relevant links:

• Privacy Management
• Privacy Risk Management
• Policy Management
• Incident Management

Cyber

Obligations may connect to access controls, vulnerability management, incident response, logging, vendor security, board reporting, and evidence.

Relevant links:

• Cyber & IT Risk
• Cyber Threat Management
• Vulnerability Management (GRC)
• Control Framework & Regulatory Libraries

AI governance

Obligations may connect to AI inventories, risk assessments, policy controls, data review, human oversight, monitoring, and evidence.

Relevant links:

• AI Governance
• CRI AI RMF
• Policy Management
• Issues Management

ESG

Obligations may connect to ESG metrics, source data, disclosure controls, supplier evidence, assurance readiness, and board reporting.

Relevant links:

• ESG Management
• ESG & Sustainability Management
• Compliance Assessments & Testing
• Internal Audit Management

SOX

Obligations may connect to financial reporting controls, ITGCs, evidence, testing, deficiencies, remediation, and audit committee reporting.

Relevant links:

• SOX Management
• SOX Compliance
• Internal Audit Management
• Control Framework & Regulatory Libraries

Operational resilience

Obligations may connect to critical services, BIAs, continuity plans, incident response, vendor dependencies, recovery evidence, and crisis management.

Relevant links:

• Operational Resilience & Business Continuity
• Business Impact Analysis
• Incident Management
• Crisis Management

A connected obligation model lets each domain specialize without creating disconnected compliance records.

15. Use a standard obligation record

A standard obligation record should include:

This record becomes the hub for compliance traceability.

16. Build dashboards around readiness, not obligation volume

Obligation dashboards often show volume:

• obligations identified
• obligations mapped
• obligations under review
• obligations by jurisdiction
• obligations by regulation

Those metrics can help.

But readiness matters more.

A connected obligation dashboard should show:

The dashboard should answer:

• Are we ready?
• Where are gaps?
• Who owns them?
• What evidence exists?
• What issues remain open?
• What decisions are needed?

That is obligation reporting in Connected GRC.

17. Avoid one-to-one thinking

One obligation may map to many controls.

One control may map to many obligations.

One policy may support many obligations.

One piece of evidence may support many controls or frameworks.

One issue may affect several obligations.

That is why mapping must be relational.

Avoid assuming:

• one regulation equals one obligation
• one obligation equals one policy
• one policy equals one control
• one control equals one evidence item
• one issue affects only one obligation

Connected GRC works because it handles many-to-many relationships.

That is especially important for common controls and reusable evidence.

18. Make obligation mapping practical for business users

Business users should not need to read regulatory text to understand what they must do.

A good obligation mapping translates the requirement into practical work.

Instead of showing a business owner:

“Comply with Section X.”

Show:

“Your team must complete a documented review before launching this process because it uses sensitive data and involves a third-party system. Required evidence includes assessment approval, vendor review, control owner signoff, and remediation closure for any open issues.”

That is operational.

Compliance teams can maintain the regulatory detail.

Business owners need actionable obligations.

Connected GRC should support both views.

19. How the conversation changes

A disconnected obligation conversation sounds like this:

“The obligation has been added to the tracker. The policy has been updated. We are following up with control owners on implementation.”

A connected obligation conversation sounds like this:

“The obligation applies to two business units and three processes. It maps to one policy section, four controls, and six evidence requirements. Two controls already exist and are mapped to SOC 2 and privacy. One new control is needed for vendor notification. Testing is scheduled, and one issue is open because contract language must be updated before full readiness can be confirmed.”

The second conversation is better.

It connects applicability, business impact, policy, controls, evidence, testing, issues, vendor contract updates, and readiness.

That is how obligation management should work.

Where to start

Organizations do not need to map every obligation at once.

Start where the risk is highest.

Start with high-risk obligations

Map obligations tied to regulatory exposure, customer commitments, sensitive data, financial reporting, critical services, or board oversight.

Relevant links:

• Regulatory Change Management
• Control Framework & Regulatory Libraries
• Compliance Assessments & Testing
• Issues Management

Start with policies that support many obligations

Map major policies to obligations and controls.

Relevant links:

• Policy Management
• Control Framework & Regulatory Libraries
• Regulatory Inquiries
• Compliance Management

Start with controls used across frameworks

Map common controls to obligations, frameworks, evidence, and testing.

Relevant links:

• Control Framework & Regulatory Libraries
• Unified Risk and Compliance Workflows
• SOC 2 Compliance
• SOX Compliance

Start with regulatory inquiries

Use recent inquiries to identify which obligations, policies, controls, and evidence need better connection.

Relevant links:

• Regulatory Inquiries
• Compliance Assessments & Testing
• Policy Management
• Issues Management

Start with failed tests

If controls are failing, trace them back to obligations and policies.

Relevant links:

• Compliance Assessments & Testing
• Issues Management
• How Controls Connect Risk, Compliance, Audit, and Remediation
• Internal Audit Management

The best starting point is the obligation area where the organization currently has the weakest proof.

Common mistakes to avoid

Mistake 1: Treating obligations as legal references only

Obligations should connect to policies, controls, evidence, testing, and issues.

Mistake 2: Mapping obligations to policies but not controls

A policy does not prove compliance by itself.

Controls and evidence are needed.

Mistake 3: Creating new controls before checking existing controls

An existing control may already satisfy the obligation or may need only a small update.

Mistake 4: Ignoring evidence requirements

If evidence is not defined, compliance readiness will be hard to prove.

Mistake 5: Failing to update mappings after regulatory change

Obligation mappings should be reviewed when requirements, policies, controls, or business processes change.

Mistake 6: Making mapping too abstract for the business

Business users need practical requirements, not only regulatory citations.

Mistake 7: Treating mapping as a one-time project

Mapping is a living workflow.

Obligations, policies, controls, and evidence change over time.

A practical test for your obligation mapping

Pick one important obligation.

Then ask whether your current GRC model can quickly show:

• source regulation or standard
• applicability decision
• applicability rationale
• affected business units
• affected processes
• affected systems
• affected vendors
• policy mapping
• policy owner
• control mapping
• control owners
• evidence requirements
• evidence status
• latest test results
• open issues
• remediation plans
• regulatory change history
• inquiry response history
• reporting status
• decisions needed

If answering those questions requires legal memos, policy files, control matrices, evidence folders, issue trackers, spreadsheets, and meetings, the obligation is not connected enough.

That is common.

It is also the opportunity.

Final thought

Regulatory obligations do not manage themselves.

They need to become internal expectations, operating controls, evidence requirements, testing workflows, remediation actions, and reporting signals.

That requires connection.

Obligation to policy.
Policy to procedure.
Procedure to control.
Control to evidence.
Evidence to testing.
Testing to issue.
Issue to remediation.
Remediation to validation.
Validation to reporting.

That is the obligation chain in a Connected GRC program.

When the chain is broken, compliance becomes hard to prove.

When the chain is connected, the organization can show not only what applies, but what it did, who owns it, what evidence exists, what failed, what was fixed, and what decisions remain.

That is how to connect regulatory obligations to policies, controls, and evidence.