Utopia Pharmaceuticals

SOP No.: SOP-QA-064

Issue date: 25/10/2024 Computer System
Next Revision: 24/10/2027
Version no: 02 Validation (CSV)
Page 1 of 19

Computer System Validation (CSV)

SOP-QA-064
Prepared by: Dr. Mohamed Ashraf Signature: ……………………………….
Title: QA Validation Senior Date: ……………………………….

Checked by: Dr. Maryam Zain Signature: ……………………………….

Title QA Validation Section Head Date: ……………………………….

Reviewed by: Dr. Fekry Fawzy Signature: ……………………………….

Title: QA Documentation Senior Date: ……………………………….

Reviewed by: Eng. Ahmed Magdy Signature: ……………………………….

Title: IT Section Head Date: ……………………………….

Approved by: Dr. Mohamed Abbas Signature: ……………………………….

Title Quality Assurance Manager Date: ……………………………….

Effective date: Copy number:

 Utopia Pharmaceuticals

SOP No.: SOP-QA-064

Issue date: 25/10/2024 Computer System
Next Revision: 24/10/2027
Version no: 02 Validation (CSV)
Page 2 of 19

1. Purpose:
1.1 The purpose of this SOP is to describe the framework for ensuring compliance of GXP computerized
systems with data integrity regulatory requirements.
2. Scope:

2.1 The SOP addresses computer validation at the enterprise and system level.
2.1.1 Enterprise Level (Specific contributions for enterprise level master planning are):
2.1.1.1 Corporate policy.
2.1.1.2 The company’s validation approaches.
2.1.1.3 Inventory of systems and associated validation status.

2.1.2 System Level (Types of systems that can be covered by this SOP include):
2.1.2.1 Enterprise resource management system
2.1.2.2 Building management system
2.1.2.3 Lab. equipment
2.1.2.4 PLC controlled production equipment
2.1.2.5 PLC controlled utilities
2.2 This SOP does not cover details of validation activities during development, for example, details of
design specifications, code development, review or structural testing.
2.3 The SOP also does not cover internet compliance or details of internet security management.

3. Responsibility:

3.1 Computer validation will affect different departments in an organization. Policies, master plans and
procedures should be preferably supported and used by the entire organization. Individual projects
need to be supported by anybody who is affected by the computer system to be validated. Therefore, it
is important that responsibilities are well defined.

Prepared by: Dr. Mohamed Ashraf Checked by: Dr. Maryam Zain
Sign: Sign:
Date: Date:
 3.2 Developing software and computer systems according to
documented procedures.
3.3 Providing documented evidence that the software has been
developedUtopia
in aPharmaceuticals
quality assurance environment and
validated during development.
SOP No.: SOP-QA-064 3.4 Allowing users to audit development and validation
Issue date: 25/10/2024 Computer
process, ifSystem
necessary.
Next Revision: 24/10/2027 3.5 Developing and providing functional specifications for the
Version no: 02 Validation (CSV)
Suppliers software and computer system.
Page 3 of 19
3.6 Offering services to assist users in specifying, installing
and validating the system.
3.7 Offering support in case the user has a problem with the
system.
3.8 Informing users on critical software errors and
workaround solutions and corrective action plans.
3.9 Maintaining version control of the code.
3.10 Informing users on new versions, e.g., what is new
and how the change can impact the validation state.
3.11 Provide training requirements and required
resources.
Top management 3.12 Reviewing and approving project plans of computer
validation projects that are critical for the organization.
3.13 Following all Corporate Computer System Policies
3.14 Determining criticality of their computer systems to
the business
3.15 Ensuring areas responsible for validating/qualifying
System Owner the systems are adequately resourced to validate/qualify
the systems and to maintain them in a validated/qualified
state
3.16 Ensuring that their computer systems are
validated/qualified and remain validated/qualified, and
accepting accountability for validation/qualification
compliance
3.17 Representing their departments.
3.18 Attending all team meetings or arranging for a
substitute.
3.19 Collecting and giving inputs for risk assessment.
Validation Team
3.20 Reviewing project plans.
3.21 Developing and reviewing procedures that are
specific for the individual project.
3.22 Reviewing test and validation protocols and other
validation deliverables.
3.23 Helping to define specifications for software and
computer systems.
3.24 Assisting the system owner in identifying and
selecting software and computer system suppliers and
models.
3.25 Creating and maintaining hardware and software
Prepared by: Dr. Mohamed Ashraf
IT Department inventoryChecked by: Dr. systems.
for computer Maryam Zain
Sign: 3.26 Sign:
Qualifying IT infrastructure.
Date: 3.27 Date:
Providing technical expertise for risk assessment
and the extent of testing and revalidation related to
networked systems.
3.28 Reviewing and approving validation documentation
 Utopia Pharmaceuticals

