Policy management

Policy management

The policy module is where the trust’s policies live — Safeguarding, Data Protection, Behaviour, Staff Code of Conduct, and the dozens of others a trust accumulates.

Why centralise

Trusts that keep policies in scattered Word docs end up with:

• “Which version is current?” — usually the one in someone’s Outlook
• Out-of-date policies referenced by the inspectorate
• Different versions at different academies
• No record of who reviewed what when

The policy module fixes this with one canonical version per policy, version history, and explicit review.

What a policy carries

• Title + slug — “Safeguarding & Child Protection Policy”
• Category — Statutory / Best practice / Operational / Local
• Owner — accountable person (Headteacher, DSL, DPO, etc.)
• Reviewed by — committee or person who signs off
• Body — the policy text (rich-text editor, with import-from-Word)
• Effective date — when this version came into force
• Review cadence — quarterly / half-yearly / annually
• Next review date
• Status — Draft / In review / Approved / Published / Archived
• Is public — flag controlling whether the policy appears on the public-facing policies surface
• Related — linked risks, controls, training records

Version history

Every published version is preserved. The current version is what staff see; previous versions are accessible via the Versions section on the policy page.

The Versions section shows what changed between versions (a diff) and who approved each change. Useful when an inspector asks “when did this clause change?”.

Review workflow

When next_review_date arrives, the policy moves to In review and the owner gets notified. The approval workflow follows these states:

1. Draft — edits in progress
2. In review — submitted; awaiting approval
3. Approved — sign-off recorded
4. Published — live for staff; adds a new version entry
5. Archived — retired; preserved in history

Skipping the review (e.g. “no changes needed, just bumped the date”) is fine — but it still has to go through the approval workflow. The audit trail records that the review happened, not just the changes.

Publishing

Published policies are visible:

• In the staff portal’s acknowledgement queue (if requires_acknowledgement is set)
• On the public policies page (if is_public is set) — accessible at /policies without authentication
• In the Solutions / KB if cross-linked

Archive a policy when it’s superseded by a new one or no longer relevant. Don’t delete — the audit trail needs the historical record.

Statutory policies

The seeded list of statutory policies (the ones DfE require) ships with every workspace. Don’t delete these — even if you choose not to use the policy module fully, the list is there as a checklist.