Most people opening up ISO 13485 to read about product realization want to get to §7.3. That’s where design controls live, and design controls are the part of the QMSR most people lose sleep over.
But before you get to §7.3, you have to walk through §7.1 (planning of product realization) and §7.2 (customer-related processes). And here’s the thing about those two clauses — the old QSR didn’t have them. Not really.
That’s worth pausing on. For decades, FDA’s quality system regulation said almost nothing about how you should plan the realization of a product before you started designing it, and even less about what to do with input from your “customers” — a word the old QSR rarely used in this sense at all. Now those sections are part of U.S. law. Skim them at your peril.
What §7.1 Actually Requires
Clause 7.1 tells you the organization shall plan and develop the processes needed for product realization, and that planning shall be consistent with the requirements of the rest of the QMS. In plain English: before you start making something, you need to have decided how you’re going to make it, who’s responsible for what, what verification and validation are needed, what records you’ll keep, and — critically — what risks you’re managing throughout.
The risk management piece is the part that often surprises people. ISO 13485 specifically requires you to “document one or more processes for risk management in product realization.” Not optional. And it’s not just a reference to ISO 14971 — it’s a directive to integrate risk management into the planning of every realization process. The old §820.30(g) treated risk analysis as part of design validation. The new §7.1 says risk management belongs to how you plan everything you do, from manufacturing to servicing.
The output of all this is sometimes called a Product Realization Plan, sometimes a Quality Plan, sometimes folded into the design and development plan. ISO doesn’t dictate the name. But it does require that the plan exist, be documented, and be appropriate to the device’s complexity, classification, and intended use. (Yes, that means a Class III implant gets a fatter plan than a tongue depressor. No, you cannot get away with one Quality Plan for the whole portfolio if the portfolio spans risk classes.)
What §7.2 Actually Requires
Clause 7.2 has three sub-clauses, and each one was either absent or barely sketched in the old QSR.
§7.2.1 Determination of requirements related to product. You have to identify all the requirements your product needs to meet — those specified by customers, those needed for intended use, statutory and regulatory requirements, any user training needed for safe and effective use, and any additional requirements you determine are necessary. That last one matters: if a customer hands you an incomplete spec, you don’t get to ship the gap. You either fill it in or go back and ask. The user-training piece is one a lot of QSR-era manufacturers handled informally; now it’s a formal input.
§7.2.2 Review of requirements related to product. Before you commit to supply a product to a particular customer, you have to review those requirements and confirm they’re complete, that any differences from earlier expressions are resolved, and that you’re capable of meeting them. Records of those reviews are required. If requirements change, you re-review.
§7.2.3 Communication. You have to plan and document arrangements for communicating with customers — covering product information, inquiries and orders (including amendments), feedback (including complaints), and advisory notices. This is where customer communication intersects with complaint handling, and where you may want to glance back at §820.35 on complaint files while you’re thinking about it.
What Changed (Mostly: The Concept Itself)
Under the old QSR, “planning” lived inside §820.20 as a quality planning requirement that ran about three sentences long, and customer-facing communication was handled, to the extent it was handled at all, through §820.198 (complaint files) and §820.200 (servicing). There was no requirement for a documented customer-related process, no formal “review of requirements,” and no obligation to plan and document customer communication arrangements.
So if you’re a manufacturer who has been quietly running an ISO 13485 system in parallel because your European notified body insisted on it — congratulations, you already have what you need. If you’re a U.S.-only manufacturer who treated ISO 13485 as someone else’s problem, this is one of the places the QMSR is asking you to build something new.
What to Actually Do
A short, practical list:
- Confirm you have a documented product realization planning process, and that it produces a record. Call it a Quality Plan, a Product Realization Plan, or anything else you like — the regulators don’t care, as long as it exists and matches what you actually do.
- Make sure your planning explicitly references your risk management process. If you’ve been treating risk management as a design-only activity, expand the scope. Production, servicing, and post-market all live under §7.1 too.
- Document your customer requirements determination and review process, and keep records of the reviews. This is a place an inspector will ask for evidence.
- Write down — actually write down — your customer communication arrangements. Who answers product inquiries? Who issues advisory notices? Who reviews amendments to orders? One short procedure can cover it, but it has to exist.
None of this is glamorous, and none of it makes a regulatory affairs résumé look more interesting. But §7.1 and §7.2 are the places the QMSR quietly added requirements the QSR didn’t bother with. They’re also the places an FDA inspector who has been told to “audit to ISO 13485” will know to look. The trick is not letting these sections slip past unnoticed because the section after them is louder.
And yes — design controls are next on the list. We’ll get there.