Risk management: ISO 14971, IEC 31010, FMEA, FTA, HAZOP
Guide, risk management
Risk management is the backbone of a modern certification dossier. Whether the target is a medical device under EU MDR and FDA QMSR, an industrial control system under IEC 61508, a passenger vehicle under ISO 26262, a civil aircraft under ARP4761 or a piece of machinery under ISO 12100, the certifier expects a structured risk file: a documented process (ISO 14971 for medical, sector standards elsewhere), a toolbox of techniques (IEC 31010), bottom-up and top-down analyses (FMEA, FTA), operational scenarios (HAZOP, what-if, STPA), evidence of risk control, and an evaluation of residual risk supported by post-market data. This page maps the landscape, details the techniques actually used at electronics and embedded software level, and lists the recurring pitfalls that cost re-files at certification audit.
Standards map
Section titled “Standards map”Risk management for product certification rests on a small number of standards, organised on three axes: process, techniques, and sector overlays.
| Layer | Standard | Scope |
|---|---|---|
| Process, medical | ISO 14971:2019 | Risk management process for medical devices, full lifecycle |
| Process, medical guidance | ISO/TR 24971:2020 | Guidance for applying ISO 14971, examples, templates |
| Process, generic | ISO 31000:2018 | Generic risk management framework, all sectors |
| Techniques catalogue | IEC 31010:2019 | Some thirty risk assessment techniques, selection by lifecycle phase |
| FMEA / FMECA | IEC 60812:2018 | Failure modes and effects analysis, methodology |
| FTA | IEC 61025:2006 | Fault tree analysis, top-down deductive |
| ETA | IEC 62502:2010 | Event tree analysis, bottom-up inductive |
| HAZOP | IEC 61882:2016 | Hazard and operability studies, guide-word based |
| Sector, automotive functional safety | ISO 26262 | HARA, ASIL determination, safety lifecycle |
| Sector, autonomy SOTIF | ISO 21448 | Safety of the intended functionality, autonomy |
| Sector, aviation | ARP4761 (1996) | FHA, PSSA, SSA, CCA = PRA + ZSA + CMA |
| Sector, machinery | ISO 12100 + ISO 13849 | Hazard analysis and performance level for safety functions |
| Sector, OT cybersecurity | IEC 62443-3-2 | Risk assessment for industrial control systems |
| Sector, automotive cyber | ISO/SAE 21434 | Cybersecurity risk for road vehicles |
| Industry FMEA reference | AIAG-VDA FMEA Handbook (2019) | Action Priority methodology, replaces SAE J1739 and VDA 4 |
The practical consequence is that an electronics or embedded software project rarely picks a single standard. It picks a process spine (ISO 14971 for a medical device, ISO 26262 for an automotive ECU, ARP4761 for an avionics LRU, ISO 12100 for machinery), then draws techniques from the IEC 31010 catalogue (FMEA, FTA, HAZOP, STPA, what-if) and documents them in line with the dedicated IEC method standards (60812, 61025, 61882).
ISO 14971 in practice
Section titled “ISO 14971 in practice”ISO 14971:2019 is the international standard for risk management of medical devices. It is harmonised under EU MDR (Regulation 2017/745) and serves as the de facto reference for demonstrating compliance with GSPR 1 to 4 of Annex I. On the US side, it is recognised by FDA, and the FDA Quality Management System Regulation (QMSR), which replaces 21 CFR Part 820 effective February 2026, incorporates ISO 13485 by reference, which itself relies on ISO 14971 for the risk management process.
Process spine
Section titled “Process spine”ISO 14971 organises risk management as a continuous process across the lifecycle, not a one-off study at design end. The required elements are stable across the 2019 edition:
- Risk management plan approved by management, defining the policy on risk acceptability, the methods chosen and the responsibilities.
- Hazard analysis (foreseeable hazards related to the intended use and reasonably foreseeable misuse), drawing on past data, similar devices, regulatory feedback and clinical literature.
- Risk estimation for each hazardous situation, in two dimensions: severity of harm and probability of occurrence.
- Risk evaluation against the acceptability criteria defined in the plan.
- Risk control by order of priority: (a) intrinsic safety by design, (b) protective measures in the device or the manufacturing process, (c) information for safety (labelling, instructions for use, training).
- Evaluation of residual risk, individually then globally, with benefit-risk analysis.
- Risk management report signed by top management, summarising acceptability of overall residual risk.
- Production and post-production activities: feedback loop from complaints, vigilance, post-market clinical follow-up into the risk file.
Risk acceptability matrix
Section titled “Risk acceptability matrix”ISO 14971 does not impose a specific matrix. It requires the manufacturer to publish its own, justified, and to apply it consistently. A common pattern combines five severity levels (negligible, minor, serious, critical, catastrophic) and five probability levels (improbable, remote, occasional, probable, frequent), with three acceptability zones: broadly acceptable, ALARP (as low as reasonably practicable), unacceptable. The 2019 edition explicitly recognises that risk reduction is required even in the broadly acceptable zone when the state of the art permits it.
Benefit-risk analysis
Section titled “Benefit-risk analysis”When an individual residual risk falls in the ALARP zone, ISO 14971 requires a documented benefit-risk analysis: is the residual risk outweighed by the medical benefit, taking into account alternatives available on the market, the state of the art and the clinical context? The conclusion is documented and re-evaluated as new clinical data becomes available. Overall residual risk receives a separate evaluation across all individual risks together. ISO/TR 24971:2020 provides examples of acceptability matrices, benefit-risk analyses and how to handle changes during production.
IEC 31010, the techniques catalogue
Section titled “IEC 31010, the techniques catalogue”IEC 31010:2019 is the international toolbox for risk assessment. It does not impose a process: it catalogues some thirty techniques, characterises each (objective, strengths, limitations, data needs) and proposes a selection table by lifecycle phase and analysis depth.
Main families
Section titled “Main families”| Family | Examples | Typical use |
|---|---|---|
| Identification techniques | Brainstorming, Delphi, structured what-if (SWIFT), checklist | Exploration of hazards in early design |
| Single-failure inductive | FMEA, FMECA | Component or sub-system level, electronic boards |
| Deductive top-down | FTA, cause-and-effect analysis | Combined failures, feared event probability |
| Inductive scenario | ETA (event tree analysis) | Consequences of an initiating event |
| Guide-word deviation | HAZOP, SWIFT | Continuous processes, programmable logic, operational sequences |
| Probabilistic | Bayesian networks, Markov chains, Monte Carlo | Reliability with dependencies, uncertain data |
| Human factors | HRA (human reliability analysis), task analysis | Use errors, operator interventions |
| Business impact | BIA, scenario analysis | Operational and commercial consequences |
| Systems-theoretic | STAMP/STPA | Cyber-physical, software-heavy, autonomous |
Selection logic
Section titled “Selection logic”The right technique is not the most sophisticated, it is the one that matches the available data and the maturity of the design. A concept-phase project typically uses brainstorming and SWIFT, then introduces a system-level FMEA when the architecture stabilises, an FTA on the most severe feared events when the design is detailed enough, and HAZOP on the programmable functions when the software architecture is stable. A late-lifecycle product uses post-market data feedback, Bayesian update, and root cause analysis on complaints.
FMEA and FMECA
Section titled “FMEA and FMECA”FMEA (Failure Mode and Effects Analysis) and FMECA (its criticality-extended variant) are the most widely used techniques in electronics certification, across sectors. The methodological reference is IEC 60812:2018, complemented by the AIAG-VDA FMEA Handbook (2019) for automotive.
Variants
Section titled “Variants”| Variant | Scope | Typical use |
|---|---|---|
| System FMEA | Functional architecture, interfaces | Concept design phase |
| Design FMEA (D-FMEA) | Components, sub-assemblies, design choices | Detailed design, board level |
| Process FMEA (P-FMEA) | Manufacturing process | Industrialisation, production |
| Service FMEA | Maintenance, repair, end of life | Operations support |
| Software FMEA | Software functions, exceptions, modes | Embedded software (limited predictive value alone) |
RPN versus Action Priority
Section titled “RPN versus Action Priority”The classic FMEA methodology ranks each failure mode by Risk Priority Number, RPN = Severity x Occurrence x Detection, on scales generally 1 to 10. The AIAG-VDA FMEA Handbook (2019) retired RPN for automotive in favour of Action Priority (AP), which categorises priority as High, Medium or Low based on the combined SOD triplet, treating severity as non-compensable.
The reason for the change: published studies on FMEA noted that very different SOD triplets produce identical RPN, which loses the ranking, and that a low detection score can dilute a high severity. Several certifying bodies now explicitly require severity to be treated as non-compensable: above a defined severity threshold (typically S = 9 or 10), a control action is mandatory regardless of RPN or detection. Outside automotive, IEC 60812:2018 documents both approaches and leaves the choice to the project, on condition of consistency and traceability.
Frequent errors
Section titled “Frequent errors”- Severity scale unstable between FMEA worksheets, which makes the prioritisation incomparable across the dossier,
- Detection inflated by counting tests that have not actually been performed, optimistic in nature,
- Occurrence under-estimated by ignoring field returns from similar products,
- FMEA performed too late, after design freeze, with no influence on the choices made,
- Action plan not traceable to verification evidence in the dossier.
FTA, ETA and cut sets
Section titled “FTA, ETA and cut sets”Fault Tree Analysis (FTA, IEC 61025:2006) is a deductive top-down technique: starting from a feared event, the analyst decomposes the logical causes through AND and OR gates down to basic events of identified probability. Event Tree Analysis (ETA, IEC 62502:2010) is the symmetrical inductive technique: starting from an initiating event, it explores the consequence branches based on the success or failure of barriers and protective measures.
FTA in practice
Section titled “FTA in practice”The strength of FTA is its ability to quantify the probability of a feared event from basic-event probabilities, and to identify the minimum cut sets, that is the smallest combinations of basic events that lead to the feared event. A cut set of size one is a single point of failure, generally unacceptable on a top-level feared event. Avionics under ARP4761 systematically uses FTA at PSSA (Preliminary System Safety Assessment) and SSA (System Safety Assessment) level, with combined target probabilities derived from event severity (catastrophic 1E-9, hazardous 1E-7, major 1E-5, minor 1E-3 per flight hour).
ETA in practice
Section titled “ETA in practice”ETA complements FTA by tracking what happens after the failure: which barriers operate, which protections engage, what is the expected consequence (negligible incident, controlled emergency, accident). It is widely used in process industries, nuclear and chemical, and increasingly in autonomous mobility to model behaviour after an internal failure (degraded mode, safe stop, handover to the driver).
Frequent errors
Section titled “Frequent errors”- Incomplete basic-event coverage, which produces an optimistic top-event probability,
- Independence wrongly assumed between basic events that share a common cause (a power supply, a software module, a sensor),
- Probabilities unsourced, generic figures borrowed without justification from a database (FIDES, Telcordia, MIL-HDBK-217),
- Lack of update when the design or component selection evolves.
For probability targets and common-cause analysis, see aviation safety assessment entries.
HAZOP and structured what-if
Section titled “HAZOP and structured what-if”HAZOP (Hazard and Operability Study, IEC 61882:2016) was developed in the 1960s by ICI for the process industries and remains the reference technique for continuous-flow systems, but its scope has extended to programmable logic, control systems and embedded software.
Method
Section titled “Method”The system is divided into nodes (a portion of pipe, a piece of equipment, a software function). For each node, the analyst defines the design intent, then applies guide words to that intent: NO (intent not achieved), MORE (more than intended), LESS (less than intended), AS WELL AS (intent plus extra), PART OF (intent partial), REVERSE (opposite of intent), OTHER THAN (something different from intent). Each guide-word combination is examined: is the deviation possible, what is the cause, what is the consequence, what protection exists, what action is needed?
Adaptation to programmable systems
Section titled “Adaptation to programmable systems”For software functions, the guide words are adapted: NO becomes "function does not execute", MORE becomes "executes too often or too long", LESS becomes "executes too rarely or too briefly", REVERSE becomes "executes the inverse function". IEC 61882:2016 documents this software extension and is used in programmable functional safety dossiers (IEC 61508, ISO 26262), in railway (EN 50128) and in industrial control system cybersecurity (IEC 62443-3-2).
Frequent errors
Section titled “Frequent errors”- HAZOP nodes too coarse, which masks intermediate deviations,
- Design intent not formalised at the node level, making guide-word application empty,
- HAZOP performed by a single engineer, whereas the method gains its power from a multidisciplinary group session led by a facilitator,
- No traceability from HAZOP findings to design changes or verification.
STAMP and STPA
Section titled “STAMP and STPA”STAMP (Systems-Theoretic Accident Model and Processes), developed by Nancy Leveson at MIT, treats safety as a control problem rather than a chain of failures. The analysis method STPA (Systems-Theoretic Process Analysis) identifies unsafe control actions in the control structure of the system: a controller issues a control action, an actuator executes it, a process responds, sensors feed back to the controller. STPA explores four classes of unsafe action: a needed control action not provided, an unsafe action provided, an action provided too early or too late, an action stopped too soon or applied too long.
STPA is increasingly cited in autonomous driving in support of ISO 26262 and ISO 21448, in advanced robotics (see industrial robotics, ISO 10218 and 15066), and in complex medical devices with significant embedded software. It does not replace FMEA or FTA, it complements them on the systemic and software-heavy axis where component-level failure analysis is poorly predictive.
Sector overlays
Section titled “Sector overlays”| Sector | Risk approach | Key references |
|---|---|---|
| Medical | ISO 14971 + design controls under ISO 13485, MDR / FDA QMSR | ISO 14971, ISO 13485, MDR Annex I, 21 CFR 820 / QMSR |
| Automotive functional safety | HARA (Hazard Analysis and Risk Assessment), ASIL determination | ISO 26262, ISO 21448 for autonomy |
| Automotive cybersecurity | TARA (Threat Analysis and Risk Assessment) | ISO/SAE 21434, UNECE R155, R156 |
| Aviation | FHA, PSSA, SSA, CCA = PRA + ZSA + CMA | ARP4761 (1996), AC 25.1309, DO-178C, DO-254 |
| Machinery | Hazard analysis, performance level for safety functions | ISO 12100, ISO 13849, IEC 62061 |
| Process and OT | Layer-of-Protection Analysis, SIL determination | IEC 61511, IEC 61508 |
| Industrial cybersecurity | Zones and conduits, cybersecurity risk assessment | IEC 62443-3-2, IEC 62443-4-1 |
| Radioactive, pharma | QRM (Quality Risk Management) | ICH Q9 |
The pattern is consistent: each sector defines its own risk acceptability criteria (ASIL for automotive, DAL for avionics, PL for machinery, SIL for process), and uses the IEC 31010 techniques to populate the analysis. A multi-target product (a connected medical device with an automotive infotainment variant, or an industrial controller with cybersecurity) maintains aligned risk files across sectors, drawing on the same FMEA and FTA backbone with sector-specific overlays.
Documentation chain
Section titled “Documentation chain”A complete risk file establishes the traceability chain from hazard to verification.
- Hazard list (intended use, foreseeable misuse, environmental, electrical, mechanical, software, cybersecurity, biological if applicable),
- Risk estimation by hazard (severity, probability, initial risk level),
- Risk control measures (intrinsic safety, protections, information for use), allocated to design requirements,
- Verification evidence by control measure (test, analysis, inspection, review), referenced to the verification dossier,
- Residual risk evaluation by hazard (post-control severity and probability, acceptability),
- Overall residual risk evaluation (aggregation, benefit-risk if applicable),
- Risk management report signed by top management,
- Post-market feedback (complaints, vigilance, field data) fed back into the risk file at each review.
Each chain link references the next by document number and version, so that an auditor can follow a hazard from its identification through to the verification evidence and the post-market data that confirm (or invalidate) the estimated probability.
Integration into the certification dossier
Section titled “Integration into the certification dossier”The risk file is rarely a standalone document. It nests into the certification dossier alongside design controls, verification and validation, manufacturing process and post-market surveillance. For consistent integration, see QMS overview (ISO 9001, AS 9100, ISO 13485, TL 9000) and laboratory and measurement safety, IEC 61010. For cybersecurity-specific risk in connected products, see Cyber Resilience Act (CRA).
A common integration pattern in a medical device dossier: ISO 14971 risk management plan and report at the top, FMEA on the electronic board feeding the design FMEA on the device, FTA on the most severe feared events (electrical shock, incorrect dose, false alarm), HAZOP on the embedded software functions and on the user-interaction sequences, and a traceability matrix linking each control measure to a design requirement and to verification evidence.
Frequent pitfalls
Section titled “Frequent pitfalls”| Pitfall | Consequence |
|---|---|
| Risk file produced as a one-off deliverable, not maintained across the lifecycle | Field returns not fed back, residual risk evaluation becomes obsolete |
| FMEA used as a checkbox without traceability to design controls | Notified body finds the link between control action and design requirement broken |
| FTA with incomplete basic-event coverage | Top-event probability optimistic, hidden single points of failure |
| FTA assuming independence of common-cause events | Combined probability under-estimated, common-cause failure unmitigated |
| RPN dichotomy masking high-severity items | Severe risk insufficiently controlled because detection score lifted the rank |
| HAZOP nodes too coarse | Intermediate deviations missed, programmable function uncovered |
| Single-engineer HAZOP instead of multidisciplinary session | Method loses its power, scenarios overlooked |
| Probabilities borrowed from a generic database without justification | Quantitative analysis weakly defensible at audit |
| Individual residual risks not aggregated into an overall residual risk | Benefit-risk analysis on the device as a whole missing or unsupported |
| Risk management report not signed by top management | Formal non-conformity under ISO 14971 |
Going further
Section titled “Going further”- Industrial robotics, ISO 10218 and 15066: sector-specific HRA and collaborative safety
- Laboratory and measurement safety, IEC 61010: risk analysis for measurement and laboratory equipment
- QMS overview (ISO 9001, AS 9100, ISO 13485, TL 9000): quality system within which the risk file is maintained
- Cyber Resilience Act (CRA): cybersecurity risk under the EU CRA, integration with ISO/IEC 27005 and IEC 62443
- Glossary: definitions of FMEA, FMECA, FTA, ETA, HAZOP, STPA, ASIL, DAL, SIL, PL, ALARP, GSPR
See also
Section titled “See also”- MDR: the EU Medical Device Regulation (2017/745)
- MDR class IIb and III: UDI, EUDAMED, NB, surveillance
- IVDR (EU) 2017/746: in vitro diagnostic medical devices
- FDA 510(k), De Novo and PMA: US medical devices
Sources & references
- ISO 14971:2019, Medical devices, Application of risk management , ISO www.iso.org/standard/72704.html
- ISO/TR 24971:2020, Guidance on the application of ISO 14971 , ISO www.iso.org/standard/74437.html
- IEC 31010:2019, Risk management, Risk assessment techniques , IEC www.iso.org/standard/72140.html
- IEC 60812:2018, Failure modes and effects analysis (FMEA and FMECA) , IEC webstore.iec.ch/publication/26359
- IEC 61025:2006, Fault tree analysis (FTA) , IEC webstore.iec.ch/publication/4311
- IEC 61882:2016, Hazard and operability studies (HAZOP studies) , IEC webstore.iec.ch/publication/24321
- AIAG-VDA FMEA Handbook (2019), Action Priority methodology , AIAG and VDA www.aiag.org/quality/automotive-core-tools/fmea