This article covers the specific requirements under 21 CFR Part 820 Subpart C, the design history file (DHF), common audit findings, and how the QMSR update aligns design control requirements with ISO 13485.

What are design controls and who must follow them?

Design controls apply to all manufacturers of Class II and Class III medical devices, and to Class I devices that are automated with software or are implantable. The FDA codified design control requirements in 21 CFR Part 820.30 when it issued the original Quality System Regulation in 1996. The QMSR, which became effective February 2, 2026, retains design control requirements and aligns them more closely with ISO 13485 Section 7.3.

The purpose of design controls is to establish a defined, documented, and verifiable process for converting user needs into device specifications and to confirm through objective testing that the final device meets those specifications.

The design control sequence under 21 CFR Part 820.30

Design and development planning (§820.30(b))

Every design project must begin with a documented plan. The plan identifies the design stages, the responsibilities assigned to each stage, and the interfaces between different development teams. The plan must be updated as the project evolves.

Design input (§820.30(c))

Design inputs are the physical and performance requirements for the device derived from the intended use and user needs. They must be documented, reviewed for adequacy, and approved by a designated individual.

The most common audit finding in design inputs is incomplete or ambiguous requirements. An input that states the device must be "easy to use" is not a design input. A measurable, verifiable requirement, such as a force threshold for actuation or a specific display resolution, is a design input.

Design output (§820.30(d))

Design outputs are the documents that define the finished device: drawings, specifications, procedures, and software code. Outputs must meet design inputs, and the connection between each output and its corresponding input must be traceable.

Design review (§820.30(e))

At each major design stage, a formal documented review must occur. The review includes at least one individual who does not have direct responsibility for the design stage being reviewed. Results, including follow-up actions, must be documented.

Design verification (§820.30(f))

Verification confirms that design outputs meet design inputs. It answers the question: did we build the device we designed? Verification methods include testing, inspection, analysis, and demonstration. Each verification activity must be documented with results, dates, and the individuals who performed and approved the testing.

Design validation (§820.30(g))

Validation confirms that the finished device meets user needs and intended uses. Where practical, validation must be performed on initial production units. Validation answers the question: does the device we built actually do what users need?

Software validation under FDA's Computer System Assurance (CSA) guidance applies to software that forms part of a device or controls a device.

Design transfer (§820.30(h))

Design transfer ensures that the device design is translated into production specifications that allow consistent manufacturing. Transfer procedures must confirm that production processes can produce a device that meets specifications.

Design changes (§820.30(i))

Any change to the design after initial approval must be identified, documented, reviewed, and approved before implementation. Changes that could affect the device's safety or effectiveness require an assessment of whether a new 510(k) or PMA supplement is needed.

Design history file (§820.30(j))

The design history file is the complete record of the design and development process. It does not need to be a single document, but it must contain or reference all records needed to demonstrate that the design was developed in accordance with the approved design plan.

Common FDA audit findings in design controls

The FDA's inspection data consistently shows design controls as one of the top observation categories for medical device manufacturers. The most frequently cited specific findings include:

Traceability gaps. Design inputs are not linked to corresponding design outputs, verification tests, or validation activities. Without traceability, there is no documented confirmation that every requirement was addressed. A design traceability matrix (DTM) or requirements traceability matrix (RTM) resolves this.

Validation using prototype devices. FDA requires that validation be performed using initial production units or their equivalent. Companies that validate using hand-built prototypes or pre-production samples and then change the manufacturing process before commercial production have a validation gap.

Incomplete design reviews. Reviews that lack the documented participation of a qualified independent reviewer, or reviews where action items are not tracked to closure, do not meet §820.30(e).

Design inputs that cannot be verified. Inputs must be stated in measurable terms. Qualitative inputs like "durable," "lightweight," or "user-friendly" cannot be verified through testing. FDA cites these as inadequate design inputs.

Design change control gaps. Post-approval changes that were implemented without documentation or without a risk assessment of their impact on safety and effectiveness represent some of the most serious design control violations. These can result in the device being distributed in an unapproved configuration.

Missing or incomplete DHF records. A design history file that cannot be located, that is incomplete, or that contains records not signed and dated by the responsible individuals fails to satisfy §820.30(j).

How QMSR changes design control requirements

The FDA's Quality Management System Regulation, effective February 2, 2026, incorporated by reference ISO 13485:2016, including Section 7.3 on design and development. The QMSR retains the substantive design control requirements from 21 CFR Part 820.30 while harmonizing the terminology and structure with ISO 13485.

Key changes quality teams should note:

• The QMSR uses the term “design and development” rather than “design controls,” aligning with ISO 13485 language
• Risk management under ISO 14971 is now explicitly integrated into the design and development process, rather than being treated as a separate activity
• The QMSR requires documented design and development inputs to include applicable regulatory requirements, making it explicit that regulatory research is part of the input process
• Transfer of design to manufacturing is now referenced in the context of documented procedures, consistent with ISO 13485 Section 7.3.7

Companies already operating under ISO 13485 certification found that their existing design control procedures required relatively minor updates to comply with the QMSR. Companies operating only under the original QSR faced more substantial documentation and process updates.

