What ISO 13485 requires for traceability
The Harmonization Shift: QMSR and ISO 13485
The regulatory landscape has reached a historic milestone. As of 2024, the FDA has finalized the Quality Management System Regulation (QMSR), formally amending 21 CFR Part 820 to align with international standards. This rule explicitly incorporates ISO 13485:2016 by reference, effectively making it the foundational framework for medical device quality systems in the United States.
For manufacturers, this means your focus on ISO 13485 is more critical than ever. The previous divide between "FDA Design Controls" and "ISO Compliance" has vanished. By mastering the traceability requirements of Clause 7.3, you are no longer just preparing for a notified body audit. Yours is a unified strategy that satisfies both global markets and FDA inspections. This transition reduces administrative duplication, but it raises the stakes for your Traceability Matrix, as it now serves as the primary evidence for global regulatory compliance.
ISO 13485:2016 is the quality management standard for medical device design and manufacture. It is a registration standard: your notified body (CE marking) or FDA 510(k)/PMA process will audit your design controls, and a requirements traceability matrix (RTM) is the primary document you will be asked to produce. Section §7.3 is where most of that scrutiny lands.
§7.3.3 Design and Development Inputs requires that requirements relating to function, performance, usability, safety, applicable regulatory requirements, and outputs from risk management be documented. The key phrase: “outputs from risk management.” ISO 13485 is formally coupled to ISO 14971 (risk management for medical devices). Risk is not an afterthought; it is a documented input to the design process.
§7.3.4 Design and Development Outputs must be verified against the inputs. Each output (a software module, a hardware component, or a labeling specification) must be traceable back to at least one input. Undocumented outputs are a major nonconformity. More common: outputs that exist but whose traceability chain is asserted verbally rather than documented.
§7.3.6 Verification and §7.3.7 Validation are distinct and both required. Verification asks: does the output meet the design input? Validation asks: does the device meet the user’s intended use under actual or simulated conditions? Your requirements traceability matrix (RTM) needs columns for both. A test record that doesn’t distinguish verification from validation will get a question from your auditor. Multiple questions if it’s an FDA inspector.
§7.1 Planning requires that risk management activities be planned and documented throughout the design process. ISO 14971 provides the framework; your RTM is where the outputs of that framework connect to specific requirements and design elements.
How the template covers ISO 13485
| Tab | ISO 13485 clause covered |
|---|---|
| User Needs | §7.3.3: user needs, intended use, use environment |
| Requirements | §7.3.3 / §7.3.4: design inputs linked to outputs |
| Tests | §7.3.6 / §7.3.7: verification and validation activities |
| Risks | §7.1 / §7.3.3 / ISO 14971: hazards, harms, mitigations per requirement |
The RTMify Status column is especially useful in medical device development because gaps are regulatory findings, not just technical debt. A requirement with NO_TEST_LINKED is a potential 483 observation or notified body major nonconformity. Catching it before the audit is the entire point.
What it doesn’t cover: ISO 13485 also requires post-market surveillance planning, device history records, complaint handling, and supplier qualification. The template covers design control traceability only.
Common ISO 13485 audit gaps
- Risk not linked to requirements. ISO 14971 requires that risk control measures be implemented and verified. If your risk register is a separate spreadsheet with no connection to your requirements or test records, your auditor will note it.
- Verification and validation conflated. A single “test” column that mixes bench testing (verification) and usability studies or clinical evaluation (validation) is a §7.3.6/7.3.7 finding. Separate them in your test records.
- Design inputs that reference only the marketing spec. “Meets marketing requirements” is not a design input. Inputs must be expressed in measurable terms. Requirements that cannot be verified are not requirements.
- No traceability to IFU or labeling. Labeling and instructions for use are design outputs (§7.3.4). If a safety-relevant claim in the IFU doesn’t trace to a requirement and a validation test, you have a gap.
- Purchased software and outsourced processes not controlled (§7.4). ISO 13485 requires control of purchased products and outsourced processes; for software medical devices, IEC 62304 introduces the specific term Software of Unknown Provenance (SOUP) for third-party libraries. Keep a controlled register with version, anomaly evaluation, and direct requirement/test linkage rather than leaving them implicit.
ISO 13485 / medical device specific guidance
IEC 62304 relationship: If your medical device includes software, ISO 13485 design controls govern the overall device; IEC 62304 governs the software development lifecycle. Your RTM bridges both: system requirements trace to software requirements (IEC 62304 §5.2), which trace to tests (§5.7). Use consistent ID prefixes across both frameworks.
Software safety classification: IEC 62304 Class A, B, and C requirements affect how rigorously you must document. Even if you’re only using ISO 13485, assign a safety class to each software requirement and document it. Auditors increasingly ask for this.
Essential Requirements / General Safety and Performance Requirements: For CE marking under MDR 2017/745, each applicable GSPR must be mapped to a standard or a design verification/validation. Your RTM’s User Needs tab is the right place to capture the intent: one row per GSPR, with references to the standards or tests that demonstrate compliance. While the User Needs tab captures intent, ensure the RTM provides a direct line from each applicable GSPR to its corresponding verification evidence. Many auditors expect a dedicated GSPR checklist that cross-references the RTM rather than relying on the RTM alone.
Usability (IEC 62366): Usability validation is distinct from functional validation. Human factors studies, summative evaluations, and use-related risk analyses are validation activities (§7.3.7) and should appear in the Tests tab with a clear VALIDATION type annotation.