Thank-You For Downloading The Validation Master Plan Template!
Thank-You For Downloading The Validation Master Plan Template!
Thank-You For Downloading The Validation Master Plan Template!
Waiver:
You can freely download and fill the templates of blog.cm-dm.com, to produce
technical documentation. The documents produced by filling the templates are
outside the scope of the license. However, the modification of templates to produce
new templates is in the scope of the license and is not allowed by this license.
To be compliant with the license, I suggest you to keep the following sentence
at least once in the templates you store, or use, or distribute:
This Template is the property of Cyrille Michaud License terms: see http://blog.cm-
dm.com/post/2011/11/04/License
You can remove this first page when youve read it and acknowledged it!
I. Introduction
Attention: This validation plan is applicable to software or computerized systems only. It is
not applicable to physical equipment.
A. Goal
This document is the validation master plan of ACME Company.
The validation of each computerized system is described in a Validation Protocol (form XXX,
see template), which implements the principles of this procedure. The results of the validation
are described in a Validation Report (form XXX, see template).
B. Scope
This validation procedure embraces all computerized and automatized systems used by
processed in the scope of ACME QMS, including text documents with macros and spreadsheet
documents with macros or complex formulas.
It doesnt include:
Text or spreadsheet documents without macros,
Software used in processes outside QMS scope: accounting, legal
The IT infrastructure (network).
C. Responsibilities
XXX (the QA manager for instance) is responsible for the application of this procedure. He/she
is also responsible for:
The coordination of validation tasks between all system owners (see below),
The periodic inventory of all computerized systems of ACME Company.
Each computerized system is attributed to a system owner. The system owner is responsible
for the validation of the computerized systems he manages.
He/she his responsible for:
The creation and the maintenance of Validation Protocols,
The follow-up of validation activities of systems he/she has is charge.
Overview of steps:
Step 2 Classification The second step is to split selected systems in three categories:
Low level of concern,
Medium level of concern,
High level of concern.
Step 3 Design The third set is to determine whether design qualification (DQ) is
qualification required, based on the features of the computerized system to
validate
A. Step 1 Selection
1. Identification of computerized systems
For each system, the following tables allow to identify computerized systems, which require
validation. Other criteria may be used to select computerized systems on a case-by-case basis.
(if the answer is yes to at least one of the question of the table below, software should be
validated, unless rationale is brought)
# Question Answer
1.1 Is the computerized system used in a process for production and service
provision, in a way that affect the ability of the product to conform to
specified requirements? (7.5.2 of ISO 13485)
1.2 Is the computerized system used in the quality management system?
(4.1.6 of ISO 13485:2016)
1.3 Add you own answers, based on ISO or 21 CFR part 820 (like 820.70(i))
requirements, or any other relevant regulations or standards.
(if the answer is yes to at least one of the questions of the table below, electronic records are
in the scope of 21 CFR part 11)
1.5 Are records stored both in electronic format and in paper, with electronic
records preferably used rather than paper records?
1.6 Are electronic signatures equivalent to inked signatures?
This risk assessment is made by seeking the following (but not limited to) sequences of
events:
For software used on or with equipment in production:
o The consequence on the equipment it controls or supports,
o The consequence on the conformity of the product,
o The consequence on the patient,
For software used for servicing:
o The consequence on the service it controls or supports,
o The consequence on the conformity of the product or of the service,
o The consequence on the patient,
For software used to process quality or regulatory data:
o The consequence on quality documents or records,
o The consequence on the conformity of the product,
o The consequence on the patient.
For all software:
o The consequence of a security breach or attack,
o The consequence on quality documents or records,
o The consequence on the conformity of the product,
o The consequence on the patient.
# Question Answer
1.7 Is the answer yes to at least one of the questions 1.1 to 1.3?
1.8 Are there risks, whichever the risk severity, where the system is involved
in the sequence of events
If the answer is yes to the following question, the computerized system shall be validated
against 21 CFR part 11:
# Question Answer
1.9 Is the answer yes to at least one of the questions 1.4 to 1.6?
If the answer is yes to the following question, the computerized system is of high level of
concern:
# Question Answer
2.1 Are there risks non acceptable (use the scale in your risk management
procedure) where the computerized system is involved in the sequence of
events?
If the answer is yes to the following question, the computerized system is of Medium level of
concern :
# Question Answer
2.2 Are there risks non acceptable (use the scale in your risk management
procedure) where the computerized system is involved in the sequence of
events?
If the answer is no to the two questions above, the computerized system is of low level of
concern.
Remarks:
3.1 Examples of Highly configurable software:
o ERP,
o Software with complex configuration files like rules or workflows in XML
o Customizable software with macros or scripts,
3.1 Examples of basic configuration, for which answer to question 3.1 could be No
o Users/passwords settings,
o Network settings,
3.2 Internally developed software includes outsourced software development based on
software specifications internally defined,
3.3 Examples of complex formulas and macros:
Depending on the computerized system level of concern, some protocol tasks are optional or
not required.
A. Design qualification
1. Design qualification steps
The design process shall include at minimum the following tasks and milestones:
Project launch review,
Software Risk assessment,
Software specifications, including risk mitigation actions,
Design review,
Software verification,
Design validation review.
The design qualification protocol contains the rationale for the chosen software verification
methods (unit tests, integration tests, code reviews).
The design qualification protocol may be adapted from a software design procedure. It may
also be adapted from purchase procedure if the development is outsourced.
R: Require. D: Desirable
Software classification
No Title
High Medium Low
1. Operation & Maintenance Manual R R R
2. Software Requirements Specification R R R
3. Architectural Design R R D
4. Detailed Design R D
5. Source Code Review and Report. D
6. Unit Test Report R
7. Integration Test Specification. R R
8. Integration Test Results. R R
9. Software Test Specification. R R R
10. Software Test Results. R R R
B. Installation qualification
1. Installation qualification steps
Installation qualification aims to ensure that computerized system is properly installed in the
right environment.
The scope of IQ inspections or testing includes, as applicable:
In the case of system installed on hardware, verifying that hardware settings and
features match hardware requirements,
o Hardware installation,
o Hardware customization or settings,
o Network connections,
o Peripherals (backup/restore peripherals, other peripherals),
o Hardware maintenance contracts,
In the case of system on the cloud, verifying:
o Cloud servers settings and characteristics,
o Contract with the cloud service provider,
Verifying that software environment settings and characteristics match
environment requirements:
o Operating system versions,
o Servers (database) versions,
o Virtual machines versions
Verifying that software documentation is available and in the right version:
o Installation, administration and user manual,
o When design qualification is required, DQ output documentation,
o Specific QMS procedures and instructions, if applicable,
Installing software, if applicable,
Verifying that software is properly installed:
o Software version,
The table below identifies the documentation group applicable to each category of software
classification.
R: Require. D: Desirable
Software classification
No Title
High Medium Low
1. IQ Protocol R R D
2. IQ Report and bug reports R R D
3. IQ Records R D
C. Operational qualification
1. Operational qualification steps
Operational qualification aims to ensure that every function of the computerized system is
working as expected.
The scope of OQ testing includes, as applicable:
Functional and performance requirements,
o Verifying software functions,
o Verifying software behavior in degraded status,
Non-functional requirements, like
o Security, safety and privacy,
o Backup/restore,
o Administration functions,
o Maintenance functions,
o 21 Part 11 compliance.
The table below identifies the documentation group applicable to each category of software
classification.
R: Require. D: Desirable
Software classification
No Title
High Medium Low
1. OQ Protocol R R D
2. OQ Report and bug reports R R D
3. OQ records R D
D. Performance qualification
1. Performance qualification steps
Performance qualification aims to ensure that the computerized system works as expected in
its target environment and with target users.
The table below identifies the documentation group applicable to each category of software
classification.
R: Require. D: Desirable
Software classification
No Title
High Medium Low
1. PQ Protocol D
2. PQ Report R R R
3. PQ Records D
4. User feedbacks and bug reports R R R
Deviations that are not software bugs follow the path of non-conformities procedure:
Identification/description of the deviation,
Investigation and identification of the root cause of the deviation,
Impact on qualification activities already completed,
Proposed corrective action.
Corrective action should include, where applicable, revision of requirements and
specifications, version changes to software, and re-testing.