A practical breakdown of every document the FDA expects for a software-based 510(k) — and the common mistakes that get submissions kicked back.
If you're preparing a 510(k) submission for a software-based medical device, the documentation requirements can feel overwhelming. This guide cuts through the noise and tells you exactly what you need, in plain language.
Software engineers, regulatory affairs professionals, and startup founders preparing their first 510(k) submission for a Class II software-based medical device. Assumes basic familiarity with FDA processes.
A 510(k) is an FDA premarket submission that demonstrates your device is substantially equivalent to a legally marketed predicate device. You need one for most Class II medical devices before you can sell them in the US.
For software-based devices, the FDA increasingly scrutinises the software documentation package. A weak software submission is one of the most common reasons for an "Additional Information" (AI) letter — which can delay your clearance by 3–6 months.
The FDA evaluates software in 510(k) submissions against two primary references:
Common mistake: Treating the software documentation as an afterthought. FDA reviewers are increasingly technical — a shallow SRS or a traceability matrix with gaps will generate an AI letter. Budget time for this.
For a typical Class II software device, you need these documents in your Design History File:
The SRS defines what your software does — every functional and non-functional requirement. This is the foundation everything else traces back to.
What FDA reviewers look for:
The IEC 62304 standard classifies software into safety classes A, B, and C. Class C (failure could cause death or serious injury) requires the most rigorous documentation — full traceability from requirements to architecture to code to tests.
How your software implements the requirements. Architecture diagrams, module decomposition, data flow. This is your "design output" document in the DHF language.
The test cases that verify each requirement. Each test case must link back to one or more SRS requirements — this is the heart of your traceability matrix.
Common structure:
The formal document that records test execution — who ran the tests, when, on which version of the software, and the actual results. This is your "testing was done" evidence for FDA reviewers.
A table (or document) showing that every SRS requirement has at least one test case, and every test case links back to an SRS requirement. No orphaned requirements, no untested requirements.
FDA guidance explicitly states: "The traceability analysis should provide reasonable assurance that all identified risks have been adequately addressed through design." An incomplete matrix is a red flag.
A record of all known software defects, their severity classification, and their resolution. FDA expects you to know your bugs — don't hide them. Classify each by severity and document your rationale for shipping with any open defects.
Version control log with release notes for each version. Shows the FDA your development process was controlled.
Traceability is the thread that ties everything together. The FDA expects a complete chain:
| Level | Document | Links to |
|---|---|---|
| User Needs | User Needs document | ↓ SRS requirements |
| Requirements | SRS | ↓ Design outputs, test cases |
| Design | SDS | ↓ Code modules, test cases |
| Verification | SSTC | ↑ SRS requirements |
| Validation | SSTP | ↑ SSTC test cases |
Every gap in this chain is a potential AI letter. FDA reviewers will look for requirements with no test cases and test cases with no requirements.
IEC 62304 software safety classes determine how deep your documentation needs to go:
| Class | Definition | Documentation requirement |
|---|---|---|
| Class A | No injury or damage to health possible | Basic — SRS, test records |
| Class B | Non-serious injury possible | Full — SRS, SDS, SSTC, SSTP, traceability |
| Class C | Death or serious injury possible | Full + additional rigor on hazard analysis, FMEA, formal design reviews |
Most software-based Class II devices fall into Class B or C. If your software controls treatment delivery, sensor data interpretation with clinical impact, or safety-critical alarms — you're Class C.
For a typical Class B software device at an experienced startup: 8–16 weeks for a first-time submission with a good regulatory consultant. The longest part is usually writing the SRS — not because it's hard, but because it forces engineering decisions that weren't previously captured in writing.
With purpose-built tooling (like PreQMS), the structural and formatting work drops significantly. The intellectual work of defining good requirements doesn't — that's on your team.
"The FDA doesn't want perfect documentation. They want documentation that demonstrates controlled development and traceable decisions. There's a difference." — Common advice from experienced regulatory consultants
SRS, SSTC, SSTP, and traceability matrix — structured, linked, and export-ready for submission.
Book a 30-minute demo