Technical data packages and what they contain

More than the drawing

A technical data package is the set of information defining an item well enough to make and inspect it. Depending on the programme it can include models, drawings, specifications, materials and process requirements, quality provisions, and instructions.

Suppliers frequently protect the model and the drawing and treat the rest as ordinary, which misreads what the package is.

What you make from it is usually covered too

Toolpaths generated from the model. Fixture designs. Inspection programmes for the coordinate measuring machine. Setup sheets. Quality records referencing controlled dimensions. Photographs of the part.

Each of these derives from controlled information and generally carries the same treatment. Each is also created by a different person on a different system, which is how a package protected on arrival ends up distributed across the business within a fortnight.

Read them and keep them

Controlled information generally arrives marked, and the markings state what applies. They should be preserved on copies and on derived documents, and stripping them, which happens routinely when a file is converted or re-exported, removes the only indication to the next person that anything applies.

Where a file arrives unmarked and you believe it is controlled, ask the customer rather than deciding.

Five copies nobody intended

The engineer's local working copy. The quote sent to a subcontractor. The attachment in the email thread. The version on the shared drive from when the job ran before. And the one on the machine.

Each was created for a reason and none was recorded. The trace exercise in the entry on scoping finds them.

A compliance question as well as a quality one

Knowing which revision is current is ordinary manufacturing practice. Knowing where every copy of every revision is, and being able to remove them, is the compliance extension of the same discipline.

Suppliers with a mature quality system are usually most of the way there and have not connected the two.

What happens at the end of the programme

Contracts frequently state what must be returned or destroyed and when. That obligation applies to all the derived data as well, and almost nobody deletes the toolpaths.

Read the term, put the date in the calendar, and record what was done.

Govern the package, not the perimeter

Because the copies proliferate through ordinary work, a control at the network edge protects little. What helps is knowing where the package is authorised to go, recording each release, and being able to enumerate copies.

That is what file-level governance means in this setting, and it is the part of the platform this site sells that maps most directly onto a requirement.

The stage where it leaks first

A package goes to three potential subcontractors during quoting and two of them do not win the work. They now hold controlled information for a job they are not doing.

Either quote from redacted information, or place the recipients under the same terms as a supplier who wins, or retrieve it. All three are work; none is as much work as explaining the alternative.

The finished item can disclose the design

Images used for marketing, for quality records or in a customer update can reveal geometry that the package protects. Whether that matters depends on the item and it is a question worth asking before the photograph is published rather than after.

Log it in on arrival

What arrived, from whom, under what markings, on what date, and where it was put. Five fields, filled in once, and they are the start of the trace that everything else in this section depends on.

Suppliers who begin here find the rest of the programme considerably easier, because the question of what they hold has an answer.

Ask where a copy came from

Whenever a controlled file turns up somewhere unexpected, ask how it got there before deleting it. The answer identifies a route, and the route will be producing other copies.

Deleting without asking removes the instance and leaves the mechanism.

Elsewhere in the shop floor

• What the three levels are, and which appliesThe level is set by your contract, not by your size. Most suppliers handling controlled unclassified information are at the second.
• Reading the clause that binds youReading the clause that binds you. What the requirement says, what it means in practice, and what an assessor will ask.
• Which systems are in scopeWhich systems are in scope. What the requirement says, what it means in practice, and what an assessor will ask.
• Self-assessment, and why the scores driftedSelf-assessment, and why the scores drifted. What the requirement says, what it means in practice, and what an assessor will ask.
• Who assesses you, and how each kind worksWho assesses you, and how each kind works. What the requirement says, what it means in practice, and what an assessor will ask.
• What the standard does not requireWhat the standard does not require. What the requirement says, what it means in practice, and what an assessor will ask.
• Machines older than the requirementsA control written for a server, applied to a lathe with a shared login, a decade-old operating system and a USB port.
• Drawings, job packets and paperDrawings, job packets and paper. What the requirement says, what it means in practice, and what an assessor will ask.
• Removable media, and why bans failRemovable media, and why bans fail. What the requirement says, what it means in practice, and what an assessor will ask.
• Vendor remote accessVendor remote access. What the requirement says, what it means in practice, and what an assessor will ask.
• Segmentation, and what it does not solveSegmentation, and what it does not solve. What the requirement says, what it means in practice, and what an assessor will ask.
• What insider risk actually coversWhat insider risk actually covers. What the requirement says, what it means in practice, and what an assessor will ask.
• What detection can and cannot establishWhat detection can and cannot establish. What the requirement says, what it means in practice, and what an assessor will ask.
• Monitoring, and where the law constrains itMonitoring, and where the law constrains it. What the requirement says, what it means in practice, and what an assessor will ask.
• The fortnight around a departureThe fortnight around a departure. What the requirement says, what it means in practice, and what an assessor will ask.
• Privileged access, and who reviews itPrivileged access, and who reviews it. What the requirement says, what it means in practice, and what an assessor will ask.
• False positives, and what they costFalse positives, and what they cost. What the requirement says, what it means in practice, and what an assessor will ask.
• The documents an assessor reads firstThe documents an assessor reads first. What the requirement says, what it means in practice, and what an assessor will ask.
• What counts as evidenceWhat counts as evidence. What the requirement says, what it means in practice, and what an assessor will ask.
• The findings that recurThe findings that recur. What the requirement says, what it means in practice, and what an assessor will ask.
• Plans of action, and their limitsPlans of action, and their limits. What the requirement says, what it means in practice, and what an assessor will ask.
• What the assessment week is likeWhat the assessment week is like. What the requirement says, what it means in practice, and what an assessor will ask.
• The certificate, and what it coversThe certificate, and what it covers. What the requirement says, what it means in practice, and what an assessor will ask.