Managing design controls in a QMS platform

Design controls generate a large volume of interconnected records across a long development timeline. Managing those records manually in spreadsheets or shared drives creates traceability risks and makes it difficult to demonstrate a complete DHF during an inspection.

Cloudtheapp's QMS platform includes a Design Controls application that manages the full design and development lifecycle, from design plans and input requirements through verification, validation, design reviews, change control, and DHF compilation. Each record links to related records, creating automated traceability across the development process.

The platform's design change control workflow routes change requests through configurable approval steps and triggers a risk assessment for changes that affect safety or effectiveness, directly addressing the most common design control audit finding.

For medical device manufacturers preparing for an initial FDA inspection or addressing design control observations from a prior cycle, Cloudtheapp offers a live demo showing how the platform manages design and development documentation: https://www.cloudtheapp.com/demo/

See also: How to write a design history file that passes FDA review

Key takeaways

Design controls under 21 CFR Part 820 require a documented, traceable, and verifiable development process for every medical device. The most common audit findings, traceability gaps, invalid validation, and incomplete design reviews, all reflect the same underlying issue: the design process was not planned and documented as a controlled system from the start.

The QMSR update aligns FDA's design control requirements with ISO 13485 Section 7.3 and explicitly integrates risk management throughout the design process. Companies that maintain a complete design history file with traceable links from user needs through validated device performance have a strong foundation for both FDA inspections and ISO 13485 audits.

This post created by and appeared first on Cloudtheapp

This article reviews the most frequently cited violations in recent FDA warning letters, examines specific case studies from 2024 and 2025, and explains what each finding means for your quality management system.

What is an FDA warning letter?

An FDA warning letter is an official communication from the agency notifying a company that it has observed violations of FDA regulations that are significant enough to warrant regulatory action. Warning letters follow an FDA inspection and a Form 483 that went unresolved or received a response FDA considered inadequate.

Warning letters are public. The FDA posts them on its website, including the company name, the site address, the specific CFR sections violated, and the exact language describing each failure. That transparency makes them one of the most useful compliance learning tools available to quality teams.

According to data published by Pharmaceutical Online in March 2026, FDA sent 303 drug warning letters in FY 2025, a 59% increase from the prior fiscal year. That volume matters because each one of those letters describes a real failure that FDA considered serious enough to escalate beyond a 483.

The most frequently cited violations across warning letters

1. CAPA system failures

Corrective and Preventive Action failures rank as the single most cited violation category in FDA warning letters for medical device manufacturers. According to Cloudtheapp's FDA enforcement trends analysis, FDA issued 279 CAPA observations to medical device facilities in FY 2025 alone.

The specific failure patterns in warning letters go beyond simply not having a CAPA procedure. FDA consistently cites:

• CAPA processes that document the corrective action but do not verify the root cause was actually eliminated
• Repeat CAPAs opened for the same failure type across multiple cycles, indicating the underlying cause was never resolved
• CAPA effectiveness checks that consist of closing the record after a defined time period rather than confirming the problem stopped occurring

The Dexcom warning letter issued March 4, 2025 (MARCS-CMS 700835) cited failures in the CAPA system among other quality system violations following inspections at San Diego facilities in October 2024. Dexcom manufactures continuous glucose monitoring systems, which makes this a high-consequence example of what happens when a medical device company's CAPA system cannot demonstrate effectiveness.

2. Data integrity violations

Data integrity citations appear in almost every pharmaceutical warning letter and an increasing percentage of medical device letters. The core violation involves records that do not accurately capture what actually happened during manufacturing, testing, or release.

Specific failure modes FDA cites in data integrity observations include:

• Backdating entries in batch records or laboratory logs
• Deleting and re-running laboratory tests without documenting the original result
• Using a shared login for electronic systems rather than individual user credentials
• Failing to maintain an audit trail that captures original entries, changes, and the identity of the person who made each change

The Glenmark Pharmaceuticals warning letter issued July 11, 2025 (MARCS-CMS 708270) cited repeat violations across multiple sites, which reflects a pattern FDA treats with particular severity. When the same violation appears at more than one facility within the same company, FDA reads it as a systemic quality culture problem rather than an isolated site issue.

3. Laboratory control failures

According to analysis published by Certainty Software in May 2026, identity testing failure was cited in 49 of 85 drug warning letters reviewed from 2025, making it the single most common violation in that set. Identity testing requires that every active ingredient in a drug product is verified at receipt. Companies that skip or abbreviate this step because their supplier has a long track record are not compliant.

Other frequent laboratory violations include:

• Out-of-specification (OOS) investigations that fail to complete a root cause investigation before invalidating a result
• No documented procedure for when and how to escalate an OOS result
• Laboratory instruments with expired calibrations used for release testing
• Stability testing programs that do not cover the full product shelf life

The FDA's own guidance on laboratory controls, published under 21 CFR 211.68 for drug products and 21 CFR Part 820 for devices, requires that all laboratory equipment is calibrated, that procedures are followed without exception, and that any deviation from a specification triggers a documented investigation.

4. Production and process controls

