Preparing for an EU MDR software security audit can be unclear at first, mainly because cybersecurity is not a single requirement. Instead, it appears across the software lifecycle, risk management, IT environment controls, and post-market processes. You are expected to show how security is built into your device from start to finish. By 2026, the compliance with the state-of-the-art anticipated by regulatory reviewers is specifically compliance with EN ISO 81001-5-1 and the EU AI Act of smart devices.
This growing focus is reflected in the European healthcare cybersecurity market, which was valued at USD 6,945.19 million in 2024, is projected to reach USD 8,168.11 million by 2025, and is expected to grow further to USD 15,331.3 million by 2030, with a CAGR of 15.03%.
Alongside this growth, Notified Bodies are examining how well your device can handle security risks, especially for software-driven and connected products where patient safety is directly involved.
Let’s see how to prepare step by step before your audit begins.
Key Takeaways
- You will not find cybersecurity sitting in one place under the EU MDR. It shows up across Annex I, so you need to connect the dots across different requirements
- Security needs to be part of how your software is built and maintained from the beginning, not something you try to fix at the end.
- What really matters during an audit is what you can prove. Clear records, traceability, and supporting documents
- Your security testing should tie back to real risks and defined requirements, so everything you test has a clear reason behind it
- Your responsibility does not stop after release. You need to keep track of security issues and respond to them once the device is in use
What Is an EU MDR Software Security Audit?
This audit is a structured review of how your device manages security across its lifecycle. It covers your cybersecurity controls, software development practices, risk management approach, and the quality of your technical documentation.
The scope extends beyond development. Auditors look at pre-market stages like design, development, and validation, along with post-market activities such as monitoring, updates, and incident handling. The focus is on how your device performs once it is in use, not just at the point of release.
EU MDR Cybersecurity Requirements You Must Meet
1. Secure Software Lifecycle and Risk Management
A key focus falls under Annex I 17.2, which covers how your software is developed and controlled. Your process should reflect current industry practices and show that security is considered from the beginning. This is where EN ISO 81001-5-1 comes into play to extend your traditional IEC 62304 Safety Lifecycle with dedicated security activities.
You need to address:
- Secure design principles during development
- Integration of cybersecurity into your risk management process
- Verification and validation activities to confirm controls are effective
Your documentation should clearly support this:
- Defined software lifecycle processes
- Well-structured security requirements
- Testing evidence linked back to those requirements
If you are preparing for an EU MDR compliance audit, cybersecurity gaps usually appear in how these elements connect. What auditors expect is simple in theory but difficult in practice. You should be able to show a clear flow from design to implementation to validation, with complete traceability.
2. Minimum IT Security and Operating Environment
Annex I 17.4 defines the conditions your device needs to operate safely from an IT and security perspective. This includes the hardware it depends on, the type of network it connects to, and the security configurations required during use.
You need to clearly define:
- Hardware requirements that support secure operation
- Network characteristics such as connectivity, access controls, and expected usage conditions
- IT security configurations required to maintain system integrity
Your device should also include protection against unauthorised access. It ensures that only approved users or systems can interact with it. All of this must be documented in a way that users can understand and apply. Instructions for use and configuration details should leave no chance for confusion.
3. Protection Against Unauthorised Access
Annex I 18.8 looks at how you control access in real use. If someone can access your device without permission and that affects safety or performance, it becomes a serious concern during review.
You are expected to put basic controls in place:
- Authentication to confirm the identity of the user
- Authorisation to define what actions each user can take
- Secure configurations to avoid unnecessary exposure
When auditors review this, they do not stop at what you have written. They look at how you have handled possible threat situations.
4. Security Information in Instructions for Use
Annex I 23.4 makes it clear that your Instructions for Use should guide users in operating the device securely, not just functionally. If security depends on certain conditions, those need to be explained up front.
Your IFU should include:
- Minimum IT requirements needed for safe operation
- Clear instructions on how to configure the system securely
You also need to define what is expected from users and operators. This includes how they manage access and handle basic security responsibilities during use. During the audit, reviewers will compare your IFU with your technical documentation. Both should tell the same story.
Explore our real-world case studies. See how a company successfully met EU MDR cybersecurity requirements with the right approach.
See How We Helped Businesses Stay Secure
How to Prepare for an EU MDR Software Security Audit
1. Define the Security Scope of Your Medical Device
Before you get into security testing or documentation, you need to be clear about what is actually part of your system. This step shapes how your MDR cybersecurity audit will be approached, since it defines what falls under review.
Start by listing every component involved:
- Embedded software within the device
- Companion mobile or web applications
- Backend or cloud systems
- APIs and external integrations
Then map how data moves between these components. Look at how patient data flows, how the device communicates, and where external systems come into play. This gives you a clearer view of where controls are needed.
Next, identify all possible entry points:
- Open ports
- Wireless connections
- Remote access paths
You should also define user roles and access levels. It should be clear who can access what and what actions they are allowed to perform. Include third-party software and dependencies in your scope. This is where you must generate a machine-readable software bill of materials (SBOM) using formats like CycloneDX.
2. Map MDR Requirements to Security Controls
Once your scope is clear, the next step is to connect MDR requirements with what you have actually implemented. This is a core part of any MDR cybersecurity audit, and it is where gaps usually become visible.
You should create a clear mapping structure:
- MDR clause
- Security control
- Implementation approach
- Supporting evidence
Each clause needs to link to something measurable. It should be possible to point to a control, show how it is implemented, and back it with proof. Broad or generic statements do not hold up during review. For example: Annex I 17.4 → network security configuration → documented requirements supported by validation or testing.
3. Implement Secure Software Development Lifecycle
You should break your software process into clear stages like design, development, testing, and maintenance. Then show how security fits into each one. During design, think through possible threats before anything is built.
While writing code, follow secure coding practices and keep track of third-party components with a clear plan for updates and fixes. Every change should be recorded through version control, with a proper trail of what changed and why. Your overall process should match IEC 62304 expectations, showing that your development approach is controlled and consistent.
4. Perform Security Risk Management
Once you have that view, assess how likely each situation is and how serious the impact could be. Based on that, decide what needs to be controlled, reduced, or accepted with justification. These decisions should be recorded in your ISO 14971 risk management file, with enough detail to explain the reasoning.
5. Conduct Security Testing and Validation
Build a V and V plan that covers methods like SAST, DAST, vulnerability scanning, and fuzz testing based on your system. Keep testing risk-based, so effort is focused on areas that can affect safety or performance. Maintain clear test records:
- What was tested and why
- Results and observations
- Link to defined requirements
Fix any issues found and retest to confirm closure. Your validation evidence should clearly connect requirements, tests, and outcomes.
6. Prepare Technical Documentation for Audit
Gather all required materials so your system can be understood without back and forth. Reviewers should be able to follow your setup, decisions, and controls directly from what you provide. Include:
- Architecture diagrams
- Threat models
- Risk management file
- Security requirements
- Traceability matrix
- V and V reports
- SBOM
Check that details match across files. Even small mismatches can raise concerns.
Add brief explanations for key security decisions so that reviewers understand the reasoning without asking for clarification. In many cases, issues arise not from missing controls but from unclear or disconnected documentation.
7. Establish Post-Market Cybersecurity Processes
Once the device is out with users, you start seeing things you could not have predicted earlier. A component you rely on might have a reported issue. A supplier might release a notice that affects your setup.
You need to keep checking for these and decide what needs action. When a fix is required, it should follow a clear process so nothing is missed. Any fixes or issues should be added to your risk file and post-market records so everything stays up to date.
8. Conduct an Internal Audit Before Notified Body Review
Before submission, review your work the way an auditor would. Start with a gap analysis against the MDR cybersecurity requirements to see what is covered and what is missing. Then check if your documentation is complete and consistent across all sections.
You should also walk through the audit flow step by step and check where things might not hold up. Focus on:
- Missing evidence
- Weak or unclear documentation
- Gaps between requirements and proof
The security of your software under audit assessment can be proven through a detailed pentesting report. The relevant personnel need to follow the EU MDR requirements to document all findings, fixes, and testing details.
Get a Free Sample Pentest Report
What Notified Bodies Look for During Security Audits
When your device goes through review, the focus is not just on what you have written, but how well everything connects. One of the first things checked is traceability. Reviewers expect to follow a clear path from requirement to risk, then to control, testing, and final evidence. If that chain breaks at any point, it raises questions.
They also examine how complete your documentation is, including what is required under Annex II and III. Missing sections or partial details can slow things down quickly.
Another area of focus is alignment. What you claim under MDR clauses should match what is actually implemented. If your documents say one thing and your system shows something else, it becomes difficult to justify.
Threat modelling and risk analysis should reflect real use, not just theoretical scenarios. Also, you should be able to show how vulnerabilities are handled and how your device is managed after release. Common red flags include:
- Missing SBOM
- Weak or unclear test evidence
- Mismatched or inconsistent documentation
- Limited or unclear security details in the IFU
EU MDR Software Security Audit Checklist for CE Certification
The EU MDR checklist helps you verify that your software complies with EU MDR cybersecurity requirements needed for CE certification. It includes essential requirements that start from secure software development and extend to post-market software monitoring.
| Section | Checklist Item |
| Annex I 17.2 |
|
| Annex I 17.4 |
|
| Annex I 23.4 |
|
| Post Market |
|
How Qualysec Helps with EU MDR Software Security Audits
When you are preparing for an audit, the real challenge is proving that your device is secure in a way that stands up to review. Qualysec supports you through medical device software security testing aligned with MDR expectations.
The testing covers your full system, including web applications, mobile apps, APIs, cloud environments, and connected devices. The approach combines manual and automated methods to uncover issues that matter in real use.
What you receive is built for audit readiness:
- Clear severity for each finding
- Reproducible steps
- Practical remediation guidance
Qualysec also supports you after fixes are applied. Retesting confirms that you resolved issues properly, and you receive direct input on how to close gaps effectively.
Conclusion
MDR cybersecurity depends on how your device is handled across its lifecycle. It is not just about adding controls, but about being able to show how those controls are built, tested, and maintained with clear evidence, often reviewed through an EU MDR software security audit.
Preparation has a direct impact on your audit outcome. When your documentation supports your implementation, and your validation backs both, the review becomes much easier to navigate. Most issues come from gaps between these areas, not from the absence of controls.
If your process already includes CE mark cybersecurity testing as part of validation, it becomes easier to present results that auditors can review without going back and forth. A well-prepared setup helps you move through certification without unnecessary delays.
If you want to go into your audit with stronger evidence and fewer gaps, Qualysec can help you get there with the right testing and support.
Speak directly with Qualysec’s certified professionals to identify vulnerabilities before attackers do.
FAQs
Q. What is an EU MDR software security audit?
It is basically a detailed review of how you handle security across your device. Reviewers look at how your software team builds it, how you manage risks, what you have documented, and how you deal with issues after release. You need to show proof, not just say things are in place.
Q. Is cybersecurity testing required for CE marking?
You do need to show that your device is secure, but MDR does not force one specific type of testing. What matters is that your approach makes sense for your device and backs clear results.
Q. What security tests are performed during MDR audits?
There is no fixed list. Most teams use a mix of methods like code reviews, scanning tools, and other checks, depending on how the device works.
Q. How do manufacturers prepare for a software security audit?
It usually starts with understanding what is in scope. Then you map requirements, organise your documents, and check if your testing actually supports your claims. Many teams run an internal review first to catch weak spots.
Q. Who performs cybersecurity audits for medical devices?
The official audit is done by a Notified Body. Before that, many manufacturers work with external security teams to test their systems and fix gaps early.
0 Comments