CSV Sop

Lupin Property for Training Purpose Only

ANNEX_MUM_ITP_006997
INVENTORY INDEX AND PERIODIC REVIEW SCHEDULE OF GXP
COMPUTERIZED SOFTWARE SYSTEM
Location Name
Department
Year
ER/ES
Software,
Equipme Client Applicab Periodic Last Next System Actual
Name GAMP Initial Last Remark
Sr. nt/ Identification ility (ER Review Periodic Periodic Status Review
and Categor Validation Validation s
No. Instrume number(s) only/ER Frequenc Review Review (Active/ Date
version y Date Date (if any)
nt No. (hostname) & ES /No y Date Date Retired)
no.
ER )
______________________ ______________________ ______________________ ______________________

Prepared by (User Dept.) Reviewed (User Dept.) Reviewed by (IT) Approved by (Site QA / CQA)
Monthly periodic review progress table:
Month Jan Feb March April May June July Aug Sept Oct Nov. Dec.
Reviewed by
Approved by
ANNEX_MUM_ITP_006997 | (1.0) | SOP_MUM_ITP_008333 | CLASS C Vinayak Baravkar (vinayakcbaravkar)

10 May 2021 (GMT+05:30) | 09:47:25 (GMT+05:30) | MASTER COPY
Page 1 of 1
DOCUMENT NUMBERING LOGBOOK FOR COMPUTERIZED SOFTWARE SYSTEM
Logbook Number: - _______________________________

Page 1 of 2
DOCUMENT NUMBERING LOGBOOK FOR COMPUTERIZED SOFTWARE SYSTEM
Document Name: - __________________________________________

Instrument/ Instrument/ Issued By Received
Sr. Document Software name Department
Equipment/ Equipment (Sign and By Remarks
No. Number & Version Name
Client/ Host ID Name date) (Sign/Date)

Page 2 of 2
DEVIATION LOG
Reference Change Control Number

System Name
Reference Validation
Protocol/CVC/Other
Allotted Checked By
Sr. Deviation Stage Deviation Deviation
Deviation Details By (Sign/Date)
No. Number (IQ/OQ/PQ/other) Type closure date
(Sign/Date) (QA/CQA)
<Rows can be added/removed>

Page 1 of 1
<TEMPLATE>
Corporate IT
Doc. No.: <Doc. No.>
USER REQUIREMENT SPECIFICATION
Supersedes: FOR <SYSTEM NAME>
<Supersede Doc. No./ Nil>
1.0 INTRODUCTION
1.1 Purpose
<This document should capture detailed user requirements with a broad overview of
their defined goals>
1.2 Scope
<The scope should capture entire business process impacted due to user
requirement for any new implementations, enhancements, upgrades, support or
rollouts regarding CSS>
2.0 SYSTEM OVERVIEW
<This section is intended to make the described user requirements easier to

understand (not to state requirements)>
2.1 Background
<This section describes the background to the decision to fulfill user requirements via
CSS with reference to feasibility study report>
2.2 Business Process Overview

<This section shall define the business process to be incorporated in CSS including
activities and resources (embed a process flow diagram if available).>
3.0 SYSTEM REQUIREMENTS

<This section shall state the requirements in which the system must operate. Every
requirement must have a unique identifier. Requirement will be as follows>
3.1 Security / Regulatory Requirements:

<This section shall specify all security specifications that are to be followed. This
should include any special business control and data security requirements of the
system. These should include protection from accidental or malicious access, use,
modification, destruction or disclosure of the system. For example, access restriction,
authorization checks, critical transaction & reports access, etc. Security issues
related to personnel, communications and physical protection of computer facilities
should also be addressed. Focus should be on system-specific requirements, with
reference to the enterprise procedures and policies applicable to all the sites
(including 21 CFR Part 11/Electronic Records/Electronic Signatures (ER / ES))>
Page 1 of 7
<TEMPLATE>
Corporate IT
FOR <SYSTEM NAME>
URS ID /
Section User Requirement Description
No.
3.1.1 System should not allow creation of duplicate username.
In system, administrator shall have option to reset user’s password
3.1.2
when required
System should have password reset period and it shall be as per Lupin
3.1.3
policy.
System should have option to disable user account option in
3.1.4
Application
3.1.5 System should not have option to delete the user account.
Verify that If application has option to delete the user account, then it
3.1.6
should be recorded in audit trail.
Application should have user groups and assigned privileges for each
3.1.7
user group as per Lupin requirement
System administrator privileges are given to Lupin IT and same is
3.1.8
captured in Privilege matrix (wherever applicable)
System date & time should be auto synchronized with Lupin Server for
3.1.9
network connected systems (Time server or Domain server)
In case of server base system, client system date & time is captured
3.1.10
from server
Application shall not store any of its data into windows public folders
3.1.11
like profile, temp, event log etc.
System supports for old version data retrievability and readability in
3.1.12 newer version, in case of system upgrade. (Applicable during system
upgrade/ reinstallation)
3.1.13 Application allows for backup of electronic data including audit trail.
Procedure is in place for periodic testing of data restore to ensure data
3.1.14
accuracy
Audit trail shall record all the activities of all users irrespective of type of
3.1.15
the user (like operator, manager etc.,) including administrator
3.1.16 Application shall store Audit trail data.
3.1.17 System date and time shall be controlled and not editable by user
3.1.18 Application has no option to disable the recording of electronic data
3.1.19 Electronic data shall not be open for modification within the application
Electronic data shall not be open for modification outside the
3.1.20
application (using external tools like notepad from data folder)
3.1.21 Electronic data shall not be deleted within the application
Electronic data shall not be deleted outside the application (from data
3.1.22
folder)
Application shall store the raw data automatically into the default data
3.1.23
folder without any operator’s decision
Page 2 of 7
<TEMPLATE>
Corporate IT
FOR <SYSTEM NAME>
URS ID /
No.
User should not have “Reset” or “Abort” or similar option, which stops
3.1.24
the current activity without storing the data
Application should have facility to maintain data in year wise folder
3.1.25
structure for ease of access control and archive (as applicable)
In case of server-based application, there shall not be any impact of
3.1.26
network failure during storing of data.
3.1.27 Audit trail shall have 3Ws (Who, When and What).
3.1.28 Audit trail data shall not be open for modification within the application
Audit trail data shall not be open for modification outside the application
3.1.29
(using external tools like notepad from data folder)
Audit trail data generated in the system shall not be able to delete
3.1.30
within the application
Audit trail data generated in the system shall not be able to delete
3.1.31
outside the application (from data folder)
Application shall not have option to disable/pause the recording of audit
3.1.32
trail
Application shall accept only valid data within their acceptable limits (as
3.1.33
applicable)
Application shall not allow to proceed without mandatory data fields
3.1.34
entered
System should perform all the actions in the correct sequence where
3.1.35
sequenced steps are required.
System captures the instrument identification details when collecting
3.1.36 raw data (this is only applicable if application connects to
equipment/instruments).
Application data is not altered and/or meaning not changed during the
3.1.37 exchange process where system is interfaced with other systems
(Applicable for interfaced systems)
System should not allow to Login with invalid username and valid
3.1.38
password.
System should not allow to Login with valid username and invalid
3.1.39
password.
System should not allow to Login with invalid username and invalid
3.1.40
password.
3.1.41 System should allow to Login with valid username and valid password.
System should not allow to set the password having length less than
3.1.42
‘__’ characters.
System should allow to Set the password length equal to minimum
3.1.43
password length ‘___’ characters.
Page 3 of 7
<TEMPLATE>
Corporate IT
FOR <SYSTEM NAME>
URS ID /
No.
System should allow to Set the password length more than minimum
3.1.44
password length ‘___’ characters.
3.1.45 User shall have option to change the password when required
3.1.46 System shall have provision for individual user account
System should not allow to Login with valid username and invalid
3.1.47 password for <__> more times. System should have Unauthorized
login attempts
3.1.48 System should keep the application idle for <___> minutes.
Procedure is established that holds individuals accountable and
3.1.49
responsible for actions initiated under their electronic signatures.
E-signature certification has been submitted to the FDA, stating their
3.1.50
intent to use electronic signatures.
System should require both components [username and Password] of
3.1.51
the electronic signature when signing a record for the first time.
System should require one component i.e. password (at a minimum)
3.1.52 which is designed and can be executed by genuine user only for
subsequent electronic signatures during a continuous session
E-Signature shall appear in reports like batch report, certificate of
3.1.53
analysis (where applicable)
Electronic signature shall appear on a printed report/record, information
(minimum requirements):
- Printed name of signer (Who)
3.1.54
- Date & time stamp of signature (When)
- Associated meaning of the signature such as Review, Approval.
(What was done)
Electronic signature shall appear in audit trail (minimum requirements):
- Printed name of signer (Who)
3.1.55 - Date & time stamp of signature (When)
- Associated meaning of the signature such as Review, Approval.
(What was done)
Validation of the system should be planned and conducted as per
3.1.56
approved validation protocol using pre-approved test procedures.
Procedure should be established for
System operation
User & System administration
3.1.57
CSS change control
Incident and CAPA management
Periodic Review.

Page 4 of 7
<TEMPLATE>
Corporate IT
FOR <SYSTEM NAME>
URS ID /
No.
Procedure for formal risk assessment and reporting should be in place
3.1.58
throughout the life cycle of the system.
System shall generate accurate and complete copies of record in both
3.1.59
human readable and electronic form.
Procedure should be established to ensure appropriate qualifications,
3.1.60
experience and/or training to personnel.
Procedure should be established for supplier assessment / vendor
3.1.61
audit/formal agreement.
System should allow qualified person for recording certification and
batch release, in case system is used for batch release & it is
3.1.62 performed using electronic signature. (This will be applicable for
Batch release system like SAP where User Decisions are done for
batch release).
3.1.63 There should be availability of business continuity plan/activities.
3.1.64 Password should be complex (at least alphanumeric characters).
3.1.65 Generic user account should not be available in system
Note: Above mentioned requirements may vary based on application.
3.2 Technical Requirements: <This section shall describe the requirements specific to
general characteristics of the intended users of the system, interface with the system etc.>
URS ID / User Requirement Description

Section No.
3.3 Software Functionality Requirements: <This section shall specify the functional
requirements i.e., what the system shall do, reporting requirements (if applicable), etc. It is
appropriate to partition requirements into subsections>
URS ID / User Requirement Description

Section No.
Note: Rows can be added/modified/deleted if needed.

Page 5 of 7
<TEMPLATE>
Corporate IT
FOR <SYSTEM NAME>
4.0 ABBREVIATIONS:
CSS : Computer Software System

ER : Electronic Records
ES : Electronic Signatures
CFR : Code of Federal Regulations
URS : User Requirement Specification
5.0 REFERENCES:
<This section shall provide a complete list of documents referenced in the URS. Each
document is identified by title & identity and for external documents, publishing
organization and version is required>
6.0 REVISION HISTORY
Version
Details of Review / Revision
No.

Page 6 of 7
<TEMPLATE>
Corporate IT
FOR <SYSTEM NAME>
7.0 APPROVAL:
PREPARED BY:
Name Department Sign and Date
<No’s of rows can be increased>
REVIEWED BY:
<No’s of reviewer can be increased>
APPROVED BY:

Page 7 of 7
<TEMPLATE>
Corporate IT

GxP ASSESSMENT FOR <SYSTEM NAME>
Supersedes:
1.0 GXP APPLICABILITY ASSESSMENT (To be filled by User)
Sr.
Questions Yes/No/NA
No.
Can the system or data from the system impact product
1 manufacturing, packaging, holding, distribution, related to any
of these?
Can the system or data from the system impact product identity,
2 strength, quality, purity or safety or decisions related to any of
these?
Can the system or data from the system impact patient safety
3
or decisions related to patient safety?
Can the system or data from the system impact submissions to

4
regulatory authorities?
5 Can the system or data from the system impact clinical studies?
If any of the answer is “Yes”, then system is considered as “GxP Applicable”. If

answer of all the questions are “NO”, then system is considered as “GxP not
applicable and further sections of this document will not be applicable.
Conclusion: The system will be  GxP Applicable  GxP Not-Applicable

Page 1 of 5
Page 1 of 5
<TEMPLATE>
Corporate IT
Doc. No.: <Doc. No.> GxP ASSESSMENT FOR <SYSTEM NAME>
2.0 ER/ES APPLICABILITY ASSESSMENT (To be filled by User)
Sr.
Questions Yes/No/NA
No.
Electronic Record Applicability (21 CFR Part 11; Subpart B)
Are any of the records referenced in Question 1-5 saved

1 electronically within the system even though they may be
printed?
Instructions:
If answer to this question is Yes, then system is required to follow the Electronic
Records requirements (Subpart B) of 21 CFR Part 11 regulation (ER/ES).
EDC assessment is required and continue to Electronic Signature applicability
questions.
If the answer to this question is No, then system is not required to follow 21 CFR Part
11 regulation and EDC assessment is not required.
2 EDC Assessment required?
Electronic Signature Applicability (21 CFR Part 11; Subpart C)
Does the system include functionality that allows users to

3
approve, authorize or otherwise sign records electronically?
Are these electronic signatures used in place of hand-written
4
signatures?
Conclusion: The system will be  ER Applicable/  ER&ES Applicable/ 
ER&ES Not Applicable

Page 2 of 5
<TEMPLATE>
Corporate IT
3.0 GAMP SOFTWARE CATEGORY DETERMINATION (To be filled by IT)
Sr.
Questions Yes/No
No.
Is the software related to infrastructure like Operating Systems,
1
Databases
Is the software non-configurable w.r.t its functional behavior?
2
This excludes the configuration of operating parameters
Is the software limited to single function as a standard
3
software?
4 Is the software configurable w.r.t its functional behavior?
Is the software allowing administrator to add/modify/remove

5 software function through configuration without modifying its
core program code?
6 Is the software inhouse developed?
Is the software exclusively developed for Lupin by external

7
party
Sr. GAMP Software Category (Tick any one as applicable)

No.
1 If the answer to question 1 is Yes, then the category is “1” Category 1
If the answer to question 2 and 3 is Yes, then the category is Category 3
2
“3”
3
“4”
4
“5”

Page 3 of 5
<TEMPLATE>
Corporate IT
4.0 OVERALL CONCLUSION:

Sr. GAMP Software Category (Tick any one as applicable)
No.
System will be : GxP Applicable / Not Applicable

Electronic Record : Applicable / Not Applicable
Electronic Signature : Applicable / Not Applicable
GAMP Category : Category- 1/ 3/ 4/ 5
5.0 ABBREVIATIONS:
ER : Electronic Record
ES : Electronic Signature.
CFR : Code of Federal Regulations.
NA : Not Applicable
GAMP : Good Automated Manufacturing Practices
6.0 REVISION HISTORY:

Version No. Details of Review / Revision

