M 171 Validation Masterplan

Best Practice
Validation Master Plan

for Equipment, Computer Systems, Networked
Systems and Spreadsheet Applications
May 2012
A master plan published for
www.labcompliance.com
Global on-line resource for validation and compliance

Copyright by Labcompliance. This document may only be saved and viewed or printed for personal
use. User may not transmit or duplicate this document in whole or in part, in any medium.
Additional copies and other publications on validation and compliance can be ordered from
While every effort has been made to ensure the accuracy of information contained in this document,
Labcompliance accepts no responsibility for errors or omissions. No liability can be accepted in any
way.
Labcompliance offers books, master plans, complete Quality Packages with

validation procedures, scripts and examples, SOPs, publications, training and
presentation material, user club membership with more than 500 downloads and
audio/web seminars. For more information and ordering, visit
www.labcompliance.com/solutions
Contents
1. Purpose and scope of this plan..................................................................3
2. Introduction......................................................................................................3
3. Responsibilities...............................................................................................4
4. Related documents.........................................................................................7
5. Products/processes to be validated and/or qualified...........................7
6. Validation approach.......................................................................................8
7. Steps for Equipment Qualification...........................................................10
8. Computer System Validation.....................................................................19
9. Networks and Networked Systems..........................................................24
10. Existing (Legacy) Systems.......................................................................28
11. Validation of Macros and Spreadsheet Applications........................30
12. Change Control...........................................................................................32
13. Instrument Obsolescence and Removal..............................................35
14. Glossary.........................................................................................................35
15. Documentation maintenance...................................................................35
Appendix A. Checklists and Forms..............................................................36
Checklists........................................................................................................36
Forms................................................................................................................36
Page 2 of 41
1. Purpose and scope of this plan

Provides a framework and practices for validation and
qualification of equipment, computer systems and networked
systems for laboratories and manufacturing. It also is
applicable to the validation of Macros and Spreadsheet
applications. The Validation Master plan should ensure that
validations and qualifications are done efficiently and
consistently throughout the organization and meet regulatory,
quality and business requirements. The plan should ensure
that the company's validation procedures are followed. The
company validation master plan is the basis of individual
project validation plans, sometimes also called master
validation plan.
2. Introduction
This is the most important part of a validation plan. It
summarizes what the project is all about and what you are
trying to accomplish with it and with validation. It summarizes
The purpose of project

Brief description of the system
Validation approach
The name and location of the facility where the equipment
or system is located
Timeline
Page 3 of 41
3. Responsibilities
Identifies all validation responsibilities like system owner,
system manager, validation team, QA, operations, plant
maintenance/engineering, IT, lab support services, users etc.
3.1 Validation team
creates, updates, and reviews/ approves individual

project validation plans and validation deliverables
ensures validation compliance with the company

validation master plan and project validation plan
coordinates, implements, verifies elements of the VMP
consults on, evaluates and approves changes
reviews and approves IQ/OQ/PQ procedures and plans
reviews test results and makes recommendations

regarding release
assess risks and develops contingency plan
3.2 User representation
create and maintain equipment inventory
makes a proposal for specifications

(user requirements, functional specifications)
provides resources for all required qualification

activities (IQ, OQ, PQ)
reviews procedures test methods for usability and

practicability
recommends criticality level of failures
monitors on-going system performance and reports

problems
Page 4 of 41
3.3 Plant safety/maintenance/engineering
advises on and prepares the facility/laboratory to meet

the equipment's environmental and safety
specifications
3.4 Information Services (IS)
assures that selected system fit into current and

future IT infrastructure
performs installation and maintenance of computer

networks
provides tools for data collection and archiving
provides training for users on the use of networks
3.5 Validation (engineering) groups
provides expertise to develop and implement

validation deliverables in efficient and consistent way
provides detailed validation guidance
trains employees on validation requirements and

techniques
3.6 Quality Assurance (QA)
provides quality assurance expertise in the creation of

the project validation plan and other validation
deliverables
monitors compliance with regulations and established

standards
approves and administrates SOPs
audits equipment/computer systems
develops test plans for equipment and computer

systems
(This can also be done by the development
department. In this case QA reviews the plans)
leads vendor assessment program
trains employees on regulations
Page 5 of 41
3.7 Responsible person
manages the validation project
establishes a project validation team
schedules and facilitates validation team meetings
initiates creation and maintenance of documentation
assures that change(s) are managed and controlled
assures the final approval of the system for use
keeps information on all validation activities
informs all parties on changes
3.8 Consultants
Some of the activities can be out-sourced to

consultants. For example, developing specifications
based on inputs from users, developing IQ/OQ/PQ
procedures, leading vendor assessment programs and
preparing validation summary reports
3.9 Vendors
Design, develop and validates equipment, software

