ISO 13485 Clause 7.1 is now FDA’s most-cited finding

When FDA’s Quality Management System Regulation took effect on 2 February 2026, it incorporated ISO 13485:2016 into 21 CFR Part 820. One consequence was procedural: findings are now cited against ISO clauses rather than CFR subparts. The more consequential change was substantive, and it has landed on risk management.

Analyses of early post-QMSR inspection outcomes consistently place Clause 7.1 — planning of product realization at or near the top of cited findings, with risk-related observations accounting for a substantial share of the total. The QMSR warning letters that have posted publicly cite it directly. That is a notable result, because Clause 7.1 is not the clause most organizations expected to be judged on.

What Clause 7.1 actually says

Clause 7.1 requires the organization to plan and develop the processes needed for product realization, and — this is the operative sentence — to document one or more processes for risk management in product realization, retaining records arising from those processes.

Read carefully, that is not a requirement to produce a hazard analysis during design. It is a requirement that risk management be planned as a process across product realization: planning, design and development, purchasing, production and service provision, and monitoring. It sits in the same clause as quality objectives, product requirements, verification and validation activities, and acceptance criteria — because it is meant to govern all of them.

Most organizations have an ISO 14971 risk management process that governs the design file. Fewer have a documented process that specifies how risk is planned into purchasing decisions, into process validation, into change control and into post-production monitoring. That distinction is where the findings are coming from.

The four things being cited

1. Roles that are not defined

The recurring criticism in published warning letter language is that risk procedures do not define who does what. Who owns the risk management file. Who approves a residual risk acceptance. Who decides that a complaint trend warrants a risk file review. Who signs the risk management report. A procedure that describes activities without assigning them is a procedure that cannot be audited against.

2. Triggers that are not specified

The second recurring gap is when. When does the risk file get updated? A procedure that says the file is reviewed “periodically” or “as required” has not answered the question. Defensible triggers are specific: a design change of defined scope, a process change affecting a risk control, a supplier change for a critical component, a complaint rate crossing a defined threshold, a new hazard identified in the field, a change in the state of the art, a defined review interval.

3. No route from post-market data back into the file

ISO 14971 treats risk management as a lifecycle process, and post-production information is an explicit input. In practice, the loop is frequently open: complaints are processed, vigilance decisions are made, trending is performed — and nothing arrives at the risk file. If a risk management file has never been revised as a result of field data, that is worth examining before an investigator examines it.

4. Risk that exists only in the design file

Product risk, process risk, supplier risk and use-related risk are frequently maintained in separate documents by separate functions with no cross-reference. When an investigator follows a specific complaint back through the system, the absence of those links is immediately visible.

What a compliant process contains

A Clause 7.1-defensible risk management process is not longer than what most organizations already have. It is more specific. At minimum it should state:

• Scope — which products, processes and activities the process governs, and how risk management is planned into each stage of product realization.
• Roles and responsibilities — named roles for authoring, reviewing, approving and maintaining risk management files, and for accepting residual risk.
• Risk acceptability criteria — defined before assessment, with the rationale documented, and applied consistently across the portfolio.
• Methods — how hazards are identified, how severity and probability are estimated, which analysis techniques are used at which stage, and how product and process analyses relate to each other.
• Risk control verification — how implementation and effectiveness of each risk control is verified, and where that evidence lives.
• Update triggers — the specific events and thresholds that require the risk management file to be reviewed or revised.
• Post-production feedback — which data sources feed back, who evaluates them, against what thresholds, and how the resulting decision is recorded.
• Records — what is retained, where, and for how long.

The consolidation question

Organizations with large legacy estates — hundreds or thousands of FMEAs accumulated across product families and site transfers — often conclude that Clause 7.1 compliance requires rewriting everything. It usually does not. What it requires is one governed structure in which a hazard, its controls and its evidence can be located and defended, with a documented rationale for how legacy analyses map into it.

Consolidating a fragmented estate into a smaller number of integrated risk management files is achievable, and the reduction can be substantial without any loss of content. The work is in the mapping and the governance, not in the rewriting.

Where to start

Read your own risk management procedure as an investigator would, and ask three questions of it. Does it name who is accountable for each activity? Does it state the specific events that require the file to be updated? Does it describe how field data reaches the file, and what happens when it does?

If the answer to any of them is no, that is the finding, and it is available to be closed before someone else writes it down.