GRC · Guide
Policy vs procedure: the difference between policy and procedure, and where standards fit
Policy vs procedure: the difference between policy and procedure, and where standards fit
Key takeaways
A policy states what a firm commits to and why, and is approved by the board or senior management. A procedure states exactly how one task is done, step by step, and by whom. Standards set measurable rules, processes show how work flows across roles, and guidelines advise. GRCMANA recommends keeping policies short and stable and putting changeable detail into procedures.
- DORA Article 6(2)
- DORA requires the ICT risk management framework to include at least strategies, policies, procedures, ICT protocols and tools needed to protect information and ICT assets.
- DORA Article 6(5)
- DORA requires the ICT risk management framework to be documented and reviewed at least once a year, and after major ICT-related incidents.
- FCA SYSC 4.1.1R
- The FCA rule requires robust governance arrangements, including effective processes for managing risk and internal control mechanisms that include sound administrative and accounting procedures.
- DORA Article 9(4)(c)
- DORA asks for policies limiting access to what legitimate, approved functions need, backed by policies, procedures and controls for access rights.
The board has asked for the policy library to be rationalised before the next DORA or ISO 27001 review. You have a 40-page access control policy full of screenshots, and no written procedure for the service desk at all. The difference between policy and procedure is the first thing to fix: a policy states what the firm commits to and why, and a procedure states exactly how a task is done. Standards and processes sit between the two. Keep policies short and stable, and put the detail that changes into procedures.
This comparison is for compliance leads and operations directors at UK FCA-regulated firms and insurers. It sets out the full document hierarchy, what ISO 27001 and DORA expect of each layer, and a worked access control example.
What is the difference between policy and procedure?
The difference between policy and procedure is the difference between intent and execution. A policy says what the firm commits to and why, and is approved by the board or senior management. A procedure says exactly how one task is done, step by step, and by whom. Policies should rarely change; procedures change whenever the work does.
Between the two sit three more document types. A standard sets a mandatory, measurable rule that makes the policy testable. A process describes how work flows across roles and teams. A guideline gives advice that people may follow but are not bound by.
Read together, the five form one hierarchy. Each layer answers a narrower question than the one above it, and each changes more often.
| Document | Purpose | Who approves it | Review | Mandatory? | Information security example | Audience |
|---|---|---|---|---|---|---|
| Policy | States what the firm commits to and why | Board or senior management | Yearly, and on significant change | Yes | All access is granted on least privilege and removed promptly | Everyone it binds |
| Standard | Sets a measurable rule that makes the policy testable | Policy owner, such as the CISO | Yearly, or when the threat or technology changes | Yes | MFA on all remote access | Control owners and technical teams |
| Process | Shows how work flows across roles, from trigger to outcome | Process owner | When the workflow or the organisation changes | Yes | Joiner, mover and leaver | The teams in the flow |
| Procedure | Sets out the exact steps for one task | Team lead for the task | Yearly, and whenever the tool or steps change | Yes | How the service desk grants access | The people doing the task |
| Guideline | Offers advice and good practice | Policy owner | As needed | No | Choosing a strong passphrase | Anyone who wants help |
The review and approval columns are our recommendation for a firm of 50 to 250 staff. ISO 27001 and DORA set their own minimums, covered below.
How do standards, processes and guidelines fit in?
Standards, processes and guidelines fill the gap between a policy's intent and a procedure's steps. A standard turns a policy commitment into a rule an auditor can test. A process shows how several teams hand work to each other. A guideline helps people make good choices where a rule would be too rigid.
The test is what happens when someone ignores the document. Breaching a policy, standard or procedure is a control failure. Ignoring a guideline is a judgement call, and it should stay that way.
When should something be a policy?
Something should be a policy when it states a commitment the board must own: what the firm protects, why, how much risk it accepts and who is accountable. If changing it would need senior sign-off, or a regulator could ask who approved it, it belongs in a policy. Its strength is stability: it outlasts the tools beneath it.
Concrete triggers for writing it into a policy:
- The board must own it. Risk appetite, accountability or a regulatory obligation sits behind it.
- It binds everyone. The rule applies across the firm, not to one team or one tool.
- It will outlast the tooling. The commitment holds whether you run one identity provider or another.
- A regulator or auditor will ask for it by name. The information security policy is the obvious case.
If a sentence names a product, a menu or a ticket queue, it is not policy material. Our ISO 27001 Clause 5.2 guide covers what the top-level information security policy must contain.
When should something be a procedure?
Something should be a procedure when it tells a named person how to complete one task in the right order. If the steps change when you swap a tool, restructure a team or update a form, they belong in a procedure. Procedures should change freely, without a board meeting each time.
Concrete triggers for writing it into a procedure:
- It has an order. Step three fails if step two is skipped.
- It names a tool or a screen. The service desk console, the HR system or the backup console.
- Someone new must do it without help. Cover for leave, a new starter or an incident at 2 a.m.
- It produces a record. A ticket, an approval or a log entry an auditor will sample.
ISO 27001 Annex A 5.37 asks for the operating procedures behind your information processing facilities to be written down. The people who run them must be able to find them.
How does the hierarchy map to ISO 27001 and DORA?
The hierarchy maps to both. ISO 27001 treats the documents your management system relies on as documented information that must be controlled, with a top-level policy set by top management. DORA Article 6 requires an ICT risk management framework that includes strategies, policies, procedures, ICT protocols and tools, documented and reviewed at least once a year.
On the ISO 27001 side, four requirements carry the hierarchy:
- Clause 5.2 asks top management to establish the information security policy.
- Annex A 5.1 adds topic-specific policies, which management approves, shares with the people they apply to and reviews on a schedule. Our A.5.1 guide covers the policy suite.
- Clause 7.5 requires documented information to be controlled: identified, approved, versioned and available. See our Clause 7.5 guide.
- Annex A 5.37 covers documented operating procedures, the bottom of the stack for IT operations.
On the DORA side, Regulation (EU) 2022/2554 is specific. Article 5(2) makes the management body responsible for defining, approving and overseeing the arrangements for the framework. Article 6(5) adds that the review must also follow major ICT-related incidents. Article 9(4)(c) asks for policies that limit access, backed by a set of policies, procedures and controls for access rights.
DORA applies to financial entities in the EU, not to UK firms directly. It reaches a UK firm through an EU-authorised entity in its group, or through the contract terms that Article 30 requires EU financial entities to agree with their ICT service providers.
Closer to home, the FCA's SYSC 4.1.1R, which applies to many FCA-authorised firms, asks for robust governance arrangements. These include effective processes for managing risk and internal control mechanisms, including sound administrative and accounting procedures. The rule names processes and procedures, not just policies.
What does access control look like from policy to procedure?
Access control shows the whole hierarchy in one thread. The policy commits to least privilege. The standard makes it testable: MFA on all remote access. The process defines how joiners, movers and leavers flow between HR, line managers and IT. The procedure tells the service desk exactly how to grant access.
Followed down the stack, it reads like this:
- Policy. "Access to information and systems is granted on least privilege, approved by the asset owner, and removed promptly when no longer needed." Approved by the board.
- Standard. "Multi-factor authentication is enforced on all remote access, all administrator accounts and all third-party connections." Owned by the CISO.
- Process. Joiner, mover and leaver: HR raises the change, the line manager confirms the role, IT provisions or removes access, and the asset owner reviews it each quarter.
- Procedure. The service desk checks the ticket for manager approval, assigns the role group in the identity provider, confirms MFA enrolment, and closes the ticket with the evidence attached.
Each layer can change without touching the one above. Moving to a new identity provider rewrites step 4 and leaves steps 1 to 3 intact. That is the payoff: the board approves a page that stays true for years.
What are the common mistakes with policies and procedures?
The common mistakes are procedures written into policies, policies nobody reads, documents with no owner, and review dates that pass unnoticed. Each one makes the library harder to maintain and weaker as evidence, because the document stops describing what the firm actually does.
- Procedures written into policies. Screenshots and step lists force a board approval for every tool change, so the policy falls out of date.
- Policies nobody reads. A 40-page policy is not read by the people it binds, and an acknowledgement does not change that.
- No named owner. A document without an owner has no one to update it, and no one to answer the auditor's questions.
- Missed review dates. An expired review date is one of the easiest findings for an auditor to raise.
- Guidelines dressed as rules. "Should" in a standard leaves nothing to test.
A short policy that people read beats a long one that people sign.
Frequently asked questions
No. A process shows how work flows across roles from a trigger to an outcome, such as joiner, mover and leaver. A procedure covers one task inside that flow, in exact steps, for one role. One process usually needs several procedures, one for each team that touches it.
Short enough that the people it binds will read it. We recommend a top-level information security policy of a few pages, with topic-specific policies of similar length. Our information security policy template is a starting point. Length grows when procedural detail creeps in, so move it down a layer.
The person who leads the team that performs it, not the compliance function. The team lead knows when the steps change and can update them the same day. Compliance checks that procedures exist, are current and match the standard above them.
Rarely on their own. Auditors test mandatory requirements, so a guideline shows good practice but not compliance. If you find yourself pointing an auditor at a guideline, the rule it describes probably belongs in a standard instead.
Domain engine
GRC reference directory.
Every guide in this domain, grouped by level — fundamentals, intermediate and advanced. Open any entry for its core practices, implementation steps and the evidence it produces.
01Fundamentals9 guides
Policy vs procedure: the difference between policy and procedure, and where standards fitGRC vs IRM: what integrated risk management adds, and whether a smaller regulated firm needs itGRC career path: roles, skills and certifications from analyst to head of GRCGRC roles and responsibilities: who owns what in a lean GRC teamIn-house, consultant or compliance as a service: which GRC model fits a 25 to 250-person tech firmGRC, financial services and the UK rulebook: what the FCA, PRA and DORA expect of a smaller regulated firmSaaS compliance for B2B tech firms selling into regulated industries: what your customers' regulators push down to youWhat GRC costs: a cost model for a 25 to 250-person UK firmGRC framework: how to structure one in a regulated firm
02Intermediate1 guide
GRC Programme Accelerator
Ready to run GRC as one system, not three spreadsheets?
Work with a Trust Architect to design a GRC programme that fits a 25 to 250-person firm: scoped, owned and built to run all year rather than in a scramble before each audit.