ISO 14971 Medical Device Risk Management
by Nick Clark | Published April 25, 2026
ISO 14971:2019 sets the international baseline for medical-device risk management, requiring manufacturers to identify hazards, estimate and evaluate associated risks, control those risks, and monitor effectiveness across the device lifecycle. As autonomous and semi-autonomous medical devices proliferate, the standard's procedural decomposition increasingly relies on architectural primitives that can express graduated actuation, residual-risk evaluation, and reversibility at the level of individual device behaviors. Governed actuation provides that substrate.
Regulatory Context
ISO 14971:2019 (Medical devices — Application of risk management to medical devices) is the harmonized international standard incorporated by reference into FDA recognition list 13-181, the EU Medical Device Regulation 2017/745 (MDR) Annex I general safety and performance requirements, the In Vitro Diagnostic Regulation 2017/746 (IVDR), Health Canada's CMDR, Japan's PMD Act, and the IMDRF risk-management framework. The standard's clause structure walks the manufacturer through risk-management planning (clause 4), risk analysis (clause 5), risk evaluation (clause 6), risk control (clause 7), evaluation of overall residual risk (clause 8), risk-management review (clause 9), and production and post-production activities (clause 10). Each clause produces documented artifacts that auditors and notified bodies inspect against the risk-management file.
Clause 7.1 of ISO 14971 establishes a strict hierarchy of risk-control options: inherent safety by design, protective measures in the device or manufacturing process, and information for safety including training. The hierarchy is not advisory; clause 7.4 requires the manufacturer to demonstrate that risk has been reduced “as far as possible” (the AFAP criterion in EU MDR contexts) or to acceptable levels per the risk-management plan. Residual risks remaining after each control measure must be re-estimated under clause 7.5, and the introduction of new hazards by the control itself must be analyzed under clause 7.6. The procedural rigor presumes the device's actuation behavior can be characterized, decomposed, and documented as discrete states with predictable outputs.
The 2019 revision tightened benefit-risk analysis (clause 7.4), expanded post-production information feedback (clause 10), and aligned terminology with ISO/TR 24971:2020 guidance. FDA's Predetermined Change Control Plan (PCCP) framework, finalized in December 2024, and the EU AI Act's classification of certain medical-device AI as high-risk under Annex III interact with ISO 14971 by requiring risk management to anticipate post-deployment learning, adaptation, and graduated autonomy. The standard's procedural backbone now sits atop devices whose actuation envelopes shift over time.
The Architectural Requirement
Modern medical devices—closed-loop insulin pumps, robotic surgical assistants, autonomous CT triage, ventilator weaning controllers, neurostimulators with adaptive parameters—do not actuate as binary on/off systems. They select among graduated actuation modes: full intervention, deferred intervention, partial intervention, refusal, or fallback to a safer manual mode. ISO 14971's clause 7 hierarchy implicitly assumes the manufacturer can define and verify each of these modes as a controllable risk-control measure, and that the device can be made to enter the appropriate mode when sensor confidence, patient state, or environmental conditions degrade.
Clause 5.5 requires the manufacturer to identify reasonably foreseeable sequences of events that could produce a hazardous situation. For an autonomous device, those sequences include sensor disagreement, model uncertainty, network partition from a clinician supervisor, and adversarial input. The architectural requirement is that the device's actuation layer must be able to read its own confidence and consequence envelope and select a mode whose residual risk is justified relative to the patient benefit at that moment. Without that capability, clause 7's hierarchy collapses into design-time documentation that does not bind run-time behavior.
Reversibility is the second architectural requirement. Clause 5.4 instructs the manufacturer to characterize the harm associated with each hazardous situation, including its severity and the probability of occurrence. For irreversible harms—intracranial lesion from misdirected ablation, vessel perforation, lethal arrhythmia from miscalibrated defibrillation—risk control must include pre-actuation gates that the device itself enforces, not gates that exist only in the manufacturer's hazard log. Post-actuation verification, the third architectural requirement, closes the loop: clause 10.1 mandates production and post-production monitoring, and the device must produce evidence sufficient for that monitoring to attribute outcomes to specific actuations.
Why Procedural Compliance Fails Alone
Procedural ISO 14971 compliance produces a risk-management file: hazard list, risk estimation matrix, control measures table, residual-risk evaluation, and a clinical evaluation tying the whole structure to intended use. The file is a document. It does not, by itself, prevent the device from actuating beyond the envelope the document describes. When the device firmware encodes clause 7 controls as conditional branches written by humans against a design-time hazard model, every hazard scenario the model did not anticipate becomes an unguarded path to actuation.
FDA Maude reports across infusion pumps, surgical robots, and AI-enabled diagnostics show a recurring pattern: the risk-management file correctly identified the hazard category, the design controls were verified at release, and the device still actuated outside its safe envelope because the run-time check was either absent or written against a degraded version of the hazard model. The 2023 da Vinci recall (FDA Class II, K-numbers in the K22XXXX series) and the 2022 Medtronic HeartWare HVAD market withdrawal both involved actuation behavior whose risk controls existed on paper but did not bind firmware decisions under the specific failure mode that occurred.
Procedural compliance also fails under change. PCCP-governed devices can update models post-clearance within a pre-specified envelope, but ISO 14971 clause 10.3 still requires the manufacturer to revisit the risk-management file when production or post-production information indicates that previously-identified risks are no longer acceptable or that new hazards have appeared. If the device's actuation layer cannot express the envelope as a machine-readable boundary, the post-market signal feeds back through human review only, and the lag between signal and control measure widens with deployment scale.
What Governed Actuation Provides
The governed-actuation primitive treats every actuation decision as a selection among graduated modes—continue, defer, partial, refuse—rather than a single commit/abort branch. Each mode carries declared preconditions (sensor confidence thresholds, supervisor reachability, patient-state bounds), declared consequences (expected effect on the patient, expected reversibility window), and declared evidence requirements (what must be recorded for the actuation to be auditable). The selection is enforced at the actuation boundary, not encoded in upstream business logic that may be bypassed.
Harm minimization is an explicit primitive operation. When the device cannot meet preconditions for full intervention but a partial intervention reduces immediate harm, the primitive selects partial; when even partial intervention exceeds the residual-risk envelope, it selects defer with a handoff signal to the supervisor; when defer is infeasible (autonomous transport ventilator, in-flight medical device, surgical procedure already underway), refuse triggers the pre-declared safe state. The mode lattice maps directly onto ISO 14971 clause 7.1's hierarchy: inherent safety becomes the refuse-to-safe-state default, protective measures become the partial and defer modes, information for safety becomes the supervisor-handoff payload.
Post-actuation verification produces a signed lineage record for every actuation: the mode selected, the preconditions evaluated, the sensor inputs and their provenance, the model version that produced any inferences, and the observed outcome within the verification window. The record is the substrate for clause 10 post-production monitoring. Reversibility evaluation, performed before the actuation commits, classifies each actuation against a reversibility horizon (immediately reversible, reversible within window, irreversible) and gates the irreversible class behind stronger preconditions, including supervisor co-sign where the risk-management plan requires it.
Compliance Mapping
ISO 14971 clause 5.4 (characterization of harm) maps to the primitive's reversibility classification: each actuation is tagged at design time with its harm severity and reversibility horizon, and the tag travels with the actuation through firmware, not only through the risk-management file. Clause 5.5 (foreseeable sequences) maps to the precondition lattice for each mode: sequences that violate preconditions force the device into a more conservative mode rather than executing under stale assumptions. Clause 6 (risk evaluation) maps to the mode-selection policy, which is itself a documented and version-controlled artifact.
Clause 7.1's control hierarchy maps directly onto the mode lattice as described above. Clause 7.4's AFAP/acceptable-risk criterion maps to the primitive's mode-selection invariant: the device commits only to the mode whose declared residual risk is the lowest feasible given current preconditions. Clause 7.5 (residual-risk re-estimation) is performed continuously rather than only at design review, because each mode carries its residual-risk parameters and the primitive logs which mode actually executed.
Clause 8 (overall residual risk) draws on the aggregated lineage records: the manufacturer can compute the actual distribution of mode selections in the field and compare it to the design-time projection. Clauses 9 and 10 (review and post-production) consume the signed lineage stream directly. EU MDR Annex I §3 (risk-management system) and FDA 21 CFR 820.30 (design controls) inherit the same mapping by reference. For PCCP-governed updates under FDA's January 2025 guidance, the primitive's declared envelope provides the machine-readable boundary the agency expects manufacturers to enforce between modifications that fall inside the pre-specified change protocol and those that require new submission.
Adoption Pathway
Adoption begins at the risk-management-plan stage (clause 4.4): the plan declares that actuation will be governed by a mode lattice, names the modes, and ties each to a clause 7.1 control category. The hazard analysis (clause 5) then enumerates failure modes against the lattice rather than against undifferentiated “device actuates incorrectly” nodes, which sharpens both the FMEA and the clinical evaluation. Notified bodies and FDA reviewers receive a risk-management file in which every control measure has a corresponding run-time enforcement point.
For devices already on the market, the pathway is incremental. The manufacturer maps existing firmware decision points onto the mode lattice, identifies actuations currently committed without a refuse path, and adds the refuse and defer modes as design changes under 21 CFR 820.30(i). Where the change is within a PCCP envelope, the modification proceeds without new 510(k); where it expands the actuation envelope, a special 510(k) or PMA supplement carries the updated risk-management file. Post-market lineage records begin populating immediately and feed clause 10 surveillance with stronger evidence than free-text complaint narratives.
For devices in development, the primitive is adopted at architecture review: the actuation layer is specified before the inference layer, and the inference layer is constrained to produce outputs that the actuation layer can map to a mode. This ordering inverts the common pattern in which an ML model is selected first and a risk-control wrapper is added later, and it produces a device whose ISO 14971 file describes behavior the device actually exhibits.
