FDA 510(k) software documentation requirements

What does a 510(k) have to contain, and how much of it is testing?

section 807.87 sets out what a premarket notification contains, and the list divides cleanly into paperwork and evidence. The paperwork is the trade and classification names of the device, the establishment registration number where one applies, the device class under section 513 of the FD&C Act or a statement that the device is unclassified, a statement of the actions taken to comply with any applicable section 514 performance standard, "proposed labels, labeling, and advertisements sufficient to describe the device", a 510(k) summary or a 510(k) statement, and the financial certification or disclosure statements under 21 CFR Part 54.

Two items are evidence, and they are the two nobody can produce in the filing month. The section requires a statement comparing the device to a comparable marketed device together with the data supporting that comparison, and supporting safety and effectiveness data for any significant modification. It also provides for any additional information FDA requests, which is the line that turns a thin file into a second round of work on somebody else's clock.

Each item a 510(k) has to contain has an owner inside the company and a price for arriving late, and the two do not track each other: the items that cost an hour belong to regulatory, and the items that cost a test cycle belong to engineering.

Contents 21 CFR 807.87 requires in a 510(k), set against who owns each item and what its absence costs.

What 807.87 asks for	Who owns it	What its absence costs
Device names, registration number, class, section 514 statement	Regulatory	An hour, if the regulatory file is current
Proposed labels, labeling and advertisements	Regulatory and marketing, against the indications	A revision cycle, and a labeling change can reopen the comparison
The comparison with a comparable marketed device, and the data behind it	Engineering, from executed test runs	A test cycle per unsupported claim, run after the file was meant to be closed
Supporting data for a significant modification	Engineering, from executed test runs	The same, plus the argument about whether the modification was significant
Truthfulness certification, 510(k) summary, Part 54 disclosures	An officer of the company, by signature	Nothing to produce, and everything to check before signing

The section requires a certification that the information submitted is truthful and accurate, and an officer of the company signs it over material that other people assembled. Every unsupported line in the comparison table sits under that signature.

How much software documentation will you have to file?

That is decided before the engineering starts, by the documentation level. FDA scopes device software documentation with a Basic Documentation Level and an Enhanced Documentation Level, and the level your product falls into sets the size of the package and the size of the bill.

The definitions to work from are in FDA's own guidance, "Content of Premarket Submissions for Device Software Functions", issue date June 2023, docket FDA-2021-D-0775, final, developed jointly by CDER, CBER, CDRH and the Office of the Commissioner. Table 1 of that guidance names two differences a test team feels. At the Enhanced level the submission carries the software design specification, traced to the requirements, and unit and integration level test protocols and reports on top of the system level ones. At the Basic level the design specification stays in the design history file. The first element the guidance asks for is a statement of the level with its rationale, so have the person who owns your regulatory file write down which level applies and why.

Section V of the guidance sets the criterion that triggers the higher level: Enhanced Documentation should be provided where a failure or flaw of any device software function could present a hazardous situation with a probable risk of death or serious injury, assessed before risk control measures are applied. Basic applies where Enhanced does not.

The words "before risk control measures are applied" are the ones that cost money when they are missed, because a software safety class is assigned on the opposite basis. IEC 62304 Edition 1.1 permits a software system initially classified B or C to be given a new classification once risk control measures external to the software system are implemented, including a revision of the system architecture containing it. A hardware interlock that moves an item down to class B does not move the documentation level. A company that lets one letter govern both decisions scopes its package against the wrong question and discovers it after the work is done. The classification decision itself, and the clause set each class pulls in, is worked through on IEC 62304 software testing requirements.

What happens when a reviewer asks a question the file cannot answer?

The answer costs a test cycle, and the cycle runs after the date you filed. The reason is in what a test record is required to contain. IEC 62304 Edition 1.1 fixes that list at 5.7.5, where the stated purpose of the record contents is to support the repeatability of tests, and the subclause binds at classes A, B and C.

A package assembled from a tracker export carries two of those seven items: the reference to the test case procedure and the pass or fail result. The software version tested, the hardware and software test configuration, the test tools, the date and the person who executed the test exist only in a record made on the day. Those five are what a re-run buys back, and the re-run is scheduled after the month you had set aside for filing.

The same exposure runs across the whole file through traceability. clause 5.7.4, EVALUATE SOFTWARE SYSTEM testing asks the manufacturer to verify that the traceability between software requirements and tests or other verification is recorded, and it binds at every class. FDA recognises this text: recognition number 13-79 on list 051, entered on 14 January 2019, extent of recognition "Complete standard", for IEC 62304 Edition 1.1 2015-06. An unrecorded trace is therefore built while the submission is in front of a reviewer, and every requirement it surfaces with no test behind it costs one run on that clock. How the trace is built, and what it is supposed to expose before anyone files, is validation documentation and requirements traceability.

What does the predicate comparison commit you to?

Two findings, and your data has to support both of them. Section 513(i) of the FD&C Act, 21 U.S.C. 360c(i), defines substantial equivalence in two branches. The device must have the same intended use as the predicate. FDA must then find by order either that it has the same technological characteristics as the predicate, or that it has different technological characteristics while the submission contains information, including clinical or scientific data where that is deemed necessary, demonstrating that the device is as safe and effective as a legally marketed device and does not raise different questions of safety and effectiveness.

