The Startup MDVisit Website →
← Back to blog

QMSR 21 CFR 820: 4 Immediate Steps for U.S. Healthtech Startups

September 4, 2026
QMSR 21 CFR 820: 4 Immediate Steps for U.S. Healthtech Startups

The FDA now operates 21 CFR Part 820 as the Quality Management System Regulation, and QMSR 21 CFR 820 incorporates ISO 13485:2016 by reference, enforceable since February 2, 2026. The single takeaway for manufacturers: reconcile your QMS documentation and terminology to ISO 13485 while preserving every FDA-specific requirement that ISO does not cover, including labeling controls, complaint handling, and device tracking.

TL;DR:

  • Manufacturers must update their QMS documentation to align with ISO 13485:2016 while maintaining FDA-specific requirements like labeling controls and complaint handling.
  • The regulation now references ISO 13485 as the basis for design controls, process validation, and traceability, with enforcement relying on compliance with the standard's clauses.
  • FDA inspections will emphasize records linking customer complaints to MDR decisions, supplier audits, and management reviews that demonstrate risk-based thinking.
  • Terminology mismatches between legacy SOPs and ISO standards are common inspection triggers; creating a crosswalk table can prevent such issues.
  • Submitting an ISO 13485 certificate alone does not meet FDA requirements, as several sections like complaint records and labeling controls remain explicitly mandated.

Table of Contents

What did the QMSR actually change in 21 CFR Part 820?

The QMSR did not rewrite medical device quality requirements from scratch. It restructured Part 820 so that the bulk of the technical quality system content now points to ISO 13485:2016 instead of restating FDA's own version of design controls, corrective action, and process validation. Most of the old numbered subparts that spelled out procedural detail were reserved, meaning the section numbers still exist but the substance moved to the incorporated standard.

Two sections carry the real weight of the new structure. Section 820.10 requires manufacturers to establish and maintain a quality management system that complies with ISO 13485:2016, and §820.10 requirements for a quality management system now function as the operative compliance clause for Class II and III devices, plus certain Class I devices. Section 820.7 defines how terms in ISO 9000:2015 Clause 3 apply throughout Part 820, which matters more than it sounds. Auditors and investigators will read your procedures against ISO's definitions, not the legacy QSR glossary.

None of this touches the Food, Drug, and Cosmetic Act's adulteration provisions. A device manufactured out of conformance with the QMS requirements is still adulterated under federal statute, and that enforcement hook survived the rewrite untouched.

Key structural shifts to track:

  • Most Subpart C through Subpart Q procedural language was reserved and replaced by reference to ISO 13485:2016.
  • Section 820.10 is now the anchor clause requiring ISO-conformant quality systems.
  • Section 820.7 imports ISO 9000:2015 Clause 3 definitions into every downstream interpretation.
  • Adulteration liability under the FD&C Act remains fully intact regardless of the ISO incorporation.
  • Several other CFR parts received technical amendments to align cross-references with the new QMSR structure.

How does incorporation by reference actually work under §820.7 and §820.10?

Incorporation by reference means the FDA does not reprint ISO 13485:2016's text inside the CFR. Instead, the regulation points to the standard and makes compliance with it a legal requirement. That distinction matters for anyone assuming a purchased copy of ISO 13485 is optional reading. It is not. It is now the operative compliance document for most quality system decisions FDA will inspect against.

The eCFR's Part 820 text confirms that §820.10 obligates manufacturers to document compliance with ISO 13485's applicable clauses alongside any other applicable regulatory requirement. In practice, that pulls design and development controls, production and process controls, and traceability obligations for life-sustaining devices directly into enforceable territory. An investigator citing a nonconformance can now point to an ISO clause number as readily as a CFR section number.

That reach has boundaries. Incorporation by reference covers the ISO 13485:2016 text FDA specifically adopted; it does not sweep in every related ISO standard by association. ISO 14971, the risk management standard for medical devices, remains voluntary under this rule. Manufacturers who already build risk files against ISO 14971 gain no regulatory shortcut for skipping it, and those who never adopted it are not suddenly required to. It still matters in practice because ISO 13485 itself expects risk-based decision-making throughout the QMS, and 14971 remains the most recognized method for satisfying that expectation.

