Your Risk File Is Not Your Risk Management Report (ISO 14971 Clause 9)

# Your Risk File Is Not Your Risk Management Report (ISO 14971 Clause 9)

The device is done. The design is locked, manufacturing is validated, the clinical team is standing by, and somebody files the regulatory submission on a Friday afternoon with a long exhale of relief. Three months later the response comes back. Not about the clinical data. Not about the manufacturing. One line: where is your risk management report? The team stares at it, because they were sure they'd already sent it. They sent the risk file. Those aren't the same document, and that mistake just cost them four months.

That's not a rare story. It plays out more than anyone in this industry likes to admit. The company assumed the risk file, the hazard analysis, the tables, the FMEA, all that work, was the report. It wasn't. The file is the work. The report is the judgment about the work, signed, and a regulator wants the judgment. And the gap is expensive out of all proportion to the fix, because a missing report doesn't get repaired with an afternoon of writing. When a regulator loses confidence in your risk documentation, they don't re-read one page. They re-open the whole file, because if the summary was missing, what else got skipped? So four months isn't the cost of writing a report. It's the cost of rebuilding trust in everything the report was supposed to stand behind. The document is cheap. The trust it signals is not.

This is Module 11 of The Operator's Guide to ISO 14971. I'm Dave Saunders. I've spent more than 30 years commercializing technology, almost 20 of them in medical devices and regulatory work, including several surgical robots. Across this series we've built the WearPump risk file from nothing: eleven hazardous situations, identified, estimated, evaluated, controlled, and closed. Module 9 resolved every individual residual; Module 10 judged the whole device acceptable against the therapy it replaces. Every piece of analysis is done. There's exactly one step left before this device goes anywhere near a market: the formal review, and the report that records it.

Clause 9: the review, then the report

Clause 9 has two halves. 9.1 is the review. 9.2 is the report.

The review, before you release the device, requires that a competent person or group confirms three specific things: that the risk management plan was actually carried out the way it was written; that the overall residual risk is acceptable by the criteria you set; and that appropriate methods are in place to collect and review information once the device is out in the world. That third one catches people, so hold onto it.

The review is a real activity, not a signature at the end. Someone competent, or a group, works back through the whole risk process and confirms it holds together. In a small company that's a cross-functional meeting with a checklist and minutes; in a large one it's a formal design review with an agenda and a scribe. Either way it produces a record of who looked, what they checked, and what they found. That record is your evidence the review actually happened and wasn't just assumed after the fact.

The third confirmation, the post-production information, trips teams up because it feels like it belongs to a different department. But field data, complaints, the whole surveillance system, those are risk management inputs, not just quality-system chores. Clause 9.1 requires you to confirm the machinery for gathering that data is already in place before you ship. Not planned. Not in draft. Operational, on the day you sign. We build that machinery in the final module, but the report has to point at it and say: it exists, it runs, here it is.

Then 9.2, the report. The standard uses the word shall: a risk management report shall be produced. It has to be traceable back to the plan, it has to contain a clear statement about whether the overall residual risk is acceptable, and it has to be signed. It's a permanent part of the risk management file for the life of the device.

The distinction whole submissions rise or fall on

The risk file is the evidence. The risk management report is the judgment about that evidence. You need both, and one doesn't stand in for the other.

The clinical side works the same way, which makes it a useful mirror. A clinical trial produces data, piles of it. The clinical evaluation report is the document that interprets that data and draws a conclusion about benefit and risk. Nobody hands a regulator the raw trial database and calls it the evaluation. Your risk file is the raw work. Your risk management report is the document that reads all of it and concludes, in plain language, this device is ready to release, and here's why. Different document, different job, both required, every time.

The seven required elements

The report has seven required elements, and a missing element is the most common finding there is. Walk each one and put it on the pump.

1. 1. Scope and device identification. The report states plainly what device it covers: the WearPump, its intended use, the patient population, the model, any variants in or out of scope. For the WearPump, that's the pump, the firmware, the companion app, the adhesive patch, the fill kit, and the cannula, and it explicitly excludes the insulin itself, which is a drug governed by a different framework. A reviewer should never have to guess what's covered.
2. 2. Traceability to the plan. The report names the risk management plan from Module 3 by document number and revision, and confirms the work was done the way the plan said. If you changed the plan mid-stream, you say so, and why.
3. 3. Confirmation the plan was executed. You state, formally, that every activity the plan required actually happened, and you list them, each with its output document cited by number and revision. You don't make a reviewer infer that the work is complete from the fact that some documents exist. You assert it, line by line, and back each line with a reference.
4. 4. The overall residual risk acceptance statement. The single most important line in the document. It states that the overall residual risk is acceptable by your defined criteria, and points at the evidence that makes it true. (More on this sentence below, because how you write it matters more than almost anything else in the document.)
5. 5. A reference to the benefit-risk evaluation. Any residual you accepted by weighing it against benefit, like the silenced-alarm situation, gets referenced here with its conclusion. You don't repeat the analysis; you point to it.
6. 6. Confirmation the post-production systems are in place. The surveillance plan, the complaint-handling procedure, the follow-up plan, all active and named by document number. Active is the word teams quietly fudge. It's not enough that a plan exists in a folder. The procedure is running, the plan has a named owner, the field-data review has a date on the calendar. A reviewer can ask to see the last complaint that went through the system, and the answer can't be "we haven't switched it on yet."
7. 7. A clear release recommendation. The report ends with a clear call: recommended for release, or not. No neutral, no maybe. If it's conditional, the conditions are spelled out with measurable completion criteria ("recommended for release once the final biocompatibility report closes"). A conditional recommendation is perfectly legitimate as long as the conditions are specific and tickable. What isn't legitimate is a soft maybe with no exit criteria, because that leaves everyone guessing whether the gate is open.

