Evidence, Not Paperwork
Measure. Trace. Prove.
Design control metrics are the small set of measures that tell a device organization whether its design controls are actually working — not whether the procedures exist, not whether the files are complete, but whether the system is catching problems while they are still cheap to fix. Most device makers have never defined them. They have a design control procedure, a Design History File, a verification protocol library, and a wall of signatures. What they do not have is a number that would have warned them six months before a field action.
That is the quiet failure at the center of most medical device quality systems. Design controls get audited for presence. They almost never get measured for performance. And because presence is what auditors historically checked, presence is what organizations built. This guide is MSI's playbook for closing that distance — a working set of design control metrics that turn ISO 13485:2016 Clause 7.3 from a compliance obligation into a leading indicator leadership can act on.
Direct Answer
What are design control metrics? Design control metrics are quantified measures of how well an organization's design and development controls are performing — covering the integrity of design inputs, the completeness of traceability from user need to verified output, and the readiness of a design to transfer to production. Unlike audit findings, which are lagging and periodic, well-chosen design control metrics are leading and continuous: they surface requirement instability, verification debt, and traceability breaks early enough to act on. They answer a question compliance records cannot: is the design control system preventing problems, or merely documenting them?
What You Will Gain
Key Takeaways on Design Control Metrics
Signal. Structure. Standard.
- Design controls are audited for existence and measured almost never — which is why they are the single largest measurement gap in most device quality systems.
- Since the FDA's Quality Management System Regulation took effect on February 2, 2026, ISO 13485 Clause 7.3 — not the legacy 21 CFR 820.30 text — is the operative U.S. requirement for design controls.
- The MSI Design Control Signal Set organizes nine design control metrics into three layers: Input Integrity, Traceability, and Transfer Readiness.
- Leading indicators such as requirement volatility and verification coverage predict trouble; lagging indicators such as design-related complaints only confirm it after the cost is sunk.
- Seven of the nine measures apply unchanged to an integrated ISO 9001 and ISO 13485 system; only risk linkage and complaint attribution need adaptation to Clause 6.1 and Clause 9.1.2.
- Vanity measures — DHF page counts, review-meeting attendance, on-time milestone percentages — feel like real measures and measure nothing about design quality.
- Metrics create value only when they reach management review, where leadership can commit the resources that fix the underlying cause.
The Core Problem
Why Design Control Metrics Are the Missing Layer
Present. Complete. Unmeasured.
Ask a device quality director how their design controls are performing and you will usually get one of three answers: no open CAPAs from the last design audit, the DHF is complete, or we passed our notified body assessment. Each answer describes a state of documentation. None describes a state of capability. That distinction is the entire reason this measurement discipline matters.
Consider how a design failure actually unfolds. A user need is written ambiguously in month two. It generates a design input that two engineers interpret differently. Verification is written against one interpretation and passes. The mismatch surfaces during validation, or during production transfer, or — in the expensive case — during clinical use. At every one of those upstream points there was an observable signal. Requirement wording changed three times. One design input had no traceable verification. A verification protocol was written by the same engineer who wrote the requirement. Design control metrics are simply the discipline of watching those signals on purpose instead of reconstructing them afterward in a root cause investigation.
The pattern MSI sees across device engagements is consistent: organizations invest heavily in design control documentation and almost nothing in design control measurement. The result is a system that survives audits and still surprises its own leadership. Recall data reinforces the point — design-related causes account for a substantial share of device recalls, and the FDA's own recall analysis has long identified design as a leading contributor rather than manufacturing execution.
A complete Design History File proves the process ran. Design control metrics prove the process worked. Those are not the same claim, and only one of them predicts anything.
Three Reasons Design Control Metrics Get Skipped
The regulation never asked for them. Neither ISO 13485 Clause 7.3 nor the legacy design control regulation requires a metric. They require records, reviews, and traceability. An organization can be fully conformant and completely blind. Design control metrics are therefore voluntary — which in practice means they are the first thing cut when a program is behind.
Design work feels unmeasurable. Manufacturing has yield, scrap, and process capability. Design has judgment. Teams conclude that creative and analytical work resists quantification, and so they measure the only things that are easy: milestones and headcount. But these measures do not assess creativity. They measure the integrity of the control structure wrapped around it, which is entirely quantifiable.
Nobody owns the number. Quality owns the procedure. R&D owns the schedule. Regulatory owns the submission. Measurement of design control sits across all three, and shared ownership without a defined owner reliably produces no owner at all. MSI client experience suggests that naming a single accountable owner for the metric set is the highest-leverage first move an organization can make here.
Direct Answer
Why do most design control metrics programs fail? Most design control metrics programs fail for three structural reasons: no regulation requires them, so they are treated as optional; design work is assumed to be unmeasurable, so teams default to schedule metrics that say nothing about quality; and ownership sits across quality, engineering, and regulatory with no single accountable party. The programs that succeed name one owner, choose fewer than ten measures, and route the results into management review where resource decisions are actually made.
The Regulatory Reset
What the QMSR Changed for Design Control Metrics
Incorporated. Inspectable. Operative.
On February 2, 2026, the FDA's Quality Management System Regulation took effect, amending 21 CFR Part 820 to incorporate ISO 13485:2016 by reference. Published at 89 FR 7496, the rule replaced the prior Quality System Regulation. For measurement purposes this is not a paperwork detail — it changes which text your measurements should be built against.
The practical consequence is that ISO 13485 Clause 7.3 is now the operative design control requirement for finished devices marketed in the United States. The nine-element structure device professionals learned from the legacy 820.30 text — planning, inputs, outputs, review, verification, validation, transfer, changes, and the Design History File — still describes the work, but the clause numbering, the terminology, and the audit trail have shifted to the ISO subclauses 7.3.2 through 7.3.10. Any design control metrics dashboard still labelled with 820.30 subsections is now measuring against a superseded reference, and MSI's analysis of the FDA QMSR rule and ISO 13485 alignment walks through the full mapping.
Two further changes matter directly to measurement. First, the FDA retired the Quality System Inspection Technique and adopted Compliance Program 7382.850 for inspections of device manufacturers. Second — and this is the one that should reshape how design control metrics are reported — management review records and internal audit reports lost their long-standing exemption from FDA inspection. Under the QMSR, the place where these numbers get discussed is itself inspectable.
The reporting consequence. Before February 2026, an organization could present candid design performance data in management review knowing the record sat outside FDA inspection. That protection is gone. The correct response is not to sanitize the metrics — it is to make sure every unfavorable number in the record is paired with a dated, resourced action. A trending metric with a documented response is evidence of a working system. The same metric with no response is evidence of a known, unaddressed risk.
Direct Answer
Does the QMSR change which design control metrics you should track? The QMSR does not mandate any design control metrics, but it changes their reference frame and their exposure. Measurements should now map to ISO 13485 Clause 7.3 subclauses rather than legacy 21 CFR 820.30 subsections, because the QMSR incorporates ISO 13485:2016 by reference as of February 2, 2026. Management review and internal audit records are also now subject to FDA inspection, which means the design control metrics you present to leadership — and your documented response to them — are part of the inspectable record.
Where Design Control Metrics Sit Among the Standards
Design control measurement rarely draws on a single standard. Traceability requirements come from Clause 7.3, but risk linkage comes from ISO 14971:2019, usability evidence from IEC 62366-1, and software lifecycle records from IEC 62304. Practical implementation guidance for the risk side sits in ISO/TR 24971:2020. A metric set that ignores these connections measures the design file rather than the design.
| Requirement Source | What It Governs | What It Contributes to Measurement |
|---|---|---|
| ISO 13485 Clause 7.3 | Design and development planning through transfer and change control | The traceability spine — inputs to outputs to verification to validation |
| ISO 14971:2019 | Risk management across the device lifecycle | Risk-control linkage: every control traced to a hazard and verified |
| IEC 62366-1 | Usability engineering | Use-related requirement coverage and formative study closure |
| IEC 62304 | Medical device software lifecycle | Software unit and integration verification coverage |
| QMSR (21 CFR Part 820) | U.S. regulatory obligation, incorporating ISO 13485:2016 | Inspectability of the review record where metrics are presented |
The MSI Framework
The MSI Design Control Signal Set: Nine Design Control Metrics
Inputs. Traceability. Transfer.
MSI developed the Design Control Signal Set after 200+ audits attended across regulated industries, as a deliberately small answer to a common failure: organizations that try to measure everything about design end up measuring nothing that changes a decision. The set contains nine design control metrics, grouped into three layers that follow the sequence in which design failures actually propagate.
Layer one asks whether the design started from solid ground. Layer two asks whether the chain from need to evidence is intact. Layer three asks whether the design is genuinely ready to leave engineering. A weakness in layer one guarantees weakness in the layers above it, which is why the order matters as much as the individual measures.
Nine numbers, reviewed monthly, in the order failures actually travel. That is the whole framework — and it outperforms a forty-metric dashboard nobody reads.
Layer One — Input Integrity
Every downstream design control metric inherits the quality of the design inputs. If requirements are ambiguous, unstable, or untraceable to a user need, no amount of verification rigor will produce a trustworthy result. These three measures test the foundation.
Metric 1
Requirement Volatility Index. The percentage of design inputs that changed after the design input freeze, measured per phase. Calculate it as requirements changed divided by total requirements, expressed as a percentage. Sustained volatility above roughly 15% after freeze usually indicates that user needs were never adequately resolved, not that the team is being appropriately responsive. This is the earliest and most predictive of the nine, because requirement churn drives verification rework, schedule pressure, and the shortcut decisions that produce findings.
Metric 2
Input Ambiguity Rate. The percentage of design inputs that fail a testability review — meaning a competent engineer could not write a pass/fail verification protocol from the requirement as written. Sample twenty requirements per phase and score them. Requirements containing words like adequate, user-friendly, minimal, or reasonable fail automatically. Of all nine measures, this one most reliably predicts conflated verification and validation later in the program.
Metric 3
Risk-to-Requirement Linkage. The percentage of risk control measures in the Risk Management File that trace to a specific, verifiable design input. A risk control that exists only in the risk file and never became a requirement is a control that will not be verified and will not be transferred. This metric is where ISO 14971 and Clause 7.3 meet, and a score below 100% is a defect in the system rather than a target for improvement.
Direct Answer
What is the most predictive of the design control metrics? Requirement Volatility Index is the most predictive single measure. It tracks the percentage of design inputs that change after the input freeze, and because requirement churn is the upstream driver of verification rework, schedule compression, and shortcut decisions, it moves before any other indicator does. Organizations that track only one of the nine design control metrics should track this one — but it is genuinely more useful paired with Input Ambiguity Rate, because volatile requirements and vague requirements have different root causes and different fixes.
Layer Two — Traceability
Traceability is the load-bearing structure of Clause 7.3. It is also where most design control metrics programs discover their real condition, because a traceability matrix that looks complete in a spreadsheet frequently breaks under sampling. These three measures test the chain rather than admiring it.
Metric 4
Trace Chain Completeness. The percentage of user needs with an unbroken chain to design input, design output, verification record, and validation evidence. Score a chain as complete only if every link is present and current. Partial credit defeats the purpose. This is the headline number in the set because a regulator sampling your design history file is performing exactly this test, one thread at a time.
Metric 5
Verification Coverage. The percentage of design outputs with a completed, approved verification record demonstrating conformance to the corresponding input. Track this as a running figure across the program rather than a phase-gate snapshot. The gap between planned and actual coverage is verification debt, and like technical debt it compounds — teams that let coverage drift below plan mid-program almost always compress verification at exactly the point where schedule pressure is highest.
Metric 6
Design Review Effectiveness. The number of substantive issues raised and formally recorded per design review, trended over the program. Reviews that consistently produce zero or one recorded issue are ceremonial. Reviews that produce issues only in late phases indicate that early reviews were not doing their job. Among the nine, this is the only one where a rising number in early phases is the healthy signal.
Direct Answer
How do you measure design traceability? Measure traceability with Trace Chain Completeness: the percentage of user needs that have an unbroken, current chain through design input, design output, verification record, and validation evidence. Score each chain as complete or incomplete with no partial credit, because a chain with one missing link fails the same sampling test a regulator or notified body would apply. Pair it with Verification Coverage — the share of design outputs carrying an approved verification record — so that traceability breadth and verification depth are visible as separate design control metrics rather than a single blended number.
Layer Three — Transfer Readiness
Design transfer under Clause 7.3.8 is where a design meets manufacturing reality, and it is the most frequently under-measured stage in the lifecycle. These final three measures test whether the design is genuinely ready to leave engineering ownership.
Metric 7
Transfer Readiness Score. The percentage of transfer criteria — process validation, tooling qualification, inspection method capability, supplier qualification, labeling and packaging verification — that are complete and approved at the transfer decision point. Organizations typically report that transfer decisions get made at 70% to 80% readiness under schedule pressure, with the remainder closed retroactively. Making that percentage visible before the decision changes the conversation.
Metric 8
Post-Transfer Change Rate. The number of design changes raised in the first ninety days after transfer, normalized per hundred design outputs. This is the sharpest lagging indicator in the set, and it functions as the scoreboard for everything upstream. A high rate means the design left engineering before it was finished, regardless of what the readiness score claimed. Change control under Clause 7.3.9 is where those chickens come home, and MSI's guide to change management automation covers how to keep that process from becoming the bottleneck.
Metric 9
Design-Attributable Complaint Share. The percentage of post-market complaints whose investigation concludes a design cause rather than a manufacturing, labeling, or use cause. This closes the loop from the field back to design control performance. Tracked over successive product generations, it is the only measure that tells you whether your design control system is genuinely improving rather than merely producing more documentation.
Self-Assessment
Scoring Your Design Control Metrics Against the Signal Set
Score. Band. Act.
The Signal Set is only useful if it produces a decision. Score each of the nine design control metrics on a 0 to 3 scale, total the result out of 27, and read the band. Run the assessment at each phase gate rather than annually — the value is in the trend, not the snapshot.
| Score | What It Means for That Metric |
|---|---|
| 0 | Not measured. The data does not exist in retrievable form. |
| 1 | Measured on request. Someone can assemble it for an audit, but nobody watches it. |
| 2 | Measured routinely and trended, but not tied to a defined threshold or action. |
| 3 | Measured, trended, threshold-defined, and routed to management review with a named owner. |
Reading Your Total
- 0–8 — Documented but blind. Design controls exist as records only. The organization will pass a conformity audit and be surprised by its own field data. Start with Metrics 1, 4, and 8 — one from each layer.
- 9–17 — Measuring without deciding. Data exists and gets reported, but no threshold triggers action. This is the most common band and the most frustrating one, because the effort has already been spent. The fix is thresholds and ownership, not more measurement.
- 18–23 — Working system. Measurement informs decisions in most phases. Focus on the two or three lowest-scoring measures rather than adding new ones.
- 24–27 — Predictive capability. The organization can forecast design risk before it materializes. At this level, design control metrics become a genuine competitive asset in supplier qualification and diligence.
Direct Answer
How should design control metrics be scored and reviewed? Score each measure on a 0 to 3 scale — not measured, measured on request, measured and trended, or measured with defined thresholds and a named owner routing results to management review. Total the nine design control metrics out of 27 and reassess at each phase gate rather than annually, because the trend across gates carries the signal. Below 18, the constraint is almost always thresholds and ownership rather than data availability, which means the fix costs decision discipline rather than measurement infrastructure.
What To Stop Measuring
Five Measures That Look Like Design Control Metrics and Are Not
Busy. Comfortable. Useless.
Substituting activity measures for real ones is worse than measuring nothing, because it manufactures confidence. Each of the following appears on real device dashboards and none of them says anything about whether the design is sound.
Design History File page count or completeness percentage. Measures documentation volume. A complete file assembled from ambiguous requirements and conflated verification is complete and wrong. Trace Chain Completeness measures the same file in a way that can actually fail.
Design review meeting attendance. Measures calendar compliance. Design Review Effectiveness — issues raised per review — measures whether anything happened in the room.
On-time phase gate percentage. Measures schedule adherence and actively rewards passing gates with open items. Transfer Readiness Score measures the same gate on the dimension that predicts post-transfer pain.
Number of verification protocols executed. Measures effort. Verification Coverage measures whether the protocols executed actually covered the outputs that needed covering.
Training completion percentage on the design control procedure. Measures awareness. Necessary, and entirely uncorrelated with design quality. MSI's work on training effectiveness measurement explains why completion rates sit at the shallowest level of any competence framework.
The substitution test. For any candidate measure, ask: could this number be excellent while the device is dangerous? If yes, it is an activity measure, not one of your design control metrics. Every one of the five above fails that test. All nine in the Signal Set pass it.
Direct Answer
What design control metrics should organizations stop tracking? Stop tracking measures that can look excellent while the device is unsafe: Design History File completeness percentage, design review attendance, on-time phase gate percentage, count of verification protocols executed, and procedure training completion rate. Each measures activity or documentation volume rather than design integrity. The substitution test is straightforward — if a number could be perfect while the product is defective, it is not among your design control metrics, and it should be replaced by the measure that tests the same activity for effect rather than occurrence.
Closing The Loop
Routing Design Control Metrics Into Management Review
Report. Decide. Resource.
A metric that stops at the engineering status meeting cannot fix anything structural. Requirement volatility is usually a resourcing or stakeholder-alignment problem. Verification debt is usually a capacity problem. Transfer readiness compression is almost always a commercial-pressure problem. All three are leadership decisions, which means design control metrics have to reach the management review table to do their job.
ISO 13485 Clause 5.6 defines the management review inputs, and design control performance is a natural fit under monitoring and measurement results, process performance, and recommendations for improvement. Under the QMSR, that record is inspectable — which raises the standard for how the numbers are presented. MSI's ISO management review training covers the mechanics of building a review that produces decisions rather than a slide deck.
A Working Reporting Format
- Trend, not snapshot. Present each metric across the last four phase gates. A single number invites debate about whether it is good; a trend line invites discussion of why it is moving.
- Threshold breaches only. Report the full set, but give agenda time only to metrics that crossed a defined threshold. This keeps the set from consuming a review that also has to cover complaints, CAPA, audits, and supplier performance.
- One named owner per breach. Every unfavorable number leaves the room with a name and a date attached, recorded in the minutes.
- Resource ask stated explicitly. If the fix requires headcount, test capacity, or schedule relief, say so in the review. Leadership cannot approve an unstated request, and the record should show the ask was made.
Direct Answer
How do design control metrics connect to management review? Design control metrics belong in management review under ISO 13485 Clause 5.6 as monitoring and measurement results, process performance data, and recommendations for improvement. The reason is practical rather than procedural: the root causes behind poor design control metrics — requirement instability, verification capacity, and schedule compression at transfer — are resourcing decisions that only leadership can make. Present trends rather than snapshots, give agenda time only to threshold breaches, and attach a named owner and date to every unfavorable number in the minutes.
Dual-Certified Organizations
Design Control Metrics in an Integrated ISO 9001 and ISO 13485 System
Two standards. One measurement set.
Many device manufacturers run a single quality system certified to both ISO 9001 and ISO 13485 — often because a corporate parent, a contract manufacturing arm, or a non-device product line brings ISO 9001 obligations alongside the device requirements. That combination creates a real question about which design control metrics apply where.
The structural point is that ISO 13485:2016 predates Annex SL and deliberately retained the older clause architecture. It does not share the harmonized ten-clause high-level structure of ISO 9001. Design and development lives at Clause 7.3 in ISO 13485 and Clause 8.3 in ISO 9001, and the requirements are close but not identical: ISO 13485 adds design transfer as an explicit subclause, requires the Design History File, and carries risk management obligations that ISO 9001 does not.
For measurement, the practical answer is that seven of the nine measures apply unchanged to both standards. Two need adaptation. Risk-to-Requirement Linkage depends on an ISO 14971 Risk Management File, which ISO 9001 organizations will not have — the equivalent is linkage to the risk register maintained under Clause 6.1. Design-Attributable Complaint Share depends on a complaint handling process with device-specific classification, which ISO 9001 organizations approximate through customer feedback categorization under Clause 9.1.2.
| Element | ISO 13485 Clause 7.3 | ISO 9001 Clause 8.3 |
|---|---|---|
| Design transfer | Explicit subclause 7.3.8 with defined records | Implicit within design and development outputs |
| Risk management | Required throughout, per ISO 14971 | Risk-based thinking, no prescribed method |
| Design file | Design History File required per project | Retained documented information, no prescribed file |
| Clause structure | Pre-Annex SL architecture retained | Harmonized ten-clause high-level structure |
Mapping the Nine Measures to ISO 9001 Clause 8.3
The table below maps each measure in the Signal Set to its anchor in both standards, and names the two that need adaptation. Organizations running an integrated system should print this mapping into the procedure itself so that a single measurement definition serves both certificates and no auditor from either scheme finds an orphaned requirement.
| Measure | ISO 13485 Anchor | ISO 9001 Anchor | Adaptation for ISO 9001 |
|---|---|---|---|
| Requirement Volatility Index | 7.3.3 Design inputs | 8.3.3 Design inputs | None — applies identically |
| Input Ambiguity Rate | 7.3.3 Design inputs | 8.3.3 Design inputs | None — applies identically |
| Risk-to-Requirement Linkage | 7.3.2 Planning, with ISO 14971 | 6.1 Risk-based thinking | Adapt — trace to the Clause 6.1 risk register instead of a Risk Management File |
| Trace Chain Completeness | 7.3.3–7.3.7 Inputs to validation | 8.3.3–8.3.4 Inputs and controls | None — applies identically |
| Verification Coverage | 7.3.6 Design verification | 8.3.4 Design controls | None — applies identically |
| Design Review Effectiveness | 7.3.5 Design review | 8.3.4 Design controls | None — applies identically |
| Transfer Readiness Score | 7.3.8 Design transfer | 8.3.5 Design outputs | Light adapt — ISO 9001 has no transfer subclause; score against production-readiness criteria in the output requirements |
| Post-Transfer Change Rate | 7.3.9 Control of changes | 8.3.6 Design changes | None — applies identically |
| Design-Attributable Complaint Share | 8.2.2 Complaint handling | 9.1.2 Customer satisfaction | Adapt — classify customer feedback by root cause rather than device complaint codes |
Direct Answer
Do design control metrics work under ISO 9001 as well as ISO 13485? Yes. Seven of the nine design control metrics in the Signal Set map directly onto ISO 9001 Clause 8.3 with no change — requirement volatility, input ambiguity, trace chain completeness, verification coverage, design review effectiveness, post-transfer change rate, and transfer readiness all measure activities both standards require. Two need adaptation: Risk-to-Requirement Linkage traces to the Clause 6.1 risk register rather than an ISO 14971 Risk Management File, and Design-Attributable Complaint Share draws on Clause 9.1.2 customer feedback analysis rather than device complaint classification.
What ISO 9001:2026 Adds to the Picture
The next edition of ISO 9001 reached FDIS with the ballot closing July 9, 2026 and publication expected in September 2026, and it introduces a quality-culture requirement at Clause 5.1 that has no predecessor in the 2008 or 2015 editions. That requirement bears directly on design control metrics, because culture is what determines whether the numbers are honest.
Design Review Effectiveness is the clearest example. It counts substantive issues raised and recorded per review — a measure that collapses immediately in an organization where raising an issue late in a program is treated as an act of disloyalty. The metric will read as a healthy zero while the review does nothing. The same dynamic distorts Requirement Volatility Index, where teams quietly absorb changes without recording them to protect a phase gate. Under the incoming Clause 5.1, leadership will need to demonstrate the culture that makes candid measurement possible, and MSI's analysis of the ISO 9001:2026 update on ethics and culture covers what that will require of leadership teams.
The integration trap. Dual-certified organizations often maintain two measurement definitions — one written for the device business, one written loosely for the ISO 9001 scope — on the theory that the ISO 9001 side faces a lighter standard. It reliably backfires. The two definitions drift, the shared engineering team ends up applying whichever is more convenient, and the eventual finding lands on the device side where it costs the most. Define the design control metrics once, at the stricter ISO 13485 level, and apply the same definition across every product line.
For ISO 9001 Organizations That Do Not Make Devices
The Signal Set was built in a device context, but nothing in seven of the nine measures is device-specific. Engineering consultancies, industrial equipment manufacturers, software companies, and contract design houses all run Clause 8.3 design and development processes, and all face the same failure sequence: ambiguous inputs, broken traceability, and a design pushed into production before it is finished. MSI's work on ISO for engineering firms shows the same discipline applied outside the regulated device sector, and the ISO 9001 quality standard overview covers where Clause 8.3 sits in the wider system.
Two differences are worth naming. ISO 9001 permits design and development to be excluded from scope where it genuinely does not apply, which ISO 13485 does not — so the first question for an ISO 9001 organization is whether Clause 8.3 is in scope at all. And ISO 9001 organizations rarely have a formal transfer stage, which means Transfer Readiness Score has to be defined against production-readiness criteria written into the design output requirements rather than a named transfer gate. Both adaptations are straightforward once the measure is defined deliberately instead of inherited.
Organizations running both standards from one procedure set get the strongest result when the measures are defined once, at the stricter ISO 13485 level, and applied across the whole system. MSI's guidance on integrated management systems covers how to build that single-procedure approach without creating two parallel measurement regimes. Teams weighing whether the effort is worth it will find the case laid out in MSI's piece on the quality management mindset.
Put It Into Practice
Turn Design Control Metrics Into a Working System
Define. Measure. Decide.
Measurement without a procedure behind it does not survive the first schedule crunch. The design control metrics in the Signal Set only stay alive when the underlying design and development procedure names them, defines their thresholds, and assigns their owners. That is the difference between a dashboard and a system.
Start with the procedure the metrics attach to. MSI's ISO 13485 Design and Development Procedure Template and Guide gives device organizations a complete, editable Clause 7.3 procedure with the traceability structure, review criteria, and transfer requirements already built in — the judgment calls made, so your team defines thresholds instead of drafting from a blank page.
Running one system against both standards? The ISO 9001 and 13485 Integrated Design and Development Procedure handles Clause 8.3 and Clause 7.3 in a single procedure set, including the integration decision record that documents why each requirement was harmonized the way it was — the appendix auditors ask about and most integrated systems cannot produce.
Need your team fluent in the process first? The Design and Development Training Video Series walks engineering and quality teams through a compliant design and development process end to end, so the people generating the data understand what the measures are actually testing.
Want the leadership conversation first? The ISO Executive Decision Briefs let executives watch the decisions only leadership can make — resourcing, thresholds, and ownership — before a measurement program is designed. Or talk it through directly: schedule a planning session with an MSI consultant at 760-434-9141.
For organizations that want the whole system built rather than assembled, MSI's SurePath turnkey certification program covers implementation end to end, and its ISO consulting practice has supported 80+ certifications across manufacturing, technology, medical device, government, and healthcare organizations over 28 years.
Go Deeper
Related Reading on Design and Measurement
Context. Method. Practice.
Design control metrics sit inside a wider measurement and design discipline. These MSI resources cover the adjacent ground.
- Design and Development Procedure: 7 Marks Most Never Meet — the pillar on building the procedure these metrics attach to.
- Project Management Quality Measurement: Metrics That Win — the broader QMS measurement framework, including cost of quality and leading versus lagging indicators.
- Medical Device Threat Modeling: Why Rationale Wins — threat modeling as design rationale under Clauses 7.3.3 through 7.3.5.
- Medical Device Cybersecurity: The Critical QMS Shift — how the QMSR relocated cybersecurity expectations into ISO 13485 subclauses.
- Why Most Medical Startups Misread ISO 13485 — the early-stage decisions that create design control debt.
- Advanced ISO 9001 Design and Development — the MSI design and development maturity model.
- ISO 13485 — Medical Devices — what the standard requires and what certification involves.
- Internal Audits — how independent auditing tests the same chains these metrics measure.
- Effective ISO Procedure: The Proven Test That Matters — the test any procedure must pass before it can carry a metric.
- Quality Improvement Culture: Why 7 Proven Steps Stick — why measurement fails without psychological safety.
- ISO for Engineering Firms: Prove Every Design — the same discipline applied outside the device sector.
- ISO Procedure Templates and Guides — the full template library across five standards.
Common Questions
Frequently Asked Questions About Design Control Metrics
Ask. Answer. Apply.
What are design control metrics?
Design control metrics are quantified measures of how well an organization's design and development controls are performing — the integrity of design inputs, the completeness of traceability from user need through verification and validation, and the readiness of a design to transfer to production. They differ from audit findings in that they are continuous and predictive rather than periodic and retrospective. The purpose is to detect requirement instability, verification debt, and traceability breaks while corrections are still inexpensive.
How many design control metrics should an organization track?
Fewer than ten. MSI's Design Control Signal Set uses nine, grouped into three layers of three. Organizations that track thirty or forty measures reliably end up reviewing none of them, because no management review has time to discuss forty numbers alongside complaints, CAPA, supplier performance, and audit results. A small set with defined thresholds and named owners outperforms a comprehensive dashboard every time.
Does ISO 13485 require design control metrics?
No. ISO 13485 Clause 7.3 requires design and development planning, inputs, outputs, review, verification, validation, transfer, and change control, along with the associated records. It does not require any metric. That is precisely why design control metrics are the largest voluntary capability gap in most device quality systems — organizations build exactly what is required and remain unable to answer whether the system is working.
Did the FDA QMSR change design control requirements?
The QMSR took effect February 2, 2026 and amended 21 CFR Part 820 to incorporate ISO 13485:2016 by reference, making Clause 7.3 the operative U.S. design control text in place of the legacy 21 CFR 820.30 provisions. The substantive expectations moved very little; the reference frame moved entirely. Two changes matter for measurement — the FDA replaced the Quality System Inspection Technique with Compliance Program 7382.850, and management review and internal audit records became subject to FDA inspection.
What is the difference between leading and lagging design control metrics?
Leading design control metrics — requirement volatility, input ambiguity, verification coverage — move before a problem materializes and give teams time to intervene. Lagging measures such as post-transfer change rate and design-attributable complaint share confirm what already happened. A usable set needs both: leading indicators to steer the current program, lagging indicators to verify that the changes made to the last program actually worked.
Can a small device company use design control metrics?
Yes, and the arithmetic is easier at small scale. A team of eight can score Trace Chain Completeness by hand across a few dozen user needs in an afternoon. Start with three measures — one from each layer of the Signal Set — rather than all nine. The principles of input integrity, unbroken traceability, and honest transfer readiness apply regardless of headcount, and small organizations usually see the trend more clearly because there is less noise in the data.
How do design control metrics apply to an integrated ISO 9001 and ISO 13485 system?
Seven of the nine measures apply unchanged to both standards. Two need adaptation, because ISO 13485 retains a pre-Annex SL clause structure and carries obligations ISO 9001 does not: Risk-to-Requirement Linkage depends on an ISO 14971 Risk Management File, which an ISO 9001 organization replaces with its Clause 6.1 risk register, and Design-Attributable Complaint Share depends on device complaint classification, approximated through Clause 9.1.2 customer feedback analysis. Define the metric set once at the stricter ISO 13485 level and apply it system-wide.
Who should own design control metrics?
One named person, with authority across quality and engineering. Shared ownership between quality, R&D, and regulatory reliably produces no ownership at all, and the metrics quietly stop being maintained during the first schedule crunch. The owner does not need to generate the data — engineering will — but they must own the definition, the threshold, the trend, and the presentation to management review.
Should an integrated ISO 9001 and ISO 13485 system use one set of design control metrics or two?
One. Maintaining a looser ISO 9001 definition alongside a stricter ISO 13485 definition seems efficient and reliably backfires: the two drift apart, a shared engineering team applies whichever is more convenient, and the resulting finding lands on the device side where the cost is highest. Define each measure once at the ISO 13485 level and apply it across every product line. The two measures that need adaptation — risk linkage and complaint attribution — should be written as a single definition with a named alternative source, not as a separate ISO 9001 metric set.
The Bottom Line
Make Design Control Metrics the Norm, Not the Exception
Prove. Improve. Repeat.
Device organizations rarely fail because they lack a design control procedure. They fail because the procedure ran correctly and nobody was watching whether it worked. Design control metrics close that distance — and they do it with nine numbers, not ninety.
The organizations that get this right share three traits. They measure input integrity before they measure anything downstream, because everything downstream inherits it. They score traceability with no partial credit, because a regulator sampling the Design History File will not offer any. And they route every unfavorable number to management review with a named owner and a date, because the root causes are resourcing decisions leadership alone can make.
Under the QMSR, that review record is inspectable. That is not a reason to soften the numbers — it is the strongest argument yet for pairing every honest metric with a documented, resourced response. A design control metrics program that shows problems found and fixed is the clearest evidence a device organization can offer that its quality system is doing real work.
Design controls tell a regulator that you followed a process. Design control metrics tell your own leadership whether the process is protecting anyone. Only one of those is worth building.
References & Sources
International Organization for Standardization. ISO 13485:2016 — Medical devices: quality management systems. www.iso.org/standard/59752.html
International Organization for Standardization. ISO 14971:2019 — Application of risk management to medical devices. www.iso.org/standard/72704.html
International Organization for Standardization. ISO/TR 24971:2020 — Guidance on the application of ISO 14971. www.iso.org/standard/74437.html
International Electrotechnical Commission. IEC 62304 — Medical device software lifecycle processes. www.iso.org/standard/38421.html
International Electrotechnical Commission. IEC 62366-1 — Application of usability engineering to medical devices. www.iso.org/standard/63179.html
International Organization for Standardization. ISO 9001 — Quality management systems. www.iso.org/iso-9001-quality-management.html
Electronic Code of Federal Regulations. 21 CFR Part 820 — Quality Management System Regulation. www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-820
Federal Register. Medical Devices; Quality System Regulation Amendments, 89 FR 7496. www.federalregister.gov/documents/2024/02/02/2024-01709/medical-devices-quality-system-regulation-amendments
U.S. Food and Drug Administration. Quality Management System Regulation final rule resources. www.fda.gov/medical-devices/quality-and-compliance-medical-devices
U.S. Food and Drug Administration. Design Control Guidance for Medical Device Manufacturers. www.fda.gov/regulatory-information/search-fda-guidance-documents/design-control-guidance-medical-device-manufacturers
U.S. Food and Drug Administration. Medical Device Recall Report analysis. www.fda.gov/medical-devices/medical-device-recalls/medical-device-recall-report-fy2003-fy2012
U.S. Food and Drug Administration. Medical Device Single Audit Program (MDSAP). www.fda.gov/medical-devices/cdrh-international-programs/medical-device-single-audit-program-mdsap
U.S. Food and Drug Administration. MAUDE — Manufacturer and User Facility Device Experience database. www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/search.cfm
International Medical Device Regulators Forum. IMDRF guidance documents. www.imdrf.org/
Association for the Advancement of Medical Instrumentation. AAMI standards and guidance for medical device quality. www.aami.org/
American Society for Quality. Failure Mode and Effects Analysis (FMEA). asq.org/quality-resources/fmea
American Society for Quality. Control Chart. asq.org/quality-resources/control-chart
Global Accreditation Cooperation International. Accreditation body directory and recognition arrangements. global-aci.org/
National Institute of Standards and Technology. Measurement science and quality infrastructure resources. www.nist.gov/
About Management Systems International (MSI)
Management Systems International (MSI) is a veteran-owned, female-owned ISO consulting firm founded in 1998. With 28 years of experience including extensive AS9100 work in MSI's early years, MSI's track record includes 80+ certifications supported, 200+ audits attended, and 600+ professionals trained across manufacturing, technology, medical device, government, healthcare, and other regulated industries.
Today MSI implements ISO 9001, ISO 13485, ISO 14001, and ISO 45001, with an expanding focus on ISO 7101 healthcare quality.
msi-international.com · 760-434-9141
