Webinar: From Paper to eIFU: Preparing for the Next Global Step in Medical Device Compliance

Register now

Medical Device Design Control: A Complete Guide to ISO 13485 & FDA Requirements

Design control is the foundation of medical device regulatory compliance. Under FDA 21 CFR Part 820.30, every manufacturer must establish and maintain procedures for the planning, implementation, and control of the design of each device. ISO 13485:2016 Section 7.3 contains equivalent requirements. Design control is not a one-time compliance exercise—it is a structured process that must be applied to new device designs, design modifications, and design changes throughout the device's lifecycle.

The purpose of design control is to ensure that devices are designed to meet user needs, are safe and effective, can be reliably manufactured, and comply with regulatory requirements. When design control is weak or incomplete, devices may fail in the field, patients may be harmed, and the manufacturer faces recalls, warning letters, and potential legal liability. Conversely, well-executed design control demonstrates to regulators and customers that the device was developed systematically with appropriate risk management and verification.

What Is Design Control and Why Is It Mandatory?

Design control is the process of systematically planning, developing, testing, and verifying a medical device design before it is released for manufacturing and distribution. It requires defining what the device must do (design inputs), determining how the device will work (design outputs), verifying that the outputs meet the inputs (design verification), validating that the device works in actual use conditions (design validation), and ensuring that the design can be reliably manufactured (design transfer). This end-to-end approach ensures that no critical requirement is overlooked and that each design decision is documented and traceable.

The FDA considers design control to be essential to device safety and effectiveness. Products developed without formal design control are at high risk for design defects, unintended uses, or manufacturing problems that emerge after commercialization. During inspections, the FDA specifically examines design control documentation to assess whether the manufacturer has a disciplined, documented process for device development.

Design Control Under 21 CFR Part 820.30 and ISO 13485 Section 7.3

Both FDA and ISO 13485 regulations require design control, and the underlying principles are nearly identical, though FDA regulations are more prescriptive. FDA's 21 CFR 820.30 specifies eight design control elements that must be addressed: design planning, design inputs, design outputs, design reviews, design verification, design validation, design transfer, and design changes. ISO 13485 uses similar concepts but grants manufacturers more flexibility in how they structure and document their process.

For manufacturers seeking compliance with both standards—which includes most companies that export internationally—FDA's prescriptive approach provides a good roadmap. A design control process that satisfies FDA's eight elements will typically satisfy ISO 13485 requirements. The key is that the manufacturer must document the approach, show that it was followed, and maintain complete records.

The Eight Elements of the Design Control Process

1. Design and Development Planning

Design control begins with planning. A design plan (also called a design protocol or design plan document) must establish the scope of the design project, identify the team members and their responsibilities, define the design timeline and milestones, specify the risk management approach that will be used, and establish design control procedures that will be followed. The plan should also define the design inputs, design review schedule, verification and validation strategies, and the criteria for design transfer. The design plan is the roadmap that ensures all stakeholders understand the approach and that no design step is skipped.

2. Design Inputs

Design inputs are the documented requirements that the device must meet. These include functional requirements (what the device must do), performance requirements (how well it must do it), safety and regulatory requirements (what standards and regulations apply), and user needs (what problems does the device solve). Design inputs must be documented in clear, measurable, and unambiguous language. Requirements that cannot be measured or verified should be refined until they are objective. Design inputs must also be reviewed and approved by qualified individuals before design development begins.

3. Design Outputs

Design outputs are the results of design development—drawings, specifications, software code, and procedures that define how the device is constructed and what it does. Every design output must be reviewed and approved before it is used. Critically, design outputs must be traceable back to design inputs, meaning that each design output can be linked to the input requirement it addresses. This traceability ensures that all requirements are met and that there are no design outputs that are not supported by a requirement.

4. Design Reviews

Formal design reviews are required at appropriate stages of development—typically at least at the conceptual design, design development, and pre-commercialization stages. Design reviews are meetings where the design team presents their work to qualified reviewers who assess whether the design is technically sound, meets all requirements, addresses identified risks, and is ready for the next phase. Design reviews must include participants from multiple disciplines (design, quality, manufacturing, regulatory) and must be documented with minutes, issues identified, and resolution plans.

5. Design Verification

Design verification confirms that the design outputs (drawings, specifications, code) correctly implement the design inputs (requirements). Verification answers the question: Did we build what we said we would build? Verification activities include testing prototypes, simulating performance, reviewing calculations, and analyzing designs against specifications. Verification must demonstrate that the design outputs are correct and that any assumptions made during design are valid.

6. Design Validation

Design validation confirms that the device, as manufactured, will perform safely and effectively in actual use conditions. Validation answers the question: Does this device do what it is intended to do, and is it safe to use? Validation typically includes human factors testing, biocompatibility testing, sterilization validation, shelf-life testing, electrical safety testing, and clinical trials or performance testing in representative use conditions. Unlike verification, which tests against specifications, validation tests the actual manufactured device in real-world scenarios.