Element three, the completion confirmation, isn't prose, it's a table, and it's worth picturing because a reviewer reads it in about ten seconds. Four columns: the activity, whether the plan required it, whether it's complete, and the exact output document, by number and revision, that proves it. Row after row, every activity the plan named, every one marked done, every one pointing at its evidence. That table is often the first thing an investigator scans, because it tells them instantly whether this was a real process or a box-checking exercise dressed up after the fact.

Who signs, and what each one certifies

The standard doesn't name a job title. It says the review is done by a competent person or group, and your quality system defines what competent means. In practice, a mature risk management report is signed by a cross-functional panel, and the structure that holds up under scrutiny is four signatures with four different scopes:

• The risk management lead signs that the process was run the way the plan said, every required activity is complete, and the file is accurate and current.
• The systems engineering lead signs for technical accuracy: the hazard analysis and the residual estimates are sound engineering judgments.
• The clinical lead signs that the benefit-risk picture is a real clinical picture, the benefits are evidenced, and the balance genuinely favors the patient.
• The regulatory lead signs that the file is complete against the requirements of the markets you're entering.

When an investigator picks up your report in a pre-approval inspection, the signature block is very often the first thing they read. They want to know who made these judgments, and whether those people had the competence and authority to make them. A single signature from a junior engineer is a flag that gets pulled on. A cross-functional panel, with documented training records behind each name, is a quiet sign the organization takes the decision as seriously as it deserves.

Two more rules bite here. First, the date of the last required signature is the official date of the report, and it has to fall after every activity the report summarizes is complete, and before the device is released. Sign in January, run a design change in February, and your report now describes a device that no longer exists. You need a fresh review. Second, the report is a controlled document under version control. If the design changes after you sign, you don't quietly edit the old report. You open a new revision, re-run the review, and re-sign. A report that floats free of a revision number is one a reviewer has no reason to trust.

The one sentence

Element four deserves more attention than any other line, because it's the sentence that tells the regulator, the auditor, and your own management that this device is safe enough to put in front of a patient. Here's the weak version and the strong version, side by side.

Weak: The overall residual risk of the WearPump appears to be acceptable based on our review of available information. Count the problems. "Appears to be" is a hedge; the risk either is acceptable or it isn't, and you're the one supposed to know. "Available information" tells a reviewer nothing: not what was reviewed, not whether it was complete, not which criteria you applied. That sentence wouldn't survive fifteen minutes with an FDA reviewer or fifteen seconds with a notified body assessor, because it's a shrug wearing a lab coat.

Strong: The overall residual risk of the WearPump, model WP-100, is acceptable as defined by the risk acceptability criteria in the risk management plan, based on the evidence in the hazard analysis, the risk control records, the residual risk evaluation, and the benefit-risk analysis, each cited by document and revision. Every one of the eleven hazardous situations has been addressed. One, the silenced-alarm situation, was accepted through a documented benefit-risk argument. No residual exceeds the acceptable threshold without that documented justification. The overall residual risk is acceptable.

That's a verdict a regulator can trace, line by line, back to a real document. And watch what a reviewer does with it: they don't nod, they take it apart. They pull the plan and confirm the criteria say what you claim. They pull each cited document and confirm the revision matches. They count your hazards and check every one is accounted for. A strong statement invites that, because every claim is checkable and every check comes back clean. A weak statement can't survive it, because there's nothing underneath the words to pull on. Write your acceptance statement to the strong bar, then read it back and cut every hedge until it's a sentence you'd defend out loud in a room full of people who disagree with you.

Two different audits

That report gets read by two very different reviewers, and understanding the difference lets you write one document that satisfies both.

