The Systems Effect

Process Mapping & Documentation

The Process Audit Checklist: Find Out Which Documents Are Fiction

August 29, 2026

A process audit checklist is a short set of checks that tells you which of your documented processes still match the way work gets done today. It runs in four moves: ask whether anybody is using the document, list every document with its owner and last-touched date, watch one real run against the text, then score it accurate, stale, fiction, or missing. Most teams skip the first three and go straight to rewriting. That is how you pay twice for the same fiction.

The audit is not really about the documents. It is about whether they describe your company or a company you used to be.

What Is a Process Audit?

A process audit is a check of your documented processes against how the work is actually being done, ending with every process sorted into one of four buckets: accurate, stale, fiction, or missing. It is a sorting exercise, not a rewrite project.

The stance matters more than the format. We do not assume inherited documentation is accurate. We validate it against how the work gets done today, and say so when it is fiction.

Skip the audit when there is almost nothing to test. With no documentation to validate, there is no fiction to find, and the hours go further documenting the first process than scoring an empty shelf.

The unit is a process, not a file: the row reads "how we handle a cancellation", not "the cancellation PDF". If you are unsure which of the five documents people mean by process documentation you are holding, sort that first.

Question One: Is Anybody Using This?

Start here, ahead of accuracy and formatting. In three different verticals we have heard the same sentence: we already documented this years ago, we just need to dust them off. The reply is one question. Is anybody using them?

The answer is usually silence, and the silence is the finding.

One deal collapsed on that exchange. The outgoing owner of a family engineering firm waved it off, and nobody in that building had opened those documents in years. The advisor predicted they would feel the pain and call back in six to nine months.

Documentation that nobody uses is a checked box, not a system.

If nobody has opened a document this quarter, its accuracy is not the problem. Answer that first, or you finish with an accurate library and the same zero readers. It is worth knowing why SOPs collect dust before you rewrite anything.

The Process Audit Checklist: Every Document, Every Owner, Every Last-Touched Date

Now build the inventory: one row per process, five columns, in a spreadsheet you can throw away afterward.

  1. Find every document. Search the SOP platform, the shared drive, email attachments, the laminated sheet on somebody's monitor, and the group chats. One operation we audited ran on more than twenty chat threads as its source of truth.
  2. Name one owner per process. A person, not a department. Two names means no owner, and that alone predicts the score.
  3. Record the last-touched date. Any document older than the software it describes is a suspect, not a source.
  4. Record the last-opened date. Most platforms report views and most drives report last opened, answering question one with data.
  5. Count the versions. How many documents claim to cover this one process. Anything above one is a finding.

Processes with no named owner sit at the bottom of the usage column every time. If the list runs long, point the checklist at the 20 percent of processes that actually matter first.

Watch One Real Run Against the Document

Watching one real run is the step everybody wants to skip. Open the document, then sit on a screen share while the person who does the job does the job, narrating as they go. You are not testing the person. You are testing the text.

Watch the practitioner, not the manager. The manager remembers the process as designed; the practitioner runs it as it survived contact with your software, your customers, and a workaround somebody invented two years ago. We tell every expert to interrupt us: no, it does not look like that, I am actually doing this.

One exiting bookkeeper took 85 minutes just to describe a weekly commission run: two reports merged with VLOOKUP because the export strips the job IDs, chat threads screenshotted to find the helper, receipts chased through a login she did not have. It is a three-day job every week, and no document in that company described any of it.

Put minutes on every step as you watch. Minutes times frequency times headcount turns the audit into a funding case for free. Score the document against the run, not against your memory of the process.

Score Every Process: Accurate, Stale, Fiction, or Missing

Every process leaves with one of four scores. This is the part you can copy today.

ScoreWhat it meansWhat you do next
AccurateMatches the run, in useSet the next review date
StaleRight shape, wrong detailsPatch only the steps that moved
FictionDescribes work nobody doesRewrite from a recording, or delete
MissingReal process, no documentQueue by risk, not by ease

The line that matters is between stale and fiction. Stale is cheap: a screen moved, a step picked up an approval, somebody renamed a field. Fiction is expensive: a new hire follows it, gets a different result than the veteran beside her, and concludes the library lies.

