Design and development audit sample ISO 13485: a realistic Clause 7.3 auditor walkthrough

If you searched for a design and development audit sample ISO 13485, you probably don’t want theory—you want to know what an auditor will actually ask, how they sample your Design History File (DHF), what “good evidence” looks like, and what findings happen most often under ISO 13485 clause 7.3. This article gives you a practical, auditor-facing “sample audit” you can run internally before your certification audit or surveillance audit.

What you’ll get:

• Auditor sampling logic (how they pick records and how they trace)
• An auditor test script (15–25 questions) mapped to 7.3.1–7.3.10
• A DHF evidence pack checklist you can use as a pre-audit pack
• Top 7 failure patterns with fast, practical fixes
• A short fictional scenario showing one change request, one review, one verification, and one validation outcome

If you prefer the clause hub view for navigation, start at the ISO 13485 Clauses 4–8 Clause Hub. If you’re working specifically on design & development, keep this page open too: ISO 13485 Clause 7.3 – Design & Development.

How auditors sample ISO 13485 design & development (Clause 7.3)

Auditors rarely read your entire design file end-to-end. They sample. Their job is to determine whether your system reliably produces controlled, traceable design outputs and objective evidence—without depending on “the one person who knows where everything is.”

Typical sampling pattern (what to expect):

1. Pick a project (new product or major change). They often choose something recent or something that triggered change control.
2. Start at the DHF index (or whatever you call the design file register) and ask for the “spine” records: plan, inputs, outputs, review records, verification, validation, transfer, change records.
3. Choose a requirement (or a hazard-related requirement) and trace it forward: input → output → verification → (if applicable) validation.
4. Choose a change and trace it both ways: why change, what’s impacted, what evidence was repeated, what was released.
5. Check independence and approvals: did the right roles review, did decisions get documented, did you follow your own plan and gates?

That’s why “design controls audit evidence” is mainly about traceability and retrieval: can you show the right record, the right version, the right approval, with a clear link to the requirement or risk that drove it?

For broader context on how design fits into product realization, see ISO 13485 Clause 7 – Product Realization.

Evidence pack checklist (DHF artifacts list) auditors expect to see

This is the “pre-audit evidence pack” checklist you should be able to open within 5–10 minutes. Keep it in a single DHF folder or a DHF index that points to controlled records.

• DHF Index / Design File Register (record list with IDs, versions, owners, locations)
• 7.3.2 Design & Development Plan (milestones, responsibilities, interfaces, review gates, deliverables)
• Design Inputs (approved requirements list; sources; measurable acceptance criteria; input IDs)
• Design Outputs (specs, drawings, software requirements, BOM, labeling drafts, test methods; output IDs)
• Design Review Records (at defined gates; decisions + action items + closure evidence)
• Verification Plan + Verification Matrix (input IDs → test/inspection/analysis methods → reports)
• Verification Reports (objective results; deviations; conclusions; approvals)
• Validation Plan (intended use, user profiles, use environment, methods, acceptance criteria)
• Validation Evidence (usability/simulated-use/performance validation outcomes and conclusions)
• Design Transfer Evidence (release package checklist; production readiness; training/hand-off)
• Design Change Records (impact assessment; updated traceability; repeated testing decisions)
• DHF Integrity Controls (version control, approvals, access control, record retention logic)

If you’re struggling to keep this tight and audit-ready, it’s a sign your DHF “spine” needs standardization. That’s exactly what our clause execution packs are designed to do (templates + filled examples + evidence indexes in DOCX + XLSX) so you can adopt a consistent structure quickly.

Auditor test script (mapped to ISO 13485 7.3.1–7.3.10)

Use the questions below as an internal “hostile audit rehearsal.” The goal isn’t to sound smart—the goal is to be able to open evidence quickly, show links, and demonstrate control.

7.3.1 General (design & development controls system)

1. Show me your design control process and how it’s applied consistently across projects.
2. Who is accountable for design inputs, outputs, and DHF integrity? Show the role assignment evidence.

7.3.2 Design & development planning

3. Show the current design plan for this project. What are the phases, deliverables, and stage gates?
4. Where do you define interface responsibilities (engineering, RA/QA, production, software, usability)?
5. When was the plan last updated, and what triggered the revision?

7.3.3 Design inputs

6. Show me the approved design inputs list. How do you ensure inputs are measurable and testable?
7. Pick one safety-critical requirement. Where did it come from, and how is it controlled?
8. How do you prevent “vague inputs” (e.g., “easy to use”) from entering the system?

7.3.4 Design outputs

9. Show the design outputs that implement the inputs (specs/drawings/software requirements/labeling).
10. How do outputs support production and inspection? Show the released test/inspection methods.
11. Show a DI→DO mapping (or equivalent). Is coverage complete and current?

7.3.5 Design review

12. Show the last formal design review record. What decisions were made and who approved them?
13. How do you ensure the right functions attend reviews (including independence where required)?
14. Show how review action items are tracked to closure with evidence.

7.3.6 Design verification

15. Show the verification plan and matrix. How do you ensure every requirement is verified?
16. Select one input requirement—show the test method, acceptance criteria, and the report results.
17. How do you control deviations and retesting decisions?

