Designing a Risk Matrix for ISO 14971: Examples and Pitfalls

A risk matrix is a decision tool inside an ISO 14971 risk management system. It is not the system itself. In audits and technical documentation reviews, failures rarely come from “not having a matrix.” Failures come from using the matrix as a shortcut: replacing hazard logic with scoring, hiding uncertainty inside arbitrary categories, and applying criteria inconsistently across design changes and post-market signals.

This guide shows two practical matrix examples, how to define severity and occurrence categories for medical devices, and the pitfalls that create weak traceability and indefensible residual risk conclusions. For end-to-end implementation context (plan → analysis → evaluation → control → PMS), use ISO 14971 Risk Management System: Step-by-Step Implementation.

1) What a risk matrix must accomplish in medical devices

A matrix must produce consistent, auditable decisions. That requires it to do three jobs well.

• Standardize decisions: multiple reviewers should reach the same acceptability outcome for the same scenario, using defined criteria.
• Trigger required actions: the output must translate into control requirements, evidence requirements, and residual risk evaluation expectations.
• Support lifecycle governance: when device changes or post-market signals occur, the matrix and criteria must remain stable so risk conclusions can be compared over time.

Keep the matrix subordinate to hazard logic. You still need hazard → hazardous situation → harm pathways, with controls mapped to specific pathway steps. Without that, a “risk score” is not defensible evidence.

2) Design rules before you build the grid

Rule A: Lock criteria in advance

Define severity categories, occurrence categories, and acceptability zones in your risk management planning and governance. Changing thresholds after results appear is a credibility collapse under audit.

Rule B: Separate the decision tool from the evidence

The matrix outputs decisions. Evidence comes from design outputs, process controls, verification reports, and post-market review records. Never treat the cell outcome as evidence.

Rule C: Avoid false precision

Occurrence in particular is rarely “known” in development. Build categories that allow bounded assumptions and explicit uncertainty handling, then compensate with controls and monitoring triggers.

Rule D: Keep the acceptability result explicit

Cells should map to decision states that drive action, not just “numbers.” Use three auditable states as a baseline:

• A: Acceptable
• T: Tolerable with controls (risk controls required and verified; residual risk evaluated)
• U: Unacceptable (must reduce risk; cannot be accepted without stronger rationale and governance)

Rule E: Prevent “matrix-only” risk evaluation

Residual risk acceptance must be tied to implemented controls and objective evidence. The matrix does not replace residual risk evaluation logic.

3) Severity categories: practical definitions that survive audit

Severity must be defined in clinical/user impact terms that match your device and use environment. Avoid vague labels (“minor,” “major”) without explicit meaning. Define what the user/patient outcome looks like.

Example severity set (5 levels)

• S1 – Negligible: no injury; transient inconvenience; no clinical intervention required.
• S2 – Minor: minor reversible harm; minimal intervention; short-term impact.
• S3 – Serious: reversible harm requiring medical intervention; significant temporary impairment; hospitalization possible depending on context.
• S4 – Critical: irreversible harm or life-threatening injury; major intervention required.
• S5 – Catastrophic: death or permanent severe injury with high severity outcome.

Apply severity to the harm outcome, not to the failure mode. A software error can be S1 in one context and S4 in another depending on how it propagates to hazardous situations and user actions.

Severity pitfalls that drive nonconformities

• Using “device damage” as severity: device damage is a failure mode outcome, not a patient/user harm outcome. Translate to credible harms.
• Ignoring environment of use: home use variability changes harm pathways and mitigations.
• Worst-case without plausibility: severity should reflect credible harm scenarios. Document rationale when selecting worst credible harm.

4) Occurrence categories: define an approach that acknowledges uncertainty

Occurrence must be defined so it can be applied consistently during development and refined post-market. Medical device teams often fail here by inventing probabilities with no basis, or by importing generic frequency bands that do not match their evidence base.

Example occurrence set (5 levels, development-friendly)