SOP No.: SOP-QA-064

Issue date: 25/10/2024 Computer System
Next Revision: 24/10/2027
Version no: 02 Validation (CSV)
Page 4 of 19

4. Forms /Appendices
4.1. Form for List of system inventory (FSOP- QA-064-01)
4.2. Form for CSV Plan (FSOP- QA-064-02)
4.3. Form for User Requirement Specification (FSOP-QA-064-03)
5.1.1

Prepared by: Dr. Mohamed Ashraf Checked by: Dr. Maryam Zain
Sign: Sign:
Date: Date:
 Utopia Pharmaceuticals

SOP No.: SOP-QA-064

Issue date: 25/10/2024 Computer System
Next Revision: 24/10/2027
Version no: 02 Validation (CSV)
Page 5 of 19

5. Procedure:
5.1 Validation Principle and Approach:

5.1.1 Categories for software:

GAMP5 specifies areas of review including looking for dead code, modular programming, annotation and
an appropriate tag-naming convention. GAMP recognizes five levels of code - Level 5 ("bespoke")
requiring the most attention.
- Category 1 - this is an area to categories "Infrastructure Software". An evaluation of the O/S itself is not
required. The version number of the O/S along with patch and hotfix information is recorded. If the
version number is changed or patches are applied, then this could lead to failure of applications running
on the O/S.
- Category 2 - this Category is no longer used in GAMP 5
- Category 3 - this is "non-configured products" (e.g. COTS software)
- Category 4 - this is "configured" software such as ERP.
- Category 5 - this is "custom applications" in the meaning of software customs designed and coded to
suit the specific business process

5.1.2 Typical Examples and Approaches:

Category Description Typical example Typical approach

1. Infrastructure - Layered software - Operating Systems - Record version number,
software (i.e., upon which - Data base Engines verify correct
applications are - Programming Installation by follow
built) languages approved installation
- Software used to - Statistical packages procedures
manage the - Spreadsheets
operating - Network monitoring
environment tools
- Scheduling tools
- Version control tools
2. Non - Run-time - Firmware-based - Abbreviated life cycle

Prepared by: Dr. Mohamed Ashraf Checked by: Dr. Maryam Zain
Sign: Sign:
Date: Date:
 Utopia Pharmaceuticals

SOP No.: SOP-QA-064

Issue date: 25/10/2024 Computer System
Next Revision: 24/10/2027
Version no: 02 Validation (CSV)
Page 6 of 19

configured parameters may - COTS software approach

be entered and - Instruments ex: - URS
- stared, but the HPLC, GC. - Risk-based approach to
software cannot supplier
be configured to - Record version number,
suit the business verify correct
process Installation
- Risk based tests against
requirements as
dictated by use (for
simple systems regular
calibration may
substitute for testing)
3. Configured Software. often - LIMS - Life cycle approach
very - ERP - Risk-based approach to
- Building supplier assessment
complex, that can Management - Demonstrate supplier
be systems has adequate QMS
- Simple Human - Some life cycle
configured by the
Machine Interfaces documentation retained
user
(HMI) only by supplier (e.g.
to meet the specific Note: specific Design Specifications)
needs of the users examples - Record version number,
business process. verify correct
of the above system installation
Software code is types may contain - Risk-based testing to
not altered. demonstrate application
substantial custom works as designed in a
test environment
elements - Risk-based testing to
demonstrate application
works as designed
within the business
process
- Procedures in place for
maintaining compliance

Prepared by: Dr. Mohamed Ashraf Checked by: Dr. Maryam Zain
Sign: Sign:
Date: Date:
 Utopia Pharmaceuticals

SOP No.: SOP-QA-064

