---
title: The Risk Matrix: Designing One That Works for Your Device Type
description: How to design a risk matrix medical device teams can defend: 3x3 vs 5x5, severity scales tied to real clinical consequence, and auditor-proof structure.
authors: Tibor Zechmeister, Felix Lenhard
category: Risk Management Under MDR
primary_keyword: risk matrix medical device
canonical_url: https://zechmeister-solutions.com/en/blog/risk-matrix-medical-device
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# The Risk Matrix: Designing One That Works for Your Device Type

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **A defensible risk matrix medical device teams can take into a notified body audit is one whose severity and probability scales map to real clinical consequence, whose cell count reflects the actual granularity of the device's hazards, and whose acceptance regions are justified by benefit-risk reasoning under MDR Annex I §8. A 3x3 matrix is enough for some simple devices. For software, connected devices, and most implantables, 5x5 usually earns its extra rows. The matrix is not decoration. It is how the reduction obligation in MDR Annex I §4 gets applied to every hazard.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- The matrix is a tool, not a template. It must fit the device, not the other way around.
- Severity levels must describe clinical consequence a clinician recognises, not internal engineering language.
- Probability levels should be quantitative where feasible and qualitative with documented rationale where not.
- 3x3 is enough for devices with narrow hazard diversity. 5x5 is usually needed for software, wearables, implantables, and anything connected.
- The matrix does not decide acceptability on its own. The acceptance regions must be justified under MDR Annex I §4 and §8.
- The matrix must survive the auditor question: "Why this shape and not another?"

## Why this matters

A risk matrix is the most visible output of a risk management process and also the most misunderstood one. Teams treat it as an administrative grid that lives in a QMS template, ticks a box for ISO 14971, and never gets questioned. Auditors treat it as a direct reflection of the manufacturer's clinical reasoning. Those two views rarely meet in the middle.

Tibor's audit experience is blunt about which view wins. A matrix that cannot be defended is a finding. "We used the template the tool came with" is not a defense. "We chose a 5x5 matrix because our device has five distinct severity levels we can describe in clinical terms" is a defense.

Felix's coaching experience is about the other direction: startups freezing on the matrix design step because every template they find online looks equally arbitrary. The fear of picking the wrong matrix delays the entire risk management process by weeks. This post gives a decision rule that unblocks that moment.

## What MDR actually says

MDR does not mandate a specific matrix design. What it mandates is the outcome the matrix has to support.

MDR Annex I §3 requires identification of known and foreseeable hazards, estimation and evaluation of associated risks, elimination or control of those risks, and re-evaluation based on production and post-market data. The matrix is one of the evaluation tools that must support these steps.

MDR Annex I §4 requires risk reduction as far as possible through the control hierarchy. The matrix must make visible which risks have been controlled and which have not, in a form that supports the reduction obligation discussed in [risk evaluation under MDR](/blog/risk-evaluation-acceptable-unacceptable-mdr).

MDR Annex I §5 requires residual risks and their significance to be communicated to the user. The matrix must be able to distinguish the residual risks that need communication from those that do not.

MDR Annex I §8 requires the measures taken to conform to the generally acknowledged state of the art and to keep the benefit-risk ratio favourable. The matrix must reflect this reasoning in its acceptance regions, not only in the cells.

EN ISO 14971:2019+A11:2021 clause 5.5 describes the criteria for risk acceptability that the risk management plan must contain. Clause 7 describes risk evaluation, which is the step where the matrix is applied. Annex C of the standard provides informative guidance on the tools used for risk evaluation, including matrix design, but it is explicitly informative and does not constrain the manufacturer to any one pattern.

What the standard and the regulation both make clear is that the matrix is the manufacturer's responsibility. The cell count, the scale definitions, the acceptance regions, and the rationale are all decisions the manufacturer must own.

## A worked example

Two devices, two matrices, two defenses.

**Device A: a single-use mechanical surgical instrument, Class I.** Hazards are bounded. Sharp edge failure. Incorrect assembly. Biocompatibility of a polymer component. Reuse failure if reprocessed despite being labelled single-use.

