The complexity of processes, management of data, and its repeated use are the driving forces for the automation of processes using computerized systems. The systems have the advantages of online data creation, review, approval, archival, retrieval, storage, and utilization and help to reduce the overall resources required for paper-based data management.

Correctness in operation and performance of these computerized systems becomes an important consideration since they manage the processes and will directly or indirectly impact consistency, reliability, accuracy of data, product quality, patient safety, and data integrity.

The compliance of these systems to GxP and regulatory requirements can be assured only if a life cycle approach is planned for systematic and documented planning, development, validation, implementation, and post-implementation activities.

This master plan and the attachments shall be used as a framework for the life cycle approach for managing computerized systems.

Protocol Content

  • Approval sheet
  • Introduction
  • Objective
  • Computerized Systems Validation Policy
  • Scope
  • Definitions
  • Role and responsibilities
  • Identification And Categorization of Computerized Systems
  • Validation Strategy and Deliverables
  • Supplier Assessment
  • Quality Risk Management
  • Validation Requirements
  • Documentation
  • Change Control
  • Training
  • Maintenance and Support
  • Document Completion Procedure
  • System Retirement
  • Project Activities Monitoring, Controlling and Reporting
  • References
  • Annexure
  • Abbreviation
  • Revision History

OBJECTIVE: The Objective of this policy is to :

  • Provide directives to develop the individual Electronic System Plan.
  • Generate Records to provide evidence of complying with regulatory requirements.
  • To ensure that the System is fit for the intended use.
  • To identify and define roles and responsibilities of key individuals during the acquisition, development, validation, and deployment process; and Spread awareness to the audience on the various aspects of acquisition, development, validation, and deployment of electronic systems.

COMPUTERIZED SYSTEMS VALIDATION POLICY: The Computerized Systems Validation Policy specifies that,

  • This Policy is owned by the Head-Quality;
  • All electronic systems, procured or developed shall adhere to this policy;
  • Any exception or deviation from this policy needs to be documented and approved.
  • Computerized systems validation is important to ensure compliance with regulations and to achieve business benefits;
  • Management supports computer system validation as a business-critical activity;
  • All systems within the scope used in regulated environments shall be validated. The extent of validation shall depend on the risk, that the system has on Product Quality, Patient Safety, Data confidentiality, Data Integrity, and Business Continuity and shall also depend on the type and complexity of the system;
  • Validation Team shall include personnel from various disciplines based on the use of the system;
  • A based approach can be taken to optimize and focus overall efforts toward the Computer system validation process; 

SCOPE: This policy is applicable for computer system validation at ______________________ The Computerized System Validation Master Plan applies to all computerized systems that are used to perform and support GxP-regulated activities. Consequently, there may be systems, whose operation, although important for the efficient and economic operation of the facility, cannot be considered critical to the quality of the product and therefore will not be validated as part of this activity.


  • Qualification: Qualification is the act of planning, executing, and recording of tests on equipment and systems, which form part of the validated process, to demonstrate that it works correctly and leads to the expected results.
  • User Requirement Specification (URS): A requirement specification that describes what the equipment or system is supposed to do, thus containing at least a set of criteria or conditions that have to be met.
  • Functional Specification (FS): Specifications that document functions, standards, and permitted tolerances of systems or system components and which define the operating capabilities of the equipment/ system.
  • Design Specification (DS): Systems design is the process of defining the architecture, components, modules, interfaces, and data for a system to satisfy specified requirements.
  • Installation Qualification (IQ): Installation qualification is a documented verification that the systems as installed or modified, comply with the approved design and manufacturer’s recommendation.
  • Operational Qualification (OQ): Operational qualification is functional testing to ensure that each component of a system performs as intended within the representative/ anticipated operating ranges according to Functional specification.
  • Performance Qualification (PQ): Performance qualification confirms that the system is capable and performing/controlling activities of the processes as intended according to URS in a reproducible manner while working in a specified operating environment, which includes hardware arid software of the computer system.
  • Validation Protocol: The validation protocol is a written plan, stating how validation will be conducted, with roles and responsibilities of the validation team, deliverables including test parameters, system characteristics, device checks, and decision points on what constitutes acceptable test results.
  • Validation Report: The validation report is a written report on the validation activities, the validation data, and the conclusions drawn.
  • Re-validation: Repeated validation of an approved system (or a part thereof) to ensure continued compliance with established requirements.
  • Risk Management: A systematic process for the assessment, control, communication, and review of risk to quality.
  • Risk Assessment: It is a systematic method to assess and characterize the critical parameters in the functioning of a system.
  • Computer System: A computer is a device that accepts information in the form of digitalized data and manipulates it for some result based on a program or sequence of instructions on how the data is to be processed. A system including input of data, electronic processing, and output of information to be used either for reporting or automatic control.
  • Computerized System: A computerized system consists of hardware, software, and network components which together fulfill certain functionalities. It can also be defined as a logical entity partially or entirely controlled by computers but may also include some equipment, utilities, sensors & actuators along with the governing procedures. For example Building Management System; Automated manufacturing / Laboratory System; Document Management System; etc.
  • Computerized System Validation: It is a process of achieving and maintaining compliance with applicable GxP regulations and fitness for the intended use of computerized systems.
  • Commercial Off-the-Shelf Software (COTS): Software defined by a market-driven need, commercially available, and whose fitness for use has been demonstrated by a broad spectrum of commercial users.
  • Electronic Signature: A computer data compilation of any symbol or series of symbols executed, adopted, or authorized by an individual to be the legally binding equivalent of the individual’s handwritten signature.
  • Electronic Records: Any combination of text, graphics, data, audio, pictorial, or other information representation in digital form that is created, modified, maintained, archived, retrieved, or distributed by a computer system.
  • Open Systems: An environment wherein system access is not controlled by person/s, responsible for the content of electronic records on the system.

An open system is a system that allows application portability, system interoperability, and user portability between many different computer vendor hardware platforms. A closed system is vice-versa to the above.

  • Closed Systems: An environment wherein system access is controlled by person/s, which are responsible for the content of electronic records on the system.
  • Configured System: Configured systems are those that consist of standard system components and that enable configuration as per user requirement (the basic software is coded for general purpose and not as per specific customer requirement).
  • Bespoke Systems / Customized Systems: Customized systems are those systems that consist of system components that are developed to meet the specific needs of customers.
  • Legacy System: Legacy systems are regarded as systems that have been established and in use for some considerable time.
  • GxP Regulation: The underlying international pharmaceutical requirements, such as those outlined in the US FD&C Act, US PHS Act, FDA regulations, EU Directives, Japanese regulations, or other applicable national legislation or regulations under which a company operates. These include but are not limited to:
  • Good Manufacturing Practices (GMP)
  • Good Laboratory Practices (GLP)
  • Good Distribution Practices (GDP)
  • Good Engineering Practices (GEP)

GxP Compliance: Meeting all applicable pharmaceutical and associated life ­science regulatory

Network: A system (transmission channels and supporting hardware and software) that connects several remotely located, computers via telecommunications and allows information and resource sharing (hardware and software) between different computers along with data transfer to distributed workstations.

Examples: Personal Area Network, Local Area Network, Wireless Local Area Network, Wide Area Network.


A specific organizational structure is responsible for the proper distribution of work to achieve the validation target. Following roles and responsibilities shall be followed by individuals and teams in the validation process.

Validation team:

This team shall comprise members from the following and/or as required.

System Owner/User Department, Quality Assurance, Information Technology, Engineering, System provider, and/ or Outside validation agency.

Responsibility of System Owner/User

  • Ensuring that all software and computer systems in the department are listed in the list.
  • Managing change control and escalating issues where necessary.
  • Ensuring that all systems in the department are validated according to the project plan/ Validation plan.
  • Ensuring that QA and IT are notified before the purchase of new systems.
  • Providing a detailed and complete set of requirements in a documented form.
  • Providing resources for functional and performance testing
  • Preparation/ Review of validation protocol/ report
  • Providing user expertise inputs in the creation and review of validation deliverables.
  • Ensuring that SOPs are developed covering the use of the system and contingency situations and system recovery in case of system failure.
  • Ensuring adequate training for the users.

Role of Engineering: Responsible for the following activities related to Process Control Systems:

  • Managing validation/project deliverables in line with the project plan.
  • Managing project scope and change control and escalating issues where necessary.
  • Preparation/ Review of validation protocol/ report
  • Ensuring the availability of information for the system inventory and configuration management.
  • Providing adequate resources to support the system validation.
  • To witness Qualification activity.
  • Reviewing assessment/audit reports, responding to findings, and taking appropriate actions to ensure GxP compliance.
  • Assist during Testing and Manage hand-over of completed Projects.

Role of Quality Assurance:

  • Review and approval of procedures and other validation deliverables
  • Providing Quality Assurance and Regulatory expertise.
  • Developing training material and delivering training on regulations and corporate standards.
  • Auditing computer systems together with the system owner for compliance with procedures.
  • Release of the computerized system for use in a live environment.

Role of Project Team

Members shall come from all departments affected by the system, As a minimum requirement, representation is necessary from the users, Quality Assurance, and Information Technology For each team member, a backup shall be identified, mitigating the risk of unavailability of core members. A list of core members and the backup shall be created and maintained with the system owner. The Project team members shall represent their departments.

  • Attend all team meetings or arrange for a substitute.
  • Collect and provide inputs for risk assessment.
  • Reviewing project plans
  • Developing and reviewing procedures.
  • Reviewing test and validation protocols and other validation deliverables.

Role of IT Department:

  • Overall technical responsibility for the project.
  • Lay down specifications for software, hardware, and computer systems.
  •  Assisting the team in identifying and selecting system vendors.
  • Maintaining hardware and software inventory for computer systems.
  • Qualifying the infrastructure.
  • Providing technical expertise for risk assessment for networked and ‘interfaced systems.
  • Preparation and review of documentation for network infrastructure.
  • Developing and maintaining security controls.
  • Coordination with Vendors for support and maintenance
  • Setting up controls for server access to user groups and vendors.

Role of Supplier:

  • Suppliers can be vendors of commercial systems, companies that develop software on a contract basis, internal software development resources, or a combination of the three categories.
  • Responsibilities include developing software and computer systems according to documented procedures.
  • Provide documented evidence that the software has been developed in a Quality Assurance environment and tested during development.
  • Allowing users to audit the development process or the testing process.
  • Developing and providing functional specifications for the software and computer system.
  • Offering services to assist users in specifying, installing, and validating the system.
  • Offering support in case the user has a problem with the system.
  • Informing users on critical software errors and workaround solutions and corrective action plans.
  • Maintaining version control of the code.
  • Informing users on new versions, For example, what is new and how the change can impact the validation state impact the validation state.

Role of Validation Agency (if any)

  • To provide third-party validation services
  • Preparation of Validation Plan, if required
  • Preparation of Risk Assessment Plan
  • Carrying Functional Risk Assessments
  • Developing and executing Installation/Operational Qualification & Performance Qualification (wherever required) Protocols for Process Control Systems.
  • To provide a Validation Summary Report and Requirement Traceability Matrix for Process Control Systems.
  • Their individuals and groups shall be identified, as necessary, by the Process or system owner, to assist in various activities where their area of expertise will facilitate the development and execution to assure the quality of the validation effort. A person can be utilized in more than one role listed above as per requirement.


Identification of Computerized Systems:

A list of Computerized Systems including legacy systems that are used or planned to be used at individual units shall be prepared. The list shall be prepared. The list shall include necessary information of the system like Name of the System, version number, Location, Application or Use, Criticality i.e. GxP / Non-GxP and Remarks, if any. GxP / Non GxP part shall be entered in the list after assessment of the system.

System Criticality Assessment:

All systems shall be assessed at the initial stage of the project to decide whether it is Quality Critical, Business Critical, or has no impact on Quality or Business. The assessment team shall essentially include members from various disciplines like Process Owner, System Owner, User department, IT, Engineering, and Quality Assurance. Another member may be included as required. The Assessment can be done. After the assessment, a conclusion shall be drawn to identify that the system belongs to one of the following two categories:

GxP System: Quality and Business Critical System

The systems can be termed as GxP System when it tails under any of the   following areas;

  • The system has an impact on patient safety product quality and data
  • The system is used for performing and supporting GxP-regulated
  • The system maintains and supports business-critical information.

Non GxP System: The system can be termed as non GxP system when it tails in all the following areas;

  • The system does not have an impact on patient safety product quality and data integrity.
  • The system is not used for performing and supporting GxP-regulated
  • The system does not maintain and support business-critical information.

GAMP 5; System Categorization: All GxP systems shall further be categorized as per GAMP 5. For complex systems, separate categorization may be carried out for different component modules.

Software Category (As per GAMP 5):

Category 1: Infrastructure Software:

Infrastructure elements are linked together to form an integrated environment for running and supporting applications and services, i.e. software used to manage the operating environment.

For example; Operating Systems, Database engines, Programming languages, etc.

Category 3: Non-Configured Products:

This category includes off-the-shelf products used for business purposes. It includes both, systems that cannot be configured to conform to business processes and systems that are configurable but for which only the default configuration is used.

For example; firmware-based applications, COTS, Instruments, etc.

Category 4: Configured Products:

Configurable software products provide standard interfaces and functions that enable the configuration of user-specific business processes. This typically involves configuring predefined software modules.

For example; SCADS, PLC, DCS, BMS, etc.

Category 5: Custom (Bespoke) Applications:

These systems or subsystems are developed to meet the specific needs of the regulated company. Software is custom-designed to suit the business process.

For example; Internally and externally developed IT applications/ process control systems, Custom ladder logic, Custom firmware, etc.

Hardware Category (As per GAMP5):

Category 1: Standard Hardware Component

These are standard commercially available hardware components and no customization is made.

Category 2: Custom Built (Bespoke) Hardware Component

These are hardware components that are configured on standard hardware or customized as per requirement.

The following decision tree can be used as a guide in determining the applicability of computer system validation to a particular computerized system;


Validation of computer systems shall be carried out to ensure that all computer systems within the organization are developed, installed, and implemented systematically, performing as intended, and ensuring that the systems are being maintained in a state of control throughout the life cycle in compliance with applicable GxP regulations.

Computer systems that are integrated with equipment for control, monitoring, operation, and/or recording shall be qualified along with the equipment qualification to have a complete operational and performance check.

GAMP Category

Software Type : Infrastructure Software (Layered software, Software used to manage the operating environment)


  • Operating systems
  • Database engines
  • Middleware
  • Programming languages
  • Statistical packages
  • Network monitoring tools
  • Scheduling tools
  • Version control tools

Suggested Validation Approach: Record the Version (including the service pack), and verify the correct installation by following the approved installation procedure.

Software Type: Non-configured Software (Run-time parameters may be entered and stored, but the software cannot be configured to suit the business process)


  • Firmware-based applications
  • COTS
  • Instruments

Suggested Validation Approach

  • Abbreviated Lifecycle approach
  • URS
  • A risk-based approach to supplier assessment
  • Record the version (and configuration of the environment) and verify the correct installation.
  • Risk-based tests against requirements as dictated by use (for simple systems regular calibration may substitute for testing)
  • Procedures in place for maintaining compliance and fitness for the intended use.

Software Type : Configurable Software Packages (Software, often very complex, that can be configured by the user to meet the specific needs of the user’s business process, software code is not altered)


  • DAS
  • PLC
  • DCS
  • BMS or EMS

Suggested Validation Approach

  • Life cycle approach
  • A risk-based approach to supplier assessment.
  • Record version number, verify correct installation
  • Risk-based testing to demonstrate applicable works as designed in a test environment and within the business process.
  • Procedure in place for maintaining compliance and fitness for the intended use.
  • Procedures in place for managing data.

Software Type Custom (Bespoke) Software (Software custom-designed and coded to suit the business process)


  • Internally and externally developed IT applications/ process control systems
  • Custom ladder logic
  • Custom firmware

Suggested Validation Approach

  • Same as configurable, in addition:
  • More rigorous supplier assessment.
  • Possession of full life cycle documentation
  • Design and source code review

Life Cycle Model

The validation for the process control system shall be carried out as per GAMP 5 guidelines using the system implementation life cycle approach (defining activities in a systematic way from understanding requirements to system retirement). The validation documentation shall cover the life cycle management approach for all process control systems.

The validation exercise will follow the typical ‘V’ diagram approach as advocated by GAMP 5.

This model comprises User Requirement Specifications (URS), Functional Specifications (FS), Configuration or Design Specifications (DS), configuration testing of code, Installation Qualification (IQ), and Operational Qualification (OQ).

The model suggests that after the completion of the first validation exercise, the Process Control systems shall be governed by a formal change control process during the operation phase. All changes shall follow the ‘V’ model depending upon the impact assessment. After completion of use of the system, the same will be retired following a defined retirement plan.

Validation using approved validation protocol and reports shall also be performed for software and programs where calculations are carried out. For example, calculation of Standard deviation, Mean, Minimum and Maximum value, Relative standard deviation, Weight variation programs calculation of percentage, etc.

The revalidation shall be done if there is any revision or updation of software. Such programs and files shall be individually password-protected for regular usage. The following validation strategy shall be adopted for the GxP Systems:

Validation deliverables shall include the requirement specifications, Qualification and validation protocols, risk assessment and strategies for contingency planning, data back­up, and system security along with others stated in the next point. For GxP systems, all deliverables shall be listed at the initial stage of the validation plan and verified for completeness and correctness after completion of all activities.

The depth and scope of the validation depends on the category of the System components and the complexity & criticality of the application. If any of these deliverables are not considered in the validation cycle, the same shall be justified. 

For GxP System:

For New Systems: Based on risk assessment, criticality, and category of the hardware, software, and other components of the system, a Qualification and Validation strategy shall be developed. The strategy and deliverables shall typically be as follows:

  • Proposal and Approval of Change
  • Validation Plan (CSVMP shall be considered as validation plan)
  • Risk Assessment at various stages of the life cycle.
  • Training Plans and Training documentation at various stages
  • Supplier Assessment/ Supplier Agreement
  • User Requirement Specification
  • Traceability Matrix
  • GxP Assessment
  • Functional Design Specification
  • Installation Qualification
  • Operational Qualification
  • User Manuals, and training guides from Vendor.
  • SOPs for the Usage, maintenance, backup, business continuity plans
  • Performance Qualification
  • Post Implementation review
  • Periodic review or verification

For Legacy Systems: Validation of, in-use legacy systems shall follow the same principles as new systems with some exceptions. Any updation to legacy systems shall follow the change control procedure and the validation strategy of the new systems.

For Non-GxP System: The Validation strategy for non-GxP system shall be decided by the Project Team and Users. However, the minimum requirements to be followed are

  • User Requirement Specification
  • User Acceptance test
  • Training
  • Standard Operating Procedures

SUPPLIER ASSESSMENT: Supplier assessment is aimed to assess the computing environment, technology used and quality management system followed to develop the proposed system is adequate and to ensure that the proposed system components conform to the Quality Requirements defined by the organization.

  • The company shall consider formally assessing each supplier of GxP’s regulated computerized systems and services.
  • Typical supplier assessment activities include but are not limited to:
    • Verification of supplier history.
    • Collection of industry feedback.
    • Assessment through Questionnaire (postal audit) or Vendor audit (site audit).
  • Typically, a basic assessment is sufficient for lower-impact systems, while higher-impact systems may require formal audits. Postal audits may be appropriate for suppliers of standard and configurable products and services.
  • The competence and reliability of a supplier are key factors when selecting a product or service provider.
  • A formal assessment of the supplier shall be done as per SOP
  • Documentation supplied with commercial off-the-shelf products shall be reviewed by regulated users to check that user requirements are fulfilled.
  • When third parties (e.g. suppliers, service providers) are used e.g. to provide, install, configure, integrate, validate, maintain (e.g. via remote access), modify or retain a computerized system or related service or for data processing, formal agreements must exist between the manufacturer and any third parties, and these agreements shall include clear statements of the responsibilities of the third party. IT departments shall be considered analogous.

QUALITY RISK MANAGEMENT: Risk management shall be applied throughout the lifecycle of the computerized system taking into account patient safety, data integrity, and product quality. As part of a risk management system, decisions on the extent of validation and data integrity controls shall be based on a justified and documented risk assessment of the computerized system.

  • Principle of Risk Assessment: The evaluation of the risk to the quality shall be based on scientific knowledge and ultimately linked to the protection of the patient. The level of effort, formality, and documentation of the Quality risk management process shall be directly related to the level of risk.
  • The five-step risk management process has been designed such that it may be scaled according to the risk, complexity, and novelty of individual systems, with each step of the process building upon the previous output;
  • Risk Management shall be done based on an understanding of the following:
    • Impact of the computer system on Patient Safety, Product Quality, and Data Integrity.
    • Impact of the proposed system on an existing system, procedures, etc.
    • Probability of occurrence
    • User Requirements
    • Regulatory requirements
    • System complexity and novelty.
    • Supplier and system capabilities
  • For tools to be used for risk assessment


    • Validation of the computer system shall be performed according to the validation process.
    • Qualification or Validation can be performed either by a Validation team or by an approved external agency.
    • When the software application meets the following prerequisites, the validation activities for various units and locations can be clubbed together and carried out centrally by ensuring that all variables in the business processes are considered during Performance Qualification.
      • The Application is managed centrally for all sites.
      • It has a single database for all sites
      • The hardware is qualified
      • Network is Qualified
      • The Software application is being used over LAN or web with firewalls for security.

Note: The above requirements may vary case to a case-to-case basis.

  • If the above-listed prerequisites are not met, the validation exercise will be carried out separately (if required).
  • However, training of Users and post-implementation review shall be done through a change control procedure.


The documentation part plays a vital role in the overall life cycle of the Computer system from a user and regulatory perspective. It provides evidence to reviewers and information to end users. The validation documentation and reports shall cover the relevant steps of the life cycle. Manufacturers shall be able to justify their standards, protocols, acceptance criteria, procedures, and records based on their risk assessment.

Validation documentation shall include change control records (if applicable) and reports on any deviations observed during the validation process. It shall be ensured that the system has been developed under an appropriate quality management system.

  • All documents (wherever feasible) shall have unique identification numbers and version control.
  • All documents shall be clear, legible, and well-defined.
  • Change in any validation activity from the initial plan (if any) shall be documented as per the Change control procedure and can be attached as amendments to the respective validation document.
  • Each validation activity executed shall be recorded and signed by individuals and groups involved.
  • Proofs of validation and related activities carried out, such as screenshots, calibration certificates, training records, etc. (where applicable), shall be retained with respective documents.
  • All documents shall be retained as per the Document Data control procedure.
  • The documentation requirements for the deliverables shall be met. If any of the deliverables is not planned for the validation cycle, the same shall be justified in the individual validation plan.

Traceability Matrix: A traceability matrix shall be prepared  (or as per the validation agency document) to ensure that all requirements are met and related documents can be traced immediately throughout the life cycle. The traceability matrix shall ensure the following

  • Requirements are met and can be traced
  • Requirements are verified.
  • Enables easier document identification.

SYSTEM DESCRIPTION: An up-to-date system description detailing the physical and logical arrangements, data flows, and interfaces with other systems or processes, any hardware and software prerequisites, and security measures shall be available. It shall include at least the following contents:

  • Purpose of the System
  • Main System function
  • Regulatory Impact
  • Computing Environment
  • System Component
  • System Interfaces
  • Access and Security Control
  • Actions in case of Failure
  • Electronic Records & Signatures (If applicable)
  • Category of the Computerized System and Justification.
  • Glossary

An updated system description shall be maintained throughout the life cycle of the system.

User Requirement Specification: The User Requirement Specification is a detailed document that is written by the Users and describes the required functions of the computerized system and shall be risk-based and GMP impact-based.

The user requirements specification shall be used as the basis for the development of the system acceptance test procedures {Performance Qualification test protocol. User requirements shall specify “WHAT is REQUIRED”. The requirements shall be Complete, Unambiguous, verifiable, traceable, clear and consistent. The User requirement shall specify the minimum hardware and Operating system for the installation of application software. For application software, detailed requirements of the controlling attributes such as password control, access level, and security system and data management shall be specified.Typical URS shall contain but not limited to or as appropriate

  • Operational requirements
  • Functional requirements
  • Data requirements
  • Technical requirements
  • Interface requirements
  • Environment requirements
  • Performance requirements
  • Availability requirements
  • Security requirements
  • Maintenance requirements
  • Regulatory requirements
  • Migration requirements
  • Life cycle requirements

Functional Design Specification: For complex Process Control Systems a functional design specification may be issued. The document includes technical details on the functions & design of the system. The Functional Design Specification defines how the requirements outlined in the URS are implemented. This document links Installation and operational qualification, which tests design and function respectively. FDS is normally written by the Vendor and reviewed and approved by the user. Bespoke systems will require a full FDS whereas commercial off-the-shelf systems (COTS) will require a much simpler FDS.

Installation Qualification (IQ): The Installation Qualification (IQ) is the process of demonstrating that the system components have been installed according to the manufacturer’s specifications and that all deliverables are properly accounted for IQ protocols shall be developed based on an understanding of the system, URS, Software design specification and System provider’s recommendation and shall describe how system components shall be installed. The IQ is achieved by documenting all installation activities carried out to ensure it meet the acceptance criteria defined in the protocol. Installation Qualification Protocol/ Report shall be prepared.

Operational Qualification (OQ): The Operational Qualification (OQ) is a test of the functions to ensure that each component of a computer system performs as intended (predefined specification) within representative or anticipated operating ranges. Operational testing shall be carried out as per the approved OQ protocol which shall be developed by the Validation team, reviewed, and approved by QA.

In certain cases, the executed Operational Qualification documents can be taken from the vendor and reviewed by the validation team members for acceptance.OQ protocols shall be developed with consideration of the following:

  • Company policies and procedures
  • Results of risk assessments carried out.
  • Results of supplier assessment.
  • Functional design specification.
  • The level of system components as per GAMP 5.

Operational Qualification Protocol/ Report shall be prepared.

Performance Qualification (PQ): Performance Qualification shall follow the successful completion of Installation Qualification and Operational Qualification. The Performance Qualification (PQ) ensures that the total system performs as intended in the specified operating range. The total system includes all hardware and software components, associated equipment, people, and procedures that make up the system. The execution process is conducted using a specific pre-defined dataset or actual live data. Computerized systems exchanging data electronically with other systems shall include appropriate built-in checks for the correct and secure entry and processing of data, to minimize the risks. Performance Qualification Protocol/ Report shall be prepared.

Validation Protocol & Report: Validation protocols & reports (FDS, IQ, OQ & PQ) shall be prepared in-house or Vendor documents can also be used, as it is if fulfilling the regulatory and customer requirements. Documents for the External Validation Agency can also be accepted.

Numbering System for Qualification Documents: The numbering system that shall be used for all documents related to Qualification and Validation shall be numbered as:


“XXX” stands for Document Code (may be of two or three characters)

*Equipment/ Instrument/ System Design Specification Sheet (DSS) may also be considered as per SOP wherever applicable.

“/” forward slash as separator.

“CSV” stands for Computer System Validation

“/” forward slash as separator.

“YYY” stands for Equipment / Instrument/ System code.

“/” forward slash as separator.

“ZZ” stands for serial number starting from 01 for individual Equipment / Instrument / System code.

“-” stands for dash as a separator.

“NN” denotes the revision number of the document which shall start from “00” and shall change after every revision as 01, 02, and so on. e.g. Document numbering for installation qualification of RMG shall be done as:

Installation Qualification Protocol -IQP/CSV/RMG/01-00

Installation Qualification Report-IQR/CSV/RMG/01-00


  1. At the time of requalification revision number of the document shall be increased as 01, 02, and so on.
  2. Whenever the group of Equipments/ Instruments/ Systems is considered for qualification/requalification denote the equipment code as EQ.
  3. Simple systems integrated with the equipment may be qualified along with equipment qualification defining the test strategy.

Qualification Summary Report:

For complex computer systems, after successful completion of qualification activities, a summary report may be prepared by a Validation team. The summary report shall include this information

  • Whether or not the qualification steps were followed
  • Whether or not the expected results were attained.
  • Description of any deviation from expected results
  • Follow-up activities to correct any deviations
  • Statement of whether the overall qualification objectives are met and the system can / cannot be used for further application.

Post-Implementation Review: Post-implementation review shall be carried out through a change control procedure. During this review period, post-go-live malfunctions shall be monitored and reported through Maintenance/Breakdown Work Order or Deviation handling (or Non-conformance handling procedure and any changes through Change Management System These malfunctions or issues shall be classified as minor/ major, software issues, training issues, and Procedural issues while investigation. The corrective action plan for these issues shall be implemented by having software’ corrections and evaluations, Training to users, and procedural updation.

Wherever the software replaces a manual operation, it is recommended to continue performing the manual activity in parallel with the software implementation during this phase.

For critical data entered manually, there shall be an additional check on the accuracy of the data. This check may be done by a second operator or by validated electronic means. The criticality and the potential consequences of erroneous or incorrectly entered data into a system shall be covered by risk management.

System Handover: After successful completion of qualification, provisional/ final handover of the system shall be carried out. A handover certificate shall be prepared or it may be included in the validation report or acceptance criteria.

Periodic Review: Periodic review shall be carried out throughout the life of the computer system to verify that the system remains compliant with relevant GxP requirements and fit for its intended use.

An annual review period is recommended. The review shall include, but shall not be limited to, the current range of functionality, changes, deviation records, incidents, problems, upgrade history, performance reliability, security and status reports for validated state, etc.

The results of the review are documented in a Periodic Review Report which will conclude either that the validation status is upheld or that revalidation is required.

Requalification and Revalidation: The extent of qualification and validation activities and tests to be carried out in both cases shall be based on the outcome of periodic review, the criticality of the system, and the risk involved.

A validation schedule/ planner for applicable systems shall be in place at the individual sites which needs to be prepared. Any change to this schedule/planner shall be recorded. Revalidation or requalification should cover all aspects of equipment and its controlling application. Requalification and Revalidation is of two types:

Requalification and Revalidation after the change:

Computer System shall be subjected to Requalification/ Revalidation after assessment of changes made to the existing system components and supporting systems etc. Complete Qualification/ Validation of the systems shall be considered when changes made can have an impact on the product Quality, patient safety, and data integrity or product characteristics. Partial or reduced Qualification/Validation of the systems shall be done when changes made can have limited impact. Justification for Partial or reduced Qualification / Validation shall be available.

Periodic Requalification and Revalidation: Recommendations for Periodic Requalification and Revalidation of the system shall be drawn based on periodic reviews of the software. It shall aim at ensuring that the system is continuing to perform as intended. Revalidation of the computerized systems shall be done every 3 years. Re-qualification of instruments shall not be performed. Instead, periodic calibration, system suitability (as applicable) and annual maintenance (i.e. AMC) shall be carried out to verify the performance of the instruments.

CHANGE CONTROL: Any changes to a computerized system including system configurations shall only be made in a controlled manner by a defined procedure.

  • Procurement and implementation of any new system or any change in the existing system component shall be handled through the Change Control procedure
  • All changes to the computer system shall be evaluated for their impact on the system and to the System lifecycle documentation.
  • The changes to any computerized system or hardware shall be done after ensuring the backup of the applications, data, etc.
  • The changes shall be primarily done on the test environment and if found successful shall be extended to the live environment.
  • The extent of verification and validation shall be risk-based depending on the type of change and its impact on Product Quality, Patient Safety, and Data integrity.

TRAINING: For successful implementation, maintenance, and operation of any system, training shall be conducted at various stages of the life cycle. The training plan shall be prepared for individual Systems as per requirement and shall cover all user groups. The type and extent of training shall be based on the role and responsibility of each user group. Training for any new computerized system shall be provided by the software developer during the initial phase for individuals from the Information Technology and Process owner, System Owner along the core group. The trained group shall be further responsible for training the remaining users at various stages of the life cycle.

Retraining shall be conducted as and when required based on the evaluation of the training needs of the users along with demonstration. The new entrants shall be trained by the existing users of the computerized system preferably in the test environment. For detailed procedure of Training


Preventive Maintenance: Preventive maintenance shall ensure smooth and reliable operation on a day­-by-day basis. Activities shall include Regular removal of temporary files from the hard disk. Regular virus checks of systems that are connected to a network and/or to the Internet, regular checks for hardware and software.

Backup and Restore: Operating software, application software, configuration settings, and data shall be backed up on external media to ensure access if online records are lost either through accidental deletion or equipment problems. Backup and restore Procedure shall essentially include:

  • Back up frequency.
  • Storage area
  • Storage period
  • Storage condition
  • Procedure for backup and restore.
  • Frequency of backup storage verification

Responsibility for backup and restore shall be with the System owner or as defined in individual SOP.

If data are transferred to another data format or system, validation shall include checks that data are not altered in value and/or meaning during this migration process. Regular backups of all relevant data shall be done. Integrity and accuracy of backup data and the ability to restore the data shall be checked during validation and monitored periodically. Support and maintenance activity provided by the manufacturer or third-party support vendors shall be onsite to the extent possible.

Remote support and maintenance activity can also be done by the manufacturer or third parties with network controls and gateway securities in place. This activity shall be monitored by the System Owners or the IT Support group within the organization.

Data storage and Archiving: The system owner with the support of IT and QA shall develop an archiving strategy for each system as per system requirement. Data generated by the computer system shall be regularly removed from the system’s hard disk(s) and archived to avoid overloading the hard disk(s) and loss of data.

Data storage/ archiving may be in the form of NAS/Server, localized system server, hard disk, or print. The system not having such options shall be made compliant by developing procedural controls. Data shall be secured by both physical and electronic means against damage. Stored data shall be checked for accessibility, readability, and accuracy. Access to data shall be ensured throughout the retention period. Data may be archived. This data shall be checked for accessibility, readability, and integrity.

If relevant changes are to be made to the system (e.g. computer equipment or programs), then the ability to retrieve the data shall be ensured and tested. 

Contingency Plan and Disaster Management: A contingency plan and disaster management procedure shall be prepared considering the impact on patient safety, data integrity, and product quality in case of a system failure or a disaster. Responsibility for contingency plans and disaster management shall be with the IT Administrator and system owner. This data shall be checked for accessibility, readability, and integrity.

For the availability of computerized systems supporting critical processes, provisions shall be made to ensure continuity of support for those processes in the event of a system breakdown (e.g. a manual or alternative system). The time required to bring the alternative arrangements into use shall be based on risk and appropriate for a particular system and the business process it supports. These arrangements shall be adequately documented and tested.

Security and User Administration: System security is important to ensure confidentiality, authenticity, and integrity of data. In general, the Process for the security system shall be prepared and followed for Security in Computerized Systems and User Management respectively. Wide Area network (WAN), if any is provided by the IT department. A firewall and router are installed for protection from any external threats. All the applications are running on the intranet and are not accessible outside the Network.

For support, access is being provided to Vendors using remote control tools which have provisions to restrict or allow view-only and full access. This is always done under the supervision of the IT Engineers and the System Owner. The changes are controlled by the System owners. Any updates/patches or changes to applications should undergo the change control procedure, However separate procedures can be developed for different computer systems by the system owner with the support of IT and QA, if required

The Security and User Management Procedure for a specific system is based on the criticality of the system and the system functions and risk assessment. Physical and logical security to limit access to the systems may be considered. Suitable methods of preventing unauthorized entry to the system may include the use of keys, pass cards, personal codes with passwords, biometrics, and restricted access to computer equipment and data storage areas. The extent of security controls depends on the criticality of the computerized system. Creation, change, and cancellation of access authorizations shall be recorded. Management systems for data and documents shall be designed to record the identity of operators entering, changing, confirming, or deleting data including date and time. The spreadsheets used for critical calculations are to be validated as per SOP and the shush sheet should be secure to avoid unauthorized access.

DOCUMENT COMPLETION PROCEDURE: Each computerized system shall have a document completion procedure defined in the Standard Operating procedure which shall include but not be limited to;

Electronic Records: It shall be possible to obtain clear printed copies of electronically stored data which can be stored and archived for the retention period of the document.

Audit Trails: Consideration shall be given, based on a risk assessment, to building into the system the creation of a record of all GMP-relevant changes and deletions (a system-generated “audit trail”). For change or deletion of GMP-relevant data, the reason shall be documented. Audit trails need to be available and convertible to a generally intelligible form and regularly reviewed.

Incident Management: All incidents, not only system failures and data errors, shall be reported and assessed. The root cause of a critical incident shall be identified and shall form the basis of corrective and preventive actions. There are different QMS tools to identify, log, investigate, evaluate/understand, correcting discrepancies (while attempting to prevent their recurrence) and recognize potential discrepancies (to prevent their occurrence)

Electronic Signature and its controls: All electronic records should have a handwritten review and approval cycle or an electronic signature. Electronic records may be signed electronically. Electronic signatures are expected to:

  • have the same impact as hand-written signatures within the boundaries of the company,
  • be permanently linked to their respective record,
  • include the time and date that they were applied.

The electronic signatures shall follow the security norms to avoid misuse and sharing.

SYSTEM RETIREMENT: System retirement for individual computer systems shall be made. A system retirement plan shall be prepared based on the risk involved and its impact on another business process. The system retirement plan shall essentially include the following:

  • Assessment of impact on interfaced systems.
  • Deactivation of system (hardware/software/ network).
  • Disposal of software and hardware.
  • Retention and controlled access to historical data for reference.
  • Migration of data to any proposed new system when the data is compatible with the flew system. (Migration process shall be accurate, complete, and verifiable).
  • Documentary evidence of each action listed above.

PROJECT ACTIVITIES MONITORING, CONTROLLING, AND REPORTING: Project activities, tasks, and their responsibilities shall be as per the Validation Master Plan. A project calendar shall be prepared to provide target timelines for each project activity and provision shall be available to record the actual activity completion date. Issues shall be tracked to manage resolution details and approval activities. Open issues shall be discussed as needed during project meetings. In addition, a project issue log, consisting of the issue, number and date, assignee, and resolution, shall be distributed to the project team members as necessary.

Team meetings shall be conducted to discuss progress, issues, and plans for the project. Meeting minutes or equivalent communication shall be made available to team members. This VMP and the validation documentation outlined above shall be created and stored for the complete life cycle of the proposed system.


  • GAMP5: Good Automated Manufacturing Practices 5: A Risk-Based Approach to Compliant GxP Computerized Systems. International Society for Pharmaceutical Engineering (ISPE); 2008.
  • 21 CFR Part 11
  • EU GMP Annex 11
  • PIC/S guide to good manufacturing practice for medicinal products annexes: Annex 11 – 1026 Computerised systems.
  • WHO Technical Report Series, No. 937, Annexure 4, Appendix 5
  • MHRA GMP data integrity definitions and guidance for industry.

More Jobs UpdatesVisit@


Check Also

Unlocking Success with User Requirement Specification: Coating Machine URS

Unlocking Success with User Requirement Specification: Coating Machine URS In any project or system development, …