ISO 13485 Design Controls for Software Teams

ISO 13485 design controls are hard to apply to software for a simple reason. Teams ship in sprints, but the evidence an auditor asks for often lives outside the sprint. This article maps each clause 7.3 stage, traceability link, and sprint activity to the record it should leave, then covers tooling and the FDA QMSR.

ISO 13485 design control stages and the evidence each one leaves

ISO 13485:2016 clause 7.3 sets design and development control as a structured, documented process inside the quality management system. The ISO 13485 standard divides it into at least 10 identifiable control areas, from general requirements and planning in 7.3.1 to 7.3.2 through design and development files in 7.3.10. Read that split as ten places where an auditor will look for a specific record.

Clause	Control area	What the control requires	Evidence to keep
7.3.1-7.3.2	General and planning	Documented plan with responsibilities, interfaces and review points	Design and development plan with revisions
7.3.3	Inputs	User needs, regulatory requirements, standards and risk outputs	Software requirements specification with IDs
7.3.4	Outputs	Characteristics essential for safe and proper use	Architecture, interface specifications and software item records
7.3.5	Reviews	Reviews at suitable stages with recorded decisions	Review minutes, decisions and action items
7.3.6	Verification	Confirmation that outputs meet inputs	Test reports traced to requirements
7.3.7	Validation	Confirmation of user needs and intended use under defined conditions	Validation records from realistic use conditions
7.3.8	Transfer	Design transferred to production and release	Transfer checklist and release record
7.3.9	Change control	Changes identified, reviewed, verified or validated, and approved before implementation	Change requests with impact assessments and approvals
7.3.10	Design and development files	Records that demonstrate conformity	Design History File or design and development file index

Planning documents are maintained as development progresses, so a plan written once and never revised already fails the intent. Inputs must address user needs, applicable regulatory requirements, standards, and risk management outputs. Outputs must specify the characteristics necessary for safe and proper use. For SaMD teams doing regulated software delivery, that means a requirement isn't ready until it carries its risk link and a testable acceptance criterion.

Why end of project documentation fails

Reviews under 7.3.5 and change records under 7.3.9 only prove control if they existed when the decision was made. A review minute dated after release doesn't show that anyone evaluated the problem before the team committed code. The same applies across functions. Named owners and dated approvals matter for the same reason.

An auditor doesn't ask whether you have a document. The question is whether the record shows who decided, when, and on what evidence.

Verification and validation also need separate evidence sets. One confirms outputs meet inputs, the other confirms user needs and intended use. Collapsing both into a single test report leaves one of those claims unsupported, and you'll find that gap during transfer, when fixing it is most expensive.

Traceability from user needs to released software

Traceability connects each user need to design inputs, outputs, risk controls, verification and validation evidence, and the released build. The FDA design control guidance for medical device manufacturers defines verification as confirmation that design outputs meet design inputs. Validation demonstrates conformity with defined user needs and intended use under defined operating conditions. Together, these links let a team follow a software change from its purpose through the evidence for the released version.

Bidirectional traceability makes the chain usable during reviews: each safety- or performance-critical input connects to an implemented output and objective evidence, while each test points back to the requirement it checks. Stable identifiers across records make those relationships clear.

Hypothetical example with an HL7 v2 result feed

Consider a SaMD module that receives HL7 v2 ORU^R01 result messages and displays laboratory values. Requirement REQ-014 specifies that the parser reads OBX segments and rejects malformed input with a visible alert. The ISO 14971 risk management standard provides the framework for linking a hazard analysis to the control: here, the hazardous situation is a dropped abnormal result, and the control links back to REQ-014. Test case TC-092 checks malformed OBX input and a message from an unintended source system, both foreseeable abnormal conditions for an interface.

