Quick Answer

ISO 13485 runs the system, ISO 14971 manages risk, and ISO 10993 handles biological safety inside that system.

EU MDR and FDA then determine how those documents must be packaged, connected, and defended during review. The framework only works when those pieces are coherent together.

Many submission packages feel fragmented because each standard was handled in isolation. Reviewers do not experience your file that way. They see one device, one evidence package, and one chain of logic that either holds together or does not.

ISO 13485: The Quality System Layer

ISO 13485 is the operating system for controlled medical device development. It governs document control, design and development planning, supplier qualification, change control, production controls, CAPA, and internal audit expectations.

For biological evaluation, that matters because material information, design changes, supplier data, and document revision history all depend on the QMS being credible and current.

ISO 14971: The Risk Logic Layer

ISO 14971 defines how hazards are identified, risks are estimated, controls are applied, residual risk is evaluated, and benefit-risk conclusions are reached. Biological risk is not separate from this framework. It is one category of device risk that must be evaluated and managed inside it.

  • Hazard identification: biological hazards from materials, residuals, and degradation products belong in the risk analysis.
  • Risk controls: material selection, processing controls, sterilization controls, and testing are all part of the control strategy.
  • Residual risk: BEP and BER conclusions should connect back to the device's residual-risk position.

ISO 10993: The Biological Safety Layer

ISO 10993 provides the biological evaluation framework. It tells you how to classify device contact, determine applicable endpoints, assess existing evidence, plan waivers, use chemistry, and interpret testing within a risk-based process.

It is not a self-contained island. A strong biological evaluation depends on QMS control of materials and changes, and it ultimately feeds the ISO 14971 risk-management file.

What EU MDR Expects to See

Under EU MDR, the technical file must show that GSPR compliance, risk management, biological evaluation, and clinical evidence all support each other. Notified bodies commonly probe the joins between these documents, not just the individual documents in isolation.

  • Annex I: material safety and biological acceptability must be demonstrated clearly.
  • Annex II: the technical documentation should contain traceable links between design, risk, and biological evaluation.
  • Reviewer focus: legacy files often fail because the links are implied instead of explicit.

What FDA Expects to See

FDA reviewers also expect coherence. In a 510(k), the biocompatibility summary, chemistry rationale, test reports, and risk framing should tell the same story. Weak packages often have test data on one side, unsupported waivers on the other, and no visible link back to the actual device construction.

The Practical Mapping Teams Need

If you want the framework to work in practice, think in sequence: design control establishes the current device definition, risk management identifies biological hazards, ISO 10993 determines how those hazards are evaluated, and the final submission package shows how the evidence supports safety for the intended use.

Practical Rule

The more your file relies on the reviewer to infer the connection between QMS control, risk logic, and biological evidence, the more likely you are to get questions that could have been prevented by clearer document architecture.

ISO 13485 ISO 14971 ISO 10993 EU MDR

Related next steps

Article

ISO 14971 + ISO 10993 Integration

See where biological evaluation conclusions must connect back to the risk file.

Article

ISO 13485 and Biological Evaluation

Review the QMS controls that most often influence biocompatibility quality.

Service

EU MDR Biocompatibility Support

Get help building a file that reads as one coherent regulatory package.

Need help turning a disconnected documentation set into a submission-ready framework?

Discuss Your Project Back to Resources