EN 62304:2006+A1:2015 Section 5.1 requires the manufacturer to establish a software development plan before the development activities begin. The plan must cover the life cycle model, the deliverables and their traceability, the standards and methods to be used, the integration with risk management under EN ISO 14971, the configuration management approach, the problem resolution approach, and the verification and release criteria. The plan is scaled by the software safety class — lighter for Class A, fuller for Class C — and it has to reflect what the engineering team actually does, not a template from another company. 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

  • EN 62304:2006+A1:2015 Section 5.1 is the clause that requires a software development plan (SDP) for every medical device software project.
  • The SDP has to exist before the other development activities under Sections 5.2 through 5.8 begin, and it has to be updated as the software evolves.
  • The plan covers the life cycle model, the deliverables, the traceability, the standards and methods, the integration with risk management, the configuration management approach, the problem resolution approach, and the verification and release criteria.
  • The plan scales with the software safety class determined under EN 62304:2006+A1:2015 Section 4.3 — Class C plans are fuller than Class A plans, but every class requires a plan.
  • The SDP connects into the QMS under EN ISO 13485:2016+A11:2021 through the design and development control clause, and the two must be internally consistent.
  • For a startup, a five-to-ten page plan that the team actually follows beats a fifty-page plan copied from a consultant template that the team ignores.
  • The most common gap auditors find is not the absence of a plan — it is a plan that describes a process the team does not run.

Why the software development plan is where the lifecycle lives or dies

Every medical software team we work with has the same moment with the software development plan. Someone on the team — usually the engineering lead, sometimes the regulatory hire, occasionally a consultant on a scoping call — says "we need an SDP" and the conversation stalls. What goes in it? How long should it be? Is there a template? Does it matter if we have been writing code for six months already? The questions are reasonable and the answers tend to be wrong in one of two directions.

The first wrong direction is the fifty-page plan copied from a consultant template. It covers every clause of EN 62304:2006+A1:2015, every sub-clause, every interpretive note. It looks thorough. The team reads it once, files it, and goes back to writing code under whatever process they had before. When the Notified Body audits, the file shows a plan that describes a process the team does not run. That is the single most common finding on software lifecycle audits, and it is fatal — not because the plan is wrong, but because the plan and the reality do not match.

The second wrong direction is the absent plan. The team starts writing code, runs tests, ships to pilot users, and treats the SDP as something to write later "when we have time for the QMS work." Six or twelve months in, the certification project starts and someone has to reconstruct a plan for code that already exists. Reconstruction works on paper. It does not work in audit rooms, because the plan has to pre-date the activities it plans, and a plan written after the fact cannot.

The right direction is a short, real plan written before the development activities begin and updated continuously as the software and the team evolve. Section 5.1 of EN 62304:2006+A1:2015 is the clause that requires it, and the clause is specific about what the plan must cover. This post walks through Section 5.1, how the content scales with the software safety class, how the plan integrates with the QMS under EN ISO 13485:2016+A11:2021, what the startup-scale version looks like, and the gaps that repeatedly show up in audits.

What Section 5.1 of EN 62304:2006+A1:2015 requires in the plan

Section 5.1 of EN 62304:2006+A1:2015 — Software development planning — sets out the content a software development plan must contain. The required elements are specific and they are not optional. A plan that is missing any of them is incomplete, regardless of page count.

The plan must identify the processes, activities, and tasks that will be performed during the software development, and it must cover the life cycle model the team will use. The standard is neutral on which life cycle model is chosen — waterfall, iterative, agile, continuous delivery — but whatever model is used has to be named, described at the level the team runs it, and followed.

The plan must identify the deliverables of the software development activities — the outputs each activity produces — and their traceability. Traceability means the chain from system requirements down through software requirements, architecture, detailed design, implementation, and verification, with every link in the chain documented and checkable.

The plan must reference the software development standards, methods, and tools that will be used. This includes programming languages, coding standards, development environments, testing tools, static analysis tools, and any other tool whose output contributes to the regulatory file. Tools whose failure could affect the safety of the device are subject to additional controls.