Link	Record
User need	Clinicians can act on displayed laboratory results
Requirement	REQ-014 parser reads OBX segments and rejects malformed input with a visible alert
Risk control	Hazard file entry for a dropped abnormal result (ISO 14971)
Design output	Parser module version and configuration file
Verification	TC-092 malformed OBX input and a message from an unintended source system
Validation	Session with intended users on realistic result sets
Release	Build tag and SBOM reference

Verify interface requirements against the specification, then validate the integrated behavior under realistic use. Keep the requirement ID consistent across the requirements tool, test case, defect record, and release note. Renaming IDs between tools breaks the links and forces manual reconstruction. Record configuration identifiers for the parser version and configuration file as well, so the validated build remains identifiable after release.

Mapping design controls onto agile sprints

A feature that handles medication data can generate design-control evidence in every sprint, provided each activity updates a named record and a review closes the work. Ekipa AI's AI-Augmented Delivery Framework uses checkpoint-based validation at each stage, with human engineers leading decisions.

Sprint activity	Design control record updated	Suggested owner	Closed by
Backlog refinement	Design inputs with stable IDs and testable acceptance criteria, including abnormal inputs	Product owner with engineering lead	Sprint planning
Sprint planning	Risk file entry for any new hazard	Engineering lead with quality	Risk review within the sprint
Definition of done	Linked verification evidence, updated risk file, and change record for any change to released behavior	Engineering team	Sprint review
Threat modeling and design outputs	Threat model, architecture, update and logging evidence, and SBOM	Security lead with engineering	Formal design review
Sprint review	Demo evidence attached to requirement IDs	Product owner	Formal review records decisions
Release sprint	Validation record, transfer checklist, and design and development file index	Quality with engineering	Formal design review before transfer

Three-sprint sequence

A six-person team working in two-week sprints is building a feature that reads MedicationStatement resources through FHIR R4, using SMART on FHIR scopes such as patient/MedicationStatement.read. In Sprint 1, the team writes design inputs for scope handling and responses to missing fields, then adds a hazard for a stale medication list. In Sprint 2, it records design outputs, a threat model, and an updated SBOM. In Sprint 3, it runs verification and records defect dispositions.

The FDA cybersecurity guidance recommends system-level security assessment and threat modeling across the device lifecycle, including deployment, operation, maintenance, and connected systems. Translate its security objectives, including authenticity and integrity, authorization, availability, confidentiality, and secure, timely updateability and patchability, into testable design inputs rather than leaving them as statements in a security policy.

A sprint demo records what the team showed; clause 7.3.5 also requires the decisions, rationale, and actions captured in a formal design review. The release sprint should include validation under intended use, followed by a review that records decisions before transfer. The formal review takes half a day, so teams that leave it until the end risk discovering incomplete records when release is due.

Tools that keep the design history file current

ISO 13485 doesn't name specific tools, so judge each category by the records it must link and preserve. Software used in the quality management system must itself be validated under clause 4.1.6, and that validation record is part of your evidence. We design internal tooling to fit existing systems and workflows, which matters here because a tool that sits outside the sprint workflow won't get updated during the sprint.

Tool category	Records it must link	What the auditor should see
Requirements management	User needs, requirement IDs, acceptance criteria	Stable IDs and a change history
Issue tracker	Backlog items, defects, requirement IDs	Links from each item to a requirement and a recorded decision
Test management	Test cases, results, defect dispositions	Results against named test cases and build identifiers
Source control	Commits, branches, release tags	Signed release tags and build identifiers
Risk management file	Hazards, risk controls, verification references	Links to ISO 14971 entries and residual-risk decisions
Document control	Plans, specifications, reviews, approvals	Approvals by role and a dated change history

Evaluation criteria follow from those records. You need IDs that link across tools, an immutable history showing who changed what and when, role-based approval workflows, exports an auditor can review, and CI/CD integration so test results attach to specific builds. A generated traceability matrix still needs recorded review decisions. Tool output shows links exist, it doesn't show anyone evaluated them.

Test your setup with one walk-through:

• Pick one release and start from a single user need.

