FDA Design Controls for Device Teams: Turn 820.30 Into QMSR Records

FDA design controls are the documented processes in 21 CFR 820.30, now carried into the QMSR, that prove a device meets user needs and its intended use. They apply to Class II and III devices and listed Class I devices. Your first move is to create or confirm a design and development plan, start or update the Design History File, and run a QMSR gap analysis on any marketed device.

Key Takeaways

Implementing comprehensive design controls aligned with FDA requirements and ISO 13485 is essential for device safety, regulatory compliance, and efficient development processes.

Table of Contents

• What does 21 CFR 820.30 require under the QMSR?
• How do you run the design and development stages?
• What is the difference between design verification and validation?
• What belongs in the design history file, and how do you control changes?
• How do you prepare for an FDA inspection after the QMSR transition?
• What role do design controls play when you change a design during iterative prototyping?
• How do you integrate suppliers and subcontractors into design controls?
• What are the best practices for design control documentation in rapid prototyping and additive manufacturing?
• How do design controls affect time-to-market, and how can you keep timelines short?
• How should you handle electronic systems and 21 CFR Part 11 for design control records?
• What practical workflow keeps design controls manageable for engineers?
• How can we support your verification and validation builds?
• FAQ
• Sources

What does 21 CFR 820.30 require under the QMSR?

The regulation lists the elements every in-scope manufacturer must put in place. FDA’s PMA quality system page summarizes them:

• A procedure that controls the design of the device
• Design and development planning
• Design inputs and design outputs
• Design review
• Design verification and validation, including software validation and risk analysis where appropriate
• Design transfer and design changes
• A design history file

The QMSR changes the framework around these elements. FDA says the QMSR incorporates ISO 13485:2016 by reference, emphasizes risk management throughout design and development, and took effect on February 2, 2026. FDA staff describe the aim as aligning U.S. requirements with ISO 13485 while keeping the assurance level substantively similar to the legacy system. Nothing in the background guidance suggests you must rewrite legacy files to insert ISO references, but you should expect inspectors to read them.

When you cite requirements in an internal review, use the e-CFR text of §820.30 and the FDA’s own QMSR pages rather than secondhand summaries. The standard itself is listed on the ISO website.

How do you run the design and development stages?

Treat each stage as a producer of one or two specific records. The sequence below keeps work traceable from the first plan to the transfer package.

1. Plan. Record who is responsible for each activity, which groups interface with each other, and the milestones where reviews happen. Update the plan as the design evolves.
2. Define inputs. Inputs must address intended use and user needs and be documented and approved. Write each one so a test can pass or fail it: a defined drop test beats “is durable.”
3. Define outputs. Under the regulation, outputs reference acceptance criteria. Drawings, specifications and software builds should each point to the input they satisfy.
4. Hold design reviews. Schedule them at defined points, include relevant functions and an independent reviewer, and minute the date, attendees, issues raised and owners for follow-up.
5. Transfer. Confirm that production specifications match the approved outputs before manufacturing begins.

Pro Tip: Number every input once, and cite that number in each output, test protocol and risk item. Renumbering later is where traceability breaks.

What is the difference between design verification and validation?

Verification asks whether the output meets the input: did we build the device right? Validation asks whether the device meets user needs and its intended use: did we build the right device? A torque test showing a connector holds the specified load is verification. A simulated-use study in which clinicians complete a procedure with the device is validation.

The rule text requires validation under defined operating conditions on initial production units, lots or batches, or their equivalents. If you test equivalents, document why they represent production, covering material, process and geometry. Software validation and risk analysis are required where appropriate, so state in the file how you decided what was appropriate.

Format records so a reviewer can follow the chain without you:

• Each report names the input it addresses and the protocol it executed
• Acceptance criteria appear in the protocol before testing, not after
• Deviations and retests are recorded, not overwritten

Why it matters: FDA’s own history shows design problems were a leading cause of recalls, which is why these controls exist in the first place.

What belongs in the design history file, and how do you control changes?

The DHF must demonstrate that the design followed the approved plan. Under the QMSR, FDA also expects a design and development file for each device type or family. The file can be a single binder, multiple volumes or an indexed set of references, as long as a reviewer can reach every record. Its practical value is institutional memory when people leave.

Include or reference these records:

• Design and development plan
• Design inputs and outputs
• Design review minutes
• Verification and validation protocols and reports
• Risk management file
• Design transfer records
• Change records

FDA’s risk presentation lists typical artifacts: a risk management plan, analysis report, evaluation summary and traceability matrix.

Changes follow a fixed path: identify the change, document it, review it, approve it, then implement it. The regulation requires that changes be identified, documented, reviewed and approved before implementation. Assess each change for its effect on risk and on prior verification and validation, and record which tests you repeated and why.

