FDA software validation services

What does FDA software validation produce?

A record that answers on its own whether the software was shown to do what it was specified to do. The FDA computer software assurance guidance defines its subject as "a risk-based approach for establishing and maintaining confidence that software is fit for its intended use", and names what that approach establishes: a validated state, in which the software is "in a state of control throughout its life cycle". A state persists between runs. A run does not.

The MDSAP Audit Approach, published by FDA, turns the same idea into an instruction for the person who will read your file. Task 15 tells the auditor to verify that the software is validated for its intended use, and expects that to have been done "according to an established protocol". Four records follow from that sentence: a software requirements document describing the intended uses and user needs, a validation protocol describing the activities that demonstrate those requirements can be met, records of the results of the activities in that protocol, and records that software changes were controlled. Off-the-shelf software gets no exemption. Where reviewing the code is neither practical nor necessary, the same document still expects validation against a protocol with predetermined acceptance criteria.

A team can test carefully and hold none of that. Testing tells you what happened on the day. The specification the software was measured against, the acceptance criterion that existed before the run, the build the run executed on and the retained result are what let a reader two years later decide whether what happened was correct. Where the acceptance criterion is written after the results are in, it can only agree with them.

Which FDA document governs your software?

Two documents are in play and they do not overlap, which is where the expensive mistake gets made. The computer software assurance guidance covers computers and automated data processing systems used as part of production or the quality management system for medical devices. Section III then states that it "does not provide recommendations for the design and development verification or validation requirements for device software functions, which are software functions that meet the definition of a device under section 201(h) of the FD&C Act". A footnote carries the same boundary through hosting: cloud computing used in production or the quality management system is inside the scope, cloud computing used as part of device software functions is outside it.

The software you sell, where it meets that definition, answers to a different route entirely. Design and development verification and validation for the product itself runs under medical device software testing. What the guidance does and does not say, including the testing taxonomy it borrows from IEC/IEEE/ISO 29119-1, is set out at FDA computer software assurance.

The guidance itself is final, issued 3 February 2026 under docket FDA-2022-D-0795, and nonbinding. Every page of it is headed "Contains Nonbinding Recommendations".

Which of your systems does this reach?

The ones whose failure would show up in the product or in the quality record. The guidance sorts software by how it is used, and only two of the three categories carry the validation requirement at all: software used directly as part of production or the quality management system, and software used to support it. Software for general business processes, or for infrastructure not specific to production or the quality management system, falls outside. The examples given there are email, accounting, networking, user authentication, and backup and restore.

The sort is done per feature, function or operation rather than per system, because one platform can hold several intended uses at once. The guidance says the framework can be applied to automation tools such as bots and automatic workflows, to data analytic tools, to artificial intelligence and machine learning tools, and to cloud computing, wherever those are used as part of production or the quality management system. In a first pass, the items that turn up are rarely the ones on the software asset register: a spreadsheet holding a custom formula that a release decision depends on, a workflow rule that routes a nonconformance, a script that moves results between two systems nobody owns.

Appendix A's worked examples stop short of a production controller, and the guidance page sets out what that omission leaves uncovered. The consequence for an inventory is narrower: an item unlike any worked example needs its risk argument built from the criteria rather than adapted from a model, and those are the items least likely to have been on the register.

If your product is software as a medical device, its own test evidence sits in the regulatory file rather than in the quality system file, and the two are assembled for different readers.

Which requirements does this close?

The enforceable requirement is in 21 CFR Part 820, and the guidance is FDA's recommended way of meeting it. The Quality Management System Regulation, issued as a final rule on 2 February 2024, took effect on 2 February 2026. It removed the majority of the previous requirements in Part 820, including 21 CFR 820.70, and incorporates the 2016 edition of ISO 13485 by reference. The validation obligation now reads as ISO 13485:2016 clause 4.1.6, clause 7.5.6 and clause 7.6. What the standard asks and how an auditor reads it is at ISO 13485 software validation.

FDA validation obligations for software, from ISO 13485:2016 via Part 820, 21 CFR 11.10 and computer software assurance guidance, with the evidence filed for each.

What binds	Where it comes from	What the work puts in the file
Validate software for its intended use	ISO 13485:2016 subclauses 4.1.6, 7.5.6 and 7.6, incorporated into 21 CFR Part 820	Requirements, protocol, executed results and change records, per item
Accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records	21 CFR 11.10(a), where the records are electronic	Results against each of the four objectives, including the negative cases
Secure, computer-generated, time-stamped audit trails that do not obscure the previous value	21 CFR 11.10(e)	Audit trail evidence, with its retention setting compared against the retention period of the subject records
A risk-based approach and a proportionate record	FDA computer software assurance guidance, recommended rather than required	The intended use, the risk determination and the assurance record for each item

