Policy vs Procedure vs Control

What goes wrong when the three are confused?

When policies, procedures, and controls are confused, GRC programs become harder to manage.

A policy may be written but never operationalized.
A procedure may describe work but not manage risk.
A control may exist but not connect to the policy it supports.
Evidence may be collected without anyone knowing what it proves.
Testing may fail because the control was never clearly defined.
An audit finding may identify a control failure when the real issue is an outdated procedure.
A regulatory change may update a policy but leave the control environment unchanged.

What is the simplest difference?

Here is a practical example.

The policy sets the expectation.

The procedure explains the workflow.

The control makes the workflow governable.

What is a policy?

A policy is a formal statement of expectation, requirement, principle, or rule that defines what the organization expects people, teams, systems, vendors, or business processes to do.

Policies are usually designed to:

• communicate expected behavior
• translate obligations into internal requirements
• set boundaries
• assign accountability
• guide decision-making
• support regulatory compliance
• support risk management
• create consistency across the organization

Examples include:

• Code of Conduct
• Information Security Policy
• Access Control Policy
• Privacy Policy
• AI Usage Policy
• Vendor Management Policy
• Business Continuity Policy
• Incident Response Policy
• Records Retention Policy
• Delegation of Authority Policy
• Financial Reporting Policy
• ESG Disclosure Policy

A policy should answer:

• What is required?
• Who does it apply to?
• Why does it exist?
• Who owns it?
• Which obligation, risk, or business need does it address?
• Which controls or procedures make it operational?
• What happens if it is not followed?

The DOJ’s 2024 corporate compliance guidance emphasizes that policies and procedures should address the company’s risks and be accessible, communicated, and incorporated into day-to-day operations.

That last point is important.

A policy is not enough because it exists.

It needs to be operational.

What is a procedure?

A procedure is a documented set of steps that explains how people perform a process, complete a task, follow a policy, operate a control, or respond to a specific situation.

Procedures are usually more detailed than policies.

They describe the work.

Examples include:

• how to perform a user access review
• how to onboard a vendor
• how to handle a privacy request
• how to escalate a security incident
• how to perform a journal entry review
• how to update a business continuity plan
• how to approve an AI use case
• how to collect ESG metric evidence
• how to process a policy exception
• how to close a remediation issue

A procedure should answer:

• What steps are performed?
• Who performs each step?
• When does the procedure run?
• Which systems or tools are used?
• Which approvals are required?
• Which evidence is retained?
• What happens if an exception is found?
• How is the work escalated?
• How is completion documented?

A procedure turns policy into action.

If a policy says, “Access must be reviewed,” the procedure explains how access is reviewed.

If a policy says, “Vendors must be assessed before onboarding,” the procedure explains how intake, due diligence, contract review, approval, and issue tracking happen.

If a policy says, “Privacy incidents must be escalated,” the procedure explains how the incident is triaged, routed, reviewed, evidenced, and remediated.

Procedures are where many GRC programs either become practical or become confusing.

What is a control?

A control is a preventive, detective, corrective, or monitoring activity that helps manage risk, meet an obligation, enforce a policy, validate a procedure, or provide evidence that required work occurred.

Controls are the bridge between intention and assurance.

A policy says what should happen.

A procedure says how people do it.

A control helps prove that it happened correctly.

Examples include:

• access reviews
• change approvals
• reconciliations
• management reviews
• vendor due diligence
• privacy impact assessments
• incident escalation
• vulnerability remediation
• policy attestations
• business continuity testing
• contract approval
• segregation of duties
• backup validation
• ESG metric review
• AI use-case approval
• regulatory change impact assessment

NIST SP 800-53 describes controls as part of an organization-wide risk-management process and provides a catalog of security and privacy controls that organizations can tailor to their context.

A control should answer:

• What risk or obligation does this address?
• Who owns it?
• How often does it operate?
• Is it preventive, detective, corrective, or monitoring?
• What evidence proves it operated?
• How is it tested?
• What happens if it fails?
• Which issue or remediation workflow applies?

A control without evidence is hard to trust.

A control without testing is hard to assess.

A control without an owner is hard to manage.

How do policies, procedures, and controls work together?

The cleanest model is:

Policy → Procedure → Control → Evidence → Testing → Issue → Remediation

This model is simple.

But many organizations do not manage it this way.

The policy sits in a policy tool.
The procedure sits in a shared folder.
The control sits in a control library.
The evidence sits in audit folders.
The test result sits in compliance workpapers.
The issue sits in a spreadsheet.
The remediation evidence sits in email.

Connected GRC brings those records together.

SmartSuite’s Compliance Management page describes connecting frameworks, controls, risks, tests, evidence, policies, and issues for traceability.

That traceability is the point.

Why does the distinction matter in GRC?

The difference between policies, procedures, and controls matters because each one fails differently.

