ISO 13485 clause 7.3 design and development: how to write design inputs; outputs auditors can trace

If you’re implementing ISO 13485 clause 7.3 design and development (or searching for ISO 13485 7.3 help), you’ll eventually hit the same truth auditors use to separate “paper compliance” from real control:

Most 7.3 audit findings start upstream—at badly written Design Inputs and Design Outputs. If inputs aren’t measurable and outputs aren’t implementation-ready, the rest of design controls becomes guesswork: verification is disconnected, validation is confused, design reviews become opinions, and traceability falls apart.

This guide teaches you exactly how to write inputs and outputs that are measurable, traceable, and verifiable—and how auditors check linkage during DHF sampling. For clause reference pages, keep these open as you work:

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

---

How auditors sample 7.3: the “linkage test” mindset

Auditors rarely read your DHF end-to-end. They sample. And their favorite sample is the one that proves your system is real:

1. Pick one design input (often a safety-related or performance requirement).
2. Ask where it came from (source/justification).
3. Ask which design outputs implement it (specs/drawings/SW requirements/labeling/manufacturing specs).
4. Ask how it was verified (test/inspection/analysis with pass/fail criteria).
5. Ask if validation is needed (intended use / user needs confirmation) and why.
6. Ask what happens when it changes (impact assessment + retest/revalidation decision logic).

If any link is missing—vague inputs, outputs that don’t “implement,” tests not mapped to requirements, validation mislabeled, changes not controlled—auditors widen sampling fast.

---

Input writing rules (measurable, testable, source/justification, acceptance criteria)

A Design Input is not a wish. It’s a controlled requirement statement that must be implemented by outputs and proven by evidence. The best inputs are boring—because they’re unambiguous.

Rule 1: Every input must be measurable (or defined with an objective rubric)

Bad: “Device must be easy to use.”
Better: “Representative users shall complete setup within 2 minutes without assistance in a simulated-use scenario.”

If you can’t express it with numbers, ranges, limits, or a clearly defined scoring rubric, you can’t verify it cleanly.

Rule 2: Every input must be testable (verification method is obvious)

When you write an input, you should already know which verification method will prove it:

• Test (bench test, functional test, environmental test)
• Inspection (dimensional, visual, labeling inspection)
• Analysis (calculation, simulation, rationale supported by evidence)
• Review (only when the input is about documentation completeness or conformance to a defined checklist)

Red flag: If the only way you can prove an input is “review” without defined acceptance criteria, it’s usually too vague.

Rule 3: Every input must have a source and justification

Auditors will ask: “Why is this requirement here?” You need a source reference. Typical sources include:

• User needs / intended use statements
• Risk analysis outputs (risk control requirements)
• Applicable regulatory expectations or guidance (without quoting standards text)
• Clinical/performance expectations for the device type
• Prior complaints / post-market feedback (if designing a change)

