A policy states what the organization intends. A procedure gives the steps to do it. A control objective is the outcome you want, tied to a risk. A control activity is the specific thing that runs to reach it. Mixing them up is the most common reason narratives and evidence fail to line up.
One example, four layers
Take unauthorized code changes.
| Layer | What it says | Example |
|---|---|---|
| Policy | Intent, in management's voice | "All production changes must be reviewed and approved before release." |
| Control objective | The outcome, tied to a risk | "Only reviewed and approved changes reach production." |
| Control activity | What runs | "Branch protection requires one approval from a non-author on the main branch." |
| Procedure | How people do it | "Open a PR, request review from the code owner, merge when checks pass, follow the emergency path for incidents." |
Evidence belongs to the activity: the approval records, the settings, the exception list.
Why the difference matters
- A policy with no activities is a promise nobody keeps.
- An activity with no objective is busywork, and nobody can tell if it is enough.
- An objective with only one weak activity is a risk you are carrying.
- A procedure that differs from the activity means staff do one thing and the system does another.
Auditors test activities against objectives. They read policies to see intent and procedures to see how people work, then check that all four agree.
Steps to tidy your own set
- List your policies. For each, pick two or three objectives.
- For each objective, name the activities. Mark each as preventive, detective or corrective.
- For each activity, write the owner, frequency and evidence source.
- Check that procedures match what activities actually do.
- Note any objective with no activity, and any activity with no objective.
Common confusions
- Calling a tool a control. A scanner is a tool. Running it on every build and triaging results is the activity.
- Writing objectives as activities. "Review code" is an activity. "Prevent unreviewed code reaching production" is the objective.
- Policies that describe tools. Tools change. Policies should outlive them.
- Procedures nobody reads. Keep them short and near the work.
Mapping to frameworks
Frameworks mostly speak in objectives and criteria. NIST's change control text, for example, asks for documented decisions and retained records, not for a specific tool. Your activities are how you meet that. One activity can serve several objectives and several frameworks, which is why a clean mapping saves work later.
Try it yourself
Click through it at your own pace, or open it full screen. Follow one requirement down to the activity and evidence that would satisfy it.
Quick check
Is a runbook a procedure or a control?
A procedure. The control is the part that is enforced or checked, such as the approval gate the runbook refers to.
Can one activity satisfy several objectives?
Yes. Document it once and map it to each objective.
Safeguard compliance and evidence automation maps scan and review records to framework controls. A free scan is available.
Sources
Last reviewed: 19 October 2026.