An FDA reviewer is checking, first, that the required content is present and the conclusions are supported. Does the report exist as its own document, not buried as "see attached"? Does it trace to the plan? Is the acceptance statement clear? And then, for a device like the WearPump, two things they lean on hard: software, and human factors. The pump runs firmware that controls insulin delivery and an app that drives the interface, both governed by the software standard, and the report has to show those software risks were analyzed and controlled, not treated as a footnote. Under that standard you classify each piece of software by how badly it can hurt someone if it fails, and the firmware that commands a dose is the most serious class there is. Human factors is the other one: the pump can be engineered perfectly and still hurt someone if a tired, frightened person misreads a screen at two in the morning and confirms the wrong dose. The regulator ties the use-error study directly to the risk file, and your report has to show that connection.

A European notified body is doing something different: they assess the process, not just the outcome. FDA largely asks, is the content here and supported. A notified body assessor asks, do you have a working system, documented, followed, and wired into the rest of your quality system. The place they most often find a gap is the seam between your clinical evaluation and your risk management. The assessor reads your benefit-risk conclusion, the one that says the pump prevents more severe lows than injections do, and asks the obvious question: where does that clinical claim come from? If the answer is a clinical evaluation report, the follow-up is instant: and where, in this risk management report, do you cite it? If the honest answer is nowhere, that's a nonconformity, because your two most important safety documents aren't speaking to each other. Wire them together on purpose, name the evaluation by its document number, and the loop is closed.

The pre-release walkthrough, and how it fails

Run the WearPump check the way the report will. Process confirmation first: the plan listed its required activities, and every one is named, its output cited, its status confirmed complete, hazard identification through overall residual risk, plus the discipline-specific pieces, the software analysis, the use-error analysis, the biocompatibility work on the silicone adhesive. Then the residual picture, stated honestly: eleven hazardous situations, most closed as individually acceptable, the motor driver and connectivity path carrying residuals that came down hard but aren't zero, and the silenced-alarm situation accepted on a benefit-risk basis. Not a wall of green. An honest account of what was reduced, what was accepted, and why. Then the post-production confirmation, all active and assigned and referenced by document number. And finally the recommendation: the WearPump is recommended for release, one clear call, signed by the four functions, dated after the last activity closed.

The report is one document in a technical file that also holds your design records, clinical evaluation, software documentation, and manufacturing information, and it's the thread that ties the safety story together and points out to all of it. A reviewer often starts right here, because a good report is a map of the whole file. Which is one reason to make it clear and honest: it's frequently the first impression your entire submission makes.

These are the patterns that generate deficiency letters:

1. 1. The post-production section is simply missing (the most common by far), because the team assumed the surveillance plan was a separate document that didn't need to appear here.
2. 2. The acceptance statement is vague or hedged ("appears acceptable"), which reads as uncertainty about whether the device is safe.
3. 3. Software risk isn't integrated, treated as a footnote to the hardware.
4. 4. The human factors results are never referenced.
5. 5. The report is dated before the last activity was truly complete.
6. 6. The signature scope is undefined, so nobody can tell what each signer was certifying.

If you fix only two things before you file, fix the first two: the missing post-production confirmation, because it's so common that finding it tells a reviewer the team stopped paying attention at the finish line, and the hedged acceptance statement, because "appears acceptable" isn't a conclusion, it's an anxiety. And here's the encouraging part: every one of these is a document problem, not a device problem. None require you to change a single thing about the pump. They're cheap to fix before you file, and brutally expensive to fix after a deficiency letter, when the clock is running and a reviewer is already skeptical.

The recap

Clause 9 is two halves: the review (confirm the plan was executed, the overall residual risk is acceptable, and the post-production machinery is live) and the report (a shall document, traceable to the plan, with a clear acceptance statement, signed). The file is the evidence; the report is the judgment about it. Build the report from its seven elements, write the acceptance statement so every claim is checkable, get four functions to sign with defined scopes and a date that follows the last activity, and satisfy both the FDA content read and the notified body process read by wiring the clinical evaluation and the risk file together. Avoid the six failure patterns, especially the missing post-production section and the hedged sentence.

And there's a longer reason to get this right, past your submission: the report outlives the team that wrote it. Years from now, if something goes wrong with this device in the field, an investigator or a lawyer opens this exact document and reads it cold, with nobody from the original project in the room to explain it. What they find is either a clear, dated, signed judgment that shows a serious organization made a careful call with the evidence it had, or a vague paragraph that looks like nobody was quite willing to own the decision. You're writing for that reader too.

So here's the question to sit with. Think about the last risk management report you produced, reviewed, or inherited. Could you point an investigator to a single sentence, not a paragraph, one sentence, that states without qualification that the overall residual risk of that device is acceptable? If you can, what makes it strong? If you can't, what's the first thing you'd change?

Module 12, the finale, builds the machinery this report kept pointing at: post-market surveillance. What you collect, how you watch it, and what happens the day the real world sends you a signal your risk file never saw.

---

If this way of closing out a device is useful to you, I write more about operating a business effectively in my newsletter, The Build, at davesaunders.net, and the rest of my work is at baserealitygroup.com. Subscribe so the final module in this series finds you when it lands.

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 →