ISO 13485 is the quality management system standard for organizations that design, manufacture, or service medical devices, and for a developer the practical requirement comes down to this: a documented, repeatable, auditable process — with design controls at its center, risk management woven through the whole lifecycle, controlled documents and records, qualified suppliers, validated production processes, and a feedback loop from the field back into design. It does not tell you what your device should be. It tells you how you must run the process that produces it.

For US-market developers, the standard matters twice over: it is effectively a prerequisite for CE marking and for working with any serious contract manufacturer or sterilizer, and FDA's quality system expectations have been harmonized toward the same structure — so a company built to ISO 13485 is largely built to what FDA inspects.

What the Standard Requires — and What It Does Not

Understand the boundary. The standard does not specify your device's design, material selection, or safety test regimen. It specifies how you manage the process. The core requirements include a written quality policy and procedures, defined roles and responsibilities including a management representative, control of documents and records, supplier evaluation and control, validation of production processes whose output cannot be fully verified by final inspection, complaint handling and adverse event reporting, internal audits, management review, and corrective and preventive action.

Put plainly, the standard asks one question: if a device leaves the line with a problem, can you show exactly who designed it, who approved it, which revision was built, from which material lot, by whom, and on which validated equipment? If the answer is yes, you have a quality system. If it is no, you have documents.

Design Controls: the Heart of the Requirement for a Developer

For a company that develops products, the most consequential clause is design and development control. It requires a structured process:

  • Design inputs: product requirements, regulatory requirements, user needs, and safety requirements — written down and stated so they can actually be verified.
  • Design outputs: drawings, specifications, manufacturing files, software builds, and acceptance criteria.
  • Design reviews: documented stop points with defined participants at each phase, including someone independent of the work being reviewed.
  • Verification vs validation: verification asks whether you built it to the requirements; validation asks whether the device meets the real clinical need in the hands of intended users under actual use conditions.
  • Design transfer: a formal handoff to manufacturing, proving the design can be produced repeatably.
  • Change control: every change assessed for its impact on safety and performance before it is implemented.
  • Traceability: a matrix linking each input to the output and the evidence that closes it.

All of this accumulates into a design history file — in practice, the complete documented history of the product. Good version and document control practice is the foundation, which is why we build prototypes for medical clients under revision control from the start; see medical device prototyping.

Risk Management and Usability Run Alongside It

The standard requires risk management integrated across the lifecycle, and in practice it leans on the dedicated medical device risk management standard: hazard identification, severity and probability estimation, risk control measures, verification that the controls work, and evaluation of residual risk. In parallel, usability engineering is expected, because a large share of field incidents come from use error rather than component failure. A device that is technically flawless and confusing at 3 a.m. in a busy ward is not a safe device.

Post-market work is part of the system too. The standard does not end on launch day: it requires field feedback collection, complaint handling, and reporting, with all of it fed back into design. Supplier control is included as well — your contract manufacturer, your software house, and your test laboratory become part of your system, and must be evaluated, approved, monitored, and covered by documented quality agreements. That is why the standard shapes your supply chain choices, not only your engineering department; see working with a contract manufacturer.

Software Is Not an Exception

Software in or as a device carries its own lifecycle expectations layered on top of the quality system, plus cybersecurity documentation for connected devices. If your product is software, or has meaningful software content, start there — see software as a medical device.

How Much of It Applies to You

Scope depends on device classification, so the first step is determining it. Whether your product is even a regulated device at all is question zero — see is my product a medical device — and once it is, classification drives everything, as laid out in FDA medical device classes and the submission routes in the FDA approval process.

When to Start and How to Prepare

Start working in a standard-compatible way at the prototype stage: keep test protocols and results, manage revision numbers, record design decisions and their rationale, and hold reviews even if they are two people and a signed page. You do not need a full certified system on day one. But reconstructing documentation retroactively is the most expensive and most demoralizing task we encounter — every day worked without document control accrues a documentation debt that has to be repaid eventually, usually under schedule pressure.

A common question: does a small developer need full certification? In practice, a company that only develops and manufactures at an already-certified contract manufacturer can begin by working to the standard's principles, then pursue formal certification as the regulatory milestone approaches. Certification itself involves selecting a registrar, a documentation review, and a staged audit — plan several months for it, plus the internal audit and management review cycles the auditors will want to see evidence of. Budget expectations for the whole program sit in medical device development cost, and more material is in our medical device development hub.

Build the Process Right From the First Prototype

Projects House develops medical devices with design controls, traceable documentation, and revision-managed builds from the earliest model onward, so nothing has to be reconstructed later. Developing a device and want the process built correctly from the start? Tell us about your product through the contact form and we will map the requirements that actually apply to it.