The Ultimate Guide To Design Controls For Medical Device Companies

Design controls are the structured quality processes medical device companies use to plan, define, review, verify, validate, transfer, and change a device design before and after release. They create traceability from user needs and intended use through design inputs, design outputs, verification, validation, design transfer, and the design history file.

For medical device manufacturers, design controls are not just product-development best practices. They are regulatory quality system expectations that help prove the device was developed through a controlled process and that design decisions are documented, reviewed, tested, and connected to safety and performance requirements.

Design controls vs product development: the seven stages and their ISO 13485 clauses

Product development is the broader process of creating a medical device. Design controls are the regulated quality system activities that make that development process traceable, reviewable, and compliant. Under the QMSR, each stage maps to ISO 13485 clause 7.3:

1. Design and development planning (7.3.2): Define the project scope, responsibilities, deliverables, review points, and required documentation.

2. User needs and intended use (feed 7.3.3 and 7.3.7): Document who the device is for, what problem it solves, and the conditions under which it will be used.

3. Design inputs (7.3.3): Translate user needs, regulatory requirements, risk controls, usability needs, and performance expectations into measurable requirements.

4. Design outputs (7.3.4): Document the specifications, drawings, software requirements, materials, labeling, and production information needed to build the device.

5. Design verification (7.3.6): Confirm the design outputs meet the approved design inputs.

6. Design validation (7.3.7): Confirm the finished device meets user needs and intended use under actual or simulated use conditions.

7. Design transfer and design changes (7.3.8, 7.3.9): Transfer the approved design into production and control future changes through documented review, approval, and traceability.

Design reviews (7.3.5) happen at planned points throughout, and the records go in the design and development file (7.3.10), still widely called the design history file.

What’s this guide about anyway?

Back in 1998, I started my career as a medical device product development engineer, when FDA Design Controls and ISO 13485 were still new to the industry and we all struggled to apply them. It took years before I understood their real purpose. Since then, I've helped get 40+ devices through regulatory clearance and, through founding Greenlight Guru, helped dozens of companies worldwide bring their products to market. Design Controls still confuses a lot of product developers, but if you have bad feelings about it, that's usually the process you're working within, not the concept itself. Design controls are simply what prudent developers do to prove their devices are safe, effective, and meet their indications for use. This guide breaks down what Design Controls are, how to address them, and how they apply to simple devices, complex devices, software as a medical device, risk management, traceability, and document-based processes. 

Design controls under FDA’s QMSR and ISO 13485

FDA’s Quality Management System Regulation (QMSR) took effect on February 2, 2026. It amends 21 CFR Part 820 and incorporates ISO 13485:2016 by reference, so U.S. design control requirements now sit in ISO 13485 clause 7.3, Design and development, and its subclauses. Under 21 CFR 820.10(c), they apply to all Class II and Class III devices and to certain Class I devices, including devices automated with computer software. Devices made under an investigational device exemption (IDE) are not exempt. Part 820 no longer has a standalone section 820.30, but the activities it covered carry forward under clause 7.3: planning, inputs, outputs, review, verification, validation, transfer, changes, and a design and development file. For the wider QMS picture, see our guides to 21 CFR Part 820 and ISO 13485.

What are Design Controls?

I will also share with you why Design Controls even matter and how they will help you during your medical device product development.

Design Controls - Comparing FDA and ISO

It is important that you design and develop a medical device that is safe. FDA, European Commission, Health Canada, and all other regulatory bodies throughout the world will want some assurances that your medical device is safe before you bring the product to market.

And this is really the essence of Design Controls. Proof that you have designed a safe product that meets user needs and requirements.

Design controls is the term FDA has used since its 1997 Quality System Regulation; ISO 13485 calls the same activities design and development (clause 7.3). Since February 2, 2026, 21 CFR 820.10(c) points U.S. manufacturers directly to clause 7.3.

In ISO 13485 speak, the terminology and intent is similar and covered in section 7.3 Design and Development.

Both FDA Design Controls regulations andISO 13485 Design & Development requirements expect you to keep documentation and records throughout the product development process.

The Design History File (DHF) is a great place to keep all of your Design Controls “evidence”.

Importance of Traceability

