Most startups create a risk file once, right before they “need it.”
Under EU MDR, that approach is a trap: risk management isn’t a document you finish. It’s a decision-making systemyou run throughout development, release, and post-market.
If you’re still getting oriented, start here:
EU MDR for Startups: Where Do I Start? (Practical Roadmap)
And if you’re mapping your overall plan, this pairs well with the roadmap approach:
Map Your MDR Pathway Like a Product Roadmap
Risk management in plain English
Risk management is how you answer three questions, continuously:
-
What can go wrong?
-
How bad would it be?
-
What are we doing to prevent it (and how do we prove it works)?
When it’s done well, it makes your product better and your regulatory path smoother.
The problem with “a one-time risk file”
A static file usually means:
-
Risks aren’t linked to requirements, so controls don’t get built
-
Tests don’t clearly verify the controls
-
Changes happen (features, suppliers, UI, cloud config) but risks don’t get updated
-
You can’t explain “why” you made key safety decisions
Auditors (and Notified Bodies) don’t just want a spreadsheet. They want to see a living system.
What “built into daily work” looks like
Here’s the startup-friendly version that works for both hardware and SaMD.
1) Make risk a standard part of every change
Rule of thumb:
-
If it changes the product, it can change the risk.
Practical workflow:
-
Every design change ticket includes a “risk impact” checkbox
-
If “yes,” you update the risk file and the traceability links
Definition of done:
-
No change is closed without a risk impact decision.
2) Link risks to requirements (so controls become real)
A risk control that isn’t implemented is just a promise.
Do this:
-
For each significant risk, define a control
-
Turn that control into a requirement (design input)
Definition of done:
-
You can trace: hazard → control → requirement.
3) Link requirements to verification (so evidence is automatic)
If you want risk management to stay alive, make it “pay rent” in your test plan.
Do this:
-
Every risk control requirement has a verification method
-
Verification results are stored as controlled records
Definition of done:
-
You can trace: requirement → test → result.
4) Run a lightweight “risk review” cadence
You don’t need a weekly committee meeting.
A good startup rhythm:
-
30 minutes monthly (or per release)
-
Same agenda every time:
-
What changed?
-
Any new hazards?
-
Any new complaints/feedback?
-
Any CAPAs?
-
Definition of done:
-
Risk is reviewed at a predictable cadence, with minutes/records.
5) Make post-market risk updates part of your PMS loop
Even pre-market, define how you’ll capture real-world signals.
Examples:
-
Support inbox trends
-
User feedback patterns
-
Known issues and bug reports
-
Distributor feedback
Definition of done:
-
Post-market inputs feed risk updates (not a separate universe).
SaMD/AI quick callout: risk changes faster in software
Software teams ship changes more often, which means risk can drift faster.
Make sure your system covers:
-
Release notes and versioning
-
Cybersecurity patches (and their risk impact)
-
Third-party libraries/dependencies
-
Cloud configuration changes
If you can’t reconstruct what was live when an issue happened, your risk system will struggle.
The “3-link chain” that keeps you audit-ready
If you only remember one thing, make it this chain:
-
Risk control → Requirement → Verification evidence
When that chain exists, your Tech Doc becomes easier, your QMS becomes real, and audits become less stressful.
Want me to sanity-check your risk workflow in 60 minutes?
If you want a lean risk management setup that fits how your team actually builds (and won’t collapse under audit), book a free 60-minute MDR Strategy Call.
Book here: https://calendly.com/niko-mangold-consultants/30min