Software Development Plan, defined development phases, deliverables list, and configuration management strategy — standard SDLC planning artifacts.
Procedure for identification and avoidance of common software defects (clause 5.1.12), SOUP review schedule, and IT security planning integrated into the plan.
Plan currency versus last software change — and whether the known-anomaly list is maintained with documented safety triage for each defect.
Maps to
IEC 62304: §5.1 Software development planning
ISO 13485: §7.3.2 Design and development planning
Pre-QMSR Part 820: §820.30(b) Design and development planning.
Requirement text
The manufacturer must establish a software development plan (or plans) for conducting the activities of the software development process appropriate to the scope, magnitude, and software safety classifications of the software system to be developed, and the plan must address the following: the processes to be used in the development of the software system; the deliverables (includes documentation) of the activities and tasks; traceability between system requirements, software requirements, software system test, and risk control measures implemented in software; software configuration and change management, including SOUP configuration items and software used to support development; and software problem resolution for handling problems detected in the medical device software, deliverables and activities at each stage of the life cycle. The manufacturer must update the plan as development proceeds as appropriate.
Why this clause exists
A software development plan's regulatory function is not planning in the project-management sense — it is the binding declaration, made before development begins, of how the organization will demonstrate to an auditor that its processes met the standard's requirements. Without a plan, every subsequent artifact (architecture document, test protocol, SOUP list, release record) exists in an evidentiary vacuum: there is no pre-stated commitment against which the artifacts can be evaluated as adequate or deficient. IEC 62304:2006+A1:2015 clause 5.1 requires the plan because the alternative — inferring the intended process from the artifacts produced — inverts the audit logic and creates an opportunity to construct a post-hoc narrative around whatever evidence happens to exist. The 2015 amendment added clause 5.1.12, 'Identification and avoidance of common software defects', which requires the software development plan to include or reference a procedure for identifying the categories of defects that may be introduced by the selected programming technology and for documenting evidence that these defects do not contribute to unacceptable risk (Class B and C). Known residual anomalies at release are a separate matter, handled by clauses 5.8.2 (document all known residual anomalies) and 5.8.3 (evaluate them to ensure that they do not contribute to an unacceptable risk).
What changed
Amendment 1 (2015) introduced a new compliance path for legacy software (Clause 4.4), allowing previously released software to meet requirements through post-market data and risk management rather than full retrospective documentation.
In Clause 4.3, Amendment 1 struck the 2006 sentence "The software safety classes shall initially be assigned based on severity as follows" and its three severity-based class definitions, and inserted class definitions that depend on whether the software system can contribute to a hazardous situation which results in unacceptable risk after consideration of risk control measures external to the software system, with the resulting possible harm being non-serious injury (Class B) or death or serious injury (Class C). Figure 3 states that the probability of a software failure shall be assumed to be 1 and that only risk control measures not implemented within (external to) the software system shall be considered. The 2006 text already allowed a hardware risk control measure to reduce the class (from C to B, and from B to A); Amendment 1 inserted a NOTE 1 stating that external risk control measures can be hardware, an independent software system, health care procedures, or other means. Amendment 1 also inserted a NOTE to clause 5.3.5 (Identify segregation necessary for risk control) that ends: "Other means of segregation can be applied when effectiveness can be ensured by the software ARCHITECTURE design (see B.4.3)."
The definition of SOUP was narrowed to apply only to software items — a complete medical device software system cannot be claimed as SOUP to bypass lifecycle requirements. New requirements were added for identification and avoidance of common software defects (5.1.12), IT security and networking considerations (5.2.2), and Class A software received additional testing, release, and monitoring requirements.
Common gaps (what we see in audits)
- Software development plan missing required content and recommended submission items — IEC 62304 requires a plan defining software safety class with rationale, standards and processes, deliverables at each stage, risk management approach, and configuration management plan. FDA's June 2023 premarket software functions guidance (which contains nonbinding recommendations) additionally recommends that a submission include a system and software architecture diagram (section VI.E) and a list of unresolved software anomalies with an evaluation of each anomaly's impact on the device's safety and effectiveness (section VI.J). Many plans are incomplete or skip these elements entirely.
- Known residual anomalies not documented and evaluated — Clause 5.8.2 requires the manufacturer to document all known residual anomalies, and clause 5.8.3 requires the manufacturer to ensure that all known residual anomalies have been evaluated so that they do not contribute to an unacceptable risk. Many manufacturers either do not maintain this list or fail to document the safety impact assessment for each known defect as part of the release process.