• O1 – Remote: not expected in normal use; requires multiple unlikely conditions; no known occurrences in similar devices.
• O2 – Unlikely: possible but not expected; limited precedents; would require specific contributing factors.
• O3 – Possible: credible under normal use or foreseeable misuse; could occur without extraordinary conditions.
• O4 – Likely: expected to occur given normal use variation; known patterns in similar devices or early testing.
• O5 – Frequent: expected to recur unless controlled; commonly observed failure pattern in field data or testing.

Evidence sources you should reference when assigning occurrence

• Complaint history and returns for legacy/similar devices (normalized to units shipped where possible).
• Verification and reliability testing results that reveal failure propensity.
• Process capability and inspection escape data for manufacturing-related hazards.
• Use-related testing outcomes (where available) that show error likelihood patterns.
• Literature and known issue patterns in the device category (treated as supporting signals, not sole proof).

Occurrence pitfalls that drive weak traceability findings

• False numeric precision: converting guesses into numbers creates defensibility risk. Use bounded categories with rationale.
• Mixing detection into occurrence: detection is a control property. If you use detection concepts, define them separately and do not bury them inside occurrence labels.
• Using complaint count without context: raw counts without exposure (units shipped, usage frequency) distort occurrence reasoning.

5) Sample matrix #1: 5×5 matrix (scales well for growing manufacturers)

This example uses a 5-level severity (S1–S5) and 5-level occurrence (O1–O5). Cells map to A/T/U states. Use it when you need enough resolution for product families and long lifecycle governance.

Legend

• A: Acceptable (document rationale; monitor assumptions)
• T: Tolerable with controls (controls required; implementation + verification evidence; residual risk evaluated)
• U: Unacceptable (risk reduction required; cannot remain without stronger control strategy and documented governance)

5×5 matrix example (A/T/U)

Occurrence \ Severity	S1	S2	S3	S4	S5
O5	T	U	U	U	U
O4	A	T	U	U	U
O3	A	T	T	U	U
O2	A	A	T	T	U
O1	A	A	A	T	T

How to use this matrix without creating audit exposure

• Define what “T” means operationally: required controls, required verification evidence, required residual risk evaluation, and required information for safety assessment.
• Define “U” escalation rules: who decides, what additional evidence is required, and how design changes are assessed.
• Document rationale for boundary cells: when a scenario sits on a boundary, record why it was categorized as O2 vs O3, or S3 vs S4.
• Keep the cell result stable across time: only change occurrence/severity when evidence changes, not because reviewers disagree.

6) Sample matrix #2: 3×3 matrix (minimum viable for startups, higher governance discipline required)

A 3×3 matrix can work when you have a small product scope and limited data, but it increases the burden on rationale and governance. With fewer categories, small shifts in interpretation can change outcomes dramatically.

Severity (3 levels)

• S1 – Minor: no or minor reversible harm.
• S2 – Serious: reversible harm requiring intervention.
• S3 – Critical: irreversible harm, life-threatening injury, or death.

Occurrence (3 levels)

• O1 – Unlikely: not expected in normal use; requires unusual contributing factors.
• O2 – Possible: credible under normal use variation or foreseeable misuse.
• O3 – Likely: expected to occur unless robustly controlled.

3×3 matrix example (A/T/U)

Occurrence \ Severity	S1	S2	S3
O3	T	U	U
O2	A	T	U
O1	A	T	T

When this matrix is appropriate

• Early-stage products where evidence is still being generated, but governance discipline is strong.
• Single device family with limited variants and limited exposure pathways.
• Teams that will enforce consistent rationale documentation and defined triggers for re-evaluation.

Additional controls required with a 3×3 matrix

• Stronger rationale requirements: every O and S assignment requires documented basis and uncertainty statement.
• Stronger escalation for “T” and “U”: fewer categories mean “T” covers a broad range; define minimum required controls and evidence for every “T.”
• Stronger post-market triggers: because development estimates are coarse, define clear PMS thresholds to re-evaluate occurrence categories.

7) Defining acceptability and residual risk expectations

Matrix outcomes must translate into auditable actions. The most common failure is treating “T” as a passive label. “T” must trigger specific control and evidence expectations.

