Governance policies and governance procedures are different documents because they serve different purposes. A policy defines what an organisation must do and why, while a procedure explains how to do it. Policies set the rules; procedures translate those rules into repeatable, actionable steps. This distinction matters for every organisation pursuing continuous governance, because blurring the two creates documents that are neither enforceable nor usable. The sections below unpack each difference in practical detail, from ISO 27001 specifics to ownership and update cycles. If you have questions about how this applies to your organisation, feel free to get in touch with us and we will be happy to help.

Why do governance policies and procedures need to be separate documents?

Policies and procedures need to be separate documents because they have different audiences, different update frequencies, and different levels of authority. A policy is a management-level commitment that changes rarely. A procedure is an operational guide that changes whenever a process, tool, or team structure changes. Keeping them separate means you can update a procedure without triggering a full policy review, and vice versa.

When policies and procedures are merged into a single document, organisations routinely face one of two problems. Either the document becomes so detailed that management hesitates to approve it, or it stays so high-level that staff cannot use it to do their actual work. Separation solves both problems by allowing each document to be written at exactly the right level of abstraction for its intended reader.

There is also a governance accountability argument. Policies are owned at the management level and reflect strategic intent. Procedures are owned by the teams that execute them. Separating the documents makes that accountability visible, which is a core principle of sound governance. When something goes wrong, you can quickly determine whether the failure was a policy gap or a procedural breakdown, and respond accordingly.

What does a governance policy actually contain?

A governance policy contains the organisation’s intent, scope, principles, and requirements for a given domain. It answers the questions of what is required and why, defines who is in scope, and establishes the consequences of non-compliance. A well-written policy is technology-agnostic and stable enough to remain valid for several years without revision.

In practice, a governance policy typically includes the following components:

  • Purpose and objective: The reason the policy exists and the risk or obligation it addresses
  • Scope: Which people, systems, processes, or entities the policy applies to
  • Principles or requirements: The high-level rules that must be followed
  • Roles and responsibilities: Who is accountable at a strategic level
  • Compliance and consequences: What happens if the policy is not followed
  • Review date and owner: When the policy will next be reviewed and by whom

Notice what a policy does not contain: step-by-step instructions, specific tool names, or names of individual employees. Those details belong in procedures. A policy written at the right level of abstraction can survive a software migration, a team restructure, or a change in vendor without becoming outdated.

What does a governance procedure actually contain?

A governance procedure contains the specific, step-by-step instructions that operationalise a policy. It answers the question of how a requirement is met in practice, naming the tools used, the roles involved, the sequence of actions, and any decision points along the way. Procedures are operational documents designed to be used during day-to-day work, not just read during audits.

A typical governance procedure includes:

  • Purpose: Which policy requirement this procedure fulfils
  • Trigger: What event or schedule initiates the procedure
  • Steps: A numbered sequence of actions, including who performs each one
  • Inputs and outputs: What information or artefacts are needed and produced
  • Tools and systems: Specific platforms or templates used
  • Exceptions: How to handle situations that fall outside the standard flow
  • Review date and owner: Typically reviewed more frequently than the parent policy

Because procedures are tied to operational reality, they tend to change more often than policies. A change in ticketing system, a new team member taking over a task, or revised regulatory guidance can all necessitate a procedure update without touching the underlying policy at all. This is precisely why the two documents must remain separate.

What’s the difference between a policy and a procedure in ISO 27001?

In ISO 27001, a policy establishes management’s direction and intent for information security, while a procedure provides the operational instructions that implement that direction. ISO 27001 explicitly requires both: Clause 5.2 requires a documented information security policy, while numerous Annex A controls require supporting procedures. The standard treats them as complementary but distinct layers of the governance framework.

ISO 27001 uses the policy layer to demonstrate that top management has made a formal commitment to information security. This is not a formality. Auditors will look for evidence that management has actually approved the policy, that it is communicated to relevant parties, and that it is reviewed at planned intervals. A procedure cannot substitute for this, because a procedure does not carry the same level of organisational authority.

At the procedure level, ISO 27001 controls such as access control, incident management, and backup management all require documented processes. These procedures must be specific enough that an auditor, or a new team member, can follow them and verify that the control is actually operating. Vague references to “best practice” are not sufficient.

For organisations pursuing ISO 27001 certification, or maintaining it across a 36-month certification cycle, keeping policies and procedures clearly separated makes both internal audits and external surveillance audits significantly more efficient. Our governance services are structured around exactly this kind of continuous, audit-ready documentation discipline.

When should an organisation update its policies versus its procedures?

Policies should be updated when the organisation’s strategic context changes: a new regulation comes into force, a significant business change occurs, a major incident reveals a gap, or the scheduled review date arrives. Procedures should be updated whenever the operational reality they describe changes, which typically happens more frequently. As a rule of thumb, policies might be reviewed annually or every two years, while procedures may need updates quarterly or even more often.

Specific triggers for a policy update include:

  • New or amended legislation (such as NIS2, the EU AI Act, or DORA coming into scope)
  • A significant change in organisational structure, ownership, or business model
  • A major security or compliance incident that reveals a gap in stated requirements
  • Feedback from an external audit or certification review
  • The scheduled review date defined in the policy itself

