Why your SOPs are out of date before anyone reads them

A procedure is a photograph of a process. The process keeps moving. Nothing in an ordinary operation makes the photograph move with it — so the gap opens quietly, from the day it is written.

The short answer. SOPs go out of date because the work changes and nothing connects the change to the document. They stay current when each one has a named owner, is reviewed when the work changes (with a date as a backstop), and is reviewed by checking it against real runs of the work instead of rereading it.

The usual diagnosis is that people are lazy about maintenance. That diagnosis survives because it puts the blame somewhere convenient. But consider what maintaining a procedure actually requires: somebody has to notice that the work changed, remember that a document describes it, locate that document, and care enough to edit it — all at a moment when they are busy doing the changed work. Every step in that chain is a place to fail, and none of them has an owner.

Meanwhile the cost of the gap is deferred and diffuse. Nobody is harmed on the day the SOP goes stale. The harm arrives months later, when a new hire follows it and produces a wrong result, or an auditor asks for evidence of a control and the document describes a process the business no longer runs. By then the connection to the original drift is invisible.

Four reasons procedures decay

01They were written from memory, not from the work

Most SOPs are written by asking someone to describe what they do. What comes back is a cleaned-up account: the happy path, in the order it makes sense in retrospect, with the exceptions omitted because they did not come to mind in a meeting. The document is out of date on day one, not because the process changed, but because it never matched.

This is the same gap between the stated and operational accounts of a business described in the four sources of truth. A procedure written from one source inherits that source's blind spots.

02They describe tools, not intent

A procedure that says "click the green Approve button in the top right" breaks when the vendor moves the button. A procedure that says "the operations lead approves the order once the credit check has cleared" survives a redesign, a migration, and a change of vendor. The first kind reads as more helpful and decays much faster.

The test: if you replaced the software tomorrow, how much of this document would still be true? Whatever survives is the actual procedure. The rest is a screenshot with words.

03Nothing connects the document to the work

In most operations the procedure and the process live in different worlds. The work happens in a scheduling system, an inbox, a spreadsheet; the document sits in a drive nobody opens unless onboarding someone. There is no mechanism by which changing one prompts a look at the other. Two artifacts describing the same thing, with no link between them, will diverge — that is not a failure of will, it is just what happens.

04Nobody finds out that they drifted

Stale documentation produces no error. A broken report fails loudly; a procedure that no longer matches reality fails silently, and keeps failing silently for as long as it takes for someone to follow it literally. Any fix that does not create a moment where the drift becomes visible is not a fix.

Call that widening gap SOP drift: the distance between the procedure as written and the work as it is actually done. Safety researchers study the same gap as work-as-imagined versus work-as-done.

Signs an SOP is already out of date

A few signs tell you a procedure has already drifted. They are lagging signs: by the time you notice them, the gap has been open a while.

• People ask the person who does the work instead of opening the document, or say "that's not how we do it anymore".
• New team members learn by shadowing someone, even though the procedure exists.
• It names a tool, form, role or person that is no longer there.
• Its last-edited date is older than the last change of tool, vendor or role in that process.
• The same question about the process keeps being asked, and answered differently.

Finding out which of yours are still true

Before rewriting anything, find out how bad it is. This takes an afternoon and it is worth doing before you commit to a documentation project, because it usually changes the scope.

• Pick five procedures at random — not the five you suspect are worst. A biased sample tells you what you already believe.
• For each, find the last three real instances in whatever system actually records the work. Not what people say happened. What the records show.
• Walk the document against the records, step by step. Mark each step matched, changed, skipped, or absent — where "absent" means the records show a step the document never mentions. The absent ones are the interesting category.
• Ask the person who does the work about every step you marked changed or absent. You now have three accounts of the same steps: what the document says, what the records show, and what the person says. Where they disagree is the finding, and which two agree tells you what kind of problem it is (see the questions at the end).
• Note who last edited the document and when. Compare that date to the last material change in how the work runs. The distance between those two dates is your real documentation lag, and it is usually the number that ends the argument.

