Documenting for an audit
An auditor is not grading your prose. They are checking whether the document is controlled, whether it matches what people do, and whether you can show it.
What an auditor is actually checking when they ask for a procedure, and why the document is the smaller half of it.
The document is the smaller half
Teams preparing for an audit usually spend their time improving the prose of their procedures. That is the part least likely to be questioned. An auditor is generally checking three other things: that the document is controlled, that it matches what people actually do, and that you can produce evidence of both.
A plain, short, slightly inelegant procedure that is numbered, current, and genuinely followed will fare better than a polished one that nobody uses.
Controlled means identifiable
A controlled document has a number, a revision, an owner and a review date, and there is exactly one current version of it. Without those, an auditor cannot establish which document was in force when the work was done — and that question is usually the one being asked.
This is the practical reason every page on this site carries a control block, including this one. Document control basics covers the discipline in full.
The failure mode is a folder of files with names like final-v3-updated.docx. It is not that the auditor dislikes the naming; it is that nobody in the room can say which one is current, and that answer is itself the finding.
Matching reality beats completeness
The single largest source of findings is a gap between the written procedure and the observed practice. An auditor reads the SOP, then asks someone to walk them through the task, and compares.
This is why an aspirational document is dangerous. Writing down the process you intend to have creates a documented standard you are visibly not meeting, which is a worse position than having no document — you have supplied the evidence against yourself.
If the real procedure has a step that is untidy but works, document the untidy step. Then improve it deliberately and revise the document. Fixing the practice and the paper in that order is the only sequence that does not create a gap.
Evidence that it was followed
A procedure states what should happen. Records show that it did. In most schemes it is the records that carry the weight — the completed checklist, the signed form, the log, the dated inspection result.
So a procedure that requires a check should say where the result of that check is recorded, and that record should exist. A step with no output leaves nothing for anyone to examine later, including you.
This is worth designing in when the SOP is written rather than reconstructing before an audit. Reconstruction is both painful and, if it produces records after the fact, exactly the thing you must not do.
The questions that come up
Who owns this document? Someone by name or role, not “the team”.
When was it last reviewed, and by whom? A review date in the future is not a review. A control block that updates itself on every publish is not a review either — it is a timestamp, and it is worth knowing the difference before someone asks.
How do people know the current version? A location, an intranet page, a folder that is genuinely the one people use.
What happens when someone cannot follow it? Every procedure meets a case it does not cover. Having a stated route for that — who to ask, how the exception is recorded — reads as maturity rather than as a gap.
What this site can and cannot tell you
The templates here are starting structures. They are not written to any particular scheme, and nothing on this site states what a specific standard, regulator or auditor requires — those differ by scheme, by sector and by jurisdiction, and anything that would have legal or contractual effect should be reviewed by someone qualified in the relevant place.
What is portable across schemes is the underlying discipline: a numbered document, a named owner, a real review, a version people can find, and records that show the work happened. Every template here carries that structure, which is the part that transfers.
The quality inspection SOP and the incident report are the two templates here that produce records rather than only describing work.
Editor's notes
Written by Free Biz Docs about the document above — not reader submissions.
The control block on this page is a timestamp
The post warns that a control block updating itself on every publish is not a review, and every page on this site carries a control block whose Last reviewed field is generated at build time. It moves when the site deploys, not when anyone reads the page.
It is left visible rather than quietly removed because the block demonstrates the structure a controlled document has, and because a site that prints the warning and then hides the case where it applies to itself would be worth less on everything else. Treat that field as a publication date. Your own documents need the other kind.
No standard is named anywhere, and that is the site's hardest limit
A post about audits that never says what any scheme requires is close to useless for the reader who arrived with a specific certification in mind. The final section says so directly rather than leaving it to be discovered.
Requirements differ by scheme, by sector and by jurisdiction, and they are revised. A template site that told you what an auditor wants would be guessing on a question where being wrong costs a finding. What is offered instead is the structure that is common underneath, which is real but is not a substitute for reading your own scheme.
One line on the page carries a weight the rest does not
"Reconstruction is both painful and, if it produces records after the fact, exactly the thing you must not do." Everything else on the page is about being better prepared. That sentence is about a line you should not cross, and creating records dated as though they were made at the time is a different category of problem from an untidy document.
This site gives no legal advice and this note is not any. It is only a flag that the sentence is doing something the others are not.
These documents are starting structures for you to build on, not professional or legal advice. Anything that will have legal or contractual effect, or that varies by jurisdiction, should be reviewed by someone qualified in the relevant place.
Common questions
- What does an auditor actually look for in a procedure?
- Generally three things beyond the prose: that the document is controlled — number, revision, owner, one current version; that it matches what people actually do; and that you can produce records showing the work happened. A plain procedure that is current and followed fares better than a polished one nobody uses.
- Should I document the process we want or the process we have?
- The one you have, even where it is untidy. An aspirational document creates a documented standard you are visibly not meeting, which is worse than having none — you have supplied the evidence yourself. Fix the practice first, then revise the document.
- Why do records matter more than the procedure?
- A procedure states what should happen; records show that it did. A step with no output leaves nothing for anyone to examine later, including you — so a procedure requiring a check should say where the result is recorded, and that record should exist.
- What is wrong with files named final-v3-updated?
- Not the naming itself — that nobody in the room can say which version was in force when the work was done. That question is usually the one being asked, and being unable to answer it is itself the finding.
- Does this site tell me what my audit requires?
- No. Requirements differ by scheme, sector and jurisdiction, and nothing here states what a specific standard or regulator demands. What is portable is the discipline underneath: a numbered document, a named owner, a real review, a findable version, and records.