SOP versus policy versus employee handbook

Policy, SOP, and handbook are three document kinds teams mash into one PDF and then argue about which clause to update. Keep them distinct. A policy states rules: what must or must not happen, who is in scope, and what happens when a rule is broken. An SOP (standard operating procedure) is the how-to for a named job: numbered steps a person can follow today. A handbook is a collection — a pack of policies and related employee text, not a third kind of rule and not an SOP by another name. Document structure for procedures lives on the SOP template. Authoring, categories, assignment, receipts, and revision control live on Dayzen SOP management. A worked policy example — not an SOP — is the leave-policy template. This page is taxonomy. It does not reprint the SOP field list and does not issue a legal packing list of handbook chapters.

Why the three words collapsed

In a small office one person writes the leave rules, the punch-regularisation steps, and the welcome pack, so the file is called “HR policy” regardless of what is inside. In a larger company Legal owns policies, Operations owns SOPs, and Communications owns the handbook, and Slack still says “update the policy” for a screen-by-screen click path. The cost is operational: people follow a rule that has no steps, or they treat a step list as if it were a rule they can waive in chat, or they hunt a 80-page handbook for a five-step job they must do before noon.

Use the three labels as different objects with different owners, artefacts, and done definitions. Then a leave change can update the policy once, the attendance SOP once, and the handbook excerpt once, without pretending those three files are the same artefact.

Policy: the rules

A policy answers what and whether. Who may take which kind of leave. Whether late punches can be regularised. Whether a document is required before activation. What is in scope for the company, the entity, or the location. The artefacts are a titled policy, an owner, an effective date, and (when you use them) exceptions written as rules, not as tribal knowledge. The typical owner is HR with Legal or an SME reviewer when the topic is sensitive. The done definition is issued rules people can be held to — not “we showed a slide.”

Policies are allowed to be short. They are not allowed to hide the operating path inside a paragraph of values language. If the reader cannot tell whether a late mark is a policy outcome or a manager mood, you do not have a policy yet; you have a slogan.

This article will not invent a nationwide list of policies every Indian employer must issue. What you must have can depend on applicable law, contract, policy, or company practice. Verify with your HR, legal, or SME team. Handbook section names later in this page are examples of what companies often collect, not a legal requirement to publish those chapters.

When you need a policy-shaped outline for leave, use the leave-policy template. That sibling is a policy example. Do not convert it into an SOP by adding click paths, and do not paste it into an SOP record as if numbered leave types were a procedure.

SOP: the how-to steps

An SOP answers how a named job is done. Who starts it, what they must have in hand, the sequence of actions, what to do when the happy path fails, what evidence to keep, and which version is current. The artefacts are the procedure text (rich text in the system of record), a category, an assignment audience, and a revision history. The typical owner is the process owner for that job — often HR operations for HR jobs, a function lead for a shop-floor or finance job — not “whoever last edited the handbook.” The done definition is that a trained person can complete the job from the steps without a hallway briefing.

Dayzen SOP management is the product surface for procedures: rich-text authoring, categories, assignment and distribution rules, My SOPs read receipts, compliance reports, revision control, and welcome SOP assignment on activation. It does not generate SOPs with AI. It does not search an AI knowledge base. It is not a second policy template. Helpdesk is not this topic; do not treat SOP assignment as a ticket queue.

If you say “the SOP is out of date,” mean the procedure steps. If the rule changed (for example, who may approve leave), that is a policy change that may force an SOP revision. Keep the objects separate even when one change touches both.

The SOP template owns purpose, scope, owner, steps, and the rest of the skeleton. This taxonomy page only needs you to stop calling a step list a policy and stop calling a policy a handbook.

Handbook: a collection, not a third rule engine

A handbook is how you bundle employee-facing text: policies, summaries, and orientation notes in one pack people can find. It is not a replacement SOP. It is not a legal instrument merely because it is bound or PDF’d. The artefacts are a table of contents, issued chapters or links, a version or issue date for the pack, and a place employees can open it. The typical owner is HR communications or HR operations. The done definition is that a joiner can find the issued rules without asking three inboxes — not that every operating click path lives in chapter 12.

Handbooks go stale when they duplicate SOPs in long prose. Point the handbook at the live policy for rules and at the live SOP for jobs. Reprinting both inside the pack is how you get three contradictory late-mark stories.

Contents you might put in a handbook are examples only: a welcome note, a pointer to the leave policy, a pointer to attendance expectations, a code-of-conduct summary, how to raise a concern, where to find SOPs. That list is not a claim that Indian law requires every employer to publish those chapters in that order. Do not treat this paragraph as a statutory packing list. Verify with your HR, legal, or SME team what you must issue for your establishments.

A comparison you can paste into a RACI

	Policy	SOP	Handbook
Object	Rules: must / must not	How a named job is done	Collection of employee-facing text
Typical owner	HR with reviewer as needed	Process owner for that job	HR communications or HR ops
Artefact	Issued policy, effective date	Procedure, category, assignment, revision	Pack, contents, issue date
Done when	People can be held to the rule	A person can complete the job from the steps	Employees can find the issued pack
Dayzen role	Not a policy CMS; configure products from issued rules	SOP management authors and assigns procedures	Not a handbook publisher; do not dump the pack as one SOP

If one human wears all three hats, still keep three done definitions. Same operator, three objects.

Overlaps that are allowed

A leave change often needs all three: the leave policy (rules and types), an SOP for how to apply and approve in the system, and a handbook paragraph that points to both. Sequence the work: issue the rule, then update the steps, then refresh the pack pointer. Do not rewrite the SOP into the policy “so there is only one file.”

A welcome SOP assigned at activation can tell a joiner where the handbook is and which procedures to read first. That assignment is SOP work. The handbook remains a collection. Activation remains onboarding. Do not merge those objects because they happen in the same week.

Attendance regularisation is a good seam test. The policy says whether regularisation exists and who may approve. The SOP says which screen, which fields, and what evidence. The handbook may say “see the attendance policy; do not regularise in chat.” Three sentences, three objects.

What this page will not become

It will not become the SOP template. Field names, purpose, scope, and review blocks stay on that template. Mentioning “steps” here is a definition, not a reprint of the skeleton.

It will not become a leave-policy chapter. Types, sandwich pointers, and year-end placeholders stay on the leave-policy template. That page is the policy example this taxonomy needs; it is not an SOP.

It will not become a product walkthrough of categories, receipts, or revision screens. Those live on SOP management and on sibling articles for writing, receipts, versioning, and assignment.

It will not claim Dayzen publishes employee handbooks, generates procedures with AI, or files anything with a government. It will not claim this taxonomy is legal advice.

Language to use in status updates

Prefer three sentences:

• “Policy: leave rules issued 1 April; owner Priya; sandwich clause unchanged.”
• “SOP: apply-and-approve procedure v3 effective Monday; assigned to managers.”
• “Handbook: pack reissued with pointers only; no new rules inside the PDF.”

If a leader asks “did we update the policy?” answer with the object they mean, or answer all three. A single yes is how a PDF handbook is refreshed while the live SOP still describes last year’s screen.

Rules, steps, collection. Three objects. If your emails use only “policy,” you will edit the wrong file and train people on the wrong artefact.

Keep policies as issued rules. Keep SOPs as jobs in Dayzen SOP management, structured from the SOP template. Keep the handbook as a pack of pointers and employee text. Point the leave-policy template at anyone who wants a policy-shaped outline. Point the SOP template at anyone who wants section headings for a procedure. This page only keeps the three words from collapsing.