Design Controls × Device Risk Management
Design controls and ISO 14971 risk management read as two processes, but regulation interlocks them: risk outputs become design inputs, verification must confirm the risk controls, and neither file is defensible without the other.
What this page does not claim
An intersection covers what happens only where two axes overlap. It does not restate what either parent page says, and it is not a substitute for reading them.
WHAT ONLY EXISTS IN THE OVERLAP
- Risk management is not a parallel document that sits beside the design file. ISO 14971's risk-control measures become design inputs, and design verification must demonstrate those controls were implemented and are effective. The traceability that binds hazard to control to verified output is the actual deliverable of the overlap — and the first thing an auditor pulls.
- How much verification rigour a design output earns is a risk decision, not a uniform rule. Quality risk management sets where the effort concentrates, so a design-control programme that verifies everything to the same depth has either wasted effort on the trivial or under-tested the critical — usually both.
- IEC 62304's software safety classification is derived from the device's risk analysis, so the depth of the software design-and-verification lifecycle is dictated by risk management upstream. The class is not a property of the software; it is the risk file's verdict on what the software could cause.
- A design change is a risk event. Changing a design output can invalidate a risk control or create a new hazard, so the change cannot be assessed inside the design file alone — it has to re-enter the risk management file, which is where the two processes prove they are actually one loop.
- The loop closes after launch. Production and post-production information feeds back into risk management under ISO 14971, and through it into design and CAPA — so post-market signals are a design-control input, not a separate complaint-handling activity.
Two files, one traceable spine
Design controls under 21 CFR 820.30 and the design-and-development clause of ISO 13485 describe a disciplined progression: user needs become design inputs, inputs become outputs, outputs are verified against inputs and validated against needs, and the whole history is captured. ISO 14971 describes a different progression: hazards are identified, risks estimated and evaluated, risk controls implemented, and residual risk assessed. Read separately they look like adjacent obligations a manufacturer happens to owe at the same time. They are not adjacent. The regulation wires them together at specific joints, and the overlap is precisely those joints — the places where an output of one process is a mandatory input to the other.
The load-bearing joint is the one auditors probe first. A risk-control measure decided in the risk file — an alarm, a mechanical interlock, a software limit, a labelling constraint — is not implemented in the risk file; it is implemented as a design output, which means it must appear as a design input and be confirmed by design verification. So the risk management file and the design history file are two views of a single traceable spine: hazard to risk control to design input to design output to verification evidence. When that spine is intact, either document can be read forward or backward and the story holds. When a device runs design controls and risk management as two teams filling two templates, the spine is broken exactly where it matters — a risk control asserted in one file with no verified design output in the other — and that gap is not a paperwork nuisance but a claim that a hazard was addressed with no evidence that it was.
Risk sets the depth of verification
Design verification answers a simple question — does the output meet the input — but it does not answer it at a uniform intensity, and deciding the intensity is where quality risk management enters the design process rather than sitting outside it. A design output that implements a risk control for a serious harm warrants verification proportionate to what rides on it; an output with no safety consequence does not warrant the same rigour. This is the same proportionality principle QRM applies everywhere, pointed at design V&V: the risk analysis tells the design team where to concentrate verification effort, what sample sizes and conditions the evidence must survive, and which outputs are so consequential that verification alone is insufficient and validation under actual-use conditions is required.
Software is where this dependency is most explicit and most often mishandled. IEC 62304 assigns a software safety class — A, B, or C — and the class determines how much of the software lifecycle's rigour applies: architecture detail, unit verification, traceability depth. Critically, the class is not chosen by the software team's sense of complexity; it is derived from the ISO 14971 risk analysis, from what the software could contribute to a hazardous situation given the risk controls external to the software. A team that classifies its software before, or independently of, the device risk analysis has put the answer before the question. The correct order runs from hazard to risk to the software's possible contribution to safety class to lifecycle rigour — device risk management setting the depth of the software design controls, not the reverse.
A design change is a risk event
Change control on a device design looks, from inside the design file, like a bounded activity: an output changes, the affected verifications are repeated, the design history is updated. That view is incomplete in a way the overlap exposes. A design output frequently is a risk control, or interacts with one, so changing it can silently defeat a control that a hazard depended on, or introduce a new hazard the original analysis never saw. The change therefore cannot be assessed within the design file alone — it has to re-enter the risk management file, where its effect on existing risk controls and its potential to create new hazards is evaluated before the change is accepted.
This is the discipline that separates a design change managed as configuration from one managed as safety. The question is never only 'does the changed output still meet its input'; it is also 'does this change weaken a risk control, invalidate a residual-risk conclusion, or open a new hazard'. A change that improves manufacturability by altering a material, or simplifies a workflow by removing a confirmation step, can pass design verification cleanly while quietly raising risk — and only the risk file will catch it, and only if the change is routed through it. Manufacturers who keep design change control and the risk management file synchronised treat every design change as a prompt to revisit risk; those who let the two drift apart accumulate a risk file that describes a device that no longer exists, which is among the most common and most serious findings at the intersection.
The loop closes after launch
The design and risk processes are often drawn as a development activity that ends at transfer to production, but ISO 14971 explicitly refuses to let the risk file close there. It requires that information from production and the post-production phase — complaints, field performance, manufacturing signals, comparable-device data — be collected and fed back into risk management, because a hazard's real-world probability is knowable only once the device is in use. That feedback is not a standalone vigilance activity running in parallel; it is an input that can change a risk estimate, and a changed risk estimate can demand a new or strengthened risk control, which lands back in the design controls as a change.
This is where the overlap becomes a full loop rather than a one-way handoff, and where it meets the quality system's CAPA machinery. A post-market signal that raises a risk beyond what the design currently controls is a corrective-action trigger whose remedy is often a design change — closing the circle from field data to risk re-evaluation to design update to re-verification. A device programme that treats post-market information as complaint-handling, disconnected from the risk file and the design history, has broken the loop at its most consequential point: the moment reality contradicts the pre-market risk assumptions. Under the harmonised quality-system regulation that incorporates ISO 13485, this feedback is not optional diligence; it is the mechanism by which the design and risk files stay true to the device that is actually in patients' hands.
Derived from the 4 standards SPEQ maps to this intersection, across 3 regulatory bodies: FDA, ISO, IEC.
FREQUENTLY ASKED
Is the risk management file separate from the design history file?
They are separate documents that regulation deliberately interlocks, so treating them as independent is the classic mistake. A risk-control measure decided in the ISO 14971 file is implemented as a design output, which means it must appear as a design input and be confirmed by design verification — so hazard, risk control, design input, design output, and verification evidence form one traceable spine seen from two angles. When the spine is intact, either file can be read forward or backward and the story holds. When design controls and risk management run as two teams filling two templates, the break shows up as a risk control asserted in one file with no verified design output in the other, which is a hazard claimed as addressed with no evidence that it was.
How does risk management decide the depth of design verification?
Through the same proportionality principle quality risk management applies everywhere, pointed at design V&V. A design output that implements a risk control for a serious harm earns verification proportionate to what depends on it — the conditions it must survive, the evidence it must produce, and whether verification alone suffices or use-condition validation is also required. An output with no safety consequence does not warrant the same intensity. So the risk analysis, not a uniform procedure, tells the design team where to concentrate effort. A programme that verifies everything to one depth has usually both over-tested the trivial and under-tested the critical, which is exactly the misallocation risk-based verification exists to prevent.
What sets a software item's IEC 62304 safety class?
The device's ISO 14971 risk analysis does — specifically, what the software could contribute to a hazardous situation given the risk controls that sit outside the software. The class (A, B, or C) then determines how much of the software lifecycle's rigour applies, from architectural detail to verification depth to traceability. The order matters and is often reversed in practice: a team that assigns a class from its own sense of the software's complexity, before or independently of the device risk analysis, has put the answer before the question. The defensible sequence runs from hazard to risk to the software's possible safety contribution to class to lifecycle rigour, which means device risk management is setting the depth of the software design controls.
Why is a design change treated as a risk event?
Because a design output is frequently a risk control, or interacts with one, so changing it can defeat a control a hazard depended on or introduce a hazard the original analysis never considered. Assessing the change inside the design file alone answers only whether the changed output still meets its input; it cannot see the safety consequence. Routing the change back through the risk management file asks the second, decisive question — does this weaken a risk control, invalidate a residual-risk conclusion, or open a new hazard. A change that improves manufacturability or simplifies a workflow can pass design verification cleanly while raising risk, and only the risk file, and only if the change enters it, will catch that.