Five samples is enough to tell the difference between a folder that needs editing and a folder that needs replacing.

What to do with an SOP that's out of date

The marks from the sample tell you what each procedure needs.

• Mostly matched, a few steps changed: edit it. Fix the changed steps now, and have the owner confirm them.
• Many steps skipped or absent: rewrite it from the record. Build the draft from what the systems show across several real instances, then have the person who does the work correct it. Correcting a draft surfaces the exceptions that describing from scratch never does — people recognise what is missing far more reliably than they recall it. Write each step around its intent, not the screen, so it survives the next software change. How to document a process covers the rewrite step by step.
• No real instance in the records for months: retire it. Mark it obsolete with the date, remove the links that point to it, and archive it rather than deleting it; an audit may need to see what the procedure used to say. If two documents describe the same process, merge them into one.

Whichever it is, tell the people who follow it what changed. A procedure updated silently is still out of date for everyone working from the old version.

Who should own an SOP

One named person per procedure, not per folder. "The ops team owns the documentation" means nobody owns any particular document. The owner should be the person who runs or supervises the work day to day, not whoever happened to write it.

The owner's job is small and specific: hear when the work changes, confirm the document still matches it, and approve edits. That is different from the owner of each step inside the procedure, which should be a role, never a name, so the steps survive turnover. The document names who keeps it true; the steps name who does the work.

When an owner leaves, handing over their procedures is part of the handover. Keep one short list for the whole operation: procedure, owner, date last verified, next review.

How often should SOPs be reviewed?

When the work changes, first. On a date, as a backstop.

A calendar review on its own gets deferred and then rubber-stamped in a batch. A review tied to an event catches drift when it starts, provided something notices the event. The events worth listing against each procedure:

• a tool or vendor changes, or the software is redesigned;
• a role changes, or the owner leaves;
• an error, a near miss or a complaint is traced back to the process;
• an audit finding, or a change in a regulation or a contract;
• the same question about the process is asked twice;
• an exception is handled outside the procedure.

Then set a backstop date by risk. Where a mistake costs money, safety or compliance, review at least once a year and after any incident; under a regulated quality system, its interval is the floor, not the target. Procedures tied closely to software should be checked whenever that software changes. Stable, low-risk procedures can wait a year.

What matters more than the interval is what a review is. Rereading the document only shows that it agrees with itself. A review pulls the last few real runs of the work and walks the document against them, the same way as the sample above. Stamp the result with the date it was verified and the runs it was checked against, not with "last edited". A last-edited date tells you someone touched the file; a verified date tells you it was true.

What actually closes the loop

The durable version stops treating the document as the record. When the work itself emits a record of what happened — each run, each decision, each approval, appended and not overwritten — the documentation stops being a separate artifact maintained out of goodwill and becomes something you can check against reality on demand. Drift is then a query, not a discovery.

That is what the document → build → govern → audit → improve loop is for, and why audit and improve are steps rather than aspirations. A procedure that is reviewed against its own execution record every week cannot quietly drift for months, because the disagreement shows up the first week it exists. Getting there is more work than writing an SOP. It is considerably less work than rewriting the folder every few years and getting the same result.

Common questions

Is an out-of-date SOP worse than none?

Usually, for anyone who follows it literally, because it is trusted. Until a procedure has been checked against the work, mark it unverified with a date rather than deleting it. People then know to ask before relying on it, and the record of what it used to say is kept.

How do I tell drift from people not following the SOP?

Compare the three accounts from the sample. If the records and the person agree and the document doesn't, the document has drifted: fix the document. If the document and the person agree and the records show something else, the procedure is right and the practice has slipped: fix the practice. If all three disagree, start from the records, because they are the only account written down at the time.

We already have fixed review intervals. Does this apply?

Yes. Keep the interval; it is the minimum. Checking each procedure against real runs is what makes a periodic review mean something, and your change-control process is the list of events that should trigger a review in between.

← All writing