A policy can fail because it is unclear

The policy may be too broad, outdated, hard to find, not approved, not communicated, not mapped to obligations, or not connected to controls.

A procedure can fail because it is impractical

The procedure may be too detailed, too vague, outdated, not aligned with the actual workflow, missing owners, or not followed by the business.

A control can fail because it does not operate

The control may be poorly designed, not performed, performed late, missing evidence, reviewed without enough precision, or disconnected from the risk it is supposed to manage.

If you call everything a policy, you may miss the operational gap.

If you call everything a procedure, you may miss the governance expectation.

If you call everything a control, you may create unnecessary testing burden.

The distinction helps teams fix the right problem.

Example 1: Access management

The policy sets the rule.

The procedure guides execution.

The control proves the review happened and exceptions were handled.

Example 2: Vendor onboarding

This example shows why procedure and control are not the same.

The procedure describes the process.

The control tests whether the required reviews actually happened before onboarding.

Example 3: Privacy incident response

The control is not the entire incident procedure.

It is the specific assurance point that privacy-relevant incidents are routed, reviewed, and evidenced.

Example 4: AI governance

This is where many organizations are today.

They have AI policies.

But the procedure and control model is still maturing.

Connected GRC helps make AI policy operational.

Example 5: Business continuity

Business continuity is a good example because plan documentation alone is not control evidence.

The control proves the plan was reviewed, tested, and improved.

How does a policy differ from a procedure?

A policy and a procedure are often confused.

The distinction is:

Example:

• Policy: Employees must report suspected security incidents promptly.
• Procedure: Employees report through the incident form, security triages the report, privacy is notified if data is involved, and response tasks are assigned.

Policies should not try to explain every step.

Procedures should not redefine the policy.

They should work together.

How does a procedure differ from a control?

Procedures and controls are also often confused.

The distinction is:

Example:

• Procedure: The finance team performs the monthly reconciliation by downloading reports, comparing balances, documenting reconciling items, obtaining manager approval, and storing evidence.
• Control: Monthly reconciliations are reviewed and approved by a manager, with reconciling items documented and resolved.

The procedure explains all the steps.

The control defines the assurance point.

How does a policy differ from a control?

Policies and controls are different but connected.

Example:

• Policy: All third parties must be risk assessed based on the services they provide and data they access.
• Control: Vendors that process sensitive data complete security and privacy due diligence before approval.

A policy without controls may be clear but unenforced.

A control without policy context may feel arbitrary.

Connected GRC links them.

The Connected GRC record model

In a Connected GRC model, each record has a purpose.

This is the practical operating model.

A regulatory obligation may require a policy.
The policy may require a procedure.
The procedure may include a control.
The control may require evidence.
The evidence may be tested.
The test may identify an issue.
The issue may require remediation.
The remediation may require validation.
The dashboard may show status and decisions needed.

That is Connected GRC.

1. Start with the obligation or risk

Policies, procedures, and controls should usually begin with a risk, obligation, or business need.

Examples:

• regulatory requirement
• customer commitment
• contractual obligation
• cyber risk
• privacy risk
• financial reporting risk
• third-party risk
• operational resilience risk
• AI governance risk
• ESG disclosure risk
• internal governance need

Before writing or updating a policy, ask:

• What risk or obligation are we addressing?
• Who is affected?
• What behavior or process needs to change?
• What control will prove the expectation is met?
• What evidence will be required?

This prevents policy creation from becoming document creation.

The goal is not a policy.

The goal is governed behavior.

2. Write policies at the right level

A good policy should be clear enough to guide behavior but not so detailed that it becomes a procedure.

A useful policy includes:

• purpose
• scope
• owner
• audience
• requirements
• responsibilities
• exceptions
• enforcement
• review cycle
• related procedures
• related controls

Avoid writing policies that are:

• too vague
• too technical
• too long
• too procedural
• not connected to risks
• not connected to controls
• not owned
• not reviewed
• not communicated
• not enforceable

The DOJ’s compliance guidance asks whether policies and procedures are designed, updated, accessible, and incorporated into operations.

That is the right test.

A policy should not only exist.

It should work.

3. Write procedures for the people doing the work

A procedure should be usable by the people who perform the task.

A good procedure includes:

• trigger
• steps
• roles
• systems used
• required approvals
• evidence retained
• exception handling
• escalation path
• timing
• related controls
• related policy
• related forms or templates

Avoid procedures that are:

• too generic
• outdated
• not aligned to actual workflow
• missing ownership
• missing evidence expectations
• not connected to controls
• not updated after incidents or audit findings

Procedures should change when the process changes.

If a procedure describes a workflow that no longer exists, it creates risk.

4. Design controls around risk points

Controls should be designed around the points in the workflow where risk needs to be prevented, detected, corrected, monitored, or evidenced.

A good control includes:

