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.
What the policy review and approval process flowchart (trigger to attestation) process is
Most policy frameworks fail quietly rather than loudly. The policies exist, they were approved by somebody, and the register even carries review dates, but a third of them are overdue, several are owned by people who left in a reorganisation, and the version on the intranet is not the version in the induction pack. The reason is rarely that nobody cares about policy. It is that a review is treated as a document-editing job rather than a governance cycle with a trigger, an owner, a decision and a record. Two symptoms are diagnostic. The first is a review that produced no change and left no trace, so a policy that was read and found correct looks untouched for six years. The second is a revision that was approved and published but never landed: no announcement anyone remembers, no attestation, and waivers still running against clause numbers that no longer exist. Neither is a drafting problem. Both are failures of the cycle around the document: nobody was named to run it, nothing recorded what it decided, and no step existed to close the loop with the people the policy binds.
This chart is the governance cycle for one policy, drawn across five phases and six lanes. It is not the general controlled-document lifecycle: version numbering, issue, distribution, withdrawal of superseded copies and the periodic review of every kind of controlled document belong to the document control process flowchart at /templates/document-control-process, and this page assumes that machinery already exists and calls into it. It is not the routing test for a single draft either: which reviewers are mandatory, what counts as an editorial change and when a second approver is needed are worked through in far more detail by the document approval workflow at /templates/document-approval-workflow. And it is not an SOP revision. A policy is a governance instrument: it states what the organisation requires, is owned at board or executive level, and comes round on a calendar whether or not anything has changed. An SOP is a work instruction that changes when the work changes, which is why the controlled SOP template at /templates/sop-controlled-sop-template is built around the activity rather than the review date. Findings that trigger a policy review often arrive from the internal audit process at /templates/internal-audit-process: that page covers how a finding is raised, this one covers what the policy owner then does with it.
Three things most written policy procedures leave implicit are drawn here as branches. "Change to the policy required?" carries a No change route that does not simply stop: it ends at "Review recorded, new date set", because a review that produced no amendment is still a review, and it is exactly what a certification auditor samples. "Which approval tier applies?" is answered before the revision is submitted rather than after it has spent a month on the wrong agenda, and it routes to three different bodies rather than one nominal approver. And "Employee consultation required?" is a real fork with a real exit. Where a works council or a recognised union holds consultation or co-determination rights, the draft goes to them and "Representatives agree the change?" is put on the record; its Not agreed branch does not send the draft back for another edit, it moves the change into a negotiation with its own timetable, which is why "Referred to formal negotiation" leaves the process rather than looping. The publication phase is deliberately longer than most procedures make it: announce, supersede, decide whether the change is material enough to train on, attest, refresh the waiver register, because that is where the failures actually are.
What this flowchart covers
In this template
- Six swimlanes (Policy office, Policy owner, Affected business areas, Legal and compliance, Employee representatives and Approval body) laid across five phases: Trigger and scoping, Gap analysis, Drafting and consultation, Approval, and Publication and attestation.
- A trigger that is either the review date the policy carries or an event that overtakes it, followed by "Confirm the accountable policy owner" (the step that catches policies orphaned by a reorganisation before any drafting starts.
- "Change to the policy required?" answered from an explicit gap analysis, with a No change branch that still finishes at "Review recorded, new date set" so a policy needing no amendment never looks unreviewed.
- Consultation split across three lanes: "Consult the affected business areas", "Review for legal and regulatory fit", and an "Employee consultation required?" decision routing to representatives, where "Representatives agree the change?" either returns the draft to "Update the draft after consultation" or exits at "Referred to formal negotiation" instead of looping back.
- "Which approval tier applies?" branching to Tier 1 (board), Tier 2 (executive) and Tier 3 (committee), which converge on a three-way "Approval decision?" (Approved, Redraft back to the draft, or Rejected, ending at "Revision withdrawn and shelved".
- A publication phase with the steps procedures usually assume: "Publish the new version and announce it", "Supersede and archive the old version", a "Material change requiring training?" decision, "Record attestation from affected staff", "Refresh the exception and waiver register", and the ending "Revised policy in force".
When to use this template
- You are writing or rebuilding a policy framework and need one picture of who triggers a review, who owns the content, who must be consulted and who signs it off.
- Your policy register still names owners who left in the last reorganisation and carries review dates that passed two years ago, and you want the owner check and the recorded no-change outcome built into the cycle rather than chased by email.
- An audit finding, a regulatory change or a reorganisation has just forced an out-of-cycle review, and you want the same route used for it as for a scheduled one.
- Revisions keep reaching the board that should have been settled by a policy committee, and you need the tier decided before submission rather than argued at the meeting.
- You publish revised policies and then cannot show who has read them, or you find waivers still live against clauses that were deleted two versions ago.
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.
Where this process fits
In most operations this process follows Internal audit process flowchart template.
It is one step in Document control.
Step 4: Document change control workflow flowchart
A document change control workflow flowchart covering minor/major classification, reviewer impact assessment, approval, version stamping, distribution list updates and formal supersession of the previous version.
Step 5: Policy review and approval process flowchart (trigger to attestation) You are here
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.