The four levels
| Level | Answers | Audience | Approved by | Trigger for change |
|---|---|---|---|---|
| Top-level policy | Why, and to what standard | The whole organisation | Top management | Rarely, on strategic change |
| Policy | What applies, who is responsible, which requirements are binding | The roles affected | Top management or a designated function | Changed requirements |
| Procedure | How the flow runs, with steps, responsibilities and decision points | The roles performing it | Process owner | Process changes |
| Work instruction and form | With what, and to what result, a single activity is performed | The performing unit | Subject matter owner | Often, for instance on a change of tool |
Below these levels sit the records: the evidence that work was actually done this way.
A note on vocabulary, because it causes trouble in bilingual documentation sets. English uses "policy" for both of the top two levels: the single overarching policy top management signs, and the topic policies derived from it. German separates them as Leitlinie and Richtlinie. Where a group works in both languages, decide which English word carries which level and hold to it. Otherwise the approval authority for a document becomes a matter of opinion.
The practical value of the separation
Put tool names and click paths in a policy, and the policy has to be re-approved on every change of tool, in case of doubt by top management. Put the requirement in the policy and the click path in the work instruction, and only the lower document changes. That is not formalism; it is the difference between a maintained rulebook and an outdated one.
As a rule of thumb: a policy should survive a change of tool. A procedure should survive a change of staff.
What belongs in every policy
Purpose, scope, audience, the binding requirements, roles and responsibilities, the procedure for exceptions, references to co-applicable documents, and a header carrying version, date, approval, the responsible unit and the date of the next review.
The item most often missing is the exception procedure. Without a governed exception, either a silent breach arises that nobody documents, or a blockage arises that holds the business up. A good provision names the deciding authority, the time limit, and the documentation of the reasoning.
Control of documented information
The ISO management system standards require, in clause 7.5, that documented information is appropriately identified, reviewed, approved, distributed and protected against unintended alteration, and that obsolete versions are identifiable. That means a single binding source instead of copies on drives and in mailboxes, a version history, a traceable approval, controlled access, and an orderly withdrawal of superseded documents.
Approval alone does not create bindingness
An approved document nobody knows about has no effect. What it takes is active announcement rather than quiet filing, training on material changes, a documented acknowledgement where direct obligations for employees are created, and a check of actual application in the internal audit. Where a rule touches the conduct or performance of employees, co-determination rights may apply; participation should be clarified early.
How a rulebook goes stale
- The policy describes a tool and goes stale with it.
- The procedure has no named owner.
- Two documents govern the same matter inconsistently.
- A document has applied unchanged for years and has never been reviewed.
- The rulebook grows without superseded versions being withdrawn.
- Exceptions are granted orally and recorded nowhere.