Don't know where to start? Watch our free starter videos and save lots of time and consultant fees

Templates ISO 13485 Templates

Updated June 9, 2022

Template: Software Validation Form

Sven Piechottka

Template Download

This is a free template, provided by OpenRegulatory.

If you are a user of Formwork, our eQMS software, choose "QMS" on the top menu and "OpenRegulatory Templates" on the left menu, and then open the relevant folder to find this template ready to load into Formwork.

If, for some mysterious reason, you're using a different QMS Software, you can also simply download this template - specifically, as Word (.docx), PDF, Google Docs or Markdown file. Scroll down for a preview!

The template license applies (don't remove the copyright at the bottom).

Download as Word File


Download as PDF


Copy-paste to Google Docs


Download as Markdown


Tired of copy-pasting? If you want to save time and edit these templates directly, you can use Formwork, our eQMS software. And if you're looking for step-by-step instructions for filling them out, check out our Wizard :)

Don't Miss Updates to This Template

Subscribe to our newsletter and we'll keep you posted on which templates we've changed.

Questions? Still Lost in Regulation?

Good news! Our goal is to provide lots of stuff for free, but we also offer consulting if you need a more hands-on approach. We get stuff done really fast. Have a look!

Related Documents

The following templates are Documents or SOPs related to this template. That means that they mention this template somewhere and (most likely) contain instructions on how and when to fill it out.

Template preview

<Software Title> - Software Validation Form

1. Information about the Software

Name <Name>
Version <x.x.x>
Location <url>
Processes <processes in which this tool is used>

2. Intended Use and Use Context

Describe intended use and usage context (e.g. automation, testing, control, altering). Include technical and usage requirements that the system shall fulfill.

3. Quality Relevance

Rate these aspects with yes (y) or no (n). If any of these aspects are rated as yes, the system is quality relevant and should be validated.

Criterion Y/N
Is the system used in one or more processes that steer the QMS?  
Could the conformity of the organization’s medical devices be affected if the system does not work according to its specifications?  
Could risks arise for patients, users, third parties or the organization if the system does not work according to its specifications?  
Does the software generate or manage data / records that are relevant to the QMS or medical device approval by authorities?  
Is the software used to generate electronic signatures on documents or records required by the QMS and/or state authorities?  

4. General Assessment

4.1 Software Category

4.2 Risk Assessment

List of Risks:

List of Risk Mitigation Measures (if necessary):

4.3 Criticality and Review Schedule

Refer to section 10 for descriptions of the criticality classifications. If a software is not highly critical and widely adopted / commonly used, it can be continuously re-validated during use.

5. Validation Plan

5.1 Participants

Role Name Task(s)

5.2 Test Environment

5.3 Testing Procedure

6. Validation Report and Requirements

6.1 Acceptance Criteria

The software is approved for use if it is validated successfully and works as expected.

6.2 Validation of Usage Requirements

ID Expected Result Pass?
U1 e.g. “A radiologist can log in with their email and password.” “Login with correct email and password grants access to the annotation tool.” yes

6.3 Validation of Technical Requirements

ID Expected Result Pass?
T1 e.g. “Execute correctly in the specified runtime (Google Chrome).” “The application runs correctly in Google Chrome.” yes

6.4 Summary of Validation

Type Total Pass Fail
Usage Requirements 1 1 0
Technical Requirements 1 1 0

6.5 Conclusion

Approving the software for use is recommended due to the acceptance criteria being fulfilled completely.

7. Proof of Validation

You can optionally insert screenshots for proof of validation. Strictly speaking, this is not a hard requirement by the standards but it’s nice to show when you’re being audited.

U1 <insert screenshot>
T1 <insert screenshot>

8. Approval and Release

Date of Approval Name of Approver
<date> <name>

9. History

Date Name Activity
    <Initial Approval>

10. Annex: Additional Information for Criticality Classification

GAMP Implications

Criticality High

Criticality Moderate

Criticality Low

Template Copyright See template license.

Please don’t remove this notice even if you’ve modified contents of this template.

No QMS on this planet will save you from creating crappy software.