• Follow the ID through requirement, risk control, design output, and test case.

• End at the build tag without reconstructing any link by hand.

• Check each link for a named owner and a dated record.

If that walk-through needs a spreadsheet assembled for the occasion, your tools aren't keeping the file current.

Aligning design controls with the FDA QMSR

FDA's Quality Management System Regulation took effect on February 2, 2026. Under 21 CFR Part 820, ISO 13485:2016 is incorporated by reference, so one quality system can serve FDA and EU requirements with design controls organized around clause 7.3. The FDA QMSR page is the regulator's reference for that incorporation.

ISO 13485 clause 7.3 covers the full design control lifecycle: planning, inputs, outputs, reviews, verification, validation, transfer, change control, and design and development files. FDA's Design History File corresponds to ISO's design and development file, so the same record set can be presented to both. Organizations serving U.S. and international markets no longer need wholly separate frameworks.

Scope and legal status

Under the QMSR, design and development requirements apply to Class II and Class III devices and to specified Class I devices, including Class I devices automated with computer software, and they begin after feasibility or proof of concept when the manufacturer plans to bring the device to market. Confirm classification and applicability with your regulatory function before applying that scope to a product. Planning must be documented, reviewed, approved, and updated as development progresses, with ownership across product, engineering, clinical, regulatory, and verification.

Keep the status of each source clear. The QMSR is a regulation, FDA's June 2025 cybersecurity document is guidance, and ISO 13485 is a standard the regulation incorporates. Cybersecurity follows the same chain either way. Security requirements are recorded as design inputs, and security evidence as outputs and verification records, which is how we structure SaMD solutions work alongside regulatory stakeholders. Change control deserves particular attention because ISO 13485 requires the review to consider effects on constituent parts and products already delivered.

Design controls connect to the rest of your regulatory work. See our guides to SaMD classification under the FDA, EU MDR Rule 11, IEC 62304 software safety classification, AI in MedTech engineering, and the predetermined change control plan.

Conclusion

Design controls should close at each sprint boundary, not accumulate for a final documentation push. Before transferring a design to production, confirm that verification and validation evidence is complete, reviews are recorded, and unresolved issues have a documented disposition. A release decision made without those records leaves the team unable to show that the design met its requirements.

Start with one check: compare the backlog, risk file, and test matrix. Find a requirement without a linked test, then assign an owner and close the gap through the next review. This small check exposes whether sprint work is producing usable design history evidence.

This article is general information, not legal or regulatory advice.

To build design controls into your delivery workflow, explore our SaMD solutions or book a consultation.

Frequently asked questions

Who owns each design control record when several teams share the work

The design and development plan assigns ownership, and that assignment is itself a required record. ISO 13485 clauses 7.3.1 and 7.3.2 require the plan to document responsibilities and interfaces. In practice, product owns inputs, engineering owns outputs and verification, clinical input supports validation, and quality owns review records and the file index.

Does a change to released software always need a new design review

Every change needs review, and the impact assessment sets its depth. Clause 7.3.9 requires each change to be identified, reviewed, verified or validated as appropriate, and approved before implementation. A small change may close with a documented impact assessment and targeted regression evidence, but the change record must show that reasoning.

What should happen when verification shows an interface requirement was wrong

Route the correction through change control rather than editing the requirement in place. Update the requirement under clause 7.3.9, revisit the linked risk file entries under ISO 14971, then repeat the affected verification. Record the decision and the reason, so the earlier test result doesn't appear to support a requirement that no longer exists.

Is an SBOM required design control evidence

ISO 13485 doesn't name an SBOM, so we treat it as supporting evidence rather than a clause 7.3 deliverable. It supports design outputs by identifying software components in a release, and it supports the update and supply chain expectations in FDA’s cybersecurity guidance, finalized in June 2025 and reissued in February 2026 to reference the QMSR. Read that guidance directly for your device type, because applicability turns on whether your product is a cyber device.