Risk Management File vs Risk Management Report: ISO 14971 Documentation Explained
Clear guide to the differences between a risk management file and risk management report under ISO 14971:2019 — what each contains, how they relate, traceability requirements, and common audit findings from notified bodies and FDA.
The Documentation Confusion That Trips Up Most Manufacturers
ISO 14971:2019 requires manufacturers to establish and maintain a risk management file — and to produce a risk management report before commercial distribution. These are not the same thing. Yet many medical device companies treat them interchangeably, stuffing everything into one document or producing a report that merely repeats what is already in the analysis records.
This confusion has real consequences. Notified bodies under EU MDR and FDA investigators routinely cite deficiencies in risk management documentation, particularly around traceability and the completeness of the risk management file. The Johner Institute notes that notified bodies "examine these reports intensively because risk management is a key regulatory requirement." Understanding the distinct purpose, structure, and content requirements of each document is essential for passing audits and maintaining compliance throughout the device lifecycle.
This guide explains exactly what goes into each, how they relate to each other, and how to structure your documentation to satisfy ISO 14971:2019 Clause 4.4 (file) and Clause 9 (report).
Risk Management File: The Complete Record Repository
Definition
ISO 14971:2019 Clause 4.4 defines the risk management file as "a set of records and other documents that are produced by risk management." The file is not a single document — it is a compilation of all records generated during the risk management process for a specific medical device or device family.
BSI's white paper on the third edition of ISO 14971 clarifies that the file "further contains (references to) all records and other documents that are produced during the risk management process." It can be physical, electronic, or a combination, but it must be organized so that all records are retrievable and traceable.
What the Risk Management File Must Contain
ISO 14971:2019 Clause 4.5 requires the file to provide traceability from each identified hazard through the entire risk management process. Based on the standard's requirements and practical implementation guidance, the file should include:
Foundational documents:
- Risk management policy (the organization-level framework for risk acceptability)
- Risk management plan for the specific device (Clause 4.2)
- Risk acceptability criteria derived from the policy
Analysis records:
- Description and intended use of the medical device
- Characteristics related to safety (Clause 5.1)
- Hazard identification records (Clause 5.2), including preliminary hazard analysis
- Identification of hazardous situations arising from sequences and combinations of events (Clause 5.3)
- Risk estimation records — severity and probability for each hazardous situation (Clause 5.4)
- Risk evaluation records — acceptable or unacceptable determinations (Clause 6)
Control records:
- Risk control option analysis documentation (Clause 7.1)
- Implementation records for each risk control measure (Clause 7.2)
- Verification that risk control measures were implemented (Clause 7.2)
- Verification of effectiveness of risk control measures (Clause 7.3)
- Residual risk evaluation records (Clause 7.3)
- Benefit-risk analysis records for residual risks (Clause 7.4)
- Risks arising from risk control measures (Clause 7.5)
- Completeness of risk control check (Clause 7.6)
Evaluation records:
- Evaluation of overall residual risk (Clause 8)
- Overall benefit-risk determination (Clause 8)
Review and production records:
- Risk management report (Clause 9)
- Production and post-production activity records (Clause 10)
- Post-market surveillance data feeding back into risk analysis
The Traceability Requirement
ISO 14971:2019 Clause 4.5 states that the risk management file "shall provide traceability for each identified hazard to the risk analysis, the risk evaluation, the implementation and verification of risk control measures, and the evaluation of the residual risks." This is the most frequently cited deficiency in audits.
As Achieve XL explains, traceability serves two purposes: ensuring that every hazard has been addressed through the full risk management process, and providing evidence that the process is complete. If you identify 5 hazards, each with 5 hazardous situations, each potentially leading to 5 different harms, you need traceability through at least 125 individual risk items.
The practical tool for demonstrating this is a risk traceability matrix — a single record linking each hazard to its analysis, controls, verification, and residual risk evaluation. Most notified bodies will look for this matrix during assessment.
File Structure Best Practice
A three-level structure, recommended by risk management consultants, provides clear organization:
| Level | Content | Purpose |
|---|---|---|
| Level 1 | Risk management plan, risk management report, risk traceability matrix | Foundational governance documents |
| Level 2 | PHA, DFMEA, PFMEA, SFMEA, FTA outputs, use-related risk analysis | Failure analysis records |
| Level 3 | Verification evidence, validation results, complaint analysis, post-market data | Supporting evidence |
Risk Management Report: The Closure Document
Definition
ISO 14971:2019 Clause 9 requires that before commercial distribution, the manufacturer review the execution of the risk management plan. The results of this review are documented as the risk management report. The report is a component of the risk management file — not a replacement for it.
BSI's analysis states that the report "forms a crucial part of the risk management file" and "serves as the high-level document providing evidence that the risk management plan has been satisfactorily executed and the objectives have been achieved."
What the Risk Management Report Must Contain
Per ISO 14971:2019 Clause 9, the report documents the outputs of the review and must address:
- Whether the risk management plan was properly executed
- Whether the overall residual risk is acceptable
- Whether appropriate methods are in place to collect and review production and post-production information
- Any remaining residual risks that have been communicated via the IFU or other accompanying documentation
The Johner Institute distinguishes between two approaches to the report:
The academically correct approach: The report contains only the judgments and justifications — a meta-level document that assesses whether the risk management process was executed properly. It does not repeat the analysis data.
The pragmatic approach: Many manufacturers expand the report to include summary tables of risk analysis results, which can be useful for notified body review but risks creating redundancy with the underlying analysis records in the file.
Key Distinction: Report vs. Review
The risk management review (the activity) and the risk management report (the document) are distinct. The review is the systematic examination of the risk management file to determine whether the plan has been executed. The report documents the conclusions of that review.
Top management must also review the suitability of the risk management process at planned intervals — but this is a separate ISO 13485 requirement (management review), not the same as the ISO 14971 risk management review.
File vs Report: Side-by-Side Comparison
| Aspect | Risk Management File | Risk Management Report |
|---|---|---|
| ISO 14971 clause | Clause 4.4 | Clause 9 |
| Nature | Complete repository of all risk management records | Summary document documenting the review of plan execution |
| Timing | Created at project start, maintained throughout lifecycle | Produced at the end of development, before commercial distribution |
| Scope | All risk management activities, analysis, controls, evaluations | Assessment of whether the plan was executed and objectives met |
| Ownership | Cross-functional team contributes | Signed off by person(s) with appropriate authority |
| Lifecycle | Living document — updated with post-market data | Updated when new risks identified or significant changes occur |
| Regulatory focus | Traceability and completeness of risk management process | Evidence that risk management plan was satisfactorily executed |
| Relationship | Contains the report | Is contained within the file |
Common Audit Findings and How to Avoid Them
1. Missing Traceability
The most common finding. Without a traceability matrix linking hazards through controls to residual risks, notified bodies cannot verify completeness. Ensure your file includes a hazard traceability matrix that maps every identified hazard to its risk analysis, evaluation, controls, and residual risk.
2. Report That Simply Repeats Analysis
Some manufacturers produce a report that copies FMEA tables verbatim. This adds no value and creates maintenance problems. The report should focus on the conclusions: Was the plan executed? Is overall residual risk acceptable? What residual risks were communicated?
3. File Not Updated Post-Market
ISO 14971:2019 significantly expanded production and post-production requirements compared to the 2007 edition. The file must be maintained as long as the device is on the market, and production and post-production data must feed back into risk analysis. As Medical Device HQ notes, the file "should be maintained as long as the product is in use and should provide the information necessary to review the risk management process at any phase in the medical device's life cycle."
4. No Clear Distinction Between Plan, File, and Report
The risk management plan (forward-looking), the risk management file (cumulative record), and the risk management report (retrospective assessment) serve different purposes. Conflating them leads to gaps that auditors will identify.
5. Benefit-Risk Analysis Missing or Inadequate
ISO 14971:2019 Clause 8 requires evaluation of overall residual risk using benefit-risk analysis — a requirement that was less emphasized in the 2007 edition. As QServe Group notes, the MDR requires risks to be reduced "as far as possible" (AFAP), and the risk management report must document this determination. This is distinct from the overall benefit-risk analysis required under Clause 8.
EU MDR vs FDA: Documentation Expectations
| Requirement | EU MDR | FDA |
|---|---|---|
| Risk management file | Required as part of technical documentation per Annex II | Expected per design control requirements and ISO 14971 recognition |
| Risk management report | Not explicitly required by MDR text, but required by harmonized EN ISO 14971:2019+A11:2021 | Expected as part of design transfer and design history file |
| Traceability | Notified bodies scrutinize traceability per ISO 14971 Clause 4.5 | FDA expects traceability from design inputs through verification/validation |
| Post-market updates | MDR Articles 83-86 require systematic PMS feeding into risk file | FDA QMSR (effective 2026) aligns with ISO 13485 risk management integration |
| Overall benefit-risk | GSPR 1-3 require AFAP risk reduction with benefit-risk justification | FDA benefit-risk guidance documents apply |
Practical Implementation Checklist
For the risk management file:
- Establish file structure at project initiation
- Define naming conventions and storage location (electronic or physical)
- Create risk traceability matrix template before starting analysis
- Include all records or references to records from risk management activities
- Ensure all verification and validation evidence is captured
- Plan for ongoing updates from production and post-production data
- Review file completeness at each design review milestone
For the risk management report:
- Write the report after all risk management activities are complete
- Address each required element from Clause 9 explicitly
- Include statement of overall residual risk acceptability
- Document communication of residual risks via IFU or labeling
- Obtain sign-off from designated authority
- Plan for report updates when new hazards are identified post-market
For traceability:
- Every hazard in the PHA must be traceable through analysis, control, and residual risk evaluation
- Every risk control measure must have verification of implementation and effectiveness
- The traceability matrix must be reviewed and maintained as a controlled document
- Changes to the risk file must trigger updates to the traceability matrix
Relationship to Other Standards
The risk management file and report do not exist in isolation. Key integration points include:
- ISO 13485:2016 Clause 7.1 — Risk management outputs must be design inputs
- IEC 62366-1 — Use-related risk analysis records feed into the risk management file
- IEC 62304 — Software safety classification and software risk analysis are part of the file
- ISO 10993-1 — Biological evaluation records within a risk management process
- IEC 60601-1 — Basic safety and essential performance risk analysis
- ISO/TR 24971:2020 — Provides practical guidance on documentation structure and methods
The risk management file serves as the central point of integration. All these standards reference or produce records that should be included in or referenced by the file.
Key Takeaways
The risk management file is the complete documentary record of all risk management activities. The risk management report is the closure document that confirms the plan was executed and overall residual risk is acceptable. They are related but distinct: the report is a component of the file, not a substitute for it. Maintaining clear traceability through a risk traceability matrix is the single most important practice for demonstrating compliance during notified body assessments and FDA inspections.