ISO 13485 design reviews (Clause 7.3): an operational playbook auditors can sample

In an ISO 13485 audit, design reviews are one of the fastest ways for an auditor to judge whether your design controls are “real” or just paperwork. Why? Because reviews sit in the middle of the design chain. They connect your design plan, inputs, outputs, verification/validation decisions, transfer readiness, and change control—plus they show whether decisions were made by the right people, using the right evidence, with traceable outcomes.

This guide is a complete operational playbook for ISO 13485 Clause 7.3 design review activity: review triggers, required attendees, agenda, required inputs/outputs, minutes structure, action tracking, closure evidence, and what auditors typically sample in the DHF.

Helpful internal references while you implement:

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

---

How auditors sample design reviews (the “show me the decision trail” test)

Auditors rarely ask “Do you do design reviews?” They ask:

• Show me where reviews are planned (and at what gates).
• Show me the last review record and what decisions were made.
• Show me evidence that actions were closed (and closure is tied to objective evidence).
• Show me that reviews covered required topics (inputs, outputs, V&V readiness, risk linkages, transfer readiness, changes).

A classic auditor sampling pattern is:

1. Select one project (or one significant design change).
2. Pick the most recent design review (or a key gate review).
3. Pick one requirement or risk control discussed in the review and trace it forward (outputs → verification/validation evidence).
4. Pick one action item and ask for closure evidence.

If you can’t retrieve the review pack, minutes, and closure evidence quickly—or if decisions are vague—auditors expand sampling across other reviews and other DHF elements.

---

Design review triggers: when you must hold a formal review

The simplest way to make reviews audit-proof is to define clear triggers. Reviews should not depend on someone remembering to schedule them.

1) Planned gate reviews (from the design plan)

In most medical device organizations, auditors expect at least these formal review gates (adjust names to your lifecycle):

• DR0 – Planning / feasibility review: scope, intended use, interfaces, risks, plan readiness.
• DR1 – Input readiness review: design inputs quality (measurable/testable), acceptance criteria, source justification, traceability approach.
• DR2 – Output readiness review: outputs complete enough to support verification and transfer; drawings/specs/BOM/labeling/test methods in shape.
• DR3 – Verification readiness review: protocols approved, methods suitable, acceptance criteria defined, resources calibrated/available.
• DR4 – Validation readiness review: intended use/user needs and representative conditions defined; validation plan is fit-for-purpose.
• DR5 – Transfer / release review: release package complete; production readiness and acceptance activities defined.

Not every product needs all of these as separate meetings—but you need a controlled approach that shows reviews happen at appropriate points, with decisions and outputs recorded.

2) Event-based reviews (must happen when triggered)

Define these triggers explicitly in your procedure or design plan:

• Design input changes: new/changed requirements, acceptance criteria changes.
• Major design output revisions: drawings/specs/BOM/software requirements/IFU changes impacting performance or safety.
• Verification/validation failures: any failed test, repeated deviations, or ambiguous results requiring decisions.
• Risk-driven triggers: new hazard identified, risk control change, or residual risk concerns.
• Supplier/manufacturing impact: component obsolescence, supplier change, or process change impacting device performance.
• Post-market signal: complaint trend or CAPA that drives a design change (connects to Clause 8 evidence).

Rule that auditors like: “If it changes what the device is or how it performs—or changes what we claim—we trigger a design review.”

---

Required attendees: who must be in the room (and why)

Design reviews are not a one-person sign-off. The purpose is cross-functional decision-making. Your attendee model should be role-based rather than name-based.

Minimum attendee roles (common, defensible baseline)

• Design/Engineering owner (presents technical status, outputs, issues)
• Quality (QA) (ensures process compliance, evidence quality, risk linkages, DHF integrity)
• Regulatory (RA) (ensures claims/intended use alignment, validation relevance, labeling alignment where applicable)
• Manufacturing/Operations representative (transfer readiness, manufacturability, acceptance activities)
• Independent reviewer (someone not directly responsible for the design output being reviewed)

Note: “Independent” doesn’t mean external—just not the primary creator of the outputs under review. Auditors look for evidence of impartial review to reduce bias.

Optional but high-value roles (triggered by scope)

• Software lead (if software contributes to device performance/safety)
• Clinical/Usability (if validation relies on use environment, user tasks, or human factors)
• Supplier Quality (if outsourced processes/components are critical)
• Service/Customer support (if feedback signals drive design change)

To keep this lean, use a rule: “Required roles vary by review type.” Then list mandatory roles per gate in your design plan.

---

Design review pack checklist (what to bring)

This is your Design Review Pack—the items you should be able to open within minutes when an auditor asks for the review evidence. Treat it like a controlled bundle linked in the DHF index.

Design review pack checklist (copy/paste)