• control objective
• control owner
• control performer
• control reviewer
• frequency
• type
• evidence
• related risk
• related policy
• related procedure
• related obligation
• test method
• issue workflow

Common control types include:

• preventive
• detective
• corrective
• monitoring
• manual
• automated
• semi-automated
• key control
• entity-level control
• process-level control
• IT general control
• application control
• vendor control

Controls should not be written only to satisfy a framework.

They should be written to manage real risk.

5. Connect controls to evidence

A control is only as defensible as its evidence.

Evidence should show:

• what happened
• when it happened
• who performed it
• who reviewed it
• what period it covered
• what exceptions were found
• what was done about exceptions
• what conclusion was reached

For example, if the control is a quarterly access review, evidence should show the access population, reviewer, review date, exceptions, removals, and approval.

If the control is vendor due diligence, evidence should show the vendor risk tier, questionnaire, security review, privacy review, contract approval, issues, and final decision.

If the control is policy attestation, evidence should show the policy version, target audience, completion status, exceptions, and escalation.

Evidence is the proof layer.

Without evidence, control operation is difficult to defend.

6. Why test controls, not policies?

A common mistake is testing a policy as if its existence proves compliance.

A policy can be reviewed.

A policy can be approved.

A policy can be attested to.

But most of the time, the organization needs to test the controls that make the policy operational.

For example:

• Do not only test whether the Access Control Policy exists. Test whether access reviews occurred.
• Do not only test whether the Vendor Management Policy exists. Test whether high-risk vendors completed due diligence.
• Do not only test whether the Incident Response Policy exists. Test whether incidents were triaged and escalated.
• Do not only test whether the AI Usage Policy exists. Test whether AI use cases were reviewed before approval.
• Do not only test whether the Business Continuity Policy exists. Test whether plans were tested and issues remediated.

Policy existence is not enough.

Control operation is what proves the policy is working.

7. Use issues to connect failure back to the right layer

When something fails, identify which layer failed.

This helps teams remediate properly.

A failed access review might not require a new policy.

It might require a better procedure, corrected report logic, control owner training, or a redesigned control.

A vendor onboarding failure might not require rewriting the vendor policy.

It might require intake routing, evidence standards, or approval gating.

Connected GRC helps identify the right fix.

8. Connect all three to dashboards

A GRC dashboard should show whether policies, procedures, and controls are working together.

Useful views include:

A dashboard should not only show policy publication or control testing completion.

It should show whether the written rule, actual workflow, and assurance mechanism are aligned.

Common mistakes to avoid

Mistake 1: Treating policies as procedures

A policy should not describe every step of the workflow.

Keep policies clear, durable, and expectation-focused.

Use procedures for detailed execution.

Mistake 2: Treating procedures as controls

A procedure describes the process.

A control is the risk-management or assurance point inside that process.

Not every procedure step is a control.

Mistake 3: Treating policy existence as proof of compliance

A policy is not proof that the organization follows the policy.

Controls, evidence, testing, and issues provide that proof.

Mistake 4: Writing controls that are too vague

A control should be specific enough to operate, evidence, and test.

“Access is managed” is not a strong control.

Mistake 5: Updating policies without updating procedures and controls

A policy update may require workflow changes, control updates, training, attestation, evidence changes, and testing updates.

Mistake 6: Updating procedures without updating controls

If the workflow changes, the control may need to change too.

Otherwise, testing may evaluate an outdated process.

Mistake 7: Managing policies, procedures, and controls in separate systems

Separate systems create traceability gaps.

Connected GRC links the rule, workflow, control, evidence, issue, and reporting.

A practical test for your GRC model

Pick one important policy.

Then ask whether your current GRC model can quickly show:

• policy owner
• current policy version
• related obligations
• related risks
• related procedures
• related controls
• control owners
• evidence required
• latest test results
• policy attestations
• policy exceptions
• open issues
• failed controls
• remediation plans
• validation evidence
• dashboard status
• decisions needed

If answering those questions requires policy folders, procedure documents, control matrices, evidence folders, audit workpapers, spreadsheets, and meetings, the model is not connected enough.

That is common.

It is also the opportunity.

Final thought

Policies, procedures, and controls are different, but they should not be disconnected.

A policy defines the expectation.

A procedure explains how work is performed.

A control proves, enforces, monitors, or validates that the expectation is being met.

Evidence supports the control.
Testing evaluates the evidence.
Issues track failures.
Remediation fixes the gap.
Validation proves the fix worked.
Dashboards show what needs attention.

Connected GRC gives these pieces one operating model.

It helps policy owners understand how policies become real.

It helps control owners know what evidence is required.

It helps compliance teams test the right things.

It helps internal audit evaluate whether governance is working.

It helps executives see whether written expectations are actually operating.

That is the practical difference between policy, procedure, and control in GRC.

And it is why they need to be connected.