What incorporation by reference actually enforces:

  • Design and development file requirements pulled from ISO 13485's design control clauses.
  • Production and process control obligations, including validation and monitoring.
  • Traceability requirements, particularly for implantable and life-sustaining devices.
  • ISO 9000:2015 Clause 3 terminology as the interpretive baseline for every defined term.
  • ISO 14971 risk management remains voluntary, though practically expected to demonstrate risk-based thinking.

What supplemental FDA requirements still apply beyond ISO 13485?

ISO 13485 certification does not, by itself, satisfy QMSR. FDA retained a handful of sections that go beyond what the international standard requires, and industry analysis of what changed is blunt about this: treating certification as equivalent to full compliance is one of the most common mistakes manufacturers make during the transition.

Section 820.35 governs control of records and requires manufacturers to maintain complaint files, service records, and production records with a level of specificity ISO 13485 does not spell out. This section connects directly to Medical Device Reporting obligations and to Unique Device Identification data, meaning your complaint intake process needs to trace cleanly into both systems, not just satisfy an internal quality metric.

Section 820.45 covers labeling and packaging controls, requiring documented procedures for label integrity checks, UDI accuracy verification, and expiration date controls before product release. This is a physical inspection point investigators can walk a production floor and check directly.

Section 820.3's definitions section also diverges from ISO 9000 terminology in places, which changes how investigators interpret ambiguous language during a records review.

Supplemental provisions worth building explicit SOPs around:

  • §820.35 complaint records, service records, and their links to MDR and UDI data systems.
  • §820.45 labeling and packaging controls, including UDI accuracy and expiration date checks.
  • §820.3 definitions that diverge from ISO 9000 terminology and affect inspection interpretation.
  • Device tracking obligations under Part 830 and Part 821 that sit outside ISO's scope entirely.

What will FDA inspections look for under the new regulation?

FDA replaced the Quality System Inspection Technique with a new compliance program built around QMSR's structure, and the shift is not cosmetic. Investigators are now trained to request documents that QSIT-era inspections sometimes treated as secondary.

According to FDA's own QMSR guidance, enforcement focus now explicitly includes internal audit reports and management review minutes, records that investigators did not always pull under prior QSR practice. Expect requests for supplier audit files and complaint records cross-referenced against MDR decisions as a matter of routine, not exception.

The stakes for getting this wrong have not softened. A device produced out of conformance with QMSR requirements is adulterated under the FD&C Act, which opens the door to warning letters, import alerts, and consent decrees exactly as it did under the old QSR.

Investigators are likely to request internal audit reports covering recent audit cycles.

  • Management review meeting minutes showing required inputs and outputs.
  • Supplier qualification and periodic audit records.
  • Complaint files with documented MDR reportability decisions.

What should practitioners actually do about terminology, risk, and records?

The terminology shift is the part most teams underestimate. AAMI's analysis of the QSR to QMSR transition counts more than 100 material terminology updates, and treating this as a simple find-and-replace exercise is a mistake. Legacy artifacts like the Device Master Record, Device History Record, and Design History File map conceptually to ISO's Medical Device File, production records, and design and development file, but the mapping is not always one-to-one. Some legacy content splits across multiple ISO artifacts; some ISO requirements have no direct QSR predecessor at all.

Consultants who work through this transition regularly point out that inconsistency between what an SOP calls a document and what the live record actually calls itself is one of the most common inspection triggers. If your procedure says "Design History File" but your eQMS folder is labeled "Design and Development File," an investigator will notice the mismatch before they notice the substance.

Pro Tip: Build a terminology crosswalk table before you touch a single SOP. List every legacy term, its ISO 13485 equivalent, and every document where the legacy term appears. Update the crosswalk first, then edit documents against it, so you never end up with three different names for the same file.

Risk-based thinking is the other quiet expectation. ISO 13485 threads risk assessment through design, supplier selection, and production decisions rather than confining it to a single risk management file. Investigators increasingly expect to see risk logic referenced inside management review minutes and supplier audit findings, not just inside a standalone ISO 14971 risk report.