and systems during development following
documented procedures
Provides documented evidence that the software has

been validated
Provides documentation on the validation approach

taken by the vendor
Provides a complete list of functional and performance

specifications that can be used to derive a company's
specification for the project
Allows a vendor audit if required by regulatory

agencies or the user
Provides documentation and services for installation

qualification
Provides documentation and services for operational

qualification
Page 6 of 41
Provides training on the technique and operation of

the system
Provides on-going support through phone or on-site
3.10 All
Assure that all people who are involved in the

specification, design, development, validation and use
of equipment and computer/networked systems are
trained and understand regulations.
4. Related documents
Corporate and/or local validation policies

Standard operating procedures
Checklists, e.g., for vendor assessment
Templates, e.g., for change control
5. Products/processes to be validated
and/or qualified
5.1 Equipment, computers, software, network modules and
networked systems that are used in regulated
environment. Requirements may come from the US FDA
and EPA, EU authorities, Japanese MHW or any other
country that may have an impact or the companies
business.
5.2 Equipment, computers and networked systems and
software that are critical to the operation of a company or
department
Page 7 of 41
5.3 New equipment, computers and networked systems

5.4 Existing equipment, computers and networked systems
5.5 Any computerized system that is used to create, modify,
maintain, archive, retrieve or transmit data (US FDA 21
CFR Part 11). This includes, for example, analytical
instruments, other automated laboratory equipment,
computers that are used to acquire, and evaluate data and
Laboratory Information Management Systems (LIMS). It
also includes systems to create and maintain Standard
Operating Procedures (SOP) in electronic format,
Calibration Tracking Systems (CTS), and may be e-mail
systems. Other examples are Supervisory Control And
Data Acquisition (SCADA), Electronic Batch Record
Systems (EBRS), Programmable Logic Controllers (PLC),
Process Control Systems (PCS), integrated
information/business Systems, Enterprise Resource
Planning (ERP) Systems, , Digital Control Systems (DCS),
Systems, Manufacturing Execution Systems (MES) and
Laboratory Information Management Systems (LIMS).
Ask yourself, if the information on the system is absolutely
required for GMP/GMP. If yes, the system should be
validated.
5.6 Equipment and computers/networked systems as
identified in chapter 5.5 after changes.
6. Validation approach
Approach for new systems
6.1 If the equipment/computers are used across more than
one department, form a project validation team
representing all affected departments. Expertise of any
of the department is needed for doing initial validation
'right' but also for revalidation when the system is
changed.
Page 8 of 41
6.2 Develop a validation project plan with time schedule and

owners
6.3 Develop user requirement and functional specifications
6.4 Select a supplier (may be internal or external)
6.5 For computer systems, qualify the supplier (for details,
see chapter 7)
6.6 Develop validation procedures (SOPs) and templates
that can be used to qualify or validate the system during
installation (IQ), prior to operation (OQ) and during
routine use (PQ).
6.7 Develop criteria and procedures for
revalidation/requalification
6.8 Develop acceptance criteria for OQ and PQ tests.
6.9 Get approval for test procedures and acceptance criteria
from QA and the validation team.
6.10 Install the system and perform IQ
6.11 Perform and document OO tests
6.12 Check if criteria under 6.8 are met
6.13 If acceptance criteria are not met, check
equipment/computerized/networked systems or
procedure. Acceptance criteria should not be changed.
Repeat steps 6.11 and 6.12. If the problem still exists,
report to the supplier.
6.14 Write an OQ summary report.
6.15 Implement procedures for on-going performance
qualification (PQ).
6.16 The validation/qualification documents should be
reviewed and approved by the validation team, the
system owner, e.g., the lab manager for small systems,
QA/QC and other departments if, affected, for example,
IT departments, for networked computer systems.
Changes to the documents should be approved and
documented (versioned).
6.17 All validation/qualification documents should be archived
in secure locations
Approach for existing systems

When the FDA or other regulatory agencies audit computer
systems, they will not ask if the system is new or legacy
Page 9 of 41
(legacy means, the system has been in place before a new

regulation has been released). They will ask for a validation
approach and expect to have similar or the same documents
available as for new systems. The following steps
demonstrate the approach the company takes to bring legacy
systems into the validated status.
6.18 Develop an inventory (master lists) that includes all
equipment and computers currently in use in the
laboratory/operation and appropriate business area. The
inventory list should be designed such that it can easily
be upgraded.
6.19 Categorize the equipment and computers based on
impact to regulatory submission and business impact,
use yes or no. (yes = requires validation, no = does not
require validation)
6.20 Further identify impact on product quality of all
equipment as classified in 6.19 with 'yes'. Use categories
high (immediate impact on product quality), medium (no
immediate impact on product quality), low (no impact on
product quality)
6.21 Develop a time plan to validate the selected systems
using classification in 6.20 as criterion. Immediately start
to validate all systems classified as "high"
6.22 For further steps, follow 6.1) to 6.17).
7. Steps for Equipment Qualification