Production control violations cite manufacturers for running processes that have not been fully validated or for running validated processes outside their specified parameters without documented justification.

Common specific observations include:

• Batch records that do not match actual manufacturing steps performed
• Environmental monitoring data showing contamination trends that were never investigated
• Failure to validate cleaning procedures between product changeovers
• Process parameters set outside the validated range without change control approval

5. Document control deficiencies

Document control violations in warning letters typically describe facilities where the procedures employees follow do not match the approved versions on file, or where the document management system does not prevent access to superseded documents.

The connection between document control failures and other quality problems is direct. If operators are working from outdated SOPs, their actions cannot be compliant regardless of how well-intentioned they are.

Three patterns that explain why the same violations repeat

Pattern 1: CAPAs that document activity instead of eliminating causes

The most common CAPA failure is not the absence of a CAPA system. It is a CAPA system that closes records based on the completion of action items rather than verification that the failure stopped. A company can complete every task in a CAPA and still reopen the same problem six months later if the root cause was misidentified.

FDA investigators look specifically at whether effectiveness checks are conducted, when they are conducted relative to the corrective action, and what objective evidence confirms the problem no longer occurs.

Pattern 2: Electronic systems without controls

Companies that transition from paper records to electronic systems often replicate the paper-based process in digital form without implementing the access controls, audit trails, and validation that electronic systems require under 21 CFR Part 11.

An electronic batch record that can be edited without creating a permanent audit trail entry is not more compliant than the paper record it replaced. It is less compliant, because the audit trail requirement is now explicit and the failure to meet it is documentable.

Pattern 3: Quality systems that do not escalate to management

FDA warning letters frequently cite situations where quality data showing a trend was available in the QMS but was never escalated to site management or addressed through the management review process. The data was collected. The CAPA was opened. The trend continued. No one with authority to allocate resources to fix the underlying problem was ever made aware of it.

This is why FDA places significant weight on the management review process. It is the mechanism by which quality data converts into resource decisions.

What these citations mean for your QMS

Each repeat citation category points to a specific capability gap that quality teams can address before an inspection.

For CAPA: Build effectiveness verification into every CAPA record before it can be closed. Define what evidence constitutes proof that the root cause is gone. Set a verification date tied to when enough time has passed to observe whether the failure recurred.

For data integrity: Audit your electronic systems for shared logins, disabled audit trails, and the ability to delete or overwrite records without a traceable entry. Any system where that is possible represents a 21 CFR Part 11 violation waiting to be cited.

For laboratory controls: Confirm that your OOS procedure requires a full root cause investigation before any test result can be invalidated. Check that all instruments in your release testing workflow have current calibration certificates and that expired instruments are physically removed from service.

For process controls: Validate every process parameter that affects product quality. If a process is running outside its validated range, treat that as a deviation requiring documentation and investigation, not a routine adjustment.

For document control: Implement a system that makes it impossible for employees to access superseded document versions. This is not a procedural requirement alone; it requires a technical control.

How a modern QMS addresses warning letter risk areas

Warning letters describe failures that are almost always traceable to the same root cause: the quality system cannot generate real-time visibility into whether its own processes are working.

A CAPA that closes without an effectiveness check is not a process failure. It is a system failure. The QMS did not require effectiveness verification before allowing the record to close.

Cloudtheapp's QMS platform includes 60+ configurable applications built specifically for regulated environments, including dedicated modules for CAPA management, deviation tracking, document control, laboratory management, and audit management. Each application is pre-configured to meet FDA QMSR, ISO 13485, and ISO 9001 requirements, and every record maintains a full audit trail by default.

For companies preparing for an FDA inspection or addressing observations from a prior inspection cycle, Cloudtheapp's CAPA module enforces an effectiveness verification step before any corrective action record can be closed, directly addressing the most frequently cited warning letter failure pattern.

Learn more about how Cloudtheapp approaches FDA inspection readiness and responding to FDA 483 observations.

Schedule a demo to see how the platform handles CAPA, document control, and data integrity in a pre-validated environment: https://www.cloudtheapp.com/demo/

Key takeaways

FDA warning letters from 2024 and 2025 show four dominant violation categories: CAPA failures, data integrity problems, laboratory control gaps, and inadequate process validation. These are not new categories. They appear in warning letters year after year because the underlying causes are not resolved at the system level.

Quality teams that read recent warning letters as case studies can identify whether their own QMS has the same structural gaps. The specific failures FDA describes in each letter are specific enough to check against your own procedures, records, and system configurations.

The companies that receive warning letters are not always the companies with the worst quality cultures. They are often companies with quality systems that cannot enforce their own requirements.

This post created by and appeared first on Cloudtheapp

A well-constructed DHF tells a coherent story: here is what the device was intended to do, here is how design requirements were established from those intentions, here is how the design was verified to meet its requirements, and here is how it was validated to meet user needs in actual use conditions. A poorly constructed DHF — one with missing records, broken traceability between requirements and verification results, or undefined design controls — tells a very different story, one that tends to generate multiple Form 483 observations and occasionally warning letters.

