An audit doesn't test whether your team knows the work. It tests whether your documentation can prove it. Those are two different things, and the distance between them is where most findings come from.
What is an auditor actually looking for in your SOPs?
An auditor is checking three things: that a procedure exists for the work being performed, that the version in use is the current controlled one, and that records show people followed it. Elegant writing is not on that list.
I sat on the management side of these reviews as the chief financial officer of a manufacturing company, and the pattern rarely varied. The auditor doesn't usually argue with how you run the process. They simply ask you to show them the procedure, show them it's the current version, and show them the records proving the last several runs matched it. If any link in that chain breaks, the finding gets written whether or not the work was done correctly.
Why do accurate procedures still fail an audit?
Because the documented version and the practiced version drift apart, and an audit measures the difference, not the intent. A procedure written two years ago describes a process that has changed four times since.
Drift is ordinary: equipment gets replaced, a supplier changes a spec, someone finds a better sequence. What does not happen is the document catching up. The operator does the sensible thing, the record shows the sensible thing, and the procedure on file says something else. That disagreement is the nonconformance. The fix is ownership and a revision cycle, not better prose.
What makes a procedure auditable?
Auditable means traceable. A reader can tell which version this is, who owns it, what it covers, and what evidence its execution leaves behind. Everything else is writing quality, which matters for a different reason.
- A document number, version, and effective date on every page
- A named individual owner rather than departmental ownership, one person whose name is on the document, who updates it when the process changes, and who auditors know to ask
- A revision history that says what changed and why
- A stated scope, so it's clear what the procedure doesn't cover
- References to the forms, records, and related documents it depends on
- Steps written so compliance is observable, each tied to the record it produces
- One controlled location where the current version lives
A quick way to think about that last point: "controlled" just means there's one official home for the current version, and everyone knows where it is. Anything else, such as a saved PDF, a printed copy, a page forwarded by email, is an uncontrolled copy. It might match the real thing today, but nobody's on the hook for updating it when the procedure changes, so it drifts.
If a step cannot produce evidence that it happened, it's guidance rather than procedure. Both belong in your documentation system, in different documents. Sorting them correctly is a large part of what technical writing actually does.
Which findings come up most often?
Uncontrolled copies, missing revision history, steps that generate no record, and training with no documented link to the procedure. None of those are about how well the business runs.
Uncontrolled copies are the most common and the easiest to create. A printout taped to a workstation, a PDF in someone's shared drive, a laminated card by the machine. Every one of them is a version an auditor can find and compare against the official file, and every one of them is a finding waiting to happen.
The training gap is the quieter one. A new hire gets taught by the person next to them, from a version that was superseded eight months ago. The work looks fine, yet the paper trail says the procedure was never actually trained.
How do you know which SOPs are current without rereading all of them?
Start with the procedures attached to something that changed. New equipment, new software, a new supplier, a reorganized team, a regulatory update. Drift concentrates there, and so do findings.
Second pass: the procedures people keep asking questions about. Repeated questions on documented work mean the document is not answering them, and the answer they're getting verbally is now the real procedure. Third pass: anything with no revision in three or more years. That document is either genuinely stable or quietly abandoned, and the difference is worth ferreting out before an auditor finds out for you.
What should you do if the audit is close, and the documentation is behind?
Triage by risk, not alphabetically, and fix control before you fix content. Procedures tied to safety, regulatory requirements, and customer commitments come first.
A plainly written procedure with the right version number, a named owner, and a clean record trail will pass, but a beautifully written one nobody can trace will not. If your manuals are largely correct and mainly need cleanup, consistency, and version control rather than rewriting, that is closer to an editing project than a new documentation build.
Is it worth bringing in a writer for audit readiness?
It's worth it when the people who understand the process are the same people who cannot find time to document it, which is most companies. That is the bottleneck, and it doesn't resolve on its own before a deadline.
An outside writer observes the work, drafts procedures a new hire can follow, and builds the version control and record structure an auditor expects to see. Technical projects are scoped individually and can include process design and staff interviews alongside the writing. Common questions about how that works are answered on the FAQ page, and if you want to talk through what your documentation needs before your next audit, book a discovery call.
Frequently asked questions
What do auditors look for in an SOP?
Auditors check that a procedure exists for the work being performed, that the version in use is the current controlled one, and that records show the procedure was followed. Writing quality matters far less to the outcome than whether that chain of evidence holds together.
Why do SOPs fail audits even when the work is done correctly?
Because the documented version and the practiced version drift apart over time. Equipment, suppliers, and sequences change while the document stays as written, so the records and the procedure disagree. The audit measures that difference rather than the quality of the work.
What makes a procedure auditable?
Traceability. Every page carries a document number, version, and effective date. The procedure has a named owner, a revision history explaining what changed, a stated scope, references to the forms and records it depends on, and one controlled location where the current version lives.
What should you fix first when an audit is coming and documentation is behind?
Triage by risk rather than alphabetically, and fix version control before content. Procedures tied to safety, regulatory requirements, and customer commitments come first. A plain procedure with a clean version and record trail passes; a polished one nobody can trace does not.
