---
title: How MDR Software Safety Class Drives Your Development Effort via IEC 62304
description: EN 62304 scales activities by software safety class. Here is what changes between A, B, and C and how much effort each level actually requires.
authors: Tibor Zechmeister, Felix Lenhard
category: Software as a Medical Device
primary_keyword: software safety class drives development effort
canonical_url: https://zechmeister-solutions.com/en/blog/software-safety-class-drives-effort
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# How MDR Software Safety Class Drives Your Development Effort via IEC 62304

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **EN 62304:2006+A1:2015 scales the required software lifecycle activities by software safety class. Class A requires planning, requirements, implementation, system testing, release, maintenance, risk management, configuration management, and problem resolution. Class B adds architectural design, detailed design at the software item level, and integration testing. Class C adds detailed design at the unit level and unit-level verification. The class is assigned per EN 62304:2006+A1:2015 Section 4.3 from the severity of possible harm identified in the EN ISO 14971:2019+A11:2021 risk-management process, and it drives how much engineering work the team has to do for the next twelve months. The MDR is the North Star. EN 62304:2006+A1:2015 is the tool.**

**By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.**

---

## TL;DR

- The software safety class assigned under EN 62304:2006+A1:2015 Section 4.3 scales the lifecycle activities the standard requires, not the standard itself.
- Class A is the lightest lifecycle: planning, requirements, implementation, system testing, release, maintenance, risk management, configuration management, problem resolution.
- Class B adds architectural design, detailed design at the software item level, and integration testing on top of the Class A activities.
- Class C adds detailed design at the unit level and unit-level verification on top of the Class B activities.
- The documentation volume scales with the class because more required activities mean more required records.
- Risk control under EN ISO 14971:2019+A11:2021 drives the class — the severity of the worst-case software contribution to harm is the input that determines A, B, or C.
- Honest classification plus segregation is how a resource-constrained startup keeps the engineering scope proportionate to the real risk rather than inflated by fear.

---

## The fork in the road that sets the budget

Every medical software team we work with hits the same planning conversation. The engineering lead sketches a roadmap. The founder looks at the runway. The question lands on the table: how much lifecycle work does EN 62304:2006+A1:2015 actually require us to do? The answer decides the next twelve months of engineering capacity. A team that has correctly scoped a Class B product will ship on a fraction of the effort of a team that defaulted its whole system to Class C. A team that should be Class C but documented Class A will be sent back by the Notified Body and rebuild the file under deadline pressure.

The software safety class is the single biggest effort multiplier in the medical software lifecycle. It does not change the list of activity areas EN 62304:2006+A1:2015 names — the areas stay the same. What it changes is which activities the standard requires inside those areas, at what depth, and with what documentation. Class A skips entire activities that Class C treats as mandatory. Class B sits in between. The gap between Class A and Class C for the same code base is large enough that it reshapes hiring plans, sprint velocity, and the date the QMS says the software can enter conformity assessment.

This post walks through the activities at each class, shows the documentation volume difference, explains how the risk-management process drives the class, and then translates the whole thing into the planning terms a startup actually uses. For the definitions of Class A, B, and C themselves, post 377 is the companion spoke. For the MDR device class under Annex VIII Rule 11 — which is a different classification — post 371 is the pillar.

## Class-to-activity mapping — what the standard requires at each level

EN 62304:2006+A1:2015 organises the software lifecycle into process groups. The class determines which activities inside those groups are required. The table below summarises what each class requires, based on the process sections of EN 62304:2006+A1:2015.

| Process area | Class A | Class B | Class C |
|---|---|---|---|
| Software development planning | Required | Required (deeper) | Required (deepest) |
| Software requirements analysis | Required | Required | Required |
| Software architectural design | Not required | Required | Required |
| Software detailed design | Not required | Required at item level | Required at unit level |
| Software unit implementation | Required | Required | Required |
| Software unit verification | Not required as separate activity | Not required as separate activity | Required |
| Software integration and integration testing | Not required | Required | Required |
| Software system testing | Required | Required | Required |
| Software release | Required | Required | Required |
| Software maintenance | Required | Required | Required |
| Software risk management | Required | Required | Required |
| Software configuration management | Required | Required | Required |
| Software problem resolution | Required | Required | Required |