This guide covers what must go into a DHF, how to structure it, and the most common mistakes that lead FDA reviewers to question whether a company’s design process was genuinely controlled.

What FDA requires in a DHF

21 CFR 820.30(j) states that each manufacturer must establish and maintain a DHF for each type of device. The DHF must contain or reference the records necessary to demonstrate that the design was developed in accordance with the approved design plan and the requirements of the design controls regulation.

The QMSR, which aligns FDA requirements more closely with ISO 13485:2016, reinforces these requirements and adds explicit expectations around risk management integration throughout the design process. A DHF that satisfies current FDA expectations covers these core areas:

• Design and development planning records
• Design input records (user needs, intended use, requirements)
• Design output records (specifications, drawings, software documentation)
• Design review records
• Design verification records
• Design validation records
• Design transfer records
• Design change records
• Risk management file records (per ISO 14971)

Each of these categories represents a phase of the design process, and they must be traceable to each other. An FDA investigator should be able to pick up any design output and trace it back to the design input that generated it, and forward to the verification test that confirmed it was met.

DHF vs. Device Master Record vs. Device History Record

The DHF is frequently confused with two related regulatory concepts. Understanding the distinction matters because FDA treats them as separate records with separate purposes.

The DHF contains the evidence of the design process: the work done to design the device. The Device Master Record (DMR) contains the specifications and procedures needed to manufacture the device: drawings, manufacturing specifications, quality plans, and labeling. The Device History Record (DHR) contains the production records for each manufactured batch or unit: what was made, when, by whom, and whether it met specifications.

These three records form a connected triad. The DHF establishes that the design is sound. The DMR defines how to build it. The DHR proves that it was built correctly. For a 510(k) submission, FDA focuses on the DHF. During a manufacturing inspection, investigators examine all three.

Structuring the DHF for FDA review

There is no single format FDA mandates for the DHF, but the structure should make traceability easy to demonstrate. A DHF that requires an investigator to search through five separate filing locations to connect a design requirement to its verification evidence is a DHF that creates problems during inspections. The best-structured DHFs are organized either chronologically by design phase or by section, with a clear index and cross-referencing between records.

Design and development planning

The DHF should begin with the design and development plan, a document that establishes the overall approach to the design project: what is being designed, who is responsible for each activity, what the project milestones are, and how design reviews will be conducted. The plan does not need to predict every activity in advance, but it should be updated as the design evolves and reviewed during formal design reviews.

Design inputs

Design inputs are the requirements the device must meet. They come from multiple sources: clinical and user needs, applicable standards, regulatory requirements, business requirements, and risk analysis. FDA expects design inputs to be documented, reviewed, and approved by qualified personnel before design work begins in earnest.

The most common design input failure is vagueness. A design input that states “the device should be easy to use” is not a requirement that can be verified. A design input that states “the device must be operated with one hand by a user wearing standard surgical gloves with a grip force not exceeding 15 Newtons” is verifiable. FDA investigators who find design inputs written in broad, unverifiable language consistently question whether the design process was genuinely controlled.

Design outputs

Design outputs are the results of design work: engineering drawings, material specifications, software design documents, labeling specifications, and manufacturing instructions. Each design output must trace to one or more design inputs, and the DHF must make this traceability visible. A design traceability matrix, linking each design input to the outputs that satisfy it and the verification tests that confirm they do, is the most efficient way to demonstrate this to an FDA reviewer.

Design reviews

Formal design reviews must be conducted at appropriate stages of the design process. The DHF must contain records of each review: who attended, what was reviewed, what questions or issues were raised, and how those issues were resolved. Design reviews that are documented only as a brief sign-off with no record of the issues discussed do not satisfy FDA’s expectations for a meaningful review process.

Design verification

Design verification confirms that design outputs meet design inputs. Verification is typically conducted through testing, analysis, inspection, or comparison to similar proven designs. Each verification activity must be documented with the verification method, the acceptance criteria, the results, and a conclusion as to whether the design input was met.

A critical point: verification confirms that you built the device to specification. It does not confirm that you built the right device. That is what validation does.

Design validation

Design validation confirms that the device meets user needs and intended uses under actual or simulated use conditions. Validation must be performed on production-equivalent units (not early prototypes), and it must address the full range of users and use environments identified in the design inputs.

For devices involving human use, validation typically includes usability testing conducted in accordance with FDA’s human factors guidance. The validation must be explicitly linked to the design inputs established at the beginning of the design process. An FDA reviewer should be able to see a direct connection between the user needs captured in design inputs and the validation test protocols designed to confirm that those needs are met.

Design transfer

Design transfer is the process of translating the design into production. The DHF must contain evidence that the design was formally transferred to manufacturing, that production processes are capable of producing devices that meet design specifications, and that the Device Master Record was established and reviewed before production began.

Design changes

Every change made to the device design after the initial design transfer must be documented in the DHF through the design change control process. The change record must include the reason for the change, the potential impact on the device’s safety, effectiveness, or regulatory status, the verification and/or validation performed to confirm the change does not create new risks, and the approval of qualified personnel.