Specific triggers for a procedure update include:

  • A change in the tools, systems, or platforms the procedure references
  • A change in team structure or role assignments
  • Discovery during an internal audit that the procedure no longer reflects actual practice
  • New guidance from a certification body or regulatory authority on how a control should be implemented
  • Process improvements identified through operational experience

One practical governance discipline is to link every procedure to its parent policy explicitly. This means that when a policy is reviewed, the owner can immediately identify which procedures also need to be checked for alignment, rather than discovering gaps during an audit.

Who is responsible for owning policies versus procedures?

Policies are owned by management, typically at director or C-suite level, because they represent a formal organisational commitment. Procedures are owned by the operational teams or process owners who execute them. This distinction is not just organisational tidiness; it reflects the principle that governance accountability must sit at the level where authority actually resides.

In practice, a policy owner is responsible for:

  • Approving the policy and any subsequent changes
  • Ensuring the policy remains aligned with legal, regulatory, and strategic requirements
  • Communicating the policy to relevant stakeholders
  • Triggering a review when a material change in context occurs

A procedure owner is responsible for:

  • Ensuring the procedure accurately reflects how the work is actually done
  • Keeping the procedure current when tools, teams, or processes change
  • Training relevant staff on the procedure
  • Reporting upward when the procedure cannot meet the requirements set by the parent policy

A common failure pattern in governance programmes is assigning both policy and procedure ownership to the same individual, often a compliance manager or IT lead. This creates a single point of dependency and blurs the management accountability that policies are specifically designed to establish. Role-based ownership, distributed across the right levels of the organisation, is what turns governance from a documentation exercise into a living operational capability. That principle sits at the heart of what continuous governance actually means in practice.

Getting the relationship between policies and procedures right is one of the most practical steps an organisation can take toward sustainable, audit-ready governance. If you want to discuss how your current documentation structure holds up, or how to build a governance framework that stays current without constant firefighting, reach out to us and plan a conversation with our team.

Frequently Asked Questions

Can a single document ever serve as both a policy and a procedure?

In very small organisations with minimal regulatory exposure, a combined document is sometimes used as a starting point, but it is rarely a sustainable approach. As the organisation grows, gets audited, or takes on more complex compliance obligations, the limitations of a merged document become a practical problem — updates stall, accountability blurs, and auditors push back. A cleaner approach, even for small teams, is to keep the documents structurally separate from the outset, even if they are brief.

How detailed should a governance procedure be — is there such a thing as too much detail?

Yes, over-specification is a real risk. A procedure that names specific individuals rather than roles, or that documents every micro-step of a tool's UI, will become outdated almost immediately and create a maintenance burden. The right level of detail is enough that a competent new team member could follow the procedure and produce the correct outcome, without the document becoming a software manual. If a procedure regularly runs to more than two or three pages, consider whether it should be split into sub-procedures.

What is the best way to get started if our organisation currently has no formal separation between policies and procedures?

Start with an audit of what you already have: list every governance document and categorise each one as policy, procedure, or neither. Then identify your highest-priority domains — typically information security, access control, and incident management — and create a clean policy and a linked procedure for each. You do not need to overhaul everything at once; a phased approach that prioritises audit-critical areas first is far more practical and sustainable.

What happens during an ISO 27001 audit if policies and procedures are not clearly separated?

Auditors will typically raise a nonconformity or at minimum an observation if they cannot clearly identify management-approved policy statements separate from operational procedures. The most common issue is a document that is too procedural to demonstrate top management commitment (failing Clause 5.2) or too vague to demonstrate that a control is actually operating (failing specific Annex A requirements). In either case, the result is rework under time pressure — exactly the scenario that proper separation is designed to prevent.

How should we handle a situation where a procedure can no longer meet the requirements set by its parent policy?

This is precisely the escalation scenario that role-based ownership is designed to address. The procedure owner should formally flag the gap to the policy owner, documenting why the procedure cannot meet the stated requirement — whether due to a tool limitation, a resource constraint, or a change in operational context. The policy owner then decides whether to update the policy requirement, provide additional resources, or accept the risk. Leaving the gap undocumented is the worst outcome, as it creates a silent compliance failure that will surface during an audit.

Do our suppliers or third parties need to comply with our governance policies?

That depends on the scope defined in each policy. If your information security policy includes third-party processors or suppliers within its scope — which ISO 27001 and regulations like GDPR and NIS2 typically require — then yes, those parties are subject to the policy's requirements. However, they will follow their own internal procedures to meet your policy requirements, not yours. The practical implication is that your supplier management procedure should define how you verify third-party compliance, rather than attempting to prescribe their internal processes.

How do we make sure policies and procedures stay aligned over time without it becoming a full-time job?

The most effective mechanism is a documented link between every procedure and its parent policy, combined with a governance calendar that schedules reviews at appropriate intervals. When a procedure is updated, the owner checks alignment with the parent policy as a mandatory step before sign-off. When a policy is reviewed, the owner pulls the list of linked procedures and confirms they are still current. This creates a lightweight but systematic feedback loop that catches drift early, rather than allowing it to accumulate until the next external audit.

Related Articles

Share

  • August 9, 2026