Every "Required" in that table corresponds to documented evidence in the lifecycle file. Every "Not required" is an activity the standard does not oblige the team to run as a distinct, documented process for that class — though modern engineering practice often runs it anyway.

The pattern is a staircase. Class A sits at the bottom with nine required activity areas. Class B adds architectural design, item-level detailed design, and integration testing for twelve. Class C adds unit-level detailed design and unit-level verification for thirteen or fourteen depending on how you count. Each step up the ladder adds a band of required work and a band of required documentation.

## Class A — what the lifecycle actually looks like

At Class A, EN 62304:2006+A1:2015 requires a complete but lean lifecycle. The team writes a software development plan that covers the processes, deliverables, and configuration approach. The team writes software requirements, traces them to system requirements, and verifies each one. The team implements the code. The team runs system-level testing — the software as a whole tested against the requirements. The team controls the release — a documented, verified build produced through a controlled process. The team maintains the software through a defined maintenance process. The team runs risk management throughout. The team controls configuration — source code, documents, third-party components. The team handles problem reports through a documented resolution process.

What Class A does not require, as a separate obligation of the standard: architectural design as a distinct activity, detailed design, unit-level verification, and integration testing. The standard is explicit that these activities are scaled down or excluded at Class A because the software cannot contribute to any injury in the worst case.

This does not mean a Class A team skips engineering discipline. Most Class A teams we see still run unit tests, still write architectural diagrams, and still run integration checks — because these are good practices that protect the code base regardless of the standard's requirement. What they skip is the formal documentation burden. The unit tests exist in the CI pipeline; they do not need to be recorded as a formal verification activity in the lifecycle file. The architecture lives in a diagram; it does not need to be a controlled document in the QMS. The discipline is kept. The paperwork is not added on top.

## Class B — what changes from Class A

At Class B, three new activities become required on top of the Class A baseline.

**Software architectural design.** The team produces a documented architecture that identifies the software items — the components the system is decomposed into — and the interfaces between them. The architecture supports the segregation arguments that might keep some items at lower classes and documents how the software handles the hazardous situations identified in the risk file. The architecture becomes a controlled document in the lifecycle file.

**Software detailed design at the software item level.** For each software item in the architecture, the team produces a detailed design that is deep enough to support implementation and verification without further architectural work. At Class B the depth is the item — not the individual unit or function — but the item design is documented and traceable.

**Software integration and integration testing.** As items are integrated into the system, the team runs documented integration testing that verifies the interactions between items work as the architecture specifies. Integration testing is distinct from system testing and produces its own records.

The planning document also expands because the plan now has to describe how the architectural work, the detailed design work, and the integration testing fit into the overall lifecycle. The risk management activity expands because the architectural decomposition surfaces more hazardous situations that have to be analysed. The documentation volume for a Class B project is meaningfully larger than for a Class A project of the same scope — in our experience, often two to three times the documented output for the same code base.

Most medical software we see at startup stage lands in Class B once the risk analysis is honest. The software provides information used for decisions, but the worst case is reversible harm. The team has to do real architectural work, real design at the item level, and real integration testing. The lifecycle is substantial. It is also manageable with a small team and a disciplined pipeline.

## Class C — what changes from Class B

At Class C, two further activities become required on top of the Class B baseline, and the depth of the existing activities increases.

**Software detailed design at the unit level.** The detailed design goes down one level — from the software item to the individual software unit. A software unit is the smallest component the standard recognises for verification purposes, and the Class C design documents every unit with enough detail that another engineer could implement it from the specification. This is a significant documentation expansion over Class B.

**Software unit verification.** Each software unit is verified against its detailed design as a distinct, documented activity. Unit verification can take the form of unit tests, code reviews, or static analysis, depending on what the team's process specifies — the standard does not mandate a single method. What it mandates is that the verification happens, produces records, and covers every unit. The records live in the lifecycle file.

