Export classification is often approached as a determination. A product is reviewed, its technical characteristics are evaluated, an ECCN or other classification is assigned, and that result becomes part of the product record.
The classification may be entirely correct when it is made.
The difficulty is that the product does not necessarily remain the product that was classified.
Engineering changes components. Software releases add functionality. Encryption capabilities change. Processing performance increases. A supplier replaces a part. Firmware is updated. A product family evolves while retaining the same commercial identity, part number structure, or position in the ERP.
None of these changes necessarily alters the export classification. Many will not.
But some can.
The export-control problem is therefore not limited to determining the correct classification. It also includes knowing when the facts supporting that determination have changed enough to require another look.
1Classification has a technical basis
An ECCN is not simply an administrative attribute assigned to a part number. It is the result of evaluating technical characteristics against regulatory criteria.
That distinction is easy to lose once the classification enters an operational system.
Engineering understands the product through specifications, components, drawings, software versions and performance. Sales understands it as something that can be quoted. ERP understands it as an item or part number. Logistics eventually receives a classification that helps determine how the item can move.
Over time, the classification can become detached from the technical facts that produced it.
The ERP still contains the ECCN. The value is populated. Nothing appears incomplete.
The problem is that completeness and validity are not the same thing.
A populated classification field proves that a classification exists. It does not prove that the classification still describes the current product.
This is particularly important because classification sits upstream from many other export-control decisions. Destination restrictions, licensing requirements, authorization analysis and shipment controls can all depend on it. A stale classification therefore does not remain an isolated data-quality problem. It can influence every decision that consumes it.
2Engineering change and regulatory change are different things
Most companies already have processes for controlling engineering changes. Products do not normally change at random. There may be engineering change orders, revision controls, configuration management, software release processes, supplier-change approvals or other mechanisms designed to preserve technical integrity.
Export compliance, however, is asking a different question.
The fact that a change passed engineering review does not establish whether it affects export classification. Conversely, requiring compliance to reclassify a product after every engineering change would create considerable work without necessarily improving control.
The useful control point sits between those extremes.
The organization needs to know which types of change can affect the technical characteristics on which the existing classification depends.
That requires preserving more than the classification itself. It requires some connection to its basis.
A classification record that contains only a part number and an ECCN provides very little information for evaluating change. A stronger record identifies the relevant technical characteristics, the version or configuration evaluated, the source of the determination, the date of the analysis, and the supporting evidence.
The purpose is not to reproduce the entire engineering record inside the compliance system. It is to retain enough of the classification basis to recognize when a subsequent change may have regulatory significance.
3The problem can also originate outside the product
Classification drift is not limited to engineering changes.
The product can remain exactly the same while the regulatory framework changes around it.
Control parameters can change. Classification criteria can be amended. New controls can be introduced for technologies that previously fell elsewhere. Regulatory treatment can become more restrictive for particular destinations, end users or applications without any physical change to the item itself.
That creates two independent sources of change: the product can move while the regulation remains stable, or the regulation can move while the product remains stable.
A classification process built primarily around initial product review can miss both.
Periodic reclassification of the entire product catalog is one response, but it is an expensive substitute for knowing what actually changed. Large catalogs may contain thousands of parts, assemblies, software items and technologies. Treating every item as equally likely to require reconsideration consumes specialist attention that could be directed toward the products whose underlying facts have actually changed.
The more useful capability is to identify change that intersects with the basis of an existing determination.
4Classification needs lineage
This is why classification history matters.
When a classification changes, the previous determination should not simply disappear beneath the new value. The organization may still have quotations, contracts, shipments, licenses or historical records associated with the earlier classification.
A transaction completed two years ago should be evaluated against the product and regulatory state that existed when that transaction occurred, not silently rewritten because the current product now carries a different classification.
The same principle applies when investigating why a classification remained unchanged. If an engineering modification occurred, the organization should be able to determine whether the change was evaluated for export-control relevance, whether reclassification was required, and what supported that conclusion.
That history provides something a current ECCN field cannot: lineage.
It connects the regulatory determination to the technical object over time.
The book also identifies the underlying failure directly: product, component, performance and regulatory changes can create classification drift while an earlier determination continues propagating through downstream systems.
5The difficult classification may be the one that looks complete
Missing classifications are relatively easy to identify. A blank ECCN field can be reported, routed for review and prevented from progressing where appropriate.
Stale classifications are harder.
They look finished.
The part number has an ECCN. The ERP accepts it. The shipment process retrieves it. Previous transactions may have used it successfully. Unless something connects technical or regulatory change back to the basis of the determination, there may be no obvious reason for anyone downstream to question it.
That changes the classification problem.
Accuracy at the moment of classification remains essential, but it is only one part of maintaining classification integrity over the life of a product. The organization also needs to know what was classified, which facts supported the determination, what has changed since then, and whether those changes affect the conclusion.
A classification can be correct, documented and properly propagated throughout the enterprise. It can still become wrong later.
That is the harder failure to see.