What ISO 13485 requires for traceability
ISO 13485:2016 is the quality management standard for medical device design and manufacture. It is a registration standard, and your notified body (CE marking) or FDA 510(k)/PMA process will involve an audit of your design controls. 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 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 / 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.
- Software of Unknown Provenance (SOUP) not tracked. For software medical devices, every third-party library is a SOUP item. These should appear in your requirements (as dependencies) with documented assessment of their impact on safety.
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 this mapping. One row per GSPR, with references to the standards or tests that demonstrate compliance.
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.