You prevent procedural drift by treating a procedure as a living agreement between the people who wrote it and the people who run it. Involve the doers when you write it. Record the reasoning and the exceptions, not only the steps. Review it on a schedule and after every incident. Retire old versions. Check regularly that the written process and the real process still match. Drift is not a discipline problem. It is what happens when documentation stops keeping pace with the work.
Below is how drift starts, what it looks like on an ordinary team, and a practical routine for stopping it without burying people in paperwork.
TL;DR
- Procedural drift is the slow, unintentional uncoupling of daily practice from written procedure. It builds on quiet days when nothing goes wrong.
- It accelerates when new people inherit steps without the reasoning behind them and turn to coworkers instead of the document.
- Prevent it by involving users in writing procedures, capturing exceptions and rationale, setting review triggers, and removing outdated versions.
- Monitor adherence by asking where the document and the work differ, not by punishing deviations. Every workaround is information.
- Handoffs and onboarding are the highest-risk moments, so capture expert judgment before people move on.
Table of Contents
- What procedural drift actually is
- Why practice drifts away from procedure
- Warning signs your workflow is drifting
- A practical routine to prevent procedural drift
- What documents hold and what people hold
- Our perspective
- Handoffs and onboarding: where drift starts
- Putting it to work with Kept
- FAQ
- Sources
What procedural drift actually is
Scott Snook coined the term in his study of a friendly-fire incident. He described the slow, steady uncoupling of practice from written procedure. Researchers also call it practical drift. It is gradual, unintentional and path-dependent, which makes a drifted routine more likely to come back and settle in as habit.
The word unintentional matters. Nobody wakes up and decides to abandon the SOP. Someone skips a step that never seemed to matter. It works. Next week a colleague copies the shortcut. A month later it is simply how the job is done, and the document describes a process that no longer exists.
That is how drift differs from ordinary non-compliance. Non-compliance is a choice made against a rule. Drift is a routine that formed because the procedure's demands and the situation's demands stopped matching, and nobody noticed the gap opening.

Why practice drifts away from procedure
Three forces show up again and again in the research.
Quiet days teach the wrong lesson
James Leemann, writing in a safety trade publication, notes that drift is reinforced daily when employees ask coworkers for advice instead of consulting procedures. Each uneventful day also makes it harder to persuade people that the rules matter. A shortcut that has worked 200 times feels safe, even when the procedure existed for the 201st.
Diane Vaughan's analysis of the Challenger disaster gave this pattern a name: normalization of deviance, where unacceptable practices become acceptable because repeating them has not yet produced a catastrophe. Your team is probably not launching shuttles. The mechanism is the same in a billing workflow, a clinical handoff or a release checklist.

