Design controls (21 CFR 820.30) are an interrelated set of practices and procedures that are incorporated into the design and development process to manage design inputs, outputs, verification, validation, transfer, and changes. Design controls usually run through a design and development plan, design inputs (user needs turned into requirements), design outputs (drawings, specifications, software), design reviews, verification, validation, design transfer to production, and change control. Traceability between these elements is key evidence in submissions and inspections. Since the QMSR took effect on February 2, 2026, FDA enforces design controls through ISO 13485:2016 as incorporated by reference in 21 CFR Part 820, so the old section numbers are now historical. Requirements now sit in ISO 13485 clause 7.3.

Why it matters

Design controls are required for almost all Class II and Class III devices and for select Class I devices listed in 21 CFR 820.30(a)(2). They form the audit trail (design history file) used by FDA, Notified Bodies, and internal auditors to evaluate design quality. Under QMSR (effective February 2026), design controls are preserved and aligned with ISO 13485 clause 7.3. The typical elements are: design and development planning, design inputs, design outputs, design review, verification, validation, transfer, and changes, with a design history file (DHF) collecting the evidence.

Common pitfalls

•Treating verification and validation as interchangeable. Verification confirms outputs meet inputs; validation confirms the device meets user needs in its intended environment.
•Weak design inputs. Vague or unmeasurable inputs make verification impossible and are one of the most common Form 483 observations.
•Skipping formal design reviews or performing them without an independent reviewer, which invalidates the review evidence under 820.30(e).
•Poor design change control. Every post-transfer change requires evaluation, verification/validation as appropriate, and documentation before implementation.

Sources

Open full page

Select term B to compare.

Why compare MedTech terms side by side?

MedTech terminology is full of pairs that look interchangeable but carry very different regulatory, clinical, and commercial consequences. Picking the wrong framework, pathway, or standard early in a project can add months to a submission, invalidate clinical evidence, or trigger an audit finding. Side-by-side comparison is the fastest way to surface those differences before they become costly mistakes.

Each comparison on this page pulls from the same vendor-neutral, sourced definitions used throughout the MedTech Terms glossary. You see the one-line summary, the formal definition, why it matters in practice, common pitfalls, and the primary sources (FDA guidance, EU MDR/IVDR articles, ISO/IEC standards, MDCG documents, IMDRF principles) that back each entry. That makes the comparison defensible in regulatory strategy memos, design reviews, and submission narratives.

Common comparison patterns

Regulatory pathway choice - 510(k) vs PMA, 510(k) vs De Novo, Abbreviated vs Special 510(k).
Quality systems - QSR vs ISO 13485, QMSR vs QSR.
Software classification - SaMD vs SiMD, Locked vs adaptive AI.
EU frameworks - MDR vs IVDR, CE Mark vs UKCA.
Cybersecurity artifacts - SPDX vs CycloneDX SBOM, CVE vs CVSS.
Post-market actions - Recall vs field action, Removal vs correction.

How to use this tool

Pick term A and term B from the dropdowns, or click a preset above. The URL updates with both slugs so you can bookmark or share the exact comparison with a colleague, a notified body reviewer, or your regulatory consultant. Click Open full page on either side for the complete entry, including FAQs, related terms, and the full citation list. If you are not sure which term to start with, browse the Categories view or the A-Z index.

MedTech Terms is a vendor-neutral community resource sponsored by Blue Goat Cyber. Definitions are written for educational use and are not legal or regulatory advice.