What is the difference between a governance policy and a procedure?

A governance policy and a procedure are not the same thing, and treating them as interchangeable is one of the most common mistakes organisations make when building their governance framework. A policy defines what must be achieved and why, while a procedure defines how to achieve it, step by step. Policies set the rules; procedures operationalise them. This distinction matters for every organisation subject to frameworks like ISO 27001, GDPR, NIS2, or the EU AI Act, because regulators assess both layers independently. If you want to talk through how this applies to your organisation, feel free to get in touch with us. The sections below unpack the most common questions around this distinction, including when to update each, and what goes wrong when they fall out of sync.

Why can’t a policy replace a procedure?

A policy cannot replace a procedure because it operates at a different level of specificity. Policies express intent and set boundaries; they tell people what is required and why it matters. Procedures translate that intent into repeatable, actionable steps that staff can follow in real situations. Without a procedure, a policy remains abstract and unenforceable in practice.

Consider a data breach response policy. It might state that all personal data incidents must be reported within 72 hours in line with GDPR obligations. That is a clear, enforceable rule. But it tells nobody who makes the first call, which system to log the incident in, who assesses severity, or what the escalation path looks like. A procedure fills every one of those gaps. Without it, two employees facing the same incident will handle it differently, and neither may meet the 72-hour window.

This is why continuous governance depends on maintaining both layers in parallel. A policy that lacks a supporting procedure is governance on paper only. It creates the illusion of control without the operational substance that makes control real.

What makes a governance policy a policy?

A governance policy is a formal statement of intent, direction, and mandatory requirements set by management. It defines the scope of a governance domain, the principles that apply within it, and the obligations that employees or the organisation must meet. A policy answers the questions: what is required, who is responsible at an ownership level, and why this requirement exists.

Policies share several defining characteristics that distinguish them from other governance documents:

Authority: Policies are approved and owned by senior management or the board. They carry organisational weight.
Scope: They define which parts of the organisation, which activities, or which assets they apply to.
Obligation language: Policies use terms like “must,” “shall,” and “is required” rather than “should” or “may.”
Stability: Policies change infrequently. They reflect strategic intent, not day-to-day operations.
Accountability: Policies assign ownership at a role level, not at an individual task level.

In a mature governance framework, policies sit at the top of a document hierarchy. They are supported by standards, procedures, and guidelines, each of which adds a different kind of detail. A policy on information security, for example, might be a single page that establishes management commitment and core obligations. Everything beneath it builds from that foundation.

What makes a procedure a procedure?

A procedure is a documented, step-by-step description of how a specific activity must be carried out. It translates policy requirements into operational instructions that are specific enough for a trained employee to follow without ambiguity. A procedure answers the questions: who does what, in what order, using which tools or systems, and under what conditions.

Good procedures share a consistent set of characteristics:

Specificity: Each step is concrete and actionable, not vague or open to interpretation.
Sequence: Steps are ordered logically, reflecting how the activity actually unfolds.
Role clarity: Each step names the role responsible for completing it, not a named individual.
Trigger and outcome: A procedure states what initiates it and what a successful completion looks like.
Traceability: Procedures reference the policy or standard they implement, creating a clear audit trail.

Procedures are living documents in a way that policies are not. They need to reflect current tools, current team structures, and current regulatory requirements. When an organisation changes its incident management platform, the relevant procedures must be updated immediately. The policy above them may not need to change at all.

How do policies and procedures relate to standards and guidelines?

Policies, standards, procedures, and guidelines form a four-layer governance document hierarchy, each serving a distinct purpose. Policies set mandatory direction at the top. Standards define specific, measurable requirements that support a policy. Procedures describe how to meet those requirements operationally. Guidelines offer recommended approaches that are advisory rather than mandatory.

Understanding where each document type sits prevents the common mistake of writing a single document that tries to do all four jobs at once, which produces something too detailed to be a policy and too vague to be a procedure.

Standards: the bridge between policy and procedure

A standard fills the gap between a high-level policy and a step-by-step procedure. Where a policy might require that all sensitive data be encrypted, a standard specifies the minimum encryption algorithm, key length, and storage requirements. Standards are mandatory, like policies, but they are technical or operational rather than strategic. They give procedures the precise requirements they need to implement.

Guidelines: structured flexibility

Guidelines are the only layer in the hierarchy that is advisory. They describe recommended approaches, best practices, or preferred methods without imposing a hard obligation. An organisation might have a guideline on how to write clear email communications or how to structure a risk assessment narrative. Deviating from a guideline does not constitute a breach; deviating from a policy or standard does. This distinction matters when governance documents are reviewed during audits or regulatory assessments.

When should an organisation update a policy versus a procedure?

An organisation should update a policy when its strategic intent, regulatory obligations, or organisational scope changes. It should update a procedure when the operational steps, tools, systems, or roles involved in an activity change. These triggers are different, and confusing them leads to either over-engineering policies or leaving procedures dangerously out of date.

Practical triggers for a policy update include:

A new regulation enters into force that changes mandatory obligations (such as NIS2 or the EU AI Act in 2026)
A significant change in business model, product scope, or geographic reach
A scheduled review cycle completion, typically aligned to certification periods
A material finding from an audit that reveals a gap in policy coverage

Practical triggers for a procedure update include:

A change in the tools or systems used to carry out the activity
A restructure that changes which roles are responsible for specific steps
An incident that reveals a step was missing, ambiguous, or ineffective
Feedback from employees who follow the procedure that it no longer reflects reality

One of the core principles behind our governance services is that policies and procedures should be reviewed on different cycles, because they age at different rates. Treating them as a single document type and reviewing them together is a common source of governance drift.

What happens when policies and procedures are misaligned?

When policies and procedures are misaligned, governance breaks down at the point where intent meets execution. Employees follow the procedure because it tells them what to do in practice, but if the procedure no longer reflects the policy, the organisation is systematically non-compliant without anyone realising it. This gap is one of the most frequent findings in ISO 27001 and NIS2 audits.

Misalignment typically takes one of three forms. First, a procedure exists but references an outdated policy version, meaning staff are following steps that were designed for requirements that have since changed. Second, a policy has been updated but the supporting procedures have not been revised to match, creating a disconnect between what management has committed to and what staff actually do. Third, a procedure has been written for an activity that no policy covers, leaving that activity outside the governance framework entirely.

The consequences are not only regulatory. Misaligned governance documents erode trust in the framework itself. When employees notice that documented procedures do not match what management says is required, they begin to treat governance documentation as a bureaucratic formality rather than an operational tool. That cultural shift is far harder to reverse than a document update.

Continuous governance, as a practice, exists precisely to prevent this kind of drift. Rather than treating governance documents as static artefacts that get reviewed every few years, a continuous model keeps policies and procedures synchronised as the organisation evolves, ensuring that what is written reflects what is actually done and what is actually required.

If your organisation is working through the relationship between its policies and procedures, or if you want to assess whether your governance framework has developed any structural gaps, contact us and we will help you map it out.

Frequently Asked Questions

How do I know if my organisation's current documents are actually policies or procedures in disguise?

Review each document against two core questions: does it state what is required and why, or does it describe how to do something step by step? If a document labelled 'policy' contains numbered steps, named systems, or role-specific task instructions, it is functioning as a procedure. Conversely, if a document labelled 'procedure' is vague about sequence and contains no role assignments, it is not yet a procedure in any operational sense. A practical audit is to hand the document to a new employee and ask whether they could act on it independently — policies should inform them of obligations, procedures should enable them to act.

What's the minimum number of procedures a policy should have supporting it?

There is no fixed minimum, but a useful rule of thumb is one procedure per distinct operational activity the policy governs. A data protection policy, for example, might require separate procedures for subject access requests, data breach response, and third-party data sharing — because each involves different roles, tools, and steps. If a single procedure attempts to cover all activities under one policy, it usually becomes too broad to be practically useful. Start by listing every activity the policy obligates the organisation to perform, and treat each distinct activity as a candidate for its own procedure.

How should we handle a situation where staff are following an informal process that works well but has never been documented as a procedure?

This is one of the most valuable opportunities in a governance review. If an informal process is working well, documenting it as a formal procedure captures institutional knowledge, reduces dependency on specific individuals, and closes a gap that an auditor would otherwise flag. The best approach is to shadow the people who carry out the activity, document what they actually do rather than what you think should happen, and then validate the draft with them before formalising it. Avoid the common mistake of writing the procedure from scratch based on policy intent alone — the gap between designed and actual process is often where compliance risk lives.

Can a single document serve as both a policy and a procedure for a small organisation?

It is possible to combine them in a single document for smaller organisations, but only if the structure is explicit — for example, clearly labelled sections that separate mandatory obligations from operational steps. The risk is that combined documents tend to blur the distinction over time, particularly when only part of the document needs updating. A procedure change that also touches policy language triggers a more significant approval process, which can cause teams to delay necessary updates. Even for small organisations, maintaining the conceptual separation — even within one document — preserves the governance integrity that frameworks like ISO 27001 and GDPR expect to see.

What approval process should a procedure go through compared to a policy?

Policies typically require board-level or senior management approval because they express organisational intent and carry strategic weight. Procedures, by contrast, are usually approved at the operational management level — by a department head, a process owner, or a designated governance role — because they deal with how work is carried out rather than what the organisation commits to. This difference in approval path is intentional: it allows procedures to be updated more quickly in response to operational changes without triggering a full governance review cycle. Documenting these approval authorities explicitly in your governance framework prevents bottlenecks and ensures the right people are accountable for each document type.

How do we prevent governance drift between policies and procedures as our organisation scales?

The most effective control is a document dependency map — a register that links each procedure to the policy or standard it implements, so that when either document is updated, the linked documents are automatically flagged for review. Scheduled review cycles should be set independently for policies and procedures, reflecting their different rates of change. Assigning a named procedure owner for each document, separate from the policy owner, creates clear accountability. Organisations that treat governance documentation as a living system rather than a one-time project are significantly less likely to face misalignment findings during audits.

How do regulators like ISO 27001 auditors or NIS2 assessors typically test the relationship between policies and procedures?

Auditors commonly use two techniques: document review and process walkthrough. In a document review, they check whether procedures reference the correct version of the governing policy, whether mandatory requirements in the policy are traceable to specific procedural steps, and whether review dates are current. In a process walkthrough, they interview staff and ask them to describe how they carry out a specific activity — then compare that account against the documented procedure and the policy above it. Gaps between what staff do, what the procedure says, and what the policy requires are the most common findings. Preparing for this means ensuring your documents reflect operational reality, not just aspirational intent.

Navigation