FDA Design Controls: Software for ISO 13485 and 21 CFR Part 820 Compliance

Design controls within a full QMS. Not a standalone tool.

FDA Design Controls Software: All Nine 21 CFR Part 820.30 Elements, the Design History File, and Post-Market Design Changes in a Full QMS Suite

Greenlight Guru built their brand on design controls for medical devices, specifically for early-stage companies navigating 510(k) preparation. Cognidox holds positions on FDA design controls terms as a document management platform focused on the design phase. Both address design controls as a bounded activity — a phase that ends at clearance or approval.

Design controls under 21 CFR Part 820.30 and ISO 13485 Section 7.3 are not a phase. They are a continuous obligation. The design history file must be maintained through every post-market design change. Every change to a cleared device requires a design change control assessment under 820.30(i). A CAPA that identifies a design-related root cause initiates a design change. A complaint that reveals a use environment problem triggers a design review. The design control system in a medical device company does not go into maintenance mode after product launch — it scales with the product lifecycle.

eLeaP competes on this ground: design controls within the context of a full QMS suite, connected to production quality, supplier management, complaint handling, CAPA, training, and change control. This page covers all nine 820.30 elements, the Design History File architecture, the traceability matrix structure, and how post-market design changes connect to the rest of the quality system.

Regulatory Basis: 21 CFR Part 820.30 and ISO 13485 Section 7.3

21 CFR Part 820 Subpart C, Sections 820.30 through 820.86, establishes the design control requirements for medical device manufacturers. The QMSR, effective February 2026, incorporates ISO 13485:2016 by reference and aligns the US design control requirements with the ISO 13485 Section 7.3 framework. For manufacturers operating in both US and international markets, satisfying ISO 13485 Section 7.3 substantially satisfies the QMSR design control requirements, with FDA’s supplemental requirements in 820.30 adding specificity in certain areas.

21 CFR Part 820.30(a) requires that each manufacturer whose devices are designed or subject to design changes establish and maintain design control procedures to ensure that the specified design requirements are met. The requirement applies not only to original device design but to any subsequent design change — a critical point for established manufacturers who may assume design controls are a development-phase obligation rather than a lifecycle obligation.

All Nine 21 CFR Part 820.30 Elements: What Each Requires and How eLeaP Addresses It

The nine design control elements specified in 820.30 map to the ISO 13485 Section 7.3 sub-clauses. Each element has specific documentation requirements and specific record linkage requirements that the design control software must support.

820.30(b) — Design and Development Planning

Section 820.30(b) requires a plan that describes the design and development activities, responsibilities, and interfaces between different groups and individuals. The plan must be updated as the design evolves. ISO 13485 Section 7.3.2 adds requirements for the plan to identify the review, verification, and validation activities appropriate to each design and development stage, and to update the plan as development progresses.

eLeaP: The design and development plan is a controlled document within the QMS document control module, version-controlled and updated through the change control workflow. The plan references the design review schedule, the verification and validation activities planned for each stage, and the responsible parties for each activity. As design stages are completed and the plan is updated, prior plan versions are archived in the document history. The DHF record links to the current plan version and to all prior versions, satisfying the requirement that the plan reflect design development progress.

820.30(c) — Design Input

Section 820.30(c) requires that procedures address the requirements relating to the device, including physical, chemical, biological, mechanical, software, and use-environment requirements. Design inputs must be documented, and incomplete, ambiguous, or conflicting requirements must be resolved before design work begins. ISO 13485 Section 7.3.3 additionally requires that inputs include applicable regulatory and legal requirements and information derived from previous similar designs.

eLeaP: design input records capture each requirement with its source — user need, regulatory requirement, risk control measure, or predecessor design reference. Incomplete or conflicting inputs are flagged at the record level and cannot be marked resolved without documenting the resolution. Design input records link to the risk management records that informed them, satisfying the requirement that inputs include risk controls derived from the risk management process. The design input record set forms the traceable foundation from which outputs, verification, and validation link.

820.30(d) — Design Output

Section 820.30(d) requires that procedures address total finished device design and its components, including relevant technical drawings, component specifications, software, labeling, and packaging. Design outputs must be expressed in terms that allow for adequate evaluation of conformance to design input requirements. Each output must identify characteristics that are critical to the proper functioning of the device.

eLeaP: design output records link explicitly to the design inputs they address, maintaining the input-to-output traceability that the traceability matrix requires. Critical characteristics are flagged at the output record level, ensuring they are addressed in the verification and validation planning. Device Master Record documents — drawings, specifications, software requirements, labeling specifications — link from the design output records as controlled documents within the QMS document control module.

820.30(e) — Design Review

Section 820.30(e) requires formal documented reviews of the design results at appropriate stages. Each review must be planned and conducted by individuals, including individuals who do not have direct responsibility for the design stage being reviewed. Design review records must include the date, participants, and review results, including any actions required.

