Your Cybersecurity Program Is Only as Strong as Its QMS Integration
Most medical device teams have a cybersecurity program. What they often don’t have is a cybersecurity program that actually talks to their quality system.
Threat models sit in a separate folder. Vulnerability monitoring runs through IT. Software patches get pushed without touching change control. Individually, each of those activities might be sound. Together, they create a system that looks integrated on paper but falls apart the moment an auditor starts tracing.
The timing matters right now. The FDA’s Quality Management System Regulation (QMSR) became effective February 2, 2026, formally replacing the old Quality System Regulation (QSR) and incorporating ISO 13485:2016 by reference. Two days later, FDA reissued its cybersecurity guidance to align with the new framework. The message is explicit: cybersecurity is no longer a technical add-on. Under QMSR – and bolstered by the statutory requirements of Section 525B of the FD&C Act – it must be embedded directly into your quality system obligations.
Here is what genuine integration looks like across the ISO 13485:2016 development lifecycle, and where most teams still need to close gaps.
What Changed Under QMSR, and Why It Matters for Cybersecurity
Under the legacy QSR (21 CFR Part 820), terms like Design History File, Device Master Record, and Device History Record had specific, well-understood meanings. Those terms are now formally retired. Under QMSR, FDA has adopted ISO 13485 terminology. Design documentation is now captured in a design and development file, and the broader framework of records that used to live across DHF, DMR, and DHR is now organized under the concept of the Medical Device File.
This is not just a vocabulary update. It reflects a structural shift toward a unified, risk-based quality system. The FDA now expects manufactures to utilize a Secure Product Development Framework (SPDF) where cybersecurity controls, design controls, and risk management operate as a single, traceable system rather than parallel tracks.
FDA’s updated cybersecurity guidance reinforces this directly, pointing manufacturers to specific ISO 13485 clauses. Clause 7.3 governs design and development, including software validation. Clause 7.1 requires documented risk management processes across product realization. These are the same clauses your quality team works from. Cybersecurity risk management now lives inside those clauses, not beside them.
Where Cybersecurity Belongs in the Development Lifecycle
The most common gap isn’t a lack of cybersecurity activity. It’s that the activity isn’t connected to the right quality touchpoints. Here’s what integration looks like at each stage.
ISO 13485 Clause 7.3 requires traceability from user needs through verification and validation. For connected devices, cybersecurity controls belong in that same traceable chain. Threat models are not standalone documents; they are inputs to hazard identification. The mitigations that come out of threat modeling (authentication requirements, encryption standards, access controls, session timeouts) need to appear as design inputs and design outputs, with verification evidence that ties back to them in the design and development file.
If a cybersecurity control can’t be traced through the design and development file the same way a mechanical or electrical specification can, the design control process is incomplete.
Threat modeling is not a substitute for ISO 14971:2019 risk management. It’s an input to it. Cyber hazards need to go through the full structured process: identification, severity assessment, and probability assessment – though in cybersecurity, exploitability replaces traditional probabilistic likelihood. From there, it requires risk control selection, verification of effectiveness, and residual risk evaluation. That logic has to appear in the risk file (often guided by AAMI TIR57/SW96), not only in a standalone threat model document.
Teams that maintain separate cybersecurity risk registers alongside their ISO 14971 risk files are creating exactly the kind of fragmentation that draws questions during inspections.
Modern connected devices rely on third-party software libraries, cloud platforms, firmware vendors, and contract manufacturers. ISO 13485 Clause 7.4 requires documented supplier evaluation and monitoring. For software-dependent devices, that evaluation needs to include:
• Assessment of the supplier’s secure development lifecycle practices
• Review of their vulnerability management and patch release processes
• Generation and continuous maintenance of a Software Bill of Materials (SBOM) to track upstream dependencies, a strict requirement under Section 524B.
• Contractual flow-down of cybersecurity requirements
• Clear allocation of responsibility for incident response and patching
FDA’s updated cybersecurity guidance specifically addresses this. A vulnerability introduced through an unqualified third-party component is still your device’s vulnerability. The quality system needs to demonstrate that oversight was in place before and after market release.
This is consistently the sharpest gap for fast-moving teams. Security patches and configuration updates happen frequently, and the instinct is to move quickly. But ISO 13485 Clause 7.3.9 requires that design and development changes go through documented impact assessment, risk re-evaluation, and approval before implementation. There is no exception for security patches.
An emergency security patch that bypasses change control is a finding waiting to happen. The fix isn’t to slow patches down. It’s to build a change control process that can handle security changes efficiently without skipping the required steps. FDA’s February 2026 cybersecurity guidance introduced a useful taxonomy here, categorizing changes as those that “may impact” versus those “unlikely to impact” cybersecurity, which can inform how you tier your change control response for routine updates versus critical vulnerabilities.
Cybersecurity risk does not end at product release. CVE databases, vendor advisories, SBOM monitoring, and coordinated vulnerability disclosure programs are all sources of postmarket signal. Under QMSR, FDA expects those signals to feed back into complaint handling, postmarket surveillance, and CAPA when systemic issues are identified.
If vulnerability monitoring lives entirely in IT with no documented trigger into the quality system, that signal never completes the loop. FDA’s February 2026 cybersecurity guidance is explicit that postmarket cybersecurity activities are quality system responsibilities, not just engineering operations.
What Auditors Are Actually Looking For
FDA investigators and ISO 13485 auditors rarely open an inspection by asking for your cybersecurity documentation. What they do is trace.
They find a hazard in the risk file and follow it forward: to the design mitigation, to verification evidence in the design and development file, to postmarket surveillance records, to management review. If cybersecurity shows up at each of those points in a traceable, controlled way, integration is evident. If it only appears in standalone cybersecurity procedures that don’t connect to those anchors, questions follow.
Management review is a specific gap worth flagging. Under QMSR’s alignment with ISO 13485 Clause 5.6, leadership is expected to review quality system performance in a structured, documented way. FDA’s updated cybersecurity guidance reinforces that vulnerability trends, patch timelines, and open risk posture belong on the management review agenda alongside traditional quality metrics.
Working Through It
Integrating cybersecurity into your quality system under QMSR does not require rebuilding from scratch. It requires mapping what your team is already doing to the right ISO 13485 structural anchors and closing the seams where activities are happening but not connected.
If your team is navigating this, whether ahead of a 510(k) submission, an ISO 13485 surveillance audit, or an EU MDR Technical File review, we’d be glad to walk through it with you. We embed into teams doing exactly this kind of integration work and can help you move efficiently without disrupting your development momentum.