ISO 14971 and start-ups: how to get started on risk analysis without getting lost

News

14 May 2025

1. Introduction - An obligation, but above all a management tool

Developing a medical device is exciting. But it's also a regulated, supervised and structured adventure. And one of the first steps is risk analysis.

There's no escaping it: Regulation (EU) 2017/745 requires it right from Article 10. ISO 14971:2019 sets out the details. And any notified body will ask you for serious, documented risk management.

But where does a start-up begin?

How can you avoid drowning in matrices, severity scales, failure analyses... even before you have a working prototype?

This guide offers a pragmatic entry into the world of ISO 14971, with case studies, common mistakes to avoid, and tools to get you started without getting lost.

2. ISO 14971 in brief: what a start-up really needs to understand

ISO 14971:2019 is THE standard for medical device risk management.

It doesn't demand the impossible.

It requires a clear, documented rationale for identifying, assessing, controlling and monitoring the risks associated with your device.

It covers

Development and design (including preclinical risk analysis) → § 4.4, § 5, § 6 and § 7
Documentary management of these analyses → § 4.5 and § 9
Traceability between risks, control measures and verifications → § 4.5, § 7.2, § 7.3
Post-market monitoring (feedback, incidents, updates) → § 10.1 to § 10.4

Pasted Graphic.png

3. ISO/TR 24971: the ally of start-ups that want to do well without drowning

Little-known and often overlooked, ISO/TR 24971 is nevertheless a goldmine.

It is a technical guide published in parallel with ISO 14971. It is not mandatory, but it has been written by the same experts... to help manufacturers implement the standard in concrete terms.

Why it's invaluable for a start-up:

It explains the subtleties of ISO 14971 with concrete examples,
It guides you in your choice of methods: FMEA? Fault tree analysis? HAZOP? ReRA?
It helps you deal with complex aspects: software, misuse, human risks, uncertainties, etc

What you'll find :

Clarified definitions (difference between "danger", "hazardous situation", "damage", etc.),
Practical recommendations for assessing probability in the absence of field data,
Tools for start-ups without full-time AR/QA or in-house clinical departments.

24971's most useful chapters for start-ups :

Chapter 4: Basic concepts
Chapter 5: Risk analysis in different contexts
Chapter 7: Software
Chapter 8: Foreseeable uses
Chapter 10: Evaluation of post-market data

4. Three common start-up mistakes (and how to avoid them)

1.Waiting until the end of development to start analysis

Too late. At this stage, any change becomes costly.
Risk must be part of the design from the very first idea.

2.Doing an FMEA to "tick the box

An FMEA without global thinking is not compliant.
It's just one tool among many, not a complete risk analysis.

3.Forget the risks associated with actual use

Many incidents stem from foreseeable misuse.
We need to analyze the environment, the user and his possible mistakes.

5. How to get started: a step-by-step method

➤ Step 1: Define destination and intended use

This is the foundation of everything. It defines the scope of your analysis.

➤ Step 2: List typical hazardous situations

Start with what can go wrong: loss of power, mechanical failure, poor positioning, etc.

➤ Step 3: Identify foreseeable misuses

Example: a sensor used on an unintended area of the body, or an unintuitive interface.

➤ Step 4: Build a compliant (but digestible) analysis grid

Even for a start-up, you need to integrate the key elements expected by ISO 14971 from the outset.

Your simplified but comprehensive table should include the following columns:

Hazardous situation (e.g. misinterpretation of an alert signal)
Risk (e.g.: Wrong clinical decision)
Cause (e.g.: Sound signal too discreet)
Severity (G) (e.g.: 3)
Frequency (F) (e.g. 2 )
Risk control (e.g.: Add visual signal + user test)
Efficacy verification (e.g. Perception test in real-life conditions)
Benefit/risk balance (e.g. Acceptable if alerts correctly perceived)

6. Case studies

Case 1 - A cardiac monitoring wearable

Product: connected armband measuring heart rate.
Problem identified: if the cuff is incorrectly positioned, the data becomes false.
Action: integration of a position sensor + alert in the app.

Result: risk analysis enabled us to add a simple control before locking in the design.

Case 2 - Diagnostic support application

Product: mobile app for dermatological diagnosis.
Identified risk: misinterpretation by an untrained user.
Action: addition of a warning and an integrated learning module.

Result: reduction of risk through controlled use, without additional hardware costs.

7. Mini-FAQ

Can risk analysis be outsourced?

Yes, but you have to remain a player: you're the only one who knows how your product is really used. And you, as the manufacturer, retain responsibility.

Is ISO 14971 mandatory for Class I devices?

The MDR imposes it indirectly via Annex I. So yes, in practice, even if the requirements are proportionate.

Can ChatGPT be used to generate an initial frame?

Why not, to save time on form. But (!) business thinking must remain human.

Which methods should I choose: FMEA, HAZOP, ReRA?

That depends on your technology. The 24971 helps you choose (see chapter 5).

Should the analysis be reviewed at each iteration?

Yes, it's a living process. Any major change requires an update.

8. Better imperfect than too late

Risk analysis should not be seen as a regulatory chore, but as a strategic tool.

Starting early, with simple, appropriate tools, enables you to:

Better manage development,
Avoid costly mistakes,
Lay a solid foundation for future CE marking.

At CSDmed, we support start-ups from the very beginning of their development, so as to lay the right foundations without overwhelming them with standards.

Are you developing a DM and don't know where to start? Then write to us.