eLeaP: Each design review is a quality record linked to the design stage it covers. The review record captures the participants, their roles, the design documents reviewed, the review findings, and the actions required before the next stage begins. The independent reviewer requirement is enforced at the review assignment stage — the design review record must include at least one reviewer who is not assigned to the design stage under review. Unresolved design review action items prevent stage advancement in the design control workflow.

820.30(f) — Design Verification

Section 820.30(f) requires procedures confirming that design output meets design input requirements. Verification activities must be documented with the method, date, and results. ISO 13485 Section 7.3.6 adds that verification must be planned, that the verification methods must confirm that outputs meet input requirements, and that records of verification results must be maintained.

eLeaP: verification records link to the specific design inputs they verify and to the design outputs being tested. Each verification record captures the verification method, the acceptance criteria, the test date, the tester identity, and the result. A verification result that does not meet acceptance criteria creates an open action that must be resolved before the verification stage can be closed. The traceability matrix view in the DHF shows, for each design input, whether the corresponding output has been verified, the verification method used, and the result.

820.30(g) — Design Validation

Section 820.30(g) requires design validation to ensure that devices conform to defined user needs and intended use. Validation must include testing under actual or simulated use conditions. Validation must be performed on production devices or on devices representative of production devices and must be completed before commercial distribution. Clinical evaluation under 21 CFR Part 860.7 may be required to support validation for certain device types.

eLeaP: design validation records link to the user needs and intended use statements that the validation is designed to confirm. Validation study records capture the test protocol, the device configuration used in validation, the test conditions, and the results. Clinical evaluation records link to the device record where applicable. The distinction between verification — confirming outputs meet inputs — and validation — confirming the device meets user needs — is maintained in the record structure, satisfying the regulatory requirement that both activities are documented separately.

820.30(h) — Design Transfer

Section 820.30(h) requires procedures ensuring that the device design is correctly translated into production specifications. Design transfer records must confirm that production methods can produce devices that meet the design requirements. This is the bridge between the design history file and the device master record: the transfer confirms that the DMR correctly implements the approved design.

eLeaP: the design transfer record links the final design output records to the corresponding DMR documents — manufacturing specifications, work instructions, process parameters, and acceptance criteria. The transfer review confirms that each design output has a corresponding production specification in the DMR and that the specification is achievable using available production methods. Transfer acceptance criteria include first article inspection results and process capability data, where required. The design transfer record closes the design history file for the initial design cycle and opens the production quality record chain.

820.30(i) — Design Changes

Section 820.30(i) requires that all design changes be identified, documented, reviewed, and approved before implementation. This element applies throughout the product lifecycle — every change to the design of a cleared or approved device, regardless of how minor the change appears, requires design change control assessment. The assessment must determine whether the change requires new or additional verification and validation before implementation. Certain changes require submission to the FDA before implementation.

eLeaP: design change records route through the change control workflow with a design control impact assessment that identifies the verification and validation implications of the proposed change. A change that affects a design output linked to a verified design input requires re-verification of that input-output pair. A change that affects a user’s need or intended use, as addressed in validation, requires re-validation. The design change record links to the DHF records it modifies, and the modified DHF records carry a change history showing the design change that authorised each modification. Post-market design changes are covered in detail in the following section.

820.30(j) — Design History File

Section 820.30(j) requires that a Design History File be established and maintained for each type of device. The DHF must contain or reference the records necessary to demonstrate that the design was developed in accordance with the approved design plan and the requirements of Part 820. A DHF that contains documents without demonstrating their connected relationship to each other and to the design plan does not satisfy the 820.30(j) requirement — the records must be navigable in the context of the design they document.

eLeaP: the DHF in eLeaP is a navigable record network rooted in the device record. The design plan links to each stage’s activities. Design inputs link to the outputs they drove. Outputs link to the verification tests that confirmed them. Verification records link to the validation studies where validation is built on verified outputs. Design review records link to the design stage they reviewed. Design change records link to the DHF records they modified. An auditor navigating the eLeaP DHF can follow any traceability path — from user need to design input to design output to verification to validation to production specification — within the quality system without assembling documents from multiple locations.

The Design History File as a Connected Record Set, Not a Document Collection

The most common DHF compliance gap in Notified Body and FDA audits is not missing documents. It is missing connections. The auditor can find a design input record and a verification test record, but cannot trace the relationship between them. They can find a complaint record and a design change record, but cannot confirm that the complaint drove the change. The documents exist in the file. The traceability does not exist in the file.