Equipment qualification should include:
7.1 Design Qualification (DQ)

DQ defines the functional and operational specifications of
Page 10 of 41
the instrument and details the conscious decisions in the

selection of the supplier. DQ should ensure that
instruments/computer systems have all the necessary
functions and performance criteria that will enable them to be
successfully implemented for the intended application and to
meet business and regulatory requirements. Inputs for
specifications come from anticipated users.
Design qualification should include these steps:
Background information and description of the

application problem. If the instrument will be used for
several applications, describe a few typical scenarios.
Selection of the technique and/or type of equipment
Description of the purpose and intended use of the

equipment. If the instrument will be used for several
applications, describe a few typical scenarios.
Description of the intended environment
Description on how the instrument will be used in the

selected environment and within a process. If the
instrument will be used for several applications,
describe a few typical scenarios.
Development of user requirement specifications
Preliminary selection of the functional and performance

specifications
(technical, environmental, safety, security access,
compatibility with existing and future
systems/platforms)
For larger systems, development of system schematics,

network layouts etc
Preliminary selection of the supplier
Instrument tests (if the technique is new)
Final selection of the equipment
Final selection and qualification of the supplier and

equipment
Discussion and documentation of warranty,

familiarization, training, consulting and other vendor
services
Page 11 of 41
Development and documentation of final functional and

operational specifications
Review and approval of user requirement and

functional specifications by users of the system and by
the project validation team.
7.2. Installation Qualification (IQ)

Installation qualification establishes that the instrument is
received as designed and specified, that it is properly
installed and configured in the selected environment, and
that this environment is suitable for the operation and use
of the instrument.
Installation Qualification should include these steps:
Check if the environmental and safety conditions, e.g.,
power condition requirements, meet the criteria as
specified for the instrument
Compare equipment, as received, with purchase order
(including software, accessories, spare parts)
Check documentation for completeness (operating
manuals, maintenance instructions, standard operating
procedures for testing, safety and validation certificates)
Check equipment for any damage
Install hardware (computer, equipment, fittings and
tubings for fluid connections, power cables, data flow
and instrument control cables)
Switch on the instruments and ensure that all modules
power up and perform an electronic self-test
Install software on computer following the
manufacturers recommendation
Verify correct software installation, e.g., verify that are
all files loaded. Utilities to do this should be included in
the software itself.
Make back-up copy of software.
Configure peripherals, e.g. printers and equipment
modules.
Page 12 of 41
Identify and make a list with a description of all

hardware, include drawings where appropriate.
Make a list with a description of all software installed on
the computer.
List equipment manuals and SOPs.
Develop operation and calibration procedures.
Make entries into the equipment logbook.
Prepare an installation report.
Enter the equipment in the laboratory's equipment
database
Items that should be included for each piece of equipment
in the database include:
Unique in-house identification number (asset number)
Name of the item of equipment
The manufacturers name, address and phone number

for service calls, service contract number, if there is
one
Serial number and firmware revision number of

equipment
Date received
Date placed in service
Current location
Size, weight
Condition when received, for example, new, used,

reconditioned
List with authorized users and responsible person
The database should also have entry fields for dates of the
last and next operational qualification.
For large systems, e.g., computerized protein sequencers,
IQ should be performed and documented by the supplier.
The user should sign the IQ report. For small equipment,
e.g., pH meters, IQ should be performed and documented
by the user.
Page 13 of 41
IQ documents must be updated, if there is any change to the

system. Changes can include:
move to an other room
update with new hardware, firmware, software
exchange of modules which have individual serial
and/or asset numbers
Page 14 of 41
7.3. Operational Qualification (OQ)

Operational qualification (OQ) is the process of
demonstrating that an instrument will function according to
its operational specification in the selected environment.
The instrument should be tested against critical
performance specifications as specified in the Design
Specifications document.
Steps for OQ include:
Obtain functional and performance specifications
(preferably use information from DQ).
Identify critical functions that should be tested in the

user's environment.
Link the test cases to the user requirement and

functional specifications as defined in the DQ phase.
Develop SOPs for testing
Test procedures should include what to test, how

testing should be conducted and the expected results
with acceptance criteria.
For modular systems, test the system as a whole, not

module by module
If there are several systems of the same type and

function in a laboratory/operation, use the same
procedure and preferably the same acceptance criteria
for all systems
Whenever possible use the manufacturer's procedure

for testing
Don't use the manufacturer's performance specification

limits if the performance is expected to deteriorate over
time. Take performance specification as required by the
application.
Decide for each instrument whether to do OQ tests by

