Maps to
QMSR / ISO 13485: §820.30(i)
ISO 13485: §8.5.2
IEC 62304: §6
Requirement text
The manufacturer shall establish a software maintenance plan and a process to monitor and address post-market feedback. 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.
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 maintenance plan must be documented.
- •A process must exist to monitor, evaluate, and respond to post-market feedback and problem reports.
- •Problem reports must be evaluated for safety impact before deciding on a response.
- •Change requests must be formally approved before implementation begins.
- •Software modifications must be implemented using the established development process (including design, testing, and verification).
- •Modified software versions must go through the release process before deployment.
- •The software maintenance plan must define the scope of maintenance activities, including who is responsible for maintenance, the schedule for planned maintenance reviews, and the criteria that trigger unplanned maintenance per IEC 62304:2006+A1:2015 clause 6.1.
- •The maintenance plan must define a process for monitoring feedback channels from post-production sources (complaint systems, field service reports, SOUP vendor advisories) to identify maintenance needs.
- •Change requests and problem reports must be evaluated to determine whether they should be implemented as a software modification or addressed through a change to the intended environment of use specification.
- •The maintenance process must address the full device lifecycle including device retirement — defining when and how the software will be decommissioned, ensuring that retirement activities do not create patient safety risks from devices remaining in use after support ends.
- •SOUP anomaly lists must be reviewed on a defined schedule and whenever SOUP vendor advisories are received, with documented determination of whether safety-relevant anomalies affect the product.
Common gaps
Cybersecurity patches not triggering impact analysis
majorPost-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
majorVulnerability 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.
Evidence signals
- •
FILE_EXISTS
Change.*Management|SOP.*Change|Maintenance.*Plan|Problem.*Resolution|Software.*Problem
- •
CONTENT_MATCH
Does this document describe a process for evaluating change requests for safety impact, approving changes before implementation, and ensuring modified software goes through the same development and release controls as new software?
Audit defense
Software maintenance for [your product] is governed by our Change Management SOP (Doc ID: [your document ID]) and Problem Resolution SOP. All post-release changes require a safety impact analysis and formal approval before implementation, with the complete development and release process applied to each modified version.