Change management process, post-market feedback intake, and applying the development process to post-release modifications — established CAPA-adjacent practice.
Formal maintenance plan distinct from development plan; SOUP anomaly list review on a defined schedule; device retirement lifecycle explicitly in scope.
Change request safety impact analysis records and SOUP advisory review logs — missing documentation for cybersecurity patches is the most common finding.
Maps to
IEC 62304: §6 Software maintenance process
ISO 13485: §7.3.9 Control of design and development changes, §8.5.2 Corrective action
Pre-QMSR Part 820: §820.30(i) Design changes., §820.100 Corrective and preventive action.
Requirement text
The manufacturer shall establish a software maintenance plan and a process to receive and review post-market field feedback (per §6.1). Change requests must be analyzed for safety impact, approved before implementation, and implemented using the established development process. Modified software must be re-released following the same controls as a new release.
Why this clause exists
Software maintenance is not a secondary concern after market clearance — it is the lifecycle phase where the organization's commitment to sustained safety is tested against the degrading effects of time, field experience, and a changing vulnerability landscape. IEC 62304:2006+A1:2015 clause 6 establishes formal maintenance requirements because the alternative — informal change management for post-market software — predictably produces hotfix releases that bypass the development, verification, and release controls applied to the original product. A hotfix that reaches patients without a safety-impact analysis, without regression testing, and without a release record is a software change made without any of the controls the organization committed to in its development plan; the regulatory consequence is that all prior verification evidence for the base release is potentially invalidated without documented evidence that the change did not compromise it. The SOUP anomaly list review obligation within maintenance reflects the further reality that third-party component risks evolve independently of any decisions the manufacturer makes: a SOUP component with no known vulnerabilities at design time may carry a critical CVE two years later, and without a documented, scheduled review process, that exposure persists indefinitely without the manufacturer having any mechanism to detect or respond to it.
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)
- Cybersecurity patches not triggering impact analysis — Post-market software updates, cybersecurity patches, and defect corrections are all regulated maintenance activities under IEC 62304. FDA now views 'patchability' as a design requirement. However, firms frequently fail to update their Impact Analysis after applying cybersecurity patches, and maintenance plans often lack linkage to vulnerability management processes.
- CVE review without formal documented evidence — Vulnerability monitoring is treated as informal rather than as a documented, auditable process. Common deficiencies include: no documented search methodology, searches covering the wrong software version, results recorded without a reviewer name and date, or blanket 'no vulnerabilities found' statements without NVD search evidence.