Preparing for Medical Device Cybersecurity Audits
Post Summary
Medical device cybersecurity audits are now essential due to increasing risks from connected devices like infusion pumps and cardiac monitors. These audits ensure security is integrated into every stage of a device's lifecycle, from design to post-market monitoring. Regulatory updates, such as the FDA's Quality Management System Regulation (QMSR) effective February 2026, mandate strict compliance with standards like ISO 13485:2016, ISO 14971, and others.
Key Takeaways:
- Cybersecurity Documentation: Centralize and align with ISO 13485 clauses. Essential documents include risk management files, SBOMs, test reports, and incident response records.
- Risk Management: Use exploitability-based frameworks (e.g., CVSS) and tools like threat modeling to address device-specific risks.
- Audit Readiness: Establish governance, run mock audits, and organize evidence around the FDA's 11 eSTAR cybersecurity categories.
- Continuous Monitoring: Regularly update SBOMs, track vulnerabilities, and maintain a coordinated disclosure policy.
Bottom Line: Treat cybersecurity as a core safety system, not just documentation. Proactive preparation and lifecycle integration can prevent delays in market approval.
Medical Device Cybersecurity Audit Readiness: 4-Step Framework
The New FDA Inspection Reality: The Shift from QSIT to QMSR & Section 524B Cybersecurity Audits
sbb-itb-535baee
Step 1: Build and Organize Your Cybersecurity Documentation
Cybersecurity documentation is the backbone of a successful audit. Even the most secure device from a technical standpoint can stumble during regulatory reviews without proper documentation. Starting in February 2026, the FDA's Quality Management System Regulation (QMSR) mandates that cybersecurity documentation must be created through controlled processes aligned with ISO 13485:2016. This means that security records need to be part of your Quality Management System (QMS) rather than scattered across random folders or systems [3].
Setting Up a Centralized Documentation Repository
A well-organized repository should be built around your Secure Product Development Framework (SPDF). This framework ensures that every security artifact ties directly to a specific phase of your device's lifecycle, from the initial design stages to ongoing post-market monitoring. By mapping each cybersecurity activity to its corresponding ISO 13485 clause, you make it easier for auditors to track and verify your compliance.
| SPDF Phase | ISO 13485 Link | Key Artifact |
|---|---|---|
| Security Planning | Design Planning (7.3.2) | Security Risk Management Plan |
| Threat Modeling | Design Inputs (7.3.3) | Threat Model Report |
| Secure Design | Design Development (7.3.4) | Security Architecture Views |
| Security Testing | Design Verification (7.3.6) | Penetration/Fuzz Test Reports |
| Vulnerability Response | Corrective Action (8.5.2) | Incident Response Records |
For organizations involved in clinical trials, ensuring research data and PHI compliance is an essential part of the broader risk management strategy.
For premarket submissions, align your repository with the FDA’s eSTAR system guidelines. This system requires precise responses and attachments across 11 specific cybersecurity deliverable categories. Missing any of these can lead to a technical screening hold, delaying the review process [7].
By structuring your documentation this way, you not only meet regulatory expectations but also streamline the process of preparing the core materials auditors will examine.
Key Documents Auditors Expect to See
Once your centralized repository is set up, the next step is to ensure you have the key documents that auditors will scrutinize. Auditors aren’t just looking for the presence of documents - they’re checking that they’re complete, up-to-date, and interconnected. For Software as a Medical Device (SaMD), missing or incomplete security documentation is one of the top five reasons for major non-conformities, according to Notified Bodies [5].
Here are five key document categories to prioritize:
- Risk Management Files: Includes threat models and security risk assessments.
- Design and Architecture Records: Features items like data flow diagrams and trust boundary maps.
- Supply Chain Documentation: Maintains an active and controlled Software Bill of Materials (SBOM).
- Testing Records: Covers penetration test reports, fuzz testing results, and static/dynamic code analyses.
- Post-Market Records: Includes a Coordinated Vulnerability Disclosure (CVD) plan, patch management processes, and an incident response plan.
The SBOM, in particular, must be treated as a living document within your QMS, updated with every change to your software [3].
Maintaining Traceability Across Documentation
Traceability is key. Use standardized methodologies like STRIDE or Attack Trees to connect threat models with security test results. This ensures that every cybersecurity step aligns with the FDA’s eSTAR control categories [3]. Your documentation should clearly trace back to the eight control categories evaluated under the eSTAR system: Authentication, Authorization, Cryptography, Integrity, Confidentiality, Event Detection/Logging, Resiliency/Recovery, and Update Controls [7].
"In 2026, medical device cybersecurity submissions rarely fail because security controls are missing. They fail because cybersecurity is treated as documentation, not as a safety system." - Wayne Stewart, Vice President, Global – IoT & AI, Intertek [1]
Step 2: Put Effective Risk Management Practices in Place
Strong risk management is the backbone of cybersecurity - it goes far beyond just having proper documentation. It works hand-in-hand with the detailed records you’ve already set up. Just like documentation, risk management is an ongoing process and essential for staying ready for audits. With cybersecurity becoming a formal part of the Quality Management System Regulation (QMSR) by February 2026, managing risks in medical devices is no longer optional. It’s now a core element of your Quality Management System.
Building a Risk Management Framework
Cybersecurity risk management isn’t the same as safety risk management. For safety, ISO 14971 relies on assessing risks based on the likelihood of failures, often using historical data and models. But cybersecurity is a different beast. As the FDA points out:
"Cybersecurity risks are difficult to predict, meaning that it is not possible to assess and quantify the likelihood of an incident occurring based on historical data or modeling." - FDA Final Guidance [4]
This means you need a security framework that uses exploitability-based scoring, like CVSS metrics, instead of traditional probability-based methods. Standards such as AAMI TIR57 and AAMI SW96 provide guidelines for creating a cybersecurity-specific risk framework. While this framework complements your ISO 14971 safety process, it remains distinct and tailored to security challenges.
The NIST Cybersecurity Framework is another valuable tool, organizing activities across five key functions: Identify, Protect, Detect, Respond, and Recover. Structuring your risk management around these functions ensures comprehensive coverage throughout your device’s lifecycle. This approach helps you build a solid foundation for conducting device-specific risk assessments.
Conducting Device-Specific Risk Assessments
Auditors won’t be satisfied with generic risk assessments. They expect evaluations that address the unique risks tied to your device - its connectivity, deployment environment, and the potential impact on patients.
Start by performing detailed threat modeling with a recognized methodology like STRIDE, PASTA, or Attack Trees. These methods help you break down your system, mapping out data flows, trust boundaries, and external interfaces. This ensures you thoroughly examine every potential attack surface. For networked devices, this step is especially critical, as a single breach could impact multiple patients simultaneously. Your assessment must specifically consider these multi-patient harm scenarios.
Another often overlooked step is analyzing unresolved software anomalies (e.g., known bugs or defects) for their cybersecurity implications - not just their functional impact. Additionally, your Software Bill of Materials (SBOM) should be tightly linked to your threat model. This connection allows you to track vulnerabilities in third-party or open-source components in context, rather than treating them as separate issues. Automated tools can simplify this process, making risk assessments and documentation more efficient.
Using Tools to Support Risk Management
Managing risks across a device’s lifecycle creates a mountain of documentation and assessments. The right tools can help you stay organized and prepared for audits.
On the technical side, integrate automated tools like static code analysis, fuzz testing, and Software Composition Analysis (SCA) into your development workflow. Continuous monitoring tools, such as feeds from the National Vulnerability Database (NVD) and the CISA Known Exploited Vulnerabilities (KEV) Catalog, keep you updated on emerging threats to third-party components.
For healthcare organizations juggling risks across multiple devices and vendors, platforms like Censinet RiskOps™ can centralize and streamline risk assessments. This platform organizes evidence and documentation, making it easier to stay audit-ready. With AI-powered features, it can speed up the assessment process while ensuring human oversight remains a critical part of decision-making.
Step 3: Get Ready for the Audit Process
Now that your documentation is in order and your risk management practices are solid, it's time to prepare your team for the audit itself. This step ensures your organization can handle the scrutiny of an audit by creating a governance structure, testing your readiness, and organizing evidence so auditors can easily navigate it. The goal here is to build on your groundwork and ensure you're fully prepared to face the audit process.
Establishing an Audit Governance Structure
Accountability is the foundation of governance. The FDA's eSTAR submission process requires manufacturers to assign responsibility for the Cybersecurity Management Plan [7]. Auditors expect to see clear ownership of this plan and related activities [7].
Start by appointing a dedicated cybersecurity lead who coordinates efforts across teams like engineering, quality, clinical, and post-market support. Each team plays a specific role: engineers manage vulnerability fixes, quality teams oversee CAPA documentation, and support teams handle customer communication during incidents. Well-defined roles reduce the risk of missed responsibilities.
Align your cybersecurity activities with ISO 13485 subclauses. For instance, threat modeling should tie to design inputs (Subclause 7.3.3), and vulnerability responses should connect to corrective action (Subclause 8.5.2). This mapping not only helps auditors follow your processes but also demonstrates that cybersecurity is fully integrated into your Quality Management System.
"A siloed SPDF rarely delivers consistent, comprehensive impact." - Exponent [2]
Additionally, clarify shared responsibilities with healthcare delivery organizations (HDOs) and third-party providers. This includes defining software update protocols and incident escalation procedures. A documented 24/7 escalation path with a decision tree for containment isn't just a good idea - it's essential. A strong governance framework not only smooths the audit process but also strengthens your cybersecurity practices over the long term.
Running Mock Audits and Closing Gaps
Mock audits are a great way to uncover issues before the real audit begins. Structure these simulations to mimic an actual audit, reviewing both policies and technical controls.
Use the MDSAP process sequence, which spans seven integrated areas: Management, Registration, Improvement/CAPA, Design, Purchasing, Production, and Post-Market Surveillance [9]. A full MDSAP audit involves 175 tasks, including 90 tied to ISO 13485 and 85 tied to country-specific regulations [9]. Mock audits that cover this full scope are far more effective than simple checklist reviews.
Don't stop at documentation. Test your technical controls, such as running penetration tests, verifying encryption in all storage environments, and ensuring patch management SLAs are met [10]. Auditors increasingly demand independently verifiable records, like logs, test reports, and configuration evidence - not just written policies [10].
Pay special attention to your CAPA process. Weak root cause analysis is a common issue during audits [9]. During mock audits, make sure investigations use structured tools like the "5 Whys" or fishbone diagrams, and confirm that every issue is documented and resolved with verification.
"The distinction between having a security program and being able to prove you have a security program is where most HIPAA audit failures happen." - Sprocket Security [10]
Regular tabletop exercises can also help. Document any remediation actions from these exercises, and ensure staff training aligns with your training records and SOPs [8][9].
Putting Together Audit-Ready Documentation Packages
After identifying and addressing any gaps, the final step is to organize your audit-ready documentation.
Even the most thorough documentation can fall short if it's poorly organized. Auditors work under tight deadlines, and a messy submission can create unnecessary delays.
Structure your audit packages around the FDA's 11 eSTAR cybersecurity categories [7], which include the Risk Management Report, Threat Model, SBOM, and Cybersecurity Management Plan. Failing to provide complete and accurate responses across all 11 categories could result in a Technical Screening hold [7], which is an avoidable delay with proper preparation.
For organizations juggling multiple devices and vendors, tools like Censinet RiskOps™ can simplify the process. This platform centralizes evidence and documentation, making it easier to assemble audit packages quickly. Its AI-powered features help validate evidence and summarize risks, while human reviewers retain control over final decisions - an important balance when time is of the essence.
Keep your documentation package updated on a quarterly basis. This should include your latest risk analyses, SBOM, incident response test results, and any open corrective actions with status updates. When auditors arrive, you’ll be ready to hand them a well-organized package instead of a pile of unstructured files.
Step 4: Stay Audit-Ready on an Ongoing Basis
After establishing solid documentation and risk management practices in the earlier steps, the next challenge is maintaining that level of preparedness over time. Cybersecurity isn’t a “set it and forget it” task. Regulators, particularly the FDA, are cracking down on manufacturers who treat cybersecurity as a one-off effort instead of an ongoing commitment [3]. To stay ahead, you need to shift your focus from reactive measures to a proactive, continuous readiness approach that seamlessly integrates into your team’s workflows.
Embedding Cybersecurity into Device Lifecycle Management
Cybersecurity shouldn’t just be a box checked during the design phase - it needs to be woven into every stage of the device lifecycle. From procurement to decommissioning, every phase should include security measures that align with your Quality Management System (QMS).
Here’s a practical way to integrate cybersecurity into lifecycle management by mapping activities to ISO 13485:2016:
| Lifecycle Phase | ISO 13485 Mapping | Cybersecurity Activity |
|---|---|---|
| Design/Onboarding | Clause 7.3.3 (Design Inputs) | Threat modeling and defining security requirements |
| Maintenance | Clause 7.5.4 (Servicing) | Managing software updates and patching vulnerabilities |
| Monitoring | Clause 8.2.1 (Feedback) | Ongoing vulnerability monitoring and CVE triage |
| Improvement | Clause 8.5.2 (Corrective Action) | Incident response and fixing identified vulnerabilities |
Procurement is also a critical component of your cybersecurity strategy. Use Software Bill of Materials (SBOMs) to evaluate third-party risks during vendor onboarding, ensuring you identify potential issues early [6][4]. Additionally, validate your update mechanisms to include features like digital signature verification, integrity checks, and rollback options for failed updates in clinical environments [4].
The FDA’s transition to the Quality Management System Regulation (QMSR), effective February 2, 2026, requires cybersecurity documentation to be generated through controlled QMS processes rather than as standalone appendices [3]. This change makes lifecycle integration a regulatory requirement, not just an optional enhancement.
By embedding cybersecurity into all lifecycle phases and maintaining continuous monitoring, you can ensure these practices remain effective and aligned with regulatory expectations.
Continuous Monitoring and Risk Reassessment
Static risk assessments quickly lose relevance as new vulnerabilities emerge. Starting in February 2026, the FDA will require monthly CVE triage against a device’s SBOM [4]. This means you’ll need to stay on top of new threats and understand their impact on your devices.
The best monitoring programs integrate automated feeds, such as the National Vulnerability Database (NVD), CISA’s Known Exploited Vulnerabilities Catalog, and vendor advisories, and cross-reference them with your SBOM. When a new CVE is identified, you should know immediately if it affects any part of your device.
A key shift in evaluating vulnerabilities is moving from probability-based scoring to an exploitability-based approach. Instead of asking how likely an attack is, focus on how technically feasible it would be to exploit a vulnerability. Factors like the attack vector, complexity, and required privileges provide a clearer picture of actual risk [4].
It’s also essential to have a Coordinated Vulnerability Disclosure (CVD) policy in place. This policy should outline a designated contact, define the scope for reporting vulnerabilities, and set response timelines for researchers. This structured approach keeps your post-market vulnerability management process transparent and effective throughout the device’s operational life [4].
Using Technology to Support Continuous Readiness
Manually managing audit readiness for multiple devices isn’t practical. Technology can simplify the process, keeping documentation up-to-date and organized without overburdening your team.
Automating SBOM generation directly from your build pipeline ensures accuracy as software evolves. Using machine-readable formats like CycloneDX or SPDX prevents your SBOM from becoming outdated between audits [4]. Pair this with Vulnerability Exploitability eXchange (VEX) documents to clarify which known CVEs do not impact your specific device configurations, reducing unnecessary audit complications [4].
For organizations managing a large portfolio of devices, tools like Censinet RiskOps™ can centralize risk assessments, automate evidence validation, and maintain current documentation. Its AI-powered workflows help teams prioritize risks more efficiently while still allowing for human oversight in critical decisions - especially important when balancing tight audit timelines with patient safety.
"The rules of the game have changed. Manufacturers that treat cybersecurity as a documentation exercise rather than a design discipline are receiving multi-page deficiency letters that delay market authorization." - Naomi Schwartz, VP of Regulatory Strategy, Medcrypt [3]
Conclusion: Key Steps for Medical Device Audit Success
To successfully navigate a medical device cybersecurity audit, organizations need to focus on creating audit-ready evidence as part of their everyday processes. The overarching takeaway is this: cybersecurity must function as a safety system, not just a collection of documents. As Wayne Stewart, Vice President, Global – IoT & AI at Intertek, explains:
"Cybersecurity submissions rarely fail because security controls are missing. They fail because cybersecurity is treated as documentation, not as a safety system." [1]
The most common reason for submission failures isn't the absence of security controls. Instead, it's the result of treating cybersecurity as an afterthought - retroactively adding it to documentation after a design freeze. To avoid this, security should be embedded into every aspect of the development process, including design controls, risk management files, quality management systems (QMS), and post-market monitoring. Auditors can easily identify documentation gaps caused by retrofitting, which can delay clearance timelines by 8 to 12 weeks [4].
Key practices such as maintaining a centralized repository, performing thorough risk assessments, and implementing continuous monitoring are essential for audit success. Here's a summary of the critical evidence areas:
| Audit Readiness Component | Key Evidence Required |
|---|---|
| Risk Management | Integrated ISO 14971 files, threat models, and risk-based rationales |
| Software Integrity | Up-to-date SBOM, vulnerability tracking logs, and CVE monitoring |
| Security Testing | Penetration test reports, fuzz testing results, and static/dynamic analysis |
| Post-Market | Incident response plans, monitoring logs, and patch deployment records |
For organizations managing multiple devices or complex vendor relationships, handling these tasks manually can be overwhelming. Tools like Censinet RiskOps™ are designed to simplify this process for healthcare organizations. These platforms centralize risk assessments, automate evidence validation, and ensure documentation stays up-to-date. With AI-powered workflows, teams can focus on what matters most while maintaining human oversight - an essential factor when patient safety is at stake.
FAQs
What cybersecurity evidence do auditors ask for first?
Auditors often request cybersecurity documentation that shows a consistent, lifecycle-based approach to managing risks. This usually includes a cybersecurity risk assessment featuring threat modeling and implemented risk controls, along with related plans, procedures, and proof of ongoing vulnerability monitoring and corrective actions through post-market surveillance. They also look for submission-ready, traceable documents like cybersecurity management plans and security testing evidence. That said, the risk assessment and its documented controls are typically the foundation.
How do I connect ISO 14971 safety risk management to cybersecurity risk scoring?
To align ISO 14971 with cybersecurity, consider security events as hazardous situations that could potentially harm patients. These risks should be integrated into your current safety risk management file. Evaluate the clinical impact of security threats using the same severity scales applied to mechanical or electrical failures.
By merging CVSS exploitability metrics with ISO 14971’s harm analysis, you can establish a framework that’s ready for audits. Tools like Censinet RiskOps simplify and centralize this process, making it more efficient to manage and document these risks.
How often should we update our SBOM and triage new CVEs?
Continuous monitoring for vulnerabilities is a must throughout a device's lifecycle. The FDA requires that vulnerabilities be reviewed and prioritized within 72 hours of being disclosed. This involves evaluating risks based on factors like patient safety, the likelihood of exploitation, and the importance of the device. Although there’s no mandated timeline for updating SBOMs (Software Bill of Materials), keeping them accurate and machine-readable to reflect the latest software versions is critical. Tools like Censinet RiskOps™ simplify risk assessments and provide support for managing vulnerabilities, helping organizations stay compliant.