The most common record-content failures worth checking now:

  • Complaint files that lack a documented, defensible MDR reportability decision.
  • Traceability gaps between production lots and UDI or device tracking data.
  • Management review minutes missing required inputs or outputs specified by ISO 13485.
  • Supplier audit records that document findings but not follow-up verification.

Quick wins include adding crosswalk metadata fields inside your eQMS that link legacy document names to their ISO equivalents, and reindexing SOP numbering to mirror ISO 13485 clause structure rather than the old QSR subpart layout.

What immediate steps close the gap to QMSR compliance?

Manufacturers who have not started their transition should not treat this as a multi-year project. The regulation is already enforceable, which makes gap closure an operational priority, not a planning exercise.

  1. Run a focused gap assessment comparing your current QMS against §820.10, §820.35, and §820.45 specifically, rather than a generic ISO 13485 readiness check.
  2. Update every SOP reference and rename legacy artifacts consistently across your eQMS, training records, and audit checklists.
  3. Assemble an inspection-ready records package: recent internal audits, management review minutes, supplier audit files, and complaint records tied to documented MDR decisions.
  4. Prioritize training and documentation review for Class II and III devices, plus any specified Class I devices subject to the design control requirements.

Pro Tip: Start your gap assessment with §820.35 and §820.45, not §820.10. Those two sections contain FDA-specific requirements that a generic ISO 13485 consultant's checklist may never flag, and they are the fastest way an inspection finding turns into a 483.

Does QMSR change software validation and cybersecurity expectations?

QMSR does not introduce new cybersecurity requirements on its own. It routes software validation obligations through ISO 13485's design and development controls instead of the QSR's separate software validation language, which changes documentation expectations more than technical substance.

For connected and software-driven devices, this means your software verification and validation records now need to trace clearly into the design and development file structure ISO 13485 expects, rather than sitting in a parallel software-specific folder disconnected from the rest of design history. Startups building software as a medical device should treat this as a documentation architecture problem: the underlying engineering work does not change, but where and how you file evidence of it does.

Cybersecurity risk management still lives primarily under FDA's separate premarket cybersecurity guidance rather than inside Part 820 itself, but the QMSR's emphasis on integrated risk-based thinking means cybersecurity risk assessments increasingly need to show up as inputs to design reviews and management review meetings, not as standalone artifacts filed elsewhere. Teams building connected diagnostic or monitoring devices should review how device networking and data integrity controls get documented, since traceability expectations under §820.10 extend to how devices communicate and how that connectivity is verified, a topic covered in more technical depth in how medical device networking works. Founders building software-first products should also revisit design control gaps flagged in FDA's SaMD guidance, since common SaMD submission gaps tend to surface in exactly the same design and development file structure QMSR now governs.

Does QMSR change software validation and cybersecurity expectations? — overview diagram

How does QMSR change post-market surveillance obligations?

QMSR does not rewrite Medical Device Reporting or post-market surveillance regulations directly. Part 803 MDR obligations and Part 822 post-market surveillance orders remain separate regulatory tracks. What changes is how tightly your complaint handling and record control processes under §820.35 need to connect to those obligations.

Section 820.35 requires documented complaint records, and investigators now expect a clear, auditable line from a customer complaint to a documented MDR reportability decision, whether that decision was "report" or "do not report." A complaint file that shows intake and closure without showing the reasoning behind the reportability call is a common finding. Post-market surveillance data, including trend analysis across complaints and service records, increasingly needs to feed back into management review as a documented input rather than existing as a siloed quality metric.

For manufacturers already running structured post-market monitoring programs, the practical shift is mostly about documentation traceability rather than new substantive obligations. A closer look at post-market clinical surveillance requirements is worth revisiting now, since the connective tissue between complaint handling, MDR decisions, and management review is exactly where QMSR-era inspections are most likely to probe.

What documentation and template changes does QMSR require?

Most manufacturers will not need to rebuild their document control system from the ground up, but templates that reference legacy QSR terminology need systematic revision. Design History File templates should be relabeled and restructured to align with ISO 13485's design and development file expectations, which typically require tighter linkage between design inputs, verification, validation, and design transfer records than the old QSR template style demanded.

