ISO 13485: A QMS Auditors Recognise, Built Around the Device

ISO 13485 follows the legacy ISO 9001:2008 clause structure rather than the High Level Structure used by 9001:2015 — deliberately, to keep continuity with the medical-device regulatory landscape. Clauses 4 to 8 cover the QMS itself, management responsibility, resource management, product realisation, and measurement / analysis / improvement. The big departures from 9001 are: a stronger emphasis on risk-based thinking applied to the QMS itself (not just product), explicit requirements for design and development controls, mandatory documentation for almost everything (where 9001 left it to your discretion), and clauses for sterile devices, implantables, and complaint handling that have no 9001 counterpart. Treat 13485 as a device-aware QMS standard, not a slight variation on 9001.

Clause 4.2.3 introduces the medical device file: a single, controlled record per device or device family that contains the general description and intended use, labelling and instructions, specifications, manufacturing and packaging procedures, installation and servicing procedures, and references to the technical documentation (DHF, DMR, DHR equivalents). The MDF is the auditor's first stop and the easiest place to look unprofessional — version skew between the MDF, the technical file submitted to the notified body, and the manufacturing records is a top finding. Build the MDF as a live, generated artefact from your QMS, not a hand-maintained Word document.

Clause 7.1 requires that risk management is applied throughout product realisation, and the standard explicitly references ISO 14971 for the methodology. In practice, that means a risk management file per device that lives from concept through post-market: hazard analysis, risk estimation, risk control measures, residual risk evaluation, production and post-production information feeding back into the risk file. Notified bodies look for traceability between hazards, control measures, design outputs, verification tests, and post-market data. A risk file that ends at design transfer and never gets updated by complaints data is a near-certain finding.

Clause 7.3 is where most 13485 implementations get hurt. The standard requires planning, inputs, outputs, review, verification, validation, transfer, change control, and a design history file — and every step has to be documented with evidence of who did what, when, and why. The classic failures are: design inputs not traceable to design outputs (so you can't show every requirement was met), verification tests not traceable to the input they're verifying, change records that don't capture the risk impact of the change, and transfer to manufacturing without a documented design transfer review. Build a traceability matrix as the spine of the DHF — it's the artefact that holds the whole clause together.

Clauses 8.2.2 (complaint handling), 8.3 (control of nonconforming product), and 8.5 (improvement, including CAPA) form the post-market loop. The standard requires that complaints, nonconformities, audit findings, and post-market surveillance data all feed a single, evaluated source of evidence for corrective and preventive action. Two failure modes recur: complaints that are logged but never analysed for trend (so a recurring failure mode hides in the volume), and CAPAs that close out with corrective action but no preventive action and no effectiveness check. A clean CAPA record in 2026 includes root cause, risk impact (back to the 14971 file), corrective and preventive actions, effectiveness verification, and a sign-off that closes the loop.

Days 1 to 15: gap assessment against the full standard, focused on documentation, design controls, risk management, and post-market feedback. Days 16 to 45: close documentation gaps, build or migrate the medical device file, populate the DHF traceability matrix for at least one device family, run internal audits on the high-risk clauses. Days 46 to 70: management review with the populated KPIs, supplier evaluations, complaint trend analysis, and effectiveness data from any open CAPAs. Days 71 to 90: stage 1 audit (documentation review) with the notified body, close minor findings, stage 2 audit (on-site implementation review). Expect at least one nonconformity at stage 2 — what matters is the rigour of the response, not the absence of findings.

Post-MDR and post-IVDR, notified bodies have tightened their unannounced audit programmes and increased scrutiny of post-market surveillance evidence. Expect a stage 2 auditor to spend at least a day on design controls (pulling at least one device through input-output-verification-validation tracing), at least half a day on the post-market loop (sampling complaints and walking the CAPA chain), and a focused session on supplier control and outsourced processes. Auditors look for evidence of use, not just procedures — an SOP that says you do trend analysis quarterly with no signed evidence of it ever happening is a worse finding than not having the SOP at all.