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.
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.
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.
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.
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.