Maps to
QMSR / ISO 13485: §820.30(b)
ISO 13485: §7.3.2
IEC 62304: §5.1
Requirement text
The manufacturer shall establish a software development plan covering development processes, deliverables, traceability requirements, configuration management, problem resolution, risk management activities, and verification approach. The plan shall be maintained throughout the development lifecycle.
What changed
Amendment 1 (2015) expanded the scope to explicitly include health software and Software as a Medical Device (SaMD), not just software embedded in physical medical devices. A new compliance path for legacy software (Clause 4.4) was introduced, allowing previously released software to meet requirements through post-market data and risk management rather than full retrospective documentation.
The software safety classification criteria (Clause 4.3) shifted from severity-only to include probability of hazardous situations. External risk control measures (hardware or clinical procedures) can now reduce the software safety class, but internal software mitigations cannot. The standard clarified that logical segregation (not just physical) is acceptable for classification purposes.
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 publishing known defects with risk assessments (5.1.12), IT security and networking considerations (5.2.2), and Class A software received additional testing, release, and monitoring requirements.
Atomic constraints
- •A Software Development Plan (or Software Development and Maintenance Plan) must be documented before development begins.
- •The plan must define development phases, processes, and expected deliverables.
- •The plan must define how traceability between requirements, design, implementation, and tests is maintained.
- •Risk management activities within software development must be explicitly planned.
- •Configuration management and version control strategy must be defined in the plan.
- •The plan must be kept current as development evolves.
Common gaps
Software development plan missing mandated deliverables
majorIEC 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 2023 guidance additionally mandates an Architecture Design Chart and a process for generating a summary of Unresolved Anomalies. Many plans are incomplete or skip these elements entirely.
Known defects list not maintained
moderateThe 2015 amendment added Section 5.1.12 requiring publication of known defects with associated triage and risk assessments demonstrating safety impact. 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.
Evidence signals
- •
FILE_EXISTS
Software.*Development.*Plan|SDMP|Software.*Plan|Development.*Maintenance.*Plan
- •
CONTENT_MATCH
Does this document define software development phases, deliverables, traceability approach, configuration management strategy, and risk management activities for the software lifecycle?
Audit defense
The Software Development and Maintenance Plan for [your product] (Doc ID: [your document ID]) defines our development phases, deliverables, and traceability requirements per IEC 62304 section 5.1. It is updated at each phase gate and serves as the master planning document for all software lifecycle activities.