Issue date: 25/10/2024 Computer System
Next Revision: 24/10/2027
Version no: 02 Validation (CSV)
Page 7 of 19

and fitness for intended

Use
- Procedures in place for
managing data
4. Custom Software custom Varies, but includes: Same as for configurable,
plus:
designed and coded - Internally and
externally developed - More rigorous supplier
to suit the business IT applications assessment with
Process. - Internally and possible supplier audit
externally developed - Possession of full life
process control cycle documentation
applications (FS, DS, structural
- Custom ladder logic testing, etc.)
- Custom firmware - Design and source code
- Spreadsheets (Macros) review

5.2 Validation Life cycle

5.2.1 V-model
- Due to the complexity and the long time span for computer validation the process is typically broken
down into life cycle phases. Several life cycle models have been described in literature. The model used
will be the V-model as shown
- Where:
 User Requirement Specifications (URS)
 Functional Specifications (FS)
 Design Specifications (DS)
 Installation Qualification (IQ)
 Operational Qualification (OQ)
 Performance Qualification (PQ)

5.2.2 4Q model

Prepared by: Dr. Mohamed Ashraf Checked by: Dr. Maryam Zain
Sign: Sign:
Date: Date:
 Utopia Pharmaceuticals

SOP No.: SOP-QA-064

Issue date: 25/10/2024 Computer System
Next Revision: 24/10/2027
Version no: 02 Validation (CSV)
Page 8 of 19

- V-model may seem quite complex for true commercial off-the-shelf systems with no code development
for customization. Phases like design specification or code development and code testing are not
necessary. For such systems the 4Q model is recommended with just four phases: Design Qualification
(DQ), Installation Qualification (IQ), Operational Qualification (OQ) and Performance Qualification
(PQ).

 User requirement specifications

Design Qualification  Functional specifications
 Operational specifications
 Vendor qualification
Installation Qualification  Check arrival as purchased
 Check installation of hardware and
software
Test of key operational functions
Operational Qualification 

 Test of security functions

 Test for specified application

Performance Qualification  Preventive maintenance
 On-going performance tests

5.3 Approach for Implementation

5.3.1 Validation of software and computer systems should follow the life cycle approach. The exact model
depends on the system, e.g., whether it is a commercial or custom built system, or a combination of both.
Typical commercial systems will follow the 4Q model, while custom built systems follow the V-model and for
combinations of customized commercial systems it will follow the combined life cycle.

5.4 Validation activities

5.4.1 Planning phase
5.4.2 User requirements specification (The user requirements specification will):
5.4.2.1 Describes the functions that a system or system component must or should be capable of
performing.

Prepared by: Dr. Mohamed Ashraf Checked by: Dr. Maryam Zain
Sign: Sign:
Date: Date:
 Utopia Pharmaceuticals

SOP No.: SOP-QA-064

Issue date: 25/10/2024 Computer System
Next Revision: 24/10/2027
Version no: 02 Validation (CSV)
Page 9 of 19

5.4.2.2 Generally developed by the user in the initial stages of a system development or system
selection process.
5.4.2.3 Written in general terms and specifies what needs to be done, not how it will be done
5.4.2.4 Independent of the specific application program (technically nonspecific) that will be written
or purchased.
5.4.2.5 Be used as the basis for the development of the system acceptance test scripts / performance
qualification test scripts.
5.4.2.6 URS should address:
5.4.2.6.1 Regulatory Requirements
5.4.2.6.2 Process Requirements
5.4.2.6.3 What e-Records are managed by the system
5.4.2.6.4 Where e-Signatures are employed
5.4.2.6.5 Necessary audits trails (who, what, when)
5.4.2.6.6 Data retention
5.4.2.6.7 Security / authorization
5.4.2.6.8 Operating environment and the computer’s role

5.4.3 Functional specification

5.4.3.1 Functional Specifications is normally written by the supplier and describes in detail the
functions of the system, it shall describe how the system performs
5.4.3.2 The functional specification will:
5.4.3.2.1 Describes in a high-level manner, the hardware, software and peripherals that make
up the computer system as a whole (Note: In system development terms, this
specification will form the basis of system testing.)
5.4.3.2.2 Describes how the specific system to be purchased or developed will meet the user
and functional requirements
5.4.3.2.3 Describes the specific user requirements that will be met by the system
5.4.3.2.4 Include reference to the data model to be used
5.4.3.2.5 Define the functionality that does not relate directly to the user interface (e.g. system
interfaces)
5.4.3.2.6 Define the non-functional requirements such as performance and availability.
5.4.3.2.7 Be used as the basis for the development of systems acceptance test scripts /
operational qualification test scripts.

