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 (legacy QSR): §820.30(d) Design output.
Requirement text
The manufacturer shall transform software requirements into an architectural design that identifies the major structural elements (software items) of the system, their interfaces, and how they interact. For Class B and C software, SOUP items must be specified including their functional requirements and system hardware and software dependencies (per §5.3.4 / §5.3.6).
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) 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)
- 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.