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
www.labcompliance.com
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
www.labcompliance.com Page 2 of 39
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
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
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
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
 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
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.
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
(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
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
 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
manufacturer’s 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.
 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 manufacturer’s 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.
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
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.
 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 lamp’s 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
 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.
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
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
# Assessment Comment
1 Through references Useful if there is no experience with
outside your company 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
2 Through own Experience may come from the
experience with the product under consideration or from
vendor other products. Criteria are
 Quality of the products (failure
rate)
 Responsiveness in case of
errors
(phone call, on-site visit, bug fix)
3 Through own Very much the same as in 2, but
experience with the more accurate because most likely
product the software has been developed
and is supported by the same
people as the new purchase
4 Checklist - Mail audit Use checklists available within your
company, through public
organizations, e.g., PDA and from

private authors, e.g., in this book
5 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
6 Assessment through 3 Give an independent assessment of
party audits the quality system and/or product
development
7 Vendor audit through Gives a good picture on the
user to assess the vendors quality system
quality system
8 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.
 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
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.
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:
 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
 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.
 Verify individual software modules and systems for
virus infection.
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
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.
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.
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 single-
sheet 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 programmer’s, and for complex macros by
quality assurance departments.
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 program’s 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 system’s validation status
should follow documented procedures and should be
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 user’s site with a validation certificate to
demonstrate that the update has been developed and
validated at the vendor’s 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 user’s 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
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
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
Appendix A. Checklists and Forms
Checklists
Forms
F1001 Change control form

F1002 Change control summary log
F1004 Initiation and authorization of Macros and Spreadsheets
F1006 Validation deliverables and owners
F1009 Validation team members
F1010 Preparation and approval of the validation master plan
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 Name: Signature Date

change
Change implemented Date:

on
Comments e.g., document any observation and new
(implementation, version or revision number, types of tests that
testing) have been performed
Completed by Name: Signature Date
Approved by Name: Signature Date
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 H1674
from version A.08.01 to A.08.01
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 function:

supervisor:
Name Signature Date
Comments:
Approval/rejection by Approval yes/no

QA:
Reason for approval/rejection
Name Signature Date
Comments/Recommendations:
Form F1006: Validation deliverables and owners
Deliverable Prepared by Reviewed Approve Reference

by d by document
Validation plan Validation Operation QA VP 679

team manager system
Owner
IQ Protocol Vendor Validation QA V456
team manager
Form F1009: Validation team members
Department Name Tel E-mail
QA
Consultant
IT
Lab
Validation
group
Vendor
Form F1010: Preparation and approval of

validation project plans (master validation
plan)
Preparation
Representing Name Signature Date

department
User
QA
IT
Validation group
System owner
Business
Management
Review and approval
Representing Name Signature Date

department Title
System Owner/
Management
QA Compliance

M 171 Validation Masterplan

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

M 171 Validation Masterplan

Diunggah oleh

Hak Cipta:

Format Tersedia

Best Practice

Validation Master Plan

A master plan published for

Labcompliance offers books, master plans, complete Quality Packages with

1. Purpose and scope of this plan..................................................................3

5. Products/processes to be validated and/or qualified...........................7

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

15. Documentation maintenance...................................................................35

Appendix A. Checklists and Forms..............................................................36

1. Purpose and scope of this plan

Provides a framework and practices for validation and

 The purpose of project

3.1 Validation team

3.2 User representation

3.3 Plant safety/maintenance/engineering

3.4 Information Services (IS)

3.5 Validation (engineering) groups

 provides detailed validation guidance

3.6 Quality Assurance (QA)

3.7 Responsible person

 Provides on-going support through phone or on-site

CFR Part 11). This includes, for example, analytical

Ask yourself, if the information on the system is absolutely

6.1 If the equipment/computers are used across more than

6.5 For computer systems, qualify the supplier (for details,

Approach for existing systems

demonstrate the approach the company takes to bring legacy

6.18 Develop an inventory (master lists) that includes all

7. Steps for Equipment Qualification

Equipment qualification should include:

7.1 Design Qualification (DQ)

meet business and regulatory requirements. Inputs for

Design qualification should include these steps:

 Background information and description of the

7.2. Installation Qualification (IQ)

Installation qualification establishes that the instrument is

Installation Qualification should include these steps:

 Prepare an installation report.

Enter the equipment in the laboratory's equipment

 Unique in-house identification number (asset number)

For large systems, e.g., computerized protein sequencers,

IQ documents must be updated, if there is any change to the

 move to an other room

7.3. Operational Qualification (OQ)

Steps for OQ include:

 Define re-qualification criteria and procedures after

7.4. Performance qualification (PQ)

Main activities in the PQ phase are

The test frequency is much higher than for OQ. Another

1. Define test procedures and the performance criteria

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

 Validation summary report with final approval

8. Computer System Validation

In principle validation of computer systems should follow the

8.1 Design qualification

two-way communication and how many instruments can

8.2 Vendor qualification