What Level 1 Design Controls Maturity Looks Like in Medical Device Organizations

The design history file arrives on your desk six weeks after product launch. It's a binder of test reports, meeting minutes, and email printouts arranged in roughly chronological order. There's no traceability matrix. The design review minutes don't record decisions — they record attendance. You're not sure which version of the design inputs the verification testing was run against.

This is Level 1. Not the absence of design activity, but the absence of design control. Engineers are designing. They are prototyping, testing, iterating, and shipping. What they are not doing is capturing the rationale, the requirements chain, or the verification evidence in a way that anyone — a regulator, a successor, a manufacturing engineer — can reconstruct after the fact.

The Tribal Knowledge Engine

Level 1 organizations run on institutional memory held by individuals. The senior engineer who has been through three product launches knows what the FDA expects, knows which tests matter, knows where the previous design ran into trouble. That knowledge drives design decisions daily. None of it is documented.

When that engineer moves to a different division, retires, or simply takes a two-week vacation during a critical design review period, the project stalls. Not because the work cannot continue, but because nobody else knows what "done" looks like for this particular design phase. The criteria for moving from concept to detailed design exist in one person's head. The rationale for selecting a particular material exists in a conversation that happened in a hallway eight months ago.

This dependency on individuals is not a staffing problem. It is a design control problem. 21 CFR 820.30 requires a documented design and development plan that identifies phases, review points, activities, and responsibilities. The plan exists so the organization can execute the design regardless of which individuals are available on any given day. Without it, the design control process is the people, and when the people change, the process changes with them.

What the Design History File Actually Contains

Open a Level 1 DHF and you will find evidence that work happened. Test reports from the lab. Specification sheets from suppliers. Emails forwarding customer feedback. PowerPoint slides from a management update. What you will not find is the thread connecting these artifacts into a coherent design narrative.

The test reports do not reference a verification protocol, because no protocol was written before testing began. The specifications do not map to design inputs, because design inputs were never formally established. The customer feedback was not translated into measurable requirements. The management slides summarize progress but do not record the technical decisions that shaped the design direction.

An FDA investigator tracing a single requirement from user need through design input, design output, verification, and validation will reach a dead end within the first two links. The user need may not be documented at all. If it is, the corresponding design input may be a vague statement like "device must be safe and effective" with no measurable acceptance criteria. The investigator does not need to go further. The observation writes itself.

Why Verification Fails at This Level

First-pass verification yield at Level 1 typically falls below 50 percent. This number sounds like a product quality problem, but it is overwhelmingly a requirements quality problem. When design inputs are ambiguous, acceptance criteria are ambiguous. When acceptance criteria are ambiguous, verification results are ambiguous. A test that "passes" under one interpretation of the requirement "fails" under another.

The response at Level 1 is to rewrite the acceptance criteria after the test to match the result that was obtained. This practice inverts the entire purpose of design verification under 820.30(f), which requires confirming that design outputs meet design inputs. If the acceptance criteria are derived from the test result rather than from the design input, the verification is circular. It proves nothing.

Protocol amendments during execution are another hallmark. When the test setup does not match what the design input implied, the team writes a protocol amendment, adjusts the setup, and reruns. Across a full verification campaign, a Level 1 project may generate more amendments than original protocols. Each amendment consumes engineering time, delays the project timeline, and introduces documentation complexity that the DHF was never structured to manage.

The Regulatory Exposure You Cannot See

Level 1 organizations often believe their regulatory risk is limited to documentation gaps that can be addressed before an audit. This underestimates the problem. The risk is not that the DHF is incomplete. The risk is that the design itself may contain unverified assumptions, uncontrolled changes, and unmitigated hazards that no one can identify because the records do not exist.

Risk management at Level 1, if it exists, runs as a parallel exercise disconnected from design decisions. The risk file lists hazards and mitigations, but mitigations are not traced as design inputs, and verification of mitigation effectiveness is not part of the verification plan. Under ISO 14971, risk controls must be verified. At Level 1, they often are not, because the design control process and the risk management process do not talk to each other.

For EU MDR, the technical documentation requirements in Annex II presume systematic design controls. The requirement for a complete description of design verification and validation data, the requirement for demonstration that the device conforms to general safety and performance requirements, the requirement for integrated clinical evaluation — all of these assume that design control records exist, are complete, and tell a coherent story. Level 1 organizations cannot produce this documentation because the underlying activities were never structured to generate it.

The Path Forward

Moving from Level 1 to Level 2 does not require a massive quality system overhaul. It requires five specific actions, executed in order.

Establish a design and development procedure. Keep it short. Define the phases, the required deliverables, the review gates, and the roles. Map it to 820.30 subsections and ISO 13485 Section 7.3. This document becomes the backbone that every other improvement attaches to.

Implement a design input template with mandatory fields: unique identifier, source user need, measurable acceptance criteria, verification method, and risk traceability. This single template eliminates the root cause of most downstream verification failures.

Formalize design reviews. Define who attends, what materials are prepared in advance, what criteria must be met to enter and exit the review, and how decisions are recorded. Ensure independent review per regulatory requirements.

Start the traceability matrix at project kickoff, not at project close. Populate it as inputs, outputs, and verification results are created. A traceability matrix built in real time is a design management tool. One assembled after the fact is a compliance artifact.

Conduct a gap assessment against 820.30 and ISO 13485 Section 7.3. Document the current state honestly. This assessment becomes the basis for your remediation plan and demonstrates management commitment to the improvement.

These five actions do not make you excellent. They make you structured. Structure is the prerequisite for everything that follows.

Assess your current state with the MedTechCMM design controls assessment at /assessments/design-controls.