Page 4 of 5
<TEMPLATE>
Corporate IT
7.0 APPROVAL:
PREPARED BY:
<No’s of rows can be increased>
REVIEWED BY:
APPROVED BY:

Page 5 of 5
<TEMPLATE>
Corporate IT
VALIDATION PROJECT PLAN FOR <SYSTEM NAME> FOR <PURPOSE>
Supersedes:
1.0 PRE-EXECUTION APPROVAL
PREPARED BY:
REVIEWED BY:
APPROVED BY:

Page 1 of 3
<TEMPLATE>
Corporate IT
Doc. No.: <Doc. No.> VALIDATION PROJECT PLAN FOR <SYSTEM NAME> FOR <PURPOSE>
2.0 VALIDATION PROJECT PLAN
Schedule Actual Completion Remarks

Sr. No. Deliverables Responsibility
From To Date (if any)
CCP No.: CCP Approval Date:

Page 2 of 3
<TEMPLATE>
Corporate IT
Doc. No.: <Doc. No.> VALIDATION PROJECT PLAN FOR <SYSTEM NAME> FOR <PURPOSE>
4.0 POST EXECUTION APPROVAL

COMPILED BY:
REVIEWED BY:
APPROVED BY:

Page 3 of 3
<TEMPLATE>
Corporate IT

VENDOR AUDIT CHECKLIST FOR <VENDOR
Supersedes: NAME>
1.0 VENDOR OVERVIEW

Sr.
Questions Comments
No.
Company details:
Company name:
1. Address:
Phone number:
Contact person:
What are the different types of products

2.
and services available in market?
Provide years of working experience in
3. pharmaceutical and healthcare sector.
Mention any three references.
How many pharma related
4. software/system implementations done in
India and overseas?
Provide organizational chart(s) giving
company structure, organization and the
responsibilities of Key individuals within the
5.
structure (from managing director to
personnel responsible for the delivery of
the product / service)
Provide details about the number of
employees in your company as follows;
a. Total employees
6. b. Total technical expert for the
product
c. Total quality personnel
d. Total ongoing support employees
Provide evidence of formal quality
7. management system certification to ISO
9001 including details of your most recent
Page 1 of 8
<TEMPLATE>
Corporate IT
NAME>
Sr.
Questions Comments
No.
certification audit by your certification body
and List Certificate / approvals obtained.
2.0 QUALITY MANAGEMENT SYSTEM:
Sr. Availability
Questions Evidences/Comments
No. (Yes/No/NA)
Does your facility operate under a
1. quality policy? If yes, mention the
details.
Does quality management
2. system available? If yes, mention
the details.
Does the quality unit independent
3.
to other functions?
Does the quality unit have
authority and responsibility to
4.
approve or reject components,
procedure, products?
Does the quality department or
unit routinely review records to
5. ensure that procedures were
followed and properly
documented?
Does staff/user training
6. procedure available? If yes,
mention the details.
Does job responsibilities
7.
available for staff?
Does role of sub-contractors
8. exist? If yes, mention details like
method of selection of sub-
Page 2 of 8
<TEMPLATE>
Corporate IT
NAME>
Sr. Availability
No. (Yes/No/NA)
contractor, method of accepting
product delivered by
subcontractor.
Is there any procedure for
handling of customer complaints?
If yes, mention the details like
9.
procedure of complaint logged,
analyzed, categorized, resolved,
tested, closed.
Does any deviations from the
10. normal practice being recorded
and authorized?
Does any awareness program
11. conducted for staff related to
regulatory requirement?
Is quality management system
12. periodically reviewed for its
effectiveness?
3.0 VALIDATION AND DOCUMENTATION:

Sr. Questions/Checking Availability
Evidences/Comments
No. parameters (Yes/No/NA)
Is documentation templates
1. available for Computer System
Validation?
Does design specification
2.
document available?
Does system manual available
that covers system operation,
3.
system configuration,
architecture, troubleshoot etc.?
Page 3 of 8
<TEMPLATE>
Corporate IT
NAME>
Sr. Questions/Checking Availability

Evidences/Comments
No. parameters (Yes/No/NA)
Is there a source code listing
4. available and are source code
restricted?
Do procedures for development
5.
and testing exist?
Are records maintained for
6.
testing of product?
Is adequate testing done before
7. releasing the system to
customers?
4.0 SOFTWARE DEVELOPMENT LIFE CYCLE:

Sr. Availability
No. (Yes/No/NA)
Does documented product
development lifecycle model like
1. GAMP/V-Model/waterfall followed
during product development? If
yes, mention the details.
Project planning: provide details
of the procedures, methodologies,
2. tools and process followed when
planning and managing projects
against project milestones.
Quality planning: Provide details
of the procedures, methodologies,
3. tools and process followed when
planning and managing quality on
projects.
Software development: provide
4.
details of the processes /
Page 4 of 8
<TEMPLATE>
Corporate IT
NAME>
Sr. Availability
No. (Yes/No/NA)
standards that are followed to
produce in-house and externally
developed software.
Software coding standards:
Provide details of the process,
definitions / standards followed
when developing in-house
5. software. Where external software
companies are utilized, provide
details of how software processes
/ standards are monitored /
controlled.
Software reviews: provide details
of the processes followed for
6.
reviewing source code at each
stage of the product development.
Software testing: provide details
of the process followed for
7.
software testing at each stage of
product development.
Document reviews / approval /
controls: provide details of the
process followed for review,
8.
approval and control of software
related documentation (e.g.
specification design)
Change control: Provide details
of the process followed for the
9.
control of the software and
hardware.

Page 5 of 8
<TEMPLATE>
Corporate IT
NAME>
Sr. Availability
No. (Yes/No/NA)
Configuration management:
Provide details regarding
10.
handling of configuration
management of software.
Final Inspection and Testing:
Provide details of the process /
11. standards that are followed for the
inspection / testing of your product
software and hardware.
Do you have traceability from
12. requirements through to testing is
available and documented.
Whether every change in existing
13. system is validated to ensure
system is fit for intended use?
Is adequate security established
to prevent unauthorized access to
14. the system or loss or changing of
programs, date, or control
parameters?
Are master documents issued and
approved before use?
15.
If so, who is responsible for
approval
Are there any procedure to
16. communicate any changes in
version or updating in software?

Page 6 of 8
<TEMPLATE>
Corporate IT
NAME>
5.0 CUSTOMER SUPPORT AND MAINTENANCE:

Sr. Availability
No. (Yes/No/NA)
What are the modes of support
services (On-site support, Call center
1.
support, web based support, mail
support) available?
Are system errors (e.g. bugs,
anomalies, incident) detection
mechanism available and same is
2. documented and handled as per
procedure and reviewed on a timely
basis and communicated to
customers?
Are investigations documented and do
they include investigation steps,
3.
findings, root cause, CAPA, and
follow-up steps, if required?
Are patches updated with adequate
4. testing, risk analysis, validation and
documentation?
Describe about service delivery
5.
processes
Do you have any product support /
6.
maintenance procedure available
Is disaster management and business
7.
continuity policy available?
Additional Information (if any)
(Please record below any other information which shall give a clear picture of your quality
management system.)

Page 7 of 8
<TEMPLATE>
Corporate IT
NAME>
PREPARED BY:
SIGN & DATE (company
seal in case of prepared
by is vendor)
NAME
DESIGNATION
Note: Vendor audit checklist shall be filled and signed by Lupin team for onsite audit.
Checklist shall be filled and signed by vendor in case off site audit and return completed
Audit Check List to the Lupin.
6.0 SUMMARY & CONCLUSION: (For Lupin representative use only)
Assessment (For Lupin representative use only)
Summary:
After careful evaluation / assessment of all the vendor provided

documents, attached with ‘Vendor Audit Checklist for <Vendor
Conclusion:
Name>’, it is concluded that this vendor is <Approved/Not Approved>
to proceed ahead for further validation activities as per CSVMP.
Approved By:

Page 8 of 8
<TEMPLATE>
Corporate IT
EDC ASSESSMENT CHECKLIST FOR
Supersedes: <SOFTWARE NAME>
For each question below evaluate the system and record the observation:
Sr.
Section-A (Details of the Supplier along with system details)
No.
Name of Software / Instrument / Equipment provider
1.
Software / Instrument / Equipment provider registered address
2.
Software / Instrument / Equipment provider contact details with name,

telephone and e-mail
3.
Name of Software / Instrument / Equipment along with version no./model

no.
4.
Section-B (System check points during on site / off site Demo)

System Type ☐ HMI ☐ IPC ☐ Normal PC ☐ Server based
Network Mode ☐ Standalone ☐ LAN Connected ☐ Cloud based
Name:
OS Requirement:
☐ 32bit ☐ 64bit
Antivirus ☐ Compatible with TrendMicro Office Scan antivirus software
Requirement Details (if Any):

Page 1 of 9
<TEMPLATE>
Corporate IT
<SOFTWARE NAME>

User
☐ Local ☐ LDAP ☐ Nil (Open System)
Authentication
Details (if Any):
Mode
System generates
☐ Yes ☐ No
Electronic
Details (if Any):
Records
System generates ☐ Yes ☐ No

Audit Trail Details (if Any):
System has
☐ Yes ☐ No
Electronic
Details (if Any):
Signatures
Feature
☐ ASCII Flat File ☐ Encrypted Flat File ☐ Local Database

Electronic Data
☐ Server Database ☐ No Data
Store Mode
Details (if Any):
☐ Local Disk ☐ Network Folder ☐ Server (Database)

Electronic Data
☐ Not Applicable
Store Location
Details (if Any):
Details of
dependant
software (if any)
Cut, Copy, Paste, File Rename, F2, Right-Click, Delete-Key,

Delete-Context-Menu, Drag & Drop, Mouse-Double-Click, F9,
Compatibility with CTRL+ALT+DEL, Recycle Bin, Task Manager, Notepad,
Lupin IT Controls Calc, IE, Command Prompt, Control Panel, F10-Key:
Disabled
Remarks (if any):
Page 2 of 9
<TEMPLATE>
Corporate IT
<SOFTWARE NAME>
☐ LIMS compliant ☐ OPC compliant ☐ Not Applicable

Details (if Any):
Connectivity with
standard
enterprise
applications like
LIMS, SCADA,
DAS, LES, MES,
BMS

Sr.
Check Point Comply Remarks
No.
1. Data Protection & Integrity – Electronic Records
Electronic data shall not be open for
unauthorized modification within the
1.1 application and outside the application ☐Yes ☐No ☐NA
(using external tools like notepad from
data folder)
Electronic data shall not be able to
1.2 delete within the application and outside ☐Yes ☐No ☐NA
the application (from data folder)
Application shall not have option to
1.3 ☐Yes ☐No ☐NA
disable the recording of electronic data
Application shall store the raw data
1.4 automatically into the default data folder ☐Yes ☐No ☐NA
without any operator’s decision

Page 3 of 9
<TEMPLATE>
Corporate IT
<SOFTWARE NAME>

Sr.
No.
System shall not have “Reset” or “Abort”
1.5 or similar option, which stops the current ☐Yes ☐No ☐NA
activity without storing the data
Application shall store raw data
permanently without any auto deletion
or auto overwriting throughout its
retention period
Application shall have facility to maintain
1.7 data in year wise folder structure for ☐Yes ☐No ☐NA
ease of access control and archive
Application shall not store any of its data
1.8 into windows public folders like profile, ☐Yes ☐No ☐NA
temp, event log etc.,
In case of server-based application,
there shall not be any impact of network
failure during storing of data. Data loss
is not permitted.
2. Data Protection & Integrity – Audit Trail
Audit trail shall record all the activities of
all users irrespective of type of the user
(like operator, manager etc.,) including
administrator
Audit trail shall have minimum 3Ws
2.2 (Who, When, What) (Optional: Why and ☐Yes ☐No ☐NA
Where)
Audit trail data shall not be open for
modification within the application and
outside the application (using external
tools like notepad from data folder)
Audit trail data generated in the system
shall not be able to delete within the
application and outside the application
(from data folder)
Page 4 of 9
<TEMPLATE>
Corporate IT
<SOFTWARE NAME>

Sr.
No.
Application shall not have option to
disable/pause the recording of audit trail
Application shall store Audit trail data
permanently without any auto deletion
or auto overwriting throughout its
retention period
3. System operating parameters
Application shall accept only valid data
within their acceptable limits and,
mandatory data fields should be
validated before storage
4. Data Backup/Archive
Application shall have option to take
4.1 backup of electronic data including audit ☐Yes ☐No ☐NA
trail
Application shall have option to archive
4.2 selected electronic data (e.g. year wise ☐Yes ☐No ☐NA
data)
Application shall check the integrity of
backup data after backup/archive
Application shall have option to restore
the backup/archive data when needed
without overwriting the current data (as
a separate data set)
5. System Access Control
Application shall allow access to only
5.1 authorized users (Login facility with ☐Yes ☐No ☐NA
username and password combination)
Application shall allow unique user
accounts
Application shall have option to disable
the user account

Page 5 of 9
<TEMPLATE>
Corporate IT
<SOFTWARE NAME>

Sr.
No.
If application has option to delete the
5.4 user account, then it shall not affect ☐Yes ☐No ☐NA
user’s existing raw data and audit trail
Application shall have option to define
required user groups and set the
privileges for each user group as per
Lupin requirement
User shall have option to change the
password when required
Administrator shall have option to reset
user’s password when required
Application shall have facility to lock the
5.8 user account after defined invalid login ☐Yes ☐No ☐NA
attempts
If this system is used interchangeably
by different departments; Usage is
clearly defined with segregation at data
level with necessary access controls
In case of Year wise data folders (as per
point 1.7); system shall have option for
access control (read/write/modify) on
previous year folders
Application shall have complex
5.11 password (at least alphanumeric but not ☐Yes ☐No ☐NA
limited to) facility
6. IT Security Policy
Password ageing option shall be
6.1 available in the system and age shall be ☐Yes ☐No ☐NA
set as per Lupin policy
System date, time and time zone shall
be controlled and not editable by user
System time shall get auto synchronized
with Lupin Server (Time server or
Page 6 of 9
<TEMPLATE>
Corporate IT
<SOFTWARE NAME>

Sr.
No.
Domain server)
In case of server base system client
6.4 system date & time is captured from ☐Yes ☐No ☐NA
application server?
System administrator privileges shall be
6.5 given to Lupin IT and same shall be ☐Yes ☐No ☐NA
captured in Privilege matrix
Application shall not require internet
6.6 connection to work during regular ☐Yes ☐No ☐NA
operations
Application shall allow administrator to
configure the system operating
parameters (if any) instead of hard-
coded
Application shall have auto-logout or
6.8 auto-lock facility with configurable ☐Yes ☐No ☐NA
duration
7. Reports
Application shall generate reports in
non-editable mode
Report shall have “report generated by
7.2 and on” and “page x of y” information ☐Yes ☐No ☐NA
populated automatically in footer area
Report shall be generated without any
input from the user that is shown on the
report and impacts the meaning of the
report.
8. Electronic Signature
Application prompts for e-signature for
all critical activities
E-Signature contains current logged-in
8.2 user (auto populated), password and ☐Yes ☐No ☐NA
meaning of signature/reason
Page 7 of 9
<TEMPLATE>
Corporate IT
<SOFTWARE NAME>