A 3x3 matrix can represent these hazards without losing information. Severity levels: reversible minor harm, reversible significant harm, irreversible or life-threatening harm. Probability levels: unlikely given the single-use context, occasional, frequent. The matrix is small because the hazard landscape is small.

The defense to an auditor: "This matrix has three severity levels because our device produces three clinically distinguishable harm outcomes. Finer severity granularity would not map to any real clinical distinction. Three probability levels match our production volume and reuse risk profile. State of the art for comparable single-use instruments uses similar granularity."

**Device B: a wearable patient monitoring device with a mobile app, Class IIa.** Hazards are diverse. False negatives and false positives on the monitored parameter. Skin reactions. Battery thermal events. Cybersecurity compromise of the data channel. Cybersecurity compromise of the alerting logic. App usability failures in older users. Loss of connectivity. Software bugs in the signal processing chain. Data loss affecting clinical decisions downstream.

A 3x3 matrix cannot carry this load. Too many different clinical consequences collapse into the same cell. Either severity granularity is lost (a minor false positive and a life-threatening missed event end up in the same "high severity" bucket) or probability granularity is lost (a bug occurring once per 100,000 uses and a bug occurring once per 1,000 uses end up in the same "rare" bucket).

A 5x5 matrix earns its extra rows. Severity: S1 reversible minor discomfort, S2 reversible harm requiring medical attention, S3 reversible harm requiring hospitalisation, S4 irreversible harm, S5 life-threatening or fatal. Probability: P1 < 1 in 10,000, P2 1 in 10,000 to 1 in 1,000, P3 1 in 1,000 to 1 in 100, P4 1 in 100 to 1 in 10, P5 > 1 in 10. The matrix now distinguishes what the device can actually do to a patient.

The defense to an auditor: "This matrix has five severity levels because our device produces five clinically distinguishable harm outcomes mapped to documented clinical pathways. Three levels would collapse distinct clinical consequences into the same bucket. Five probability levels match the variability we observe in software failure modes and usability failure modes. Comparable state-of-the-art devices in the same classification use 5x5 or equivalent granularity."

Tibor's field observation: the 3x3-where-5x5-was-needed failure shows up in audit as "the risk file cannot distinguish between risks the clinical context distinguishes". It is a credibility failure that rolls forward into every subsequent audit question.

## The Subtract to Ship playbook

Felix's coaching pattern for choosing and defending a matrix runs in six steps.

**Step 1. Start from the clinical consequences, not from the matrix.** List every distinct clinical outcome the device can cause a patient. If the list has three entries, a 3x3 severity scale may be enough. If it has five or more, the severity scale needs to carry that granularity. The list is the input to the matrix, not an output of it.

**Step 2. Anchor probability in the device context.** Software failure rates differ from mechanical failure rates. Implantable failure rates differ from handheld failure rates. The probability scale must be calibrated to the failure modes the device actually produces. Templates that carry forward probability ranges from unrelated device categories are a red flag.

**Step 3. Choose the matrix size from the list, not from a tool default.** Tibor's heuristic: if the clinical consequence list has three clean clusters and the probability context has three clean clusters, 3x3 is legitimate. If either list has five clean clusters, 5x5 is legitimate. Anything in between (4x4, 4x5, 5x3) is legitimate if the asymmetry reflects real asymmetry in the hazard landscape. The matrix does not have to be square.

**Step 4. Draw acceptance regions with benefit-risk reasoning.** Where green, yellow and red regions fall is the second half of the design. The justification must cite the device's benefit under its intended purpose, the state of the art for comparable devices, and the MDR Annex I §8 constraint. Acceptance regions that are just "whatever the tool came with" are a finding waiting to happen.

**Step 5. Write the rationale into the risk management plan.** One paragraph explaining why this matrix shape, this scale definition, and these acceptance regions were chosen for this device. The paragraph is short and load-bearing. Without it, the matrix is undefendable in audit.