Successors inherit steps without reasons
In his paper on procedural drift in commercial aviation, Johnston explains that every system develops a contingent daily logic of work practice, supported by a social network that evolves alongside it. Drift speeds up when new personnel do not know the rationale and assumptions behind the original design. The history behind a decision is often unclear to successors, who interpret the rule instead of learning its intent.
This is the part most documentation programs miss. A procedure says do X. It rarely says do X because of the failure we had in 2019, except when the customer is on a legacy contract. When the person who knew that leaves, the step becomes a ceremony, and ceremony steps are the first to be dropped.
Procedures written by people who do not do the work
An IChemE paper on operating procedures observes that many SOPs in high-hazard industries bear little relationship to how the plant is actually operated because they are written by people with limited practical experience. The consequences it lists: untested methods creep in, shifts behave inconsistently, and the organization wastes the tacit knowledge its operators hold.
Johnston adds a related point. Fixes aimed at drift tend to be over-designed, because the authors do not always have to work inside the system or carry the burden of impractical rules. Heavier procedures then drift faster, because people route around them.
Warning signs your workflow is drifting
Drift is quiet, but it leaves traces. Watch for these:
- Different answers to the same question. Ask three people how a process works. If you get three versions, the document is no longer the source of truth.
- New hires told to ignore the documentation. "Don't worry about that step, nobody does it" is the clearest signal there is.
- Private notes and side channels. Personal checklists, saved messages and unofficial spreadsheets fill the space the official procedure leaves empty. The HSE guidance on procedures asks directly whether operators keep what it calls black books, meaning private notebooks of how the task is really done.
- Exceptions that are no longer exceptional. When a "special case" happens weekly, it is the process.
- Veteran shortcuts becoming standard. An undocumented step that only the longest-tenured people perform is knowledge at risk.
- Questions that go to a person, not the document. If everyone asks the same two experts, the real procedure lives in their heads.
None of these means people are careless. They mean the written process has stopped answering the questions the work raises.
A practical routine to prevent procedural drift
The steps below follow the HSE's recommendations on procedures and the OSHA guidance on worker involvement, adapted for ordinary business workflows.
1. Write procedures with the people who use them
The HSE states that procedure users should be involved in writing procedures to encourage ownership and compliance. It also says this does not mean handing the job to one individual. The aim is active input from as many users as possible, across different teams and shifts. OSHA makes the same case for safety programs: worker input at every step creates a sense of ownership, helps people understand how the program works and helps sustain it over time.
In practice, that means interviewing the people who run the process before you draft anything. Our guide to five questions for subject-matter-expert interviews shows how to pull out tacit decisions in about an hour.
2. Capture the why and the exceptions, not only the steps
A step list tells a newcomer what to do on a normal day. It does not tell them what to do on the abnormal day, which is when drift is born. For every load-bearing step, record three things:
- What the step is.
- Why it exists, including what went wrong before it was added.
- When it can be adapted, and who decides.
That third item is the one most documents lack. If people have no sanctioned way to adapt a step, they will adapt it silently. See process documentation examples that capture exceptions for how this looks on the page, and why we capture decisions, not steps.
3. Tie reviews to triggers, not only calendars
An annual review is better than none, but drift does not wait for January. The HSE recommends a process to keep procedures valid and up to date, plus a process to review the relevant procedural controls after an incident or audit non-compliance. Combine both:
| Trigger | What to review |
|---|---|
| Scheduled cycle (for example, twice a year for critical processes) | The full procedure, against how it is really done |
| Incident, near miss or audit finding | The steps involved, and whether people were following them |
| Tool, system or policy change | Every procedure that touches the change |
| Team change or departure of an expert | Who holds the undocumented parts |
| Repeated exception requests | Whether the exception should become a documented branch |
Recording why each change was made helps the next reviewer. Our piece on process version control that keeps the reasoning covers this, and audit-ready process change documentation covers what managers should log.
4. Retire outdated versions and train on updates
The same HSE guidance lists a formal mechanism to remove out-of-date procedures and another to make sure staff are trained in new or updated ones. Both are easy to skip. A superseded document that is still in the shared drive is a drift engine: someone will find it, trust it and teach it.
Approval is part of this. Updates that stall in review leave people working from stale instructions, or working around them. A clear document approval workflow with named roles keeps changes moving, and our walkthrough of SOP approval stages, roles and fixes for stalls shows where they usually get stuck.
5. Monitor adherence without making procedures impractical
This is the balance leaders struggle with. Tighten monitoring into policing and people hide their workarounds. Loosen it and drift continues unseen. A workable middle:
- Ask where the document is wrong, not who broke it. Regular, blame-free questions such as "which step do you skip, and why?" surface drift while it is still small.
- Use the HSE's own test questions. Are procedures always used? Are they up to date? Do they reflect how the task is performed?
- Sample real work. Walk through a recent case with the person who handled it and compare it to the written process. Differences are findings, not violations.
- Convert recurring workarounds into updates. If three people independently invented the same fix, the procedure is what needs changing.
- Prune ceremony. If a step has no recorded reason and nobody can explain it, challenge it. A shorter procedure that people follow beats a longer one they ignore.
What documents hold and what people hold
Most drift programs fail because they treat a document as the whole of the knowledge. It is not.
| What the document holds | What the person holds |
|---|---|
| The steps, in order | Which steps are load-bearing and which are ceremony |
| The standard case | The ten exceptions and how each is handled |
| The rule | The reasoning behind the rule and its history |
| Who approves | Who actually gets things unstuck |
| The tools to use | The workarounds for when the tools misbehave |
The right column is what leaves when an expert does. It is also what a successor most needs. We explore this gap in documentation captures what people do, but misses how they decide.
Our perspective
We have read a lot of procedures that were accurate on the day they were written and wrong within a year. The authors were not careless. They documented what people do, and the real value sat in how people decide.
Drift usually begins at that gap. A document records the rule. The expert carries the thresholds, the exceptions and the memory of why the rule exists. When that expert is asked to write it all down, the result is a flat list. When the same expert is interviewed, with someone asking "what do you do when this doesn't fit?", the judgment comes out.
That is the idea behind Kept. People describe their work in their own words, guided by questions that draw out exceptions and reasoning, and the platform turns that into structured workflows. The context stays attached to the steps, so a successor inherits the logic as well as the sequence. Workspaces are opt-in, with clear control over who owns the knowledge and when it is deleted.
We think procedure owners should aim to make the written process worth following, not to enforce it harder. A procedure that carries its own reasons is much harder to drift from.
Anthony
Handoffs and onboarding: where drift starts
Drift is most likely at the moment knowledge changes hands. Johnston's point about successors who cannot see the rationale applies here directly, and it is why departures and new hires deserve their own routine.
One leader quoted in a regional business magazine describes a simple practice. The departing operator records a 30-minute screen-share walking through their last five in-flight tickets and narrates the decision rules applied at each step. They pay particular attention to the rule they would not put in a standard SOP because it depended on context. The successor watches that recording before any other onboarding material. It is cheap, and it targets exactly what a document leaves out.
Knowledge transfer also pays back in speed. A software company's guide reports that a structured knowledge transfer plan can cut onboarding time by up to 40% and reduce project delays from knowledge gaps by 30 to 50%. Treat those as that vendor's reported figures, not guarantees. The same guide recommends periodic refreshers and feedback loops, which fit drift prevention well: a refresher is a scheduled moment to compare practice with procedure.
A starter checklist for any handoff:
- List the three to five processes the person owns most personally.
- Interview them on each one, with questions focused on exceptions and judgment calls.
- Have the successor run a real case alongside them.
- Update the written procedure with whatever the interview exposed.
- Revisit the process after the first 30 days, when the new owner has found the gaps.
Putting it to work with Kept
If you want the routine above without turning it into a documentation project, this is the job Kept does. Guided conversations let your people explain a process the way they would to a colleague. We structure what they say into a workflow that keeps the exceptions and the reasoning. Your team can then search it and get answers with citations back to the source.
We offer kept for you, for individuals who want to capture their own processes, and kept for business, for teams that need shared workspaces with access controls. See the plans on our pricing page. If your most pressing risk is people changing roles, look at how we handle expert handoffs, or at our onboarding use case if new hires are the concern.

