ISO 13485 and the MDR: why the quality system is a precondition

Picture a manufacturer that has done the hard engineering. The product performs, the technical documentation runs to hundreds of pages, the test reports are clean, and the Notified Body audit is on the calendar. Then the review stalls. Not over a design flaw, but because recent design changes never flowed through change control, two critical suppliers were re-sourced without re-qualification, and a year of post-market feedback sits in an inbox instead of feeding the risk file. The technical file was a snapshot in time. The quality system that was meant to keep it honest was never really switched on.

That scene plays out often, and it traces back to one misreading: treating ISO 13485 and the EU Medical Device Regulation (Regulation (EU) 2017/745, the MDR) as two separate projects. They are not. The quality management system is the precondition for MDR conformity, and the device file is one of the things that system produces. Get the order right and the certification audit largely confirms work that is already under control. Get it wrong and you spend the better part of a year writing corrective actions against findings you could have prevented.

The MDR turns a quality system into a legal obligation

Article 10(9) of the MDR is direct about this. A manufacturer must establish, document, implement, maintain, keep up to date and continually improve a quality management system, and the article then lists what the system has to cover. That list includes a strategy for regulatory compliance, identification of the applicable General Safety and Performance Requirements, management responsibility, resource and supplier management, risk management, clinical evaluation, post-market surveillance, vigilance reporting, and corrective and preventive action. None of it is optional, and none of it is a document you file once and forget.

When a Notified Body assesses your device, it assesses the quality system alongside the technical documentation. If the system does not hold up, the certificate does not issue, however strong the engineering behind the product. That is what makes the QMS a precondition rather than a parallel nicety. ISO 13485 is the internationally recognised way to build that system and to show an auditor it functions, which is why most manufacturers entering the European market treat 13485 as the first move rather than a later add-on.

Where ISO 13485 and the MDR pull in the same direction

The 2016 revision of ISO 13485 was drafted with regulatory expectations in view, and the overlap with Article 10 is wide. Management responsibility, document and record control, design and development controls, purchasing and supplier evaluation, process validation, complaint handling, internal audit, management review, and corrective and preventive action all map onto duties the MDR sets out. In the European Union, EN ISO 13485:2016 is a harmonised standard, and its Annex ZA states the presumption of conformity it carries for the quality-system requirements it covers.

In plain terms, a 13485-conformant QMS is the backbone the regulation assumes you already operate, and the harmonised annex even names which requirements it answers for. That alignment is why a sound 13485 implementation takes so much friction out of the conformity assessment. The auditor is not meeting your processes for the first time during the MDR review. They are confirming that a system you already run does what the regulation needs it to do.

Where ISO 13485 stops and the MDR keeps going

Alignment is not equivalence, and the difference is where unprepared manufacturers lose time. A 13485 certificate, on its own, does not discharge every MDR duty. The regulation adds processes that the standard either touches lightly or does not name at all, and the quality system has to be extended so that it owns each of them.

Clinical evaluation is the clearest case. ISO 13485 asks for design validation; the MDR asks for a clinical evaluation plan and report, clinical evidence appropriate to the device class, and a post-market clinical follow-up programme under Article 61 and Annex XIV. Post-market surveillance is another: clause 8.2.1 of the standard expects feedback and monitoring, while Articles 83 to 86 require a planned surveillance system, periodic safety update reports, and trend reporting. Vigilance brings fixed reporting clocks for serious incidents and field safety corrective actions under Articles 87 to 92.

On top of those sit duties with no ISO equivalent at all. The MDR requires a named Person Responsible for Regulatory Compliance under Article 15, Unique Device Identification and EUDAMED registration under Articles 27 to 31, and a Summary of Safety and Clinical Performance for implantable and class III devices. Underneath everything are the General Safety and Performance Requirements in Annex I. Where the old directives spoke of essential requirements, the MDR expects documented evidence that each applicable requirement is met, and the quality system is what produces and maintains that evidence as the design and its clinical picture change.

The integration point is straightforward. None of these are alternatives to the quality system. They are modules that have to be designed into it, so that a clinical evaluation update, a periodic safety update report, or a UDI record is generated by a controlled procedure rather than assembled by hand the week before an audit.

Why the sequence has to be quality system first

Every MDR deliverable is the output of a process. A clinical evaluation is a procedure with defined inputs, authors, and review. The technical documentation is a set of records held under document control. Post-market data feeds corrective action and design change. Risk management to ISO 14971 is not a file you close once; the MDR wants the benefit-risk judgement kept current from real-world evidence. If the system that runs those processes is not in place, the device file becomes a one-time artefact that drifts out of date the moment anything changes.

Auditors read that drift quickly. Records that do not reconcile, a design change with no impact assessment, a supplier swapped without evaluation, a complaint that never reached the risk file: each one signals a system built for the certificate rather than for the work. Building the QMS first is what keeps conformity continuous, so that the file an auditor opens in year three still matches the product coming off the line.

The failure patterns that show up in audits

A handful of recurring patterns separate the firms that clear the MDR cleanly from the ones that stall:

• Two projects that never meet. A consultant assembles the technical file while someone else writes procedures, and neither matches what actually happens on the floor.
• A certified but unlived system. The procedures describe an ideal process the team does not follow, which an experienced auditor notices within hours.
• Static risk management. The risk file is completed once and shelved, rather than a live benefit-risk that post-market data keeps updating.
• Reactive post-market surveillance. PMS is run as after-the-fact complaint handling instead of the planned, proactive system the MDR describes.
• Thin supplier control. Purchasing controls sized for a lighter regime do not meet the MDR expectations for critical suppliers and outsourced processes.

What a quality-system-first posture is worth

Putting the system first pays back where it counts: a shorter Notified Body review, fewer nonconformities at the certification audit, and a CE marking for medical devices that holds up through surveillance audits and across the device lifecycle. The same backbone also travels well. A 13485 system extended for one market is most of the way toward others, which is why a single MDSAP audit can satisfy several regulators at once. The effort spent making the quality system real for the MDR is rarely wasted. It is the foundation every other market builds on.