A procedure is written once and trusted for years. Somewhere along the way the supplier changes, the accounting package is upgraded, a new approval step is added by the finance director, and the document that is supposed to describe all of this stays exactly as it was. Nobody decided to let it rot. It simply sat in a folder, in a format that nobody had a reason to reopen, until a new hire followed it to the letter and did the wrong thing.
The common response is to commission a rewrite. A few weeks later the new set of procedures is exported to PDF, emailed round, and the cycle begins again. The problem is rarely the quality of the writing. It is that nothing in the business makes the document change when the work changes. This article looks at what does.
Why a PDF goes stale faster than a process changes
A PDF is a snapshot. It is good for things that should not change, such as a signed contract or a published report. A working procedure is the opposite: it describes how people actually do something, and people keep adjusting how they do it. When the document is a locked file, the only way to update it is to find the original, edit it, export it again, replace the copy in the shared folder and tell everyone. Every one of those steps is a place where the update can be abandoned, and the person who noticed the problem is usually not the person with the original file.
There is a second, quieter cause. Copies multiply. One goes into an induction pack, one is attached to a training email, one is printed and pinned to a wall in the warehouse. Even if the master is corrected, the copies remain in circulation, and staff cannot tell which version is current. Guidance on content retention from Microsoft makes the same point from the other side: one reason to manage content deliberately is to make sure users work only with content that is current and relevant to them. The goal is not just storing documents but retiring the ones that no longer apply.
Give every procedure one live home
The first fix is structural. Each procedure should exist in exactly one place that people open when they need it, not in a folder they search once and then copy from. That place can be a shared wiki, a page in your document platform or a controlled folder, as long as three things are true.
- It is editable by the people who do the work. If the only person who can change a procedure is the one who left in March, it will not change.
- It shows when it was last confirmed. A visible date, and the name of the person who confirmed it, lets a reader judge how far to trust it.
- Other places point to it rather than copy it. Training emails, onboarding checklists and system help text should link to the live page. A link cannot go out of date, while a copy always will.
If you must still produce a PDF for an auditor or a client, treat it as an output generated on demand from the live page, stamped with the date it was produced. It is a receipt, not the source.
Name an owner and a review rhythm
Documents decay when they belong to everyone. Every procedure needs a named owner, and the owner should be the person accountable for the outcome the procedure protects, not the person who happened to type it up. For a debtor follow-up routine, that is the credit controller or the finance manager. For a stock receiving routine, it is the warehouse supervisor. We explore this idea more fully in our article on why ownership needs to be explicit, and the same logic applies to the procedures that surround the software.
Next, give each procedure a review interval that matches its risk, rather than a blanket annual review that everyone ignores. A rough starting point is:
- Procedures that touch money, regulated personal information or safety: review every quarter, and immediately after any change to the system or the rule behind them.
- Procedures that support routine operations: review every six months.
- Rarely used reference material: review once a year, or retire it.
These intervals are our suggestion, not a standard. Adjust them to how quickly your own systems and rules move. What matters is that the interval is written down, a person is expected to act at the end of it, and a missed review is visible to someone senior.
Tie reviews to events, not just dates
Calendar reviews catch slow drift. They miss sudden change. The most reliable trigger for updating a procedure is the event that makes it wrong, so list those events and attach them to the owner's routine. Typical triggers include:
- a software upgrade, a new integration or a changed setting in a business system;
- a new supplier, bank, courier or payment provider;
- a change in a rule you depend on, such as a tax or labour requirement;
- a staff member saying "that is not how we do it any more";
- an incident, error or customer complaint that traces back to a step.
The same discipline is familiar from technical teams. NIST's guide to configuration management describes managing and monitoring configurations so that systems stay in a known, intended state. A procedure is the human half of that configuration. If the system changes under change control but the procedure does not, you have two halves of the same arrangement drifting apart. Add a line to your change checklist: "Which procedures does this alter, and who has been told?"
Make the document earn its place
Some procedures are never opened because nobody needs them. Retiring them keeps the rest trustworthy, because readers stop checking the date once they have been burned a few times. If a page has not been opened in a year, ask the owner whether it should exist. If staff keep asking colleagues the same question rather than reading the document, the document is failing, and the cost of that shows up in interruptions, as described in our note on the cost of repeated internal questions. When you retire a procedure, archive it with a note saying why, so that an auditor or a curious manager can still see what the rule used to be.
Keep procedures short enough to maintain
Length is a hidden cause of rot. A fifteen-page procedure with screenshots of every screen needs rework after every software update, so it will not get it. Aim for the smallest document that lets a competent person do the task correctly: purpose, who does it, the steps in order, the decision points, what to do when something goes wrong, and where the evidence is kept. Rely on the system's own help for screen-by-screen detail. A procedure that explains what must happen and why is more durable than one that describes where to click.
Test the procedure with someone who does not know it
The cheapest accuracy check is to hand the document to a person who has not done the task, and watch them try. Every point where they hesitate, ask a question or guess is a gap between the page and the work. Do this with new starters in their first month, when they are the ideal reader, and encourage them to correct what they find. Our overview of which processes need documentation first can help you decide where to begin if you cannot test them all.
Practical next actions
- List your ten most important procedures and record, for each, where the current version lives, who owns it and when it was last confirmed as accurate.
- Move each of those procedures to a single editable location, replace emailed or printed copies with links, and generate any needed PDF from that page with a date stamp.
- Write a review interval next to each procedure, shorter for anything involving money, personal information or safety, and put the dates in the owner's calendar.
- Add a question to your software and supplier change checklist asking which procedures are affected and who has been told.
- Ask the next two people who join the business to follow their procedures exactly and mark every point where the document and reality differ, then fix those within a week.
Procedures stay accurate when updating them is cheaper than working around them. Give each one a home, an owner and a trigger, and the PDF stops being the problem.
Sources and further reading
- Learn about retention policies & labels to retain or delete
- SP 800-128, Guide for Security-Focused Configuration Management of Information Systems - CSRC (last verified 10 October 2026)
- Make better use of data
Related Mellorca reading
- How to Document a Workflow People Will Actually Follow
- What Keep, Fix, Integrate, Automate, Replace or Remove Means in Practice
- Why automation documentation matters