We once heard: "The Software Development Plan is the first document FDA reviewers open. If it's unclear, they assume the rest of the submission will be too."
That single document sets the tone for everything that follows in your FDA submission. Yet for most teams building medical device software, it's either written too late, treated as a formality, or both.
This guide explains exactly what FDA-compliant software development requires in a Software Development Plan: the sections that matter, the language that works, and the gaps that cause additional information requests. We have also included a free downloadable template at the end.
What is a Software Development Plan — and why FDA cares
The Software Development Plan (SDP) is your upfront commitment to FDA that you knew how you were going to build safe software before you wrote the first line of code. It is required under IEC 62304, the international standard for medical device software development, and it plays a central role in your Design History File.
The key word is plan. An SDP is not a description of what you built. It is documentation that you had a controlled, intentional process for building it and that process was appropriate for the risk class of your device.
What FDA is really looking for
A thin SDP signals a thin development process. Reviewers are experienced enough to read between the lines.
Specifically, FDA wants to see three things from your SDP:
→ That you made deliberate, documented decisions about how to develop safe software — before development began.
→ That those decisions were appropriate for your device's IEC 62304 safety class.
→ That your development approach integrates compliance activities — risk management, verification, configuration control — rather than treating them as a separate phase.
A well-written SDP doesn’t need to be long. It needs to be specific, internally consistent, and clearly connected to the rest of your technical documentation.
The 7 sections of a compliant Software Development Plan
The following sections are expected in any SDP for a Class B or Class C device under IEC 62304. Class A devices have lighter requirements, but a complete SDP is still best practice and typically expected by FDA reviewers regardless of class.
1. Product and intended use overview
This is not a marketing paragraph. It is a precise, technical statement that anchors the entire document. It must answer:
- What does the software do and what clinical function does it support?
- Who is the intended user — clinician, patient, or technician?
- What is the potential harm if the software fails to perform as intended?
This section drives your safety class determination and your risk identification. A vague intended use statement produces a vague risk analysis — and FDA will notice.
2. IEC 62304 software safety class determination
State your class (A, B, or C) and provide a brief, evidence-based justification from your preliminary hazard analysis. FDA wants to understand how you arrived at the classification, not just which box you checked.
A common mistake is stating Class A or Class B with no supporting rationale. Reviewers will ask for the hazard analysis that supports it. Include a summary here and reference the full risk analysis in your risk management documentation.
The FDA has slowly moved away from this classification and now aligns with two types of documentation levels. Read more about it in their Content of Premarket Submissions.
3. Development lifecycle approach
This section is where most teams are vague and where FDA reviewers spend the most time. You need to explain not just what methodology you are using, but how regulatory requirements are integrated into it.
If you are using Agile — which is both acceptable and common under AAMI TIR45 — you must address:
→ Design controls: explain how they map to your sprint cadence
→ Risk management: describe how it is integrated into sprint planning and backlog refinement
→ Verification evidence: explain how it is generated during development, not assembled retrospectively
→ Definition of Done: state how IEC 62304 compliance requirements are part of it
"We use Agile" is not sufficient. FDA does not automatically understand what that means for your compliance activities. The connection must be made explicit in your SDP.
4. Roles and responsibilities
Name the roles responsible for development, verification and validation, risk management, and regulatory documentation. This does not require an org chart, but it should be specific enough that a reviewer can identify accountability for each compliance activity.
For small teams, one person may hold multiple roles. That is acceptable — but for Class C devices, the separation between development and independent verification activities should be clearly articulated.
5. Configuration management approach
Explain how code changes are tracked, how builds are controlled, and how you manage SOUP (Software of Unknown Provenance), meaning third-party libraries, open-source components, and commercial off-the-shelf software included in your device.
IEC 62304 Section 8 has specific SOUP management requirements that many teams underestimate. Your SDP should reference your SOUP inventory and describe how component risk is assessed both at adoption and when updates occur.
6. Verification and validation plan
Describe what you will test, at what level (unit, integration, system), and how pass/fail criteria will be defined. This section can reference a separate V&V plan, but the SDP should summarize your overall approach clearly.
For Class C devices, FDA expects full traceability between requirements, test cases, and risk controls. Your SDP should state how that traceability will be maintained throughout the project, not just at submission time.
7. Risk management integration
The SDP must explicitly reference your ISO 14971 risk management plan and describe how risk management connects to your development process. Risk management is not a separate workstream that runs alongside development, it must be woven into it.
Specifically: explain how risk controls identified in your risk analysis become software requirements, and how you verify that those controls are implemented and effective in the final product.
Common gaps FDA reviewers flag
These are the SDP issues that most reliably generate questions or hold letters from reviewers:
How to keep your SDP current throughout development
The SDP is a living document. Write it at the start of the project, update it as significant decisions change, and finalize it as part of your Design History File before submission.
FDA reviewers can often tell the difference between an SDP that guided development and one written retrospectively to describe what happened. The former is specific about decisions, timelines, and rationale. The latter tends to be generic and abstract, the document equivalent of describing a journey after you have already arrived.
In practice, this means:
→ Write the initial SDP before development begins — even a first draft is better than nothing.
→ Update it when your lifecycle approach changes significantly, your team structure changes, or your safety class is revised.
→ Maintain a version history. Changes to the SDP should be controlled under your configuration management process.
Not sure if your current SDP will hold up under FDA review? We offer a complimentary review for MedTech teams preparing for submission. Get in touch: [email protected]