Good practice: record the source as a reference ID (e.g., UN-###, RM-###, PRD-###, complaint trend reference) and a one-line justification.

Rule 4: Every input must include acceptance criteria (pass/fail or defined thresholds)

Acceptance criteria is what makes verification objective. If the criteria isn’t defined up front, your verification becomes defenseless (“we think it passed”).

Example format you can standardize:

• Requirement statement: what must be true
• Acceptance criteria: numeric threshold / range / pass-fail rule
• Verification method: test/inspection/analysis
• Source: reference + justification

Rule 5: Use unique IDs and stable wording

Every design input gets a unique ID (DI-###). Don’t reuse IDs. Don’t delete IDs—obsolete them. Stability matters for traceability and change control.

Rule 6: Avoid “compound inputs” (one input should test as one thing)

Bad: “Device shall be accurate, robust, and easy to clean.”
That’s three requirements. Split it into three inputs so verification is clean and traceability isn’t messy.

Rule 7: Mark “verification” vs “validation relevance” explicitly

Many requirements are verifiable in the lab. Some must be validated in representative use conditions. Flag which inputs are:

• V: Verification-only (lab/bench)
• VAL: Validation-relevant (intended use/user need confirmation)
• V+VAL: Both

This reduces the classic audit problem: teams calling late verification “validation” just because it happened later.

---

Output writing rules (drawings/specs/BOM/SW requirements, labeling/IFU, manufacturing specs)

Design Outputs are the “build and test instructions.” Auditors expect outputs to be sufficient to manufacture, inspect, and verify the device consistently. Outputs are not just CAD files or a BOM—outputs are a controlled set of artifacts that implement inputs.

Rule 1: Each output must clearly implement one or more inputs

Outputs should reference the input IDs they implement (or you maintain that linkage in a DI→DO matrix). Either approach is fine as long as the linkage is clean and controlled.

Rule 2: Outputs must be production-usable (not just engineering artifacts)

Ask this question: “Could production build and inspect using this output?” If the answer is no, it’s not a sufficient output.

Typical output categories auditors expect for many devices:

• Drawings/specifications (materials, dimensions, tolerances, performance requirements)
• BOM (controlled, revisioned, approved)
• Software requirements/specifications (where software exists; include versioning and interface requirements)
• Labeling/IFU (claims, warnings, instructions aligned to design inputs and risk controls)
• Manufacturing specifications (critical process parameters, inspection steps, acceptance criteria)
• Test methods / inspection procedures used to verify inputs

Rule 3: Include output acceptance and release criteria

Outputs should be reviewed and released under control. Auditors often sample: “Show me the released output version and approvals.” That’s why document control discipline matters (see ISO 13485 Clause 4 – QMS & Document Control).

Rule 4: Outputs must be versioned and traceable (DO IDs)

Give outputs IDs (DO-###) and track versions. When an output changes, you need a design change record and an impact assessment that references which inputs are affected and what re-verification/re-validation is required.

Rule 5: Labeling and IFU outputs must be treated as design outputs

Auditors routinely see teams treat labeling as marketing collateral. In ISO 13485 reality, labeling/IFU is a design output that:

• implements safety-related inputs (warnings, contraindications, user instructions)
• supports intended use (validation relevance)
• must be controlled, reviewed, approved, and traceable

Rule 6: Manufacturing specs and acceptance methods must be consistent with design verification

One common trap is designing verification tests that don’t match production acceptance criteria. You want alignment: design verification proves the requirement; production acceptance ensures ongoing conformity.

This is where Clause 7 (Product Realization) connects: design outputs must transfer cleanly into production controls (ISO 13485 Clause 7), without losing version control and acceptance criteria.

---

Practical “writing pattern” for Design Inputs (copy structure)

Here’s a simple pattern you can standardize across your design input document. It forces audit-friendly clarity.

• DI ID: DI-###
• Requirement statement: “The device shall…”
• Acceptance criteria: numeric threshold/range or pass/fail rubric
• Verification method: test / inspection / analysis / review
• Validation relevance: V / VAL / V+VAL
• Source: reference ID + 1-line justification
• Notes: assumptions, operating conditions, dependencies

Example (good input):

• DI-018 — The device shall display measurement results within 2 seconds of stable signal detection.
• Acceptance criteria: ≤ 2.0 seconds in bench test under defined signal conditions.
• Verification method: test
• Validation relevance: V+VAL (confirm usability in intended workflow)
• Source: UN-004 clinical workflow need; justified to reduce user workarounds.

---

Practical “writing pattern” for Design Outputs (copy structure)

For outputs, your structure should help the auditor understand: “What is this artifact, what does it control, and how does it implement requirements?”

• DO ID: DO-###
• Output artifact: spec/drawing/BOM/SW requirements/IFU/manufacturing spec/test method
• Implements: DI-### list (or maintain DI→DO matrix)
• Release status: draft / reviewed / released
• Version and effective date
• Owner and approver
• Location/path (DHF index entry)

Example (good output):

• DO-031 — Display timing and UI response specification (includes testable interface timing requirements).
• Implements: DI-018, DI-019
• Release: Released v2.0 (approved)

---

Traceability mini-walkthrough (input → output → verification method)

Here’s a short traceability walkthrough you can use as an internal audit rehearsal. The point is to demonstrate that your inputs, outputs, and verification are linked with clean evidence.

Fictional device context

Device: Handheld diagnostic reader used in clinics.
Sample requirement category: performance + usability timing requirement.

Step 1 — Design input (DI)

DI-018: The device shall display results within 2 seconds of stable signal detection.
Acceptance criteria: ≤ 2.0 seconds measured via test protocol TP-018 under defined signal conditions.
Source: UN-004 clinical workflow requirement; justified to prevent delays and user workarounds.
Verification method: test

Step 2 — Design output (DO)

DO-031: UI/Timing specification (includes algorithm timing requirements, UI refresh timing, and interface timing constraints).
Implements: DI-018
Associated artifacts: SW requirement set (if software), timing test method, and interface design notes (as applicable).

Step 3 — Verification method (VER)

TP-018 Verification Protocol: defines setup, input signal conditions, test equipment/software timing capture approach, sample size, and acceptance criteria.
VR-018 Verification Report: records results, deviations (if any), conclusion (pass/fail), and approval.

What an auditor expects to see:

• DI-018 exists, measurable, with acceptance criteria and source justification
• DO-031 exists and is released/controlled (or clearly at the correct lifecycle stage)
• TP-018 references DI-018 (or the matrix links them)
• VR-018 provides objective results and a conclusion tied to the acceptance criteria
• If DI-018 is validation-relevant, a targeted validation justification exists (e.g., workflow simulated-use confirmation)

---

Common traps + fixes (the ones auditors flag constantly)

Trap 1: Inputs are vague or subjective

Symptom: words like “easy,” “robust,” “user-friendly,” “safe,” “high quality” with no criteria.
Fix: convert to measurable criteria (time, error rate, pass/fail thresholds, defined rubric). Add acceptance criteria and verification method.

Trap 2: Inputs mix multiple requirements

Symptom: one DI contains performance + usability + cleaning + packaging in one line.
Fix: split into atomic inputs; map each to its own outputs and tests.

Trap 3: Outputs don’t implement inputs (or implement them implicitly)

Symptom: “We have a drawing” but it doesn’t specify the critical requirement or acceptance method.
Fix: ensure outputs explicitly include the requirement constraints (dimensions/tolerances/spec limits), and that test methods exist where needed.

Trap 4: Verification evidence exists but isn’t linked

Symptom: test reports are present but cannot be shown to verify a specific input.
Fix: build a verification matrix keyed to DI IDs; require each test report to reference the protocol and DI IDs it covers.

Trap 5: Validation is treated as “late verification”

Symptom: final bench testing is labeled validation without intended use/user need justification.
Fix: document intended use/user profile and validate representative use conditions (even if limited scope). Keep the purpose distinction clear.

Trap 6: Labeling/IFU is disconnected from design controls

Symptom: warnings and instructions aren’t traceable to safety inputs or risk controls.
Fix: treat IFU/labels as DO artifacts; include them in traceability and design reviews.

Trap 7: Changes update outputs but not traceability and retest logic

Symptom: DO version changes but DI links and verification plans aren’t updated; retest decisions are undocumented.
Fix: impact assessment must list affected DI/DO/VER/VAL links and define required rework and evidence updates.

---

---

FAQ (ISO 13485 7.3 design inputs and outputs)

• What makes a design input “good” under ISO 13485 7.3?
  It is measurable, testable, sourced/justified, includes acceptance criteria, has a defined verification method, and can be traced to outputs and evidence.
• Do all design inputs need numeric acceptance criteria?
  Most do. When numbers aren’t realistic, you still need an objective rubric (defined scoring, checklist pass/fail, or clearly bounded qualitative criteria).
• What counts as a design output in ISO 13485 clause 7.3 design and development?
  Outputs are controlled artifacts used to build, inspect, and verify the device: drawings/specs, BOM, software requirements (if applicable), labeling/IFU, manufacturing specs, and test/inspection methods.
• How do auditors check linkage between inputs and verification?
  They pick an input, ask for the implementing output(s), then request the verification method and report that proves the input was met—using clear IDs or a matrix.
• Should labeling and IFU be traceable to inputs?
  Yes. Labeling is a design output and often implements safety-related requirements and risk controls. Treat it like any other controlled output.
• What’s the most common traceability failure?
  Test reports exist, but no one can prove which requirements they verify. Fix it with a DI-keyed verification matrix and disciplined referencing in reports.
• Where does document control fit into 7.3 success?
  If outputs, protocols, and reports aren’t version-controlled and retrievable, your traceability is fragile. Clause 4 document control is the foundation: ISO 13485 Clause 4.

---

For clause navigation and related evidence expectations, use the Clause Hub and then dive into Clause 7.3 and Clause 7 as needed.