SOP-001166

Software and IT Change Management

Aim and Purpose

The aim of this SOP is to ensure that the configuration of hardware and software is traceable at all times.
The SOP provides the necessary processes and details to ensure that no modifications are carried out
without being subjected to these controls.
Software is a critical component of computerised systems. The aim of this SOP is to ensure that GxP-
relevant software or other critical software (e.g. financial software) is registered and qualified for use and
that standard software can always be installed quickly and maintained in full working order. The
classification of software helps to determine the necessary validation activities.
This SOP applies to general IT infrastructure modifications (e.g. networks, servers, PCs, release updates,
security patches for operating systems, etc.) and also governs the initiation of requests for, and the
approval of, modifications affecting basic software and complex IT systems such as but not exclusively
the the SAP (ERP) system.

1 Scope

This SOP applies to all sections of XXXXX partaking in the maintenance, modification or configuration of
IT hardware and software and the computerised systems.

2 Responsibilities

Function Responsibility

System Owner / Service Expert appraisal of change controls (F-001861) and implementation
Owner documentation (F-001862)

Preparation of the application for software classification (F-001856)

Preparation of qualification and validation documents

Initiating necessary software installations and software classifications

IT Preparation and review of the modification matrix (F-001858)

Verification of the technical feasibility of change controls (F-001861)

Documentation of the change implementation (F-001862)

Review of the software classification (F-001856)

Creation and maintenance of the IT logbooks

Documentation of modifications

Documentation of installation and qualification work

Installation of software and hardware

Technical appraisal of qualification and validation documents

QS Approval of the modification matrix (F-001858)

Approval of change controls (F-001861) and implementation

SOP-001166
Software and IT Change Management
Function
3 Definitions / Abbreviations
Term / abbreviation
CR
Linux server
Environment types
productive system / test
system / development system
Logbook
Modification Matrix
Modifications / changes
Responsibility
documentations (F-001862)
Approval of software classifications (F-001856)
Numbering of change controls and thus creation of traceability
Approval of installation and qualification documents for work related to
modifications and software installation
Manage the software classification documentation
Manage the change control documentation, e.g. executed change
controls (F-001861) and documenting implementations (F-001862)
Description
Change control (= Change Request). A CR is a request for a Non-
Routine Change. Form F-001861 (IT Change Request) is used for this
purpose.
The Linux server is domain server and servers are used to give all
staff access to file sharing and printing application
The following environment types are normally available during the
operation and life cycle of IT systems and services (possibly only some
of them, depending on complexity):
Users work day-to-day with the productive system, within which
they generate business & quality-relevant and/or approval/release-
relevant data. A test system (called a validation system in older
systems) is reserved exclusively for testing modifications prior to
implementation in the productive system. Test systems are under
control consistent with those of the productive system.
A development system is used to prepare and test new software
releases. It is not under the same level of GMP control as the
productive system
The IT logbook is a service-specific logbook in which all modifications,
faults and other incidents relating to the IT hardware and software of a
service (see Section Documentation in the IT Logbook) are
documented.
Form F-001858 (Modification Matrix) defines whether a modification is
to be classified as a Routine Change or a Non-Routine Change. If a
modification is not defined in the Modification Matrix, the planned
modification is automatically classified as a Non-Routine Change.
During normal operation of an IT infrastructure, changes /
Page 2 of 10
SOP-001166
Software and IT Change Management
Term / abbreviation Description
modifications are always necessary and a matter of routine to rectify
faults or problems and implement enhancements.
Non-Routine Change A modification that alters or potentially alters quality- or business-
critical processes or data is classified as a Non-Routine Change.
Furthermore, if current technical knowledge does not explicitly rule out
that a modification will result in such consequences, the modification in
question is classified as a Non-Routine change.
Objects The term “objects” refers to various types of information. Objects are
not system dependent (e.g. the object “analytical raw data” can be
present in several systems).
Office PC / PC An office PC is a computer that is used for office work. It is usually a
commercially available PC or notebook computer.
Platform The term “platform” refers to the hardware on which software is
installed and where a system documentation is maintained. A platform
can thus be a ChemStation or a server (also referred to as a server
platform below) but not an office PC or something similar.
Routine Change A Routine Change is a modification that is not a Non-Routine Change
as defined in form F-001858 (Modification Matrix) (e.g. routine work or
no major alteration of functions).
The term used previously in the literature for such changes was
configuration.
Server / SRV A server is a computer on which data is stored and/or processed
centrally. Users except administrators cannot usually log-into a server
directly. They use applications to interact with the server or use
remote access to use data or software.
Service A (productive) service is provided directly by XXXXX’s IT department to
internal or external customers (e.g. communication, SAP service, print
service). A service is normally made up of several components that are
referred to as a system.
Software classification The classification of software takes into account how the software
handles the creation, processing and storage of data and information
that can have a direct influence on the quality of analytical data (GLP
compliance), product quality (cGMP compliance) or critical business
data.
System A system is a combination of hardware and software that processes or
stores object data (e.g. server, software, etc.). A system is used for
inputting, electronically processing and outputting information that is
used either to document or automatically control a process.

