Set the Line First: Why ISO 14971 Clause 4 Comes Before Any Risk Analysis

# Set the Line First: Why ISO 14971 Clause 4 Comes Before Any Risk Analysis

Around 80,000 people were walking around with a small piece of metal inside their heart that could snap without warning. It was a heart valve, and in most respects a good one. It kept tens of thousands of patients alive who otherwise would not have been. But one part of it, the strut that held the disc in place, could fracture. And when it fractured, the valve failed in an instant, and roughly 2 out of every 3 people it happened to did not survive.

This was the Björk-Shiley convexo-concave valve, and the fractures started showing up in the early 1980s. Not in a lab. In people. About 619 of those valves eventually broke that way. The company had data on the fracture risk. Changes they had made to the design, and to how fast they built the valve, had actually made that little strut weaker. And the valve stayed on the market, year after year, while the reports came in.

The point of the story is not that some engineers were careless. The point is about a decision. Somewhere inside that company, someone decided the fracture risk was acceptable, that the valve was good enough to keep selling. And the thing worth noticing is who made that call, and what they made it against. As far as anyone can tell, it was made commercially, and it was made against no acceptability criteria that had been written down in advance. There was no system designed to catch that decision and hold it honest. The risk got weighed, quietly, by the wrong people, against a bar that moved to wherever it needed to be.

The FDA withdrew approval of the convexo-concave valve in 1986. Pfizer, which owned it by then, eventually settled with patients and their families for somewhere around $215 million. But the lawsuits are not the lesson. People had already died. The lesson is everything that should have happened before the first valve was ever implanted, and didn't.

The failure was the system, not the math

Here is the thesis. The failure was not a missing calculation. It was a missing system. Risk management does not start the moment you open a spreadsheet and fill in your first hazard. It starts well before that, with the thing that decides who is allowed to call a risk acceptable, on what criteria, set down in advance, before anyone has seen a single result. That thing has a name in ISO 14971. It is Clause 4.

Most people do not start there. The day they are told to do risk management, they open a hazard analysis template and start typing: hazard, hazardous situation, harm, a number for probability, a number for severity. The rows fill up, and it feels like progress. But if you started there, you started in the middle. You skipped the part that was supposed to tell you what those numbers even mean, and what counts as a pass. Almost every explanation of ISO 14971 you will find does the same thing, mentioning the plan in a sentence and a half on the way to the analysis table, because the table is the part that looks like the work.

I'm Dave Saunders. I have spent more than 30 years in medical devices and regulatory affairs, a good share of it in audit rooms watching risk files get pulled apart. The single most reliable tell that a file is in trouble is a risk management plan whose date is later than the analysis it supposedly governed. It means the line was drawn after the shooting.

What Clause 4 actually requires

Clause 4 is the general requirements for risk management, and it is short. But it carries four things your whole risk file rests on. A risk management process, established, documented, and maintained. A risk management plan for the specific device. People who are competent to do the work, with records to prove it. And a risk management file that stays alive for the life of the product.

Two distinctions clear up most of the confusion. The first is process versus plan. The process is the general way your company does risk management across every product, your standard operating procedure, the rules of the road. The plan is the specific application of that process to one device. Process is the company. Plan is the product. You need both.

The second is the policy. Sitting above the process, Clause 4 asks top management to define and document a policy for establishing criteria for risk acceptability. Not the criteria themselves yet, but the policy for how the criteria get set. And notice who that lands on. Not the engineer with the spreadsheet. Top management. We will come back to why. If you ever feel like you are inventing all of this from a blank page, the companion technical report, ISO/TR 24971, exists to help with the how; the standard tells you what, the report shows you how.

The plan, element by element

The plan is where most of the real decisions of Clause 4 live, and the standard gives you a list of what it has to cover. Miss an element and that is a gap an auditor is trained to find.

• Scope. What device, and which parts of its life. Scope has to run the whole life cycle: manufacturing, shipping, storage, setup, maintenance, and disposal. Each phase can create its own hazards.
• Responsibilities. Who does what, and who signs off on what. This is the element that quietly prevents the heart valve story. If the person who approves a residual risk as acceptable is not the same person carrying the revenue target, you have built a small wall between the judgment and the pressure.
• Review. When risk management gets reviewed, by whom, at which milestones. Design freeze, design transfer, before launch, then a defined cadence after that.
• Verification. When you put a risk control in place, the plan commits, up front, to proving the control works and that it actually made it into the shipping product.
• Production and post-production. How you will collect and review information from the field after launch. This is the loop that keeps the file alive.

And the plan is not frozen once written. If the device changes, the plan changes, and that update gets recorded.

Set the line before you measure

There is one more thing the plan has to include, and it is the one everything turns on: the criteria for risk acceptability. The actual bar. And here is the rule I would tattoo on a new risk manager if they would let me. You set that bar before you measure. Before you estimate a single probability, before you know where your risks will land, you decide, with no skin in the result, what level of risk your company is willing to stand behind. Then you measure, and you live with what the measurement tells you.

The reason is human, not technical. Run the analysis first, then draw the line, and you will draw it in the wrong place. Not because you are dishonest, but because the line will drift to wherever makes your device pass. Your worst risk comes in a little high, and the bar quietly moves up to meet it. That is the backfill, and it is exactly what happened to that heart valve. The risk did not get evaluated against a fixed standard. The standard bent around the risk.

So what does a real criterion look like? Specific enough that two reasonable people, handed the same probability and severity, reach the same accept-or-reject decision. "Residual risks shall be acceptable as judged by the team" is a mirror; whatever the team judges becomes the definition of acceptable. "Any life-threatening harm with a probability above remote is unacceptable and must be reduced" is a line, and it does not care how inconvenient it is today.