Sr.
No.
8.3 E-signatures appear in audit trail ☐Yes ☐No ☐NA
E-Signature appear in final reports like
8.4 batch report, certificate of analysis ☐Yes ☐No ☐NA
(where applicable)
Note: “Remarks” in above table is required in case of “Comply” column is filled with “No”
or “NA”.
Additional Information (if any)
(Please record below any other information which shall give a further clarity on electronic
data compliance of your system.)
PREPARED BY:
SIGN & DATE (company
seal in case of prepared
by is vendor)
NAME
DESIGNATION

Page 8 of 9
<TEMPLATE>
Corporate IT
<SOFTWARE NAME>
SECTION-C: SUMMARY AND CONCLUSION: (TO BE FILLED BY LUPIN)
Summary:
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
____________________________________________________________
Conclusion:
Based on evaluation this computer software system found to be:
☐ Acceptable ☐ *Conditionally Acceptable ☐ Not Acceptable
*Justification if conditionally acceptable (If any):
REVIEWED BY:
APPROVED BY:

Page 9 of 9
<TEMPLATE>
Corporate IT
FUNCTIONAL REQUIREMENT
Supersedes: SPECIFICATION FOR <SYSTEM NAME>
1.0 INTRODUCTION
Purpose
<This document should capture detailed solution provided against user
requirements specification (URS)>
Scope
The solution comprises of following aspects:
 Security / Regulatory Specifications
 Technical Specifications
 Software Functionality Specifications
2.0 SYSTEM OVERVIEW
System Functions
<This section shall describe the system function in detail>
Business Perspective
<This section shall describe the function view of the business>
3.0 SYSTEM SPECIFICATIONS

<This section shall specify the functional specification for the entire requirement in
URS>.
3.1 Security / Regulatory Specifications: <This section shall detail all security
specifications that will be followed. This should include any special business control
and data security requirements of the system. These should include protection from
accidental or malicious access, use, modification, destruction or disclosure of the
system. For example, access restriction, authorization checks, critical transaction &
reports access, etc. Security issues related to personnel, communications and
physical protection of computer facilities should also be addressed. Focus should
be on system-specific requirements, with reference to the enterprise procedures
and policies applicable to all the sites> (including 21 CRF Part 11/Electronic
Records/Electronic Signatures (ER / ES))

Page 1 of 3
<TEMPLATE>
Corporate IT
SPECIFICATION FOR <SYSTEM NAME>
FRS ID / Functional Requirement Description

Section No.
3.2 Technical Specifications: <This section shall describe the specifications related to
general characteristics of the intended users of the system, interface with the system etc.>

Section No.
3.3 Software Functionality Specifications: <This section shall specify the functional
requirements i.e., what the system shall do, reporting functionalities (if applicable), etc. It is
appropriate to partition specifications into subsections>

Section No.

4.0 ABBREVIATIONS:

ER : Electronic Records
ES : Electronic Signatures
CFR : Code of Federal Regulations
URS : User Requirement Specification
FRS : Functional Requirement Specification
5.0 REFERENCES:
<This section shall provide a complete list of documents referenced in the FRS.
Each document is identified by title & identity and for external documents,
publishing organization and version is required>.

Page 2 of 3
<TEMPLATE>
Corporate IT
SPECIFICATION FOR <SYSTEM NAME>

7.0 APPROVALS:
PREPARED BY:
REVIEWED BY:
APPROVED BY:

Page 3 of 3
<TEMPLATE>
Corporate IT
FUNCTIONAL RISK ASSESSMENT FOR <SOFTWARE NAME> FOR <PURPOSE>
Supersedes:
1.0 INTRODUCTION
1.1 Purpose
<This document should capture detailed risk assessment against each user requirements specification (URS) points to
determine the level of validation activities.>
1.2 Scope
The solution comprises of following aspects:
 Security / Regulatory Specifications
 Technical Specifications
 Software Functionality Specifications
2.0 FUNCTIONAL RISK ASSESSMENT GUIDANCE:
2.1. Regulatory (GxP) Impact Assessment:

Based on the following criteria, the requirement is categorized as "GxP Impact" (G) or "No GxP Impact" (N).
G If requirement has regulatory (GxP) impact, then GxP Impact is “G”. A requirement or a process is to have "GxP
Impact", if it has an impact on Clinical, Laboratory, Manufacturing Practices. For example, if the functionality
impacts product manufacturing, packaging, holding, distribution, identity, strength, purity or safety, impacts
patient safety etc.
N If requirement has No regulatory (GxP) impact, then GxP Impact is “N”.
Note: Select G/N in the GxP Impact column of FRA sheet as identified by the above criteria

Page 1 of 5
<TEMPLATE>
Corporate IT
Doc. No.: <Doc. No.> FUNCTIONAL RISK ASSESSMENT FOR <SOFTWARE NAME> FOR <PURPOSE>
2.2. Business Impact Assessment:

Business Impact shall be assessed according to the following criteria:
High (H) A requirement or a process is said to have “High” Business Impact, if it has an impact on overall functionality of
the business. For Example, if the functionality has an impact to Company’s revenue, or interruption to business
transactions preventing it from proceeding further, etc, then the functionality can be classified to have High
Business Impact
Medium A requirement or a process is said to have “Medium” Business Impact, if the functionality has an impact on a
(M) specific process that affects a department or an individual or the functionality has an impact on highly significant
business process but would have a work around to continue business
Low (L) A requirement or a process is said to have “Low” Business Impact, if the functionality has minimal or no impact
on the functionality of the system. Functions relating to User Interface, Accessibility etc., may be classified as
Low Business Impact
2.3. Functional Impact Assessment:

Functional Impact shall be assessed according to the following criteria:
High (H) A requirement or a process is said to have “High” functional impact, if it has an impact on overall functionality of
the business.
Medium A requirement or a process is said to have “Medium” functional impact, if the functionality has an impact on a
(M) specific process that affects a department or an individual or the functionality has an impact on highly significant
business process but would have a work around to continue business
Low (L) A requirement or a process is said to have “Low” functional impact, if the functionality has minimal or no impact
on the functionality of the system. Functions relating to User Interface, Accessibility etc., may be classified as
Low Business Impact

Page 2 of 5
<TEMPLATE>
Corporate IT
2.4. Error Exposure Assessment:
Error exposure assessment shall be assessed according to the following criteria:

High (H) Customized, then the Error Risk is “High”. A requirement or a process is said to be customized, if there is code
change to create functionality that is not available.
Medium Configured, and then the Error Risk is “Medium”. A requirement or a process is said to be configured, if the
(M) functionality is created by setting up of Application parameters to meet the business requirement.
Low (L) Neither customized not configured, and then the Error Risk is “Low”.
2.5. Risk Class Matrix Table
Functional, Business Impact Risk Class Matrix
Business Impact Error Exposure
High Medium Low High Medium Low
High H H H High H H H
Functional
Function
Medium H M M , Business Medium H M M
al Impact
Impact
Low M L L Low M L L

Page 3 of 5
<TEMPLATE>
Corporate IT
2.6. Testing requirement as per Risk Class:
High Validation Testing (Including testing of positive and negative

scenarios)
Medium Functional Testing covering only positive scenarios
Low Selective Testing based on Business and Functional Risk
3.0 FUNCTIONAL RISK ASSESSMENT:

Assessment
Req Requirement GxP Business Functional Error
Risk Testing Approach Remarks
ID Description Impact impact Impact Exposure
Class
(G/N) (H /M /L) (H /M /L) (H /M /L)
4.0 ABBREVIATIONS:
CSS: Computer Software System

FRA: Functional Risk Assessment


Page 4 of 5
<TEMPLATE>
Corporate IT
6.0 APPROVALS:
PREPARED BY:
REVIEWED BY:
APPROVED BY:

Page 5 of 5
<TEMPLATE>
Corporate IT
Doc. No.: <Doc. No.> DESIGN AND CONFIGURATION SPECIFICATION
Supersedes: FOR <SYSTEM NAME>
1.0 INTRODUCTION
1.1. Purpose
To define the purpose of Design and Configuration Specification for <Software

name>
1.2. Scope
<This section shall identify the design scope and business process to be
supported by the system and / or shall also identify the configuration of the
installed system.>
Note: Sections or subsections in this template can be removed whenever not

required.
2.0 FUNCTIONAL DESIGN

2.1 Business Process Description
<A brief design overview>.

2.2 Process Flows and system architecture
<Detailed Process Flow and system architecture>
2.3 Hardware design specification (Server and client) (as applicable):
Parameter Value
Server type Physical/Virtual
Make and Model
Processor name
Memory (RAM)
Hard disk (Total)
Network Mode ☐ Standalone ☐ LAN Connected
<Table and rows can be added or removed as per applicability>

Page 1 of 5
<TEMPLATE>
Corporate IT
DESIGN AND CONFIGURATION SPECIFICATION
FOR <SOFTWARE NAME>
2.4 Software design specification
Parameter Value
System Type ☐ HMI ☐ IPC ☐ Normal PC
Software name and
version
Operating system
Database software
User Authentication
☐ Local ☐ LDAP ☐ Nil
Mode
Details (if Any):
☐ Yes ☐ No
User Privilege Matrix
Note: Attach draft /final privilege matrix copy
☐ ASCII Flat File ☐ Encrypted Flat File ☐
Raw Data Type Local Database ☐ Server Database ☐ No
Data
Audit Trail Feature ☐ Yes ☐ No
Data Storage minimum
capacity
Data Storage Path
Back up Type ☐ Auto Backup ☐ Manual Backup
2.5 System policy
Parameter Value
Set password expiry
period
Set auto lock out
duration
Number of invalid
password attempts
Minimum password
length
Password complexity
(At least
Page 2 of 5
<TEMPLATE>
Corporate IT
FOR <SOFTWARE NAME>
Parameter Value
alphanumeric)
3.0 TECHNICAL DESIGN (for GAMP Category-5 Systems)

3.1 Screen Layout
Screen Number Description

Dictionary
Field Field Checkbox/
Type / Mandatory
Name Description Radio button
Custom Type
C/R
C/R
C/R
C/R
Sample screenshot or layout of the screen
3.2 Report Output Format
Field Field Dictionary Type /

Comments
Name Description Custom Type
3.3 Table Fields
Table Name Description

Field Domain/ Search
Field Name Key Field
Description Custom Type Help
3.4 Other Objects

Include objects other than those mentioned above.

Page 3 of 5
<TEMPLATE>
Corporate IT
FOR <SOFTWARE NAME>
3.5 Processing Logic
3.5.1 Selection Screen / Input Parameters

Selection screen fields.
3.5.2 Processing Logic / Pseudo code
Selection for Pseudo code.
3.5.3 Output Details
Sample report output format.
3.5.4 Audit and Error Handling Requirements
Sample report output format.
3.5.5 Other Specification
Include specifications other than those mentioned above
3.6 Detailed Design
A detailed design / pseudo code to be filled up by the developer with
comments.
3.7 Issues
List out the issues related to the development of the Design Specification.
Issue Found Description Person Status Issue
on Responsible Resolved on
4.0 ABBREVIATIONS:
<This section shall define any acronyms and key words used in the instruction.>
5.0 REFERENCES:
<Reference Document if any Ex: URS>


Page 4 of 5
<TEMPLATE>
Corporate IT
FOR <SOFTWARE NAME>
7.0 APPROVALS:
PREPARED BY:
REVIEWED BY:
APPROVED BY:

Page 5 of 5
<TEMPLATE>
Corporate IT
VALIDATION PROTOCOL FOR <SOFTWARE NAME>
Supersedes:
Validation Protocol

Page 1 of 11
<TEMPLATE>
Corporate IT
Doc. No.: <Doc. No.> VALIDATION PROTOCOL FOR <SOFTWARE NAME>
TABLE OF CONTENTS
1.0 PURPOSE ............................................................................................................ 4
2.0 SCOPE ................................................................................................................. 4
3.0 RESPONSIBILITIES............................................................................................. 4
4.0 SYSTEM DETAILS: .............................................................................................. 4
5.0 TECHNICAL DETAILS ......................................................................................... 5
6.0 IMPLEMENTATION METHODOLOGY................................................................. 5
7.0 DATA MIGRATION............................................................................................... 5
8.0 VALIDATION APPROACH AND DELIVERABLES............................................... 5
8.1 User Requirements Specification ......................................................................... 6
8.2 Risk Assessment .................................................................................................. 6
8.2.1 GxP Assessment ....................................................................................... 6
8.2.2 Functional Risk Assessment ...................................................................... 6
8.3 Vendor Audit......................................................................................................... 6
8.4 Functional Requirements Specification................................................................. 7
8.5 Design and Configuration Specification ................................................................ 7
8.6 Testing.................................................................................................................. 7
8.6.1 INSTALLATION QUALIFICATION ............................................................. 7
8.6.2 IQ TEST PLAN........................................................................................... 7
8.6.3 OPERATIONAL QUALIFICATION ............................................................. 8
8.6.4 OQ TEST PLAN......................................................................................... 8
8.6.5 PERFORMANCE QUALIFICATION........................................................... 8
8.6.6 PQ TEST PLAN ......................................................................................... 8
8.7 System Release Certificate .................................................................................. 9
8.8 Traceability Matrix:................................................................................................ 9
8.9 Validation Summary Report:................................................................................. 9
9.0 DOCUMENTATION .............................................................................................. 9
10.0 TRAINING ............................................................................................................ 9
11.0 STANDARD OPERATING PROCEDURES.......................................................... 9
12.0 DEVIATIONS...................................................................................................... 10
13.0 CHANGE CONTROL.......................................................................................... 10
14.0 ACCEPTANCE CRITERIA ................................................................................. 10
15.0 ABBREVIATIONS:.............................................................................................. 10
16.0 REVISION HISTORY:......................................................................................... 10
17.0 APPROVAL ........................................................................................................ 11

Page 2 of 11
<TEMPLATE>
Corporate IT
ATTACHMENTS
 Installation qualification test script (as applicable)

 Operational qualification test script (as applicable)
 Performance qualification test script (as applicable)

Page 3 of 11
<TEMPLATE>
Corporate IT
1.0 PURPOSE
The objective of this Validation Protocol (VP) is to provide documented evidence for
the deliverables and approach that the hardware and software for this system is
accurately and reliably installed and operational according to its installation
requirements and operational/functional requirements as listed in URS (<URS Doc.
No.>) and change details as defined in change control (Change Control No. <CCP
No.>) approved on <dd/mm/yyyy>. This VP describes the system and the sequence of
validation activities that will be carried out at each qualification stage. This document
will ensure that the validation approach used is pre-approved and executed using pre-
defined acceptance criteria. Validation requirements specified in this protocol are in
accordance to the current Corporate VMP for Computerized Systems (VMPCS-HO)
and consistent with the requirements of the applicable regulatory agencies.
Execution of this protocol will provide a high degree of assurance that;

 The hardware and software are accurately and reliably installed according to its