Design changes with uncontrolled documentation are among the most frequently cited DHF deficiencies in FDA inspections. When a device undergoes multiple design iterations over its commercial life but the DHF is not updated to reflect those changes, investigators cannot determine whether the device being manufactured is actually the device that was validated.

Risk management integration

Under the QMSR and ISO 13485:2016, risk management is expected to be integrated throughout the design process, not performed as a standalone document at the end. The DHF should contain or reference the risk management file (per ISO 14971), and risk assessment results should be traceable to design inputs, design outputs, and verification/validation activities. The risk register maintained during design development must reflect how identified hazards were addressed through design changes, protective measures, or labeling.

Common DHF failures that generate FDA citations

The patterns that lead to DHF-related observations are consistent across FDA inspection reports and warning letters.

Missing traceability. A DHF where design inputs, outputs, and verification records exist as separate documents with no connecting links fails to demonstrate a controlled design process. The investigator cannot confirm that every design input was addressed by a design output and verified.

Inadequate design inputs. Vague or unverifiable design inputs are a foundational problem because everything downstream relies on them. If the requirements are not specific and measurable, verification cannot confirm they were met, and validation cannot confirm the device meets user needs.

Incomplete design change records. Device modifications made during development or post-market without corresponding design change records create a DHF that does not reflect the actual device. This is particularly problematic for software-containing devices where firmware updates may not have triggered formal change control.

Validation on non-representative units. Performing design validation on pre-production prototypes that differ materially from the production device does not satisfy FDA’s requirement that validation be performed on production-equivalent units.

No connection between risk management and design decisions. A risk management file that exists as a separate document with no visible influence on design inputs, design changes, or validation scope does not demonstrate that risk management was genuinely integrated into the design process.

How Cloudtheapp supports design history file management

Managing a DHF across a multi-year development program, with multiple engineering disciplines, iterative design changes, and evolving regulatory requirements, is genuinely difficult with paper-based or disconnected systems. When verification test results live in one system, design change records in another, and the risk management file in a third, traceability becomes a manual effort that creates inconsistency and audit risk.

Cloudtheapp’s design controls module links design inputs, design outputs, verification records, validation protocols, and design change records within a single quality management environment. The traceability matrix is generated automatically from the linked records, so quality teams spend less time assembling evidence packages and more time doing engineering work. The audit trail captures every record creation, revision, and approval, giving FDA reviewers the complete document history they expect to see.

With 60+ applications covering the full quality and compliance lifecycle for medical device, pharma, and biotech companies, Cloudtheapp supports design control programs from initial product concept through post-market design changes. Schedule a demo to see how the design controls and DHF management features work in practice.

Conclusion

A DHF that passes FDA review is not a collection of documents assembled at the end of development. It is a living record built throughout the design process, where each phase generates documented evidence that is linked to the phases before and after it. The traceability between design inputs, design outputs, verification, and validation is what gives an investigator confidence that the design process was genuinely controlled. Organizations that build traceability into their design process from the first requirements workshop tend to produce DHFs that hold up under scrutiny. Those that try to reconstruct traceability after the device is already in production typically find gaps that are difficult to close without repeating development work.

This post created by and appeared first on Cloudtheapp

The structure changed significantly while the underlying compliance obligations largely stayed intact. Here is what your quality team needs to understand.

What is 21 CFR Part 820?

21 CFR Part 820 is the section of the Code of Federal Regulations that establishes the minimum current good manufacturing practice (cGMP) requirements for the design, manufacture, packaging, labeling, storage, installation, and servicing of all finished medical devices sold in the United States. The original Quality System Regulation (QSR) under Part 820 went into effect on December 18, 1978, and was last substantively updated in 1996.

For roughly 28 years before the QMSR transition, the QSR operated as a standalone FDA framework, separate from international standards like ISO 13485. That gap between US and global requirements created a dual-compliance burden for manufacturers selling into both US and international markets.

What is the QMSR?

The QMSR (Quality Management System Regulation) is the revised version of 21 CFR Part 820, published by FDA on February 2, 2024, in the Federal Register, with a two-year compliance window that ended February 2, 2026.

The QMSR's central change is that it incorporates ISO 13485:2016 by reference as the core compliance framework. Rather than maintaining a separate FDA-specific quality system standard, the QMSR treats ISO 13485 as the baseline, with FDA supplemental requirements layered on top. According to FDA's QMSR FAQ page, the agency made conforming edits to 21 CFR Part 4 as well to address combination product oversight.

What changed: the major differences

Structure and framework

The legacy QSR was a standalone document with its own clause structure, definitions, and requirements. The QMSR replaced that structure with ISO 13485:2016 as the incorporated standard, meaning manufacturers now work within an internationally recognized framework rather than a purely FDA-specific one.

For manufacturers already certified to ISO 13485, this simplifies dual compliance significantly. The two frameworks address the same quality system domains but used different terminology and clause numbering. QMSR eliminates much of that redundancy.

Terminology and definitions

The old QSR used terms like "finished device," "quality audit," and "quality system record" in ways that did not always map cleanly to ISO 13485 vocabulary. The QMSR aligns terminology with ISO 13485, which means quality system documentation may need updates to reflect current regulatory language.