Software usually puts a company in the second branch. Every difference you declare against the predicate is a claim you have undertaken to support, and the support has to reach two separate findings: as safe and effective as the marketed device, and no different questions of safety and effectiveness. A performance number answers the first. The second is answered by showing which failure modes the difference introduces and what happens in each, which is a larger piece of work and is routinely left out of the estimate.

Is the design history file still a requirement?

The phrase is not in the current regulation, and a package citing it by its old clause number is citing text that is no longer there. In the 21 CFR Part 820 text carried at the eCFR issue date of 31 August 2026, Subpart B is headed "Supplemental Provisions" and its section range is printed as "820.20 to 820.30 [Reserved]", with 820.35 Control of records and 820.45 Device labeling and packaging controls following it. A search of that fetched content for "design history file" returns nothing.

What stands in its place is the quality management system regulation. section 820.1 now states that "Current good manufacturing practice (CGMP) requirements are set forth in this quality management system regulation (QMSR)", and section 820.7 incorporates two standards by reference: ISO 9000:2015(E) Clause 3, terms and definitions, and ISO 13485:2016(E). The part's source note reads 89 FR 7523 of 2 February 2024, with an amendment at 89 FR 82945 of 15 October 2024, and FDA's own page gives the rule an effective date of 2 February 2026 and says the agency began using the corresponding updated inspection process, compliance program 7382.850, on that date.

Which clause of ISO 13485:2016 now carries the design history file content was left open when the source record for this page was collected, and this page will not guess at a number. The direction is readable in the codified text: 820.35 Control of records opens "In addition to the requirements of Clause 4.2.5 in ISO 13485", then adds its own record requirements on top of it. The practical instruction for a management team is short. The records you were keeping still have to exist, the obligation now runs through an incorporated standard your quality lead has to hold a copy of, and nobody in your company should cite a clause number they have not read out of that copy. What the incorporated standard governs is set out on the ISO 13485 software validation page.

Which artefacts have to exist before the testing starts?

Three, and each of them makes the testing worthless if it arrives afterwards. None of the three can be added at the end, so a project that skips them buys a second round of the same testing.

The statute defines a cyber device at 21 U.S.C. 360n-2(c) as one that "includes software validated, installed, or authorized by the sponsor as a device or in a device", "has the ability to connect to the internet", and "contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats". A connected product meets all three limbs. The bill of materials is a build output and takes a day. The plan describes a process your company has to be running already, and a process cannot be backdated by anyone at any price. The testing that stands behind it is covered in cybersecurity testing under FDA section 524B.

One requirement sits outside the package and reaches it anyway. 21 CFR 11.2(b) permits electronic records to be submitted to the agency only where the requirements of the part are met and the document or parts of it have been identified in public docket No. 92S-0251 as a type of submission the agency accepts in electronic form. Which of the part's sections reach a given system is worked through on the 21 CFR Part 11 validation testing page.

What does a reviewer find in a package assembled at the end?

• The comparison declares a technological difference and the evidence section contains no result that addresses it, so the claim is carried by the reader's goodwill.
• The trace 5.7.4 asks for was never recorded, and building it during the review is what turns up the requirements nobody tested.
• The documentation level was inherited from the software safety class, and that class was assigned after external risk controls the level criterion does not count.
• Records carry a pass and a date, without the software version, the test configuration or the tools, which are three of the seven items 5.7.5 lists.
• The package cites 820.30(j) for the design history file, out of a template written before the quality management system regulation took effect on 2 February 2026.
• The software bill of materials was generated for the submission, and no postmarket vulnerability process exists behind the plan filed beside it.
• Anomalies are listed with no disposition, so nobody outside the team can tell which were assessed and which were only observed.

Sources for this page: the section contents of 21 CFR Part 807, 21 CFR Part 820 and the FD&C Act citations are read in the eCFR at the issue date of 31 August 2026, and the IEC 62304 subclauses in Edition 1.1. The documentation levels are read in the guidance issued on 14 June 2023, Section V and Table 1, on 10 September 2026. This page names no ISO 13485:2016 clause as the equivalent of the former design history file requirement.

What do we do on a 510(k) software package?

We start from the comparison and the level decision, because those two decide what counts as evidence and therefore what the work costs. The test plan is written against the declared differences one row at a time, and each run is recorded while it happens in the form 5.7.5 asks for, so the file answers a reviewer's question out of what is already in it. The frame around that work, which edition each record answers to and which of your two software files the submission reads, is set out under preparing software for an FDA submission, and the quality system side of it under FDA software validation.

Performance data for a submission is generated in an environment somebody has to specify, and the specification includes what data sits in it. We do not need production PHI to test. Environments run on synthetic and de-identified data. Where a test genuinely needs a real-world data shape, the route to it is agreed in writing before the environment exists. We sign a Business Associate Agreement before any engagement that touches PHI, and the answers we give before an engagement starts are published at how we work with protected health information.