installation requirements,
 The system can consistently and reliably produce results meeting pre-defined
acceptance criteria thereby, demonstrating that the system is suitable for its intended
use.
2.0 SCOPE
(Describe the details of following at high level, as applicable)
 Change control details.
 Project details.
 Impacted department/function/site
 Interfaced systems.
 Impacted documents
 Client details, if any
 Etc.
3.0 RESPONSIBILITIES
Responsibilities for entire validation process will be followed as per current SOP
SOP_MUM_ITP_008333 titled “Validation of computerized software system”.
(site specific responsibilities can be documented in this section)
4.0 SYSTEM DETAILS:

(Describe the details of system.)

Page 4 of 11
<TEMPLATE>
Corporate IT
5.0 TECHNICAL DETAILS

(Describe brief details about below points.)
 System details (Name, Version) and Hardware/software components (Architecture/
Diagram)
 System functionalities/features.
 System interfaces (if any)
6.0 IMPLEMENTATION METHODOLOGY

Describe below details about how system is deployed, configured, installed:
1. System deployment and configuration methodology.
2. Mention scope of implementation in case of multiple modules/large scale system.
3. Mention system release and go live strategy
7.0 DATA MIGRATION

(Describe below details if data is to be migrated as part of same change control with
below) (if applicable, or else mention as not applicable)
 Data migration strategy
1. What will be data/data size
2. How data will be migrated (Process/Tools)
 Verification strategy for migrated data.
8.0 VALIDATION APPROACH AND DELIVERABLES

This section includes all information to complete the qualification stages till the system
release. Validation activities for system will be performed according to this protocol.
Below mentioned validation deliverables shall be created, reviewed and approved as

part of this Validation project.
(Describe applicable deliverables as per project/change)
 GxP Assessment (GxPA)

 User Requirements Specification (URS)
 Vendor Audit checklist (VAC)
 EDC Assessment checklist (EAC)
 Functional requirement specification (FRS)
 Functional Risk assessment (FRA)
 Design and/or Configuration Specifications (DCS)
 Validation Protocol (VP)
 Installation Qualification (IQ)
 Operational Qualification (OQ)
 Performance Qualification (PQ)
Page 5 of 11
<TEMPLATE>
Corporate IT
 Validation Summary Report (VSR) with Traceability Matrix (TM)

 System Release Certificate (SRC)
Note that IQ (Installation Qualification), OQ (Operational Qualification), and PQ
(Performance Qualification) will be performed using pre-approved test scripts as part of
Validation Protocol.
8.1 User Requirements Specification

User Requirements Specification (URS) (Doc.No. xxx) is approved on dd/mm/yyyy to
define the user expectations regarding security and regulatory requirement, system
functionalities & technical requirements etc. URS is defined by the user department of
the system which will be the basis for the validation acceptance criteria.
8.2 Risk Assessment

8.2.1 GxP Assessment
GxP Assessment (GxPA) (Doc.No.xxx) is approved on dd/mm/yyyy, to
determine GxP impact and applicability of Electronic Record/Electronic
Signature regulation of subjected system. As per the assessment, below are
the observations.
 The system is GxP impacting/Non Impacting.
 Electronic Record Regulation is Applicable/Not Applicable to the
system.
 ES Regulation is Applicable/Not Applicable to the system.
 The system is classified as GAMP Category (3/ 4/ 5).
8.2.2 Functional Risk Assessment
Functional risk assessment (FRA) (Doc.No.xxx) is approved on dd/mm/yyyy
for the system based on system complexity to determine potential risk and
control measures. Functional risk assessment shall be used to determine rigor
of testing during validation process.
(if applicable, else mention as not applicable.)
8.3 Vendor Audit

(Describe the vendor audit details based on GAMP category of the system)
<System has been categorized as Category-4/5, hence Vendor audit has been
performed and vendor audit checklist (VAC) (Doc.No.xxx) is approved on
dd/mm/yyyy.> OR
<System has been categorized as Category- 3 hence vendor audit is not required >

Page 6 of 11
<TEMPLATE>
Corporate IT
8.4 Functional Requirements Specification

Functional Requirements Specification (FRS) (Doc.No.xxx) is approved on
dd/mm/yyyy to define the system functionalities based on user requirement
specification.
(if applicable, else mention as not applicable.)
8.5 Design and Configuration Specification

Design and Configuration Specification (DCS) (Doc.No.xxx) is approved on
dd/mm/yyyy to define the system design and configuration details based on
Functional requirement specification. (if applicable, else mention as not applicable.)
8.6 Testing
Test scripts are created, and pre-approved to perform necessary IQ/OQ/PQ activities.
Each test script will include test objective, testing stage (IQ/OQ/PQ), testing
environment, pre-requisite information, test steps, acceptance criteria, deviation
details and conclusion. Each test step will be listed with the expected results. Testing
rigor will be determined based on Functional Risk Assessment.
Observed results and relevant input data will be captured during the execution, as
applicable. Any deviation observed during testing shall be documented, investigated,
resolved and summarized in respective TS & VSR.
All user requirements shall be mapped through Functional requirement specifications
(as applicable) and test scripts in Traceability Matrix section of Validation Summary
Report.
OQ testing shall be performed after IQ execution is completed and all IQ test scripts
are approved. Similarly, PQ shall be performed after OQ execution is completed and
all are approved.
8.6.1 INSTALLATION QUALIFICATION

Installation Qualification (IQ) is to provide documented verification that a
system is installed according to written and pre-approved specifications. IQ
tests will be performed in Validation / Production environments (describe
Applicable Environment) as per installation, design and configuration
requirements. This will include testing for installation of servers, application,
utilities and clients (As applicable).
8.6.2 IQ TEST PLAN

This section describes the test scripts & objective details to carry out the
Installation Qualification activity.
Page 7 of 11
<TEMPLATE>
Corporate IT
Test Script Test ID

Sr. No. Objective
document number
<Rows can be added if required>
8.6.3 OPERATIONAL QUALIFICATION

Documented verification that each component of the computerized system
performs as intended throughout on anticipated operating ranges. OQ tests will
be performed in Validation / Production environments [describe Applicable
Environment] as per qualification activities. This will include testing for Security
& regulatory requirements, technical requirements, software functional
requirements etc. User Roles and Privileges shall be identical in Validation and
Production environments wherever validation and production environments are
available.
8.6.4 OQ TEST PLAN

Operational Qualification activity. 21 CFR Part 11 & EU Annex 11 verification
shall be performed using pre-approved standard test script (OQ-TS-EDC-XX,
XX represents version number) as part of OQ testing.
Test Script
Sr. No. Test ID Objective
document number
8.6.5 PERFORMANCE QUALIFICATION

Performance Qualification (PQ) is to provide documented evidence that the
system is capable of performing or controlling the activities of the business
processes it is required to perform or control according to written and pre-
approved specifications, demonstrating that the system is suitable for business
use. PQ tests will be performed in Production environments as per qualification
activities.
8.6.6 PQ TEST PLAN

Performance Qualification activity.

Page 8 of 11
<TEMPLATE>
Corporate IT
Test Script
Sr. No. Test ID Objective
document number
8.7 System Release Certificate

Validation activities shall be summarised along with system release Certificate
(SRC). System will be released for routine operation through system release
certificate as part of validation report once all the applicable activities mentioned in
validation protocol are completed successfully and meeting the acceptance criteria.
In case of multiple clients, separate system release certificate shall be created for
each client. All these reports shall be summarised in VSR.
8.8 Traceability Matrix:

The Traceability Matrix (TM) shall be created as part of validation summary report to
list out user requirements, system specifications (FRS) (if any) and corresponding
test script reference to demonstrate that the requirement is tested before releasing
to business use.
8.9 Validation Summary Report:

Validation Summary Report (VSR) shall be created at the end of the all the validation
activities (inclusive of all applicable clients mentioned in the scope of this document)
to summarize all the validation activities performed as per approved validation
protocol. This report will list out details regarding outcome of identified validation
deliverables, issues/open actions (if any) and system release certification.
9.0 DOCUMENTATION
All the validation documentation shall be created as per current work instruction
(WI_MUM_ITP_009073) for Good documentation practice & naming standards.
10.0 TRAINING
The team involved in the validation of the system will have sufficient education,
training, and experience to complete the intended project. The users of the system
will be granted system access after successful completion of training. Formal training
activities will be performed to ensure the appropriate use of the system.
11.0 STANDARD OPERATING PROCEDURES

All Standard Operating Procedures applicable for the system will be approved before
the system is released for Production/routine GxP operations.

Page 9 of 11
<TEMPLATE>
Corporate IT
System specific procedures related to the use, maintenance and administration of the
system will be approved and in effect.
12.0 DEVIATIONS
Any deviations from the approved validation protocol and approved test scripts shall
be investigated and documented as per current procedures.
13.0 CHANGE CONTROL

A standard Change Control Process shall ensure that all new systems and changes
to existing validated computerized systems are implemented in a compliant manner
to ensure that the system remains in a validated state throughout its lifecycle. Any
change in validated computerized system during routine GxP operation shall follow
the current change control procedure.
14.0 ACCEPTANCE CRITERIA

The system will be accepted for business use if the following requirements are met:
 All installation, operational and performance requirements defined in the URS,

FRS and DCS (as applicable) have been satisfied.
 All IQ/OQ/PQ (as applicable) testing results are documented and approved.
 All deviations observed during entire validation are appropriately recorded,
investigated and closed.
 All relevant Standard Operating Procedures (SOPs) for the system are
obsoleted/created/modified, approved.
 All requirements mentioned in the scope of this validation protocol are satisfied.
 The criteria established in the validation process for system release in business
use have been met.
15.0 ABBREVIATIONS:
<if any>

Version
No.

Page 10 of 11
<TEMPLATE>
Corporate IT
17.0 APPROVAL
PREPARED BY:
REVIEWED BY:
APPROVED BY

Page 11 of 11
<TEMPLATE>
Corporate IT
<IQ/OQ/PQ> TEST SCRIPT FOR <SOFTWARE NAME> FOR <PURPOSE>
Supersedes:
<Supersede Doc. No./Nil>
1.0 PRE APPROVAL:
PREPARED BY:
REVIEWED BY:
APPROVED BY

Page 1 of 6
<TEMPLATE>
Corporate IT
Doc. No.: <Doc. No.> <IQ/OQ/PQ> TEST SCRIPT FOR <SOFTWARE NAME> FOR <PURPOSE>
2.0 TEST SCRIPT:

Test ID
Reference Validation
Protocol No.
Hostname Equipment ID
Iteration No.
Test Title
Testing Stage <IQ / OQ / PQ>
Testing Environment Validation / Production
Objective
Prepared By
Pre-Requisite

Page 2 of 6
<TEMPLATE>
Corporate IT
Deviatio
Pass /
Expected Observed Performed Sign/ n no. /
Step ID Step Fail
Result Results by Date Remarks
/ NA
if any
Pass 
Fail 
NA 
Pass 
Fail 
NA 
<Rows can be added or removed as required.>

Page 3 of 6
<TEMPLATE>
Corporate IT
3.0 CONCLUSION:  PASS/ FAIL

Conclusion for <Installation Qualification / Operational Qualification>:
Approved <IQ/ OQ> test script has been executed in <Validation / Production> environment for <Installation /Operational
Qualification>. Test script execution has been started on ___________ and completed on _____________. All the
observed deviations are recorded, investigated and closed. (if any)
With approval of this Test script, <OQ / PQ> execution in <Validation / Production> environment can be commenced.
Conclusion for Performance Qualification:
Approved PQ test script has been executed in Production environment for Performance Qualification. Test script
execution has been started on _____________ and completed on _____________. All the observed deviations are
recorded, investigated and closed. (if any)
With approval of this Test script, Validation summary report etc. can be commenced.
< Conclusion can be modified based on Test script stage>

Page 4 of 6
<TEMPLATE>
Corporate IT
4.0 ATTACHMENTS:
Sr. No. Attachment description Number of pages


Page 5 of 6
<TEMPLATE>
Corporate IT
6.0 POST APPROVAL:
COMPILED BY:
REVIEWED BY:
APPROVED BY

Page 6 of 6
<TEMPLATE>
Corporate IT
<IQ/OQ/PQ> ACTUAL TEST RESULT FOR <SOFTWARE NAME> FOR <PURPOSE>
TEST SCRIPT REFERENCE DETAILS
Test Script Doc. No.:

Test ID: Iteration No.:
Step ID: 001

Description of screen print (If any):
<Screenshot> and/or <Annexure Number>
Step ID: 002

Step ID: 003

Note: In case of any step require data print, the same shall be sequentially numbered and attached to this document
referring that annexure no. under corresponding Step. Print out can be taken both sides of the paper.
COMPILED BY (SIGN/DATE):
<Signature of compiled by shall be done in last page of ATR>
Page 1 of 1
<TEMPLATE>
Corporate IT
Deviation No.:
DEVIATION FORM FOR COMPUTER SOFTWARE
_______________________ SYSTEM
Deviation Form
Section I: Deviation Description and Investigation Details
Severity (Check
Reference Details Type (Check One):
One):
Test Script Doc. No.: Test Script Critical
Other Major
Test ID:
Iteration Number:
Step ID:
Deviation Description:
Investigation Details:
Impact Assessment:
Initiated By: Signature: Date:

Section II: Proposed Resolution and Follow-up Actions
Re-testing Required (Test Reviewer check as applicable):

Entire Script Individual Step(s) None NA
List retesting if other than entire script:

________________________________________________

Page 1 of 2
<TEMPLATE>
Corporate IT
Deviation No.: DEVIATION FORM FOR COMPUTER SOFTWARE

SYSTEM
_______________________
Deviation Closure tentative due

Date:__________________________________________________________
Prepared By: Signature: Date:

Reviewed
Signature: Date:
By:
Approved By
(Site Signature: Date:
QA/CQA):
Section III: Follow-up Actions Completed
Description of Corrective Actions and Preventive Action Completed:
Confirmed
Signature: Date:
By:
Section IV: Final Disposition
Conforms to Requirements: Yes No (If ‘No’, provide the explanation in
comments column below)
Comments:
Reviewed By: Signature: Date:

Approved By (Site
Signature: Date:
QA/CQA):

Page 2 of 2
<TEMPLATE>
Corporate IT
VALIDATION SUMMARY REPORT FOR
Supersedes: <SOFTWARE NAME> FOR <PURPOSE>
VALIDATION SUMMARY REPORT

