Quality data that survives an audit

Three questions, in that order

Audits look intimidating from the outside and are fairly mechanical from the inside. A registrar auditor, a customer's supplier quality engineer and a government assessor are asking versions of the same three things. Can you reconstruct what happened to this specific part, on this specific date, from records rather than from memory. Can you show that the record has not been altered since. And can you show that whoever created it was trained and authorized to do so. Everything else — the procedures, the manual, the matrices — exists to make those three answerable.

Most manufacturers pass the first question. It is the second and third that produce findings, and both are data-architecture problems rather than paperwork problems. A record that can be edited in place cannot answer the second question no matter how good the procedure says it is. A record signed from a shared login cannot answer the third one at all.

Traceability is a chain of join keys, and the keys are what break

Written out, the chain is unremarkable. A purchase order buys material. The material arrives with a certification tied to a heat or lot number. Receiving inspection accepts it. A work order consumes it. Each operation records an operator, a machine, a tool and a program revision. In-process inspection records measurements against a drawing revision. Final inspection accepts the part. A certificate of conformance goes out with the shipment.

Every arrow in that chain is a join between two systems that were bought separately, and the failures are boringly consistent. The heat number is typed by hand at receiving and typed differently on the traveller. The work order knows the part number but not which of the four identical machines ran it. The inspection record cites “Rev C” without saying Rev C of what, and the drawing was revised twice that year. The operator field holds initials that two people share.

None of these matter until an auditor picks one serial number and walks it end to end — which is exactly what an auditor does, because it is the fastest way to test a system. So the work is not more documentation. It is making each join key unambiguous at the point of capture: scan the material certificate rather than typing the lot, give every machine a permanent asset identifier that appears in the record, cite drawing revisions as a full document identifier plus revision, and give every person their own login.

Records are append-only, and corrections are new records

The single most consequential design decision is that a quality record is never edited in place. Ever. If an inspection value was entered wrong, the correction is a new entry that references the original, carries a reason, a person and a time, and leaves the original visible. The current value is derived from the history rather than stored over it.

This is what the audit-trail language in regulated environments is reaching for when it requires that a trail be computer-generated, time-stamped, and that it not obscure previously recorded information. It is also just good engineering, and it costs nothing extra if it is designed in from the start. Retrofitting it into a system built around editable rows is expensive, which is why it is worth deciding at the beginning even if nobody is currently asking.

Three properties follow from append-only and are worth stating explicitly. Timestamps come from a synchronized clock and are stored with their zone, because a plant that runs across midnight or across a daylight-saving change will otherwise produce records that appear out of order. Deletions are marks, not removals. And the identity attached to every entry is a real individual, which brings us to the finding auditors write more than any other.

Shared logins are the most common finding, and the easiest to fix

Somewhere in most plants there is a workstation logged in as QC1, or a tablet on the line that everybody uses, or a supervisor password that four people know because the system times out and the line cannot wait. Everyone knows. It has been that way for years. It is also a direct contradiction of the requirement, in essentially every framework that touches electronic records, that a signature be attributable to one identified individual.

The reason it persists is never laziness. It is that individual login was made slower than the work allows. A gloved operator at a machine will not type a twelve-character password forty times a shift, and if you make them, they will share a session instead and you will have created the exact problem you were trying to prevent. Solve the ergonomics and the compliance follows: badge taps, proximity tokens, short-lived sessions scoped to a station, biometric readers where the environment allows. Then the audit answer is straightforward and true.

The related item is what an electronic signature has to carry. Where electronic-records rules apply, a signature manifestation is expected to show the printed name of the signer, the date and time, and the meaning of the signing — reviewed, approved, verified — and to be linked to the record so it cannot be transplanted. A typed name in a text field satisfies none of that. If your system does that today, it is worth knowing before someone tells you.

The gage question that turns one finding into a recall

Calibration records usually live in their own system, and quality measurements live in another, and the link between them is often nothing but the gage number written on a form. That link is load-bearing, and here is why.

A gage is sent out for calibration and comes back found out of tolerance. The obligation at that point — in the monitoring-and-measuring-resources clauses of the common quality standards — is to assess the validity of previous measurements taken with it. If your data can answer “which parts were measured with gage 4471 between its last two calibrations,” the exposure is a bounded list you can evaluate. If it cannot, the honest answer is every part inspected at that station in that period, and the scope of the problem is set by the limits of your records rather than by the facts.

So store the gage identifier on every measurement, as a real reference rather than free text, and keep calibration events in the same queryable place. It is a small schema decision made once. It is also the difference between a contained conversation and an open-ended one.

While you are in that neighbourhood: measurement system analysis deserves more attention than it usually gets from data teams. If repeatability and reproducibility on a gage are poor, then every downstream chart, capability index and control limit built on it is precise-looking noise. The commonly cited industry guideline treats measurement variation under about 10% of the study as acceptable, 10% to 30% as conditionally acceptable depending on the application and cost, and above 30% as unacceptable — confirm the specific criterion your customer requires. The point for a data project is simple: check the measurement system before you model anything built on top of it.

If you are a defense supplier, quality records are where CUI shows up