• 1) Review cover sheet: project ID/name, review gate (DR0/DR1/etc.), date/time, location, chair, scribe
• 2) Attendee list: names + roles + independence indicator; invited vs attended
• 3) Agenda: topics + timeboxes + decision points
• 4) Design plan excerpt: planned milestones and what the gate must approve
• 5) Design inputs snapshot: inputs list (DI IDs), acceptance criteria completeness status, source references
• 6) Design outputs snapshot: outputs list (DO IDs), version status (draft/released), key artifacts attached or linked
• 7) Traceability view: DI→DO matrix (and where verification methods will map)
• 8) Risk linkage view: list of top risks and associated control requirements affecting current gate (no standard quoting; use your own risk IDs)
• 9) V&V readiness: verification protocols planned/approved, validation plan summary, acceptance criteria readiness
• 10) Open issues log: known issues, deviations, decisions needed
• 11) Change summary (if review triggered by change): what changed, why, impacted DI/DO/VER/VAL
• 12) Decisions required: explicit “approve / approve with actions / reject” items

Best practice: keep the pack consistent across reviews so retrieval is predictable. This is where Clause 4 document control makes audits easier: Clause 4 – Document Control.

---

Agenda: a repeatable design review meeting flow

A good ISO 13485 design review agenda is not a slide presentation. It’s a decision workflow. Here’s a practical agenda that works across many review types.

Standard agenda (60–120 minutes depending on scope)

1. Opening & scope (5 min): review objective, gate criteria, what must be decided today
2. Prior actions closure (10 min): review last review action status; show closure evidence for completed actions
3. Inputs review (15–25 min): key input changes, completeness, measurability/testability, acceptance criteria readiness
4. Outputs review (15–25 min): key output changes, readiness, manufacturability, labeling alignment
5. Traceability check (10–15 min): coverage and gaps (DI→DO and DI→verification method mapping)
6. Risk linkage check (10–15 min): confirm risk controls are implemented in outputs and planned verification/validation
7. V&V readiness / results (15–30 min): protocols approved, results summary, deviations and dispositions
8. Transfer readiness (if applicable) (10–15 min): release package readiness, production acceptance activities
9. Decisions (10 min): approve/approve-with-actions/reject; define gate exit criteria
10. Actions & owners (10 min): create actions with due dates and objective closure requirements

Chair tip: If the review ends without explicit decisions, auditors treat it as an information meeting—not a controlled review.

---

Minutes structure example (headings + what to record)

Auditors don’t need perfect prose. They need objective evidence of decisions. Your minutes should capture what was reviewed, what was decided, and what evidence supports closure.

Minutes template structure (example headings)

Document header

• Record ID: DR-MIN-###
• Project/Device: [Project name + ID]
• Review gate/type: [DR1 Input Review / DR3 Verification Readiness / Change Review, etc.]
• Date/time, location, chair, scribe
• Document version + status (if your minutes are controlled)

1. Attendees & roles

• Attended: name – role – function – independence (Y/N)
• Invited but absent: name – role – justification (if needed)

2. Purpose & scope of review

• What this review is approving (gate exit criteria)
• What is out of scope

3. Inputs reviewed (list IDs and versions)