Page 1 of 7
<TEMPLATE>
Corporate IT
<SOFTWARE NAME> FOR <PURPOSE>
TABLE OF CONTENTS
1.0 PURPOSE ............................................................................................................ 3
2.0 VALIDATION OVERVIEW/SUMMARY................................................................. 3
3.0 TESTING SUMMARY........................................................................................... 3
4.0 DEVIATIONS AND RESOLUTION: ...................................................................... 5
5.0 SUPPORTING DOCUMENTS .............................................................................. 5
5.1 Vendor Audit & EDC Assessment ................................................................... 5
5.2 Training Records ............................................................................................. 5
5.3 Standard Operating Procedures...................................................................... 5
6.0 EXISTING SYSTEM RETIREMENT ..................................................................... 6
7.0 INDEXING OF COMPUTER SOFTWARE SYSTEM ............................................ 6
8.0 SUMMARY OF VALIDATION DELIVERABLES: .................................................. 6
9.0 CONCLUSION...................................................................................................... 6
10.0 SYSTEM RELEASE CERTIFICATION ................................................................. 7
11.0 ABBREVIATIONS:................................................................................................ 7
12.0 REVISION HISTORY............................................................................................ 7
13.0 APPROVAL .......................................................................................................... 7

Page 2 of 7
<TEMPLATE>
Corporate IT
1.0 PURPOSE
The purpose of this Validation Summary Report (VSR) is to summarize the activities
and deliverables that were identified in validation protocol to validate the system through
the applicable qualification activities. It is also to ensure that the system was qualified in
compliance with all applicable regulatory requirements and procedures.
The Validation Team was responsible for coordinating all validation activities performed
to qualify and verify the system. The Technical, Business and Validation representatives
assisted in the validation process by providing their expertise in preparing and executing
test procedures and supporting documents.
2.0 VALIDATION OVERVIEW/SUMMARY

