Masking part numbers and customer names without breaking record links

Why simple redaction breaks manufacturing records#

Simple redaction breaks manufacturing records because part numbers and customer IDs are the keys that join them. Blank out the part number on a job, an NCR and a return, and nobody can tell that all three concern the same valve body. Replace it with a fresh random value on each row, and the result is the same.

Manufacturing makes this harder than most fields. The same part number appears in quotes, BOMs, routings, jobs, inspection plans, NCRs, shipments and warranty claims, usually across an ERP, a QMS and several spreadsheets. A masking approach that works table by table leaves the chain in pieces.

The rule set for consistent masking#

Consistent masking follows a small set of rules applied across every system in scope. Agree on them before anyone writes a script, because changing a rule halfway means redoing every table already processed.

• 1One entity, one token: each customer, part, drawing and supplier gets a single replacement used everywhere.
• 2Keyed, not guessable: tokens come from a keyed method such as deterministic encryption or a keyed hash, with the key held by the manufacturer.
• 3Keep the family, drop the customer: preserve part family, material, process and size class, and remove customer identity and customer part numbers.
• 4Preserve order where it matters: revisions keep their sequence, so a later revision still follows an earlier one.
• 5Generalize what would re-identify: ship-to addresses become regions and customer names become industry segments.
• 6Never share a token between two real items: a part number that was reused for a new item gets one token per real item.
• 7Keep the mapping out of the delivery: the table linking tokens to real values stays inside the company.

Which fields to tokenize, generalize or drop#

Each field in scope gets one treatment: tokenize, generalize, replace or drop. The table shows typical choices for a manufacturer; the final call depends on customer contracts and the rights review.

Smart part numbers and free text: the two hard cases#

Smart part numbers and free text are where masking most often fails. A smart part number encodes meaning in segments, such as a customer prefix, a product family, a material code and a size. Tokenizing the whole string hides the family; leaving it intact exposes the customer prefix.

The fix for smart numbers is to parse the segments first. Tokenize the customer segment, keep family and material segments that follow your own coding scheme, and store the parsed parts as separate fields so their meaning survives.

Free text is harder. NCR descriptions, job notes and service comments mention customer names, drawing numbers and part numbers in passing. Build a dictionary of every real identifier from master data and replace matches in text with the same tokens used in structured fields. Then add automated detection for names and contact details, plus human review of samples, since Presidio's own documentation warns that automated detection gives no guarantee of finding all sensitive information.

Deterministic encryption, keyed hashes and format-preserving tokens#

The method behind the tokens decides whether masking stays consistent and whether the manufacturer can reverse a token if it ever needs to. Deterministic methods always produce the same output for the same input under the same key, which is what keeps record links intact.

Mainstream tools support these methods. Google's Sensitive Data Protection API offers both deterministic encryption and format-preserving encryption, and its API notes recommend deterministic encryption where the input alphabet need not be preserved, because format-preserving encryption carries significant latency costs.

A keyed hash is a simpler choice when nobody will ever need to reverse a token. Whichever method you pick, record it in the package documentation and protect the key like any other secret. Pseudonymized records can still count as personal data under some privacy laws when people are involved, so masking does not end the privacy review.

Illustrative: before and after masking a nonconformance chain#

Illustrative: a fictional maker of stainless steel process valves masks the records behind one complaint: the sales order, the job, an NCR and a return. Every value shown is invented for the example.

The same tokens appear in the job, the return and every other record about that customer and part, so a reviewer can follow the chain end to end without learning who the customer is. The customer's own part number disappears entirely, while the valve family and material remain readable.

How to test that the links survived#

Testing masked data means proving that joins behave exactly as they did before masking and that no real identifier slipped through. Run the tests on the full masked set, not on a sample.

• 1Compare row counts for each join, such as jobs to orders and NCRs to jobs, before and after masking.
• 2Compare distinct counts of customers, parts and lots; any change means tokens collided or split.
• 3Rebuild several complete chains by hand and confirm each step still connects.
• 4Search the output for every real identifier in the master-data dictionary, including partial matches.
• 5Confirm the mapping table and the key are absent from the delivery folder.

How SourceX handles masking#

Masking happens in the Preparation step of the SourceX five-step transaction, after the Rights step has settled which records and fields are in scope. The manufacturer keeps the key and the mapping; the buyer receives tokens only.

The methods used, the fields treated and the test results go into the privacy record of the SourceX Evidence Packet. That mirrors provenance standards such as the Data & Trust Alliance's Data Provenance Standards, whose list of privacy-enhancing tools includes masking, pseudonymization and tokenization. The manufacturer approves the masked package before delivery.