According to the Federal Register final rule, FDA received comments recommending full alignment of definitions with ISO 13485, and the agency made significant adjustments in response.

FDA supplemental requirements

Even though ISO 13485 is now the core, FDA retained supplemental requirements that go beyond the international standard. These include requirements specific to complaint files and Medical Device Reports (MDRs), Unique Device Identifier (UDI) integration requirements, provisions addressing combination products under 21 CFR Part 4, and specific requirements for software validation tied to FDA's Computer Software Assurance (CSA) framework.

The NSF analysis of QMSR notes that QMSR makes ISO 13485:2016 "the core set of requirements," with FDA additions that enhance or clarify the international standard rather than replace it.

Design controls

Design controls remain mandatory under QMSR, but the requirements now flow through ISO 13485 Section 7.3. The substantive obligations are similar to the old 21 CFR 820.30 design control requirements, but the structure and documentation expectations reflect ISO 13485 conventions.

Risk management

The QMSR places greater emphasis on risk management by aligning with ISO 13485's risk-based approach. Manufacturers should ensure their risk register and associated risk management documentation meet ISO 14971 integration requirements, which are referenced in ISO 13485 and by extension in QMSR.

What stayed the same

The core compliance obligations that FDA has enforced for decades remain in place.

Document control remains required: all quality system documentation must be reviewed, approved, and controlled. The process does not change materially, though the clause references update to ISO 13485 numbering.

CAPA requirements carry forward. FDA inspectors continue to scrutinize CAPA programs closely, and the expectation for thorough root cause investigation remains unchanged.

Complaint handling persists: manufacturers must still maintain complaint files and evaluate each complaint for potential reportability as an MDR. The threshold for determining reportability has not changed.

Audits of the quality system remain required. The audit trail requirements for electronic records under 21 CFR Part 11 also remain in effect.

Supplier qualification and management requirements persist. The QMSR continues to require that manufacturers evaluate and select suppliers capable of meeting quality requirements.

Records retention timeframes and requirements carry over with limited modification.

What QMSR means for companies already certified to ISO 13485

For manufacturers who hold ISO 13485:2016 certification, the transition to QMSR compliance is primarily about understanding where FDA's supplemental requirements go beyond the international standard and ensuring those gaps are addressed in your quality system.

The Morgan Lewis QMSR readiness guide from October 2024 identified the key areas requiring attention as: MDR-specific complaint file requirements, UDI integration in records, software validation under CSA guidance, and combination product-specific provisions.

If your ISO 13485 certification scope covers those areas and your procedures reflect current FDA expectations, the transition documentation burden is manageable.

What QMSR means for companies that relied only on the old QSR

Manufacturers who built their quality system around the legacy QSR without maintaining ISO 13485 alignment face a more significant gap analysis. The clause structure is different, the risk management expectations are deeper, and the terminology in procedures and records may need updating.

FDA's own FAQ confirms that manufacturers were expected to have full systems in place by February 2, 2026, and that inspectors will evaluate compliance against the new QMSR framework. An FDA Form 483 observation citing QMSR non-compliance carries the same weight as any other observation, and repeated findings can escalate to warning letters.

The practical gap analysis: where to start

A QMSR transition gap analysis typically covers five areas.

First, map existing procedures to QMSR/ISO 13485 clause numbers. Identify procedures that reference old QSR sections by number and update those references.

Second, confirm that risk management documentation meets ISO 14971 requirements as integrated into ISO 13485 Section 7.1.

Third, verify supplier qualification files reflect QMSR requirements for supplier evaluation and re-evaluation.

Fourth, confirm that your computer system validation approach aligns with FDA's CSA guidance, which applies under QMSR.

Fifth, ensure the complaint process clearly identifies the MDR reporting decision point and documents that determination in the complaint record.

How a modern QMS platform supports QMSR compliance

Maintaining QMSR compliance requires a quality system that connects CAPA, complaints, document control, supplier qualification, risk management, and audit management in a single traceable environment. Disconnected spreadsheets and paper-based systems make it difficult to demonstrate the integrated quality system FDA now expects.

Cloudtheapp's cloud-based QMS gives medical device manufacturers a pre-validated, FDA-compliant platform with 60+ applications covering every QMSR domain. The platform supports ISO 13485 alignment out of the box, with built-in audit trail functionality, automated CAPA workflows, and electronic records that meet 21 CFR Part 11 requirements.

If your quality system needs a structural update to support QMSR compliance, schedule a demo to see how Cloudtheapp can accelerate your transition.

Frequently asked questions

When did QMSR go into effect?

The QMSR became effective February 2, 2026. FDA published the final rule in the Federal Register on February 2, 2024.

Does QMSR replace 21 CFR Part 820?

The QMSR revises 21 CFR Part 820, rather than replacing the regulatory citation. Part 820 still exists as the regulatory address, but the content now incorporates ISO 13485:2016 by reference.

Do I need ISO 13485 certification to comply with QMSR?

Certification is not required. ISO 13485 certification demonstrates conformance but is not mandated by FDA. The QMSR requires compliance with the substance of ISO 13485, not the certification credential.

