What Level 1 Risk Management Maturity Looks Like in Medical Device Organizations

The Audit That Reveals Everything

The notified body auditor asks to see evidence that post-production information has been evaluated against your risk management file per ISO 14971 Section 10. Your quality team looks at each other. Nobody owns that activity. The risk file was completed during development. It hasn't been opened since.

This is not a hypothetical. It plays out in conformity assessments across the industry, and the finding it generates is not a minor nonconformity that can be addressed with a corrective action plan. It exposes a structural gap: the organization built a risk management file but never built a risk management system. The file satisfied a design control milestone. Nothing in the organization's infrastructure ensures that it remains a living document afterward.

Level 1 risk management maturity is defined by this disconnect. Risk activities happen. Risk files exist. But the organizational capability to sustain risk management across the product lifecycle does not.

Where the Dependence on Individuals Shows

The clearest signal of Level 1 is inconsistency that tracks to personnel rather than process. When the senior systems engineer leads hazard identification, the analysis is thorough — broad hazard categories, well-reasoned severity assignments, creative consideration of foreseeable misuse scenarios. When a junior engineer leads the same activity on a different product, the analysis covers the obvious use-case hazards and stops. The depth of the risk file correlates with who wrote it, not with any organizational standard for what it should contain.

This personnel dependence extends to risk acceptability decisions. Ask three engineers on three product teams how they determine whether a risk is acceptable, and you will get three different answers. One references the matrix in the procedure. Another uses professional judgment calibrated against years of experience. A third defaults to whatever the predicate device's risk file documented. None of them are wrong in isolation. Collectively, they reveal that the organization has no operational definition of risk acceptability that produces consistent results across assessors and products.

Probability estimation is where personnel dependence becomes most consequential. Without historical failure rate data, without a calibration exercise to align assessors, and without documented rationale for each estimate, probability scores are arbitrary. A probability rating of 2 on one product's FMEA may represent a fundamentally different failure frequency than a 2 on another product's FMEA, even when the same scale definitions are printed at the top of both worksheets. The risk acceptability decisions that flow from these estimates inherit their arbitrariness.

The Frozen Risk File and Its Consequences

A risk management file that was current at product launch and has not been substantively updated since is the defining documentation artifact of Level 1. It is also the single most consequential regulatory gap, because it implicates multiple clauses of ISO 14971, multiple requirements of EU MDR, and FDA's increasingly explicit expectation of lifecycle risk management.

ISO 14971:2019 Section 10 requires that production and post-production information be collected, reviewed for relevance to safety, and evaluated against the existing risk management file. When a product has been on the market for five years and the risk file shows no evidence of post-market review, the finding writes itself. The organization is not meeting the standard's requirements for ongoing risk management.

Under EU MDR, the consequences compound. Article 83 requires that post-market surveillance feed into risk management. Article 86 requires periodic safety update reports that include conclusions from the benefit-risk determination. The PSUR cannot reach meaningful conclusions about benefit-risk if the risk management file has not incorporated the post-market data that would inform those conclusions. The frozen risk file creates a cascade of documentation gaps across the regulatory framework.

FDA's 21 CFR 820.30(g) has historically been interpreted as a design control requirement, but the agency's total product lifecycle approach and the QMSR alignment with ISO 13485 both signal that risk management limited to the design phase is insufficient. A frozen risk file is a 483 observation that increasingly appears outside the context of design control audits.

How Design Decisions Bypass Risk Intelligence

At Level 1, the risk management file and the design decision process exist in separate workflows. A design change is proposed, evaluated against performance requirements, reviewed for manufacturability, and implemented. The risk file is not consulted. Nobody asks whether the change introduces new hazardous situations, alters the probability of existing ones, or invalidates a risk control measure that the original analysis depended on.

This happens not because engineers are careless but because the organizational process does not require it. The design change procedure references risk analysis as a consideration, perhaps in a checklist item, but the connection is procedural rather than substantive. The checkbox gets checked. The risk file does not get opened.

The result is a growing divergence between the risk file's description of the device and the device's actual design. After several design changes, the risk file describes a product that no longer exists in its original form, and the risks associated with the current design have never been formally evaluated. The document that is supposed to demonstrate ongoing risk management instead demonstrates its absence.

Regulatory Exposure in Plain Terms

Organizations at Level 1 face a specific pattern of regulatory vulnerability. For FDA-regulated products, the exposure centers on 483 observations citing inadequate risk analysis maintenance and absence of post-market risk review. For EU MDR, the exposure is broader: notified body findings related to ISO 14971 Section 10 compliance, inadequate PMS-to-risk-management linkage, and PSUR content that lacks substantive risk analysis. For organizations in both jurisdictions, the risk management gap creates parallel findings that consume disproportionate remediation effort because they reflect a systemic capability deficit rather than an isolated documentation lapse.

The path from Level 1 is not about writing more documents. It is about building the organizational infrastructure that makes risk management a continuous activity rather than a project milestone. That starts with assigning process ownership, establishing post-market review cadences, connecting complaint data to risk files, and calibrating assessors so that risk acceptability decisions mean the same thing across every product team.

Take the Risk Management Maturity Assessment