Change control (change control number#____) was initiated and approved on
dd/mm/yyyy to implement the subjected system/change. Validation activities for the
system performed successfully as per approved validation protocol <protocol no.> dated
dd/mm/yyyy by the individuals responsible for the functional areas prior to its release.
The validation documents were prepared by a Technical, Business and Validation
representatives and reviewed & approved by the Individuals responsible for the
functional areas. All the validation documents including executed tests scripts are
recorded in this report. In conclusion, the system was successfully validated & released
for routine use in the Production environment.
The validation activities demonstrated that
 The hardware and software are accurately and reliably installed according to its
installation requirements,
 The system can consistently and reliably produce results meeting pre-defined
acceptance criteria thereby, demonstrating that the system is suitable for its
intended use.
3.0 TESTING SUMMARY

3.1 IQ Testing Summary:
The IQ activities in <validation / Production environment> were started on <date>
and completed on <date>. All IQ activities were completed successfully as per
approved test script. The acceptance criteria outlined in the test script have been
met.
The following is the summary of the IQ tests performed and their status

Page 3 of 7
<TEMPLATE>
Corporate IT
Sr. Test Script Test ID Status Deviations (if

No. document number any)
3.2 OQ Testing Summary:

The OQ activities in <validation/production environment> were started on <date>
and completed on <date> after post approval of the IQ test scripts. All OQ
activities were completed successfully as per approved test script. The
acceptance criteria outlined in the test script have been met.
The following is the summary of the OQ tests performed and their status
Sr. Test Script Status Deviations (if

Test ID
3.3 EDC OQ Testing summary (i.e. 21 CFR Part 11 & EU Annex 11 Testing):
The compliance of the system with the requirements of Electronic Records and
Electronic Signatures (US Title 21 Code of Federal Regulations Part 11 and
Annex 11) was verified on <date> by executing <OQ-TS-EDC-01>test script as
part of OQ. The system was found to be in compliant with the 21 CFR Part 11 and
Annex 11 requirements. The IQ activities in Production environment commenced
on <date> and were completed on <date> after post approval of the OQ Test
scripts.
3.4 PQ Testing Summary:

The PQ activities in Production Environment were started on <date> and
completed on <date> after post approval of the OQ Test script and IQ of
Production environment. All PQ activities were completed successfully. The
acceptance criteria outlined in the test script have been met.
The following is the summary of the PQ tests performed and their status
Sr. Test Script Deviations (if

Test ID Status
<In case of vendor IQ/OQ document, record details in VSR>.

Page 4 of 7
<TEMPLATE>
Corporate IT
3.5 Traceability Matrix

Traceability Matrix has been developed for list of user requirements, functional
requirements (if applicable) and corresponding test script reference to
demonstrate that the requirement is tested before system release to business use.
Sr. Requirement Test ID and

URS ID FRS ID Comments
No. Description Step ID
4.0 DEVIATIONS AND RESOLUTION:

The following is the summary of the deviations occurred during IQ, OQ and PQ tests
execution and their status.
Test
Sr. Step Deviation Deviation
Script Resolution Status
No. details No. Details
ID
(if no deviations found, then mention “No deviations found during execution of IQ, OQ
and PQ”.)
5.0 SUPPORTING DOCUMENTS
The following documents were prepared to support the validation activities of the
system.
5.1 Vendor Audit & EDC Assessment
Vendor audit was performed for the system on <date> and approved on <date>.
Observations & conclusion regarding vendor was summarized in the vendor audit
checklist. EDC assessment was performed for the system on <date> and approved
on <date>.
5.2 Training Records
All members involved in the creation, execution (as applicable), review and
approval of validation documents are trained. Those involved in validation activities
are trained on respective SOPs <Describe the applicable SOP details> <Attach the
Training attendance log>.
Employees, who have access and will utilize the system, will be trained for intended
purposes as defined in the relative business procedure(s).
5.3 Standard Operating Procedures
All Standard Operating Procedures applicable for the system were approved and
in effect.
Page 5 of 7
<TEMPLATE>
Corporate IT
System specific procedures related to the use, maintenance, calibration and

administration of the system were approved and in effect.
Sr. SOP/WI Version Document Status Effective
Title
No. No. No. (Created/Updated/Retired/Available) Date
6.0 EXISTING SYSTEM RETIREMENT

Describe the CCP details for retirement of existing system. (if applicable, else mention
as Not applicable)
7.0 INDEXING OF COMPUTER SOFTWARE SYSTEM
System information has been entered/updated in Annexure
ANNEX_MUM_ITP_037352. (Attach the updated ANNEX_MUM_ITP_037352-
Addition/removal of Computerized Software System for inventory index).
8.0 SUMMARY OF VALIDATION DELIVERABLES:
Sr. Approval
Deliverable Name Document number Status
No. Date
1
2
9.0 CONCLUSION
All qualification activities were performed as per approved validation protocol meeting
below mentioned acceptance criteria.
 All installation, operational and performance requirements defined in the URS,

FRS and DCS (as applicable) have been satisfied.
 All IQ/OQ/PQ testing has been completed successfully, results are documented
and approved.
 All deviations observed during entire validation are appropriately recorded,
investigated and closed.
 All relevant Standard Operating Procedures (SOPs) for the system are
obsoleted/created/modified, approved and are in effect.
 All requirements mentioned in the scope of this validation protocol are fully
satisfied.
 The criteria established in the validation process for system release in business
use have been met.

Page 6 of 7
<TEMPLATE>
Corporate IT
Upon approval of this report, the system is certified for intended purpose and released
for business use.
10.0 SYSTEM RELEASE CERTIFICATION
This is to certify that (Software Id/Name/Version) has been successfully validated as
per approved validation protocol, regulatory requirements and in-house procedures.
This certifies that system is fit for intended use.
Sr. No. Host Name/system name (as applicable)
11.0 ABBREVIATIONS:
<if any>

13.0 APPROVAL
PREPARED BY:
REVIEWED BY:
APPROVED BY:

Page 7 of 7
<TEMPLATE>
Corporate IT
SYSTEM RELEASE CERTIFICATE FOR <SOFTWARE
Supersedes: NAME> FOR <PURPOSE>
1.0 System Details:
Software Name and version:
Client Details:
Intended use of software:
2.0 Validation Summary:

Validation of above mentioned client/s has been completed successfully and met all the
acceptance criteria. Summary of the IQ/OQ/PQ tests performed and their status:
Test Start
Qualification
Sr. Script Date- Deviations
Stage Environment Status
No. document End (if any)
(IQ/OQ/PQ)
number Date
3.0 Training Records

All members involved in the creation, execution (as applicable), review and approval of
validation documents are trained. <Describe the applicable SOP details> <Attach the Training
attendance log>.
Those involved in validation activities are trained on respective SOPs. Employees, who have
access and will utilize the system, were trained for intended purposes as defined in the relative
business procedure(s).

Page 1 of 3
<TEMPLATE>
Corporate IT
NAME> FOR <PURPOSE>
4.0 Standard Operating Procedures

All Standard Operating Procedures applicable for the system were approved and in effect.
System specific procedures related to the use, maintenance, calibration and administration of
the system were approved and in effect.
Sr. SOP/WI Version Document Status Effective

Title
No. No. No. (Created/Updated/Retired/Available) Date
5.0 Certification:
This is to certify that system has been successfully validated as per approved validation
protocol, regulatory requirements and in-house procedures. This certifies that system is fit for
intended use. The system shall be maintained in a validated state by performing the changes
to the system as per the current Change Control Procedure for Computer Software System.


Page 2 of 3
<TEMPLATE>
Corporate IT
NAME> FOR <PURPOSE>
7.0 Approvals:
PREPARED BY:
REVIEWED BY:
APPROVED BY:

Page 3 of 3
<TEMPLATE>
Corporate IT
CHANGE VERIFICATION CHECKLIST FOR <SOFTWARE NAME> FOR
Supersedes: <PURPOSE>
<Supersede Doc. No. / Nil>
1.0 PRE APPROVAL:
PREPARED BY:
REVIEWED BY:
APPROVED BY:

Page 1 of 7
<TEMPLATE>
Corporate IT
<PURPOSE>
2.0 CHANGE VERIFICATION CHECKLIST:

Test ID
Reference CCP
No.
Hostname Equipment ID:
Iteration Number
Test Title
Testing
Environment □ Validation / □ Production
Objective
Prepared By
Pre-Requisite

Page 2 of 7
<TEMPLATE>
Corporate IT
<PURPOSE>
Stage: IQ
Deviatio
Expected Observed Pass/Fail Performed Sign/ n no. /
Step ID Step
Result Results /NA by Date Remarks
if any
Pass □
Fail □
NA □
Pass □
Fail □
NA □

Page 3 of 7
<TEMPLATE>
Corporate IT
<PURPOSE>
Stage: OQ
Deviatio
Step ID Step
if any
Pass □
Fail □
NA □
Pass □
Fail □
NA □

Page 4 of 7
<TEMPLATE>
Corporate IT
<PURPOSE>
Stage: PQ
Deviatio
Step ID Step
if any
Pass □
Fail □
NA □
Pass □
Fail □
NA □
Note: IQ, OQ and PQ stages will be identified based on change. All stages may not be applicable for each change. IQ, OQ
& PQ stages (wherever applicable) in this test script shall be executed in sequential manner.

Page 5 of 7
<TEMPLATE>
Corporate IT
<PURPOSE>
3.0 CONCLUSION: □ PASS / □ FAIL

Approved Change Verification Checklist for change has been executed in <Validation / Production> environment to
maintain validated state of GxP system. Test script execution has been started on __________________ and completed
on _____________.
All the observed deviations are recorded, investigated and closed. (if any).
It is concluded that change verification is □ Successful / □ Not successful. Hence it is certified that system is □Fit /
□not Fit for intended use.
4.0 ATTACHMENTS:
<Row can be added or removed as required>


Page 6 of 7
<TEMPLATE>
Corporate IT
<PURPOSE>
6.0 POST APPROVAL

COMPILED BY:
REVIEWED BY:
APPROVED BY:

Page 7 of 7
<TEMPLATE>
Corporate IT
PERIODIC REVIEW REPORT FOR <SOFTWARE
Supersedes: NAME>
<Supersede Doc. No./Nil>
1.0 INTRODUCTION:
1.1 Purpose
This document is used to review <Mention the name of the computerized

system> as part of periodic review.
1.2 Scope
<The scope shall capture the details of the computer software system that is
periodically being verified>.
2.0 PROCEDURE:
After completion of the review, if there any discrepancy found, then perform the risk
assessment for all the risks identified using SOP: SOP_MUM_CQA_009003 to
document the risk rating and mitigation plan for each risk.
3.0 COMPUTERIZED SYSTEM PERIODIC REVIEW REPORT

For each question below evaluate the system and record the observation.
System Details
Site/Location
Date
Department
Client/Computer
Name
Operating System
Software Name(s)
Sr.
Check Point Remarks
No.
1 Review Period From <Date> To <Date>
2 Previous periodic review <Mention doc. no. of previous report>
Page 1 of 3
<TEMPLATE>
Corporate IT
NAME>
Sr.
Check Point Remarks
No.
reports
Changes to the system
(list total number of <Mention the Change control details>
3
changes along with
document numbers)
Deviations, including <Mention the deviation details>
4
frequencies and reasons
New requirements based
on changes in regulatory
5 <Mention, if any new requirements>
guidelines and/or company
procedures/policies
Validation documents and
software is in line with <Mention the name and document no.
6
current business reviewed>
operations
<Mention the SOP(s) reviewed>
7 Applicable SOPs
Source code (if exists with

8 Lupin) review for GAMP <as applicable>
Category-5 systems
Regulatory or any internal <Mention, if any regulatory or internal
9
audit observations audit and closure details>
10 Training of users <Users Training details>
Verification of EDC (OQ-
11 TS-EDC-XX, Where XX <Mention testing details if any>
stand for current version)
Sr.
Observation/Discrepancy Resolution Status
No.

Page 2 of 3
<TEMPLATE>
Corporate IT
NAME>
System’s Validation status Comply/ Not Comply

Revalidation required Yes / No
Next Review Date
Inventory Index & Periodic Review
Yes/No
Schedule updated
Remarks
4.0 REFERENCES:
SOP_MUM_ITP_008333: Validation of Computerized Software System.
6.0 APPROVAL:
PREPARED BY:
REVIEWED BY:
APPROVED BY:

Page 3 of 3
<TEMPLATE>
Corporate IT
SYSTEM RETIREMENT REPORT FOR
Supersedes: <SOFTWARE NAME>
1.0 PURPOSE:
The purpose of this System Retirement Report is to summarize activities performed
during retirement of validated computerized system.
2.0 Retirement activities:

The software system is retired with below listed check points and remarks are
mentioned below.
Sr.
Check Point Remarks
No.
Change control
<Mention Change control details which was initiated for
1 details for
subjected system retirement.>
retirement
Application/software <Mention Software details Name, version, purpose of
2
details. system, validation date>
Reason/justification
3 <Mention the reason for retirement of the system.>
of retirement.
<Mention below statements as applicable as per
Data (generated or respective scenario.
stored data) 1. “Data has been archived in path_______”
4 handling for 2. “System/application has been retained as is with data &
associated system restricted system access”
& user restrictions. 3. “Data has been migrated in new system__________ “>
4. System has been removed from routine use.
Administrator
<Mentioned that “Administrator has been granted the
5 access to required
access for required data for future reference purpose.”>
data.
Hardware <Mention as “Hardware has been handed over to IT
6
(Workstation etc.) department” >
Mention as “Back up schedule has been updated to
7 Back Up schedule
remove the subjected system”

Page 1 of 3
<TEMPLATE>
Corporate IT
<SOFTWARE NAME>
Sr.
Check Point Remarks
No.
Mention as “Addition/removal of computer software
System inventory
8 system has been updated to retire the subjected system”
update
(Refer ANNEX_MUM_ITP_037352).
Applicable
9 Validation Mention as “validation documents <details> are archived”
documentation
10 Applicable SOP Mention “SOP’s <details> are obsoleted or active.”
11 Inventory of retired Mention “Inventory of retired system has been updated in
system and periodic Annexure ANNEX_MUM_ITP_037353”.
verification <Applicable if system/application has been retained as is
schedule with data>
<rows can be added or removed based on each retirement scenario>
3.0 SUMMARY:
After verification of the above check points, it is concluded that <software name> is
retired/discontinued from routine GxP operation and no further action is required.
4.0 REFERENCES:
<if any>

Version
No.

Page 2 of 3
<TEMPLATE>
Corporate IT
<SOFTWARE NAME>
6.0 APPROVAL:
PREPARED BY:
REVIEWED BY:
APPROVED BY:

Page 3 of 3
<TEMPLATE>
Corporate IT
ASSESSMENT FOR LEVERAGING EXISTING INTERNAL
Supersedes: VALIDATION DOCUMENTATION
<Doc. No./ Nil>
Base site:______________________ Reference location:_________________
Software identification
Manufacturer/Vendor Name
Software Name
Software Version
Connected Instrument/Equipment
Name (If any)
Sr.
Item Document number Review comments Action needed
No.
Validation document details (As applicable)
1. GAMP Category
2. URS
3. GxPA
4. VAC
5. EAC
6. FRS
7. FRA
8. DCS

Page 1 of 2
<TEMPLATE>
Corporate IT
ASSESSMENT FOR LEVERAGING EXISTING INTERNAL
VALIDATION DOCUMENTATION
Sr.
Item Document number Review comments Action needed
No.
9. VP
10. IQ TS
11. OQ TS
12. EDC OQ
13. PQ TS
<Rows and listed documents can be added or removed as per applicability>
Name Sign/Date
Compiled By
Reviewed By
Approved By

Page 2 of 2
<TEMPLATE>
Corporate IT
ASSESSMENT FOR LEVERAGING VENDOR DOCUMENT FOR <SOFTWARE
Doc. No.: <Doc. No.> NAME, VERSION>
Sr. Vendor document Vendor document

Lupin review remarks Action needed
No. name number
<Rows can be added or removed>

Conclusion:
Name Sign/Date
Compiled By
Reviewed By
Approved By

Page 1 of 1
<TEMPLATE>
Corporate IT
BOT QUALIFICATION PROTOCOL/REPORT FOR <BOT NAME>
Supersedes: <PURPOSE>
<Supersede Doc. No. / Nil>
1.0 PRE APPROVAL:

PREPARED BY:
REVIEWED BY:
APPROVED BY

Page 1 of 7
<TEMPLATE>
Corporate IT
Doc. No.: <Doc. No.> BOT QUALIFICATION PROTOCOL/REPORT FOR <BOT NAME> <PURPOSE>
2.0 QUALIFICATION DETAILS:

Test ID
Reference CCP
No.
Iteration Number
Test Title
Testing
Environment □ Validation / □ Production
Objective
Prepared By
Pre-Requisite

Page 2 of 7
<TEMPLATE>
Corporate IT
Stage: IQ
Deviatio
Step ID Step
if any
Pass □
Fail □
NA □
Pass □
Fail □
NA □

Page 3 of 7
<TEMPLATE>
Corporate IT
Stage: OQ
Deviatio
Step ID Step
if any
Pass □
Fail □
NA □
Pass □
Fail □
NA □

Page 4 of 7
<TEMPLATE>
Corporate IT
Stage: PQ
Deviatio
Step ID Step
if any
Pass □
Fail □
NA □
Pass □
Fail □
NA □
Note: IQ, OQ and PQ stages will be identified based on respective BOT. All stages may not be applicable for each BOT
validation. IQ, OQ & PQ stages (wherever applicable) in this test script shall be executed in sequential manner.

Page 5 of 7
<TEMPLATE>
Corporate IT
3.0 CONCLUSION: □ PASS / □ FAIL

Approved BOT qualification protocol has been executed in <Validation/Production> environment to validate BOT. Test
script execution has been started on __________________ and completed on _____________.
All the observed deviations are recorded, investigated and closed. (if any).
It is concluded that BOT Qualification is □ Successful / □ Not successful. Hence it is certified that system is □ Fit / □
Not Fit for intended use.
4.0 ATTACHMENTS:
<Row can be added or removed as required>

Page 6 of 7
<TEMPLATE>
Corporate IT
5.0 POST APPROVAL

PREPARED BY:
REVIEWED BY:
APPROVED BY:


Page 7 of 7
SIGNATURE LOG
Reference Change
Control Number
System Name
Validation
Protocol/CVC/Other
Sr. No Name Department Designation Initial/Date

Page 1 of 1
LOG FOR ISSUANCE AND RETRIEVAL OF LOGBOOK
Completed Logbook
Reason Logbook Issued By
Sr. Requested by
Date (Issuance/Re- number (Sign & Submitted Received Remarks
No. (Sign/date)
issuance) assigned Date) by by
(Sign/date) (Sign/date)

Page 1 of 1
ADDITION/REMOVAL OF COMPUTER SOFTWARE SYSTEM FOR INVENTORY INDEX
Location Name
Department
Year
Period
Client ER/ES
ic Last Next
Equip Softwar Identific Applica
GAM Initial Last Revie Perio Perio System Actual Rem Reviewe Appro
ment/ e, Name ation bility Updated
Sr. P Valida Valida w dic dic Status Review arks d by ved By
Instru and number( (ER By (IT
No. Categ tion tion Freque Revi Revi (Active/Re Date (if (User (QA/
ment version s) only/ER dept.)
ory Date Date ncy ew ew tired) any) dept.) CQA)
No. no. (hostna & ES
Date Date
me) /No ER )

Page 1 of 1
INVENTORY OF RETIRED SYSTEM AND PERIODIC VERIFICATION SCHEDULE
Connec
Softw Re 1st Verification 2nd Verification 3rd Verification 4th Verification
ted
are, tire
equipm
Sr. Name me
ent
No. and nt Act
/instru Actu Con Con Conc Actu
versio dat Due Done Due ual Done Due Actual Done Due Concl Done
ment al clusi clusi lusio al
n no. e date By date dat By date date By date usion By
number date on on n date
e
Note: Retired system (wherever applicable) shall be verified annually for physical condition of workstation, System power up, data accessibility and readability
through admin login.

Page 1 of 1
<TEMPLATE>
VENDOR AGREEMENT
Corporate IT
VENDOR AGREEMENT
FOR CONTRACT COMPUTER SYSTEM VALIDATION SERVICES
BY AND BETWEEN
– CONTRACT GIVER-
LUPIN LIMITED
And
-CONTRACT ACCEPTOR (CSV PARTNER)-
_____________________________________________________________
Effective date:
(Date of approval of contract)

Page 1 of 5
<TEMPLATE>
VENDOR AGREEMENT
Corporate IT
This Vendor Agreement has been created between CSV partner and Lupin limited to
provide computer system validation services across Lupin Ltd.
Contract giver Name and Address:
Lupin Limited,
Address:
___________________________________________________________________
CSV Partner Name and Address:

_____________________________________________________________________
_________________________________________________________________
1.0 DEFINITIONS
1.1 Services shall mean – Computer system validation (CSV) activities as per
regulatory guidelines like 21 CFR Part 11 or EU Annex 11 or GAMP5.
1.2 Contract Giver: Lupin Limited
1.3 Contract Accepter or CSV Partner: The party selected to provide CSV
services to Lupin.
1.4 CSV Consultant – will be employee of contract acceptor, having the

necessary educational qualifications and technical expertise.
2.0 SCOPE AND SERVICES
2.1 Services covered by this Agreement can be used for all Lupin sites including
head office (as required).
2.2 CSV partner will provide services for Computer system validation activities
of GxP computerized system.
2.3 Services provided by CSV partner must be in compliance with cGMP
regulatory requirements.
2.4 Lupin will oversight the services provided by CSV partner.
2.5 Lupin may terminate this agreement by giving fifteen (15) days written
notice to CSV partner.
2.6 CSV Partner may terminate their services by providing one month prior
notice.

Page 2 of 5
<TEMPLATE>
VENDOR AGREEMENT
Corporate IT
2.7 Services may stand closed based on approved purchase order/respective
project completion.
3.0 RESPONSIBILITIES
Both parties agree to the following listed responsibilities for all the operations
that are marked with "X" in the respective column that bears its name.
CSV
RESPONSIBILITIES LUPIN
Partner
Provide copies of establishment certifications/licenses (to be
3.1. X
attached).
3.2. Responsible to provide organogram (to be attached). X
Provide customer support and escalation matrix for service

3.3. X
contact, whenever requested (to be attached).
Provide number of years of expertise in Pharmaceutical
3.4. X
industries for CSV services (to be attached).
Provide the name of pharmaceutical industries worked for
3.5. X
CSV services (to be attached).
Evaluation (telephonic or personal interviews) of CSV
3.6. consultant for relevant experience and expertise to perform X
validation activities.
Provide qualification/training records of CSV consultants (to
3.7. X
be attached).
Deployment of CSV resources within timelines at Lupin sites

3.8. X
as per requirements.
Responsible for providing training of applicable procedures to

3.9. X
CSV consultant prior to activity.
3.10. Adhere to follow applicable SOPs while working in Lupin. X X
Responsible to ensure GMP computer systems in Lupin

3.11. premises are validated as per EU Annex 11 or FDA 21CFR X X
Part 11 or GAMP5 and Lupin procedures.
Responsible to complete CSV activities as per pre-defined
3.12. X
timelines.
Responsible to follow good documentation practices of
3.13. X X
Lupin during CSV activities.
Page 3 of 5
<TEMPLATE>
VENDOR AGREEMENT
Corporate IT
CSV
RESPONSIBILITIES LUPIN
Partner
Responsible to maintain integrity and traceability of data
3.14. X
obtained during validation of GxP computer systems.
To carry out/assist in QMS activities and GMP
3.15. X X
activities/documentation.
Contract acceptor should maintain confidentiality of data,
3.16. X
procedures, protocols, report and record related to Lupin.
Obtain prior approval for implementation of any proposed
3.17. changes related to the services provided. After necessary X X
assessment the change shall be authorized to use.
Provide Service in accordance with the applicable approved
3.18. X
agreements.
Lupin reserve the right to take control of ongoing work at any
3.19. moment of time and complete remaining task of in progress X
activity either internally or through any alternate contractor.
In case of any data integrity breach by CSV consultant,
3.20. services of respective CSV consultant shall be discontinued X
immediately.
Responsible to follow environmental, health and safety rules
3.21. X X
and regulations laid down by Lupin.
Accepted By: Contract Acceptor/CSV Partner: ____________________________
Name
Head/ Designee Signature
Conclusion (To be mentioned by Lupin IT-CSV)
Agreement has been reviewed and found satisfactory/Not satisfactory.

CSV partner________________________________ is Approved/Not Approved to provide CSV
services in Lupin.

Page 4 of 5
<TEMPLATE>
VENDOR AGREEMENT
Corporate IT
4.0 APPROVAL:
Reviewed By: IT-CSV: (Lupin Limited)
Name
IT-CSV Head/ Designee Signature

(Name and Sign/Date)
Approved By: Quality Assurance/Corporate Quality Assurance: (Lupin Limited)
Name
Head/ Designee Signature

(Name and Sign/Date)

Page 5 of 5
WI_MUM_ITP_009073
GOOD DOCUMENTATION PRACTICES &
NAMING STANDARDS FOR COMPUTER SOFTWARE SYSTEM
1.0 PURPOSE:
The purpose of this Work Instruction (WI) is to define instructions for Good
Documentation Practices and Naming Standards to be followed throughout the life
cycle of the Computer Software System (CSS) Validation activity.
2.0 SCOPE:
This Work Instruction (WI) shall be applicable to all personnel, employees and contract
staff involved in Computer Software System (CSS) Validation activity.
Good Documentation Practices instructs the standards and procedures that shall be
followed for completing, editing or correcting a GxP document.
3.0 RESPONSIBILITY:
All personnel involved in the GxP document shall be responsible to follow this Good
Documentation Practices.
4.0 INSTRUCTION:
4.1 General Instruction
 Documents shall be clear and legible. The templates are the guideline
document used for creation of respective system validation documents.
 Not Applicable (NA) shall be entered in defined spaces that are not used.
 If the space provided for a particular section is not sufficient, additional
sheets shall be added if necessary with page numbers (Page x of y) or
details shall be added in the available space with a reference to the Section.
 An example shall be prefixed with “Ex:” or “e.g.” or “For Example:” Ex: “Ex:
Defect description”.
 When providing references to controlled documents in a comment or
disposition, the identification number shall be provided for future references.
 A document entry shall be completed concurrently with the actual operation,
task, or test activity.
 While recording data such as reading from a scale, gauge or instrument,
record immediately and directly onto the record provided for documentation.
 Draft documents shall not be referred to or listed in the Reference Document
section of an effective document.
 Only indelible blue ink shall be used.
 In case of unavoidable situation, standard functionality of digital/electronic
signature in adobe acrobat or other tools can be utilized to sign the validation
related documentation.
WI_MUM_ITP_009073 | (1.0) | SOP_MUM_ITP_008333 | CLASS C Vinayak Baravkar (vinayakcbaravkar)
Page 1 of 10
WI_MUM_ITP_009073
 No whiteout or other means of masking an error may be used.

 Follow the test script exactly. Do not conduct tests of the system that have
not been scripted.
 If it is necessary to deviate from the test script or test data provided, those
deviations must be documented and explained.
 When recording test data, do not use abbreviations or shorthand
annotations.
 If additional space is needed to record information, use the back or a
separate sheet of paper. Annotate it with the script and test step id, iteration,
initial and date.
 Testers must sign each step at the time of execution when it is completed.
Once Executor completes a test, ATR shall be complied and prepared for
each test ID and attach to executed test script.
4.2 Signature Concept

Signatures represent that one accepts responsibility related to one’s designation
and/or function (e.g. reviewer, approver, etc.) that the data, record, report, form,
or document being signed is correct, complete, and acceptable. Signatures
convey an understanding and concurrence with the content of the document.
4.3 Screenshot
Capturing and attaching screenshot during test script execution is project
specific process, hence shall be addressed.
Date and Time shall be displayed in the screenshot.
4.4 Date and Time conventions

 Record the dates. Leading zeros for Month and Date shall be optional. The
acceptable formats for dates are listed below:
 dd-Mon-yyyy, Ex: 19-Jan-2009
 dd/Mon/yyyy, Ex:19/Jan/2009
 dd-Mon-yy, Ex: 19-Jan-09
 dd/mm/yyyy. Ex:19/01/2009
 dd/mm/yy. Ex:19/01/09
 dd.mm.yy, Ex: 19.01.09
 dd.mm.yyyy, Ex: 19.01.2009
 dd.Mon.yy, Ex: 19.Jan.09
 dd.Mon.yyyy, Ex:19.Jan.2009
 Record the time in 24 hrs Format.

Page 2 of 10
WI_MUM_ITP_009073
 The acceptable formats for Time are listed below:

 hh:mm in 24 hrs format, Ex: 20:00
4.5 Minimum Handwritten Signature and Date

 A person’s handwritten signature minimally consists of:
- Signature or Initials
- Date at the time of signature.
Example: Xxx Yyy 01-Mar-05 or XY 01-Mar-05
4.6 Use of Faxes and Other Rendered Documents

Faxes shall be used for document approval.
 E-mail is not a validated system. If the information in the E-mail is used to
fulfill a regulatory requirement or contains source/raw data the E-mail in
question shall be printed (without change), signed, dated and retained by the
recipient.
 Alternatively, correspondence shall be signed and dated by the
author/approver and rendered to an uneditable electronic file for
transmission.
4.7 Archiving
 Store all hard copy evidences in a safe storage location with locking
mechanism maintained by CQA for HO systems and Enterprise/Corporate
systems and Site QA for site level systems.
 The documents shall be labeled and filed in an efficient manner so that they
are easily retrievable.
 Printouts and other documents to be archived shall be of suitable quality (i.e.
legible).
 Records that are affixed to another record shall be dated and signed in such
a way that the signature overlaps both records.
 If it is not possible to store supplemental records with the main record, a
reference shall be made to the supplemental record in the main record. The
supplemental record shall be numbered (i.e. each page or summary page), if
appropriate.
 If any document is prepared remotely for corporate/enterprise systems e.g.
URS, FRS, IQ, OQ, PQ etc. then preparer and reviewer shall send the
signed scanned copy to CQA for approval. If Approved, CQA shall sign on
Page 3 of 10
WI_MUM_ITP_009073
scanned printout as approver & shall send the scanned copy and original
copy of the same to remote site. Remote site user shall file the scanned copy
as well as the original copy sent by CQA.
 The project documents shall be retained as follows:
o For all deliverables, the document shall be converted into read only PDF
file. PDF file shall be archived in secured folder.
4.8 Document Reconstruction

1. If a document or record is illegible due to corrections or damage:
 Initiate a new document or record with Compliance Manager/Quality
Assurance Approval.
 Transcribe the original data to the replacement document or record.
 Attach the original document or record to the replacement record, when
possible.
 Document explanation for the reconstruction.
 Draw a “single” line through the original document or record.
 Sign and date.
 A second individual shall verify the reconstructed document or record
against the original document or record for accuracy, sign and date.
2. If an original document or record is lost and a copy of the missing
document is available:
Note: The copy available shall be a true copy of the original
document. A true copy is defined as a completed document with all
required signatures and dates.
 Add a comment to the copy of the document to explain why a copy of the
original is being used.
 Write / Stamp across the top of each page of the document as
“Certified Copy of Original”.
 Sign and Date.
 Get the approval signature from the Quality Assurance.
 If the original document is later found, attach the original to the copy and
retain both.
3. If an original document or record is lost and a copy of the missing
document is not available:
 Initiate a new document or record and follow the process of creating a
copy if original document is missing.
 Prepare a summary document describing the missing document
investigation, project impact and recommended action. This document
Page 4 of 10
WI_MUM_ITP_009073
shall be prepared by the responsible department/individual and approved

by the Quality Assurance
4.9 Corrections
 For an incorrect entry, in order that an original entry is not obscured, adhere
to the following steps:
 Draw a single, straight line through the incorrect entry
 Enter the correction
 Include an explanation for the change if it is not obvious why the
correction is made
 Initial and date the change.
 Missing explanation on the corrections is done by
 The individual who originally corrected the entry records for the
missing explanation
 If that individual is not available, the Manager who has approval
authority for the document makes the explanation and Initial and Date
the explanation
 Predating or postdating a correction is not permitted. When an error is
discovered at a later date, the date on which the correction is made shall be
entered. An explanation shall clearly indicate what occurred and why the
correction was made. The documented explanation shall be clear, concise,
easily understood and logically sound.
 Where space is not available for a correction or change, a distinct reference
shall be used to locate the new entry elsewhere, preferably on the bottom of
the current page or, as needed, a new page or an attachment. These shall
be cross-referenced to each other using a reference such as an asterisk or
number (* or 1,2…etc.).
 When a document has received final approval and is considered closed, no
further corrections shall be made to that document without prior approval
from the Quality Assurance. If such corrections are deemed necessary,
options include:
 Re-issuance of the document
 Amending the completed document
 Correction using the practices defined in this work instruction
In all cases, the Quality Assurance shall approve the correction.
 If a document contains a blank page, draw a diagonal line from the top left
corner to the bottom right corner, write “NA” in between the diagonal line with
initial and date.

Page 5 of 10
WI_MUM_ITP_009073
4.10 Practices Not Allowed

 Using pencil for entries, corrections, and/or signatures.
 Using erasable ink for entries, corrections, and/or signatures.
 Using any other ink color other than blue
 Using a masking device for corrections.
Examples: Correction fluid or tape.
 Obscuring information which includes obscuring the original entry or covering
existing text.
 Using ink stamps in place of initials or signatures unless otherwise
acceptable by local regulations.
 Using scanned signatures in place of handwritten signatures.
 Using “adhesive” notes in lieu of permanently recording information.
 Making changes to approved documents, records, forms, or reports without
obtaining re-approvals.
 Abbreviations, acronyms or change codes unless defined elsewhere
 Do not record results on scrap paper, sticky notes or anywhere else other
than the official record provided for this purpose.
 When multiple rows or columns have the same value, do not use ditto marks
to complete the entry. Enter the actual data.
 Do not use Comment Section for routine data entry.
 No whiteout or other means of masking an error shall be used.
4.11 Location Code Table:

Location Name Location Code
Ankleshwar AN
Aurangabad AU
Mandideep MD
Pune Lupin Research Park, PN
Nande
Jammu JK
Indore IN
Dabhasa DS
Tarapur TR
Goa GA
Pune – Biotech BT
Pune – Hinjewadi HW
Pune – LBC CR
Nagpur NG
Pune – Lupin research park, WK
Wakad
Page 6 of 10
WI_MUM_ITP_009073
Pune-Panchshil PS
Vishakhapatnam (Vizag) VZ
Sikkim SK
Nagpur Injectable NI
Pune – LCEL Wakad EL
Head Office - Mumbai HO
Note: In case of multiple units at same location, location code shall be suffix to
the serial number 1, 2, 3 and so on. In case of new location, location code shall
be assigned as abbreviation of loation. Eg: Baddi shall be assigned as BD.
4.12 Validation document code List
Abbreviations Document Name
URS User requirement specification

GxPA GxP Assessment
VPP Validation project plan
VAC Vendor audit checklist
EAC EDC Asssessment checklist
FRS Functional requirement specification
FRA Functional risk assessment
DCS Design and configuration specification
VP Validation protocol
IQ Installation qualification
OQ Operation qualification
PQ Performance qualification
SRC System relese certificate
VSR Validation summary report
PRR Periodic review report
SRR System retirement report
CVC Change verification checklist
LVD Assessment for leveraging vendor document
LED Assessment for leveraging existing internal
validation documentation
BQPR BOT qualification protocol cum report

Page 7 of 10
WI_MUM_ITP_009073
4.13 Numbering system of validation deliverables:

Validation documents shall follow numbering convention as mentioned below:
“<Doc Type>-<location code>-<Year>-<xxxx>-<zz>”
Where;
Doc Type : URS, GxPA, EAC etc (as per section 4.12)
Location Code : Location code (as per section 4.11)
Year : Current Year,
xxxx : Serial Number
zz : Version Number.
e.g. First URS for Nagpur site unit-1, for year 2021 shall be numbered as
“URS-NG1-2021-0001-00” and so on.
First URS for Nagpur site unit-2, for year 2021 shall be numbered as “URS-
NG2-2021-0001-00” and so on.
Similar numbering convention shall be followed for below mentioned

documents types:
GxPA, EAC, FRS, FRA, DCS, VPP, VP, IQ, OQ, PQ, VSR, PRR, SRR, SRC,
LVD, LED, BQPR, CVC etc. wherever applicable.
Electronic data compliance test script numbering shall be followed as OQ-TS-

EDC-Version number. This test script shall be prepared and pre-approved at
CQA. Pre-approved test script shall be uploaded in DMS and shall be printed
for validation activities. In case DMS is not available/under breakdown,
preapproved test script shall be issued manually.
Test ID shall be continuous serial number within the respective test script. It
shall be numbered as <Test ID-001>, <Test ID-002> and so on within
respective test script.
4.14 Naming Convention and Numbering of Deviation Forms

Deviation form shall be numbered as
DF-YYYY-XXX, where,
DF : Deviation Form
YYYY : Current Year
XXX : Sequence Number
For e.g. First deviation for respective validation/revalidation in year 2021 shall be
numbered as:
DF-2021-001 and so on.
Page 8 of 10
WI_MUM_ITP_009073
Deviation numbering shall be assigned in deviation log printed through

DMS/eDMS issued manually before start of each validation.
4.15 Instructions for Document Standards

The following instructions shall be applicable for formatting all the documents
delivered for Lupin CSS Validation.
 Use Arial 14 for the “Document Type” in center in the Header
 Use Arial 12 for all other entries in the header and footer.
 Use Arial Font 12 and upper case for Heading 1.
 Use Arial Font 11 and sentence case for all other headings.
 Use Arial regular Font 11 for the text.
 Use single space for the content and ‘Justify’ align text.
 Repeat Table header across pages.
 No blank cells in the Table. The Cells without value is either mentioned
as ‘NA’ or grayed out.
 Excel document consists of :
 Cover Page in the first sheet
 Actual Content in intermediate sheets
 Revision History in the last sheet
 Use Arial Font in the Templates. The Font Size of the text shall vary
between 8 and 11 to accommodate spacing constraints.
 Print documents on both sides of pages except SOPs, QIs & Templates.
5.0 ABBREVIATIONS:
SOP : Standard Operating Procedure

WI : Work Instruction
CQA : Corporate Quality Assurance
CVC : Change Verification Checklist
GxP : Good Manufacturing/Clinical/Laboratory Practices
IQ : Installation Qualification
OQ : Operational Qualification
PQ : Performance Qualification
ATR : Actual Test Result
TS : Test Script
CS : Client Server
DP : Data Protection
DM : Domain Migration
RN : Restoration
PDF : Portable Document Format
ID : Identification
Page 9 of 10
WI_MUM_ITP_009073
NA : Not Applicable
PRR : Periodic Review Report
6.0 REFERENCES:
SOP_MUM_ITP_008333 : Validation of Computerized Software System.

Page 10 of 10
LUPIN LIMITED Revision History
Title : VALIDATION OF COMPUTERIZED SOFTWARE SYSTEM
Filter criteria
Name/Number : SOP_MUM_ITP_008333 Sorted by : Title
Version Effective Date Change / Reason
1.0 10-May-2021
Change : Revision History for SOP_MUM_ITP_008333
• SOP Legacy Number was ITP-038-07.

• Section 1.0 Purpose has been updated for activities as per
the procedure and modified for better clarity.
• Section 2.0 updated and procedural details from the
section 2.0 is removed and added in new section 5.8.6.
• In Section 3.0, sub section 3.1, 3.2, 3.3 and 3.4 added to
in lined with GAMP terminology and table of responsibility for
validation deliverables updated for better clarity and
numbered as section 3.5.
• Section 4.0 Updated to include definition of system owner,
process/business owner, user, Thick client, web client,
BOTs, commercial off the self-software, electronic record,
electronic signature. And procedural related definition
removed (GxPA, VAR, VAC, EAC, EAR, URS, FRS, FRA,
DCS, IQ, OQ, PQ, VP, TS, CVC, Limited OQ, Limited PQ,
TM, SRC, VSR). Retrospective validation definition modified
and some editorial changes done.
• Old Section 5.1 and 5.2 removed and new section 5.1
procedure for identifying scope of validation and section 5.2
procedure for defining extent of validation added. Contents of
old section 5.1 and section 5.2 modified and incorporated in
new section 5.13 and 5.3 respectively.
• Old section 5.3 removed and modified contents covers
under new section 5.2.2 ‘GAMP category and examples’ and
new section 5.3 V Model/system life cycle (SLC) Model
added.
• Old section 5.4 removed and modified contents included
under new section 5.5.1.3 ‘vendor assessment’ and new
section 5.4 ‘Concept phase’ has been added.
• Old section 5.5 removed and included under new section
5.5.3.5 ‘test scripts’ and new section 5.5 ‘Project phase’ has
been added to include procedures of planning, specification,
qualification and implementation stages.
• Old section 5.6 and 5.6.1 removed. Old section 5.6.2
removed & covered under new section 5.2.3 with correction
in validation deliverables as per GAMP and old section 5.6.3
removed and covered under new section 5.2.4 with updation.
New section 5.6 Operation / Maintenance phase has been
Prepared by : vinayakcbaravkar Page 1of 8 5/10/2021 12:28:48PM

Filter criteria
added.
• Old section 5.7 covered under new section 5.8 with
modification
• Old section 5.7.1 simplified and covered under new section
5.8.1
5.8.2
5.8.5
• New section 5.8.3 validation strategy for standalone
system, new section 5.8.4 validation strategy for cloud
based system, new section 5.8.6 leveraging existing internal
documentation and new section 5.8.7 validation approach for
robotic process has been introduced.
• Old section 5.7.4 timeline for validation deliverables has
been removed and modified contents added in section
5.5.1.2.
• Old section 5.8 modified and covered under new section
5.9.
5.5.3.8.
5.11.
• New section 5.10 introduced for instructions to fill
document numbering logbook for computerized software
system
5.6.5.
• Section 5.13 modified to update reference procedure
number.
5.7.
• New section 5.14 has been introduced for CSV Vendor
agreement.
• Section 6.0 Abbreviations updated.
• Section 7.2.12 (Reference for templates) removed and
covered under section 8.0 (Annexure).
• Section 7.2 modified as per current SOP numbering of
EDMS.
• Template Vendor Audit Report for <Vendor Name>
(TMPLT-VAR) obsoleted and contents merged into Vendor
audit checklist.
• Template: EDC Assessment Report for <Software Name>
(TMPLT-EAR) obsoleted and content merged into EDC
assessment checklist.
• Old Annexure 2 (Logbook for software identification codes)
removed and new annexure ANNEX_MUM_ITP_006999
introduced for Document Numbering logbook for
Computerized Software System.
• Template ANNEX_MUM_ITP_037336 (Assessment for
leveraging existing internal validation documentation)
included newly.
• Template ANNEX_MUM_ITP_037345 (Assessment for

Filter criteria
leveraging vendor document for <software name, version>)

included newly.
• Template ANNEX_MUM_ITP_037346 (BOT qualification
protocol for integrated <software name> for <purpose>)
Included newly.
• Annexure ANNEX_MUM_ITP_037347 (Signature Log)
Included newly.
• Annexure ANNEX_MUM_ITP_037349 (Log for issuance and
retrieval of logbook) Included newly.
• Annexure ANNEX_MUM_ITP_037352 (Addition/removal of
computer software system for inventory index) Included
newly.
• Annexure ANNEX_MUM_ITP_037353 (Inventory of Retired
system and periodic verification schedule) Included newly.
• Template ANNEX_MUM_ITP_037355 (Vendor agreement)
Included newly.
Revision History for ANNEX_MUM_ITP_006997 (Inventory

Index and Periodic Review Schedule of GxP Computerized
Software System)
• Annexure Legacy Number was Annexure 1.

• Version number removed from header.
• Year added in Header.
• Software identification code has been removed from the
column ‘Software identification code, name, and version no’.
• Column ‘Periodic review frequency (3 years/5 years±30
days)’ updated to remove ‘3 years/5 years±30 days’.
• New column of Actual review date included.
• Monthly periodic review progress table has been
incorporated.
Revision History for ANNEX_MUM_ITP_007001 (Deviation

Log)
• Annexure Legacy Number was Annexure 3.
• Title of document modified.
• Table updated to include “Stage (IQ/OQ/PQ/Other), Column
of deviation number allotted by, Deviation closure date and
checked by included”
• ‘Reviewed by’ has been removed from footer of table.
• New table incorporated to include “Reference change
control number, System name, and Reference validation
protocol/CVC/other”.
Revision History for ANNEX_MUM_ITP_037264 (Template for
User Requirement Specification)
• Template Legacy Number was TMPLT-URS-03.
• In Document Title, ‘Software name’ replaced with ‘System
name’.
• Document Approval table removed form first page and
incorporated in newsection 7.0.
• In section 3.1, content of point No. 3.1.27 updated.
• In section 3.1, content of section 3.1.35 removed due to
duplication with 3.1.36

Filter criteria
• In section 3.1, content of 3.1.43 removed due to duplication

with 3.1.47
• In section 3.1, content of Point No 3.1.44 updated.
• In section 3.1, content of Point No 3.1.48 is removed due to
duplication with 3.1.40 and replaced with new requirement
‘system shall have individual user name and password’.
• In Section 3.1, Point No. 3.1.66 and Point No. 3.1.67
incorporated.

GxP Assessment)
• Template Legacy Number was TMPLT-GxPA-00.
• In document Title, ‘Software name’ replaced with ‘System
name’.
• Title and content of Section1.0 updated.
• Content of Electronic record applicability and Electronic
signature applicability removed from section 1.0 and included
in new section 2.0.
• Content of old section 2.0 ‘GAMP Software Category
Determination’ incorporated in new section 3.0.
• Old section 3.0 ‘Abbreviation’ incorporated in New section
5.0.
• Content of old section 4.0 incorporated in new section 6.0
and new section 4.0 introduced for ‘Overall Conclusion’.
modified table incorporated in new section 7.0 better clarity.

Validation Project Plan)
• Template Legacy Number was TMPLT-VPP-00
name’.
• Pre-Execution Approval table updated and incorporated
under Section 1.0.
• Table of Validation Project Plan updated for editorial
change and incorporated under section 2.0.
• Revision History incorporated under section 3.0.
• Post-Execution Approval table updated and incorporated
under Section 4.0.

Vendor Audit Checklist)
• Template Legacy Number was TMPLT-VAC-00.
• Section 1.0 ‘Computerized System Vendor Audit Report’
updated as Vendor Overviewand content has been modified
for better clarity.
• New section 2.0 Quality Management System incorporated
• New section 3.0 Validation and Documentation
incorporated
• New section 4.0 Software Development Life Cycle
incorporated
• New section 5.0 Customer Support and Maintenance

Filter criteria
incorporated
• New section 6.0 Summary & Conclusion incorporated.

EDC Assessment Checklist)
• Template Legacy Number was TMPLT-EAC-00.
• In Section-B ‘System type’, PLC selection removed and
server based section updated
• In Section-B ‘Network Mode’, Cloud Based section updated
• Section B, point no. 2.2 Updated for better clarity.
• In section B, point no. 5.11 incorporated to add password
complexity testing.
• New Section-C ‘Summary and Conclusion’ incorporated to
include contents of ‘vendor audit report’ template.
• Table of ‘Prepared By’ removed from each page of footer
and incorporated in Section-C.

Functional Requirement Specification)
• Template Legacy Number was TMPLT-FRS-02.
name’.
incorporated in new section 7.0.

Functional Risk Assessment)
• Template Legacy Number was TMPLT-FRA-03.
• Approval table removed from first page and incorporated in
New section 6.0

Design and Configuration Specification)
• Template Legacy Number was TMPLT-DCS-00.
• Content of old section 2.2 removed and updated as
‘Process Flows and system architecture’.
• Content of old Section 2.3 removed and updated as
‘Hardware design specification (Server and client)’.
• Content of old section 2.4 ‘Process Flows’ merge with
section 2.2 and Section 2.4 updated as ‘Software design
specification’ and Audit trail storage path, alarm storage path
section removed.
• Content of oldsection 2.5 ‘Processing Logic (for GAMP-5
Category Systems)’ incorporated in new section 3.5 and
section 2.5 updated as ‘System policy’.
• Content of old section 4.0 ‘Detailed Design (for GAMP
Category-5 Systems)’ removed and incorporated in new
section 3.6 and section 4.0 updated as Abbreviations.
• Content of old section 5.0 ‘Issues’ removed and
incorporated in new section 3.7 and section 5.0 updated as
References.
• Content of old section 6.0 ‘Configuration Details’ is removed
and updated content incorporated in new section 2.4.

