Design Controls

What design controls are

Design controls are the formalised, documented practices that govern medical-device design and development. In US device GMP they originated in 21 CFR 820.30; under the FDA QMSR (effective February 2, 2026) that content now flows through ISO 13485:2016 §7.3, which the QMSR incorporates by reference. The elements are consistent across both: design and development planning, design inputs (requirements), design outputs (specifications), design review, design verification (outputs meet inputs), design validation (the device meets user needs under actual or simulated use), design transfer to manufacturing, and design changes — all under control.

The Design History File (DHF) is the compilation of records demonstrating the design was developed in accordance with the approved design plan and the design-control requirements. It is the evidence trail an auditor walks to confirm the process was followed. Two related but distinct files often get confused with it: the Device Master Record (DMR) — the recipe for building the device, an output of design transfer — and the Device History Record (DHR) — the production record for specific units. The DHF is about how the design was developed; the DMR is how to make it; the DHR is proof a batch was made to spec.

Design controls apply to most Class II and Class III devices and a subset of Class I devices; the requirement scales with risk, but for any device where they apply, the traceability they create is the spine of the technical documentation.

Why design controls dominate device audits

Design controls are among the most-cited areas in FDA device inspections and a central focus of notified-body audits under the EU MDR. The reason is structural: nearly every serious device field problem can be traced back to a design-control gap, so regulators treat the design-control records as a leading indicator of product safety.

The recurring failures are traceability failures. Design inputs that don't trace to outputs. Verification that doesn't close every input — leaving a requirement asserted but never tested. Validation performed on non-representative product, or on bench units rather than production-equivalent devices. And — the most common of all — design changes made without re-assessing impact, re-running the affected verification or validation, and updating the DHF, so the file gradually diverges from the device that actually ships.

Two integrations make or break design control, and auditors probe both. Risk management (ISO 14971) must feed design inputs — risk controls become requirements — and must be revisited as the design evolves, so the risk file and the design file stay in step. Change control must catch every design change, route it through review and the appropriate re-verification or re-validation, and update the DHF. A device team can have excellent design documents and still fail if these two threads aren't connected to them.

Where design controls live

• 21 CFR 820.30 — the original FDA design-controls requirement; its content now applies via ISO 13485 §7.3 under the QMSR
• ISO 13485:2016 §7.3 — design and development; the clause structure the QMSR and notified bodies both work from
• EU MDR (2017/745) Annexes I, II, III — general safety and performance requirements, plus the technical documentation that the DHF feeds
• ISO 14971:2019 — risk management; design inputs and risk controls are intertwined throughout the design process
• IEC 62304 — software lifecycle for devices containing software (SaMD and software-in-device); a design-control sub-discipline
• IEC 62366-1 — usability engineering; feeds design validation and human-factors evidence
• FDA Design Controls Guidance (1997) — the long-standing interpretive guide, still widely used for the waterfall/iterative design model
• FDA QMSR / CP 7382.850 — design records are within scope of the risk-based inspection program that replaced QSIT

How the design-control loop actually runs

In practice, design control is a loop, not a waterfall — even when documented in phases. A workable rhythm:

Plan and capture inputs. The design and development plan defines stages, responsibilities, reviews, and the verification/validation strategy. Design inputs are gathered from user needs, intended use, regulatory requirements, and — critically — the risk analysis, where each risk control measure becomes a design input that must be verified later.

Produce and review outputs. Design outputs (drawings, specifications, software, labeling) are created against the inputs and reviewed at defined milestones with the right participants and independent reviewers. Each review is a record.

Verify, then validate. Verification confirms outputs meet inputs — every input closed by an objective test, with a traceability matrix proving none were missed. Validation confirms the finished device meets user needs and intended uses under actual or simulated conditions, on production-representative product.

Transfer and control changes. Design transfer translates the design into the DMR for manufacturing, verified to ensure the design is correctly rendered into production. From that point, every design change is evaluated for impact, re-verified or re-validated as appropriate, approved, and reflected in the DHF — the discipline that keeps the file honest over the product's life.

The DHF accumulates throughout: plans, inputs, outputs, review records, verification and validation results, the traceability matrix, transfer records, and the running design-change history. It is assembled continuously, not reconstructed at audit time.

What strong design control looks like

Whether you run a dedicated DHF tool or assemble the file from documents, these are the controls auditors look for:

• A maintained traceability matrix — user needs to inputs to outputs to verification to validation, with no orphan requirements
• Risk-linked inputs — every ISO 14971 risk control traceable to a design input and its verification
• Milestone design reviews — with required participants, independent review, and records of issues and resolutions
• Verification closing every input — objective evidence per input, not a sampled subset
• Validation on representative product — production-equivalent units, actual or simulated use, including human factors where applicable
• Controlled design transfer — verified rendering of design into the DMR
• Design-change control — every change impact-assessed, re-V&V'd as appropriate, approved, and reflected in the DHF and risk file
• Software lifecycle control — IEC 62304 activities where the device contains software
• A continuously assembled DHF — built as you go, retrievable on demand

Where Complere supports design control — honestly scoped

Complere is not a Design History File system. It does not maintain the live design-input-to-output-to-verification traceability matrix that a dedicated product-development or ALM tool provides, and device teams whose work depends on that structured, linked requirements data should run one. Saying this plainly is the point: a vendor who claims an eQMS replaces a DHF tool is overselling, and a skeptical device-quality lead will catch it.

What Complere governs is the quality-system layer around design control — and that layer is substantial. Design plans, review minutes, design outputs, and the DHF documents themselves live in Document Control as controlled, versioned records with electronic signatures. Design changes route through impact-assessed change control — the gate that keeps the file honest — so a change carries its approval chain, document updates, training triggers, and a documented impact decision. ISO 14971 risk records are managed with linkage to CAPA and change, keeping the risk file in step with the design. Design-related quality issues become CAPAs with full investigation and traceability.

For teams whose engineering and requirements work lives in tools like Jira, GitHub, or TestRail, Complere's integrations connect that evidence into the governed quality system, so the design-control records and the development activity stay associated. The honest fit: Complere is a strong governed-quality layer that complements a DHF/ALM tool — controlled documents, change discipline, risk management, and CAPA around the design process — not a replacement for the structured design-traceability system itself. For the broader device picture, see the medical devices industry page.

Terms related to design controls

Design controls sit at the centre of device development. Explore related terms to build a complete picture.

• Risk Management — ISO 14971; feeds design inputs and tracks alongside the design
• Change Control — the gate that keeps the DHF and the device in sync
• FDA QMSR — routes 820.30 content through ISO 13485 §7.3
• Document Control — governs design documents and the DHF
• Validation — design validation versus process/computerised-system validation
• CAPA — where design-related quality issues are investigated