your own people, by the vendor or by a 3 rd party.
Criteria are costs, availability and training of people
and available of (traceable) qualification tools.
Define the frequency of OQ as recommended by the

vendor.
Page 15 of 41
Define re-qualification criteria and procedures after

equipment up-dates, moves and repairs.
7.4. Performance qualification (PQ)

Performance Qualification (PQ) is the process of
demonstrating that an instrument consistently performs
according to a specification appropriate for its routine use.
Important here is the word consistently.
Main activities in the PQ phase are
preventive maintenance
requalification after changes and
on-going tests.
The test frequency is much higher than for OQ. Another
difference is that PQ should always be performed under
method conditions that are similar to routine sample
analysis.
In practice, for laboratory operation PQ testing can mean
system suitability testing, where critical key system
performance characteristics are measured and compared
with documented, preset limits. For example, a well
characterized standard can be injected 5 or 6 times and
the standard deviation of amounts are then compared with
a predefined value. If the limit of detection and/or
quantitation are critical, the lamps intensity profile or the
baseline noise should be tested. Recommended steps for
PQ are:
1.
Define test procedures and the performance criteria

for the complete system.
2.
Select critical parameters. For a chromatography

system this can be
precision of the amounts
precision of retention times
resolution between two peaks
peak width at half height or
peak tailing
limit of detection and limit of quantitation
Page 16 of 41
wavelength accuracy of a UV/Visible wavelength

detector.
3. Define the test intervals, e.g.,

every day
every time the system is used
before, between and after a series of runs
4. Record any unusual event in the equipment logbook
5. Define corrective actions on what to do if the system
does not meet the criteria, in other words if the system
operates out of specification.
7.5. Documentation
On completion of equipment qualification, documentation
should be available that consists of:
Validation summary report with final approval

(disapproval) statement, the qualified operating
ranges, and a list of all deliverables generated during
the validation process. The report should also contain
a list of follow-up activities if there are some
deviations.
Design qualification documents with purpose of the
system, user requirements and functional and
performance specifications.
Installation qualification document (includes
description of hardware and software).
Procedures for OQ testing and acceptance criteria.
OQ test protocols and results with signatures and
dates
PQ test procedures, acceptance criteria, test protocols
and representative results
OQ stickers for the equipment with information on test
engineer, date of OQ and date next OQ
Statement by the user on formal acceptance
Updated equipment database with information on
validation status.
Page 17 of 41
8. Computer System Validation

In principle validation of computer systems should follow the
same guidelines as outlined in Chapter 7 for equipment
qualification. If the computer is connected to equipment and
used for instrument control and data evaluation for that
equipment without networking to other computers, the
computer can be treated as a module of that system and
should be qualified as part the system.
For networked computer systems with more complex
functionality additional tasks should be performed for the
individual qualification steps (see also next chapter).
8.1 Design qualification

DQ should include a background information and a
description of the current computer system platform,
future plans and how the new system fits into this
environment. It should describe which role the system
plays in the workflow of an overall process. This includes
interfaces to equipment but also to a corporate IT
system. Once the workflow and data flow known, there
should be a definition
of raw data and meta data,
how integrity of the data is ensured
for how long these data must be archived and
how they can be retrieved.
DQ should also describe whether the system will be

configured or otherwise customized in the user's
environment. If the system is purchased from a vendor
and customized by the user, it should clearly describe
who is providing what.
When documenting communication between equipment
and the computer, the user requirement and functional
Page 18 of 41
specifications should clearly state if it is a one-way or

two-way communication and how many instruments can
communicate with the computer simultaneously.
8.2 Vendor qualification

For computer systems there should be documented
evidence that software and system has been validated
during and at the end of development. The vendor
should also provide assistance for DQ, IQ and OQ and
on-going support during routine use. The user must have
confidence in the supplier's quality, validation and
support processes that should be documented in a
formal vendor assessment document. There are
different possibilities to assess a vendor. They are listed
in table 8.1.
Table 8.1 Possibilities to assess a vendor
#
1
Assessment
Through references
outside your company
Comment
Useful if there is no experience with
the vendor within your company.
Criteria are
acceptance of the vendor in the
market place
image of the vendor as software
supplier
quality reputation of the product
Through own
experience with the
vendor
Through own
experience with the
product
Checklist - Mail audit
Experience may come from the

product under consideration or from
other products. Criteria are
Quality of the products (failure
rate)
Responsiveness in case of
errors
(phone call, on-site visit, bug fix)
Very much the same as in 2, but
more accurate because most likely
the software has been developed
and is supported by the same
people as the new purchase
Use checklists available within your
Page 19 of 41
company, through public

