Who Owns the Design History File: R&D, Quality, or Both?

Key Takeaways

• Design History File ownership requires R&D technical ownership, Quality process governance, specialist evidence ownership, record custodianship, and one accountable lifecycle owner.
• R&D owns the technical truth of the Design History File, including requirements, architecture, outputs, verification strategy, failure analysis, and change impact.
• Quality owns Design History File process integrity by governing design controls, evidence standards, traceability, phase-gate concurrence, record integrity, and escalation.

 

The DHF Ownership Test

The question of who owns the Design History File is rarely about where documents are stored. The real issue is how authority is divided across technical content, process governance, record control, and lifecycle accountability. R&D often views the DHF as the natural output of product development, since engineering generates requirements, specifications, design outputs, test evidence, and technical rationale. Quality views the same record as evidence that development occurred through a controlled and defensible process.

The FDA’s Quality Management System Regulation, or QMSR, became effective on February 2, 2026, and incorporates ISO 13485:2016 by reference into 21 CFR Part 820. FDA did not retain DHF as a separately defined QMSR record type. Instead, ISO 13485:2016 Clause 7.3.10 requires a design and development file for each medical device type or family.

A defensible ownership model must therefore answer three questions:

1. Who creates and defends the technical truth?
2. Who governs how that truth is reviewed, approved, and preserved?
3. Who is accountable for the completeness of the full record?

 

Define the Object Being Owned

For purposes of this article, “DHF” refers to the design and development file and the records it contains or references. ISO 13485:2016 Clause 7.3.10 requires records demonstrating conformity with applicable design and development requirements, including design changes. These records may reside across eQMS, PLM, requirements management, ALM, source code, test, laboratory, and supplier systems, so organizations should define controls for identification, approval status, revision, configuration, retention, and retrieval.

 

What the DHF must allow the organization to reconstruct

• The approved design intent and intended use
• User needs and measurable design inputs
• Design outputs and released configurations
• Hazards, risk controls, and benefit-risk rationale
• Verification and validation evidence
• Design reviews, deviations, and failure investigations
• Design transfer and manufacturing readiness
• Changes made before and after release

 

What “Ownership” Actually Means

The word ownership is too broad to support effective governance unless it is divided into distinct responsibilities. A company can assign document authorship while leaving approval authority, record control, and accountability unresolved. That creates the appearance of shared ownership without defining who can require evidence, prevent phase closure, or escalate gaps.

A stronger model separates technical authority, process governance, record custodianship, and overall accountability. The structure should identify who creates evidence, challenges it, approves decisions, controls records, and closes gaps.

 

An Example DHF Governance Matrix

 

“R&D and Quality jointly own the DHF” is not sufficient unless each of these dimensions is assigned explicitly. Shared participation supports control, but shared ambiguity weakens it.

 

R&D and Quality Can Hold Different Responsibilities

In the proposed model, R&D or a designated Design Authority owns the technical content and rationale for the design. Engineering defines the architecture, design inputs and outputs, verification strategy, failure investigations, technical trade-offs, and design-change impact. A function that did not make or understand those decisions cannot authentically own their rationale.

Quality or Design Assurance governs the integrity of the design and development process. It defines evidence expectations, governs reviews, challenges weak acceptance criteria, monitors traceability, and may hold or escalate phase closure when approved procedures grant that authority. Quality should not write engineering conclusions or replace technical judgment, but R&D should not be the sole judge of record acceptability.

 

Differentiated Ownership

 

Under this model, R&D or the Design Authority owns technical content and rationale, while Quality or Design Assurance governs the process used to create, review, approve, and preserve records.

 

 

The Federated Ownership Architecture

One defensible operating model is federated responsibility with a named point of accountability. R&D or the designated Design Authority owns the technical core, while Quality or Design Assurance owns the control framework.

Regulatory, Clinical, Human Factors, Cybersecurity, Supplier Quality, Operations, and Manufacturing Engineering own specialized evidence within their respective areas of competence. Document Control or Quality Systems owns the controlled record infrastructure. 

The organization should assign one named role accountable for file completeness, such as a Product Development Leader, Chief Engineer, Design Control Lead, Design Authority, or Product Lifecycle Owner. That role should be able to assign actions, maintain an index, escalate deficiencies, and block phase closure in accordance with approved procedures.

 

DHF Ownership Architecture

The following example separates responsibilities by function, decision authority, and record control. Organizations may allocate responsibilities differently, provided their QMS defines the applicable authorities and interfaces.

 

 

