Design Freeze is a controlled milestone in medical device development when the design is locked, and no further changes are permitted without formal change control. It marks the point where design outputs are finalized, allowing verification, validation, and design transfer to proceed against a stable, documented baseline.
What is Design Freeze?
A Design Freeze (also called a design lock or feature freeze) is the formal point in a device program where the design baseline becomes fixed. After this gate, the design outputs, meaning drawings, specifications, bills of materials, and software builds, are placed under strict change control. Any modification then requires a documented engineering change order, an impact assessment, and re-approval.
It usually sits late in the design and development phase under design controls, after most design verification and before design transfer to manufacturing. The freeze does not mean engineering work stops. It means changes stop being casual and start being governed.
Why Design Freeze matters in medical device development
A device file is only as trustworthy as the baseline it describes. If the design keeps shifting while verification testing runs, your evidence no longer maps to the product you ship. That gap is exactly what auditors and notified bodies look for.
Under FDA 21 CFR Part 820.30 and ISO 13485, design verification and validation must be performed against approved design outputs. Without a freeze, teams test against a moving target, then discover late that a “small” change invalidated a passing test. The cost of that rework climbs steeply the closer you get to launch.
Patient safety is the deeper reason. A late, undocumented change can break a risk control that ISO 14971 says must hold. A freeze forces every change after the lock through risk re-assessment, so safety-relevant edits cannot slip in quietly.
The freeze also protects the schedule and budget. It gives manufacturing a stable target for tooling, process validation, and supplier qualification. Pour money into IQ/OQ/PQ on a design that is still changing, and you may pay for it twice.
How a Design Freeze works
A Design Freeze is a planned gate, not a sudden event. It works best as a phase-gate review with clear entry and exit criteria. A typical sequence:
- Set freeze criteria up front. Define in the design and development plan what “frozen” means: which outputs lock, what level of verification must be complete, and what open items are acceptable.
- Confirm design outputs are complete. Specifications, schematics, CAD, software versions, and the BOM must be approved and traceable to design inputs.
- Check verification status. Most design verification testing should be done or scheduled against the frozen configuration, per 21 CFR 820.30(f). For software, the IEC 62304 version baseline is fixed here.
- Review risk and usability. Confirm the ISO 14971 risk file and IEC 62366-1 usability work reflect the locked design.
- Hold the gate review. Cross-functional approvers (engineering, QA/RA, manufacturing) sign off and record the decision in the design history file.
- Switch to formal change control. After the freeze, every change runs through an engineering change order with impact analysis and re-verification as needed.
The standards do not always use the phrase “design freeze,” but the concept lives inside their requirements for controlled design outputs, change control, and design transfer.
Common challenges and best practices
The most common mistake is freezing too early or too late. Freeze before verification is mature, and you will reopen the baseline repeatedly, which defeats the purpose. Freeze after manufacturing has already committed to tooling, and you have lost the protection the gate exists to give.
A second problem is the “soft freeze” that everyone ignores. If changes keep flowing without going through change control, the freeze is theater. Teams should treat the locked baseline as genuinely locked and route exceptions through a documented, traceable process.
Hardware and software often freeze on different clocks, and that catches teams out. Firmware may need one more iteration after the mechanical design is set. Plan staged freezes with explicit dependencies rather than pretending everything locks on the same day.
Good practice looks like this: write measurable freeze criteria into the plan early, keep a single source of truth for the configuration, and make sure the risk file and verification evidence both point at the same baseline. Keep a short, visible log of every post-freeze change so an auditor can reconstruct exactly what moved and why.
How SJML helps with Design Freeze
Syrma Johari MedTech (SJML) runs device programs through phase-gate management with built-in change control, so a Design Freeze becomes a documented, defensible milestone rather than an informal handoff. Our teams cover mechanical, electronics, embedded, and systems engineering, with risk management to ISO 14971 and usability engineering to IEC 62366 integrated through the design phase. In-house labs for IEC 60601 electrical safety, EMC, and reliability testing let verification run against the frozen baseline before design transfer (DfX). That continuity from design through manufacturing helps shorten time-to-market while keeping the design history file audit-ready.
Talk to SJML’s engineering team →
Frequently asked questions
A Design Freeze typically happens late in the design and development phase, after most design verification is complete and before design transfer to manufacturing. Freezing too early forces repeated reopening of the baseline. Freezing too late wastes money on tooling and process validation built around a design that is still changing. Tie the timing to defined, measurable criteria in your design plan.
The exact phrase “Design Freeze” does not appear in FDA 21 CFR Part 820.30 or ISO 13485, but the concept is required in substance. Both demand approved design outputs, controlled changes, and verification against a defined configuration. A freeze is the practical mechanism teams use to satisfy those requirements and create a stable baseline for the design history file.
A soft freeze discourages new changes but still allows minor edits with light oversight, often used while late verification wraps up. A hard freeze fully locks the baseline, so any change requires a formal engineering change order, impact assessment, and re-approval. Many programs move from soft to hard freeze in stages, especially when hardware and software lock on different schedules.
Yes, but only through formal change control. After the freeze, a change needs a documented engineering change order, an impact analysis covering risk and verification, and re-approval by the relevant functions. The change and its rationale are recorded in the design history file. This keeps post-freeze edits traceable and ensures safety-relevant changes get re-assessed under ISO 14971.
Related terms
- Design Controls
- Design Verification
- Design Validation
- Design Transfer
- Change Control