Page 3 of 10
SOP-001166
Software and IT Change Management

4 Description

4.1 Regulations for Various Types of Computers and Platforms

4.1.1 Office PCs

Initial installation of office PCs and thin clients is not documented. Modifications are recorded and entered
in the IT logbook. No class 3-5 software is installed on office PCs / thin clients. Class 3-5 software and
also other software for control
The installation of patches on office PCs / thin clients is treated by default as a Routine Change and does
not therefore require approval by means of a Change Request form F-001861.
Installation work is documented via the IT logbook or, if appropriate, in qualification documents for a unit
/ system.

4.1.2 Servers

The installation of software patches on Linux servers is always treated as a Routine Change and does not
therefore require approval by means of a CR (F-001861).
Installation work is documented via the IT logbook or, if appropriate, in qualification documents for a unit
/ system.

4.1.3 Servers and SAP

The installation of new servers and SAP is always documented using check list F-001565 (IQ OQ for the
Setup of SAP, Servers and Platforms). The approval form F-001565 form is filed in the IT logbook.
The installation of software patches on SAP and other servers is treated as defined in the Modification
Matrix (F-001858) of the platform and thus requires CR (F-001861) as recorded therein. The logbook of
each system contains the changes and copies of the CR’s where required.

4.1.4 Anti-Virus Protection

Anti-virus protection is installed on all platforms and clients, with the exception of operating systems or
applications that are not supported by anti-virus software. Anti-virus software is configured in such a way
that data is automatically verified when files are run (on hard disks, CD-ROMs, floppy drives and USB
devices). Updating of virus signatures is centrally managed by IT and installation of anti-virus software
respectively signature updates are treated by default as a Routine Change.
Systems and platforms without installed anti-virus software must be set-up or managed such that they
cannot access the internet nor can be accessed from the internet. Where needed firewall rules and
routing entries in the network infrastructure prevent this.

Page 4 of 10
SOP-001166
Software and IT Change Management
4.2 Modification Matrix

The Modification Matrix (F-001858) for each system is prepared and as a default is identical for all
systems. Where needed specific differences to this master set of modification rules are added but should
be kept to a minimum. The matrix describes pre-defined modification situations and their classification
into Routine Change or Non-Routine Change. The matrix is prepared and modified by IT in consultation
with the System Owners and approved by QS.

4.2.1 Requested Changes

Requested changes may come from many different sources such as user requests or technical
necessities. There is no specific form for the transmission of such a request, but, provided it is not an
emergency request, the minimum is a help desk entry (classified by IT as change request in the
helpdesk). IT receives the request and initiates further steps, e.g. requests the creation of a CR based on
the relevant modification matrix.

4.2.2 Urgency

IT verifies the urgency of the requested change. Where the normal execution / documentation of the
modifications prevents an adequate response time to the need the request can be implemented
immediately. This applies for example for critical security patches, anti-virus signature updates, exchange
of critical faulty hardware. In such cases, the priority is to attempt to resolve the problem. The precise
course of events, the modifications that were implemented and additional measures must then be
described retrospectively via a deviation report
However this type of change should remain exceptional and is termed emergency change. In the
documentation of an emergency change there must be an explanation, why the change was applied
without prior approval and testing. The IT Head must be informed about emergency changes and
approve the reasoning.
Should the post-emergency deviation process show that the emergency process has been used
inappropriately and without satisfactory reasoning the relevant personnel is retrained, and in repetitive
cases, other personnel relevant sanctions as per employment regulations applied.

4.2.3 Software Changes

If the modification affects a software installation and is deemed to be a Non-Routine Change, the change
control must specify whether or not the modified software must be re-classified as described in Section
Software Management.

4.2.4 Hardware Changes

Replacement of hardware by identical hardware is a like by change and is per default a Routine Change
that is documented in the logbook. Replacement by non-identical hardware must be executed under
change control for business-critical or GxP critical systems.

Page 5 of 10
SOP-001166
Software and IT Change Management
4.2.5 Classification into Routine and Non-Routine Changes – Modification
Matrix

