The exclusion question first
Clause 7.3 covers design and development, and it can be excluded — but only if you genuinely do not carry design responsibility.
A contract manufacturer producing to a customer's specification can exclude it with a documented justification. A manufacturer that designs its own devices cannot. Getting this wrong is expensive in both directions: implementing design controls you could have excluded wastes months, and excluding them when you do design produces a nonconformity at audit.
Settle it before anything else, because it determines the size of the project — see ISO 13485 certification cost.
The design control elements
| Element | What it requires | Common failure |
|---|---|---|
| Design planning | Stages, reviews, responsibilities, updated as design evolves | Written once, never updated |
| Design inputs | Requirements — functional, performance, safety, regulatory | Vague or untestable inputs |
| Design outputs | Specifications verifiable against inputs | Outputs not traceable to inputs |
| Design review | Documented reviews at planned stages | No independent reviewer present |
| Design verification | Outputs meet inputs | Confused with validation |
| Design validation | Device meets user needs and intended use | Done on non-representative product |
| Design transfer | Design correctly translated into production | Informal handover, no record |
| Design changes | Reviewed, verified, validated, approved before implementation | Changes made then documented later |
| Design files | A file per device type or family | Scattered across systems |
Verification vs validation
The distinction auditors probe most, and the one teams most often blur.
Verification asks: did we build the device right? Do the outputs meet the inputs. Testing against your own specification.
Validation asks: did we build the right device? Does it meet user needs and its intended use, under actual or simulated use conditions, on initial production units or their equivalent.
That last clause is where validation most often fails. Validating on an engineering prototype rather than production-equivalent product is a finding, because it does not demonstrate that the device you actually manufacture meets user needs.
The design history file
The DHF is the compiled record demonstrating the design was developed in accordance with your design plan and clause 7.3.
It contains the design plan and revisions, inputs and their approval, outputs, review records with attendees and outcomes, verification protocols and results, validation protocols and results, the transfer record, the change history, and the risk management file linkage.
It cannot be assembled retroactively in a hurry. A DHF constructed the month before an audit reads exactly as what it is, because the dates tell the story. Building it as you go costs almost nothing extra; reconstructing it costs months.
Risk management runs alongside
Design controls and ISO 14971 risk management are not sequential activities. Risk analysis informs design inputs; design changes trigger risk re-evaluation; validation confirms risk controls are effective.
Organizations that treat risk management as a document produced after the design is finished end up with a risk management file that does not reflect the device, and the disconnect is visible to an auditor comparing the two.
FAQs
What are design controls in ISO 13485?
The requirements of clause 7.3 covering design and development: planning, inputs, outputs, review, verification, validation, transfer, change control and the design file. They apply to any manufacturer carrying design responsibility for its devices.
Can I exclude design controls from ISO 13485?
Yes, if you genuinely do not carry design responsibility — a contract manufacturer producing to a customer's specification can exclude clause 7.3 with a documented justification. A manufacturer designing its own devices cannot, and excluding it wrongly produces a nonconformity.
What is the difference between design verification and validation?
Verification confirms the design outputs meet the design inputs — did we build the device right. Validation confirms the device meets user needs and its intended use under actual or simulated conditions, performed on initial production units or their equivalent — did we build the right device.
What is a design history file?
The compiled record demonstrating the design was developed according to the design plan and clause 7.3. It contains the design plan and revisions, inputs and outputs, review records, verification and validation protocols and results, the transfer record, change history and the link to the risk management file.
When should the design history file be built?
Continuously, as the design progresses. It cannot credibly be assembled retroactively — the dates on a file constructed the month before an audit tell the story, and reconstructing it costs months where building it as you go costs almost nothing extra.
Where to go next
See ISO 13485 consulting, CAPA, or what certification costs.