Even if you've read IEC 62304 twice, front to back, before writing a line of production code, and think you understand every clause, there's still a good chance you'll walk out of your first internal audit with three findings. Few people think to turn "software development plan" into something more than a document sitting in a folder somewhere. Reading the standard and producing what an auditor expects to see are two different skills, and IEC 62304 rewards the second one almost exclusively.
If you want the clause-by-clause version, our walkthrough of how to apply IEC 62304 requirements covers that ground well. This piece picks up where that one leaves off: the actual artifacts a first-time software as a medical device (SaMD) team needs to produce, in roughly the order you will produce them, and why so many teams stall on the same three or four deliverables.
Why the standard trips up first-time SaMD teams
IEC 62304 is a process standard. It tells you what activities have to happen and what records have to exist, but it doesn't hand you a template for any of them. Hardware teams usually have some muscle memory here. Design history files, verification protocols, and change records have existed in medical device development for decades, and a mechanical or electrical engineer coming into a device company inherits that structure whether they know it or not.
Software teams building their first SaMD product rarely have that inheritance. Many come from consumer or enterprise software backgrounds, where continuous deployment and lightweight documentation are the norm and a compliance-grade audit trail simply is not. I hear a version of this conversation constantly on the podcast: an engineering lead who can ship a feature in a day but has no idea what a "software safety classification" is supposed to look like as a document, or who's supposed to sign it.
The gap isn't intelligence or effort, but translation. The standard describes outcomes; someone still has to decide what document satisfies each outcome, what it contains, and where it lives.
BONUS RESOURCE: Grab the 3-in-1 SaMD Gap Assessment Tool and confirm you have every document an auditor will ask for before you're asked for it.
Start with the software development plan
Every other deliverable in this guide traces back to the software development plan (SDP), so it goes first for a reason. The SDP is where you commit, in writing, to the process you're going to follow: which lifecycle model you're using, what activities happen at each stage, who reviews and approves what, and which standards and tools govern the work.
A common first-timer mistake is writing the SDP as a generic policy document that could apply to any project the company ever runs. Auditors want to see a plan specific enough to actually govern the software in front of them. That means naming your safety classification approach, your configuration management tool, your defect tracking system, and the specific verification activities planned for this release, not a boilerplate description of "our software development lifecycle."
The SDP also doesn't need to be finished before development starts. It needs to exist, and it needs to be updated as decisions change. A plan that was accurate in January but has not been touched since, while the team switched sprint cadences and testing tools in March, is a finding waiting to happen.
Classify before you build
Your software safety classification determines almost everything downstream: how much documentation you need, how rigorous your testing has to be, and how heavily each defect gets scrutinized. IEC 62304 defines three classes based on the severity of harm a software failure could cause, from Class A (no injury possible) to Class C (death or serious injury possible). Our guide to IEC 62304 software safety classes breaks down how each class is determined and what it changes about your process, so I won't repeat that here.
What I will say: classify early, and classify at the right level of granularity. Teams sometimes assign one blanket classification to an entire application when different software items within it carry genuinely different risk profiles. A dosing calculation and a settings screen inside the same app are not equally dangerous if they fail, and treating them identically either buries the calculation in insufficient rigor or buries the settings screen in unnecessary paperwork. Decompose your software into items first, then classify each one.
Build traceability into requirements and architecture
Most first-time teams lose the thread right here, because requirements and architecture live in engineering tools that were never built with an audit trail in mind. IEC 62304 expects a clear line from a user need, through a software requirement, into the architecture that implements it, and eventually into a test that verifies it. If that chain has a broken link anywhere, an auditor will find it.
The deliverables here are:
- Software requirements, each one specific enough to be objectively verified, not aspirational statements like "the software shall be user-friendly"
- Software architecture documentation showing how the system decomposes into components and how those components interact
- A traceability matrix or equivalent tool output linking requirements to architecture elements, and eventually to verification records
Jira tickets and GitHub issues can absolutely serve as your system of record for this, provided you're disciplined about linking practices and consistent ID schemes. What auditors care about is whether the trail exists and holds together, not which tool it lives in.
Verification records: the evidence auditors check
If there is one category of deliverable that determines how an audit goes, it's this one. Verification records are the proof that what you built actually does what the requirements said it would do, at the unit level, the integration level, and the full system level.
For each level, you need a protocol that states what's being tested and how, and a report that documents the actual results, including any deviations and how they were resolved. A passing test with no record of what was tested against which requirement is functionally the same as no test at all, from a compliance standpoint. Automated test suites are a legitimate source of verification evidence, but the output has to be captured, dated, and traceable back to the requirement it satisfies, not just a green checkmark in a CI pipeline that nobody archived.
Class B and Class C software carry additional expectations here, including more rigorous integration testing and, for Class C, independence between the person who wrote the code and the person who verifies it.
Problem resolution and configuration management
Two process areas get consistently under-built by first-time teams: problem resolution and configuration management.
Problem resolution is your defined process for identifying, evaluating, and resolving software problems, including a decision about whether a given defect requires a risk assessment before it ships. Most engineering teams already track bugs somewhere. What's usually missing is the documented evaluation step that connects a bug ticket to a risk decision, and a record of who made that call.
Configuration management is where your software of unknown provenance, or SOUP, gets documented: every third-party library, open-source component, and off-the-shelf module your software depends on, along with the version, the known anomalies, and your rationale for using it despite whatever limitations it has. A dependency scan is a starting point, not a finished deliverable. Each SOUP item needs a documented risk evaluation tied back to how your software actually uses it.
Where checklist-driven compliance breaks down
Even teams that build every deliverable on this list sometimes still struggle, because they treat the list as a one-time paperwork exercise instead of a living output of how the team actually works. The SDP gets written once and never revisited. The traceability matrix gets built for the submission and immediately falls out of date the next sprint. Verification records pile up in a shared drive that nobody can search when an auditor asks a specific question 18 months later.
BONUS RESOURCE: Grab the 3-in-1 SaMD Gap Assessment Tool and build a record structure your team will actually maintain past the first release.
The teams that hold up well under audit are the ones where these deliverables are a byproduct of normal development work, not a separate compliance project running in parallel to it.
Build compliance into the way your team already works
The good news is that most of the raw material for these deliverables already exists somewhere in your engineering tools: requirements in Jira, code changes in GitHub, test runs in CI. Compliance inside your dev tools: the SaMD guide goes deeper on how to structure that connection so the traceability auditors want is a natural output of your existing sprint work, not a translation project someone does the week before a submission.
The common pattern: the standard feels abstract right up until someone hands you the list of documents you're actually expected to produce, and then it becomes a project plan instead of a reading assignment. Start with the SDP, classify honestly, and build your traceability while the work is fresh instead of reconstructing it later.
Keep reading
If you are building out your IEC 62304 compliance process, these related guides go deeper on the specific components:
- How to apply IEC 62304 requirements for medical device software
- IEC 62304 software safety classes: what they are and how to apply them
- IEC 62304 and the software DHF: design controls that don't slow engineers down
- SaMD quality ops: why Jira and GitHub belong inside your QMS
- What auditors actually look for in software documentation
- Software risk management under ISO 14971
If you're standing up a quality system for the first time and don't want to build a compliance program before you've even validated the device, see how a system built specifically for early-stage SaMD teams keeps that traceability connected from day one.
BONUS RESOURCE:
3-in-1 SaMD Gap Assessment Tool
3-in-1 SaMD Gap Assessment Tool
