Policies and Procedures: What's the Difference?

Compliance programs live or die by the distinction between policies and procedures. They sound interchangeable — they're not. Here's how to think about each, why auditors expect both, and where they fit in frameworks like SOC 2, HIPAA, and ISO 27001.

The short version

A policy without a procedure is aspirational. A procedure without a policy is uncontrolled. Audit-ready programs ship them as a pair.

What a policy looks like

A policy is high-level governance. It's approved by leadership, reviewed annually, and rarely changes more than once a year. It assigns ownership, sets boundaries, and references the controls (e.g., SOC 2 CC6.1, ISO 27001 A.9.2) that it satisfies.

Example — Access Control Policy: "All production systems require multi-factor authentication. Access is granted on a least-privilege basis and reviewed quarterly by the system owner."

What a procedure looks like

A procedure is operational. It tells the on-call engineer, the HR generalist, or the IT admin exactly what to do — usually as a numbered checklist with screenshots, ticket templates, or commands.

Example — Access Provisioning Procedure: "1. Manager opens an access request in Jira. 2. IT verifies role mapping. 3. IT enables the user in Okta and assigns the required groups. 4. IT attaches the ticket to the quarterly access review log."

Why auditors want both

Frameworks like SOC 2, ISO 27001, HIPAA, and NIST 800-53 evaluate two things: design (does the rule exist?) and operating effectiveness (is it actually followed?). Policies are evidence of design. Procedures — and the artifacts they produce — are evidence of operation. You need both to pass.

How PolicyForge handles the pair

PolicyForge generates a matched library: every policy ships with the procedures it depends on, and every clause carries the framework control numbers it satisfies. When a control changes, both the policy and procedure update together, and your team attests in a single click.