organizations, e.g., PDA and from
private authors, e.g., in this book
Follow up through video Can be used to proof that
or teleconference
documents referred to in the mail
audit exist, are readily available and
have required content and quality
rd
Assessment through 3
Give an independent assessment of
party audits
the quality system and/or product
development
Vendor audit through
Gives a good picture on the
user to assess the
vendors quality system
quality system
Vendor audits through
Gives a good picture on how the
user for individual
quality of the individual product
projects
The required assessment level depends on the

complexity of the system and should be defined by the
project team and documented in the individual project
validation plan.
The vendor should be qualified based on business
aspects (size, market focus, financial strengths, attitude
to people qualification, future perspective) and technical
aspects (specification, design, development, testing and
support).
Key elements of a vendor assessment are:
The vendor must provide documented evidence that

the software has been validated during development.
This can include a validation certificate and a
description on the vendor's development and
validation procedure. The vendor should also agree
to provide access to additional information like test
plans, test results or source code at the vendor's
location.
The vendor should have procedures and/or systems

in place for: security, maintenance, user feedback,
change control, backup and disaster recovery system
to ensure safe ongoing support of the system.
Page 20 of 41
All people in software development should be

adequately trained on software engineering practices
but should also have a basic understanding on
regulatory requirements, e.g., GLP and GMP.
Customer support people should be available on the

phone and for on-site visits, if need arises.
Depending on the criticality and complexity of

computer system, the assessment can be based on
historical experience with the vendor, checking the
documentation as provided by the vendor, developing
and evaluation of additional questions/answers and
finally through a vendor audit.
A vendor assessment or qualification report should be

developed which includes a statement on 'vendor
qualification status'.
Depending on the complexity and information existing on a

vendor a direct audit can be necessary. The validation
team should decide on this for each individual project.
Criteria for a vendor audit are:
Commercial off the shelf system or be-spoke

Complexity of the system
Number of systems purchased from the vendor
Availability of development validation from the vendor
Stand alone or networked system
Influence of the system on other systems
Maturity of system
Experience with the system
Reputation of the system in the market place
Experience with the vendor
A vendor's documented evidence of audits from other
companies within the same industry?
Own audit experience with the vendor
Business impact of the system
8.3 Installation qualification
IQ should include a test to verify that the software

has been copied accurately and completely to the
Page 21 of 41
computer's hard disk. Preferably the vendor should

provide such verification programs as part of the
application software.
For complex computer systems, a schematic diagram

should be developed to illustrate the individual
hardware connections and the data flow.
Verify correct use of cables as specified by the

vendor, for example type and length.
Computers should be entered in the equipment

inventory database. Information should include
-
Computer hardware with information on the

processor, hard disk space, memory and the
monitor
Software with product and revision number
8.4 Operational qualification

Most important for OQ testing of computer systems is the
right selection of tests. It is obvious, that not all functions
can be tested. Selection of tests should be based on risk
assessment and must be approved by the validation
team.
OQ should also include specific tests to meet

requirements of 21 CFR 11, e.g., limited system
access, electronic audit trail, generation of exact
copies, prevention of overwriting raw data when
reprocessing data.
If multiple analytical instruments are connected to

single computers, proper function and correct data
transmission should be verified under the highest
anticipated data transfer rate (high load testing).
If the computer system is expected to perform

multiple tasks simultaneously, proper function should
be verified under highest anticipated workload.
Tests cases and acceptance criteria should be traceable to

specifications. Test data sets and procedures should be
designed such that they can be easily re-used for later
requalification.
Page 22 of 41
8.5 Performance qualification

Performance qualification should include
regular virus checks
regular data backup and removal of unnecessary files
to avoid hard disk overflow. As a rule of thumb, the
hard disk should not be loaded more than 80%
procedures and regular check for authorized user
access
procedure and regular problem reporting system back
to the system developer
9. Networks and Networked Systems

In principal networked systems and applications running on
networks are computer systems and as such should follow
practices for computer system validation. Everything what is
important about computer validation can be applied to
networks as well. A network component should be treated like
a piece of equipment, which is installed and qualified. As next
typical network functions such as limited access and network
transactions should be qualified. As the final step the
complete network application should be tested and test
results compared with specifications.
Compared to standalone computer systems, networks and
networked systems require some special considerations for all
qualification phases:

When a network is specified, the following questions
should be answered:
Page 23 of 41
How much traffic will it carry, especially under highest

load or under so called worst case conditions?
What is the maximum distance between individual

network components?
How many users are using the network concurrently?
What is the risk and impact of a server failure?
What are the backup and archiving cycles?
What availability is expected from the network?
What is the environment in which it will be operating?
What are the protocols: GPIB-IEEE vs. TCP/IP?
For networked systems: Description of the scope of

the system: what is it, what is it not (important to
define the validation box). This is important to draw
the boundaries to other systems.
9.2. Installation Qualification

