Design Controls for Medical Devices: Regulatory Requirements and Software Best Practices

Design controls are where most device failures begin. Not in manufacturing, not in post-market surveillance — in the decisions made (or poorly documented) during development. When FDA investigators cite design control deficiencies, they are rarely finding missing paperwork after the fact. They are finding that the link between what a user needed, what the engineer designed, and what the verification test confirmed was never formally established in the first place.

If you are responsible for quality or regulatory affairs at a medical device company, this is the terrain you manage every development cycle. Here is a precise look at what the regulations require, where teams consistently fall short, and how to build a process that holds up under audit.

‍

The Regulatory Foundation

Two parallel frameworks govern design controls for most device manufacturers operating globally.

21 CFR Part 820.30 (FDA Quality System Regulation, now integrated into 21 CFR Part 820 under the Quality Management System Regulation aligned with ISO 13485) requires manufacturers of Class II and Class III devices — and Class I devices with specific characteristics — to establish and maintain design control procedures covering:

• Design and development planning (820.30(b))
• Design input (820.30(c))
• Design output (820.30(d))
• Design review (820.30(e))
• Design verification (820.30(f))
• Design validation (820.30(g))
• Design transfer (820.30(h))
• Design changes (820.30(i))
• Design history file (820.30(j))

ISO 13485:2016 Clause 7.3 mirrors this structure and adds specificity around risk management integration throughout the design and development process. Clause 7.3.2 requires that planning outputs identify review, verification, and validation activities appropriate to each design stage. Clause 7.3.9 requires that design and development changes be evaluated for effect on constituent parts and delivered product — including risk reassessment.

IEC 62304 adds a software-specific layer for device software and software as a medical device (SaMD), classifying software units by safety class and linking classification directly to the rigor of development and testing activities required.

These three frameworks overlap intentionally. Your design control process needs to satisfy all three simultaneously, which means your documentation cannot live in silos.

‍

Where Teams Consistently Fail

FDA inspection data and ISO 13485 audit findings cluster around the same failure modes year after year.

Weak design inputs. Design inputs must be complete, unambiguous, and expressed in terms that allow verification. What auditors find instead are requirement documents that mix user needs with engineering solutions, contain untestable statements ("the device shall be easy to use"), or were written after development was already underway. ISO 13485 Clause 7.3.3 and 21 CFR 820.30(c) both require that inputs be reviewed and approved before design work begins. The approval timestamp matters.

Broken traceability. The single most common citation in design control audits is the inability to trace a design output back to a design input, and trace that input forward to a verification or validation record. When this trace lives in a spreadsheet — or worse, across a spreadsheet and a separate document management system — it breaks the moment anyone renames a file, revises a requirement, or runs a verification test without updating the matrix.

Risk management treated as a parallel activity. ISO 14971:2019 requires risk management to be integrated throughout the lifecycle, not completed as a standalone exercise at the end of design. When risk records live in a separate system from requirements and design outputs, teams cannot demonstrate that identified hazards influenced design decisions. Clause 7.3.3 of ISO 13485 explicitly requires that design inputs include applicable regulatory requirements and results of risk management activities.

Incomplete design history files. The DHF must contain or reference the records necessary to demonstrate that the design was developed in accordance with the approved design plan. Auditors look for the approved plan first, then work forward. If your DHF is assembled retroactively by pulling documents from shared drives, the sequence of approvals rarely holds up.

Design changes without proper impact assessment. A change to a component, software module, or manufacturing process triggers a requirement under 820.30(i) and ISO 13485 Clause 7.3.9 to evaluate whether the change affects safety, performance, or regulatory status. Teams that manage changes informally — through email or verbal approval — cannot produce the documented rationale an auditor will request.

‍

Building a Design Control Process That Holds Up

The following steps describe a structured design control process aligned with both FDA and ISO 13485 requirements.

1. Write design inputs before design work starts. Translate user needs into measurable, verifiable requirements. Each input should identify the source (user need, regulatory requirement, or risk mitigation measure) and carry a unique identifier. Review and approve formally before design activities begin.

2. Maintain a live traceability matrix. Every design input traces to at least one design output. Every design output traces to at least one verification or validation activity. Every risk control measure traces to the hazard it addresses and to the verification that confirms its effectiveness. This matrix is not a deliverable you produce at the end of the project — it is a living document updated continuously throughout development.

3. Integrate risk management into design reviews. At each formal design review (ISO 13485 Clause 7.3.5), the risk management file should be reviewed alongside design outputs. Any open risk that has not yet been mitigated should be on record as a known item with a planned resolution.

4. Document design verification and validation separately. Verification confirms that design outputs meet design inputs ("did we build it right?"). Validation confirms that the device meets user needs under actual or simulated use conditions ("did we build the right thing?"). These are distinct activities with distinct protocols and reports. Conflating them in a single test plan is a recurring audit finding.

5. Control design changes through your change management process. Every change to a design input, output, or verification record should flow through a documented change request. The impact assessment must address safety, performance, regulatory classification, and risk. Approval authority should be defined in your design control procedure.

6. Build the DHF in real time. The DHF is not a binder you assemble before a submission. It is the living record of your development process. Establish a defined structure at the start of the project and populate it as each phase completes.

‍

Where Software Tools Either Help or Break the Process

The practical challenge is not understanding what design controls require. It is maintaining compliance across a development team that uses different tools for requirements, testing, risk management, and document control.

When requirements live in a standalone ALM tool and risk records live in a separate QMS, traceability breaks at the boundary. A change in the requirements tool does not automatically prompt a review of the linked risk record. A CAPA that addresses a design deficiency has no programmatic link to the design input it affects. Auditors find these gaps because the audit trail stops at the tool boundary.

An integrated ALM and QMS platform resolves this structurally. When requirements, design outputs, risk management, verification records, CAPAs, and the DHF live in one system, traceability is not a report you generate — it is a property of the data. A requirement change triggers a notification to linked risk items and verification records. A CAPA links directly to the design control record it affects. The DHF index is populated automatically as records are approved.

Orcanos is built on this model. Its combined ALM and QMS gives device teams a single environment where design inputs link to risk hazards, verification records, and CAPAs within one audit trail. When an FDA investigator or notified body auditor asks to trace a design requirement from user need to validation evidence, that trace is one query, not an afternoon of spreadsheet assembly.

‍

Practical Takeaway

Design controls fail in the gaps: between user needs and documented inputs, between requirements and risk records, between development tools and quality systems. Closing those gaps is not a documentation exercise — it is a systems question. Build your process so that traceability is maintained continuously, not reconstructed at audit time.

If you want to see how an integrated platform handles design control traceability in practice, [schedule a demo with the Orcanos team](https://www.orcanos.com/demo). Bring your current tool stack — the gaps usually become visible within the first fifteen minutes.

‍