The depth of the Class B activities also increases. Architectural design at Class C is more rigorous because the architecture has to support unit-level decomposition. Integration testing at Class C is more thorough because the interfaces between units are examined in addition to the interfaces between items. Risk management integration at Class C is tighter because the software contribution to harm can be fatal, which makes every hazardous situation analysis load-bearing.

The documentation volume at Class C is the largest in the standard. Teams moving from Class B to Class C for the same code base typically see the documented evidence double again — roughly four to six times a Class A project of the same scope. This is not waste. It is the standard's response to the fact that a software failure at Class C could contribute to death or serious injury, and the evidence of disciplined development has to match the stakes.

## Documentation volume differences — what the file actually looks like

Three projects, same code base, three different software safety classes. Here is what the lifecycle files look like at the end.

**The Class A file.** Software development plan. Software requirements specification with traceability. Implementation records sufficient for configuration management. System test protocol and records. Release records. Maintenance plan. Risk management file (feeding and fed by the EN ISO 14971:2019+A11:2021 process). Configuration management records. Problem resolution records. The file is organised, traceable, and lean. It fits in a structured document repository that a small team can maintain without a dedicated document controller.

**The Class B file.** Everything in the Class A file, plus software architecture document, detailed design documents at the software item level, integration test protocols and records, and expanded planning to cover the additional activities. The trace matrix now runs from system requirements to software requirements to architecture to item-level design to integration tests to system tests. The file is noticeably larger, and maintaining it requires more discipline — document versioning, review cycles, and change control across more artifacts.

**The Class C file.** Everything in the Class B file, plus unit-level detailed design documents, unit verification records for every unit, and further expanded planning and risk integration. The trace matrix runs all the way from system requirements down to individual units and their verification records. The file is the largest, and maintaining it through iterative development requires either strong automation of the traceability and documentation layer or a dedicated team member whose job is to keep the file current.

The size difference matters because it is not just a one-time cost. The file has to stay current as the code evolves, and every change to the code triggers updates across the trace matrix. A Class C project with active development has an ongoing documentation workload that a Class A project does not. This is one of the reasons segregation matters so much in practice — if a startup can legitimately keep large portions of its code base at Class A while the safety-critical core runs at Class C, the steady-state documentation load is dramatically lower than if everything carried Class C.

## How risk control drives the class

The class is not chosen. It is derived. EN 62304:2006+A1:2015 Section 4.3 requires the class to be assigned from the outputs of the risk-management process, and EN ISO 14971:2019+A11:2021 defines that process. The chain is specific.

The risk-management process identifies the hazardous situations the device can contribute to, estimates the severity of the possible harm for each situation, and evaluates whether the risk is acceptable. For every hazardous situation to which the software can contribute, the severity of the possible harm is recorded. The software safety class is then the worst-case severity across all those contributions — before external risk controls outside the software are taken into account. If the worst case is death or serious injury, the class is C. If the worst case is non-serious injury, the class is B. If no contribution could lead to any injury, the class is A.

External risk controls can reduce the class, under conditions. A hardware cut-off circuit that is independent of the software, itself verified, and controlled under the QMS can reduce the severity of the software's contribution such that the class drops. A procedural control that does not rely on the software — a clinician checking the output against a reference before acting — can also reduce the class if the control is effective and documented. What cannot reduce the class is another piece of software running in the same system as the software being evaluated. A software watchdog is not an external control.

This is where the risk-management file and the software lifecycle file have to talk to each other continuously. A change in the risk file — a new hazardous situation identified, a severity re-estimated, an external control removed — can change the class, which changes the required lifecycle activities, which changes the engineering effort. Teams that run these two files as independent workstreams get caught when the files diverge. Teams that run them together catch problems early.

## What this means for startup planning