• Design plan reference (version/date)
• Design input list reference (DI list version/date)
• Key input changes since last review (DI-### additions/updates/obsoletes)

4. Outputs reviewed (list IDs and versions)

• Key output artifacts (DO-### with versions)
• Labeling/IFU status (DO-###)
• Manufacturing/inspection specs readiness (DO-###)

5. Traceability & coverage check

• DI→DO coverage summary: [e.g., 95% covered; gaps listed below]
• DI→verification method readiness summary
• Gaps: list DI IDs with missing output(s) or missing verification method

6. Risk linkage check (summary)

• Top risk control requirements reviewed and where implemented (DI/DO references)
• Any risk changes triggered by design changes

7. Verification/validation readiness or results

• Verification protocols reviewed (TP-###) and approval status
• Results reviewed (VR-###) and deviations/dispositions
• Validation plan status (VAL-PLAN-###) and any changes to intended use/user assumptions

8. Decisions

• Decision statement: Approve / Approve with actions / Reject
• Decision rationale (short, evidence-based)
• Gate exit criteria (what must be true before moving forward)

9. Actions (with objective closure evidence)

• Action ID, description, owner, due date, closure evidence required (record ID(s) expected), status

10. Approvals

• Approver names/roles + date
• Electronic signatures or controlled sign-off mechanism

Key principle: Every decision should tie to an artifact or record ID (inputs list version, output spec version, test report ID, change record ID). That’s what makes minutes “auditable.”

---

Action closure + follow-up evidence (what “closed” means in ISO 13485 reality)

A design review action item is only valuable if you can show closure with objective evidence. Auditors often pick one action and ask: “Show me closure.” If closure is “we discussed it,” you’re exposed.

Write actions with “closure evidence” built in

When you write an action, include:

• What must be produced (artifact/record ID expected)
• What acceptance criteria apply (pass/fail or readiness criteria)
• Who verifies closure (not always the same person who performs it)
• Due date and escalation rule

Examples of strong action wording

• Weak: “Update inputs.”
• Strong: “Revise DI list to make DI-014 measurable; add acceptance criteria; update DI→DO matrix; submit DI-DOC v2.0 for approval by QA + RA (evidence: DI-DOC v2.0 + matrix v2.0).”

• Weak: “Do verification test.”
• Strong: “Execute TP-018; document results in VR-018; record deviation disposition if any; submit VR-018 for approval (evidence: VR-018 approved).”

Follow-up mechanisms auditors like

• Action log maintained as a controlled record (linked to each design review record)
• Next review starts with action closure and references closure evidence IDs
• Escalation if overdue actions impact gate exit criteria (ties to governance expectations under Clause 5)

Practical audit tip: In the DHF index, store (or link) review minutes + the action log + closure evidence references together. That makes sampling easy and reduces audit friction.

---

10 auditor checks (what they will test in a design review record)

1. Planned reviews exist: reviews are referenced in the design plan with defined gates and criteria.
2. Right attendees and roles: cross-functional participation is evident; independence is addressed.
3. Inputs and outputs are identified: minutes list which documents/artifacts were reviewed (IDs + versions).
4. Decisions are explicit: approve/approve-with-actions/reject is stated (not implied).
5. Rationale exists: decisions have short, evidence-based reasoning.
6. Actions are concrete: each action has owner, due date, and closure evidence expectations.
7. Action closure is provable: closures reference objective evidence (record IDs), not “completed.”
8. Traceability gaps are managed: gaps are identified and actions created; matrices updated.
9. V&V readiness/results are controlled: protocols and reports are referenced and appropriately approved.
10. DHF integrity: review records are retrievable quickly and tied into the DHF index under document control (Clause 4).

---

Top 5 failure patterns (and fixes that actually work)

1) Failure pattern: “Minutes exist, but they don’t show decisions”

What auditors see: meeting notes, slides, or a calendar invite—no decision statement, no gate exit criteria.
Fix: enforce a minutes structure with a dedicated “Decisions” section and explicit approve/approve-with-actions/reject outcomes.

2) Failure pattern: “Wrong attendees” (no cross-functional review)

What auditors see: only engineering attended; manufacturing/QA/RA absent; no independence.
Fix: define required roles per review type and require justification if a role is absent; add an independent reviewer rule.

3) Failure pattern: “Actions without objective closure evidence”

What auditors see: actions like “update spec” marked complete with no reference to revised artifacts or approvals.
Fix: require closure evidence IDs in the action log (e.g., DO-### v2.0 approved; VR-### approved).

4) Failure pattern: “Traceability isn’t reviewed”

What auditors see: inputs/outputs discussed but no DI→DO or DI→VER coverage check, so gaps survive until late stages.
Fix: make traceability a standing agenda item; include a coverage summary and list gaps with actions.

5) Failure pattern: “Review pack isn’t controlled or retrievable”

What auditors see: artifacts scattered in email/Teams; versions unclear; people can’t retrieve within minutes.
Fix: maintain a DHF index and controlled storage paths; link review packs to the DHF record set and lock archives (Clause 4 discipline).

---

---

FAQ (ISO 13485 design reviews)

• How many design reviews do we need for ISO 13485 Clause 7.3?
  Enough to demonstrate planned, appropriate reviews at key stages and when changes or issues occur. Auditors look for a risk- and lifecycle-appropriate set of gate reviews plus event-triggered reviews.
• Do design reviews have to be formal meetings?
  They must be formal in evidence: planned or triggered, documented, with defined participants, inputs, outputs, decisions, and action closure. The meeting format can be lean as long as the evidence is strong.
• What should be included in design review minutes for audit defense?
  IDs/versions of inputs and outputs reviewed, attendee roles, explicit decisions with rationale, action list with closure evidence requirements, and approvals/sign-off.
• Can the design owner approve their own work in a review?
  They can participate, but auditors generally expect some independence in review—at minimum, another qualified person not responsible for creating the specific output should review and challenge it.
• How do we show action closure objectively?
  Link each action to a record ID that proves closure (revised input/output document version approved, verification report approved, updated traceability matrix). “Completed” is not evidence.
• How do design reviews connect to product realization (Clause 7)?
  Reviews should confirm outputs are suitable for verification and transfer, and that released outputs become controlled production acceptance activities and work instructions without version drift. See Clause 7 – Product Realization.
• Where do design review records live?
  In the DHF (design file) with a DHF index that makes retrieval and version control easy. Strong document control under Clause 4 makes this much easier in audits.

---

If you want the full navigation map across clauses 4–8, start at the ISO 13485 Clauses 4–8 Clause Hub and then drill into Clause 7.3.