IEC 62304 Clause 7 in practice: why your risk file and your risk process aren't the same document

We've written about IEC 62304 clauses before, Clause 6 (maintenance, back in June) and Clause 8 (configuration management, in August). But what about Clause 7?

Clause 7 might be the most skipped clause in the whole standard. Not because it's obscure,  because most teams already have a document that sounds like it covers this. They have an ISO 14971 risk management file. Hazards, identified. Risks, assessed. Residual risk, accepted and signed off. Box checked.

Except Clause 7 isn't asking you to have a risk file. It's asking you to run a process, one that connects that risk file to your actual codebase, your actual SOUP components, and your actual test evidence. That process is where teams either build real traceability or quietly accumulate a gap that an auditor will eventually find.

Here's the practitioner's read on Clause 7. What it actually asks for, where teams get it wrong, and the patterns that hold up.

What Clause 7 actually requires

Strip out the standard's language and Clause 7 boils down to three linked questions you have to be able to answer for every hazard in your risk file, with evidence, not just an assertion.

Which software items could actually cause or contribute to this hazard? For every hazardous situation your ISO 14971 process has already identified, you have to trace it forward into your codebase: which modules, which components, which SOUP items could plausibly be a cause. This is the link most teams never build. The risk file lives in one tool. The codebase lives in another. Nobody owns the line between them.

What's the risk control measure, and how do we know it works? A mitigation that exists only as a design decision in someone's head, or a line in a review comment, isn't a risk control measure yet. It needs a defined implementation and a verification method — a specific test, with a specific expected result, that gets run and recorded. “We fixed it” is not evidence. A test log with a timestamp and a pass result is.

Did the fix introduce a new hazard? This is the step everyone forgets, and it's arguably the most important one. Every risk control measure is itself new software. New software can fail in new ways. Clause 7 explicitly expects you to check whether closing one gap opened another — including checking whether any SOUP component involved has known anomalies on a public list that could interact badly with your fix.

Three questions. All three need to be answerable with evidence, for every hazard, every time your software changes. That's the process.

Where teams get stuck

These are some of the common five failure patterns that show up again and again:

1. The single-file fallacy. The ISO 14971 file is treated as sufficient on its own. There's no tag, no field, no marker distinguishing which entries are software-caused. When an auditor asks “show me every risk where software is a contributing cause,” the answer is a scramble through the whole file by hand.

2. The shadow risk log. Instead of extending the existing risk file, someone builds a second “software risk register” to satisfy Clause 7 specifically. Now there are two documents that are supposed to agree with each other and frequently don't. Nobody trusts either one completely.

3. Review instead of verification. A risk control measure gets “verified” by a design review or a Slack thread where someone says it looks fine. No test ID, no recorded result, no objective evidence. It holds up until the first audit that asks to see it.

4. The SOUP blind spot. Nobody is checking published anomaly lists for the third-party and open-source components sitting inside the product. The assumption is that the vendor — or the open-source maintainer — is handling it. Often nobody is, and the first anyone hears about a known issue is when a customer or an auditor brings it up.

5. New-hazard blindness. The team confirms the original problem is fixed and stops there. Nobody explicitly asks whether the fix could have introduced a new failure mode. This is usually not negligence — it's just that the step isn't built into anyone's workflow, so it never happens by default.

Patterns that work

These are the patterns that consistently keep Clause 7 audit-ready without turning it into its own bureaucracy:

Tag, don't duplicate. Add a software-cause flag and a component/module reference directly to the existing ISO 14971 risk file. One file, addressable in slices. “Show me every software-caused risk” becomes a filter, not an investigation.

No closure without evidence. A risk control measure doesn't get marked complete without a linked test ID, a recorded result, a date, and a signer attached to the same ticket or record. Make the field mandatory in whatever tool your team already uses — the friction is the point.

Build the new-hazard check into the same workflow. Don't bolt on a separate “new hazard review” after the fact. Add it as a required section in the same code review or verification step that closes out any change tied to a risk control measure. One motion, not two.

Put SOUP anomaly checks on a calendar, not a hope. Establish a routine cadence — quarterly is common — for checking anomaly lists and vendor bulletins for every SOUP component in the risk file. Log the check even when nothing turns up. Absence of a known issue, documented on a specific date, is exactly the evidence an auditor wants to see.

Connect Clause 6 and Clause 7 on purpose. If you've read our piece on Clause 6, you already have a modification analysis step for every change. Make “does this affect an existing risk-classified pathway” a mandatory question inside that same analysis. The two processes should be talking to each other, not running in parallel and hoping they agree.

What this looks like in production

The teams that handle Clause 7 well didn't write a new procedure and bolt it onto an existing workflow. They looked at the risk file they already had, the ticketing system they already used, and the code review they already ran and added three things: a traceability tag, a mandatory evidence field, and a new-hazard question. Nothing exotic. Just three gaps closed in tools that already existed.

The teams that struggle usually have a technically compliant-looking risk file and a codebase that has quietly drifted away from it for a year. Nobody lied on the document. Nobody kept it current, either.

Clause 5 builds your traceability. Clause 7 is what proves it's still true after the software has changed a hundred times since submission.

If you're scoping a maintenance roadmap that includes real post-market changes, it's also worth asking whether some of that roadmap belongs inside a Predetermined Change Control Plan — more on that in next month's piece.

Building or supporting a medical device software team? Hattrick helps medtech companies design FDA-compliant software processes — from IEC 62304 risk management built in from day one, to retrofitting a process that will hold up to the next audit. Get in touch at [email protected].