The Workbench · Craft
Clause 7.2 reviews requirements the order never stated
This blog has already covered what makes a design input verifiable, not just approved, and, on the purchasing side, why Clause 7.4.3 checks the shipment a supplier ships, not the supplier itself. Both of those clauses sit downstream of a decision ISO 13485:2016 makes earlier, and separately: whether the organization can actually accept a given order in the first place. Clause 7.2, customer-related processes, is the gate before either file opens, and it asks for more than whatever specification the customer actually wrote down.
7.2.1 names requirements the customer never stated
Clause 7.2.1 requires the organization to determine requirements specified by the customer, including requirements for delivery and post-delivery activities; requirements not stated by the customer but necessary for specified or intended use, where known; applicable statutory and regulatory requirements; and any user training needed to ensure specified performance and safe use of the medical device. Four categories, and only the first is literally what's written on the purchase order. The other three are determinations the organization has to make on the customer's behalf, not items it can wait for the customer to supply.
The unstated-use clause is the one most order reviews skip
A purchase order for a device rarely spells out the sterility assurance level, the packaging integrity requirement, or the labeling language a destination market's own regulation demands — the customer ordered a device by part number, not a specification document. Clause 7.2.1(b) places the duty to know and apply those unstated requirements on the organization receiving the order, because the standard assumes a supplier of medical devices knows its own product's intended use better than a purchasing department typing a part number into a form. An order review that treats the PO's literal text as the complete requirement set has covered the one category of four that needed the least help.
Training lands here before it lands in the field
Clause 7.2.1(d) names user training as a determined requirement, not a detail left for the instructions for use to handle on its own. Where specified performance or safe use genuinely depends on a user receiving training before the device is used, that requirement gets determined and tracked at the order-review stage, the same way a technical specification would be — not discovered later, inside a complaint record, once a device already in the field has been used incorrectly by someone who was never trained on it.
7.2.2 reviews that list before commitment, every time
Clause 7.2.2 requires the review to happen before the organization commits to supply product to the customer, confirming that requirements are defined and documented, that any difference between what the customer said and what's actually in the order gets resolved, and that the organization has the ability to meet the requirements it just determined. Where the customer provides no documented statement of requirement at all, the organization still has to confirm the requirement before accepting the order — silence from the customer isn't itself agreement with whatever ends up shipped. Records of the review, and of any action it leads to, have to be maintained; the review is a controlled record, not an internal checkpoint with no evidence trail behind it.
A repeat order still has to clear the same gate
Nothing in Clause 7.2.2 exempts a routine reorder from the review it requires, though the standard doesn't dictate how much new work that review has to involve each time. A second shipment of the same part, to the same specification, for the same customer, can often confirm 7.2.2's requirements by reference to the file the first order already built, rather than repeating the full determination from scratch — but that's a documented decision about how the review gets satisfied, not a license to treat the second order as needing no review at all. A file that can't show how a repeat order's review was satisfied has a gap an auditor will ask about by the third repeat order, not the first.
Where this meets the file
An order-review record built around Clause 7.2.1's four categories, with the unstated-use and training determinations carried as their own fields rather than folded into a single “requirements confirmed” checkbox, is previewed alongside the launch catalog's other quality-system templates. If your program runs this review differently, the shelf takes that correction directly.
The Regulatory Toolkit launches soon — a free shelf of source-mapped templates, checklists and browser-only tools for regulatory teams. Get one email when it opens, or contribute a template.