A traceability matrix links user needs, inputs, outputs, verification, and validation, and ISO 13485 clause 7.3.2 requires your plan to document how outputs trace to inputs. Spreadsheets work early but get harder to maintain as a project grows. See our traceability matrix guide.

Incorporate Risk Management

It is an expected best practice that you integrate Design Controls and Risk Management during your medical device product development efforts. For Risk Management, be sure your approach is up-to-date and aligns with ISO 14971.

The Definitive Guide to ISO 14971 Risk Management for Medical Devices

Design Controls are intended to demonstrate that a medical device has been:

1. Designed to address the needs of users and patients.
2. Designed to meet inputs and requirements.
3. Proven to meet applicable standards.
4. Meets performance criteria.

Your Design Controls will prove that your medical device is safe for use.

Does this sound like Risk Management?

The intent behind Risk Management is to identify, evaluate, analyze, assess, and mitigate potential product issues.

There is a very strong correlation and relationship between Design Controls and Risk Management.

With Design Controls, you also identify, evaluate, analyze, assess, and mitigate potential product issues.

Design Controls and Risk Management address design, development, and manufacturing of medical devices from slightly different perspectives.

Risk Management & Design Controls Must Be Linked

The best practices of medical device product development have a good flow between Design Controls and Risk Management.

For example, as you identify hazards and hazardous situations, these should “feed” into the Design Controls process in defining User Needs and Design Inputs.

When you evaluate risks, you will need to establish Risk Controls to mitigate and reduce risks. Design Outputs, Design Verifications, and Design Validations become these risk controls.

In fact, using Risk Management as a real tool will help you with Design Verification and Design Validation planning. Let me explain.

Risk Controls are used to help identify ways to reduce the risks. Your Risk Controls should align with and include Design Verification and Design Validation activities.

Are you starting to see how closely related Risk Management and Design Controls should be?

The QMSR makes this link explicit: it now specifically requires risk management, including in design and development planning (clause 7.1). See our ISO 14971 guide.

Product Development Process Methodology / Approach

I often hear that the Design Controls requirements are often restrictive and require a phase / stage-based approach (some refer to this as “waterfall”) for the product development process.

Let me set the record straight.

FDA does not mandate a waterfall approach for medical device product development and capturing Design Controls. In fact the FDA Design Control Guidance, a historical document published in 1997, is very clear about the iterative nature during device development.

I bring this up largely because of the current popularity of “agile” methodology for product development, especially with complex devices and software as a medical device (SaMD).

For example, the image below is the “V-model” described in IEC 62304, a standard that describes software life cycle product development processes.

IEC 62304 Medical device software: Software life cycle processes

Figure C.2: Software as part of the V-model

Note, the v-model describes a product development methodology and approach.

Regardless of product development methodologies and approaches used, demonstrating Design Controls as defined by FDA and ISO 13485 are still a requirement.

Maintaining a Design History File

Your Design History File (DHF) should stay organized, accessible, and separate from your general project files throughout development, not something you piece together retroactively before an audit or submission. How you store it matters: paper systems and general-purpose tools like Excel or shared drives tend to break down as a project grows, leading to missing documents, version control headaches, and lost approval signatures, so it's worth choosing a storage approach deliberately rather than letting it happen by default. 

Why capturing User Needs sets the stage

Remember when you had the idea for your new medical device, you came up with this wonderful product because you want to address unmet clinical needs. There are two terms that you should understand:  intended use and indications for use.

Intended Use is the general purpose of the medical device or its function (what you “claim” the medical device does)

Indications for Use describe the disease or condition the medical device will diagnose, treat, prevent, cure, or mitigate, including a description of the target patient population

First, intended use is EXACTLY what your product is used for. Don’t focus on what it COULD be used for. Rather, define exactly what it is in as few words as possible.

Second, your indications for use statement describes the precise situations and reasons where and why you would use this device. Again, being very clear and definitive here is extremely important.

“They think they understand what intended use means, but they really don’t…Intended use is all about what we say this device is to be used for, and indications for use is under what circumstances or under what conditions you would use that particular product.” says Mike Drues.

All of this relates to the User Needs for your medical device and are part of Design Controls.

Now you can do a lot of digging to try to get a better understanding of what User Needs really are. FDA doesn’t really define User Needs in its design control requirements per se. User Needs are shown kicking off the Design Controls process in the classic “waterfall diagram”