Prepared by: Dr. Mohamed Ashraf Checked by: Dr. Maryam Zain
Sign: Sign:
Date: Date:
 Utopia Pharmaceuticals

SOP No.: SOP-QA-064

Issue date: 25/10/2024 Computer System
Next Revision: 24/10/2027
Version no: 02 Validation (CSV)
Page 10 of 19

5.4.4 Design specification

5.4.4.1 Design Specification shall describe how the system has been developed in order to
perform the functions required, this will include:
5.4.4.2 Software Design Specification (SDS):
5.4.4.2.1 Contains software components and sub-systems to be provided as part of the
system
5.4.4.2.2 Subsequent Software Module Design Specifications (SMDS) may be produced
for sub-systems
5.4.4.2.3 Should contain enough information to enable the code to be produced

5.4.4.3 Hardware Design Specification (HDS):

5.4.4.3.1 Identifies hardware components and modules to be provided and configured as part of the
system
5.4.4.3.2 Shows how the hardware interacts with its environment.
5.4.4.3.3 Subsequent detailed design specifications may be produced.

5.4.5 Design qualification

5.4.5.1 Design Qualification (also termed Design review) is a planned and systematic review of
specifications, design, and development throughout the lifecycle. Design reviews evaluate deliverables
against standards and requirements, identify problems, and propose required corrective actions.
5.4.6 validation phase
5.4.6.1 Code review
5.4.6.1.1 It will focus upon bespoke software developments which will be subject to a code
review and will focus on GxP critical bespoke developments
5.4.6.2 Source code reviews objectives:
5.4.5.2.1 To ensure that programming standards, are consistently and correctly applied
5.4.6.2.2 To ensure that the code is written in accordance with the design specifications

Prepared by: Dr. Mohamed Ashraf Checked by: Dr. Maryam Zain
Sign: Sign:
Date: Date:
 Utopia Pharmaceuticals

SOP No.: SOP-QA-064

Issue date: 25/10/2024 Computer System
Next Revision: 24/10/2027
Version no: 02 Validation (CSV)
Page 11 of 19

5.4.6.2.3 The review aims to ensure that the code is fit to enter testing (module, integration or
system tests), and that the code can be effectively and efficiently maintained during the period of
use of the application.
5.4.6.2.4 The review should be carried out in accordance with a documented procedure, and
performed by at least one Independent person with sufficient knowledge and expertise, in
conjunction with the author of the code.
5.4.6.2.5 Automated source code review tools are particularly useful & should be identified if
used
5.4.6.3 Testing
5.4.6.3.1 For product development, the supplier should test the product in accordance with approved test plans
and test specifications.
5.4.6.3.2 The test specifications, when executed, should demonstrate that all requirements, functionality, and
design have been met; this may involve one or many stages of testing, depending on the nature of the product.
For example, a simple product may only need one test specification while a complex product may have:
1. Module (Unit) Testing
2. Integration Testing
3. System Testing

5.4.6.3.3 Test records for each stage should be reviewed and approved, and retained for a period defined in the
QMS (not to be shorter than the supported lifetime of the current software version).
5.4.6.3.4 Test failures should be managed in accordance with a formal documented process.

5.4.6.3.5 If the supplier is involved in configuring a product or developing a custom application, the number and
level of test specifications can vary considerably and should be agreed with the regulated company

5.4.6.3 Purpose of Testing

5.4.6.3.1 Demonstrate conformity with defined specifications
5.4.6.3.2 Measure how well product meets customers’ requirements
5.4.6.3.3 Determine performance

Prepared by: Dr. Mohamed Ashraf Checked by: Dr. Maryam Zain
Sign: Sign:
Date: Date:
 Utopia Pharmaceuticals

SOP No.: SOP-QA-064

Issue date: 25/10/2024 Computer System
Next Revision: 24/10/2027
Version no: 02 Validation (CSV)
Page 12 of 19

