SBOM requirements: who is actually asking, and for what
The obligation reaches most software companies through customer contracts rather than through regulation — which means the requirement is whatever the contract says.
Approving a change is the easy part. The ECO has to say from when it applies and what to do with the parts already in the building.
An engineering change order is the document that authorises a change to a released product definition — a drawing, a specification, a bill of materials — and records what was decided. It typically follows a change request, which proposes the change, and is followed by a change notice, which tells everyone affected that it has happened.
What distinguishes a working change process from a nominal one is not the approval routing. It is whether the order answers the two questions that determine what actually happens on the floor: from when does this apply, and what do we do with the parts, sub-assemblies and finished goods that already exist under the old definition.
Use up existing stock, rework it, scrap it, or return it to the supplier — each is a legitimate answer and each has a different cost, and the decision belongs in the order rather than to whoever is standing in the stores when the question arises. A change approved without disposition instructions produces a warehouse holding parts nobody will confirm as usable, which quietly becomes a write-off at the next stocktake.
Safety and regulatory changes are not effectivity decisions. Where a change corrects a hazard or a compliance defect, "use up existing stock" is usually not available, and the disposition extends to units already sold. Treat that class of change as a different process with a different approval path.
A change request is a proposal that may be rejected; a change order is a decision. Merging them produces a queue in which everything is approved because rejecting feels like reversing something already agreed. Keeping the two distinct also produces a useful record: the requests that were declined, and why, which is the institutional memory that stops the same change being proposed annually.
What matters later is being able to reconstruct which definition a given unit was built to. Ettex Docs holds the change orders with version history and the approvals, Ettex Records keeps them against the affected part numbers with their effectivity, and the structure being changed is covered in bill of materials, kept current as described in bom management.
To be clear: this is documents and records, not PLM or quality management software. In regulated manufacturing the change process is part of the quality system and is audited as such; what this covers is the content of the decision, which no system supplies for you.
The document authorising a change to a released product definition, recording what changed, from when it applies and what happens to existing material.
The request proposes a change, the order authorises it, and the notice informs affected parties that it has been made.
The point from which the change applies — a date, serial number, lot, or exhaustion of existing stock. Leaving it vague is the most common defect.
The order states the disposition: use up, rework, scrap or return. For safety or regulatory changes, using up existing stock is usually not an option.
The obligation reaches most software companies through customer contracts rather than through regulation — which means the requirement is whatever the contract says.
A bridge letter is management’s own assertion, not the auditor’s. It closes a few months of calendar and nothing more — and customers who understand that read it accordingly.
A contracting officer scans it for identifiers and past performance. Design-led capability statements that hide the codes get filed and forgotten.