Maps to
QMSR / ISO 13485: §820.30(d)
ISO 13485: §7.3.4
IEC 62304: §5.3
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 dependencies.
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 architecture document or architecture diagrams must exist.
- •The architecture must identify all major software items and their interfaces.
- •SOUP (Software of Unknown Provenance) items must be listed with their functional and performance requirements.
- •For Class C software, segregation of software items necessary for risk control must be identified.
- •The architecture must be verified before implementation begins.
- •Architecture documentation must be updated when structural changes occur.
- •For Class B and C software, SOUP items must be identified in the architecture with their exact version numbers, supplier information, and system hardware and software dependencies per IEC 62304:2006+A1:2015 clause 5.3.3.
- •For Class B and C software, the architecture must specify SOUP configuration parameters or conditions required for the SOUP to operate within its specified functional and performance requirements.
- •For Class C software, the architecture must identify software items that implement risk controls and specify the segregation required to ensure those items cannot be adversely affected by other software items per IEC 62304:2006+A1:2015 clause 5.3.5.
- •The rationale for the chosen segregation approach — whether physical or logical — must be documented when segregation is used to support a lower safety classification.
- •Security-related architecture elements must be addressed in the architecture design per IEC 62304:2006+A1:2015 clause 5.2.2, including identification of interfaces and data flows that are relevant to security risks.
Common gaps
SOUP items not specified in architecture with exact versions
majorIEC 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
majorNotified 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
majorTeams 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.
Evidence signals
- •
FILE_EXISTS
Software.*Architecture|Architecture.*Description|System.*Architecture|SOUP.*List
- •
CONTENT_MATCH
Does this document describe the major software components, their interfaces, SOUP dependencies with version and functional requirements, and any required segregation for risk control purposes?
Audit defense
The Software Architecture Description for [your product] (Doc ID: [your document ID]) identifies all major software items, interfaces, and SOUP dependencies with version-specific requirements. The architecture was verified using our Checklist Software Architecture before implementation and updated following any structural changes.