ISO 13485 clause 7.3: Development Controls with Audit-Ready Evidence

If you’re implementing ISO 13485 clause 7.3, your success isn’t measured by how good your procedure reads—it’s measured by whether an auditor can sample your Design History File (DHF) and see a clean chain of evidence: plan → inputs → outputs → reviews → verification → validation → transfer → controlled changes. This guide is a practical, evidence-first walkthrough of 7.3.1–7.3.10, including what auditors ask for, what to show, common failure patterns, and quick fixes. For the clause-by-clause hub view, start at our ISO 13485 Clauses 4–8 Hub.

In this article you’ll get:

• A “what auditors expect” implementation checklist for each 7.3 subclause
• A single evidence table you can use as an internal pre-audit check
• Two realistic mini examples (inputs/outputs and verification vs validation)

How auditors actually audit ISO 13485 7.3 (the sampling mindset)

Most auditors don’t read your entire DHF. They sample—and they’re looking for clean design controls audit evidence that proves your design and development controls ISO 13485 are working. A typical sampling flow looks like this:

1. Pick a device family and a recent change (software update, labeling update, supplier swap, design tweak).
2. Trace backward: what triggered it, what requirements changed, and who approved the plan.
3. Trace forward: which outputs changed, which tests were repeated, what validation impact was assessed, and what was released.

If any link is missing—no defined inputs, vague outputs, undocumented review decisions, verification not tied to requirements, validation not tied to intended use, or uncontrolled changes—7.3 becomes an easy nonconformity. Keep your reference pages open while you build: ISO 13485 Clause 7.3 – Design & Development and (for context) ISO 13485 Clause 7 – Product Realization.

Evidence table: ISO 13485 clause 7.3 auditor questions vs what to show

7.3.1 General: define the design control system auditors can follow

Operationally, 7.3.1 is about a repeatable system—not heroics. Auditors want to see that design work is planned, reviewed, and controlled the same way every time. Minimum evidence usually includes: a design control SOP, defined roles (who owns inputs, who approves outputs, who is independent for reviews), and a DHF index that lists the records you generate for each project.

• Set a single DHF structure (folders or system index) used for every project.
• Define independence: who can approve verification/validation evidence.
• Define stage gates: what must exist before moving to the next phase.

7.3.2 Design & development planning: treat the plan as a controlled record

A good design plan is not a Gantt chart you forget. It’s a controlled record that tells an auditor: what you’re building, how you’ll prove it works, and when you’ll review decisions. The plan should identify milestones, responsibilities, required deliverables, and how you manage cross-functional interfaces (engineering, RA/QA, production, software, usability).

Implementation checklist:

• Define phases (concept → feasibility → design freeze → verification → validation → transfer)
• List required outputs per phase (specs, drawings, labeling drafts, test plans)
• Schedule formal reviews and define entry/exit criteria
• Include a “plan update trigger” section (major change, failed verification, new hazard)

7.3.3 Design inputs: make requirements measurable and traceable

Inputs are where audits are won or lost. If inputs are vague, nothing downstream can be objectively verified. Build a design inputs list that is: (1) sourced (user needs, regulatory, risk, standards you apply), (2) measurable, and (3) approved.

Mini example 1: inputs → outputs (fictional but realistic)

Device family: handheld pulse oximeter used in clinics (non-invasive).

Input quality rules that prevent audit findings:

• Every input has acceptance criteria (numbers, ranges, pass/fail, or defined qualitative rubric)
• Every input has an owner and an approval date
• Every input is “verifiable” (test/inspection/analysis) or “validatable” (intended use / user need)

7.3.4 Design outputs: produce the artifacts production and testing actually use

Outputs are the “build and test instructions.” Auditors check whether outputs are sufficient to: (a) make the device consistently, and (b) verify that it meets inputs. Typical outputs include drawings/specifications, software requirements, BOMs, labeling/IFU drafts, and inspection/test methods. A key control is a DI→DO matrix showing 100% coverage (each input is realized by at least one output).

7.3.5 Design review: record decisions, not just discussions

Auditors look for evidence that design decisions were reviewed by appropriate people at appropriate times—and that outcomes were captured (approve, approve with actions, or reject). A strong review record includes: agenda, attendees/roles, reviewed inputs/outputs/risk updates, decisions, action items with owners/dates, and approval signatures.

• Use a standard review template with a decision block and a risk-impact prompt.
• Track actions to closure (and reference the closure evidence in the DHF).
• Ensure review timing matches the plan (or document justified deviations).

7.3.6 Design verification: prove outputs meet inputs