The plan must cover the integration with the software risk management process. This is the bridge from EN 62304:2006+A1:2015 to EN ISO 14971:2019+A11:2021. The SDP has to state how risk management runs alongside development, how the outputs of the risk process feed into the software safety class determination, and how risk control measures implemented in software are verified.

The plan must cover the software configuration management approach and the software problem resolution approach. These two processes run continuously through the lifecycle and the plan has to define how they operate — what is under configuration control, how versions are identified, how changes are authorised, how anomalies are captured, investigated, and closed.

The plan must define the software verification activities and the criteria for release. Verification is the set of checks that each activity meets its requirements; release is the gate where the manufacturer confirms that all planned activities are complete and the software is ready for clinical use.

Finally, the plan has to be kept up to date. Section 5.1 is explicit that the plan is maintained throughout the lifecycle. A plan written once at the start of the project and never revisited does not meet the clause, because the clause assumes the plan reflects the current state of the process.

How the plan scales with the software safety class

The content required by Section 5.1 is the same across all three software safety classes — Class A, Class B, and Class C all need a plan — but the depth scales with the class. The scaling follows the principle that runs through the entire standard: higher severity of possible harm means more required activities, which means more content in the plan that governs those activities.

Class A plans cover the life cycle model, the deliverables at the requirements and system-testing level, the standards and tools, the risk management integration, the configuration management approach, the problem resolution approach, and the release criteria. They do not need to elaborate on architectural design or unit-level verification, because those activities are not required for Class A software. A competent Class A plan can be five to eight pages.

Class B plans add architectural design deliverables, detailed design at the software item level, integration test planning, and the additional configuration and problem-resolution rigour that Class B items need. A competent Class B plan is eight to fifteen pages.

Class C plans add detailed design at the unit level, unit verification planning, the fullest integration test strategy, and the tightest release criteria the project will use. Class C plans also need more explicit coverage of the verification of risk control measures implemented in software, because Class C software is, by definition, software that could contribute to death or serious injury. A competent Class C plan is fifteen to thirty pages.

If your project contains software items at different classes — which is the normal outcome of an honest classification exercise under Section 4.3 — the plan has to say which parts of the plan apply to which class, or maintain class-specific sections. A monolithic Class C plan applied to a mixed-class codebase commits the team to Class C work on Class A items and wastes the segregation work that got the items to Class A in the first place.

The scaling is not a license to cut the mandatory elements for lower classes. Every element in Section 5.1 is required for every class. What changes is the depth at which each element is described, not whether it is described at all.

How the plan integrates with the QMS under EN ISO 13485

EN 62304:2006+A1:2015 assumes the manufacturer operates under a QMS aligned with EN ISO 13485:2016+A11:2021. The SDP is not a free-standing document; it sits inside the design and development control process of the QMS, which is where the 13485 standard places planning for product development.

The integration works in two directions. First, the QMS defines the generic design and development control process — what a design input is, how design outputs are verified against inputs, how design reviews are run, how design changes are controlled. The SDP applies that process to a specific software project and adds the software-specific content required by Section 5.1. The SDP does not repeat the QMS — it references it and adds the software layer on top.

Second, the QMS defines the cross-cutting processes the SDP depends on. Document control, record control, training, supplier management, CAPA, internal audit, management review — all of these are QMS processes, and the SDP is written assuming they exist and are running. A startup that writes an SDP before the QMS is built ends up with a plan that references processes that do not exist, and the inconsistency is a finding waiting to happen.

The practical implication is that the SDP cannot be written in isolation. It is written alongside the QMS design and development procedure, and the two are reviewed together whenever either one changes. For a small team, this means one regulatory lead owns both documents or two people own them with a shared review cadence. It does not mean one document for each software item.

The startup-scale software development plan

