Writing an SOP That Survives the Audit

Every laboratory that has been through an ISO 9001 certification has a folder of standard operating procedures. A good proportion of those folders contain documents nobody has opened since the assessment, describing a method that has since changed twice.

That is the failure mode worth designing against, and it is not really an audit failure. An auditor who finds a procedure being followed exactly as written, with records to show it, will pass a modest quality system. An auditor who finds an immaculate document and an analyst doing something else has found the one thing they are looking for, and no amount of formatting rescues it.

So the test of a procedure is not whether it reads well. It is whether the person doing the work at seven in the evening, without the person who developed the method, can follow it and get the right answer.

What an assessor is actually checking

Three things, in this order, and they are simpler than most people expect.

Does a documented procedure exist for the activity. Is the version in use the current one. Is there evidence it was followed, by someone trained to follow it.

Almost every non-conformance traces back to one of those three. Not to the prose, not to the template, and not to how thorough the theory section is.

The four ways procedures fail in practice

They record intent instead of instruction. "The sample is filtered and analysed by HPLC" is a description of what happens. It is not a procedure. Which filter, what pore size, what dilution, which column, what mobile phase, what injection volume, what integration parameters. If a competent analyst who has not done this method before cannot get the same result, it is not written yet.

They leave the acceptance criteria out. A procedure that says to run a system suitability injection but does not say what makes it acceptable has moved the decision from the document into somebody's memory. Every measured thing needs the range it has to be inside and the instruction for what to do when it is not. That last part is the one usually missing, and it is the part that gets used.

They are written by the person who developed the method. Developers know the things they never wrote down. That the solution must be prepared fresh. That the reagent goes in slowly at the start. That the reading drifts for the first two minutes. These are not omissions from carelessness; they are invisible to the author precisely because they are automatic. The only reliable fix is to have someone else run the method from the document alone and note every point at which they had to ask a question.

They describe an instrument that has been replaced. A procedure naming a specific detector, a specific software version, a specific column part number is correct on the day it is issued and quietly wrong two years later. Reference the requirement, then record the equipment actually used in the record rather than in the procedure.

Version control is most of the discipline

If a procedure is worth having, exactly one version of it is in force at any moment, and everybody can tell which.

That means each document carries a number and a revision, an effective date, an author, and an approver. It means superseded copies are removed from the bench rather than left in the folder behind the current one, because a printed copy of revision two sitting next to revision three will be used eventually. It means changes are recorded with a reason, since the question at an audit is not only what changed but why.

None of this needs software. A controlled register listing every procedure, its current revision and its review date will hold a small laboratory perfectly well, provided somebody owns it.

Training records are part of the procedure

A procedure only counts as implemented when the people doing the work are recorded as trained on the current revision.

This is the part most often skipped, and it is also the easiest to fix. When a revision is issued, the people who use it read it and sign that they have. When someone new joins, their training against each relevant procedure is recorded. When a method changes materially, retraining happens rather than an email.

The reason to do this properly is not the audit. It is that this record is what tells you, when a result is questioned six months later, whether the person who produced it was working to the version you think they were.

Fixing the folder you already have

Nobody should rewrite forty procedures at once, and an attempt to do so is usually abandoned halfway, leaving a system half in one state and half in another.

A workable sequence: list every procedure and mark which are actually in weekly use, which is usually a much shorter list than the folder suggests. Take those in order of use and have someone other than the author run each from the document alone. Fix what they had to ask about. Add the acceptance criteria and the out-of-range instruction. Then set a review date and put it in a calendar, because a procedure with no review date will not be reviewed.

The remainder can wait. A small number of procedures that are genuinely correct and genuinely followed is a better quality system than a complete set that is neither.

We hold ISO 9001, ISO 14001 and ISO 45001, and we write and maintain method procedures both for our own laboratory and as a documentation service for clients building a quality system for the first time. If you have a folder of procedures you suspect nobody uses, the cheapest diagnostic is the one described above: hand one to someone who did not write it and watch where they stop.