The planning implication is direct. Before the engineering team picks a sprint cadence, before the founder writes a board update, before the QMS timeline is signed off, the software safety class has to be assigned from the risk file. The assignment determines the list of activities the lifecycle has to run, which determines the engineering effort, which determines the runway the project consumes.

The most expensive mistake we see at this stage is inflation. A founder worried about the Notified Body assigns Class C to everything. The engineering team commits to the full Class C lifecycle for modules whose risk does not warrant it. Six months in, the runway is gone, the code base is still small, and the file is bloated with unit-level design documents for the administrative module. The founder's caution cost them the company.

The second most expensive mistake is deflation. A team hoping for a lighter lifecycle assigns Class A to code that deserves Class B. The file gets built under Class A assumptions. The Notified Body reads it, identifies the mismatch, and the team rebuilds the lifecycle activities under deadline pressure. Rebuilding is more expensive than building right because the code has moved on and the reconstruction has to chase it.

The honest path is the middle. Run the risk analysis. Assign each software system the class the risk genuinely supports. Use segregation to keep lower-risk items out of the top class. Use external risk controls where they are genuinely independent and verified. Document the reasoning. Then build the file to match the class, and no larger.

## The Subtract to Ship angle — scope the lifecycle to the class

The software safety class is the category where Subtract to Ship pays off most visibly. The default move — Class C on everything to be safe — adds lifecycle activities, documentation, and review layers that the standard does not require once the class is assigned correctly. It looks diligent and is actually waste. The subtraction move is to assign the class from the risk file, apply segregation where the architecture supports it, and then run the activities the standard requires at that class — no more, no less.

Every activity in the final lifecycle plan should survive a single test. Does the activity trace to a required process of EN 62304:2006+A1:2015 at the assigned class? If yes, it stays. If the only justification is "we thought we should," it comes out. The standard is specific about what is required at each class, and the specificity is the lever the subtraction uses. For the broader framework, see post 065. For the class definitions this post operationalises, see post 377. For the MDR device class that is often confused with the software safety class, see post 371.

## Reality Check — Is your lifecycle scoped to the correct class?

1. Have you assigned a software safety class to each software system in your product, in writing, traced to the EN ISO 14971:2019+A11:2021 risk file?
2. Does your software development plan list the activities EN 62304:2006+A1:2015 requires for your assigned class, and only those?
3. If you are at Class B or Class C, does the architectural design document actually exist, or is it a placeholder?
4. If you are at Class C, does the unit-level detailed design exist for every unit, and does unit verification run as a distinct, documented activity?
5. Is the documentation volume proportionate to the class, or is it inflated by activities the standard does not require at your class?
6. When the risk file changes, does the lifecycle plan get revisited, or does it drift?
7. If you have used segregation to keep items at lower classes, is the segregation argued, implemented, verified, and documented?
8. Would the lifecycle file survive a Notified Body audit that asked to see the trace from risk file to class to activities?

Any answer short of a clear yes is a gap. Close it before the next sprint plans work that is either above or below the class the standard requires.

## Frequently Asked Questions

**How much more effort is Class C compared to Class A for the same code base?**
In our experience, a Class C lifecycle file for the same code base is roughly four to six times the documented output of a Class A file, and the steady-state documentation maintenance is correspondingly larger. The engineering effort increase is not linear with the documentation — much of the extra work is design and verification rigour at the unit level, which also adds engineering hours on top of the paperwork. Class B sits in the middle at roughly two to three times the Class A output.

**Does Class A mean no unit tests?**
No. Class A means EN 62304:2006+A1:2015 does not require unit-level verification as a distinct, documented activity of the standard. Most Class A teams still run unit tests because they are good engineering practice. The tests exist in the CI pipeline; they do not need to be formalised as a lifecycle activity in the file. The discipline is kept; the formal documentation burden is not added.

**Can I skip architectural design if I am at Class A?**
The standard does not require software architectural design as a distinct activity at Class A. Most teams still maintain architectural diagrams because they need them to reason about the code, but the architecture does not have to be a controlled document in the lifecycle file at Class A. At Class B and Class C, architectural design is required and the document becomes part of the lifecycle file.