A lean SDP that meets Section 5.1 and scales to a real startup engineering team covers the following sections. This is not a template to copy — it is the minimum content the plan has to address, expressed as the questions the plan answers.

Scope and intended purpose. What software system does this plan cover? What is the intended purpose of the device, and what role does the software play in it? What is the software safety class of each software system under the plan, and how does it relate to the MDR device class under Annex VIII Rule 11?

Life cycle model. What development model does the team use — agile sprints, continuous delivery, hybrid? How are the EN 62304:2006+A1:2015 activities mapped onto the chosen model? When do planning, requirements, design, implementation, and verification happen in the team's actual cadence?

Deliverables and traceability. What documents, code artefacts, test results, and records does each activity produce? How is traceability maintained from system requirements to software requirements to design to implementation to verification? Where does the traceability record live, and how is it kept current?

Standards, methods, and tools. What programming languages, frameworks, coding standards, development environments, and tools does the team use? Which tools contribute to the regulatory evidence, and how are they qualified or controlled? How are third-party components (open-source libraries, commercial SDKs) managed under Section 8 of the standard?

Risk management integration. How does the software risk-management process under EN 62304:2006+A1:2015 connect to the EN ISO 14971:2019+A11:2021 process for the device? Who owns the risk file? How do risk control measures implemented in software get verified, and how do the results feed back into the risk file?

Configuration management. What is under configuration control — source code, documents, third-party components, build scripts, tools? How are items identified, versioned, and changed? How is a release reproducible from the configuration management record?

Problem resolution. How are anomalies captured, investigated, classified, resolved, and verified? How do resolved problems link back to risk management, configuration management, and release?

Verification and release criteria. What has to be true before a software release can go to clinical use? What are the gates, what evidence closes each gate, and who approves the release?

Maintenance. How does the plan extend into post-release maintenance? What is the maintenance cadence, how are maintenance activities scoped, and how do they trigger re-verification?

Plan maintenance. Who owns the SDP? When is it reviewed? How are changes to the plan itself recorded?

A plan that answers those ten questions honestly, in the team's own words, reflecting what the team actually does, is a plan that will survive audit. A plan that looks polished but does not match the team's work is not.

Common gaps auditors find in software development plans

The gaps in software development plans are predictable and they repeat across companies. The following are the ones we see most often.

The plan describes a process the team does not run. This is the most common finding, and it is the single biggest reason SDP audits go badly. The plan references daily stand-ups that do not happen, code review procedures that are not followed, test reports that are not produced. The auditor asks to see the artefact, the team cannot produce it, and the finding is written. The fix is to write the plan around the process the team runs, not around what the plan "should" say.

The plan and the QMS design and development procedure contradict each other. The SDP says changes are approved by the engineering lead; the QMS procedure says changes are approved by the design authority. The two sentences are from different documents written by different people at different times, and nobody noticed the inconsistency until the auditor did. The fix is to review the two documents together and reconcile them before either one ships.

The plan does not reflect the software safety class. A plan written before the class was determined, or written to a single class when the items have different classes, or written to Class C when the items are Class B. The fix is to determine the class under Section 4.3 first, then write the plan scaled to the class.

The plan is missing one of the Section 5.1 elements. Usually it is the problem resolution approach or the release criteria that get left out, because the team has not thought about them yet. The fix is to run the Section 5.1 checklist against the plan before it is signed.

The plan is static. Written once at project start, never updated, while the team's actual process has evolved substantially. The fix is a review cadence — every sprint, every release, every risk file change — and an explicit owner.

The plan references tools without qualifying them. Static analysis tools, test automation frameworks, build systems whose output goes into the regulatory file. Section 5.1 expects the team to identify these tools in the plan, and Section 8 expects controls on them. The fix is to list the tools explicitly and document what role each one plays.

The Subtract to Ship angle — the shortest plan that survives audit

The software development plan is the category where the temptation to add is strongest. Templates promise comprehensiveness. Consultants recommend thoroughness. The team's instinct is to cover every possible requirement so nothing is missed. Every one of those moves makes the plan longer, harder to maintain, and more likely to drift from reality.