This section is narrower and it is the one that is changing fastest. Skip it if you have no defense work.

Two categories matter and they are not the same thing. Federal Contract Information is information provided by or generated for the Government under a contract that is not intended for public release. Controlled Unclassified Information is a broader and more sensitive category defined by a government-wide program, and in manufacturing it usually arrives as controlled technical information: drawings, specifications, process definitions, test data, anything export-controlled. The distinction matters because it drives which set of requirements applies to you.

Under the Department's cybersecurity certification program, the lower level addresses Federal Contract Information and rests on a short list of basic safeguarding requirements. The higher level addresses Controlled Unclassified Information and rests on the 110 security requirements in NIST SP 800-171, at the revision your contract clause cites. Compliance is scored using a Department assessment methodology that starts at 110 and deducts weighted points for each requirement not met, so a score can be negative, and that score is posted in the Supplier Performance Risk System. Depending on what a given contract requires, the higher level is satisfied either by a self-assessment or by a certification assessment performed by an accredited third-party assessment organization.

The program also allows a limited plan of action for a defined subset of requirements — not everything is eligible, a minimum score is required to use one at all, and it must be closed out within a fixed window, with award status conditional until it is. Those three constraints are exactly the kind of detail that has been revised more than once, so read the current rule text rather than a summary, including this one.

What is worth planning around now is the timing. The clause is being phased into new solicitations rather than switched on everywhere at once, with the phased rollout advancing from late 2026. That means the practical question for most suppliers is not “when is the deadline” but “which of my customers' next contract actions will carry the clause, and at which level.” That is knowable, it is specific to you, and asking your customers now is a better use of a quarter than reading general guidance.

The scoping decision that decides the cost

Here is the part that most affects a data project, and it is the reason this article covers both subjects together.

The assessment applies to the systems that process, store or transmit the controlled information, plus the systems that protect them. The published scoping guidance sorts your environment into categories along those lines and treats them differently. Which means scope is something you design rather than something you discover. A supplier that keeps controlled technical data inside a defined enclave — a specific set of systems, users and networks, with everything else deliberately outside it — is assessed on that enclave. A supplier where drawings sit on the general file share, in the general ERP, and on everyone's laptop is assessed on the whole company.

The trap for anyone doing analytics is that a data platform can quietly widen the boundary. Pull dimensional inspection results derived from a controlled drawing into a general-purpose data lake and you may have just brought that lake, its cloud account, its identity provider and everyone with access to it into scope. The same is true of a dashboard that renders characteristics from a controlled specification, a backup that spans both environments, and a support tool with broad read access.

So the sequence matters. Decide what is controlled and where it is allowed to live. Draw the boundary. Then design the analytics to respect it — which usually means aggregating or de-identifying inside the enclave and exporting only what is genuinely not controlled, rather than exporting everything and filtering later. Doing this in the right order is the difference between an assessment of one environment and an assessment of everything you own, and it is nearly free at design time.

Reproducible exports, and retention that comes from the contract

Two smaller things that cause disproportionate trouble.

A report has to be reproducible. If an auditor asks for last quarter's nonconformance summary, the same request run twice should return the same rows. That fails when the query was written ad hoc and never saved, when the underlying records are editable, or when the report silently depends on today's date. Save the query with the report, stamp every output with the query identifier and the run time, and treat any report that cannot be regenerated as a document rather than as evidence.

Retention is set by your contract and your product, not by your storage vendor. Different customers, standards and clauses impose different periods, and long-life products can outlast several generations of the system that recorded them. Two questions are worth answering in writing before you need them: can these records be read at all in fifteen years, and can they be read without the vendor whose software created them. An export in an open, documented format, produced and tested annually, answers both. A proprietary backup of a discontinued product answers neither.

What we would not do

• Build you a quality management system — buy one that already knows your standard; the work worth paying an engineer for is the connections between systems and the evidence they produce
• Put controlled data in a general analytics platform to save time — that decision is reversible only on paper
• Promise that a tool makes you compliant — no tool does; a tool makes evidence easier to produce
• Automate a process nobody has written down — automating an undocumented process produces a faster undocumented process
• Migrate historical records without a reconciliation — row counts and spot checks against the source, documented, or the migration itself becomes the finding

What we would check first

• Walk one serial number end to end from purchase order to certificate of conformance, and note where you had to ask a person
• Try to change an inspection value and see whether the previous value survives
• Count the shared logins honestly, including the tablet everyone uses
• Ask which parts were measured with one specific gage between two calibration dates
• Run last quarter's report twice and compare the outputs row for row
• Locate every copy of one controlled drawing, including laptops, email and the file share
• Open the oldest record you are still obliged to keep and confirm it still opens

Bottom line

Quality data survives an audit when the record can be reconstructed from systems rather than people, when history is append-only so nothing can be quietly overwritten, and when every entry is attributable to one real individual who was authorized to make it. The join keys along the traceability chain are where reconstruction actually fails, and they fail because someone typed a lot number twice. If you carry controlled technical information, decide where it is allowed to live before you build anything that reads it, because that one decision sets the size of your assessment and it is far cheaper to make now than to unwind later.

Frequently asked questions