What happens during an FDA inspection under QMSR?

FDA inspectors will evaluate your quality system against QMSR requirements, which include ISO 13485 obligations plus FDA supplemental requirements. Inspectors may ask to see gap analysis documentation from the transition, particularly for companies that previously operated under the old QSR without ISO 13485 alignment.

How long does a QMSR gap analysis take?

The timeline depends on the size and complexity of your existing quality system. A manufacturer with an ISO 13485-aligned system may complete the gap analysis in weeks. A manufacturer rebuilding from a QSR-only baseline may need three to six months.

This post created by and appeared first on Cloudtheapp

The FDA’s Quality Management System Regulation (QMSR) took effect on February 2, 2026, replacing the old Quality System Regulation (QSR) that had governed 21 CFR Part 820 since 1996. The regulation number stayed the same — 21 CFR Part 820 — but the substance changed significantly. The core shift: the FDA incorporated ISO 13485:2016 by reference, making it the backbone of U.S. medical device quality system requirements for the first time. For manufacturers already certified to ISO 13485, many obligations now overlap with FDA expectations. For those who were not, the QMSR represents a broader set of documented requirements than the old QSR demanded.

What the QMSR actually is

The QMSR is the revised version of 21 CFR Part 820. The FDA published the final rule on February 2, 2024, giving manufacturers exactly two years to prepare before enforcement began. The rule did not create a new regulation from scratch. It amended the existing Part 820 by incorporating ISO 13485:2016 and ISO 9000:2015 Clause 3 (definitions) by reference, while adding FDA-specific requirements where ISO 13485 alone was insufficient to meet the statutory expectations of the Federal Food, Drug, and Cosmetic Act.

The old regulation was informally called the Quality System Regulation or QSR. The revised version carries a new name: the Quality Management System Regulation, or QMSR. The underlying legal authority — Section 520(f) of the FD&C Act — did not change. What changed is how the FDA defines what a compliant quality system looks like in practice.

According to the FDA’s QMSR page, the agency determined that ISO 13485:2016 requirements are, taken in totality, substantially similar to the old QSR requirements, providing an equivalent level of assurance that devices are manufactured safely and consistently.

What changed from the old QSR

Incorporation of ISO 13485:2016

The most consequential change is structural. Under the old QSR, the FDA maintained its own standalone quality system requirements. Under the QMSR, ISO 13485:2016 is incorporated by reference, meaning compliance with the QMSR requires compliance with ISO 13485 unless FDA-specific provisions say otherwise. Manufacturers can access the standard in read-only format through the ANSI Incorporated by Reference Portal at ibr.ansi.org.

This harmonization aligns the U.S. with regulatory authorities in Canada, the European Union, Japan, and other markets that have used ISO 13485 as the baseline standard for years. A manufacturer certified to ISO 13485:2016 by an accredited certification body will find that a large portion of their existing documentation already addresses QMSR obligations, though FDA-specific additions still apply.

Expanded FDA inspection authority

Under the old QSR, Section 820.180(c) exempted internal quality audits from FDA inspection — including supplier audits and management review reports. The QMSR eliminates this exemption entirely.

As of February 2, 2026, FDA investigators can request and review:

• Internal audit reports
• Supplier audit reports and findings
• Management review meeting records and outputs

The FDA’s rationale, stated in the final rule preamble, is that manufacturers already provide these records to other regulatory bodies under ISO 13485, so making them available to FDA investigators does not create additional burden. For manufacturers whose internal audits have historically been informal or underdocumented, this change creates a real compliance gap. An audit trail that shows systematic, structured internal reviews is now essential to inspection readiness.

New inspection process replacing QSIT

The Quality System Inspection Technique (QSIT), which FDA investigators used for decades to structure device inspections, was withdrawn on February 2, 2026. The new inspection process is described in the updated Compliance Program 7382.850 (Inspection of Medical Device Manufacturers), implemented on the same date the QMSR took effect.

Manufacturers preparing for their first post-QMSR inspection should review this compliance program and understand how their quality system documentation maps to QMSR requirements rather than the old QSIT subsystem framework.

Combination product requirements clarified

The FDA also made conforming edits to 21 CFR Part 4 to clarify quality management system requirements for combination products (devices combined with drugs or biologics). These edits did not change the underlying CGMP requirements for combination products but provide additional clarity for manufacturers operating at the device-drug or device-biologic boundary.

What stayed the same

The fundamental obligations of a quality management system for medical devices did not change. Manufacturers must still:

• Establish, document, implement, and maintain a quality management system
• Define and control processes for design, production, and post-market activities
• Conduct internal audits at planned intervals
• Control nonconforming products and initiate corrective and preventive actions
• Maintain document and record control systems
• Qualify and monitor suppliers

The FDA was explicit in the final rule: the requirements of the QSR and the QMSR are substantially similar. A manufacturer that maintained a well-run quality system under the old regulation should find the transition manageable. Records created before February 2, 2026 remain valid, and the FDA has indicated that investigators may find it useful when manufacturers complete a comparative analysis showing that pre-QMSR records meet QMSR requirements.