A SharePoint folder, a Google Drive, or a standalone EDMS like Cognidox manages documents. It does not maintain record relationships. When an auditor asks to see the verification evidence for a specific design input, the answer from a document-management DHF is a search that may or may not locate the right test report. The answer from eLeaP’s record-network DHF is a direct navigation from the design input record to its linked verification records, with the acceptance criteria and results visible without leaving the device record view.

Every record in the eLeaP DHF carries explicit links to the records it connects to. Design inputs link to their source (user need, regulatory requirement, risk control) and to the outputs that address them. Outputs link to the inputs they address and to the verification tests that confirm them. Verification tests link to the outputs tested and the inputs verified. The links are system-maintained record relationships, not manual hyperlinks in documents that can drift or break when records are modified.

Traceability Matrix: System-Maintained Linkage vs. Manual Spreadsheet

The design control traceability matrix maps each user need to the design input that addresses it, to the design output that implements the input, to the verification test that confirms the output meets the input, and to the validation study that confirms the device meets the user need. In most medical device companies, this matrix is a manually maintained spreadsheet. It is created at some point in the development cycle, updated inconsistently as changes are made, and does not reflect the current state of the DHF at the time of an audit.

In eLeaP, the traceability matrix is a live query of the record relationships in the DHF. Because each record type carries its links as part of the record structure, the traceability view can be generated at any time and will always reflect the current state of the DHF. When a design change modifies an output, the traceability view immediately reflects that the verification for that output may need to be updated. When a new design input is added, the traceability view shows it as unverified until a verification record is linked. The matrix is not a document that requires manual maintenance — it is a view of the record network that maintains itself through the record-linking architecture.

For Notified Body audits, the traceability matrix generated from eLeaP demonstrates design control traceability without requiring the quality team to assemble a new matrix for each audit. The most current version of the matrix reflects the most current state of the DHF. Gaps in traceability — design inputs without linked outputs, outputs without linked verification tests, verification tests that did not meet acceptance criteria — are visible in the matrix view and can be addressed before the audit rather than being discovered during it.

Post-Market Design Changes: Connecting 820.30(i) to the Full QMS

Post-market design changes are where the integration between design controls and the broader quality management system becomes most visible. A design change triggered by a CAPA connects the design history file to the quality event that drove the change. A design change that affects production methods connects the DHF to the device master record and to the training records for personnel who will work under the modified process. A design change that requires FDA submission connects the DHF to the regulatory affairs function. In a standalone design control tool, these connections exist only through manual cross-reference or external document links. In eLeaP’s integrated QMS, they are system-record relationships.

CAPA-Driven Design Changes

When a CAPA investigation identifies a design-related root cause — a complaint about a device performance characteristic that was not adequately addressed in the original design validation, a nonconformance revealing that a design tolerance is not achievable in production, a field safety report indicating a use environment condition that the original user needs analysis did not capture — the corrective action requires a design change. In eLeaP, the design change record is initiated from within the CAPA record. The CAPA record links to the design change as its corrective action. The design change record links back to the CAPA as its originating quality event. An auditor reviewing either record can navigate to the other without leaving the quality system.

Design Changes Affecting Production Methods and Training

A design change that modifies a device component, a manufacturing process parameter, or a device labeling requirement affects both the DHF and the DMR, and requires retraining for personnel whose work activities are affected. In eLeaP, the design change control record identifies the DMR documents requiring revision as part of the change impact assessment. Those documents route through the document revision workflow. When the revised documents reach effective status, the integrated LMS generates retraining assignments for every role assigned to those documents. The design change cannot be closed until the DMR revisions are documented, the revised documents are effective, and the required training completions are confirmed. The training gate that applies to all document revisions in eLeaP applies equally to design-change-driven document revisions.

Design Changes Requiring FDA Submission Assessment

Some post-market design changes to cleared or approved medical devices require FDA submission before implementation: a new 510(k) for changes that could significantly affect safety or effectiveness, a PMA supplement for changes to approved devices, or a Special 510(k) for certain changes to the device’s design specifications, components, materials, or manufacturing processes. The 820.30(i) assessment must include a regulatory submission impact determination. In eLeaP, the design change impact assessment includes a regulatory submission field that routes to the regulatory affairs function when a submission assessment is required. The regulatory affairs determination and the submission status — pending, submitted, cleared, or not required — are tracked within the design change record. A design change that requires prior submission cannot advance to implementation sign-off until the submission status is confirmed.

Evaluating FDA Design Controls Software: Five Questions Beyond the Design Phase

Design control software evaluations that focus only on the development phase miss the ongoing lifecycle obligations of 820.30. The questions below test the full scope of design control software requirements, including post-market design change management.

eLeaP’s answers to all five questions are yes. The design controls demo covers the full DHF record network view, the live traceability matrix, a post-market design change initiated from a CAPA record, and the training gate on design-change-driven document revisions. Request a scoped FDA design controls demo at eleapsoftware.com.

Related resources: