This SOP Template (template) is being provided by Praxis Management International, LLC

(Praxis) for the "fair use" by you, the User, as that term is defined under the U.S. Copyright
Laws. All other use, reproduction or re-transmission in any form or by any means, electronic
or mechanical, including photocopying and recording, or by any information storage or
retrieval system, without prior written permission from Praxis is prohibited. ©2011-2016
Praxis Management International, LLC. All rights reserved.

Praxis makes no representations or warranties concerning the suitability or use of, or

reliance on, the Template. Any actual or implied representation or warranty that the
Template does not infringe the intellectual property rights of any third party is specifically
hereby void. Any special, indirect or consequential damages or any damages whatsoever
resulting from the use or misuse of the Template, the loss of use, data, or profits, whether in
an action of contract, negligence, or other tortious action arising out of or in connection with
the Template shall be born exclusively by the user.

Copyright 2011-2015, Praxis Management International, LLC praxislifesciences.com

 STANDARD OPERATING PROCEDURE SOP No.: __
TITLE: Computer System Validation
Dept: Effective Date: Version PAGE
1.0 2 OF 15

Contents
PURPOSE.............................................................................................................3
SOP SCOPE......................................................................................................... 3
DEFINITIONS........................................................................................................3
RESPONSIBILITIES.............................................................................................4
PROCEDURES..................................................................................................... 5
System Life Cycle .............................................................................................................. 5
Validation Framework......................................................................................................... 6
Standard Validation Deliverables........................................................................................6
Risk Based Validation Approach......................................................................................... 10
Validation Deliverable Approvers........................................................................................11
Documentation Retention................................................................................................... 12
Personnel............................................................................................................................ 13
REFERENCES....................................................................................................14

Copyright 2011-2016, Praxis Management International, LLC praxislifesciences.com

 STANDARD OPERATING PROCEDURE SOP No.: __
TITLE: Computer System Validation
Dept: Effective Date: Version PAGE
1.0 3 OF 15

PURPOSE

The purpose of this Standard Operating Procedure (SOP) is to define the procedures,
responsibilities, and controls for validation of computerized systems to ensure quality, reliability,
and conformance with regulatory requirements.

SOP SCOPE

This SOP applies to computerized systems where one or more of the following conditions are
met:
 Software or system is used as a medical device or as a component, part, or accessory of
a medical device
 Software or system is used in the production of a regulated product
 Software or system is used in implementation of the quality system as defined in
predicate rules
 System or software creates, modifies, maintains, backs up, restores, transfers, migrates,
archives, retrieves, or transmits records required by predicate rules
 System or software submits electronic records to a regulatory agency, even if such
records are not specifically identified in agency regulations

Applications built with off-the-shelf packages:

 Applications built with any industry-common off-the-shelf packages such as word
processors and spreadsheets require validation; however, the underlying off-the-shelf
packages and operating systems do not require independent validation.
 The application shall be re-evaluated and re-validated as necessary when the off-the-
shelf package or underlying operating system is upgraded or modified.
 Output of word-processors, spreadsheets or other applications do not require validation
when the output is subsequently subject to 100% human review, verification, and
approval.

Testing Tools:
 Testing tools used to validate applications or systems require validation in order to
ensure their reliability.

DEFINITIONS

Computerized System is a functional unit, consisting of one or more computers and associated
peripheral input and output devices, and associated software, that uses common storage for all
or part of a program and also for all or part of the data necessary for the execution of the
program; executes user written or user-designated programs; performs user-designated data
manipulation, including arithmetic operations and logic operations; and that can execute
programs that modify themselves during their execution. A computerized system may be a
stand-alone unit or may consist of several interconnected units.

Computer System Validation is the establishment of documented evidence that provides a high
degree of assurance that a specific system will consistently produce a product meeting its
predetermined specifications and quality attributes.

Copyright 2011-2016, Praxis Management International, LLC praxislifesciences.com

 STANDARD OPERATING PROCEDURE SOP No.: __
TITLE: Computer System Validation
Dept: Effective Date: Version PAGE
1.0 4 OF 15

Predicate Rules are the regulations that govern the process that is computerized or automated
(e.g., 21 CFR 820, 21 CFR 211, Eudralex Volume 4).

The Project Team is a group of qualified individuals appointed to design and implement the
validated computer system.

RESPONSIBILITIES

The Validation Committee is responsible for

 Overseeing validation activities.
 Determining whether or not to authorize the system for production use.
The Validation Committee shall be comprised of the System Owner and management members
from Information Technology and Quality Assurance.

The Quality Assurance Manager and staff are responsible for

 Ensuring that the system meets the regulatory requirements for software validation, and
that the company will be able to respond to any compliance audit.
 Working with System Users and Information Technology to systematically plan the
activities necessary to ensure that a component, module, or system conforms to
established business, technical, and compliance requirements.
QA shall operate independently from Information Technology and System Users.

The System Owner and Users are responsible for

 Clearly specifying and communicating the intended business use and operation of the
system.
 Using and operating the validated system within their business and functional areas.

The Information Technology Manager and staff are responsible for

 Designing, developing, deploying, and maintaining computerized systems in support of
the System Users in such a manner that the computerized systems are reliable and
trustworthy.

o The IT Manager shall oversee all activities performed by the Information

Technology organization.
o The Systems Analyst shall work with the System Users to develop and document
system requirements, work with developers to translate requirements into system
capabilities, and work with testers to ensure that the Users’ requirements have been
fulfilled and function as expected.
o The Developer shall build system capabilities to fulfill requirements and ensure that
the system performs as specified.

The Project Manager shall manage the project’s timeline, budget, and resources. The project
manager may be staffed from either the Information Technology or the System User
organization.

Copyright 2011-2016, Praxis Management International, LLC praxislifesciences.com

 STANDARD OPERATING PROCEDURE SOP No.: __
TITLE: Computer System Validation
Dept: Effective Date: Version PAGE
1.0 5 OF 15

The Lead Tester shall define the testing strategy and manage testing activities. The lead tester
may be staffed from either the Information Technology or the Quality Assurance organization.

PROCEDURES

System Life Cycle

Computerized Systems shall be managed according to a life cycle which includes the following
phases and activities. For additional system life cycle details, see SOP Software Development
Life Cycle for Package Software, and SOP Software Development Life Cycle for Custom
Development.

Phase Example Activities

Project planning, validation planning, risk assessment and mitigation
Planning
planning
Requirements User requirements definition, functional requirements definition,
Analysis prototyping
Data design, architecture design, configuration design, interface design,
Design
vendor selection
Construction/
Coding, configuration, software purchase, hardware purchase
Purchase
Unit testing, code walkthroughs, integration testing, validation protocol
Testing
execution
Installation, training, data conversion, user procedures, support
Deployment
procedures
Operation and Change control, incident management, enhancements, modifications,
Maintenance version upgrades, back-ups, data archival, documentation updates
Decommissioning Data retention, system retirement

Copyright 2011-2016, Praxis Management International, LLC praxislifesciences.com

 STANDARD OPERATING PROCEDURE SOP No.: __
TITLE: Computer System Validation
Dept: Effective Date: Version PAGE
1.0 6 OF 15

Validation Framework
This model provides a framework for validation activities and identifies the relationship between
requirements activities and corresponding verification activities.

Standard Validation Deliverables

1. Computerized systems shall be developed using a methodology that ensures that validation
deliverables are developed in a logical and predictable manner. The validation deliverables
may be developed sequentially or iteratively.

2. The Project Team is responsible for producing the following validation deliverables:

2.1 Validation Master Plan

2.2 Change Request
2.3 User Requirement Specification
2.4 Functional Requirement Specification
2.5 System Risk Assessment
2.6 Vendor Assessment
2.7 Validation Plan
2.8 System Design Document
2.9 Testing Plan
2.10 Code Review Reports
2.11 Unit Test Results
2.12 Validation Protocols
2.12.1 Installation Qualification
2.12.2 Operational Qualification

Copyright 2011-2016, Praxis Management International, LLC praxislifesciences.com

 STANDARD OPERATING PROCEDURE SOP No.: __
TITLE: Computer System Validation
Dept: Effective Date: Version PAGE
1.0 7 OF 15

2.12.3 Performance Qualification

2.13 Validation Incident Reports
2.14 Trace Matrices
2.14.1 User Requirements Specification to Functional Requirements Specification
2.14.2 Functional Requirements Specification to System Design
2.14.3 Functional Requirements Specification to OQ
2.14.4 User Requirements Specification to PQ
2.15 21 CFR Part 11 Compliance Assessment
2.16 Testing Summary
2.17 Validation Summary
2.18 Deployment Plan
2.19 Data Conversion Plan
2.20 System SOPs and Guidelines
2.21 System Source Code
2.22 System Executable Version
2.23 Decommissioning Plan

2.1. The Validation Master Plan describes the overall validation program and includes the
validation scope, schedule, methodology, and responsibilities for all computerized
systems.

2.2. The Change Request (CR) is the first document of a project. The CR describes the
change, documents the assessment of the impact of the change, and records the
authorization for a project to begin or a change to be made.

2.3. The User Requirements Specification (URS) is a documented set of conditions or

capabilities to be met or possessed by a system to enable a user to solve a business
problem or achieve an objective. The format is open, but these requirements must be
documented with a nomenclature that permits the Trace Matrices to link specific
elements of the User Requirements Specification with the elements of the Functional
Requirements Specification and PQ Validation Protocols.

2.4. The Functional Requirements Specification (FRS) is the documented specification that
describes in a complete, precise, and verifiable manner, the requirements, design,
behavior, or other characteristics of a system or component. These requirements must
also be documented with a nomenclature that permits the traceability to the User
Requirements, the System Design and the OQ Validation Protocols.

2.5. The System Risk Assessment is a document that defines the type and level of risk that
various components of a computerized system pose to patient safety. The results of
the risk assessment are utilized to determine a vendor assessment strategy and risk-
based validation approach.

2.6. The Vendor Assessment is a summary of the assessment conducted by the company of
each vendor supplying software components to the system. Vendors must be assessed
for their methodology and quality practices as well as for 21 CFR Part 11 compliance.

Copyright 2011-2016, Praxis Management International, LLC praxislifesciences.com

 STANDARD OPERATING PROCEDURE SOP No.: __
TITLE: Computer System Validation
Dept: Effective Date: Version PAGE
1.0 8 OF 15

2.7. The Validation Plan is a document produced after requirements have been defined and
(where applicable) the vendor assessment has been performed. It describes the
project’s validation deliverables, testing process, schedule, and acceptance criteria.
The Validation Plan defines who is responsible for creating, reviewing and approving
each validation deliverable.

2.8. The System Design Document is a document that describes in words and pictures the
system’s hardware infrastructure, network architecture, database design and
architecture, interface design, software functionality, software configuration, and any
other important technical aspects. For complex systems, the system design may be
encompassed in multiple documents, e.g., System Architecture Design Document,
Software Design Document, System Configuration Specification.

2.9. The Testing Plan describes the strategy for formally testing the system. It includes a
description of the process for defining and writing tests as well as the plan for
conducting and documenting the test execution.

2.10. The Code Review Reports are documented records of the walkthrough of the source
code to ensure that it conforms to requirements and meets quality levels defined in
the coding standards. Code reviews are conducted by the author of the code and at
least one other qualified person.

2.11. The Unit Test Results are documented evidence that the functionality of each of the
system components was tested by the developers as it was developed.

2.12. The Validation Protocols are the testing scripts that establish confidence that the
system will consistently operate within established limits, tolerances and performance
levels. The step-by-step process of executing each test must be documented, and
the expected results of each test must be predefined. The validation protocols must
be pre-approved before execution of the tests. Tests must be executed on either the
version of the system intended to be the final production system, or on an identical
copy. Test results must be documented. Each test protocol must be reviewed and
approved after execution.

2.12.1. The Installation Qualification (IQ) provides documented verification that the
hardware, operating system, configuration, and any software set up conditions
have been installed as documented in the System Design Document. The
system’s pre-approved IQ document will be used during installation of every
instance of the system.

2.12.2. The Operational Qualification (OQ) establishes confidence that the system will
consistently operate within established limits, tolerances and performance
levels. Each functional requirement of the system must be adequately tested;
protocols should include testing of boundary conditions and sophisticated
calculations. The OQ is performed after the IQ to ensure that the system
works as expected on the specific hardware infrastructure.

2.12.3. The Performance Qualification (PQ) establishes confidence that the system is
suitable for the intended business use. Each user requirement of the system

Copyright 2011-2016, Praxis Management International, LLC praxislifesciences.com

 STANDARD OPERATING PROCEDURE SOP No.: __
TITLE: Computer System Validation
Dept: Effective Date: Version PAGE
1.0 9 OF 15

is adequately tested; protocols should include intended uses of the system.

The PQ should be performed after the IQ and OQ to verify user acceptance of
the system. The PQ is executed either in the actual production system or on
an identical image (i.e., a validation environment).

2.13. Validation protocol failures and other incidents detected during the validation process
are documented on Validation Incident Reports. These reports also are also used to
record the associated impact assessment, regression testing, and resolution of the
incident.

2.14. The Trace Matrices are mappings between two lists of items which confirm that all
items of the first list relate to at least one item of the second list, and vice-versa. The
purpose of trace matrices are to confirm completeness and to ensure that there are
no gaps or overlooked items in either list. Trace matrices should be documented for
the following pairs of items:

2.14.1. User Requirements Specification to Functional Requirements Specification

2.14.2. Functional Requirements Specification to System Design
2.14.3. Functional Requirements Specification to OQ
2.14.4. User Requirements Specification to PQ

2.15. The 21 CFR Part 11 Compliance Assessment is a document that describes each Part
11 requirement and provides verification of the system’s compliance with each
requirement.

2.16. The Testing Summary is created after the entire Testing Plan has been executed.
This document provides a report of the testing methodology, activities, results,
validation incident reports, and incident resolutions.

2.17. The Validation Summary Report is produced after all other validation deliverables are
produced and approved. It provides verification that all of the activities and
deliverables defined in the Validation Plan have been completed and the acceptance
criteria defined in the Validation Plan has been met. The approval of the Validation
Summary Report authorizes the system for production use.

2.18. The Deployment Plan describes the process of deploying the finished system.
Contents including plans for training users, transitioning from the existing system to a
new system, and the procedures for any intermediary time span.

2.19. The Data Conversion Plan describes the process of loading static data values into the
new system and moving existing data from an old system into the new system. The
Data Conversion Plan describes the data load activities, timing, and responsibilities.

2.20. The SOPs include all the procedures needed to maintain, support, and use the
system. SOPs include topics such as electronic signature use, training, user access
management, back-ups, recovery, incident management, periodic maintenance, and
user operation.

Copyright 2011-2016, Praxis Management International, LLC praxislifesciences.com

 STANDARD OPERATING PROCEDURE SOP No.: __
TITLE: Computer System Validation
Dept: Effective Date: Version PAGE
1.0 10 OF 15

2.21. The System Source Code is a permanent archive in electronic format of all source
code used to produce the executable application. It must include all libraries,
compilers, or other tools and components that would be necessary to recreate the
identical executable object(s).

2.22. The System Executable Files are a permanent archive of the executable application.
They must include any installation or configuration software necessary to re-install the
application.

2.23. The Decommissioning Plan documents the approach to retiring a validated system.
This document includes the plan for retention and/or destruction of software,
hardware, data, source code, system documentation, SOPs and guidelines, and
training material.

1. The project team is responsible for keeping all system documentation up-to-date
for each version of the system and during maintenance periods in between
versions.

2. All validation deliverables will be subject to version control processes by which all
modifications are documented and approved and all previously-approved versions
are maintained.

Execution of Validation Activities

The diagram below represents a typical sequence of validation activities. The planned
sequence of activities can vary for each validation project and must be documented in the
Validation Plan.

For small validation projects, the validation deliverables can be merged. Decisions to merge
deliverables must be documented in the Validation Plan. Merge examples:
 URS and FRS
 IQ and OQ
 OQ and PQ
 Trace Matrices
 Validation Plan and Testing Plan

Copyright 2011-2016, Praxis Management International, LLC praxislifesciences.com

 STANDARD OPERATING PROCEDURE SOP No.: __
TITLE: Computer System Validation
Dept: Effective Date: Version PAGE
1.0 11 OF 15

 Testing Summary and Validation Summary Report

For commercial off-the-shelf (COTS) systems, vendor supplied documents can be leveraged as
validation deliverables when the vendor has passed a Vendor Assessment.
 Examples of vendor supplied documents include Functional Requirements
Specifications, Operational Qualifications, and Trace Matrices.
 Vendor supplied validation deliverables shall be reviewed and signed per the approval
matrix in section Validation Deliverable Approvers.

Risk Based Validation Approach

The approach to validation of computerized systems shall be commensurate with the level of
risk associated with the intended use of the software and the degree of software complexity.
For details, see SOP System Risk Assessment and SOP System Risk-Based Validation.

Deviation or variation from the standard list of validation deliverables, is allowed, dependent on
system risk and complexity, and must be

 described in the Validation Plan

 approved by the Validation Committee.

Copyright 2011-2016, Praxis Management International, LLC praxislifesciences.com

 STANDARD OPERATING PROCEDURE SOP No.: __
TITLE: Computer System Validation
Dept: Effective Date: Version PAGE
1.0 12 OF 15

Validation Deliverable Approvers

The sign-offs for the validation deliverables shall be obtained based on the following table. The
‘X’s in the columns indicate required approvers.

Validation Quality IT System Project Lead Systems

Developer
Committee Assurance Manager Owner Manager Tester Analyst
Validation Master Plan X X X X
Change Request X X X X
Project Plan X X X X
User Requirements
X X X
Specification
Functional
Requirements X X X X
Specification
System Risk
X X X X
Assessment
Vendor Assessment X X X X
Validation Plan X X X X X
System Design
X X
Document
Testing Plan X X X X X
Code Review Reports X X X
Unit Test Results X X
Validation Protocols X X X X
Validation Incident
X X X X
Reports
Testing Summary X X X X
Trace Matrix
X X
– URS to FRS
Trace Matrix
X X X
– FRS to Design
Trace Matrix
– FRS to Validation X X X
Tests
21 CFR Part 11
Compliance X X X
Assessment
Validation Summary X X X X X
Deployment Plan X X X
Data Conversion Plan X X X
Installation Qualification X X X
Operational
X X X X
Qualification
Performance
X X X X
Qualification
System SOPs X X X
Decommissioning Plan X X X X
NOTE: A person can fulfill more than one of the roles in this table. However, the System Owner, IT Manager, and
QA Representative must be different people.

Copyright 2011-2016, Praxis Management International, LLC praxislifesciences.com

 STANDARD OPERATING PROCEDURE SOP No.: __
TITLE: Computer System Validation
Dept: Effective Date: Version PAGE
1.0 13 OF 15

Documentation Retention

1. The validation deliverables shall be retained for the same period of time as the associated
electronic records generated by each system.

2. The validation deliverables shall be retained in a format and location that is readily available
for future reference and inspection by regulatory agencies and other appropriate parties.

Procedures and Controls

The following processes shall be in place for each validated system to ensure that it remains in
a controlled, validated state. These controls will be documented in one or more SOPs.

Control
Description
Element
A documented process, which defines
Access  training requirements for each user access level
Control  method of requesting and approving access
 method of periodically auditing system access
A documented process, by which system changes are
 proposed and recorded
Change
 evaluated and assessed to identify the impact to system documentation and
Control
the extent of re-validation
 approved or rejected
A documented process for
 identifying and defining configuration items in a computerized system
Configuration
 controlling the release and change of these items throughout their lifecycle
Control
 recording and reporting the status of items and change requests
 verifying the completeness and correctness of items.
A documented process for system documentation generated throughout the
System Life Cycle defining
Documentation  retention schedules
Control  means of access
 review and approval requirements
 version identification
A documented process for software that defines
 retention schedules
Data/Record
 back-up and restoration
Control
 disaster recovery
 archival and restoration
A documented process for software that defines
 retention schedules
Software
 back-up and restore
Control
 disaster recovery
 maintenance requirements
Incident A documented process to
Management  report and record
 track status

Copyright 2011-2016, Praxis Management International, LLC praxislifesciences.com

 STANDARD OPERATING PROCEDURE SOP No.: __
TITLE: Computer System Validation
Dept: Effective Date: Version PAGE
1.0 14 OF 15

Control
Description
Element
 resolve unexpected events

Personnel

All resources involved in the design, construction, testing, validation and deployment of the
computerized system shall be qualified and adequately trained to fulfill their roles.

 A record of these qualifications and training will be stored with the project
documentation.

Copyright 2011-2016, Praxis Management International, LLC praxislifesciences.com

 STANDARD OPERATING PROCEDURE SOP No.: __
TITLE: Computer System Validation
Dept: Effective Date: Version PAGE
1.0 15 OF 15

REFERENCES

General Principles of Software Validation; Final Guidance for Industry and FDA Staff, FDA,
January 11, 2002

Guidance for Industry: Computerized Systems Used in Clinical Investigations, FDA, May,
2007

Glossary of Computerized System and Software Development Terminology, FDA, April 30,
2003

Guidance for Industry: Part 11, Electronic Records; Electronic Signatures – Scope and
Application, FDA, August 2003

21 CFR Part 11, Electronic Records; Electronic Signatures, Federal Register Vol. 62, No.
54, 13429, March 20, 1997

Volume 4, Annex 11, Computerised Systems, Eudralex, 2011

Copyright 2011-2016, Praxis Management International, LLC praxislifesciences.com