510(k) Submission Checklist for Medical Device Software

Every founder preparing a 510(k) eventually finds a checklist online. Some are six items. Some are sixty. Most are structured around device type, not software content, which means they miss the things that actually cause software-heavy submissions to stall.

This is not that checklist.

What follows is a decision-point framework for the software documentation package inside a 510(k) submission. It’s structured around the choices that determine whether your submission holds up under FDA review, not just the documents you need to produce, but the questions you need to have answered before you produce them.

It’s also a map of the content we’ve published on each of these areas. Where a topic has a deeper treatment, I’ve linked to it.

A 510(k) submission is not a document. It’s an argument. These are the decision points that determine whether the argument is coherent.

Before you open a template: four decisions that shape everything

Most submission problems are set in motion before a single document is written. These four decisions should be made, and documented, before development starts. If you’re reading this mid-development, make them now and assess what’s already been affected.

Decision 1: Your predicate device

A 510(k) submission argues that your device is substantially equivalent to a legally marketed predicate. Your predicate isn’t just a regulatory reference, it defines your feature ceiling, anchors your intended use, constrains your testing benchmark, and shapes the risk profile FDA will use to evaluate you.

Teams that choose predicates well treat it as a product strategy decision. They map the predicate’s cleared features against their intended architecture before finalizing the roadmap. Teams that choose poorly, or choose late, spend months either defending divergence or redesigning to fit.

The predicate decision should be made before architecture is finalized. Not before submission. Before development.

☐ Predicate device identified and documented

FDA 510(k) database search completed. Intended use comparison documented. Known differences identified and assessed for substantial equivalence.

☐ Feature set validated against predicate

Any features that diverge from the predicate have a documented rationale. Divergence that affects intended use has been flagged for regulatory strategy review.

Decision 2: Software safety class

IEC 62304 assigns a safety class to each software item based on the severity of harm that could result from a software failure: Class A (no injury possible), Class B (non-serious injury), Class C (serious injury or death). The class determines your documentation depth, testing rigor, and FDA scrutiny level.

The most common mistake: assuming Class A or B, building with that rigor, then discovering mid-submission that Class C applies. The remediation cost is substantial. The time cost is worse.

Safety class is determined by hazard analysis, not by intuition. Conduct the analysis. Document the reasoning. Apply the result.

☐ Preliminary hazard analysis completed

Worst-case failure modes identified for each software function. Harm severity assessed. Safety class assigned per IEC 62304 with documented rationale.

☐ Safety class applied at the software item level, not the system level

If the system contains components of different classes, each item is classified individually. Proportionate rigor applied per item.

Deeper read: IEC 62304 Software Safety Classes Explained — March LinkedIn carousel.

Decision 3: Regulatory pathway and submission type

510(k) is the most common pathway for software-driven medical devices, but not the only one. De Novo is appropriate when no predicate exists for a novel device. Some SaMD products may qualify for the FDA’s AI/ML-specific frameworks. The pathway affects the structure of the submission, the level of clinical evidence required, and the review timeline.

If you’re on a 510(k) pathway, also determine whether your device qualifies as a Breakthrough Device, which affects review priority.

☐ Regulatory pathway confirmed

510(k) vs. De Novo vs. Other pathway decisions documented with rationale. If 510(k), substantial equivalence argument outlined.

☐ Device classification confirmed

21 CFR product code and classification verified. Special controls applicable to your device type identified.

Decision 4: Whether your device is a cyber device under Section 524B

FDA’s 2023 cybersecurity guidance introduced mandatory requirements for “cyber devices” — any device with software that can connect to the internet, a network, or another device. If your device qualifies, cybersecurity documentation is not optional and not a late-stage addition. It affects architecture, testing, and submission content.

☐ Cyber device determination made and documented

If the device connects to any network or external system, cybersecurity requirements under Section 524B apply. Determination documented.

☐ Cybersecurity architecture and SBOM approach confirmed

If a cyber device: threat modeling initiated, SBOM toolchain selected, patch management process defined. See SBOM guide for detail.

Deeper read: The Guide to FDA’s SBOM Requirements for Medical Devices — March blog.

