A product safety file audit: reading one file the way an authority would

Starting from the file flatters the file, because the file describes the product it wishes it were. Starting from the product as sold, its label, its listing, its parts, its instructions, grounds the audit in reality, and the file is then judged by how well it explains that reality.

The product first method also reveals missing elements quickly. A warning on the product that the file never mentions, a part on the product that the file never lists, or a batch code on the product that the file never traces, each appears immediately when product and file are compared side by side. That comparison is the core technique of a file audit, and it requires the physical product, not just its paperwork.

Scope matching checks that every document in the file actually covers the product version, batch, and market being audited. The auditor should list each document's model, version, date, and scope, and compare that list against the product's identity. Mismatches, such as a test report for an earlier version or a supplier certificate for a different material, should be recorded as findings, with the document and the product detail that mismatch, so the fix is precise.

Scope matching should also check market coverage. A file that proves safety for one market may not prove it for another, where language, labelling, or market rules differ. The auditor should ask, for each market the product is sold in, whether the file contains the evidence and labelling for that market, or whether the file silently assumes one market's evidence covers all.

Link checking follows the file's reasoning chain: the risk assessment names hazards and controls, the test evidence proves the controls, the batch records show which units the evidence covers, the labelling carries the warnings the assessment requires, and the complaint log shows whether the controls held in use. A break anywhere in that chain weakens the whole file, because a control without evidence is an assertion, and evidence without a batch link is a result without a product.

The auditor should draw the chain, even informally, noting each link and its document, and marking breaks. That drawing turns a file audit from a page turning exercise into a reasoning check, and it produces findings that are easy to fix, because each break names the missing link. Illustration: an auditor draws the chain for a heater file and finds the assessment requires a cut out test, but no test report for the cut out exists, a single break that explains the file's weakness.

Currency checking asks whether the file reflects the product as sold today, after all its changes. The auditor should list product changes since the file's creation, from design, supplier, material, labelling, or packaging changes, and check whether each change updated the file: assessment revised, tests repeated where needed, labels updated, supplier documents refreshed. A change without a file update is a finding, even where the change itself was sound, because the file no longer describes the product.

Currency also covers document expiry and review dates. Supplier documents, test evidence, and assessments that carry review dates should be checked against those dates, and overdue reviews should be recorded as findings. A file whose documents are all technically present but several years past review is a file that has not been maintained, and maintenance is part of what an audit judges.

Honesty checking compares each claim in the file, and in the product's listing and labelling, against the evidence that supports it. The auditor should ask, for each safety claim, what document proves it, what that document's scope and limits are, and whether the claim exceeds them. A claim that a product is fully tested, supported only by a single property test, is overclaiming. A claim that a product meets a standard, supported only by a supplier's word, is overclaiming. Each overclaim should be recorded with the claim and the evidence gap.

Honesty checking should be done without assuming bad faith. Most overclaiming comes from enthusiasm, copying, or misunderstanding, and the audit finding should state the gap factually, allowing the file owner to correct the claim or supply the missing evidence. A file corrected for honesty becomes stronger, because its remaining claims can then be trusted.

A file audit report should contain the product audited, the documents reviewed, the method used, the findings with evidence and risk grades, the strengths found, and the actions with owners and dates. It should be brief enough to be read and acted on, and specific enough that each action can be verified at the next audit. A report that lists findings without actions is a description, not an audit outcome, and it will not change the file.

The report should be filed with the product file itself, so the next auditor can see what was found and what was fixed. That filing turns audits into a history of improvement, rather than a series of isolated exercises, and it allows a future authority, reading the file, to see that the business audits itself seriously and acts on what it finds.