The Subtract to Ship move is to write the shortest plan that meets every element of Section 5.1, reflects the software safety class of each item honestly, describes the team's actual process, and stays current. Everything beyond that is waste — not because it is wrong, but because it will not be read, will not be followed, and will not survive the first material change to how the team works.

The subtraction test is the same as for the broader framework: can every paragraph in the plan be traced to a specific Section 5.1 requirement or to a specific team practice that supports it? If yes, keep it. If no, cut it. The plan that remains is shorter than the template, harder to write, and much more likely to hold up in audit. For the broader framework applied to MDR, see post 065.

Reality Check — Is your software development plan ready for audit?

  1. Does your software development plan exist before the development activities it governs, or was it reconstructed after the fact?
  2. Does the plan cover every element of EN 62304:2006+A1:2015 Section 5.1 — life cycle model, deliverables, traceability, standards and tools, risk management integration, configuration management, problem resolution, verification, release criteria?
  3. Is the plan scaled to the software safety class of each software item, not bulk-written to a single class for the whole system?
  4. Does the plan describe the process the engineering team actually runs, or a process copied from a template?
  5. Is the plan internally consistent with the design and development control procedure in your QMS under EN ISO 13485:2016+A11:2021?
  6. Is there a named owner for the plan, and a defined review cadence that updates the plan as the process and the code base evolve?
  7. Are the tools the team uses — compilers, testing frameworks, static analysis, build systems — named in the plan and subject to appropriate controls?
  8. Would the plan survive a skeptical Notified Body auditor who asked to see one artefact from each activity listed in the plan?

Any question you cannot answer with a clear yes is a gap. Plans are cheaper to rewrite than to reconstruct, and they are cheaper to rewrite before the audit than during it.

Frequently Asked Questions

Is a software development plan required for Class A software? Yes. EN 62304:2006+A1:2015 Section 5.1 applies to all three software safety classes. Class A software needs a plan that covers all the required elements — the depth of the plan scales with the class, but the plan itself is required for every class, including Class A.

How long should a software development plan be? As long as it needs to be to cover every element of Section 5.1 honestly and no longer. For a Class A software item on a small team, five to eight pages is often enough. For a Class C codebase with multiple software items, fifteen to thirty pages is typical. Length is not the quality indicator — fidelity to the team's actual process is.

Can the software development plan be merged with the design and development plan in the QMS? Yes, if the merged document covers both the generic QMS design and development control content and the software-specific content required by Section 5.1. Many startups find a single combined document easier to maintain than two separate plans. What matters is that every Section 5.1 element is covered and the document is consistent with the rest of the QMS.

When does the plan have to be written? Before the development activities it governs begin. EN 62304:2006+A1:2015 Section 5.1 is clear that planning precedes execution. In practice this means the plan exists before the first sprint of code that is intended to become medical device software. Plans written after the fact do not satisfy the clause, no matter how polished they look.

How often should the plan be updated? Whenever the process it describes changes materially. For most startups this means a formal review at every major release, at every risk file update, and at every team or tool change that affects how the lifecycle runs. The plan is a living document, not a project-start artefact.

Does agile development need a different kind of plan? No. Section 5.1 is neutral on life cycle model. Agile plans cover the same elements as waterfall plans — they just describe how the activities run in sprint cadence rather than in phases. The key is that the plan names the model, describes how the required activities map onto it, and matches what the team actually does.

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 5.1 Software development planning. Harmonised standard referenced for the software lifecycle under MDR Annex I Section 17.
  3. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes. Harmonised standard referenced for the QMS under MDR Article 10(9) and Annex IX.

This post is a category-9 spoke in the Subtract to Ship: MDR blog, focused on the software development plan required by EN 62304:2006+A1:2015 Section 5.1. 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 support on writing a software development plan that matches a real engineering team and survives Notified Body audit, Zechmeister Strategic Solutions is where this work is done in practice.