The core software documentation package

These are the documents FDA expects to see in a 510(k) submission for a device with significant software content. The FDA’s 2023 guidance “Content of Premarket Submissions for Device Software Functions” is the current authoritative reference for what’s required and at what level of detail.

The level of documentation required scales with software safety class. Class A devices have a much lighter documentation burden than Class C. What follows covers the full picture, apply proportionately.

Software description and level of concern

A narrative description of what the software does, how it integrates with the device, and its role in device function. FDA historically used a “level of concern” framework (minor / moderate / major) to tier documentation requirements. The 2023 guidance replaced this with a device software function categorization, but the underlying logic, proportionate documentation to risk, remains.

☐ Software description documented

Intended use, software functions, operating environment, hardware dependencies. Written for an FDA reviewer who understands software but not your specific device.

☐ Device software function categorization completed

Functions categorized per FDA 2023 guidance. Documentation level justified.

IEC 62304 development lifecycle documentation

This is the core of the software submission package. FDA expects evidence that the software was developed according to IEC 62304 — not a declaration that it was, but artifacts that demonstrate it. The specific artifacts required depend on safety class.

☐ Software Development Plan (SDP)

Defines lifecycle model, deliverables, safety class rationale, links to risk management and configuration management. Must reflect how development actually ran — not just the original plan.

☐ Software Requirements Specification (SRS)

Documented before development. Requirements carry unique IDs. Testable. Traceable to system requirements.

☐ Software architecture design document

Software items identified. Safety class per item. Interfaces defined. Architectural rationale documented, particularly for safety-relevant decisions.

☐ Software detailed design (Class B and C)

Sufficient detail that implementation and verification don’t require inventing requirements. Interfaces, data flows, error handling, state transitions.

☐ Unit verification evidence (Class B and C)

Test protocols and results. Pass/fail records. Coverage appropriate to safety class. Traceability from test to requirement.

☐ Integration test protocols and results

Pre-approved protocols. Results recorded against protocol. Anomalies documented and resolved.

☐ System test protocols and results

Pre-approved protocols. Tested against the SRS. Anomalies recorded, evaluated, and formally closed or accepted with rationale.

☐ Software release record

Release criteria met. Known anomalies listed with risk-evaluated status. Configuration baseline recorded.

Deeper reads: IEC 62304 Clause 5 in practice (this month, Martin’s blog) | IEC 62304 Clause 6 in practice (June, Martin’s blog).

Traceability matrix

A single artifact that links requirements to design, code, and test evidence. This is one of the most scrutinized documents in a software-heavy submission. FDA reviewers pull threads — they pick a requirement and follow the chain to see if evidence exists at every link.

A traceability matrix built backward from test runs is detectable and erodes confidence in the submission. It should be a living document maintained throughout development, not assembled pre-submission.

☐ Traceability matrix complete and forward-built

Every safety-critical requirement traces to: design document, code reference, unit test, integration test (where applicable), system test. Risk controls traceable to hazards.

ISO 14971 risk management file

Risk management is not a submission artifact. It’s an ongoing process that runs throughout development and continues post-market. The risk management file submitted with the 510(k) is a snapshot of a living document, not a final report.

FDA expects to see: a hazard analysis covering all reasonably foreseeable failure modes, risk controls for each hazard above acceptable risk, verification that risk controls are implemented and effective, and a residual risk evaluation. The file should be traceable to the SRS — risk controls become requirements.

☐ Hazard analysis complete

All foreseeable failure modes identified. Harm severity and probability assessed. Risk level evaluated against defined criteria.

☐ Risk controls defined and implemented

Each unacceptable risk has a documented control. Controls implemented in design or verified through testing. Residual risk evaluated and accepted.

☐ Risk management report

Summary of the risk management process, residual risks, and overall residual risk conclusion. Signed and dated.

☐ Risk-benefit analysis (if residual risks remain)

Where residual risk is not negligible, a risk-benefit analysis documenting why benefits outweigh risks.

Cybersecurity documentation (cyber devices)

If your device qualifies as a cyber device under Section 524B, these items are mandatory. They cannot be deferred to post-market.