Network specific IQ activities include:
Configure and document all network settings (e.g.,

routers settings).
Include network cables and other hardware

components, e.g., hubs, and software into the
equipment data base.
Check if physical security specifications are met (e.g.,

lockable hardware to prevent unauthorized access to
the server's RAID system).
Develop high level and detailed system drawings,

physical diagrams such as floor plans with component
locations and cabling, and logical diagrams like TCP/IP
schemes and how components interrelate with each
other.
9.3 Operational Qualification

Network specific tests should include
Page 24 of 41
Starting and shutting down networked systems

(including documenting messages indicating whether
the network was successfully started/shutdowned)
Switching of and on network components (e.g., hubs,

routers, switches) and to note the impact of the action
on the network capability to operate.
Security tests, for example logging on with correct and

incorrect password.
Checking correct password administration, for

example, when the password policy says that a
password should have a minimum length of six
characters, try to specify one with four characters.
Checking session unlock and user specific automated

time-outs, if there are any.
Checking access to task and file permissions. For

example, if an operator has permission to review data,
try to modify them and see if the system behaves as
expected.
Checking correct backup and restoration of data.
Checking how the system behaves and recovers from

system failures. Trigger a failure through
disconnecting and reconnecting network components.
Checking correct audit trail of network transactions.
Checking correct data transfer under normal AND

under high traffic.
Checking individual software modules and systems for

virus infection
9.3 Performance Qualification
Develop and implement procedures for back-up and

retrieval. The frequency should be based on risk
assessment and be defined by the validation team.
Validate back-up and retrieval procedures.
Develop and implement a contingency plan for failures
of network components to avoid loss of data.
Review of network diagrams.
Page 25 of 41
Verify individual software modules and systems for

virus infection.
Page 26 of 41
9.5 Documentation
Network specific documentation should include
Network drawings.
Updated glossary with network terminology
Updated equipment data base with network hardware,

firmware and software
Procedures to control network security in general
Procedures for generation, distribution and use of

passwords
Procedures for back-up and contingency planning
Network configuration management
10. Existing (Legacy) Systems

Existing equipment and computer systems should be qualified
and/or validated. The same principles apply as for new
systems. As explained in the preamble of FDA's 21 CFR Part
11 does not grandfather legacy systems and FDA expects that
firms using legacy systems will begin taking steps to achieve
full compliance. Firms should have a reasonable timetable for
promptly modifying any system not in compliance (including
legacy systems) to make them Part 11 compliant, and should
be able to demonstrate progress in implementing their
timetable. FDA expects that 21CFR Part11 requirements for
procedural controls will already be in place. FDA recognizes
that technology based controls may take longer to install in
older systems
The main difference to new systems is that typically no
information on the development process is available. Instead,
there is lots of knowledge from past experience. This
experience should be used to proof correct function and
Page 27 of 41
performance. Develop an equipment master plan that lists all

equipment and computer systems together with a judgment for
validation need. Develop an implementation plan with a time
schedule for the validation of all systems. Validation should
follow the same steps as for new systems.
Describe the use of the systems.
Describe required functions and performance.
No vendor qualification or evidence of development

validation is required.
10.2 Installation qualification

Document system hardware and software and enter
equipment data into the laboratory's database.
10.3 Operational qualification

Evaluate which tests have been done in the past and
check if they are sufficient to proof operational
qualification
If not, develop test procedures and acceptance criteria.
Execute and document test and compare test results
with acceptance criteria.
Declare the system as validated.
10.4 Performance qualification

Follow steps as described in chapter 7 and 8.
Page 28 of 41
11. Validation of Macros and

Spreadsheet Applications
Macro programs and spreadsheet calculations are considered
to be software and should be validated to demonstrate
suitability for their intended use. The extent of validation
depends on the impact of the Macro on product quality and on the
complexity of the Macro. Any step can be passed over as long as
there is sufficient explanation that the skipped step has no
relevance for the program. The validation steps should include:
11.1 Develop a project validation plan

Defines the scope of the project, responsibilities,
validation approach and timeline and it includes
checkpoints.
11.2 Define responsible persons

Identify persons responsible for specifications, design,
development, tests, and approvals.
11.3 Define user requirements

Describe the task, how the task is done currently and how
the new program will do it more efficiently. Describe user
requirements (what the user wants to do with the system),
system requirements (computer hardware, operating
system), regulatory (GLP/GMP/GCP, 21 CFR Part 11)
requirements and security requirements. Describe the
user's current environment: hardware environment,
software environment, IT environment. Specify minimum
hardware and software requirements that will be used.
Describe the required skill level of the end users. Describe
how extensively and how long the software is intended to
be used (anticipated number of users, life time, frequency
of use) and whether any changes are anticipated during
the life of the program.
Page 29 of 41
11.4 Specify Functions

Describe the program in terms of the functions it will
perform, written in such a way that it is understood by both
the software developer and the user. Review the functional
description against the requirement specifications
11.5 Design and implementation

Document formulae or algorithms used within the program.
Write the code. Define file structure, e.g., whether to use
one Excel workbook with multiple sheets, several singlesheet workbooks or just a template. Define formulas to
perform calculations. When using Excel, define whether to
use Excel functions or VBA procedures. Determine the
most appropriate user interface: dialog boxes, list boxes,
menus, toolbars, short cut keys. Define the level of
security to restrict access to the whole or particular
elements of the program. Define how to handle errors,
e.g., how the application detects and deals with errors.
Annotate the code using documentation standards of your
organization, if available Document the program such that
it can be understood by other people whose education and
experience are similar to the programmer.
11.6 Testing
Develop a test plan to test the Macro and Spreadsheet
application for all functions the user will use. Develop a matrix
that links functions to be tested to requirement specifications.
Develop test cases and test data sets with known inputs and
outputs. Describe the test environment and the execution of
tests. Test protocols must clearly state the Macro title, revision
number, and file name. Tests should describe the test
environment and the execution of tests. Develop test cases and
data test sets that can be used for current and future testing
that simulate as much as possible the real-life environment (life
testing). Include test cases with normal data across the
operating range, boundary testing and unusual cases (wrong
inputs). Include procedures to verify calculations. Test
procedure and results should be documented, reviewed and
approved by the programmers, and for complex macros by
quality assurance departments.
Page 30 of 41
11.7 Ongoing performance checks

Specify type and frequency of checks as well as expected
results and acceptance criteria. Develop test data sets and
procedures for ongoing performance checks.
11.8 User documentation

Describe the programs functionality and formulae used for
calculations and how to install, operate and test the
program.
11.9 System security and data integrity

Describe which features are implemented to meet security
requirements, for example, back-up procedures and
limited authorized system access to the program and data.
Describe how integrity of Macro and Spreadsheet program
and data generated by the program is ensured, for
example how can you ensure that only authorized Macros
are used and Macros are not changed, either incidentally
or accidentally, outside the change control environment.
11.10 Change and version control

Develop a procedure to authorize, test, document and
approve any changes to the software before
implementation.
12. Change Control

Equipment, computers and networked systems are frequently
changed during the life of the systems. It is of utmost
importance to keep systems in the validation status.
Any change to equipment and computerized/networked

systems that may affect the systems validation status
should follow documented procedures and should be
Page 31 of 41
formally approved. The procedure should include

instructions for requesting, approving, documenting and
implementing changes. They should also describe the
method of evaluation to determine the degree of
revalidation or requalification necessary to maintain the
validated state of the system. The procedure should also
identify the persons responsible for determining the
necessity for change control and for authorizing the
change.
If changes are made within a complex

computerized/networked system, the project validation
team consisting of users of equipment, support personnel
and computer validation experts should evaluate the need,
type and extend of re-qualifications on a case by case
basis. The user of the system should get advice from the
computer validation experts on which impact the change
may have on her/his system and which type tests should
be done.
If a vendor changes the software the new release should

be shipped to the users site with a validation certificate to
demonstrate that the update has been developed and
validated at the vendors site to appropriate standards.
The vendor should also inform users if the new software
may have an impact on Marco programs the user has
written.
The vendor should provide a list with functions that have

been changed, added or deleted and with information on
which impact the changes have on the validation status.
At the users site the system with the new software revision
should undergo formal installation qualification (IQ) as for
a new system.
The validation team should evaluate the need for OQ

testing. Where possible, the test cases test data used for
the re-qualification should be designed so that the results
can be compared with those obtained using earlier
versions.
Before the system continues with routine analysis, a

performance qualification (PQ) should be carried out. All
Page 32 of 41
details of the change should be formally documented with

information on:
-
clear identification of software or hardware to be

changed
reference number of change for clear process
identification
nature of the change
the reason for the change
date when the change was requested
removed software errors
new functions together with their features and
benefits
impact analysis the change may have on the
performance of connected modules and systems
the impact the change may have on user
contributed Macro programs
the type of revalidation or re-qualification tests
based on the impact analysis
acceptance criteria and
test results
revision history with old and new version numbers
date when the update was installed
list of people who have been informed
Page 33 of 41
13. Instrument Obsolescence and

Removal
When instruments are retired, a plan should be in place to
ensure that the application can run on the new system and
data generated on the old system work on the new instrument.
Steps include
Transfer the application, e.g., analytical methods, raw

data, analytical results and databases to the instrument.
Check if the new system generates the same results from

raw data as the old system.
14. Glossary
For an extensive glossary on qualification and validation see:
www.labcompliance.com/glossary
The glossary also includes terminology for network hardware

and software.
15. Documentation maintenance
Lists all documents

Describes where documentation and software is archived.
Describes criteria and examples for time the
documentation must be archived:
examples include validation master plans, project
validation plans, validation deliverables, user manuals
Defines owners of documents
Page 34 of 41
Appendix A. Checklists and Forms

Checklists
Forms
F1001
F1002
F1004
F1006
F1009
F1010
Change control form

Change control summary log
Initiation and authorization of Macros and Spreadsheets
Validation deliverables and owners
Validation team members
Preparation and approval of the validation master plan
Page 35 of 41
Form F1001: Change control

Change Control Form
Form ID
Date:
System ID:
Location:
Description of change
(should include
reason for change)
Expected impact on
validation
Authorization to
change
Name:
Change implemented
on
Date:
Comments
(implementation,
testing)
e.g., document any observation and new

version or revision number, types of tests that
have been performed
Completed by
Name:
Signature
Date
Approved by
Name:
Signature
Date
Signature
Date
Page 36 of 41
Form F1002: Change control summary log
System ID
Name: CDS ChemStation Plus

Number: C4663B
Date
Type of Change
Change
control form
ID
04/75/01
ChemStation software upgrade

from version A.08.01 to A.08.01
H1674
Page 37 of 41
Form F1004: Initiation and Authorization of

Macros & Spreadsheets
Form ID
System Location:
Initiator:
Description of
problem, how it is
solved now and how
the new software can
improve efficiency
Expected duration of
use and frequency of
use: e.g., 6 months, 5
times a day
Approval of
supervisor:
Supervisor function:
Name
Signature
Date
Comments:
Approval/rejection by
QA:
Approval yes/no
Reason for approval/rejection
Name
Signature
Date
Comments/Recommendations:
Page 38 of 41
Form F1006: Validation deliverables and owners

Deliverable
Prepared by
Reviewed
by
Approve
d by
Reference
document
Validation plan
Validation
team
Operation
manager
VP 679
IQ Protocol
Vendor
Validation
team
QA
system
Owner
QA
manager
V456
Page 39 of 41
Form F1009: Validation team members
Department
Name
Tel
E-mail
QA
Consultant
IT
Lab
Validation
group
Vendor
Page 40 of 41
Form F1010: Preparation and approval of

validation project plans (master validation
plan)
Preparation
Representing
department
Name
Signature
Date
Signature
Date
User
QA
IT
Validation group
System owner
Business
Management
Review and approval

Representing
department
Name
Title
System Owner/
Management
QA Compliance
Page 41 of 41

M 171 Validation Masterplan

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

M 171 Validation Masterplan

Caricato da

Copyright:

Formati disponibili

Best Practice

Validation Master Plan

Global on-line resource for validation and compliance

Labcompliance offers books, master plans, complete Quality Packages with

Validation Master Plan

Validation Master Plan

1. Purpose and scope of this plan

The purpose of project

Validation Master Plan

3.1 Validation team

creates, updates, and reviews/ approves individual

ensures validation compliance with the company

coordinates, implements, verifies elements of the VMP

consults on, evaluates and approves changes

reviews and approves IQ/OQ/PQ procedures and plans

reviews test results and makes recommendations

assess risks and develops contingency plan

3.2 User representation

create and maintain equipment inventory

makes a proposal for specifications

provides resources for all required qualification

reviews procedures test methods for usability and

recommends criticality level of failures

monitors on-going system performance and reports

Validation Master Plan

3.3 Plant safety/maintenance/engineering

advises on and prepares the facility/laboratory to meet

3.4 Information Services (IS)

assures that selected system fit into current and

performs installation and maintenance of computer

provides tools for data collection and archiving

provides training for users on the use of networks

3.5 Validation (engineering) groups

provides expertise to develop and implement

provides detailed validation guidance

trains employees on validation requirements and

3.6 Quality Assurance (QA)

provides quality assurance expertise in the creation of

monitors compliance with regulations and established

approves and administrates SOPs

audits equipment/computer systems

develops test plans for equipment and computer

leads vendor assessment program

trains employees on regulations

Validation Master Plan

3.7 Responsible person

manages the validation project

establishes a project validation team

schedules and facilitates validation team meetings

initiates creation and maintenance of documentation

assures that change(s) are managed and controlled

assures the final approval of the system for use

keeps information on all validation activities

informs all parties on changes

Some of the activities can be out-sourced to

Design, develop and validates equipment, software

Provides documented evidence that the software has

Provides documentation on the validation approach

Provides a complete list of functional and performance

Allows a vendor audit if required by regulatory

Provides documentation and services for installation

Provides documentation and services for operational

Validation Master Plan