5.4.6.3.4 Determine reliability

5.4.6.3.5 Establishing confidence

5.4.6.4 Principles of Testing

5.4.6.4.1 Test throughout development process Objective, testing requires independence Plan for
finding errors
5.4.6.4.2 A test case should always define the expected output or result
5.4.6.4.3 Test for invalid and unexpected, as well as valid and expected situations
5.4.6.4.4 Test that software does not perform unspecified operations, as well as performing the
specified ones
5.4.6.4.5 Review tests thoroughly and take action
5.4.6.4.6 Retain test results

5.4.6.5 Types of Testing

Two general types of testing activities may be identified:
5.4.6.5.1 White Box Testing is also known as code-based testing, or structural testing. Test cases are
identified based on source code knowledge, knowledge of detailed design specifications and
other development documents.
5.4.6.5.2 Black Box Testing is based on the functional specification, thus often known as functional
testing. Black box testing may be sufficient providing the supplier assessment has found
adequate evidence of white box testing.

Specific types of testing should be considered, depending on the complexity of the system, the risk and supplier
assessments of the system to be tested, Including:
1. Normal Case testing (Positive Case or Capability testing) challenges the system's ability to do what it
should do, including triggering significant alerts and error messages, according to specifications.
2. Invalid Case testing (Negative Case or Resistance testing) challenges the system's ability not to do
what it should not according to specifications.
3. Repeatability testing challenges the system’s ability to repeatedly do what It should, or continuously if
associated with real time control algorithms.

Prepared by: Dr. Mohamed Ashraf Checked by: Dr. Maryam Zain
Sign: Sign:
Date: Date:
 Utopia Pharmaceuticals

SOP No.: SOP-QA-064

Issue date: 25/10/2024 Computer System
Next Revision: 24/10/2027
Version no: 02 Validation (CSV)
Page 13 of 19

4. Performance testing challenges the system's ability to do what it should as fast and effectively as it
should, according to specifications.
5. Volume/Load testing challenges the system's ability to manage high loads as it should. Volume/load
testing is required when system resources are critical.
6. Regression testing challenges the system's ability to still do what it should after being modified
according to specified requirements and those portions of the software not involved in the change were
not adversely affected.
7. Structural/Path testing challenges a program's internal structure by exercising detailed program code.

5.4.7 Installation Qualification (IQ)

5.4.7.1 Installation Qualification is performed to assure that the computer system has been installed as specified
and documented evidence exists to demonstrate this.

5.4.7.2 IQ shall confirm that:

5.4.7.2.1 Software has been loaded correctly
5.4.7.2.2 Specific site hardware items have been assembled and installed correctly
5.4.7.2.3 Power supplier, earth connections, data connections and field connections are correct and enable
the system to be powered up
5.4.7.2.4 Control and monitoring instrumentation have been calibrated and installed correctly
5.4.7.2.5 Basic system functions operate on power up and any built-in diagnostics are satisfactorily
Installation Qualification is in practice performed to assure that the CS has been installed as
specified and documented evidence exists to demonstrate this.IQ shall
5.4.7.2.6 Documentation must exist for installation of the application software in the production
environment, including:
5.4.7.2.6.1 Name and version of the software
5.4.7.2.6.2 Who performed the installation.
5.4.7.2.6.3 Date/time of installation
5.4.7.2.6.4 Installation instructions (listed or referenced)
5.4.7.2.6.5 Special set-up parameters
5.4.7.2.6.6 Verification that the installation was successfully completed

5.4.7.2.7 If testing is not performed in the production environment, include documented evidence that:
5.4.7.2.7.1 Test environment is essentially the same as production environment

Prepared by: Dr. Mohamed Ashraf Checked by: Dr. Maryam Zain
Sign: Sign:
Date: Date:
 Utopia Pharmaceuticals

SOP No.: SOP-QA-064

Issue date: 25/10/2024 Computer System
Next Revision: 24/10/2027
Version no: 02 Validation (CSV)
Page 14 of 19

5.4.7.2.7.2 Test installation meets the same criteria as production installation

5.4.7.2.8 IQ activities shall include:

5.4.7.2.8.1 Hardware Acceptance Testing (HAT):
- Defines the tests to be conducted on the hardware described in the HDS.
- Ensures that the hardware supplied meets its specification and integrates correctly with existing
computer hardware or plant equipment