7. Design Transfer

Design transfer is the process of moving the design from development into manufacturing. It ensures that manufacturing can reliably produce the device to the design specifications established during development. Design transfer includes scaling from prototype to full production, validating manufacturing processes, qualifying suppliers, training manufacturing personnel, and establishing acceptance criteria for manufactured devices. Design transfer is complete when manufacturing can consistently produce devices that meet design specifications with documented evidence.

8. Design Changes

After commercialization, design changes may be necessary for improvements, corrections, or responses to field issues. Every design change must go through a change control process that documents the reason for the change, assesses the impact on safety and effectiveness, determines what re-testing or re-validation is needed, and ensures that all affected documentation is updated. Design changes must be evaluated using the same rigor as the original design, not as shortcuts.

Design Control Documentation: What You Need to Maintain

Design control requirements mandate maintaining a Design History File (DHF) that documents the entire design and development process. The DHF must contain all design control records, from initial planning through design transfer and into post-market phase. Key documents that must be included in the DHF are listed below. These documents must be organized, indexed, and maintained with appropriate version control and approval records.

  • Design plan or protocol defining the design development approach and responsibilities

  • Design input specifications with documented approval

  • Design output documentation (drawings, specifications, software code, algorithms) with traceability to design inputs

  • Risk management file demonstrating that design hazards have been identified and controls implemented

  • Design review meeting minutes, including pre-design, interim, and final reviews

  • Design verification test plans, test reports, and results

  • Design validation protocols, testing results, and biocompatibility/sterilization/clinical data

  • Design transfer records showing that manufacturing can reliably produce the device

  • Design change records for any modifications made after initial commercialization

  • 21 CFR Part 820.30 vs. ISO 13485 Section 7.3: Key Differences

While both FDA and ISO 13485 require design control, there are some notable differences in how each regulation frames the requirements. FDA regulations are more prescriptive, explicitly naming the eight design control elements and requiring that manufacturers address each one. FDA also explicitly requires that design changes be addressed with the same rigor as the original design. ISO 13485 uses more general language, requiring that manufacturers establish procedures for design and development but allowing more flexibility in how the process is structured.

A second difference is terminology: FDA uses the term 'Design History File' (DHF) while ISO 13485 refers to 'design and development records.' The concept is equivalent—both require comprehensive documentation of the design process. FDA regulations also more explicitly address design transfer, human factors, and software as medical device components, though ISO standards cover these through referenced standards (IEC 62304 for software, ISO 14971 for risk management).

Practically speaking, a design control process that complies with FDA's eight elements and maintains a comprehensive DHF will satisfy ISO 13485 requirements as well. Many international device manufacturers use FDA requirements as their baseline, as FDA's prescriptive approach leaves no ambiguity about what must be done.

Most Common Design Control Failures in FDA Inspections

The FDA has published guidance on the most frequently observed design control deficiencies during facility inspections. One of the most common findings is inadequate design input documentation. Some manufacturers document their design inputs informally, fail to obtain approval before design begins, or do not clearly define performance requirements in measurable terms. Without clear, approved design inputs, it is impossible to verify that the device design is correct.

A second major deficiency is incomplete design verification and validation. Some companies conduct only limited testing, skip validation in actual use conditions, or conduct verification and validation only on early prototypes rather than on production-representative devices. FDA expects that design verification confirms the design is correct and that design validation demonstrates the device works as intended in representative use conditions.

  • Design inputs not documented, not approved, or stated in vague, unmeasurable language

  • No traceability between design inputs and design outputs, making it unclear which requirements are met by the design

  • Design reviews conducted informally without documented minutes, attendance records, or resolution of identified issues

  • Design verification limited to prototype testing without evidence that production devices continue to meet specifications

  • Design validation not conducted in actual use conditions or with representative users

  • Risk management not integrated into design control; hazards identified but not linked to design requirements and controls

  • Design changes not subjected to the same rigor as original design; changes made without impact assessment or re-testing

💡 Best practice: Treat design control as a process, not a documentation exercise. Engage the full development team—design, quality, manufacturing, and regulatory—in each design stage. Document decisions as they are made, not months later. Maintain clear traceability between design inputs, outputs, verification, and validation so that inspectors can quickly understand your design reasoning.

The challenge
How Matrix Req Helps

Request a demo and get started today.

See how Matrix Req connects your requirements, risks, tests, and documentation in one platform.