In the case of modifications / changes, a distinction is made between Routine Changes and Non-Routine
Changes.
Routine Changes are modifications for which no detrimental impact on platforms, systems or services is
expected and will not affect GxP or business critical data and processes directly. Non-Routine Changes
may have a greater impact on platforms, systems or services and must thus be more carefully evaluated
and the approval of minimally the Process / System owner, IT.
The Modification Matrix (F-001858) is used to help distinguish between Routine Changes and Non-Routine
Changes. This makes it easy to classify modifications already recorded in the Modification Matrix as
Routine Changes or Non-Routine Changes. If a modification is not recorded in the Modification Matrix, it
is automatically classified as a Non-Routine Change.
If the post-assessment of a Routine Change shows, that systems / services / platforms / data where
affected in unexpected ways, a deviation report is initiated and the consequences evaluated and
implemented, e.g. the reclassification of the type of change.

4.2.6 Routine Changes

If a modification is defined as a Routine Change, it can be implemented directly in the productive system,
without the need for further approval procedures. An entry in the IT logbook is necessary for traceability
purposes.

4.2.7 Non-Routine Changes

4.2.7.1 Request

A Non-Routine Change must be requested using form F-001861 (IT Change Request) The submitting
party (any employee, a System Owner or IT) requests a CR number. CRs are not given a location
abbreviation when they are recorded and they are numbered consecutively.
The CR (F-001861) describes the change, provides a cost estimate and a risk assessment, evaluates the
influence of the planned change on other systems, sets out which documents are required for the
processing and conclusion of the change and defines a test system and test points.
Text explaining and giving reasons for the risk classification must be added to the risk assessment
(Section 4) in form F-001861.
If it is not possible to define a test system for the implementation of the change, part of the productive
system or the entire productive system is defined as the test system for a limited period of time. This is
to be explained and reasons given as appropriate in the CR. During the test period the parts or the entire
system, as defined, cannot be used for productive activities, respectively the users must exert extra
controls to maintain the GxP or business status of the critical actions and data.
The Change Request is processed by IT and assessed in terms of its technical feasibility and desirability
with the long term plans for the system and service and quality, legal and financial considerations and
whether the planned modification influences other systems or platforms. The Process Manager / System

Page 6 of 10
SOP-001166
Software and IT Change Management
Owner / Service Owner then carries out an expert appraisal and reviews in particular the impact on the
business processes.
The Head of IT at XXXXX or the manager of the resources who are involved verifies that the necessary
resources are available.

If a Change Request is rejected by IT, Process Owner / System Owner , reasons must be provided. In
such a case. Rejection of a CR cannot be undone, the decision is final. If for whatever reason the CR is
considered to become desirable again, a new CR has to be issued.
QS sends an electronic copy (pdf) of the IT Change to inform the submitting party and the responsible IT
employees that the planned modification has been approved or rejected as may be the case.

4.2.7.2 Implementation

implementation of the intended change can start. If a test system exists and is defined in form F-001861,
the modifications are implemented in the test system first.
Implementation is documented using form F-001862 (Change control – Implementation). Once
implementation in the test system has been concluded, IT assesses whether or not it was successful.

If no test system was defined with the CR (F-001861). Installation takes place directly in the productive
system in line with the CR. Accordingly, part 1 of form F-001862 is crossed-out to indicate that this was
not needed.
Once the work and all defined tests have been concluded in the productive system, the person
responsible for implementation completes form F-001862. IT verifies that the technical details in the
documentation are correct and the System Owner / Service Owner verifies that the specialist details are
correct.
IT documents the implemented modifications in the IT logbook including the CR number and, if
necessary. If appropriate, the System Owner also documents them in the system logbooks with a
reference to the relevant Change Request.
enters the conclusion of the change in list L-002259 (IT Changes) and archives the documentation. also
archives independent documents prepared during implementation such as qualification plans or reports
(separately from the changes).

4.2.8 Documentation in the IT Logbook

IT keeps an IT logbook based on form F-001859 for each service or system. Routine Changes, Non-
Routine Changes and other observations are documented in this logbook.
Additional data can also be archived in the logbook. Form F-001860 (IT Logbook Contents) serves as the
table of contents. Subsequent pages are prepared using form F-001859.
In addition to the IT logbooks, System Owners can also keep service / system logbooks documenting
modifications to the service / system itself (e.g. SAP process modifications, etc.). The relevant System
Owner or an individual appointed by the System Owner is responsible for the completeness and proper
management of these logbooks.

Page 7 of 10
SOP-001166
Software and IT Change Management
4.3 Software Management

4.3.1 New Software

Before software can be installed, it must be registered and classified. This also applies to new versions of
a software or software modified such that the original assumptions about software classification are no
longer valid. IT verifies whether the software version has already been recorded and classified. If it has,
work can continue. Otherwise, IT initiates the software registering process in line with form F-001856
(Software Registration and Classification).

