What an IATF 16949 auditor actually asks for on traceability
Clause references are easy to quote and not much use at 09:00 on audit day. This is what gets asked for in the room, and what a record has to contain to answer it.
The question underneath every traceability question
An auditor is testing one thing: if this part comes back from the field, can you bound the problem? Everything else — the records, the labels, the retention policy — is instrumentation for that single question. When a supplier fails a traceability finding it is almost never because a document was missing. It is because the answer to "which other units are affected" was an estimate.
What gets asked for, in order
- 01Pick a finished unit at random from stock. Show me its build record.
- 02Show me the components that went into it, by lot or serial, and where those lot numbers are recorded.
- 03Show me the process parameters that were specified for it, and the values actually captured.
- 04Show me who performed that operation and evidence that they were qualified to.
- 05Now go the other way. Here is a component lot. Which finished units contain it, and where did they go?
- 06Show me a unit that failed and was reworked. Show me the rework was authorised and the affected operations were repeated.
- 07How do I know these records have not been edited since they were captured?
Questions one to four are answerable from most systems, including a well-kept set of spreadsheets. Question five is where batch-level records fail. Questions six and seven are where nearly everybody fails.
Why batch records fail question five
A batch record ties a day's production to a set of component lots. When one of those lots is bad, the affected set is the entire batch, because the record cannot distinguish within it. If you build 400 units a day and the bad lot was consumed by 60 of them, a batch record forces you to contain 400.
That is not a documentation problem, it is a cost problem, and it recurs every time. The fix is to record consumption at the unit, at the operation that consumed it.
What a per-unit record has to contain
| Element | Why the auditor wants it |
|---|---|
| Unique unit identity, on the part | Without it, the record and the object cannot be connected in the field |
| Job card and product revision | Ties the unit to the specification that applied at the time |
| Every component lot or serial consumed, with the operation | The forward trace depends on it |
| Captured process values with the limits that applied | A value without its limit proves nothing |
| The instrument that produced each reading | Lets you bound a containment when an instrument drifts |
| Operator identity and qualification | Clause 7.2 competence, evidenced per operation |
| Rework and repair history, including what was invalidated | A rework loop that is invisible in the record is a finding |
| Evidence of integrity | Answers question seven |
Question six: rework that stays visible
A common failure is a system that lets an operator redo a failed operation so the record shows only the passing result. That is a record of what you wish had happened. What an auditor wants to see is the failure, the authorisation to rework, which operations were invalidated by it, and those operations being performed again.
In Trace a rework path names the operation the unit returns to and the operations whose completion is voided by it. Those operations must be performed again before the unit can advance, and both attempts stay in the record.
Question seven: proving the record was not edited
This is the question most systems answer with "we have user permissions", which is an answer about access control, not integrity. It does not cover anyone with database access, and auditors know it.
A stronger answer has two parts. First, the records are append-only, enforced by the database rather than by application code, so there is no code path — and no SQL prompt — that updates or deletes a captured measurement. Second, each record carries a hash of the one before it, forming a chain per unit. Altering a historical row breaks every link after it, and the chain can be recomputed on demand.
Corrections still have to be possible, because readings do genuinely get recorded against the wrong unit. The correct shape is a new row that supersedes the old one, carrying a reason and the operator who authorised it, with the original left in place. An auditor who sees corrections handled that way trusts the rest of the record more, not less.
Practical preparation
- Pick three finished units from stock yourself and walk questions one to seven. Time it. If any answer takes more than a few minutes, that is your finding waiting to happen.
- Pick a component lot from a supplier invoice and try the forward trace cold. Most plants discover here that the lot number was never captured at the station.
- Check that your captured values carry the limits that applied at the time, not today's limits. Specifications change.
- Check that a reworked unit's record shows the failure, not just the eventual pass.
Written by Dinesh Kumar G, ElectronIx, Coimbatore. If something here is wrong or incomplete for your process, tell us — we would rather fix it.