Request A Demo Today
DE
USUnited States
GBUnited Kingdom
FRFrance
AUAustralia
DEGermany
ESSpain
AFAfghanistan
ALAlbania
DZAlgeria
ASAmerican Samoa
ADAndorra
AOAngola
AIAnguilla
AGAntigua and Barbuda
ARArgentina
AMArmenia
AWAruba
ATAustria
AZAzerbaijan
BSBahamas
BHBahrain
BDBangladesh
BBBarbados
BYBelarus
BEBelgium
BZBelize
BJBenin
BMBermuda
BTBhutan
BOBolivia
BABosnia and Herzegovina
BWBotswana
BRBrazil
IOBritish Indian Ocean Territory
VGBritish Virgin Islands
BNBrunei Darussalam
BGBulgaria
BFBurkina Faso
BIBurundi
KHCambodia
CMCameroon
CACanada
CVCape Verde
KYCayman Islands
CFCentral African Republic
TDChad
CLChile
CNChina
CXChristmas Island
CCCocos (Keeling) Islands
COColombia
KMComoros
CGCongo
CDThe Democratic Republic of the Congo
CKCook Islands
CRCosta Rica
CICote d'Ivoire
HRCroatia
CUCuba
CYCyprus
CZCzech Republic
DKDenmark
DJDjibouti
DMDominica
DODominican Republic
ECEcuador
EGEgypt
SVEl Salvador
GQEquatorial Guinea
EREritrea
EEEstonia
ETEthiopia
FKFalkland Islands
FOFaroe Islands
FJFiji
FIFinland
GFFrench Guiana
PFFrench Polynesia
GAGabon
GMGambia
GEGeorgia
GHGhana
GIGibraltar
GRGreece
GLGreenland
GDGrenada
GPGuadeloupe
GUGuam
GTGuatemala
GGGuernsey
GNGuinea
GWGuinea-Bissau
GYGuyana
HTHaiti
HNHonduras
HKHong Kong
HUHungary
ISIceland
INIndia
IDIndonesia
IRIran
IQIraq
IEIreland
IMIsle of Man
ILIsrael
ITItaly
JMJamaica
JPJapan
JEJersey
JOJordan
KZKazakhstan
KEKenya
KIKiribati
KWKuwait
KGKyrgyzstan
LALao People’s Democratic Republic
LVLatvia
LBLebanon
LSLesotho
LRLiberia
LYLibya
LILiechtenstein
LTLithuania
LULuxembourg
MOMacau
MKMacedonia
MGMadagascar
MWMalawi
MYMalaysia
MVMaldives
MLMali
MTMalta
MHMarshall Islands
MQMartinique
MRMauritania
MUMauritius
YTMayotte
MXMexico
FMMicronesia
MDMoldova
MCMonaco
MNMongolia
MEMontenegro
MSMontserrat
MAMorocco
MZMozambique
MMMyanmar
NANamibia
NRNauru
NPNepal
NLNetherlands
NCNew Caledonia
NZNew Zealand
NINicaragua
NENiger
NGNigeria
NUNiue
NFNorfolk Island
KPNorth Korea
MPNorthern Mariana Islands
NONorway
OMOman
PKPakistan
PWPalau
PSPalestine
PAPanama
PGPapua New Guinea
PYParaguay
PEPeru
PHPhilippines
PLPoland
PTPortugal
PRPuerto Rico
QAQatar
REReunion
RORomania
RURussia
RWRwanda
BLSaint Barthelemy
SHSaint Helena
KNSaint Kitts and Nevis
LCSaint Lucia
MFSaint Martin
PMSaint Pierre and Miquelon
VCSaint Vincent and the Grenadines
WSSamoa
SMSan Marino
STSao Tome and Principe
SASaudi Arabia
SNSenegal
RSSerbia
SCSeychelles
SLSierra Leone
SGSingapore
SKSlovakia
SISlovenia
SBSolomon Islands
SOSomalia
ZASouth Africa
KRSouth Korea
LKSri Lanka
SDSudan
SRSuriname
SJSvalbard and Jan Mayen
SZSwaziland
SESweden
CHSwitzerland
SYSyria
TWTaiwan
TJTajikistan
TZTanzania
THThailand
TLTimor-Leste
TGTogo
TKTokelau
TOTonga
TTTrinidad and Tobago
TNTunisia
TRTurkey
TMTurkmenistan
TCTurks and Caicos Islands
TVTuvalu
VIU.S. irgin Islands
UGUganda
UAUkraine
AEUnited Arab Emirates
UYUruguay
UZUzbekistan
VUVanuatu
VAHoly See (Vatican City State)
VEVenezuela
VNVietnam
WFWallis and Futuna
YEYemen
ZMZambia
ZWZimbabwe

Thank you

A member of our team will be in contact within 48 hours.


Stay up to date with our latest success stories.

Take a look at how Limbus AI cuts time to market with their innovative deep-learning solution for CT contour delineation.

Read the customer story