How do you prepare for an FDA inspection after the QMSR transition?

On February 2, 2026, FDA withdrew QSIT and began using a new inspection process, Compliance Program 7382.850, aligned to the QMSR. According to FDA’s QMSR FAQ, inspectors may review records created before that date, and the agency recommends gap analyses of legacy files. Expect requests for the DHF, risk management files, verification and validation evidence, software validation evidence and design plans.

A gap analysis should compare your existing design files against the QMSR’s ISO 13485 clause structure and its risk emphasis, and list what is missing or unclear. Work through this checklist in priority order:

1. Confirm every in-scope device has a current design and development plan.
2. Pull each DHF and check that it is indexed and complete.
3. Verify that risk files link to inputs, tests and changes.
4. Check that closed design reviews have signed minutes.
5. Confirm software validation records exist where software is part of the device.
6. Run a mock walkthrough: ask a team member to trace one requirement to its test and risk item.

Pro Tip: Do the mock walkthrough with someone who did not work on the device. Gaps that insiders skip over are the ones an inspector finds.

What role do design controls play when you change a design during iterative prototyping?

Prototype iteration is where design control discipline either pays off or collapses. Design controls begin after feasibility work and before premarket activities, as FDA’s training material explains, so early builds can be loose. Once the design is under control, every revision to inputs, outputs or test methods needs a recorded reason and an approval, even when the change is small and the build takes an afternoon.

The practical goal is to separate exploratory builds from builds that generate evidence. Label each prototype with its purpose and revision. A build used only to check fit needs a note; a build used for verification needs a release against a specific revision of the drawings, and the file must show which revision was tested.

When a change lands, ask three questions. Which inputs or outputs does it touch? Which prior verification results are now stale? Does it alter any risk item? Record the answers in the change record, not in email. Teams that skip this step find, months later, that a verification report describes a geometry that no longer exists.

Iteration also feeds the next review. A short summary of what changed since the last review, drawn from the change log, keeps formal reviews fast and the minutes meaningful. Our guide on the role of prototyping in medical devices covers how early builds support verification and validation planning.

How do you integrate suppliers and subcontractors into design controls?

Supplier work can affect a controlled design, so consider supplier controls as part of the design process. Start by deciding which design outputs depend on outside work: machined components, printed parts, molded housings, coatings, test services. For each, the drawing or specification is a design output, and it must reference acceptance criteria.

Give suppliers what they need to meet those criteria:

• The current released revision of the drawing and specification, and nothing else
• Critical-to-function dimensions and material callouts, flagged as such
• Inspection requirements and the form of the inspection report you expect
• A rule that no process or material change happens without your written approval

Treat the supplier’s inspection data as input to verification evidence. When a verification lot is built by a subcontractor, keep the build records, material certificates and inspection reports with the DHF or reference them from it. At design transfer, confirm the supplier can reproduce the approved outputs at production conditions.

Change control extends outward too. A supplier switching resin lots, tooling or machine type can invalidate prior testing. Make notification a contractual term and route each notice through your change process. If you qualify a vendor for prototype runs, document the qualification basis so it is clear why test articles represent production. Our guide to designing for manufacturability helps translate outputs into reducible specifications before they reach a supplier.

What are the best practices for design control documentation in rapid prototyping and additive manufacturing?

Additive builds raise a documentation question conventional parts rarely do: the process itself shapes the material. Layer orientation, build parameters, powder or resin lot, post-processing and curing can all change performance, so the file should capture them for every build that generates evidence.

A workable record for each verification build includes:

• Machine, software version and parameter set
• Material and lot identifier, plus any reuse of powder or resin
• Part orientation and position in the build
• Post-processing steps, such as support removal, thermal treatment and finishing
• Inspection results tied to the part serial or build identifier

Lock the process before you verify against it. If the parameter set changes after testing, treat that as a design or process change and assess whether results still apply. When you justify using printed parts as equivalents of production units, write down the comparison: same material family, same critical dimensions, same finishing, and an explanation of any differences.

Keep the records lightweight by using templates. One build traveler, one inspection form and one equivalence memo, reused across builds, are easier to audit than bespoke documents. Link each to the input it supports. Our additive manufacturing workflow guide walks through planning production-equivalent prototypes, and our Class I prototype audit guide covers quick preparation steps for inspections.

How do design controls affect time-to-market, and how can you keep timelines short?

Design controls add documentation work, but the cost is front-loaded and predictable, while the cost of skipping them shows up as rework, failed reviews and retested devices. The schedule risk lives in three places: ambiguous inputs that force late redesign, verification run on unreleased or unrepresentative parts, and change records reconstructed after the fact.

