Design Qualification (DQ)
Frequently Asked Questions

DQ is the formal, documented confirmation that the finalized design — drawings, specifications, and vendor documentation taken together — actually satisfies every URS requirement and applicable regulatory standard, whereas reviewing a vendor proposal or the URS in isolation only confirms intent, not that the completed design closes every gap.

A vendor proposal review typically checks feasibility and cost; a URS review checks that requirements are complete and testable. DQ is the step that formally traces the finished design back to those requirements, one by one, and is the last checkpoint before committing to procurement or build.

DQ can often be reduced to a lighter-weight review, or in some cases skipped, for simple, standard, low-risk off-the-shelf equipment with no custom configuration — but this should be a documented, risk-based decision, not a default assumption, and higher-risk or custom equipment should always have a formal DQ.

DQ should be completed and approved before the purchase order is issued or construction begins, because its purpose is to catch design gaps while changes are still cheap — approving DQ after procurement has already started defeats that purpose and shifts the cost of any design gap found later onto a more expensive change.

The equipment or system owner and engineering typically lead the technical review of the design against the URS, the vendor provides the design documentation being reviewed, and QA reviews and approves the completed DQ to confirm the process and conclusion meet quality system requirements — the vendor should not be the one approving their own design's compliance.

Reviewing a Functional or Design Specification checks that the document itself is internally clear, complete, and technically sound; DQ is the broader activity that uses that review, alongside drawings and other design documentation, to formally confirm and document that the resulting design as a whole meets every URS requirement and applicable regulation.

In practice, FS/DS review is usually one of the inputs into DQ rather than a separate, standalone gate — DQ is the activity that closes the loop back to the URS, which an FS/DS review alone does not do.

A design gap found during DQ should be documented, and either the design is revised and re-reviewed until it meets the requirement, or a formal deviation with QA-approved justification is raised if the gap will be accepted or resolved later in the project — DQ should not be approved with an unresolved, undocumented gap against a GxP-critical requirement.

Every URS requirement should be traceable within the DQ, but closely related requirements can be grouped and addressed together in a single review line as long as the traceability back to each individual requirement is still clear and auditable — grouping should aid clarity, not hide the fact that a specific requirement was never actually checked.

A useful DQ record shows the specific URS requirement, the design element that satisfies it with a reference to the exact drawing or specification section, the reviewer's assessment, and, for any gap found, what was done about it — a simple pass or fail checkbox against each requirement with no supporting reference is easy to produce but doesn't demonstrate the review actually happened.

• URS requirement identifier and text.
• Reference to the specific drawing, specification, or vendor document section addressing it.
• Reviewer assessment: met, partially met, or not met.
• Action taken for any gap identified.
• Reviewer name, role, and date.

DQ can be approved with open items only if each open item is formally risk-assessed, documented, and assigned a clear resolution path and owner before proceeding — open items affecting GxP-critical requirements should generally block DQ approval rather than be carried forward informally.

DQ typically draws on and updates the same system-level risk assessment used throughout the qualification lifecycle rather than requiring an entirely separate one — the risk assessment identifies which requirements are GxP-critical, and DQ uses that classification to decide how rigorously each requirement needs to be reviewed.

Computerized systems generally do need an equivalent design review under GAMP 5, though it's often called a design review or configuration specification review rather than "DQ," and its depth scales with the system's GAMP category — a category 5 custom system warrants a much more thorough design review than a category 3 off-the-shelf system with standard configuration.

For modular or skid-based equipment, DQ typically reviews the base design and platform against the URS first, followed by a supplementary design review once site-specific or configuration-specific details are finalized — treating the initial DQ as complete and final when significant configuration decisions are still pending creates a gap that should be explicitly tracked and closed later.

DQ should include the automation and control system as part of the overall equipment design review, but the control system's software design typically also goes through its own GAMP 5 design review appropriate to its category — the two reviews are complementary, and DQ shouldn't be treated as a substitute for a dedicated software design review on a complex control system.

Design documentation needs to be detailed enough that a reviewer can trace each URS requirement to a specific, verifiable design element — a high-level marketing datasheet or general capability statement from the vendor isn't sufficient; DQ needs actual drawings, specifications, or configuration documents specific to the equipment being purchased.

A significant design change after DQ approval should trigger a change control record and a re-review of DQ, at least for the affected requirements, before the change is implemented — treating a post-DQ design change as a minor detail not worth revisiting is a common way for an unqualified design element to slip through unnoticed.

At minimum, the system or equipment owner and QA should sign off on DQ before procurement or build proceeds, with engineering typically also signing as the technical reviewer — the specific signatory list should be defined in the site's validation plan or CQV procedure and scaled to the equipment's GxP impact.

DQ can often be leveraged across multiple identical units of the same equipment, provided a documented assessment confirms the units are truly identical in design and configuration — but each unit still needs its own IQ, OQ, and PQ, since DQ only confirms the design is sound, not that a specific physical unit was built and installed correctly.

DQ records should be retained for at least as long as the equipment's qualification and operational records, since DQ is the foundational evidence that the equipment was designed to meet requirements in the first place — commonly the equipment's operational lifetime plus the site's standard retention period after decommissioning.

Inspectors typically check that DQ was approved before procurement or build began, that it traces clearly back to specific URS requirements rather than describing the design in general terms, and that any gaps identified during the review were formally resolved or risk-assessed rather than silently dropped.

A frequent finding is a DQ that reads as a generic summary of the vendor's equipment rather than a requirement-by-requirement assessment — this suggests the review confirmed the equipment exists and looks suitable, not that it was actually checked against every requirement.

The most common downstream problem is discovering during OQ or PQ that the equipment simply cannot meet a URS requirement — a design limitation that a thorough DQ would have caught before procurement, when changing the design was still realistic, instead of after the equipment is installed, when the fix usually means costly rework or an accepted permanent deviation.

This is why DQ is often described as the cheapest place in the qualification lifecycle to catch a problem — every stage after it makes the same design gap progressively more expensive and disruptive to fix.