**What if the risk analysis is not finished when we need to plan the lifecycle?**
The class has to be assignable before the lifecycle activities fully kick in, because the activities depend on the class. In practice, the risk analysis has to be mature enough to support a preliminary class assignment early in the planning phase. The assignment is reviewed as the risk file matures and confirmed once the hazard analysis is complete. A lifecycle planned against a class that later changes has to be re-scoped, which is the most expensive form of rework in this category.

**How does segregation change the effort?**
Segregation lets you assign different classes to different software items inside the same system. If a Class C system contains a Class C safety-critical core and Class A administrative modules that are segregated from the core, the lifecycle work for the administrative modules runs at Class A while the core runs at Class C. The total effort is dramatically lower than running everything at Class C. The segregation has to be argued in the architecture, implemented in the code, verified through testing, and documented in the lifecycle file.

**Does Agile work for Class C?**
Yes. EN 62304:2006+A1:2015 is process-neutral. Agile teams can run Class C lifecycles by automating the traceability layer, producing the required design and verification evidence within each sprint, and maintaining the file continuously rather than in a big-bang release phase. The documentation has to reflect what actually happens, and with a well-set-up Agile pipeline most of the trace matrix can be generated from the existing engineering artifacts.

## Related reading

- [What Is Software as a Medical Device (SaMD)? The MDR Definition for Startups](/blog/what-is-software-as-medical-device-samd-mdr) — the category pillar that frames this post.
- [MDR Software Lifecycle Requirements: How IEC 62304 Helps You Demonstrate Conformity](/blog/mdr-software-lifecycle-iec-62304) — the lifecycle overview that this post drills into.
- [MDR Software Safety Classification: Understanding IEC 62304 Class A, B, and C](/blog/software-safety-classification-iec-62304) — the companion spoke defining the classes this post scales activities from.
- [Software Development Planning Under EN 62304](/blog/software-development-planning-en-62304) — the planning activity that captures the class and the activity scope.
- [Software Requirements Analysis Under EN 62304](/blog/software-requirements-analysis-en-62304) — the requirements activity required at every class.
- [Software Architecture and Detailed Design Under EN 62304](/blog/software-architecture-detailed-design-en-62304) — the design activities that scale from Class B upward.
- [Risk Management for Medical Device Software Under EN ISO 14971](/blog/risk-management-medical-device-software) — the risk process that drives the class determination.
- [EN ISO 14971:2019+A11:2021 Risk Management Overview](/blog/en-iso-14971-risk-management-overview) — the harmonised standard referenced for MDR Annex I risk management.
- [The Subtract to Ship Framework for MDR Compliance](/blog/subtract-to-ship-framework-mdr) — the methodology this post applies to lifecycle scoping.

## Sources

1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Annex I, Section 17. Official Journal L 117, 5.5.2017.
2. EN 62304:2006+A1:2015 — Medical device software — Software life-cycle processes (IEC 62304:2006 + IEC 62304:2006/A1:2015), Section 4.3 Software safety classification and process sections by class. Harmonised standard referenced for the software lifecycle under MDR Annex I Section 17.
3. EN ISO 14971:2019+A11:2021 — Medical devices — Application of risk management to medical devices. Harmonised standard referenced for risk management under MDR Annex I.

---

*This post is a category-9 spoke in the Subtract to Ship: MDR blog, focused on how the EN 62304:2006+A1:2015 software safety class scales the required lifecycle activities and therefore the engineering effort. Authored by Felix Lenhard and Tibor Zechmeister. The MDR is the North Star for every claim in this post — EN 62304:2006+A1:2015 is the harmonised tool that provides presumption of conformity with the software-lifecycle aspects of MDR Annex I Section 17, not an independent authority. For startup-specific regulatory support on scoping the software lifecycle to the correct class, Zechmeister Strategic Solutions is where this work is done in practice.*

---

*This post is part of the [Software as a Medical Device](https://zechmeister-solutions.com/en/blog/category/samd) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*