Acceptability state definitions (operational)

• A (Acceptable): risk may be accepted with documented rationale and defined monitoring assumptions; controls may still be applied if feasible and proportional.
• T (Tolerable with controls): risk controls are required. You must show implementation and verification evidence references, then evaluate residual risk explicitly.
• U (Unacceptable): risk reduction required. If controls cannot reduce risk adequately, escalation and governance decisions are required, and residual risk acceptance must be defensible and explicitly justified.

Residual risk evaluation discipline

Residual risk ISO 14971 evaluation is not “move to a lower cell and stop.” It is the documented conclusion after controls are implemented and verified.

• Control implementation evidence: design requirements, software requirements, process controls, inspection plans, labeling statements.
• Verification evidence: test reports showing control performance against requirements.
• Communication alignment: information for safety must match the remaining hazardous situation pathways.
• Monitoring assumptions: define what post-market signals would challenge the conclusion.

8) Pitfalls that create audit findings and how to prevent them

Pitfall 1: Using the matrix to replace hazard logic

Failure mode: hazards are listed with a score but no credible sequence-of-events reasoning. Controls cannot be mapped to pathway steps.

Prevention: require hazard → hazardous situation → harm logic, and require each control to identify which pathway step it breaks.

Pitfall 2: Inconsistent category application across reviewers

Failure mode: different teams score the same scenario differently. Auditors detect inconsistency when sampling similar hazards or changes.

Prevention: define category definitions with examples; require rationale for O and S assignments; run calibration sessions for reviewers; keep a controlled “rating guide” annex.

Pitfall 3: Changing criteria after results appear

Failure mode: acceptability thresholds are changed to avoid redesign or to justify acceptance. This is visible in document history and undermines credibility.

Prevention: lock criteria in the ISO 14971 risk management plan; require controlled change governance to modify criteria with justification and approval.

Pitfall 4: Embedding detection or control performance inside occurrence

Failure mode: occurrence categories are adjusted because a control exists (“we detect it, so occurrence is low”). That conflates pre-control likelihood with post-control exposure.

Prevention: assign occurrence for the hazardous situation pathway, then document the control and its verification evidence separately; evaluate residual risk after controls.

Pitfall 5: Treating labeling as a primary control by default

Failure mode: teams jump to warnings and IFU statements without demonstrating design or protective controls were considered and implemented where feasible.

Prevention: enforce a control hierarchy decision record: inherent safety by design first, then protective measures, then information for safety.

Pitfall 6: No lifecycle triggers (“keep alive” missing)

Failure mode: the matrix is applied once during development; complaints and post-market signals do not trigger re-evaluation; auditors flag the risk file as stale.

Prevention: define event triggers and review cadence; require documented outcomes of each review; update occurrence assumptions when field evidence changes.

9) Practical implementation steps (build and deploy)

1. Define severity and occurrence categories: clinical/user outcome definitions for severity; development-credible occurrence definitions with evidence sources.
2. Define acceptability zones: A/T/U decision states with required actions and evidence expectations.
3. Choose the matrix size: 5×5 for scalable governance; 3×3 only with stronger rationale and triggers.
4. Write usage rules: when to assign ratings, how to document rationale, and how to treat uncertainty.
5. Integrate residual risk discipline: require control implementation evidence references and verification evidence references for every “T” and “U.”
6. Implement governance: lock criteria; control changes; define approval checkpoints; ensure reviewer calibration.
7. Define lifecycle triggers: design changes, supplier/process changes, complaint trends, field actions, vigilance signals.

Conclusion

A risk matrix supports consistent decisions only when it is built on clear definitions, stable governance, and explicit linkage to controls and objective evidence. Use the matrix to standardize decisions, not to replace hazard reasoning. Enforce residual risk discipline and lifecycle triggers so the tool remains defensible as the device evolves and post-market data accumulates.

To integrate matrix design into the full workflow and keep the risk management system alive across design changes, controls, and PMS updates, use ISO 14971 Risk Management System: Step-by-Step Implementation.