Most stale scores have a structural cause. One cleaning company had process steps, training content, and software how-tos fused into one document, so every time the CRM vendor moved a button the whole thing aged. That is the rules changing while nobody updates the SOP, and the fix is splitting tool steps from process steps.

Missing is the bucket owners underestimate. When we measured 16 small businesses across 68 roles and 461 process areas, 27 percent of the work was documented on average, and half the role areas had nothing. Order those with a knowledge risk assessment, so the process that hurts most if its owner resigns goes first.

The Three Redundant Versions Problem

Duplicates are the failure mode nobody scores, because on paper three documents look like three times the coverage. The COO of a 55-person residential cleaning company described what they actually produce: a playbook grown bloated, three redundant versions of one process, nobody able to find anything. Her phrase for it was cognitive overload.

She was honest about the cause: she would start one document, get pulled into operations, start another, and never make the set cohesive. That company services 85 homes a day.

Three documents for one process do not triple your coverage; they triple the odds that somebody follows the wrong one.

The quieter version is three versions running in people's heads. In one nonprofit department, colleagues learned mid-session that they had each been running the same process differently for years. When you find three versions, do not merge them: watch one real run, write one document, and delete the other two.


What Do You Delete?

A client put the question to us in three words on a delivery call: what do we delete? It usually goes unanswered. Here are the rules we use.

  1. Delete fiction that has a replacement. Once the rewrite exists and has an owner, the old file is not a backup. It is a trap with a search ranking.
  2. Cut duplicates to one. Keep the version closest to the run you watched, not the longest or the prettiest.
  3. Archive anything legal, safety, or compliance related. Move it into a dated archive, then put its rewrite at the top of the queue.
  4. Keep nothing because it took a long time to write. Sunk cost is the most common reason a fiction survives an audit.

Rule three earns its place. One operator only reached for the safety playbook after an incident: we wait until there is a fire, then ask somebody to revisit that part. Nothing gets deleted until somebody has watched the real process and named who owns the replacement.

Set the Review Rhythm So You Never Need This Audit Again

The audit is a one-time cost. The rhythm is what stops you paying it twice.

Give every accurate document a review date before the audit closes, and every process one named owner for that date. The rhythm that holds is small: an hour a month per department, plus a short retro at the end of each wave. One nonprofit we work with adds a capacity check to the same meeting: capacity, commitments, clarity.

Sequence matters. Land the plane, put it in the system, then bend it, break it, and improve it.

Clients ask whether this means a consultant forever. It does not. You need somebody named, a date on the calendar, and a rule that the document changes the same day the process does, which is most of keeping the systems alive after the project ends.

The Systems Effect runs this audit at the start of most engagements, because inherited documentation gets validated rather than trusted. Pick the process your team interrupts you about most, pull its document, and watch somebody run it this week.

Frequently Asked Questions

What is a process audit?

A process audit compares your documented processes against the way work actually gets done, then scores each one accurate, stale, fiction, or missing. Every process leaves with a decision attached: keep, patch, rewrite, or delete.

How do you know if your SOPs are still accurate?

Watch somebody run the process while you hold the document, and mark every place the two diverge. Memory is not evidence: whoever wrote the SOP remembers it as designed, not as it runs now. Any document older than the software it describes is a suspect.

How often should you audit your processes?

Run the full audit once, then replace it with a rhythm. Give every accurate document a review date, 6 to 12 months out for stable processes and quarterly for anything built on fast-changing software. The rest is event driven: when a tool, rule, or owner changes, review that process the same month.

What do you do with outdated SOPs?

Sort them before you touch them. One with the right shape and wrong details gets patched; one describing work nobody does anymore gets rewritten from a recording or deleted. Archive rather than delete outright, into a dated folder the live library does not search.

Who should run a process audit?

One person owns the audit, and ideally it is not the person who wrote the documents. Scoring takes somebody willing to write fiction next to work a colleague spent a weekend producing, which is harder from inside the team than it sounds. Practitioners still run the process while the auditor watches.

Want help putting this into practice?