5.4.7.2.8.2 System Configuration Test

5.4.8 Operation Qualification (OQ)

5.4.8.1 The Operational procedures, Critical algorithms and parameters should be tested as well as Data
integrity, security, accuracy and reliability. Stress test would normally be a part of OQ
5.4.8.2 Tests should challenge normal and abnormal conditions including:
5.4.8.2.1 Security controls
5.4.8.2.2 Range checking for data entry
5.4.8.2.3 Sequences of operations
5.4.8.2.4 Alarm conditions

5.4.8.3 OQ activities shall include:

5.4.8.3.1 System Acceptance Testing (SAT)
5.4.8.3.1.1 Defines the tests to be conducted against approved SDS or SMDS documentation
5.4.8.3.1.2 Ensures that software (in particular bespoke elements) are tested and ‘challenged’ accordingly

5.4.8.3.2 Functional Acceptance Testing (FAT)

5.4.8.3.2.1 Covers all stated functional requirements
5.4.8.3.2.2 Evaluates the compliance of a system or component with specified functional requirements
5.4.8.3.2.3 Based on the definition of what the software is intended to do
5.4.8.3.2.4 Challenges the intended use or functionality of a system, and the program’s internal and external
interfaces.

Prepared by: Dr. Mohamed Ashraf Checked by: Dr. Maryam Zain
Sign: Sign:
Date: Date:
 Utopia Pharmaceuticals

SOP No.: SOP-QA-064

Issue date: 25/10/2024 Computer System
Next Revision: 24/10/2027
Version no: 02 Validation (CSV)
Page 15 of 19

5.4.9 Performance Qualification (PQ)

5.4.9.1 As part of the PQ it is necessary to prove that the system works correctly and consistently in the
intended operational environment at the Client as part of the process for which it has been designed, using all
procedures, equipment, utilities.

5.4.9.2 PQ activities shall include:

5.4.9.2.1 User Acceptance Testing (UAT), the activities shall cover:
- Business process normal testing
- Regression testing: reprocessing of data files and compare the result with previous result
- Final acceptance testing

5.4.9.2.2 System retirement

- Retirement of computer systems should be thoroughly planned and implemented. Most important is to
ensure that data created and/or processed on the system are readily available on the new systems in a
form required by regulations and business standards. Tasks are managed by the system owner with the
support of IT.
Tasks include:
1. Initiating the retirement process.
2. Drafting a retirement plan.
3. Collecting and reviewing all system documentation that may be necessary to demonstrate compliance of
the system.
4. Developing a plan to migrate critical data to the new system and verifying that the data can be retrieved on
the new system in the same way as on the existing one.
5. Documenting the latest configuration settings.
6. Deleting all data from the hard disk of the existing system.
7. Taking the system out of service.

5.4.9.2.3 Periodic reviews and auditing

Computer systems should be regularly reviewed and included in the department’s audit schedule. Reviews
1. The purpose of the review is to verify that the actual system is identical to the current documentation and
that a system, once validated, remains in a validated state. Differences between documentation and the

Prepared by: Dr. Mohamed Ashraf Checked by: Dr. Maryam Zain
Sign: Sign:
Date: Date:
 Utopia Pharmaceuticals

SOP No.: SOP-QA-064

Issue date: 25/10/2024 Computer System
Next Revision: 24/10/2027
Version no: 02 Validation (CSV)
Page 16 of 19

actual system should be identified and documented and the impact on the validation status should be
evaluated and corrective actions initiated if necessary.
2. Reviews should be regularly scheduled and conducted based risk assessment.
3. Special focus should be on changes such as checking for software revisions of the operating system and
application software, and on changes of configuration settings and documents.
4. The review should also check if scheduled performance tests have been performed and in case of
deviations if corrective actions have been planned and implemented.

5.4.9.2.4 Auditing
Computer systems should be audited as part of the regular department or site audit schedule. Focus of the audit
should be on:
1. User training: Is the training material current, are all users properly trained and is the training documented?
2. Procedures: Are they available at the work place, are they current and followed?
3. Operating manuals: Are they current?
4. Security policies: Are they followed?
5. Back-up: Has data back-up been regularly performed according to the back-up schedule?