Filter criteria
Section 6.0 updated as Revision history.

• Old section 7.0 ‘Abbreviations’ incorporated in section 4.0
and section 7.0 updated as Approval.
• Old section 8.0 ‘Reference’ removed and incorporated in
section 5.0.
• Old section 9.0 ‘Revision History’ removed and incorporated
in section 6.0.

Validation Protocol)
• Template Legacy Number was TMPLT-VP-00
• Section 1.0 updated to exclude ‘CRF No.’
• Section 6.0 ‘Implementation Methodology’ updated.
• Content of section 9.0 merged in section 8.0 and section
8.0 renamed as ‘Validation approach and deliverables’.
• Old section 9.1, 9.2, 9.3, 9.4, 9.5, 9.6, 9.7, 9.8, 9.9, 10.0,
11.0, 12.0, 13.0, 14.0, 15.0, 16.0, 17.0, 18.0 renumbered to
new section 8.1, 8.2, 8.3, 8.4, 8.5, 8.6, 8.7, 8.8, 8.9, 9.0,
10.0, 11.0, 12.0, 13.0, 14.0, 15.0, 16.0, 17.0 respectively.
• In new section 8.6.2, 8.6.4 and 8.6.6, column of Test ID
included in table.
• Section 8.9 updated to exclude responsibility paragraph.

Test Script)
• Template Legacy Number was TMPLT-TS-00.
• Pre-execution Approval table of first page updated for better
clarity and numbered as section 1.0.
• Content of Old Section 1.0 incorporated in New section 2.0.
• Old section 2.0 Deviation removed.
• Column of Equipment ID included in new section 2.0.
• Selection Box added in Test Environment row at New
Section 2.0 for better clarity.
• Selection Box added in section 3.0 Conclusion for better
clarity.
• Attachment table added in section 4.0 for better clarity.
• Revision History numbered as section 5.0.
• Post-Execution approval updated for better clarity and
numbered as section 6.0.

Actual Test Result)
• Template Legacy Number was TMPLT-ATR-00.
• Description of screen print added included with Step ID.
• Compiled By sign added at last of the document.

Deviation Form)
• Template Legacy Number was TMPLT-DF-04.
• In section, I, Test script Doc. No. / SOP No updated to Test
Script Doc. No.
• in Section I, SOP/WI selection checkbox excluded.
• In section I, Minor selection checkbox excluded.

Filter criteria
• In Section I, “Initiated by” Added.

• In section I, impact assessment included.
• In section II, Deviation closure due date updated to
Deviation Closure tentative due Date.

Validation Summary Report)
• Template Legacy Number was TMPLT-VSR-04
• In section 2.0, Change Control Form updated as Change
control.
• In section 3.1, 3.2 and 3.4 table updated to include test ID
• In Section 3.5, table updated to include ‘step ID’ in ‘Test ID
column’.
• Section 5.2 modified.
• In section 5.3 table updated for include document status as
‘available’.
• In section 7.0, Annexure name updated to
ANNEX_MUM_ITP_037352.
• In section 10.0, column of Document Number and Approval
Date removed.
• In section 13.0, Approval table updated for better clarity.

System Release Certificate)
• Template Legacy Number was TMPLT-SRC-03.
• Section 1 updated to exclude software identification ID.
• Content of section 2.1 modified and merged in section 2.0
for better clarity.
• Content of section 2.2 merged in new section 3.0
• Content of section 2.3 merged in new section 4.0
• In Section 3.0, modified.
• Old section 3.0 renumbered as section 5.0
• In section 4.0, table updated for include document status
as ‘available’
modified table incorporated in new section 7.0 for better
clarity.

Change Verification Checklist)
• Template Legacy Number was TMPLT-CVC-00.
• Pre-Execution Approval incorporated under Section 1.0.
• Section 1.0 numbered as section 2.0.
• Section 2.0 updated to remove CRF and updated to include
equipment ID.
• In section 3.0, Selection check box included.
• In section 4.0, Attachment table added
• Post-Execution Approval updated and incorporated under
Section 6.0.
Lupin Property forHistory

Revision Training Purpose Only
for ANNEX_MUM_ITP_037321 (Template for

Filter criteria
Periodic Review Report)

• Template Legacy Number was TMPLT-PRR-02.
• Approval table removed from first page of footer and
updated table added in New section 6.0
• In Section 3.0, Selection check box added in relevant place
for better clarity.
• In section 4.0, SOP number updated as per EDMS
under Section 6.0.

System Retirement Report)
• Template Legacy Number was TMPLT-SRR-00
• In Section 2.0, Remarks of Sr. No.4 and 8 updated for
better clarity.
• In Section 2.0, Sr. No. 11 included to mention ‘Inventory of
retired system and periodic verification schedule’.
under Section 6.0.
Revision History for WI_MUM_ITP_009073 (Good

Documentation Practices & Naming Standards for Computer
Software System)
• Work Instruction Legacy Number was WI-GDPNS-00.

• Section 4.1 general instructions updated to include work
instructions of test script management.
• Section 4.8 modified to exclude Contact Quality Assurance
for confirmation on whether
Reason : Refer Change Control : CCP-MM-941-21-0021


CSV Sop

Uploaded by

Copyright:

Available Formats

You might also like

CSV Sop

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CSV Sop

Uploaded by

Copyright:

Available Formats

Lupin Property for Training Purpose Only

Lupin Property for Training Purpose Only

______________________ ______________________ ______________________ ______________________

Monthly periodic review progress table:

ANNEX_MUM_ITP_006997 | (1.0) | SOP_MUM_ITP_008333 | CLASS C Vinayak Baravkar (vinayakcbaravkar)

Logbook Number: - _______________________________

ANNEX_MUM_ITP_006999 | (1.0) | SOP_MUM_ITP_008333 | CLASS C Vinayak Baravkar (vinayakcbaravkar)

Document Name: - __________________________________________

ANNEX_MUM_ITP_006999 | (1.0) | SOP_MUM_ITP_008333 | CLASS C Vinayak Baravkar (vinayakcbaravkar)

Reference Change Control Number

<Rows can be added/removed>

ANNEX_MUM_ITP_007001 | (1.0) | SOP_MUM_ITP_008333 | CLASS C Vinayak Baravkar (vinayakcbaravkar)

2.0 SYSTEM OVERVIEW

<This section is intended to make the described user requirements easier to

2.2 Business Process Overview

3.0 SYSTEM REQUIREMENTS

3.1 Security / Regulatory Requirements:

Lupin Property for Training Purpose Only

URS ID / User Requirement Description

URS ID / User Requirement Description

Note: Rows can be added/modified/deleted if needed.

Lupin Property for Training Purpose Only

CSS : Computer Software System

6.0 REVISION HISTORY

Lupin Property for Training Purpose Only

<No’s of rows can be increased>

<No’s of reviewer can be increased>

Lupin Property for Training Purpose Only

Doc. No.: <Doc. No.>

1.0 GXP APPLICABILITY ASSESSMENT (To be filled by User)

Can the system or data from the system impact submissions to

If any of the answer is “Yes”, then system is considered as “GxP Applicable”. If

Conclusion: The system will be  GxP Applicable  GxP Not-Applicable

Lupin Property for Training Purpose Only

2.0 ER/ES APPLICABILITY ASSESSMENT (To be filled by User)

Electronic Record Applicability (21 CFR Part 11; Subpart B)

Are any of the records referenced in Question 1-5 saved

2 EDC Assessment required?

Electronic Signature Applicability (21 CFR Part 11; Subpart C)

Does the system include functionality that allows users to

Lupin Property for Training Purpose Only

3.0 GAMP SOFTWARE CATEGORY DETERMINATION (To be filled by IT)

4 Is the software configurable w.r.t its functional behavior?

Is the software allowing administrator to add/modify/remove

6 Is the software inhouse developed?

Is the software exclusively developed for Lupin by external

Sr. GAMP Software Category (Tick any one as applicable)

Lupin Property for Training Purpose Only

4.0 OVERALL CONCLUSION:

System will be : GxP Applicable / Not Applicable

6.0 REVISION HISTORY:

Lupin Property for Training Purpose Only

Name Department Sign and Date

<No’s of rows can be increased>

<No’s of reviewer can be increased>

Lupin Property for Training Purpose Only

1.0 PRE-EXECUTION APPROVAL

<No’s of reviewer can be increased>