The classic Design Controls diagram should be viewed as a means to describe the relationship between Design Controls elements. As discussed earlier, this does not mean your medical device product development methodology has to be “waterfall” in nature.

The best place, aside from this guide, for you to get some insights about what User Needs are is the FDA Design Controls Guidance, a historical document.

And when you read the FDA guidance, just about every reference involving User Needs is tied directly to Design Validation. Validation proves your medical device meets User Needs and intended uses.

Documenting User Needs

Okay, so let me get into documenting User Needs. When documenting User Needs, think about your medical device product idea.

User needs describe how your medical device is going to be used. User needs help establish the framework for your medical device product design. Intended use describes the clinical issue your product addresses. Indications for Use pertain to clinical applications use, environment, and end user.

Here are some questions to help you better understand User Needs.

• What do you want it to do?
• Who is going to use it?
• When will it be used?
• What important features and attributes should be considered?
• How will the user and patient interact with the device?
• In what types of procedures will the device be used?
• In what type of environment will the device be used?
• When will the device be used?
• Is the device used one time or over and over?
• What other products will the device interact and interface with?

There likely are dozens and dozens more questions you need to ask.

And answer! Document your responses to all the questions.

Your responses become the information you should consider as the User Needs for your medical device idea, and included as part of your Design Controls.

Looking again at the waterfall diagram, you see that the proposed next major step after User Needs is Design Inputs. Logically, User Needs are the lead into Design Inputs.

And many medical device product development professionals will share with you how important Design Inputs are to the success of a new device.

Do not be too worried about whether or not your User Needs are exactly correct. Do not get too hung up on the format and wording.

Do realize that one day in the future, you will need to demonstrate that the product you develop addresses the User Needs you define.

The traceability matrix described earlier in this guide starts with the User Needs. User Needs feed into Design Inputs. Design Validation proves User Needs are met.

The purpose behind Design & Development Planning

In my experience, the topic of Design & Development Planning is very misunderstood. When most medical device product developers think about Design & Development Planning, the first thing that comes to mind is this:

Project schedule.

Since there is confusion about this, let me share what FDA and ISO state about Design & Development Planning.

ISO 13485:2016 7.3.2 Design and development planning

The organization shall plan and control the design and development of product. As appropriate, design and development planning documents shall be maintained and updated as the design and development progresses.

During design and development planning, the organization shall document:

1. a) the design and development stages;
2. b) the review(s) needed at each design and development stage;
3. c) the verification, validation, and design transfer activities that are appropriate at each design and development stage;
4. d) the responsibilities and authorities for design and development;
5. e) the methods to ensure traceability of design and development outputs to design and

development inputs;

1. f) the resources needed, including necessary competence of personnel.

Did you come across anything that suggests a project schedule? Or timeline?

Your product development schedule is definitely important. Don’t mishear me.

Remember where I shared some thoughts about product development versus Design Controls earlier in this guide?

Project schedule versus Design & Development Planning is in the same vein. Project schedule is a product development thing. Yet there is also a definite relationship with Design & Development Planning.

What goes into a Design & Development Plan?

Let me pick out the important aspects about Design & Development Planning from what FDA and ISO state about the topic:

• Identify Design & Development stages and activities
• Define responsibility for Design & Development activities
• Define the resources required; this includes project team members, as well as vendors
• Plans should evolve throughout Design & Development

A Design & Development Plan describes all the Design Controls, including when Design Reviews are expected. The plan describes who the team members are, including roles and responsibilities. The plan is not a “one and done” and needs to be revisited and updated throughout the project.

To help, here is a table listing the types of deliverables that should be expected and defined as part of your Design & Development Plan.

Understanding the role and importance of Design Reviews

Design Reviews are moments in time for you to evaluate the progress of your medical device project as it progresses through development.

During Design Reviews, you and the project team are formally reviewing -- and agreeing to -- Design Controls. This means your team will review and agree to your User Needs, Design Inputs, Design Outputs, Design Verifications, and Design Validations.

Design Reviews are also a time in a project to bring the team together in order to scrutinize and evaluate the state of the medical device and ensure that what needs to be done has been addressed.

How many? Who is involved?

