What is the difference between a policy and a procedure in GRC mapping?

Why Policy and Procedure Map to Different GRC Artifacts

Policy is the governing layer. It defines the rule, expectation, or control intent that a business or security programme wants to enforce. Procedure is the execution layer. It translates that intent into repeatable steps, ownership, and sequencing so people can carry the rule out consistently and prove they did so.

The distinction matters because GRC mapping is not just about finding a related document, it is about mapping the right artifact to the right control need. A control that requires accountability, approval, or a stated requirement usually maps to policy, while a control that requires operational consistency, evidence capture, or task completion often maps to procedure. ISO/IEC 27002:2022 Information Security Controls is useful here because it distinguishes control intent from implementation guidance in a way that mirrors this split.

In practice, the two artifacts are complementary, not interchangeable. A policy can tell you what must happen, such as access approval before production changes. A procedure can tell you how that approval is obtained, recorded, and reviewed. If teams collapse both into one document, they often create either vague policy that is hard to audit, or procedural clutter that is difficult to govern.

How to Tell Which Artifact Supports the Control

Use the control statement as the deciding test. If the control asks for a principle, standard, mandate, or accountable expectation, it belongs with policy. If it asks for an operational method, sequence, checklist, or implementation step, it belongs with procedure. The same control family can legitimately have both, but they should not be treated as the same evidence object.

This also helps when requirements change. Policy usually changes less often and should be reviewed by the control owner or governance function. Procedure changes more often because it tracks tooling, workflows, handoffs, and evidence capture. That separation reduces the chance of rewriting the governing rule every time a team improves an operational step.

For mapping purposes, the strongest signal is whether the artifact answers “what must be true” or “how we do it.” Policy answers the first. Procedure answers the second. When a single document mixes both, you may still map it to a control, but auditors and practitioners will generally prefer to see the governance statement separated from the working instructions.

What Good GRC Mapping Looks Like in Practice

Good mapping is precise enough that another reviewer can tell why the artifact was chosen. A policy should be able to stand on its own as the approved requirement, while a procedure should be able to stand on its own as the repeatable operational method. Where there is a control objective, map both if both are needed, but avoid using one artifact as a substitute for the other.

That separation becomes especially valuable when evidence is reviewed. Policy usually supports approval, authority, and scope. Procedure usually supports execution evidence, timestamps, logs, tickets, or workflow records. If the evidence only shows that a process ran, it does not prove the governing expectation was defined. If the policy exists but no procedure exists, the control may be approved in principle but weak in execution.

For broader GRC programmes, this distinction also makes control maintenance cleaner. A governance change may require a policy update, while a tooling or workflow change may require a procedure update. Teams that track both artifacts distinctly usually find it easier to assign ownership and update the right document without creating unnecessary review churn.

Practitioner Guidance

What to verify: Confirm whether the control owner wants a governing statement, an operational instruction, or both. If the artifact is expected to prove intent, approve or revise the policy; if it is expected to prove repeatability, inspect the procedure and the evidence it produces.

Common mistake: Do not treat a detailed runbook as policy just because it is authoritative, and do not treat a one-line policy as sufficient evidence of implementation. In audits, that mix-up is one of the fastest ways to create gaps between control design and control operation.

What good looks like: The policy is concise, approved, and stable enough to express intent, while the procedure is current, executable, and clearly tied to the actual workflow. Together they show both governance and execution without forcing one document to do both jobs.

Practitioner takeaway: Separate the rule from the method, then map each artifact to the control purpose it actually serves. That discipline produces cleaner evidence, clearer ownership, and fewer update mistakes when requirements or workflows change.

Related resources from NHI Mgmt Group

• What is the difference between attack surface management and NHI governance?
• What is the difference between reviewing human access and reviewing NHIs?
• What is the difference between role-based access and API key governance for NHI security?
• What is the difference between human IAM controls and NHI governance?