General Principles of Software Validation; Final Guidance for Industry and FDA Staff

Aug. 23, 2013
Document issued on: January 11, 2002
This document supersedes the draft document, "General Principles of Software Validation, Version 1.1, dated June 9, 1997
This guidance outlines general validation principles that the Food and Drug Administration (FDA)considers to be applicable to the validation of medical device software or the validation of software used to design, develop, or manufacture medical devices. This final guidance document, Version 2.0, supersedes the draft document, General Principles of Software Validation, Version 1.1, dated June 9, 1997.


This guidance describes how certain provisions of the medical device Quality System regulation apply to software and the agency’s current approach to evaluating a software validation system. For example, this document lists elements that are acceptable to the FDA for the validation of software; however, it does not list all of the activities and tasks that must, in all instances, be used to comply with the law.


The scope of this guidance is somewhat broader than the scope of validation in the strictest definition of that term. Planning, verification, testing, traceability, configuration management, and many other aspects of good software engineering discussed in this guidance are important activities that together help to support a final conclusion that software is validated.


This guidance recommends an integration of software life cycle management and risk management activities. Based on the intended use and the safety risk associated with the software to be developed, the software developer should determine the specific approach, the combination of techniques to be used, and the level of effort to be applied. While this guidance does not recommend any specific life cycle model or any specific technique or method, it does recommend that software validation and verification activities be conducted throughout the entire software life cycle.


Where the software is developed by someone other than the device manufacturer (e.g., off-the-shelf software) the software developer may not be directly responsible for compliance with FDA regulations. In that case, the party with regulatory responsibility (i.e., the device manufacturer) needs to assess the adequacy of the off-the-shelf software developer’s activities and determine what additional efforts are needed to establish that the software is validated for the device manufacturer’s intended use.