A policy and procedure manual is one controlled set of documents that holds an organization’s rules (policies) and the step-by-step instructions for following them (procedures). It tells employees what is required, why, and how to do it, names who owns each part, and records which version is current, so everyone works to the same approved standard.
Most organizations already have policies and procedures. What they often lack is a manual: one place where every document follows the same structure, has an owner and a review date, and can be found in seconds. This guide explains what goes in a policy and procedure manual, shows an example table of contents and a sample entry, and walks through how to write one. It also covers two things most guides skip: how to structure the manual so it stays current, and how to prove the right people have read it.
What is a policy and procedure manual?
A policy and procedure manual (also called a policies and procedures manual or P&P manual) brings together two kinds of document:
- Policies state what the organization requires and why, such as “access to customer data is limited to the staff who need it for their role”.
- Procedures give the exact steps for meeting that requirement, such as how a manager requests, approves and removes access in the IT system.
Each policy in the manual links to the procedures that carry it out, so a reader can move from the rule to the instructions in one click. If you’re unsure where one ends and the other begins, see our guide to policy vs procedure vs process.
The manual’s audience is wider than a single team. Employees use it to look up how to do something correctly. Managers use it to make consistent decisions. Compliance, quality and HR teams use it as the record they show auditors, regulators and, sometimes, courts.
Policy and procedure manual vs employee handbook vs operations manual
These three documents overlap, and many organizations keep all of them. The difference is audience and depth.
| Policy and procedure manual | Employee handbook | Operations procedure manual | |
|---|---|---|---|
| Purpose | The full, controlled set of rules and how to follow them | A readable summary of what employees can expect and what is expected of them | How the organization’s core work gets done, task by task |
| Audience | All staff, managers, compliance and auditors | All employees, especially new hires | The teams that run day-to-day operations |
| Depth | Policy statements plus detailed procedures | Summaries that point to the full policies | Detailed procedures, SOPs and work instructions |
| Typical contents | Code of conduct, information security, privacy, health and safety, finance, HR and operational procedures | Pay, leave, benefits, conduct, working hours, who to contact | Opening and closing, order handling, equipment use, quality checks |
| Changes | Section by section, under document control | Usually once or twice a year | Whenever a process, system or piece of equipment changes |
An operations procedure manual is often a section of the wider policy and procedure manual, or a separate manual of standard operating procedures (SOPs). For that side, read the benefits of an SOPs manual. The employee handbook should summarize the manual and link to it, not repeat it.
Why organizations need a policy and procedure manual
- Consistency. Two managers facing the same situation reach the same decision, and two employees doing the same task do it the same way.
- Faster onboarding. New hires learn the rules and the methods from one source instead of from whoever sits next to them.
- Clear accountability. Every document has a named owner and approver, so it’s obvious who keeps it accurate.
- Evidence for audits. A controlled manual shows what the rules were, when they changed and who approved them.
In some regulated settings, written policies and procedures are a legal requirement rather than good practice. These rules apply only to the organizations they cover:
| Who it applies to | What the rule requires | Source |
|---|---|---|
| HIPAA covered entities and business associates (US) | Keep security policies and procedures in writing for 6 years from creation or last effective date, make them available to the people who implement them, and review them periodically | 45 CFR 164.316 |
| FINRA member firms (US) | Establish, maintain and enforce written procedures to supervise their business and associated persons | FINRA Rule 3110(b)(1) |
| US drug manufacturers | Have written production and process control procedures, approved by the quality control unit, and record any deviation | 21 CFR 211.100 |
| US employers required to have an emergency action plan | Keep the plan in writing (employers with 10 or fewer employees may communicate it orally), and review it with each covered employee when they start, when their duties change and when the plan changes | 29 CFR 1910.38 |
Check which rules apply to your organization. None of them requires a document called a “manual”, but a well-run manual is the simplest way to meet them all in one place.
What to include in a policy and procedure manual
Front matter
- Title page: organization name, manual title, version and effective date.
- How to use this manual: who it applies to, how it’s organized and where the current version lives.
- Table of contents: grouped by area, with each policy’s ID.
- Definitions: terms used across the manual.
- Governance: who owns the manual, who approves changes and how often each section is reviewed.
The structure of every policy and procedure
Use the same sections in the same order for every entry, so readers always know where to look.
| Section | What it contains |
|---|---|
| Header | Title, policy ID, version, effective date, owner, approver and next review date |
| Purpose and scope | Why the policy exists and who and what it covers |
| Policy statement | The requirements, in plain language |
| Roles and responsibilities | Who follows it, who enforces it and who handles exceptions |
| Procedures | Numbered steps, or links to the procedures that carry the policy out |
| Related documents | Forms, standards, other policies and the laws or regulations it supports |
| Revision history | Each version, its date, its author and what changed |
Our free policy and procedure template for Word already has this structure, with a review history table.
Policy and procedure manual example
The example below shows how a mid-size organization might lay out its manual. It’s illustrative. Use the areas that apply to you and add your own.
Example table of contents
| Section | Example policies | Example procedures | Owner |
|---|---|---|---|
| 1. Governance | Policy on policies, code of conduct, conflicts of interest | How to request a policy exception | Compliance |
| 2. People | Equal employment opportunity, anti-harassment, leave and absence | How to report absence; how to raise a grievance | HR |
| 3. Information security | Acceptable use, access control, data classification | How to request system access; how to report a security incident | IT or information security |
| 4. Privacy and records | Data protection, records retention | How to respond to a request for personal data | Legal or privacy lead |
| 5. Health and safety | Health and safety, emergency action plan | How to report an incident or near miss; evacuation procedure | Health and safety |
| 6. Finance | Expenses, purchasing, delegated authority | How to submit an expense claim; how to raise a purchase order | Finance |
| 7. Operations | Quality, customer complaints | Daily opening checks; how to log and resolve a complaint | Operations |
Example entry: a policy with its procedure
| Policy: IS-03 Access control (version 2.0) | Procedure: IS-03-P1 Requesting system access |
|---|---|
| Purpose: Protect company and customer data by limiting access to the people who need it. Scope: All employees, contractors and systems that hold company data. Policy statement: Access is granted only for a defined business need, approved by the employee’s manager, reviewed every six months and removed when no longer needed. Owner: Head of Information Security. Approver: Executive team. |
1. The manager submits an access request on the service desk portal, naming the system and the business need. 2. The system owner approves or rejects the request within 2 business days. 3. IT grants access by adding the employee to the matching security group. 4. IT records the change on the request and closes it. 5. If access is no longer needed, the manager submits a removal request the same day. |
Notice how the policy says what and why in four lines, and the procedure says how in numbered steps. The review interval in this example is an illustration. Set your own based on risk and any rules that apply.
Examples of procedures manuals by department
| Manual | Who uses it | Typical procedures |
|---|---|---|
| HR procedures manual | HR and line managers | Recruitment, onboarding, absence, performance, disciplinary and grievance |
| IT procedures manual | IT and service desk | Access requests, joiners and leavers, backups, patching, incident response |
| Finance procedures manual | Finance and budget holders | Purchasing, invoice approval, expenses, month-end close |
| Health and safety manual | All staff, supervisors | Risk assessment, incident reporting, emergency evacuation, equipment checks |
| Operations procedure manual | Front-line and operations teams | Opening and closing, order handling, quality checks, customer complaints |
How to write a policy and procedure manual in 8 steps
- Inventory what you have. List every existing policy, procedure, form and informal “how we do it” document, with its owner and last review date.
- Decide the structure. Group documents by area, set an ID scheme and agree the standard sections every entry will use.
- Assign owners. Give every policy and procedure one owner, named by role, and decide who approves each level.
- Fill the gaps. Compare your list with the risks and rules that apply to you, and write the policies that are missing.
- Write in plain language. Keep policies short. Put the steps in procedures, start each step with a verb and test them on someone new to the task.
- Review and approve. Route each document to its approver, with legal, HR or quality review where needed.
- Publish one controlled version. Put the approved manual in one place that everyone uses, and remove old copies.
- Communicate, track and review. Tell people what applies to them, record that they’ve read it, and set a review date for every section.
One binder or a library? Structure the manual so it stays current
Many manuals start as a single Word file or PDF. That works for a small team, but it causes problems as the manual grows. One change to one procedure means re-issuing the whole document. Nobody can tell which pages changed, and old printed or downloaded copies stay in circulation.
A more durable approach is to treat the manual as a library of separate controlled documents, one per policy or procedure, held in a single location and joined up by the table of contents. In SharePoint that means:
- One document library for the manual, with a folder or metadata column for each section.
- Version history turned on, so each document keeps its own versions and shows who changed it and when (Microsoft Support).
- Columns for owner, approver and next review date, so the library works as your policy register.
- A front page or table of contents that links to each document, rather than copies of them.
Each section then changes on its own schedule, and the “manual” is always the current set.
Getting people to read the manual, and proving they did
Publishing a manual doesn’t mean anyone has read it. Asking every employee to read the whole manual is rarely realistic, and it produces a single sign-off that says nothing about which version or which sections they saw. A better approach:
- Assign by relevance. Everyone reads the governance and conduct sections. Each team reads the procedures it actually uses.
- Acknowledge by document, not by manual. Record a confirmation for each policy or procedure, against the version the person read.
- Re-issue on change. When a section changes, send just that section to the people it applies to and collect fresh confirmations. Some rules require this. OSHA’s emergency action plan rule, for example, requires a review with each covered employee whenever the plan changes.
- Cover joiners and movers. New starters and people who change roles should receive the sections that now apply to them automatically.
SharePoint stores the manual and its version history, but it doesn’t assign documents to readers or record that each person accepted a specific version. DocRead adds that inside SharePoint and Microsoft 365. It assigns each policy or procedure to SharePoint or Microsoft Entra ID groups, sets a reading deadline, sends reminders, escalates overdue readers to managers, and records a time-stamped acknowledgment of the exact version read. Where reading isn’t enough, an optional DocSurvey quiz checks understanding. See policy and procedure management software for SharePoint for how this works.
An acknowledgment confirms that someone read a document. It doesn’t prove they follow it, so pair it with training, supervision and audits.
Keeping the manual up to date
Set a review date for every section, and review sooner when a law, regulation, system or role changes. Keep a revision log at both levels: for each document, and for the manual as a whole.
| Version | Date | Section | Change | Approved by |
|---|---|---|---|---|
| 3.1 | March 2, 2026 | IS-03 Access control | Added six-monthly access review | Executive team |
| 3.0 | January 12, 2026 | All | Moved the manual to a SharePoint library; added policy IDs | Compliance |
Example revision log. The entries are illustrative.
Common mistakes to avoid
- Policies written like procedures. Long policies full of steps are hard to approve and quick to go out of date. Keep the steps in procedures.
- No owner or review date. Without them, sections quietly expire.
- Several copies in circulation. Publish from one place and retire old versions.
- One sign-off for the whole manual. It doesn’t show who read which section or version.
- Handbook and manual saying different things. Let the handbook summarize and link. Don’t keep two versions of the same rule.
- Writing for auditors, not users. If employees can’t follow it, it won’t be followed.
For a practical guide to getting a handbook read, see how to get employees to read and agree to your employee handbook.
Policy and procedure manual FAQ
What is a policy and procedure manual?
A policy and procedure manual is one controlled set of documents that holds an organization’s policies (what is required and why) and procedures (how to do it, step by step), with an owner, version and review date for each.
How do you write a policy and procedure manual?
Inventory your existing documents, agree a structure and ID scheme, assign an owner to each document, write the missing policies, keep policies short and procedures step by step, get each document approved, publish one controlled version and set a review date for every section.
Can you give an example of a policy and procedure manual?
A typical manual has sections for governance, people, information security, privacy, health and safety, finance and operations. Each section holds policies, such as an access control policy, and the procedures that carry them out, such as how to request system access.
What is the difference between a policy manual and an employee handbook?
A policy and procedure manual is the complete, controlled set of rules and instructions. An employee handbook is a shorter, readable summary for employees that should point to the full policies rather than repeat them.
What is an operations procedure manual?
An operations procedure manual documents how an organization’s day-to-day work gets done, task by task, such as opening checks, order handling and quality checks. It’s often a section of the wider policy and procedure manual or a separate SOP manual.
How often should a policy and procedure manual be updated?
Give every section its own review date based on risk and any rules that apply, and review sooner when a law, system or role changes. Some regulations set requirements; the HIPAA Security Rule, for example, requires periodic review of documented policies and procedures.
How do you prove employees have read the manual?
Assign each policy or procedure to the people it applies to, set a deadline, and record a time-stamped acknowledgment against the version each person read. Re-issue a section when it changes. DocRead does this inside SharePoint and Microsoft 365.
Put your manual in front of the right people
DocRead assigns each section of your policy and procedure manual to the people it applies to, follows up until they’ve read it, and keeps a time-stamped record of who confirmed which version, all inside SharePoint.
Book a demoRequest a quoteStart the 30-day SharePoint Server trial