**Step 6. Re-examine the matrix at post-market milestones.** Post-market data can reveal that the original probability scale was miscalibrated, or that a clinical consequence the team did not anticipate deserves its own severity level. MDR Annex I §3 requires re-evaluation as information comes in. The matrix is allowed to change with documented rationale. What is not allowed is silent drift.

The acceptability criteria applied to the matrix live in the risk management plan, covered in depth in [risk acceptability criteria for startups](/blog/risk-acceptability-criteria-startup). The matrix and the criteria are two halves of the same design.

## Reality Check

1. Can you list the distinct clinical consequences your device can cause, before looking at your matrix? Does the severity scale match that list?
2. Is your probability scale calibrated to the failure mode data of your device category, or did it come from a template unrelated to your device?
3. If an auditor asked "why a 3x3 matrix and not 5x5" (or the reverse), could you answer without referring to the template your QMS tool provided?
4. Do your acceptance regions carry a documented benefit-risk rationale under MDR Annex I §8?
5. Is the matrix rationale written into your risk management plan, or does the plan only show the matrix without explanation?
6. Does your process allow the matrix to evolve based on post-market data, with a documentation path for changes?
7. For a device with connected software, are cybersecurity failure modes visible in the matrix at the right severity level, or are they collapsed into a single cell?
8. If your acceptance region has any cells on the boundary between acceptable and unacceptable, are those boundary cells handled by explicit benefit-risk reasoning rather than by matrix mechanics alone?

## Frequently Asked Questions

**Is there an MDR-approved matrix shape we can copy?**
No. Neither MDR nor EN ISO 14971:2019+A11:2021 specifies a matrix shape. Annex C of the standard is informative. The manufacturer owns the choice and must justify it.

**Can we use a risk score (severity times probability) instead of a matrix?**
A numeric score can accompany a matrix, but on its own it is harder to defend because it hides clinical reasoning inside arithmetic. Tibor's preference in audit is to see both: the matrix for visual reasoning and the score for sorting and prioritisation.

**Should the matrix have more severity levels than probability levels, or vice versa?**
It can, and sometimes it should. A device with narrow severity outcomes but wide probability variation might use a 3x5 matrix. A device with broad severity outcomes but narrow probability variation might use a 5x3 matrix. Asymmetry is legitimate when it reflects real asymmetry in the hazard landscape.

**What about the colour coding, green/yellow/red?**
Colours are a visualisation of the acceptance regions. They carry no regulatory weight on their own. What matters is the acceptance region itself and the reasoning behind it, not the colour.

**Can we change the matrix once the risk file is live?**
Yes, with documentation. A matrix change is a change to the risk management plan, which is a controlled document. The rationale must be recorded and previously evaluated risks may need re-evaluation against the new matrix.

**How does the matrix interact with the reduction obligation in MDR Annex I §4?**
The matrix shows where each risk sits. The reduction obligation says reduction continues as far as possible regardless of which cell the risk is in. The matrix does not decide when to stop reducing. It supports the evaluation step in MDR Annex I §3, which feeds the control step in §4.

## Related reading
- [Risk acceptability criteria for your startup's device](/blog/risk-acceptability-criteria-startup) – the criteria that sit inside the matrix and the plan that holds them.
- [Risk evaluation under MDR](/blog/risk-evaluation-acceptable-unacceptable-mdr) – why the matrix cannot be used as the stopping rule for reduction.
- [The ISO 14971 Annex Z trap](/blog/iso-14971-annex-z-trap) – the harmonisation context for any matrix design decision.
- [MDR Annex I and the GSPRs](/blog/mdr-annex-i-gspr) – the regulatory requirements the matrix is ultimately serving.

## Sources
1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I, Chapter I §3, §4, §5, §8.
2. EN ISO 14971:2019+A11:2021, Medical devices – Application of risk management to medical devices, clauses 5.5 and 7.
3. EN ISO 14971:2019+A11:2021, Annex C (informative) on techniques to support risk analysis, and Annex Z mapping to Regulation (EU) 2017/745.

---

*This post is part of the [Risk Management Under MDR](https://zechmeister-solutions.com/en/blog/category/risk-management) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*