FAQ
What is the difference between procedural drift and process drift?
The terms overlap heavily. Procedural or practical drift usually refers to the gradual, unintentional gap between a written procedure and everyday behavior, a term that comes from safety research. Process drift is a broader business phrase for the same divergence between how a process is documented and how it is actually performed. The fixes are the same.
How often should we review procedures to prevent drift?
There is no single correct interval. Set a regular cycle based on how critical and how volatile the process is, and add event triggers on top: incidents, audit findings, tool changes and staff departures. The HSE recommends both a process to keep procedures current and a review after incidents or audit non-compliance.
Is a workaround always a sign of drift?
Not always, but it is always worth a conversation. A workaround may point to a step that no longer fits the work, a tool that fails, or knowledge that was never documented. Treat it as input for the next procedure update rather than as a violation to be punished.
Who should own keeping a procedure accurate?
Give each procedure a named owner who actually runs or supervises the work, and involve users across teams and shifts in revisions. The HSE specifically cautions against assigning procedure writing to a single individual. The owner coordinates the updates, but the knowledge comes from the people doing the job.
Sources
- Toward a Theory of Practical Drift in Teams (UCF honors thesis, 2014)
- Practical drift and writing safety rules (ISHN, 2011)
- The Challenger Disaster: Normalisation of Deviance (Psych Safety)
- The Paradox of Rules: Procedural Drift in Commercial Aviation (Johnston, 2003)
- Intelligent Operating Procedures (IChemE)
- Revitalising Procedures for Major Hazards (HSE)
- Recommended Practices for Safety and Health Programs (OSHA)
- 18 leaders share how they preserve knowledge when key employees leave (AZ Big Media)
- Knowledge Transfer Plan: Steps, Template and Checklist (NIX United)
- Document Approval Workflow: Design It, Automate It, Prove It (CoreWorx)
