Policy Management: How to Run Policies From Draft to Retirement

Writing a good policy is only the start. The harder part comes later: getting it approved, making sure people can find it, confirming they have read it, and keeping it accurate as the business changes. When that work is left to chance, policies drift out of date, old versions linger in shared folders, and no one is sure which rules actually apply.

This guide explains what policy management is, walks through each stage of the policy lifecycle, and shows how to set up a simple process your team can keep running.

What is policy management?

Policy management is the ongoing process of creating, approving, publishing, communicating, reviewing, and retiring an organization's policies. It covers who owns each policy, how changes are approved, where the current version lives, how employees are told about it, and when it is checked again.

In other words, a policy is a document. Policy management is the system that keeps that document accurate, approved, and in front of the right people.

The U.S. Government Accountability Office's internal control standards, often called the Green Book, describe the same idea. They say management documents what is expected in policies and the specific actions that carry those policies out in procedures. They also say management communicates those policies and procedures across the organization, and reviews them on a periodic and ongoing basis. If you want a refresher on how the two document types differ, see our guide to policy vs procedure.

Why policy management matters

Without a defined process, the same problems show up in almost every organization:

• Nobody owns the policy. It was written years ago, the author has moved on, and no one is responsible for keeping it current.
• Several versions exist. A PDF in email, a copy on the intranet, a draft on someone's drive. Employees follow whichever one they find first.
• Changes are not communicated. The policy is updated, but the people affected never hear about it.
• There is no evidence. When an auditor or customer asks who approved a policy, when it was last reviewed, or whether staff have read it, the answer takes days to piece together.

The EPA's guidance on standard operating procedures puts it simply: even the best-written procedures fail if they are not followed, and current copies need to be readily accessible to the people doing the work. Policy management is how you make both of those things true.

The policy lifecycle, stage by stage

A typical policy lifecycle has eight stages. Your organization may name them differently, but each one needs an answer.

1. Identify the need and assign an owner

A new policy usually starts with a trigger: a new regulation, a risk someone has spotted, a customer requirement, or an incident. Before anyone writes a word, name a policy owner. That person is accountable for the content, for getting it approved, and for keeping it current.

The Green Book says each part of the organization should document its responsibility for a process's objectives and risks, at a level of detail that lets management monitor it. A named owner is the simplest way to make that responsibility real.

2. Draft with the people who will follow it

Policy drafts should come from people who understand the work, not only from legal or compliance teams. The EPA guidance recommends that documents like these be written by subject-matter experts who actually perform the work, and notes that a team approach builds buy-in from the people who will use them.

Keep the draft in a consistent template so every policy has the same core sections: purpose, scope, the policy statement itself, roles and responsibilities, related procedures, and revision details. For help with the writing itself, see our guide on how to write policies and procedures.

3. Review and approve

Every policy needs a defined approval path before it is published. Decide in advance who reviews each type of policy and who gives final approval. A data protection policy might need review from IT and legal, then sign-off from an executive. A travel expense policy might only need finance.

The EPA guidance describes review by people with relevant experience, followed by approval from the responsible manager and the quality lead. It also accepts electronic signatures in place of paper, which makes approval much faster to track.

Write the approval path down. A policy that can be approved by "whoever is around" will eventually be approved by no one.

4. Publish one current version

Once approved, the policy should be published in exactly one place that everyone uses. That place should show the current version clearly and keep older versions out of the way.

The EPA guidance recommends a few habits that apply to any controlled document:

• Give each document an ID and show its revision number and date, so readers can confirm they have the current version.
• Store documents electronically for easier access, with read-only access for readers so no one changes the text by accident.
• Withdraw and archive documents that no longer apply.

For a deeper look at numbering, versioning, and archiving, see our guide to document control.

5. Communicate and collect attestation

Publishing a policy is not the same as communicating it. The Green Book says management communicates policies and procedures across the organization so people can carry out their responsibilities. In practice, that means telling the right people when a policy is new or has changed, and explaining what is different.

Many organizations also ask employees to confirm they have read and understood key policies. This is usually called policy attestation or policy acknowledgement. It gives you a record that each person received the policy, and it prompts people to actually open it. Common approaches include:

• Acknowledgement at onboarding for core policies, such as the code of conduct and information security.
• Re-acknowledgement whenever a policy changes in a meaningful way.
• A regular cycle, such as once a year, for the highest-risk policies.

Keep attestation focused. Asking people to confirm dozens of policies every year teaches them to click through without reading.

6. Handle exceptions

Sometimes a team cannot follow a policy as written, for a good reason. Rather than letting people quietly work around it, define how exceptions are requested, who can approve them, and how long they last. Record each approved exception, and review them when the policy itself is reviewed. A pattern of repeated exceptions is a strong signal that the policy needs to change.

7. Review on a schedule and after changes

Policies go stale. The Green Book says management should review policies, procedures, and related controls on a periodic and ongoing basis to confirm they are still relevant and effective. It also says that after a significant change, such as new people, new processes, new technology, or a new law or regulation, the affected process should be reviewed in a timely manner.

The EPA guidance gives a concrete example of a review interval: every one to two years, with the review date recorded on the document. Pick a default cycle that fits your organization, then shorten it for high-risk policies. Our article on the policies and procedures review cycle covers how to choose the right cadence.

8. Retire what no longer applies

When a policy is replaced or no longer needed, retire it on purpose. Remove it from the published set, archive it with its approval history, and point any links to its replacement. An old policy that is still searchable is worse than none at all, because someone will eventually follow it.

Policy management best practices

A few habits make the whole lifecycle easier to run:

• Keep a policy register. One list of every policy with its owner, approver, current version, last review date, and next review date. If you only do one thing, do this.
• Use a consistent template. The same sections in the same order make policies faster to write, review, and read.
• Write for the reader. Short sentences, plain words, and clear "must" and "must not" statements. A policy no one understands will not be followed.
• Link policies to procedures. Each policy should point to the procedures that carry it out, and each procedure back to its policy.
• Make policies easy to search. If employees cannot find a policy in under a minute, they will guess or ask a colleague.
• Listen to readers. Questions and comments from employees are early warnings that a policy is unclear or out of date.

What to look for in a policy management system

You can run policy management with documents and a spreadsheet, and many small teams start that way. As the number of policies and reviewers grows, a dedicated system saves time and reduces risk. Look for:

• Approval workflows that route each policy to the right reviewers and record who approved what, and when.
• Version history so you can see every past version and restore one if needed.
• One published source of truth with search, so employees always land on the current version.
• Access control so internal policies stay private while public ones can be shared.
• Reader feedback so employees can flag confusing or outdated content.
• Translation if your teams work in more than one language.

Sonat covers these needs for teams that manage policies and procedures. Authors draft in Google Docs or the built-in editor, changes go through parallel or sequential approval workflows, every version is kept in an archive, and the current version is published to a searchable, mobile-friendly site that can be private to your organization. Readers can leave feedback on any page, and content can be machine-translated into other languages.

Conclusion

Policy management turns policies from static documents into a process that someone owns. Give every policy an owner and an approval path, publish one current version, tell people when it changes, and review it on a schedule. Those few habits prevent most of the problems that make policies hard to trust.

Start with a simple policy register this week, then work through your highest-risk policies first. If you want one place to approve, publish, and maintain them, you can try Sonat for free.