Architecture documents, component diagrams, interface specifications, and formal architecture verification before implementation — standard design output.
SOUP list with exact versions, functional requirements, and system dependencies is mandatory for Class B/C; logical segregation accepted to support lower classification.
SOUP list currency and segregation rationale — reviewers look for version-pinned dependencies and documented evidence that segregation claims hold.
Maps to
IEC 62304: §5.3 Software architectural design
ISO 13485: §7.3.4 Design and development outputs
Pre-QMSR Part 820: §820.30(d) Design output.
Requirement text
The manufacturer must transform the requirements for the medical device software into a documented architecture that describes the software's structure and identifies the software items. If a software item is identified as SOUP, the manufacturer must specify functional and performance requirements for the SOUP item that are necessary for its intended use (clause 5.3.3), and the system hardware and software necessary to support the proper operation of the SOUP item (clause 5.3.4).
Why this clause exists
Software architecture documentation is the bridge between requirements and implementation — it is the artifact that makes it possible to evaluate, before a line of code is written, whether the design can satisfy the safety requirements and risk controls. Without a documented architecture, there is no basis for verifying that risk-control software items are segregated from non-safety software, no way to confirm that SOUP dependencies are specified with precision sufficient for vulnerability tracking, and no foundation for the traceability chain that links hazard analysis to verified code. IEC 62304:2006+A1:2015 clause 5.3 addresses the SOUP inventory requirement with particular rigor because unmanaged third-party components are among the most common sources of post-market safety issues: a library integrated without exact-version pinning or functional specification cannot be assessed for CVE applicability, cannot be accurately represented in an SBOM, and cannot be evaluated for anomaly impact when the vendor publishes a security advisory. The pattern of device manufacturers running unpatched third-party code years after critical vulnerabilities were disclosed — because they lacked the SOUP documentation needed to even identify which products were affected — is the supply-chain risk the clause is designed to prevent at the architectural stage rather than discovering it post-market.
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)
- SOUP items not specified in architecture with exact versions — IEC 62304 requires functional and performance specifications for each SOUP item in the software architecture. Teams using dozens of open-source libraries frequently lack formal SOUP management — documentation uses 'latest stable,' branch names, or floating version ranges instead of exact version numbers, making CVE database lookups impossible.
- AI/ML components treated as black boxes in architecture — Notified bodies reject architectures that treat AI/ML components as opaque 'black boxes.' They expect the AI pipeline (pre-processing, model inference, post-processing) to be decomposed into logical software items with clearly defined interface specifications and safety guardrails.
- Unsupported segregation claims for lower classification — Teams assert lower safety classifications for software components by claiming segregation from safety-critical functions, but lack architectural documentation or test data proving the component's failure cannot affect safety-critical functions. The 2015 amendment explicitly allowed logical segregation, which teams interpret too loosely.