In February 2026, FDA's Quality Management System Regulation (QMSR) replaced 21 CFR Part 820, the Quality System Regulation that governed medical device manufacturing for almost three decades.
The headlines were relatively quiet. That is partly because QMSR was designed to harmonize FDA requirements with ISO 13485:2016, a standard that many device companies were already working against. For manufacturers with mature ISO 13485 quality systems, the transition was easy.
For medical device software teams, the picture is more nuanced. QMSR's alignment with ISO 13485 has direct implications for design controls, risk management integration, and how software development processes connect to the quality system. If your team has been operating under the old QSR framework — or under no formal framework at all — there are specific things worth reviewing now.
What Actually Changed and What Stayed the Same
The core structure of device quality system requirements is largely intact. Design controls, risk management, document control, corrective and preventive action — these requirements exist under QMSR as they did under the QSR. The shift is in how they are framed and what the harmonization with ISO 13485 implies about implementation.
If your quality system was built against ISO 13485:2016 and your software development process was built against IEC 62304, QMSR does not require a significant rebuild. If your quality system was built against the old QSR without ISO 13485 alignment, or if your software development process was informal, the gap is larger.
The Software-Specific Implications Worth Your Attention
Risk management is now a quality system requirement, not just a development process requirement.
Under the old QSR, risk analysis appeared in design controls but was not explicitly threaded through the quality system. QMSR's harmonization with ISO 13485 brings risk management more centrally into the quality system framework. For software teams, this means the connection between your ISO 14971 risk management process and your design controls documentation needs to be explicit and visible, not two parallel processes that happen to reference each other at submission time.
Design and development controls are now more clearly tied to IEC 62304 expectations.
QMSR does not name IEC 62304 explicitly, but the ISO 13485 harmonization makes the alignment clearer. Software development plans, software requirements, verification and validation activities, and configuration management are all areas where FDA reviewers will be reading your submission against both the QMSR design controls requirements and IEC 62304 expectations simultaneously. If these were managed as separate compliance tracks, they should now be integrated.
Post-market surveillance requirements are more substantive.
QMSR strengthens post-market surveillance requirements in alignment with ISO 13485. For software teams, this has practical implications for how post-market monitoring is planned and documented at submission time. FDA increasingly expects to see a post-market surveillance plan that is active from the start of commercial distribution, not a placeholder document that will be developed later.
A Practical Review Checklist for Software Teams
If you are mid-development or approaching submission, here is what is worth reviewing against the QMSR framework:
- Risk management integration: Is your ISO 14971 risk management process visibly connected to your design controls documentation? Can a reviewer trace identified hazards to architectural decisions and requirement-level controls?
- Software development plan: Does your SDP reference both QMSR design controls requirements and IEC 62304? If it was written against the old QSR, it may need updating to reflect the QMSR framing.
- Design history file structure: Is your DHF organized in a way that maps to ISO 13485 design and development records expectations, not just the old QSR design controls requirements?
- Post-market surveillance plan: Does a plan exist? Is it specific enough to satisfy QMSR's more substantive post-market requirements? For SaMD, FDA expects real-world performance monitoring from day one of distribution.
- CAPA process: Is your corrective and preventive action process aligned with ISO 13485 structure? If your CAPA process was built against the old QSR framework without ISO 13485 harmonization, the structural differences are worth reviewing.
One Important Note on Transition
FDA has stated that it will apply enforcement discretion during the initial QMSR transition period for manufacturers who demonstrate good faith efforts to align with the new requirements. This does not mean the transition is optional — it means FDA recognizes that full alignment takes time for some organizations.
For teams mid-development or approaching submission, the practical guidance is to align your documentation with QMSR now rather than submitting against the old QSR framework and addressing gaps in a deficiency response. Reviewers are reading submissions against the current regulatory standard.
The Bottom Line
QMSR is not a dramatic departure from what came before. For teams that were already working against ISO 13485 and IEC 62304, the transition is largely a documentation and framing exercise.
For teams that were not — or for teams that treated QSR compliance as a submission-time activity rather than a development-time discipline — QMSR's alignment with ISO 13485 raises the bar in ways that are worth addressing before your next submission, not during it.
The underlying requirement has not changed: FDA expects to see a quality system that demonstrably shaped how your device was built. QMSR makes that expectation clearer and the standard for meeting it more specific.
At Hattrick IT we build FDA-regulated medical device software against current IEC 62304 and ISO 13485 requirements. If you are mid-development and unsure how your process maps to the QMSR framework, we can help you assess the gap.
Get in touch: [email protected]