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: §8.5.2 Corrective action
Pre-QMSR Part 820 (legacy QSR): §820.30(i) Design changes.
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) 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.
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.