Ownership Across the Product Lifecycle

Responsibility for the design and development file begins during planning and continues for records associated with subsequent design changes.

During planning, R&D and project leadership define technical deliverables, interfaces, and configuration controls, while Quality establishes procedural expectations and review requirements.

During development, R&D owns technical accuracy, while specialist functions contribute requirements and evidence for their respective domains.

Under the proposed model, R&D or the Design Authority leads technical execution during verification, validation, transfer, and later changes. Operations contributes to production-readiness decisions, while Quality or Design Assurance governs conformity with approved procedures. Complaints, CAPA, software updates, supplier changes, cybersecurity vulnerabilities, labeling changes, and manufacturing changes should link to the design record when they support or result in design changes.

 

Lifecycle Ownership Table

 

Distributed Records Require Stronger Governance

Modern development environments often separate where work occurs from where approved records are retained. Engineers may work in ALM, source-code, requirements, simulation, or test-management tools, while approved evidence is retained in an eQMS or another controlled repository. The QMSR does not prescribe a particular software or repository architecture. As a governance practice, the organization should identify the authoritative record location for each evidence type and maintain sufficient controls to identify its approval status, revision, product applicability, configuration, retention, and retrieval requirements. Broken links, duplicate copies, lost approval histories, and missing configuration metadata can make an apparently complete DHF impossible to defend.

 

System of work compared with system of record

 

Warning Signs of Weak DHF Ownership

Weak ownership usually becomes visible through recurring governance failures. Quality may function as an archivist that repeatedly requests missing records but lacks authority to enforce closure.

R&D may act as the sole gatekeeper and advance development despite unresolved failures, incomplete traceability, or undocumented deviations. A policy may also assign ownership jointly while no role is accountable for escalation, closure, or post-launch maintenance.

Other warning signs include multiple sources of truth, retrospective documentation, supplier-controlled evidence, and an orphaned DHF after the original project team disbands. These are not merely administrative weaknesses. They show the organization cannot reliably connect technical decisions to the approved product state.

 

DHF Ownership Diagnostic Checklist

• Quality requests missing evidence but cannot prevent phase closure.
• R&D closes phases with unresolved failures or incomplete traceability.
• No named role owns escalation and gap closure.
• Submission, risk, manufacturing, and verification records describe different configurations.
• Requirements or rationales are documented after decisions are made.
• No post-launch owner maintains the design record.
• Critical supplier evidence remains outside the manufacturer’s practical control. 
• The DHF index is incomplete, outdated, or uncontrolled.
• Correct records cannot be retrieved without specific individuals.

 

 

Decision Rights Must Be Explicit

A useful RACI should be built around decisions, not only documents. Assigning an author and approver to a protocol does not establish who can accept the verification strategy, disposition a deviation, determine risk acceptability, or declare the design ready for transfer. Decision authority must be defined at the points where technical evidence becomes an approved conclusion.

The governance model should also specify required concurrence. R&D may own the technical decision, but Quality may need to confirm that the process was followed and the evidence is complete. Regulatory, Clinical, Human Factors, or Operations may also need decision rights where specialized requirements are affected.

 

DHF Decision Rights and Required Quality Concurrence

 

To Conclude: The Defensible Answer Is Differentiated Ownership

The DHF should be owned by both R&D and Quality, but not in the same way. R&D owns the technical substance: requirements, architecture, outputs, verification strategy, failure analysis, and design-change impact. Quality owns the process for creating, challenging, approving, preserving, and retrieving that substance.

Other functions own specialized evidence, and Document Control owns the record infrastructure. One named role must remain accountable for completeness. Assigning the DHF entirely to Quality lets engineering disengage from its decisions, while assigning it entirely to R&D weakens independent oversight.

 

 

 

How Enlil Helps MedTech Teams Turn DHF Ownership Into Operational Control

DHF ownership breaks down when disconnected functions, systems, and partners each hold pieces of the evidence. R&D, Quality, Regulatory, Manufacturing, and external contributors all shape the design record, but PLM, QMS, ERP, MES, requirements, and project systems often remain fragmented.

Enlil helps solve that problem with a cloud-native development traceability platform purpose-built for MedTech. We create a unified source of truth across product development, helping medical device companies, contract manufacturers, development partners, and regulatory or compliance consultants maintain traceability, compliance, efficiency, and manufacturing alignment.

With Agentic AI designed for MedTech, Enlil helps teams keep product evidence connected, up to date, and inspection-ready. To strengthen DHF traceability, alignment, and compliant development, connect with our team.