The statutory basis and enforcement authority also stayed the same. The FDA still conducts risk-based inspections. A FDA Form 483 observation under the QMSR carries the same weight as it did under the old QSR. The path from inspection observation to warning letter to consent decree follows the same escalation pattern.

MDSAP (Medical Device Single Audit Program) continues as a voluntary third-party audit program. Holding an MDSAP certificate does not exempt a manufacturer from FDA inspection, and the FDA will not issue ISO 13485 certificates of conformance. FDA inspections assess compliance with federal regulations; third-party MDSAP audits assess conformance to the ISO standard.

What the QMSR means for ISO 13485-certified manufacturers

If your facility holds a current ISO 13485:2016 certification, a significant portion of your quality system already aligns with QMSR requirements. The areas to examine carefully are the FDA-specific additions: requirements that clarify expectations beyond what ISO 13485 alone specifies, particularly around electronic records under 21 CFR Part 11, combination product documentation, and the now-eliminated inspection exemptions for audits and management reviews.

ISO 13485 certification is not a substitute for QMSR compliance, and the FDA will not accept a certification certificate as evidence of compliance. The FDA’s inspection program operates independently from third-party certification schemes.

What the QMSR means for manufacturers who were not ISO 13485-certified

The transition is more substantial for facilities that built their quality systems to the minimum QSR requirements without pursuing ISO 13485 certification. ISO 13485 is more prescriptive in certain areas — particularly risk management integration, supplier qualification, and formal management review documentation.

Areas that commonly require additional work include:

• Risk management documentation and integration with design and production processes
• Supplier qualification and audit programs (now fully subject to FDA inspection)
• Formal management review records with documented outputs and follow-up actions
• Process validation with documented evidence across all production stages

The two-year transition period from February 2024 to February 2026 was intended to allow manufacturers to close these gaps. Manufacturers still working through their gap analysis should prioritize the areas most likely to surface during an inspection visit: internal audit records, supplier controls, management review minutes, and corrective action systems.

How an eQMS supports QMSR compliance

The shift to QMSR compliance is, at its core, a documentation and traceability challenge. Every process change, corrective action, audit finding, supplier evaluation, and management review decision must be recorded, controlled, and available for review on demand.

Paper-based or fragmented quality systems create serious risk in this environment. When an FDA investigator arrives and requests your supplier audit reports from the past three years, a quality management system that stores documents in shared drives or physical binders cannot produce them quickly or consistently.

Cloudtheapp’s cloud-based eQMS is built for exactly this operating model. With 60+ purpose-built applications covering audits, supplier qualification, CAPA, document control, and management review, Cloudtheapp gives quality teams a single source of truth for every record that matters under the QMSR. The platform is validated to FDA computer system validation guidelines and supports 21 CFR Part 11 electronic records and signatures, so your digital records meet the same evidentiary standards as paper records in an FDA inspection.

Manufacturers transitioning from the old QSR to the QMSR use Cloudtheapp to map their existing quality system documentation against QMSR requirements, identify gaps, and build the processes needed to close them — without rebuilding their system from scratch.

See how Cloudtheapp supports QMSR compliance

Common questions about 21 CFR Part 820 and the QMSR

Does 21 CFR Part 820 still exist?

Yes. The regulation number 21 CFR Part 820 did not change. The QMSR is the updated version of Part 820, published under the same citation. References to “21 CFR Part 820” after February 2, 2026 refer to the QMSR.

When did the QMSR become mandatory?

February 2, 2026. The final rule was published on February 2, 2024, and the two-year transition period ended on the effective date. FDA inspections conducted on or after that date assess compliance with the QMSR, not the old QSR.

Do I need ISO 13485 certification to comply with the QMSR?

No. ISO 13485 certification from a third-party body is voluntary. The QMSR incorporates ISO 13485:2016 requirements by reference as the substantive content of the regulation. You must meet those requirements, but the FDA does not require a third-party certificate.

What happened to the QSIT inspection process?

The Quality System Inspection Technique (QSIT) was withdrawn on February 2, 2026. FDA device inspections now follow the updated Compliance Program 7382.850.

Can FDA now inspect my internal audit records?

Yes. The exemption that previously protected internal quality audits, supplier audits, and management review reports from FDA inspection was eliminated under the QMSR. These records are now subject to review during FDA device inspections.

Conclusion

The QMSR kept the same regulation number but changed the underlying framework in ways that matter for daily quality operations. ISO 13485:2016 is now legally embedded in 21 CFR Part 820. Internal audits and management reviews are fully visible to FDA investigators. A new inspection process governs how those investigations unfold.

Manufacturers with well-documented quality systems built on ISO 13485 are in a strong position. Those whose quality systems were structured around the minimum QSR requirements have more work ahead, particularly in supplier qualification, audit documentation, and risk management.

The practical path forward is a documented gap analysis against QMSR requirements, followed by a systematic plan to close the identified gaps before your next FDA inspection visit. An eQMS like Cloudtheapp makes that process faster and gives you the documentation infrastructure to sustain it.

Request a demo to see how Cloudtheapp supports QMSR compliance

This post created by and appeared first on Cloudtheapp