Policy review and approval process flowchart (trigger to attestation)
Policy review and approval process flowchart: calendar or event trigger, owner confirmation, gap analysis, consultation, legal and employee-representative review, tiered approval, publication and attestation.
How it works
Rename the lanes to your governance
Replace Policy office, Policy owner, Affected business areas, Legal and compliance, Employee representatives and Approval body with the roles and bodies you actually have. Keep the policy office separate from the policy owner even if the policy office is one person: one runs the cycle and holds the register, the other owns the content and defends the change. If you have no works council or recognised union, delete the Employee representatives lane and the decision that feeds it rather than leaving a body in the chart that never does anything.
Write the trigger list into the framework
The calendar trigger is easy; the event triggers are the ones people argue about afterwards. Name them in the framework document: a change in law or regulation, an enforcement action, a serious incident, an internal or external audit finding, a material change to the operating model, a reorganisation, and an acquisition. Say who is entitled to pull a review forward and how they do it, because an out-of-cycle review that depends on someone spotting a news item is not a control. Then record which trigger fired on every review you run.
Set the approval tiers before you need them
Tag every policy in the register with its tier and its named approval body now, while nothing is pending — deciding a tier with a revision already drafted turns a governance question into a scheduling argument. For Tier 1, read the schedule of matters reserved to the board rather than guessing from the subject. Then write down the two things frameworks leave out: who may move a revision between tiers, and what a delegated approval looks like when the body will not meet before the effective date. That second gap is where unapproved policies quietly go into force.
Define what a material change means
"Material change requiring training?" is inert until you write the test. Material means the change alters what somebody must do: a new obligation, a lower threshold, a new prohibition, a different reporting route. It does not mean a renamed department or a corrected cross-reference. Getting this wrong is costly in both directions — training on trivia teaches people to click through, and a silent material change leaves staff confidently doing the old thing. Have the policy owner propose the answer and the approval body confirm it as part of the approval.
Decide how attestation and waivers are tracked
Define the affected population from a system of record rather than a mailing list, set a deadline, chase non-responders through line managers, and file the completion figures against the policy version they belong to — an attestation rate with no version attached proves nothing. Then treat the exception register as part of the release rather than a later tidy-up. Give it a named owner, require every waiver to carry an expiry date, an approver and the compensating control it relies on, and re-point the survivors at the new clause numbering before the revision takes effect.
Walk it through and publish a version
Take the finished chart to the people in the lanes — the policy owner, whoever runs the register, a legal reviewer, and the secretary of the approval body — and walk one real policy through it end to end, including a review that changes nothing. Correct the chart to what they actually do, not what the framework says. Then publish that revision with an approval recorded against it and keep the earlier ones, so the process for reviewing policies is itself under the version control it demands of everything else.
Frequently asked questions
What are the steps in a policy review and approval process?
Trigger the review, either from the date the policy carries or from an event that overtakes it. Confirm who the accountable owner is, because reorganisations orphan policies. Analyse the current text against whatever triggered the review and decide whether a change is needed. If it is not, record the review and set a new date. If it is, draft the revision against the approved version with changes tracked, consult the business areas the clause governs, take legal and compliance review, and put the change to employee representatives wherever they hold consultation or co-determination rights. Update the draft, submit it to the approval tier the policy sits in, and record the decision. Then publish a numbered version with an effective date, announce what changed, withdraw and archive the superseded version, train where the change is material, collect attestation from affected staff, and refresh the exception register against the new clause numbers.
How often should policies be reviewed?
Annually for policies carrying legal or regulatory obligations and for anything the board owns; every two years for most others; and immediately whenever an event overtakes the calendar. The fixed cycle is not the important part — the event triggers are. A policy reviewed on schedule the month before a legislative change is out of date the following week, and the review that matters is the unscheduled one. Set the interval per policy rather than across the whole framework, write it on the policy itself, and hold it in a register that shows the next date for every entry, not just the last one. Two practical points. Stagger the dates so the approval body does not receive forty policies in one quarter. And decide what an overdue review means before you have one: a policy does not lapse when its review date passes, it stays in force, so an overdue entry has to be visible in the register and escalated to the owner's line management rather than quietly re-dated by whoever maintains the list.
Who should approve a policy?
The body that carries the accountability the policy expresses, which is why one nominal approver rarely works across a whole framework. This chart routes to three. Policies that set risk appetite, discharge a statutory duty or bind the organisation externally go to the board. Policies with cross-functional impact — how expenses are claimed, how personal data is handled, how suppliers are engaged — go to an executive committee where the affected functions are represented. The rest go to a policy committee holding delegated authority from the board. Tag each policy with its tier in the register in advance, so the route is settled before drafting rather than argued at submission. And keep the owner and the approver distinct, however small the organisation: a policy that one person writes, owns and authorises has had no second reading, and that is the first thing tested when a policy turns out to contradict a statutory duty or an existing contract.
How is this different from a document control process flowchart?
They sit at different levels. The document control process flowchart at /templates/document-control-process is the lifecycle every controlled document follows — change request, draft, review, approval, version numbering, issue, distribution, withdrawal of superseded copies and periodic review — with a document controller running it. This page is the governance cycle for one policy, and it assumes that document control machinery exists underneath it. What it adds is the part that is specific to policy: an owner check that catches orphans after a reorganisation, gap analysis against the trigger, works council or union consultation, tiered approval by board, executive or committee, attestation by the affected population, and the exception register that has to be revalidated when clauses move. If you want the routing decisions inside a single approval, use /templates/document-approval-workflow. And note the distinction from an SOP: a policy is a governance instrument reviewed on a calendar whether or not anything changed, while an SOP at /templates/sop/controlled-sop-template is a work instruction revised when the work changes.
What happens if a policy review finds no change is needed?
It still has to be recorded, which is the half of the process most frameworks skip. In this chart the No change branch of "Change to the policy required?" does not exit silently; it ends at "Review recorded, new date set". The record should name who reviewed it, what they checked it against — the current regulations, the incident history, the audit findings since the last review — the date they did it, and the next due date. Optionally re-issue the same version with a new review date rather than incrementing the version number, so the document history does not fill with revisions that changed nothing. This matters because certification and regulatory auditors sample for evidence of review, not evidence of change. A policy whose content is genuinely still correct after three years is a good outcome; a policy that looks unreviewed for three years because nobody logged the reviews is a finding, and the two are indistinguishable from the register.