FDA states that it does not require or issue ISO 13485 certificates of conformance, and that holding one does not exempt a manufacturer from inspection. Nobody outside your own organisation can carry the regulatory position for a device you place on the market. What an outside team can build is the evidence you present when someone asks, in the form the reader expects to receive it.

What do you receive?

You receive the artefacts listed below, one set per item in the inventory, sequenced the way an auditor works through them. The guidance recommends the same record elements for every assurance activity, whichever method produced it: the intended use of the feature, function or operation, the result of the risk-based analysis, and the documentation of the assurance activities. That documentation carries a description of the testing, the issues found, a conclusion declaring the software acceptable for its intended use, the person who performed the work and the date, and review and approval where that applies.

What you do not receive is a binder of screenshots. FDA recommends incorporating digital records such as system logs and audit trails "as opposed to paper documentation, screenshots, or duplicating results already digitally retained by the software". Where the evidence already exists inside the system, the work is to establish that it can be produced and read, rather than to photograph it. How the protocols and matrices are structured so that a change does not orphan them is covered at validation documentation.

What has to be true of a record for it to stand as evidence?

It has to be attributable to a person, retrievable through its whole retention period, copyable in a form the agency can read, and unable to hide what it used to say. section 11.10(a) names four objectives for validation: accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records. The fourth objective is the one a functional suite never arrives at, because answering it means producing an altered or invalid record and showing the system catch it, which needs somebody able to corrupt a record in a controlled environment on purpose.

section 11.10(e) then sets four separate obligations on the audit trail inside one sentence. The trail has to be secure, computer-generated and time-stamped. It has to record the date and time of operator entries and actions that create, modify or delete records, independently of the operator. Changes must not obscure previously recorded information. The trail has to be retained at least as long as the subject records and be available for agency review and copying. The retention obligation is the one that reaches outside the application, because the trail's own retention is normally configured by whoever sized the database and the record retention period is set by somebody else entirely. The evidence each step of that test has to leave behind is covered at audit trail testing.

Two questions decide scope before any of it is tested. A record falls under Part 11 when some other requirement already obliges you to keep it and you keep it electronically, and the practical test the guidance offers is whether the record would be necessary as evidence to document required validation. A system is closed or open according to who controls access to it, under the definitions at section 11.3(b)(4) and section 11.3(b)(9), so a hosted system is not automatically an open one. The full control set is at 21 CFR Part 11 validation testing.

How does this fit a team that ships continuously?

By deciding what a change reopens before the change ships. The validated state carries a date, and every release after that date is either assessed or a gap. Two things keep the cost of that assessment down.

The first is what you are allowed to lean on. The guidance names controls a manufacturer may leverage instead of repeating: existing production controls and fully verified processes, purchasing controls for selecting and monitoring vendors together with the vendor's own development practices and validation work, monitoring data the software itself collects after implementation, and life cycle tooling such as anomaly tracking and requirement traceability. For some lower risk items it states that the vendor assessment may be all the assurance needed. The options it names for that assessment are an onsite audit where feasible, review of accreditations and certifications such as Service Organization Controls reports, review of the vendor's development, quality assurance and cybersecurity documentation, and review of data integrity capabilities including record retention, encryption in transit and at rest, and access controls.

The second is change reporting, which is a timing question. Where the device has an approved PMA or HDE, a change to the software behind production or the quality system goes down one of two routes, a 30-day notice or the annual report, and the fork is whether the change may result in a quality problem foreseeably compromising safety. Which of the two a change is has to be decided on the day it ships and recorded then, because a team releasing weekly cannot reconstruct the reasoning for a year of changes when the annual report falls due.

Some of the systems in scope hold protected health information, and a quality record can carry it too. What happens to protected health information in a test environment is a separate question, and it decides the shape of the environment before any of the work above can start.

Where does a validation file fail an inspection?

• The protocol and the report are one document, written after the run, so no acceptance criterion in the file predates a result.
• The requirements document describes what the system does and never states what it is used for, so the intended use that sets the whole scope is absent.
• The evidence is a passing screenshot, and nothing on file names the build or the configuration the run executed against.
• The package is complete for the version that went live and silent on every change since, which puts an end date on the validated state.
• The audit trail holding the evidence rotates on a schedule shorter than the retention period of the records it covers, against an obligation written into section 11.10(e).
• The record names no individual and carries no date, both of which the guidance recommends for every assurance activity, unscripted ones included.
• Device software functions sit inside the same validation programme as the quality system software, under a guidance whose Section III excludes them.
• A spreadsheet with a custom formula that a release decision depends on was never in the inventory, because the inventory was built from installed software.

Every quotation, subclause number and date above was read from its source on 2 September 2026: the FDA guidance Computer Software Assurance for Production and Quality Management System Software issued 3 February 2026, the codified text of 21 CFR Part 11, and the MDSAP Audit Approach. The guidance is nonbinding, and the requirement it recommends a method for is the one incorporated into 21 CFR Part 820.