Audit Evidence Preparation

Audit questions follow a fixed route: you say you do this, do you in fact do it, how do you know you are still doing it, and did you still do it after you changed something. Applied to a vision system, that route needs four documents and three traceability chains. A well prepared site can put the relevant paper in an auditor's hand within a minute or two of the question. A site that is not prepared ends up explaining verbally, and a verbal explanation is not evidence.

The four documents

The change record is the one most often missing, for an understandable reason. Adjusting a parameter on a vision station is quick and feels trivial — a threshold, an exposure, a light repositioned, a few minutes of work. Whoever does it does not experience it as a change. To an auditor it is a change to how the criteria are implemented, and it needs a record and a re-validation. A typical finding reads "provide records of all parameter changes to this system in the last twelve months, together with verification after each change", and if that cannot be produced, the quality of the other three documents will not save the result.

The three chains

• From a part to its record. The auditor picks up a work in progress or a lot number and asks how it was judged and where the result is. The station has to produce the record for that part, or failing that for that lot, immediately. This chain tests retrieval, not criteria.
• From a record to the criteria. Starting from a record, the auditor asks which version of the criteria was in force. That means each record has to carry a criteria version or effective date. Many sites record results but not versions, and the chain stops here.
• From the criteria to the approver. Starting from the criteria document, the auditor asks who approved this revision, on what basis, and whether the customer acknowledged it. This needs a signature on the revision and, where applicable, a customer acknowledgement tied to that version.

Questions that catch people out

• "Did you define these criteria, or did the customer?" There needs to be a clear answer about the source. If it was defined in house, be ready to explain the basis — process requirements, customer specification, industry practice — and whether the customer is aware of it. Vagueness invites further digging.
• "When did the system last get something wrong, and what did you do?" This tests exception handling. "It never has" is not usually accepted and suggests nobody is watching. The stronger answer is the record of an exception: how it was found, what was affected, what was done and what prevents a repeat.
• "If someone else operated this tomorrow, would they get the same result?" This is about standardisation, and it calls for operating instructions, evidence that parameters are controlled, and training records — which is where the alignment training above becomes audit evidence.
• "How many times has this system been changed, and did the results shift?" Straight at the change record. The number of changes is not the issue; the absence of records is.