Shorten the path by sequencing decisions deliberately:

• Write testable inputs first. Time spent here prevents arguments during verification.
• Plan verification and validation early. Decide test methods and sample sizes while the design is still flexible, so you order the right test articles once.
• Build representative parts for evidence runs. Parts that do not represent production invite repeat testing.
• Run reviews on a calendar. Fixed review dates stop decisions from drifting.
• Maintain the DHF as you go. Weekly filing is faster than a pre-submission scramble.

For prototype and production runs, parallelize where the risk allows: start transfer planning and supplier qualification while validation is underway, and keep a single change log so nothing waits on a missing approval. Risk-based thinking, which the QMSR emphasizes across design and development, also helps you spend effort where severity and probability are highest rather than documenting everything equally.

The fastest teams treat the DHF as a working index of what they are already doing, not a separate deliverable. That habit costs little per week and removes the largest source of late delay.

How should you handle electronic systems and 21 CFR Part 11 for design control records?

Many teams keep the DHF in a document management system, a product lifecycle tool or a quality platform. That is acceptable, but the system becomes part of your compliance posture. 21 CFR Part 11 governs electronic records and electronic signatures, so check how your system handles them, and confirm the details against the current regulation text rather than relying on this summary.

Questions to settle before relying on a system for design controls:

• Can you show who created or changed a record, when, and what changed?
• Are approvals tied to individual, uniquely identified signers?
• Are released documents locked, with revisions controlled?
• Can you retrieve complete records, including legacy ones, during an inspection?
• Is the tool validated for its intended use, with the depth of validation matched to the risk?

Spreadsheets and shared drives are the usual weak points. Files without revision control, overwritten test data and approvals by email are hard to defend. If you use them for interim work, move final records into the controlled system at release.

Plan the structure of the electronic DHF around traceability: requirement, output, test, risk item and change should link to each other, so an inspector can start from any one and reach the rest. Since the QMSR expects a design and development file per device type or family, organize folders or records the same way. Backup, access control and a defined retention approach round out the setup.

What practical workflow keeps design controls manageable for engineers?

Keep one thread running from requirement to test to risk item, and resist adding paperwork beyond it. Give each requirement an identifier, attach the verification test that proves it, and link any hazard it mitigates. A single traceability matrix maintained weekly beats a dozen documents assembled at the end.

Bring manufacturing and prototyping partners into verification and validation planning early. They can tell you whether a build will behave like production before you spend on testing. And here is the tip I would give any team: end every sprint or build cycle with a brief DHF update, filing what was tested, what changed and what was decided. Audit friction almost always traces back to records written from memory.

— Nas

How can we support your verification and validation builds?

When your verification and validation plan calls for production-equivalent test articles, we can build them. Our team produces prototypes and small runs using available manufacturing processes.

• 3D printing in SLA, SLS, FDM, MJF and DMLS for functional test articles
• CNC machining for precision metal and plastic components
• Injection molding for production-representative parts
• Medical device prototyping support from first article to low-volume runs

Send us your drawings and test specification, and request a quote at Wjprototypes. We will work with you on materials, finishes and quantities that fit your protocol.

This article is general information, not a substitute for advice from a qualified doctor. Consult a qualified healthcare professional about your own circumstances before acting on anything here.

FAQ

What are the FDA guidelines for design control?

The core requirements are in 21 CFR 820.30: design planning, inputs, outputs, review, verification, validation, transfer, changes and a design history file. FDA also publishes a design controls guidance document explaining its expectations for each element. Since the QMSR took effect, these requirements sit alongside ISO 13485 alignment.

What are the FDA’s new regulations for 2026?

The main change is the Quality Management System Regulation, which became effective on February 2, 2026 and incorporates ISO 13485:2016 by reference. FDA also began inspecting under a new compliance program aligned to the QMSR, as described in its QMSR FAQ.

Is 21 CFR 820 still valid?

The design control requirements remain relevant, and FDA keeps the regulation text online through its CFR database. Because the QMSR changed the surrounding framework, confirm current clause references directly in the code before citing them in procedures.

Does ISO 13485 cover design controls?

Yes. ISO 13485:2016 includes design and development requirements, and FDA states that the QMSR’s design and development requirements align with ISO 13485 clause references. Manufacturers should map their procedures to both the ISO clauses and the QMSR text.

Sources

• PMA Quality System | FDA
• 21 CFR § 820.30 - Design controls. | Electronic Code of Federal Regulations (e-CFR) | US Law | LII / Legal Information Institute

Recommended

• Make FDA Class I Prototypes Audit Ready in the U.S. With One Page
• Prototype QA Guide: Aerospace, Automotive, And Medical
• How to Design for Manufacturability: Engineer’s Guide