Management review templates need explicit fields for the required inputs and outputs ISO 13485 specifies, including customer feedback, process performance data, and corrective and preventive action status. A template that just captures "attendees and action items" without those structured inputs will not hold up well against an investigator checking for ISO clause conformance.

Complaint handling templates should add a dedicated, documented field for the MDR reportability decision and its rationale, separate from the general complaint investigation notes. This single template change resolves one of the most frequently cited gap findings in early QMSR transitions.

Supplier audit templates benefit from adding explicit risk-tier justification fields, since ISO 13485 expects supplier control intensity to scale with the risk the supplied component or service poses to the finished device.

Who owns what under the new QMSR framework?

Top management carries explicit, documented responsibility under ISO 13485 that the old QSR left more implicit. Management review is not a courtesy briefing; it is a required activity with specified inputs and outputs, and investigators can now ask to see evidence that leadership actually engaged with quality system performance data, not just attended a meeting.

Quality leadership owns the terminology crosswalk and SOP reindexing effort, but that work fails without buy-in from regulatory affairs, since MDR reportability decisions and UDI accuracy sit at the intersection of quality records and regulatory submissions. Engineering and product leadership own design and development file integrity, particularly for software-driven devices where design history has historically lived in disconnected systems.

For healthcare SaaS and device-connected healthtech companies, this cross-functional ownership model is often harder to implement than the paperwork itself, since startup teams frequently lack a dedicated quality function and distribute these responsibilities across founders wearing multiple hats. Reviewing regulatory basics for founders early helps clarify which of these ownership gaps need dedicated hires versus fractional support.

What training and competency expectations come with QMSR?

Staff training needs to reflect the actual terminology and structure your QMS now uses, not the language your team learned under the old QSR. Training records that reference "Device History Record" when your live SOPs now say "production records" create the same inspection risk as document mismatches, only at the personnel level instead of the document level.

Competency expectations extend beyond quality personnel. Design engineers need working familiarity with ISO 13485's design and development clause structure, since design file organization now flows directly from that standard rather than a QSR-specific template. Regulatory affairs staff need to understand where FDA's supplemental requirements, particularly §820.35 and §820.45, diverge from what a purely ISO-trained auditor would check.

Retraining should be documented as a discrete event tied to the QMSR transition, with records showing which personnel completed it and when. An investigator reviewing training records after a document mismatch finding will often ask whether the affected staff had been retrained on the new terminology, and a documented training record closes that line of questioning quickly.

An advisory perspective on what this means for healthtech startups

QMS alignment is not paperwork startups can defer until after a raise. Investors performing diligence on a device-connected or SaMD product increasingly ask for evidence of QMSR readiness, and gaps here slow commercialization timelines more than founders expect.

My guidance to startup leadership is straightforward: retain ownership of design and development file integrity in-house, since that knowledge is core to your product, but consider outsourcing terminology crosswalk work and gap assessments to specialists who do this daily. Engage fractional regulatory or clinical leadership before your first inspection, not after a finding forces the conversation.

— Paul Bergeron MD, MBA

How The StartupMD helps healthtech teams navigate the QMSR transition

The StartupMD gives healthcare SaaS and device-connected startups something a generic compliance consultant cannot: physician-level clinical judgment paired with the operational discipline of a fractional Chief Medical Officer, so QMSR readiness is evaluated against your actual product and commercialization timeline, not a generic checklist.

The StartupMD

Founder-led teams often discover QMSR gaps only when an investor or acquirer's diligence team asks pointed questions about design history files or complaint traceability. Advisers can work with healthcare SaaS and digital health leadership on the strategic side of this problem, helping decide what quality and regulatory functions to build in-house versus engage on a fractional basis, and how that decision affects fundraising readiness and go-to-market timing. If your team is weighing how quality system maturity factors into investor conversations, the Healthcare SaaS Revenue Model Evaluation guide is a useful next step, and reaching out through The StartupMD's services page is the fastest way to scope an advisory engagement suited to where your compliance program stands today.

Sources