If software is GxP relevant, it is assigned to one of the classes 3-5 in line with the specifications of GAMP
5.
Depending on its function and area of use, firmware is assigned to class 0, 3, 4 or 5.
Critical business software, e.g. financial software or HR software, security critical software are considered
in analogy to GxP (x=Business)
In the subsequent the term critical software is used to include both GxP and business critical software

Description Examples Class

Not critical software Access control software, management tools,

0
software with a business-relevant impact

No crtical data is created directly MS Office (not including Excel sheets),

Adobe Reader

Operating systems
1

This applies only to operating systems that Microsoft Windows, Linux

are running critical software; operating
systems themselves are not tested
separately, but only in conjunction with a
functional test for a specific application

Standard software packages

3

Commercially available software that is not Analytical software for HPLC, mass
configured for a specific process spectrometers, SMB control and method
development

Configurable software packages

4

Commercially available software that is process control system, ACD (NMR)

configured for processes

User-specific software (bespoke)

5

Software that has been developed for specific Excel sheets for calculation of GxP-relevant
customer requirements data

Page 8 of 10
SOP-001166
Software and IT Change Management

Class 0 software is also recorded using form F-001856 (Software Registration and Classification), but
there is no subsequent documentation of installation etc..
verifies the definition on form F-001856 (Software Registration and Classification). If QS disagrees,
consultation takes place with the personnel involved and, if appropriate, the relevant department heads
in order to agree on how to proceed.
Following approval, enters the result in the overview list of classified software (L-002258, Overview
Critical Software).
Additional entries are made in L-002258 (Overview Critical Software) to record the equipment or platform
on which the software has been installed or the environment in which the software is being used. Details
are also to be provided in L-002258 (Overview Critical Software) regarding the qualification and/or
validation status of the software and also regarding the system review.
manage and file released F-001856 forms (Software Registration and Classification).
At request, IT can provide a list of software installed throughout the company (e.g. to compare with the
list of qualified software).
New versions of software will not be added as separate records. The new versions are listed in the
relevant sections in F-001856 (Software Registration and Classification) and list L-002258 (Overview
Critical Software). The approval / disapproval of software versions needs both verification through IT .
For software classes 3-5 or qualified / validated systems an IT Change Request (F-001861) respectively
other documentation can be referenced.
Software no longer used in the line-of-business processes (either because it is deleted completely from all
systems and platforms or if it is only maintained as a necessary reference to access historical data for a
limited small number of employees) will be identified in the L-002258 (Overview Critical Software) with a
remark, that the software is no longer used / maintained. As appropriate, a reference to other documents
detailing the out-of-service of the software is made. Software versions no longer used will be deleted in
L-002258 (Overview Critical Software) and the Out-of-Service date recorded in F-001856 (Software
Registration and Classification) and L-002258.

4.3.2 Software Qualification

The classification of software leads to various validations / qualification requirements depending on to

which class a software package is assigned to.
The scope of validation / qualification work related to software classes 3-5 varies, depending on the class
and the complexity of the software and is defined by the responsible IT staff member in cooperation with
the submitting party and/or System Owner and QS.
In principle, qualification is executed in line with (Validation Master Plan) and ancillary documents. An
appropriate risk analysis must be performed for all systems. The qualification procedure is then defined
on the basis of these two documents.
If software is part of a piece of equipment, it should be qualified together with the equipment (relevant
aspects of the software qualification must be taken into account in the qualification plans for the system).
If it is a standalone software product, an appropriate risk analysis must be performed for the software
itself (and any associated hardware) and the scope of qualification must be defined.

Page 9 of 10
SOP-001166
Software and IT Change Management
Qualification of operating systems and firmware is carried out in a similar way in conjunction with
qualification of the application and/or unit.
QS together with the System Owner is responsible for monitoring compliance with regulatory
requirements and GxP guidelines relating to the release of the qualification and/or validation plans and
reports.
Accordingly, it must be defined in the qualification plans when qualification / validation is deemed to have
been concluded and how the system is released for use.
As part of the implementation and qualification project, IT is responsible for the installation of the
hardware and software parts and for the administration of permissions and users. Further qualification /
validation work and receipt of the qualified status are the responsibility of the Equipment Owner / Process
Owner / System Owner / Implementation project manager.

References

1.1 Forms

F-001856 (Software Registration and Classification)

F-001858 (Modification Matrix)
F-001860 (IT Logbook Content Page)
F-001859 (IT Logbook Additional Page)
F-001861 (IT Change Request)
F-001862 (IT Change Implementation Report)

1.2 Lists

L-001285 (Overview Critical Software)

Check Lists

None

1.3 Other

- none

Page 10 of 10