How many Design Reviews does your medical device product development project need? This is a good question to ask. I do not have the answer for your project.

Here’s what I can tell you about Design Reviews.

How many Design Reviews to have depends on numerous factors. Factors like what the product is and who the players are need to be considered when determining the timing of Design Reviews.

The expectation is that your Design Review includes the right functions (engineering, marketing, manufacturing, etc.). Also, you need to include a resource who is independent.

When should Design Reviews happen?

All Design Controls must be included as part of a Design Review. As noted, I cannot for certain tell you exactly when to have Design Reviews. If you press me to provide a definitive response to this question, I will defer to what is suggested by the Design Controls waterfall diagram.

I will advise you to have a Design Review when User Needs are drafted.

I will advise you to have a Design Review after Design Inputs are established.

And after Design Outputs. After Design Verification. After Design Validation...and before going to full production.

But if you are following an agile product development process, this approach may not be ideal.

Design Reviews - the absolutes

Okay, let me be more helpful regarding Design Reviews.

First, you must have a record to prove that all Design Controls have been included as part of a Design Review.

Let me provide you with a few “rules” when it comes to Design Review:

1. Design Verification cannot happen until Design Outputs and Design Inputs are done.
2. Design Validation cannot happen until User Needs are done.
3. Design Transfer cannot happen until Design Outputs are done.

Free eBook: Click here to download a PDF version of the Ultimate Guide to Design Controls for Medical Device companies.

Design inputs: turning user needs into measurable requirements

Design inputs define the functional, performance, usability, and safety requirements of the device. They come mainly from user needs, plus standards, regulations, and risk controls. User needs can be subjective; inputs cannot, so write each one to be measurable and verifiable. See our guide to design inputs and outputs.

Defining how to make your medical device through Design Outputs

Design outputs are the recipe: the drawings, specifications, software, labeling, and work instructions needed to build the device, each traced to the input it satisfies. After transfer they become the core of the production records, which the former Part 820 called the device master record (DMR) and ISO 13485 calls the medical device file.

Proving you designed correctly via Design Verification

Design verification confirms outputs meet inputs: did you build the device right? Testing is most common, but inspection and analysis also count.

Proving you have the correct device via Design Validation

Design validation confirms the finished device meets user needs and intended use: did you build the right device? Involve end users and test production-equivalent units under actual or simulated use. See our verification and validation guide.

Completing Design Transfer

Design transfer moves the design from the project team to production, starting during validation and closing with a final design review. Keep the design history file current throughout. See our design transfer guide.

Preparing regulatory submissions

I want to spend a few moments now talking a bit about regulatory submissions and the relationship with Design Controls.

Generally speaking, as you successfully finish Design Verification, this means you are approaching a time when you can prepare a regulatory submission.

Specifically, this is the time in your medical device project when you should put together your FDA 510(k) submission (provided this is your path to market clearance).

If you plan to conduct a human clinical investigation in the U.S., successful completion of Design Verifications also marks the time when you should put together a FDA investigational device exemption (IDE) submission. (An IDE is likely for FDA PMA devices or could be of interest for clinical investigation before receiving 510(k) clearance.)

FDA PMA devices will be ready for FDA review upon completion of Design Validation.

Outside the U.S. regulatory submissions and files, such as technical documentation under the EU MDR, are provided to regulatory bodies upon completion of Design Validation, during Design Transfer.

Bringing it all together

After you complete your design transfer design review, you are almost ready for market launch, and you need to have all the necessary regulatory clearances in place. Then, at least from a Design Controls perspective, it is time to sell your medical device. Design Controls should be a systematic way to demonstrate the progress of your medical device product development efforts.

In this guide, I have shared with you what is expected for Design History File, User Needs, Design & Development Planning, Design Reviews, Design Inputs, Design Outputs, Design Verification, Design Validation, and Design Transfer.

I hope this guide helps answer all your questions about Design Controls (let me know in the comments!) -- even the questions you didn’t know you had.

Medical device product development should follow a structured, methodical approach with traceability throughout. But we all know nothing always goes according to plan.

That’s why in addition to this guide, we’ve also created Greenlight Guru, an easy-to-use, cloud-based software platform specifically to help medical device companies get to market faster by better managing their Design Controls.