Policy Governance · 16 min read
Policy on Policies: How to Write One for a Growing Company
A policy on policies is the master policy that sets out how your company writes, formats, approves, publishes, reviews and retires every other policy. It names who owns each policy, who signs it off, how often it gets reviewed and how people confirm they’ve read it, so policy work runs the same way every time instead of depending on whoever happens to be writing.
Most of what you’ll find on this topic was written for universities and state agencies, with committees, senates and forty-page procedures. This guide is for a company of 30 to 500 people that has outgrown a folder of documents nobody quite owns, and it is part of our wider guide to policy governance for growing companies.
Key takeaways
- A policy on policies is one short policy that governs all the others, covering roles, approval, format, numbering, review, acknowledgment, exceptions and retirement.
- Sort every document into tiers, because the tier decides who approves it and how often it is reviewed.
- At 30 people it fits on a page, and at 500 people it grows to a few pages with an appendix of owners, while the stages stay the same.
- Write it, approve it and get it acknowledged like any other policy, then follow it yourself, because the first thing an auditor checks is whether you do.
What is a policy on policies?
A policy on policies, sometimes called a policy management policy, a policy framework policy or a policy development procedure, is the rulebook for your rulebook. It doesn’t tell anyone how to book leave or handle customer data, but it tells the people who write those policies how a policy gets created, what it has to look like, who must approve it before it counts, how it reaches employees and when it must be looked at again.
Without one, every policy is a small project with its own rules. One manager writes a two-page policy and emails it round, another writes twelve pages that nobody approves, and a third copies a template that contradicts both. A policy on policies replaces those habits with one agreed process, and it gives a new policy owner a clear answer to the question “what do I actually have to do?”
Why a growing company needs one
The problems a policy on policies solves show up gradually as a company grows, and they tend to surface all at once when someone outside the business asks for proof.
Policies contradict each other. The remote work policy says one thing about home equipment and the information security policy says another, because two people wrote them a year apart and nobody checked one against the other.
Policies are orphaned. The person who wrote the expenses policy left eighteen months ago, so nobody updates it, nobody answers questions about it, and nobody notices when it falls out of date.
Nobody can prove a policy was approved. The file exists, but there is no record of who agreed it was right or when it came into force, which is the first thing an auditor or a customer’s security review will ask.
Reviews never happen. Without a review date written into each policy, the only time anyone revisits a policy is after something goes wrong.
Outside rules expect this kind of control too. Having been through ISO 9001 audits more than ten times, I know document control is never optional, because the standard asks you to approve documents before use, review and update them, identify changes and the current version, and make sure the right version is available where it is used. SOC 2 asks that controls are deployed through policies that set out expectations, healthcare rules require written policies to be kept, reviewed periodically and made available to the people who use them, and federal compliance program guidance puts written policies and procedures first among the elements of an effective program, which we cover in our guide to building a compliance program.
Sources: ISO 9001:2015 clause 7.5, Control of documented information, AICPA Trust Services Criteria CC5.3, 45 CFR 164.316 (HIPAA Security Rule documentation), HHS-OIG General Compliance Program Guidance, November 2023
What a policy on policies should include
The twelve sections below make a complete policy on policies for a growing company. Use all twelve if you have more than about a hundred people, and merge them into five or six short paragraphs if you’re smaller, because the ideas matter more than the headings. The examples show how a company like ShiftTilt Inc, with about 120 people, might fill each one in.
| Section | What it says | Example for ShiftTilt Inc (about 120 people) |
|---|---|---|
| 1. Purpose | Why the company manages policies in one consistent way | “So every policy is approved, current, easy to find and provably read by the people it applies to.” |
| 2. Scope | Which documents it covers and which it doesn’t | All company policies and procedures; customer contracts and marketing copy are out of scope. |
| 3. Definitions | What counts as a policy, a procedure, a standard and a guideline | A policy says what must happen and why; a procedure says how, step by step. |
| 4. Tiers | The levels of document and what belongs in each | Governance policies, company policies, procedures (see the diagram above). |
| 5. Roles | Who requests, owns, drafts, approves and coordinates | Each policy has one owner role, such as Head of People; the Operations Manager coordinates the library. |
| 6. Approval authority | Who signs off on each tier, and in what order | Governance: owner, then CEO. Company: owner, then department head, then CEO where law or money is involved. |
| 7. Format | The standard header and the sections every policy must have | Title, number, owner, approver, effective date, review date, who it applies to, related documents. |
| 8. Numbering and naming | How policies are numbered, named and versioned | Area prefix plus number, such as HR-004 or SEC-002, with version numbers that only go up. |
| 9. Communication and acknowledgment | How approved policies reach people and how reading is recorded | Every new or changed policy goes to the people it applies to for acknowledgment, with automatic reminders. |
| 10. Review | How often each tier is reviewed and what a review produces | Governance every 12 months, company policies every 12 to 24 months, procedures when the process changes. |
| 11. Exceptions | How someone asks to depart from a policy, who decides, and how it is recorded | A written request to the policy owner, approved by the owner’s manager, time-limited and logged. |
| 12. Retirement and records | How a policy is withdrawn and how old versions are kept | Retired policies are removed from view but every version and its approval record are kept. |
Two sections cause most of the arguments, so settle them early. The first is the definitions, because the line between a policy and a procedure decides who can change what: if procedures can be updated by the policy owner while policies need leadership sign-off, people need to know which is which. The second is approval authority, because a policy on policies that says “approved by management” without naming a role will be read differently by every manager who uses it.
Who approves policies at a growing company
Name roles rather than people, so the policy survives someone leaving. At 50 to 500 people the cast is usually small, and the same person may hold two of these roles, which is fine as long as nobody approves a policy they wrote on their own.
| Who | Their job in the policy process | Typical person at 50 to 500 people |
|---|---|---|
| Requester | Raises the need for a new or changed policy | Anyone, though usually a manager, an auditor’s finding or a customer request |
| Policy owner | Accountable for the policy’s content, keeps it current, answers questions about it | A role such as Head of People, IT Manager or Quality Manager |
| Approver | Confirms the policy is right and can be put in force | Department head, CEO, an outside lawyer for anything with legal weight |
| Policy coordinator | Keeps the library tidy, chases review dates, runs this policy | An operations, HR or compliance lead, often part-time |
| Board or leadership team | Approves the governance tier and the policy on policies itself | The leadership team, or the board where the company has one |
Our guide to the policy owner role goes deeper on the role people most often leave blank, and the one that matters most once the policy is in force.
Order matters as much as names. A sensible path for a company policy is owner first, then the department head, then the CEO only when the policy carries legal or financial weight, so the CEO isn’t reading every procedure while the important policies still get senior eyes. An outside lawyer can sit in the path too, as an approver on the policies where their sign-off matters.
The policy lifecycle, from request to retirement
The heart of a policy on policies is the lifecycle every policy follows. Seven stages cover almost every company, and writing them down means a manager with a new policy to write can start at stage one without asking anyone how it works.
The rule at the bottom of that diagram is the one most policies on policies leave out. Many allow “minor” edits to skip approval or re-acknowledgment, and the trouble is that nobody agrees what minor means, because a single changed word in a disciplinary or safety clause can change what people have to do. We built AllyMatter so that every new version goes back through approval and out for acknowledgment, with no exception for small edits, and our post on re-acknowledging policy updates explains how to make that painless for staff.
Acknowledgment deserves its own sentence in the policy on policies. Say who must acknowledge each tier, how soon after publication, and what happens if someone doesn’t, and decide whether some policies need a formal yearly confirmation as well, which our guide to policy attestation covers.
Review cycles that people actually keep
A review date is only useful if someone sees it coming. Put the cycle for each tier in the policy on policies, put the next review date on every policy, and define what a review produces: either a confirmation that the policy is still right, which is recorded, or a revised version that goes back through approval.
| Document | Sensible review cycle | Also review when |
|---|---|---|
| Policy on policies | Every 12 months | The company changes shape, such as a new department or a merger |
| Code of conduct, conflict of interest, information security | Every 12 months | A law, a certification or a major customer requirement changes |
| HR and workplace policies | Every 12 to 24 months | You cross a headcount threshold or open in a new location |
| Safety programs | Every 12 months | An incident, a new hazard or new equipment |
| Procedures and SOPs | When the process changes, at least every 24 months | A mistake shows the written steps no longer match the work |
Stagger the dates. If every policy is due in January, the review becomes a month of rubber-stamping, whereas spreading reviews across the year gives each owner one or two policies at a time and a real chance to read them.
Format, numbering and naming conventions
A standard format makes policies faster to write, easier to read and much easier to audit, because everyone knows where to find the owner, the effective date and the review date. Ask every policy to open with the same header block:
- Title and number, such as HR-004 Remote Work Policy
- Owner, as a role rather than a name
- Approved by, the role or roles that signed it off
- Effective date and next review date
- Applies to, the teams, locations or roles in scope
- Related documents, such as the procedures and forms that carry it out
Then ask for the same body sections in the same order: purpose, scope, the policy itself, responsibilities, and what happens if it isn’t followed. A short prefix per area keeps numbering simple, such as HR, SEC for information security, FIN, OPS, QA and HS for health and safety, and numbers that are never reused stop an old reference from pointing at a new policy.
Version numbers should only ever go up. A version that is restored or re-issued still gets a new number, so an auditor can line up exactly which text was in force on any date and who had acknowledged it, and a word-by-word comparison between versions shows precisely what changed.
Exceptions and retirement
Every policy meets a situation it didn’t foresee, so decide in advance how exceptions work rather than letting managers improvise. A good exceptions section says who can ask, who decides, how long an exception lasts and where it is recorded, and it treats a pile of exceptions to the same policy as a sign that the policy needs rewriting.
Retirement needs the same care. When a policy is withdrawn or replaced, it should disappear from everyday view so nobody follows it by mistake, while its versions and approval history are kept for as long as your records rules require. Our guide to the records retention schedule covers how long to keep them, and governance policies like a conflict of interest policy usually sit in the top tier alongside the policy on policies itself.
How a policy on policies grows from 30 to 500 people
You don’t need the university version on day one. A 30-person company can cover everything in a page, and the document grows only as new roles and approvers appear, while the lifecycle stays the same at every size.
How to write your policy on policies in a week
Day one: list what you have. Gather every policy and procedure in one place, note who wrote each one and when it was last changed, and mark the ones nobody owns.
Day two: choose tiers and owners. Sort each document into a tier and give each one an owner role, and expect a few uncomfortable conversations about policies nobody wants.
Day three: set approval paths and review cycles. Agree who approves each tier and in what order, and give every policy a review date spread across the coming year.
Day four: write it. Use the twelve sections above, keep it short, and write in the same plain language you want every other policy to use.
Day five: approve it, publish it and follow it. Put the policy on policies through its own top-tier approval, send it to everyone who writes or approves policies for acknowledgment, and then bring your most important policies into line with it first.
The last step is the one that counts. A policy on policies that the company ignores is worse than none, because it shows an auditor a process you said you would follow and didn’t, so start with the handful of policies that matter most and work through the rest at each review.
How AllyMatter runs your policy on policies for you
We built AllyMatter so that the process written in your policy on policies is the process the software follows, rather than a document people are supposed to remember.
Tiers become folders with their own approval paths. An approval workflow attached to a folder applies to every policy saved there, so governance policies always go to the CEO and procedures stay with their owners.
Every policy has a named Editor. The person responsible for keeping each policy current is its Editor, so there is never a document without someone accountable for it.
Only approved versions reach people. A policy is locked while it is being reviewed, a rejection needs a written reason, and drafts never reach staff.
The right people get each policy. Tags for teams, locations and roles decide who sees each policy and who is asked to acknowledge it, and the request can be a simple notification or an acknowledgment with automatic reminders.
Reviews and retirement are built in. Each policy carries a fixed or repeating review date, and an expiry date takes a retired policy out of everyone’s view while its history stays on record.
The record writes itself. Every step lands in the policy’s audit trail, so when an auditor asks how you control your policies, you show them the policy on policies and then the trail that proves you followed it.
For the full picture of how the pieces fit together, from ownership to attestation to records, start with our policy governance guide or our guide to policy management software for small and growing businesses.
Start your 30-day free trial of AllyMatter. No credit card to start, and a 30-day money-back guarantee if you subscribe and change your mind. Free migration.
Questions about a policy on policies
What is a policy on policies?
A policy on policies is the master policy that sets out how a company creates, formats, approves, publishes, reviews and retires all of its other policies. It names who owns each policy, who approves it, how often it is reviewed and how employees confirm they have read it.
Is a policy on policies the same as a policy framework?
They overlap. A policy framework usually describes the whole structure of policies, standards and procedures, while the policy on policies is the single written policy that puts that framework into force and makes it binding on everyone who writes or approves a policy.
Does a small company need a policy on policies?
Once more than one or two people write policies, yes, even if it is only a page long. It is the cheapest way to stop contradicting policies, missed reviews and policies nobody can prove were approved, and auditors and enterprise customers often ask how you control your documents.
Who should approve the policy on policies?
The CEO or the leadership team, and the board where the company has one. Because it governs every other policy, it should sit in the top tier and be reviewed at least once a year.
How often should company policies be reviewed?
Most companies review governance policies every 12 months, other company policies every 12 to 24 months, and procedures whenever the process changes. Many standards and regulators expect a periodic review, and a change in law, an audit finding or an incident should trigger one early.
What is the difference between a policy and a procedure?
A policy states what must happen and why, and changes rarely. A procedure explains how to do it, step by step, and changes whenever the process changes. A policy on policies usually lets a policy owner approve procedure changes, while policy changes need a higher sign-off.
Where should a policy on policies be kept?
In the same place as the policies it governs, approved, versioned and acknowledged like any other policy, so the people who write and approve policies can always find the current rules.
A policy on policies is the shortest important document most growing companies never write, and it is the one that makes every other policy easier to write, approve, find and prove.
Start your 30-day free trial of AllyMatter. No credit card to start, and a 30-day money-back guarantee if you subscribe and change your mind. Free migration.