7.3.7 Design validation

18. What is the intended use and user profile? Show where it is defined and approved.
19. Show your validation plan. Why is the chosen validation method appropriate for intended use?
20. Explain how you distinguish verification vs validation in your records (not just timing).

7.3.8 Design transfer

21. Show evidence of design transfer. What constitutes the release package and who signs it off?
22. How do you ensure production is using the correct released outputs (specs, BOM, labeling, test methods)?

7.3.9 Control of design changes

23. Show a recent design change record. What triggered it and what was impacted?
24. Show the impact assessment: requirements affected, risks affected, verification/validation scope affected.
25. How do you decide what must be reverified or revalidated after a change?

7.3.10 Design & development files (DHF)

26. Open your DHF index and retrieve the exact version of: plan, inputs, outputs, last review, key V&V, transfer, and latest change record.
27. How do you prevent “record scatter” and ensure DHF completeness at release?

Scoring tip: If answering any question requires “let me ask John” or “it’s somewhere in email,” treat it as a likely audit weakness. Fix it by tightening your DHF index and standardizing your required record set.

Top 7 failure patterns (and fast, realistic fixes)

1. Inputs are not measurable (requirements can’t be verified).
   Fix: rewrite inputs as testable statements with acceptance criteria; assign unique IDs.
2. No clean traceability (inputs don’t map to outputs/tests).
   Fix: maintain a simple DI→DO and DI→VER/VAL matrix; require 100% coverage.
3. Design reviews are “meetings” not decisions (no recorded outcomes).
   Fix: enforce a review record that captures decision, rationale, approvals, actions, and closures.
4. Verification evidence exists but is disconnected (tests not linked to requirements).
   Fix: verification plan + matrix keyed to input IDs; every report references test case IDs.
5. Validation doesn’t reflect intended use (wrong users, wrong environment, wrong endpoints).
   Fix: define intended use + user profile explicitly; validate under representative conditions.
6. Change control is informal (CAD/software changes without impact assessment).
   Fix: design change record required for any output revision affecting performance/safety/labeling; include V&V retest triggers.
7. DHF retrieval is slow or incomplete (records scattered, versions unclear).
   Fix: one DHF index as “source of truth” with record IDs, owners, paths, versions; enforce release readiness checks.

Fictional audit scenario (short, realistic, and traceable)

Device: “ThermoPatch T1” — a reusable skin temperature monitoring patch used in outpatient clinics.
Trigger: Change request CR-014 — supplier discontinues the adhesive liner material; replacement adhesive has slightly different peel strength.

What the auditor does

The auditor selects CR-014 as the sampling anchor. They ask for the change record, then trace to inputs, outputs, and re-testing decisions.

One design review (what good looks like)

Design Review DR-03 (Change Review Gate) includes Engineering, QA/RA, Production, and an independent reviewer. The record shows:

• Decision: approve adhesive material change with defined re-verification and a targeted validation check
• Rationale: adhesive change impacts skin contact performance and labeling claims (“wear duration”)
• Actions: update output spec DO-112 (adhesive material spec), update IFU handling note, execute VER test protocol TP-VER-07, run a limited simulated-use validation scenario

One verification outcome

Verification TP-VER-07: bench peel-strength test against acceptance criteria linked to DI-045 (minimum adhesion threshold and removal safety).
Result: pass across defined sample size; one borderline sample triggers a documented deviation review and confirms it remains within acceptable range after conditioning.

One validation outcome

Validation V-VAL-02 (targeted simulated-use): representative users apply/remove patch under normal clinic workflow; endpoints include skin irritation observations and removal usability under stated wear time.
Result: intended use tasks completed successfully; minor IFU wording updated to reduce user confusion; change record shows labeling output DO-205 updated and re-approved.

What the auditor concludes: Change control is working because the change record links: trigger → impacted requirements → updated outputs → defined V&V scope → objective results → release decision → DHF update.

Where to go deeper on clause guidance (internal reference pages)

Use these pages as your implementation map while building your DHF evidence:

• Clause 7.3 – Design & Development
• Clause 7 – Product Realization
• ISO 13485 Clauses 4–8 Clause Hub

FAQ: design and development audit sample ISO 13485

• What does an ISO 13485 design and development audit focus on?
  Evidence and traceability: plan → inputs → outputs → reviews → verification → validation → transfer → controlled changes → DHF integrity.
• How many design projects will an auditor sample?
  Often 1–2 core projects plus at least one significant change. They also sample key records (reviews and tests) across phases.
• What’s the fastest way to avoid clause 7.3 findings?
  Standardize your DHF “spine”: consistent record set, unique IDs, clean traceability matrices, and fast retrieval from a DHF index.
• What is the most common mistake in verification and validation?
  Treating them as timing-based rather than purpose-based. Verification proves requirements are met; validation confirms intended use and user needs under representative conditions.
• What should I hand an auditor in the first 10 minutes?
  DHF index, design plan, inputs list, outputs list, last review minutes, verification matrix + key reports, validation summary, transfer record, latest change record.
• Where can I get filled examples of design controls records?
  If you want audit-ready filled examples (not blank templates), use purpose-built filled-example packs designed for auditor sampling and CAPA closure.

---