☐ Cybersecurity management plan

Covers the device’s security architecture, threat modeling, vulnerability management, and post-market monitoring approach.

☐ Software Bill of Materials (SBOM)

Machine-readable inventory of all software components, including third-party libraries and open-source dependencies. Generated from your build process, not manually compiled.

☐ Vulnerability assessment

Known vulnerabilities in SBOM components assessed. Unmitigated vulnerabilities documented with risk rationale.

☐ Patch management process documented

How security patches will be evaluated, tested, and deployed. Links to Clause 6 maintenance process.

Deeper read: The Guide to FDA’s SBOM Requirements for Medical Devices — March blog.

Post-market obligations: what the submission commits you to

This is the section most founders underweight when preparing a submission. A 510(k) clearance isn’t an endpoint — it’s an ongoing commitment. The submission establishes obligations that follow the device into the field. FDA’s reviewers read the submission knowing this. Your post-market processes need to be credible before you submit, not planned after clearance.

Software maintenance process (IEC 62304 Clause 6)

Clause 6 governs how your software is maintained after release. Every bug report, security patch, and software change enters a regulated process. The Clause 6 documentation in your submission needs to describe a process that will actually run, not a theoretical framework that nobody will follow.

☐ Software maintenance plan documented

Problem reporting process defined. Modification analysis process defined. Re-entry criteria for the development lifecycle documented. Responsibility assigned.

☐ 510(k) change threshold documented

Written criteria for when a software change requires a new FDA submission. Based on FDA’s “Deciding When to Submit a 510(k) for a Software Change” guidance.

Deeper read: IEC 62304 Clause 6 in practice — June blog (Martin).

Post-market surveillance plan

FDA expects a plan for monitoring device performance in the field. For software-heavy devices, this includes monitoring for software anomalies, adverse events, and cybersecurity vulnerabilities. The plan should connect to your risk management process, post-market data feeds back into the risk file.

☐ Post-market surveillance plan documented

Surveillance methods defined. Data sources identified (complaints, MDRs, literature, registries where applicable). Review frequency and escalation criteria defined.

☐ MDR reporting threshold documented

Criteria for when a software malfunction constitutes a reportable adverse event. Process for timely MDR filing if threshold is crossed.

The gaps that cause deficiency letters

An FDA deficiency letter means the review clock stops and you answer questions before the review continues. The most common software-related deficiencies we see follow a pattern:

Traceability gaps: requirements exist, tests exist, but the chain between them has missing links. Often caused by requirements written after development or tests added post-submission.
SRS written as a product description: describes the software as built, not the specification it was built against. Detectable because requirements don’t have unique IDs or aren’t testable.
Safety class applied to the system: the whole device is called Class B, but no item-level classification exists. FDA expects to see the decomposition.
Risk controls that aren’t in the SRS: risk management and software requirements are separate silos. Risk controls need to trace to requirements. If they don’t, the risk file and the software package are incoherent.
Cybersecurity documentation deferred: “we’ll address this post-clearance” is not an acceptable position for cyber devices under 524B. FDA will flag it.
Post-market processes that aren’t credible: a maintenance plan that no engineer has read, an MDR threshold that nobody knows, a surveillance process that exists only in the submission. Reviewers are experienced at identifying plans that won’t survive contact with reality.

FDA isn’t just reviewing your documents. They’re evaluating whether your team can be trusted to maintain a safe device in the field. The submission is evidence for that judgment.

How to use this checklist

If you’re in pre-development: use the four decisions in the first section as a pre-sprint gate. Don’t start building until those decisions are made and documented. Everything else is easier when those are right.

If you’re mid-development: run this checklist as a gap assessment. The items you’re missing are the items that will cost you time at submission. Better to find them now.

If you’re pre-submission: the checklist is your submission readiness review. Any item you can’t check is either a deficiency waiting to happen or something you need to make a documented decision about before you file.

The teams that move fastest through 510(k) review don’t move fastest because they’re lucky. They move fastest because they built the submission package as they went, and when they got to the end, there was nothing left to reconstruct.