Two more constraints shape the line. The first is state of the art, which does not mean the most advanced technology that exists; it means generally accepted good practice for your kind of device, now. If comparable pumps all have an occlusion alarm, you do not get to call a missing one acceptable because your math came out low. The second is ALARP, "as low as reasonably practicable," the most abused idea in the field. Real ALARP means you drove the risk down as far as was practical, documented what you tried, and can show why stopping there was reasonable. It is a verb you prove, not a label you claim. And none of this is only an ISO preference: the FDA expects a documented process, the EU Medical Device Regulation makes it law, and a notified body reviewing your file will look at the plan, and yes, at its dates.

The 5x5 matrix, built before the analysis

How do you write that line so a team can use it on dozens of risks? You build a matrix: probability on one axis, severity on the other, every cell colored to say acceptable, tolerable but watch it, or unacceptable. Here is WearPump's, our running example, a wearable insulin pump for Type 1 diabetes.

WearPump risk acceptability matrix Severity, five levels: Negligible (no clinical effect) · Minor (the patient self-corrects) · Serious (reversible, needs intervention) · Critical (permanent or life-threatening, survived) · Catastrophic (death). Each level gets a written definition, or the team will slot the same harm differently on different days. Probability, five levels: Improbable · Remote · Occasional · Probable · Frequent. For a new device with no field data, these are educated judgments at first. That is allowed; hiding the reasoning behind them is not. Three zones across the 25 cells: Green, broadly acceptable. Amber, tolerable only if driven as low as reasonably practicable and justified. Red, unacceptable, not shippable until reduced. For WearPump, anything that can kill is red unless it is improbable, and even then it lands in amber and gets scrutinized. Anything critical is at best amber until it is remote or rarer.

Walk one cell. WearPump delivering a sudden unintended dose of insulin is critical, because severe hypoglycemia can be life-threatening. Say the early probability estimate lands at remote. Critical and remote falls on the red-amber border, and the plan says that border is treated as unacceptable until proven otherwise. So before WearPump ships, that risk must be controlled down. The matrix made the decision, and nobody had to argue about it in the moment.

The point is the timing. We built that entire matrix, both scales, all three zones, every boundary, without estimating a single real WearPump risk. When the analysis comes, in a later module, we are not deciding what passes. We already decided. The matrix is a contract you signed with yourself before you could be tempted, and when the pressure comes, a launch date, a competitor, a board meeting, it is the one thing in the room that does not care about any of that.

The people, and why management owns the line

A plan and a matrix are only as good as the team applying them. Risk management sits across engineering, software, medicine, human factors, manufacturing, and regulatory, and no one person holds all of it, so the competence requirement is really a requirement to assemble a team that, between them, covers the device. You want them in the room at once, not in a relay, because the worst hazards hide in the handoffs: the software assumes the hardware will catch the over-pressure, the hardware team assumes the software will, and the patient took the device off and put it in a drawer.

Which answers the question I left open. Why does the standard hand acceptability to top management instead of the experts? Not because executives understand the device better; they do not. Setting the acceptable level of risk is not a technical question. It is a question of how much risk the company is willing to own, on behalf of patients, in exchange for the good the device does and the business it brings. That is a values-and-accountability decision, and it has to sit with the people who carry the legal and moral weight for the whole organization. The engineers estimate the risk. Management decides what the company will accept. Keeping those two jobs in different hands is the entire design, and it is precisely the separation the heart valve never had.

The file that outlives the meeting

The last of the four is the risk management file, and it is the most misunderstood object in the standard. People picture a thick binder assembled the week before submission. That picture is wrong, and it causes real problems. The file is the traceable record of everything the process produces, often a master index that points to the plan, the analysis, the verification records, the reviews, the clinical evaluation, and the post-market data. Pull any residual risk and you can walk the chain back to the hazard that started it. And it is alive: you maintain it every time the field teaches you something, a complaint that reveals a missed hazard, data showing a feared risk barely happens, a design change that introduces a new one. When an auditor shows up, the file is what they read. If a decision is not traceable in it, then as far as the audit is concerned, the decision was not made.

What WearPump has now

By the end of this, WearPump has the two artifacts Clause 4 exists to produce before any analysis is allowed to count. A risk management plan: scope across the full life cycle, responsibilities with sign-off held outside the commercial line, three review gates plus a quarterly cadence, verification attached to every control, and named post-market sources with named owners. And the 5x5 matrix it points to, dated and signed, sitting at the front of the file.

That sets up everything that follows. The next module begins risk analysis proper, with WearPump's intended use and safety characteristics, now that there is finally a system to hold it. The order matters. We built the courtroom before we tried the case.

So if you take one thing from this, take the order. Policy, from top management. Then the plan. Then the criteria and the matrix, set cold. And only then the analysis, measured against all of it. Risk management is not a math problem you solve at a table. It is a system of judgment you build before the table, so that when the hard calls come, they are made by the right people, against a bar set in advance, recorded where it cannot be quietly moved.

If this was useful, Module 4 is where the analysis begins. There is more on product strategy, roadmaps, and fractional CPO work at baserealitygroup.com, and the written version of this work goes out in a newsletter called The Build, at davesaunders.net.

Dave Saunders is the founder of Base Reality Group and a Fractional CPO for hard-tech founders. He was a founder and operator at Galen Robotics, where the surgical-robotics platform earned FDA De Novo authorization in 2023, and he managed a 35-patent portfolio licensed from Johns Hopkins. He wrote Founders Who Finish and publishes The Build. More about Dave →