{"id":66,"date":"2025-12-30T22:55:20","date_gmt":"2025-12-31T06:55:20","guid":{"rendered":"https:\/\/grumpyoldengineer.com\/?p=66"},"modified":"2026-09-24T11:49:01","modified_gmt":"2026-09-24T19:49:01","slug":"architectural-risk-segregation-doesnt-need-to-be-difficult-iec-62304","status":"publish","type":"post","link":"https:\/\/grumpyoldengineer.com\/?p=66","title":{"rendered":"Architectural risk segregation (IEC 62304)"},"content":{"rendered":"\n

Software segregation is one of those architectural concepts everyone claims to understand until you ask them to actually do it. In theory it\u2019s simple, prevent a failure in one part of the system from dragging the rest of the system into the abyss. In practice, many teams treat segregation like a decorative sticker they slap onto a PowerPoint right before an audit.<\/p>\n\n\n\n

This discussion focuses on medical software under IEC 62304, because nothing sharpens architectural thinking quite like the possibility of harming a patient or failing an audit so catastrophically it becomes a cautionary tale.<\/p>\n\n\n\n

While there are numerous ways to go about segregating risk in an architectural fashion, I put forth a stripped-down method which should be straight forward enough and practical for the general audience.<\/p>\n\n\n\n

And yes, you cannot perform risk segregation without a documented architecture. Trying to do software risk segregation without architecture is like trying to perform surgery with a spoon and fork.<\/p>\n\n\n\n

Terminology<\/h2>\n\n\n\n

Let\u2019s start with terminology, because IEC 62304 loves its taxonomy almost as much as organizations love misusing it<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

Everything is a software item. The top\u2011level item is the software system, and the leaf is the software unit. This is an important concept to understand as IEC 62304 defines requirements based on these terms. If a requirement says \u201csoftware item”, then the requirement applies to all elements. Other domains use similar hierarchies (CSCI, CSC, CSU), but the point is the same, you need to know what you\u2019re classifying before you start classifying it.<\/p>\n\n\n\n

The Method<\/h2>\n\n\n\n

Step 1) Identify all hazardous sequences per risk analysis<\/h3>\n\n\n\n

This assumes you actually conducted a risk analysis and didn\u2019t just recycle last year\u2019s spreadsheet. Each risk has severity, occurrence, and criticality, which map to safety classes. The important part is the sequence of events, the chain that leads to harm.<\/p>\n\n\n\n

Step 2) Identify all design threads for each hazardous sequence<\/h3>\n\n\n\n

This requires architecture and design to exist in more than tribal memory. Behavioral diagrams, structural diagrams, logical views, process views. Whatever your methodology, you need something concrete as you’ll need to mark the interface as you trace each hazardous sequence through the design.<\/p>\n\n\n\n

Example here uses sequence diagram showing the behavioral relationship and a component diagram showing the interfaces provided by each SW Item.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Start by marking all interfaces with safety classification of Class A as shown below.<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

This is now your baseline before reality ruins your optimism.<\/p>\n\n\n\n

Step 3) Assess each design and apply the safety classification to interfaces<\/h3>\n\n\n\n

Walk through each behavioral diagram and identify invocations that contribute to the hazardous sequence. Mark the interface with the corresponding safety class (A, B, or C).<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

As we iterate through each risk item, overwrite the lower one with the higher safety class. This is not a negotiation. By the end, every relevant interface should be marked.<\/p>\n\n\n\n

Once this activity is conducted for all hazard risks, we should end up with a safety class marking on all applicable interfaces as illustrated below.<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

I would like to point out that we’re assigning the safety class on the interface rather than the software item itself. This is to provide the architectural flexibility in composing the system.<\/p>\n\n\n\n

The granularity classification can be on the interface or on the operation. This is for the team to decide based on how architecture\/design is conducted.<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

For example, if we want to split or combine a software item for risk segregation purposes, it’s a lot easier to have the safety class retained on the interface for composability purpose.<\/p>\n\n\n\n

Step 4) Apply the highest safety classification to the SW Item<\/h3>\n\n\n\n

Now propagate the highest interface safety classification to the software item providing that interface.<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

We now have safety classifications on each software item and able to create a breakdown structure as illustrated below.<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

Steps 1-4 are recursive and can be applied to lower-level software item if the software system has multiple layers. The same method can be used for FMEA when hazard contributing scenarios are identified and new risks are generated.<\/p>\n\n\n\n

Closing thoughts<\/h2>\n\n\n\n

Software risk segregation is not<\/em> an activity the software team can “just do” at the end of development. It relies on existing software architecture\/design that is built up over the course of project execution. It is an iterative process as risks are identified and mitigated.<\/p>\n\n\n\n

Risk segregation is all about architectural justification. It’s not about writing one or two bullshit sentences to justify why it’s a certain safety class and “handwaving” in front of auditors. Remember, risk segregation is ultimately to ensure patient safety.<\/p>\n\n\n\n

Per IEC 62304, safety classification is tied to the required deliverables and activities (e.g., class A does not require design or unit verification deliverables). This is why some organizations desperately try to classify everything as Class A, fewer deliverables, less work, more denial. This behavior is dangerous, lazy and unprofessional. My advice is if you don’t know how to conduct risk segregation, then find somebody who can, and get out of their way.<\/p>\n\n\n\n

Risk segregation requires a mature organization and people who actually understand architecture and design, it’s not a creative writing prompt.<\/p>\n\n\n\n

If your organization has no idea what it\u2019s doing, the safest option might be to classify everything as Class C <\/strong>and verify the hell out of it. At least then you\u2019re being consistently cautious instead of inventing bullshit rationales to justify lowering safety classes.<\/p>\n\n\n\n

Half\u2011assing safety classification doesn\u2019t make your system safer. It just makes your audit more interesting.<\/p>\n","protected":false},"excerpt":{"rendered":"

Software segregation is one of those architectural concepts everyone claims to understand until you ask them to actually do it. In theory it\u2019s simple, prevent a failure in one part of the system from dragging the rest of the system into the abyss. In practice, many teams treat segregation like a decorative sticker they slap […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[],"class_list":["post-66","post","type-post","status-publish","format-standard","hentry","category-architecture"],"_links":{"self":[{"href":"https:\/\/grumpyoldengineer.com\/index.php?rest_route=\/wp\/v2\/posts\/66","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/grumpyoldengineer.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/grumpyoldengineer.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/grumpyoldengineer.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/grumpyoldengineer.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=66"}],"version-history":[{"count":5,"href":"https:\/\/grumpyoldengineer.com\/index.php?rest_route=\/wp\/v2\/posts\/66\/revisions"}],"predecessor-version":[{"id":265,"href":"https:\/\/grumpyoldengineer.com\/index.php?rest_route=\/wp\/v2\/posts\/66\/revisions\/265"}],"wp:attachment":[{"href":"https:\/\/grumpyoldengineer.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=66"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/grumpyoldengineer.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=66"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/grumpyoldengineer.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=66"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}