Verification answers: “Did we build the design right?” The auditor expectation is simple: every design input that is verifiable has a corresponding verification method and evidence of results. Control this with a verification plan and a verification matrix that links DI IDs to test cases, methods, and reports.

Verification discipline that prevents findings:

• Define pass/fail criteria before testing (no retrofitting acceptance)
• Use controlled test methods (versioned protocols, calibrated equipment, defined samples)
• Record deviations and dispositions (and trigger change control if needed)

7.3.7 Design validation: prove the device meets user needs and intended use

Validation answers: “Is this the right design for the intended use?” Auditors expect validation to reflect real use conditions, user profiles, and key safety/performance questions. This can include usability validation, clinical/performance evaluation, simulated-use, and labeling comprehension checks—depending on your device and risk.

Mini example 2: verification vs validation (quick distinction)

• Verification example: “Display refresh ≤ 2 seconds” — bench test using a defined signal input and timing measurement.
• Validation example: “Clinicians can correctly use the device and interpret outputs in the intended environment” — usability study or simulated-use scenario with representative users and tasks.

Common audit trap: calling a bench performance test “validation” because it happened late. The safer approach is to label evidence by its purpose (requirements conformance vs intended-use confirmation) and link it to the plan.

7.3.8 Design & development transfer: prevent “design drift” at handover

Transfer is the controlled handover from design to production/service delivery. Auditors want evidence that what you release is what production uses, and that critical knowledge (CTQs, inspection points, acceptance methods) is transferred. A simple transfer gate record with acceptance criteria is often enough.

• Define the release package (final specs, BOM, drawings, labeling, test methods)
• Define production readiness checks (training completed, suppliers confirmed, key jigs/testers available)
• Record the transfer decision and any open issues with mitigation

7.3.9 Control of design changes: force an impact assessment every time

Clause 7.3.9 is where “small changes” become big audit findings. The control you want is a design change record that requires: reason for change, affected outputs, impact assessment (requirements, risk, verification/validation scope, products in process), approvals, and release decisions.

• Trigger change control for any revision affecting requirements, performance, safety, labeling, software, or critical suppliers.
• Define re-test triggers: what changes require partial vs full re-verification and re-validation.
• Keep traceability current: update DI/DO links and V&V links when anything changes.

7.3.10 Design & development files (DHF): make retrieval and traceability effortless

Your DHF is your audit interface. A strong DHF is an index that points to controlled records, not a dump of folders. Auditors love when you can open an index and answer: “What version is released? Where are the reviews? Where is verification evidence? Where is validation evidence? What changed and why?”

DHF index checklist:

• Project identifiers (device family, project code, revision status)
• Design plan + revision history
• Design inputs list + approval
• Design outputs list + release evidence
• Review records (by milestone)
• Verification plan/matrix + reports
• Validation plan + evidence
• Transfer record + release sign-off
• Change log + impact assessments

Where ISOCloud Consulting can help (without slowing your team down)

If you need hands-on help building design controls or preparing for an audit, start with our Services page. If you want proof-style examples of what we deliver, see Proof & Capabilities. For packaging and options, see Pricing or reach out via Contact Us.

FAQ: ISO 13485 clause 7.3 (design controls) questions people actually search

• What is ISO 13485 7.3 in simple terms?
  It’s the set of controls that prove your medical device design is planned, requirements-driven, reviewed, tested (verification), confirmed for intended use (validation), and transferred and changed under control—with all evidence retrievable in a DHF.
• What evidence do auditors expect for ISO 13485 clause 7.3?
  A design plan, approved inputs and outputs, formal review records, linked verification and validation evidence, a documented transfer decision, controlled change records with impact assessment, and a DHF index that ties it all together.
• How do I distinguish verification vs validation in design controls audit evidence?
  Verification shows outputs meet inputs (requirement conformance). Validation shows the device meets user needs and intended use in representative conditions. Label your evidence by purpose and link both to your plan.
• What are common design controls audit findings under ISO 13485 7.3?
  Unmeasurable inputs, missing traceability, informal reviews without decisions, tests not linked to requirements, validation that doesn’t reflect intended use, and design changes made without impact assessment.
• Do small companies need the same DHF rigor?
  Yes—auditors scale expectations by complexity and risk, but they still expect the same chain of evidence. Smaller teams usually succeed by using a tight DHF index and a minimal set of mandatory records per phase.
• Where can I find practical examples and templates for clause 7.3?
  We publish clause guidance on our ISO Clause Hub and maintain a FAQs page for common implementation questions.