Audits should be conducted by an audit team from outside the department. Deviations found during the audit
should be documented and a corrective action plan developed and implemented.

6. Process Flow Chart:

6.1 N/A
7. References:
Ser. # Reference Name
1 Eur annex 11, 15
2 CFR 21 part 11
3 GAMP 5

Prepared by: Dr. Mohamed Ashraf Checked by: Dr. Maryam Zain
Sign: Sign:
Date: Date:
 Utopia Pharmaceuticals

SOP No.: SOP-QA-064

Issue date: 25/10/2024 Computer System
Next Revision: 24/10/2027
Version no: 02 Validation (CSV)
Page 17 of 19

8. Related documents:
8.1 N/A
9. Definitions / Abbreviations:
9.1 Data integrity:
is the degree of completeness, consistency, and accuracy of data Complete, consistent, and accurate data
should be attributable, legible, contemporaneously recorded, original or a true copy, and accurate.

9.2 Computerized system:

a system that collectively controls the performance of one or more automated processes and/or
functions. It includes computer hardware, software, peripheral devices, networks and documentation,
e.g. manuals and standard operating procedures, as well as the personnel interfacing with the hardware
and software, e.g. users and information technology support personnel.

9.3 Audit trail:

is a secure, computer-generated, time-stamped electronic record that allows for reconstruction of the
course of events relating to the creation, modification, or deletion of an electronic record. An audit trail can
be considered a form of metadata that is provided for secure recording of data life cycle details. An audit
trail is a chronology of the “who, what, when, and why” of a record.

9.4 Good practices (GXP):

It is a term (or acronym) describing the group of good practice guides governing activities for regulated
pharmaceuticals, biological and medical devices, such as good laboratory practices, good clinical
practices, good manufacturing practices, good pharmacovigilance practices and good distribution
practices.

9.5 Backup:
a copy of current (editable) data, metadata and system configuration settings maintained for recovery
including disaster recovery.

9.6 Archive:
a designated secure area or facility (e.g. computerized system) for the long-term, retention of data and
metadata for the purposes of verification of the process or activity.
9.7 Process owner:

Prepared by: Dr. Mohamed Ashraf Checked by: Dr. Maryam Zain
Sign: Sign:
Date: Date:
 Utopia Pharmaceuticals

SOP No.: SOP-QA-064

Issue date: 25/10/2024 Computer System
Next Revision: 24/10/2027
Version no: 02 Validation (CSV)
Page 18 of 19

personnel who is responsible for managing the process or processes using a specific system.

9.8 System owner:

personnel who is responsible for the availability and readiness of the system to be used or operated by the
process owner.

9.9 Administrator:
personnel who has full access rights over a specific system. The main role of the system administrator is
access management and system configurations. The system owner granted the administration when the
system owner is from two different functional areas, otherwise system owner cannot be the administrator
due to the likelihood of conflict of interest. In this case, administration is granted to independent personnel.

9.10 Conflict of interest:

A situation in which a person is in a position to derive benefit from actions or decisions made in their
official capacity.

Abbreviatio Definition
n
CSV : Computerized System Validation
DI : Date Integrity
DQ : Design Qualification
GLP : Good Laboratory Practices
GMP : Good Manufacturing Practices
GXP : Good Practices
IQ : Installation Qualification
IT : Information Technology
KSH : Key stakeholder
OQ : Operation Qualification
PQ : Performance Qualification
QA : Quality Assurance
QC : Quality Control
SOP : Standard Operating Procedure

Prepared by: Dr. Mohamed Ashraf Checked by: Dr. Maryam Zain
Sign: Sign:
Date: Date:
 Utopia Pharmaceuticals

SOP No.: SOP-QA-064

Issue date: 25/10/2024 Computer System
Next Revision: 24/10/2027
Version no: 02 Validation (CSV)
Page 19 of 19

URS : User Requirement Specifications.

O/S Operating system

10. History:
Version No. Page No. Description of change(s) Issue Date

01 All Doc First issue 03/01/2024

02 All Doc According to CCR: QACR042-24 25/10/2024

Prepared by: Dr. Mohamed Ashraf Checked by: Dr. Maryam Zain
Sign: Sign:
Date: Date: