Document No.

Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 1 of 35

Validation of Computer Systems

Validation Manual

Customer, Location Siemens, Global

Project, Project-ID Siemens Validation Manual, n/a
Document No. GMP-VM-GEN-001
Version V03.04
Date 20 Oct 2021

Management of this document

Task Role/Company Name / Signature / Date
Author GMP Regulations
Siemens 26 Oct 2021
Approved by Head of GMP Regulations
Digital signiert von Gierse Alexander
Gierse DN: cn=Gierse Alexander, o=Siemens,

Siemens [email protected]

Alexander Grund: I approve the document

Datum: 2021.10.28 14:41:03 +02'00'

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 2 of 35

Document history
Version Description Author Date
V03.04 Template for Change Request / Change Note VM Pharma 20 Oct 2021
GMP Regulations
V03.03 Design specification (DS) becomes configuration VM Pharma 12 Apr 2021
and design (CS/DS). GMP Regulations
Added the document “Glossary” in chapters 1.5 and
4.3.
Minimal formal adaption.
V03.02 Style fonts revised. VM Pharma 31 Aug 2020
Document numbers of templates adapted. GMP Regulations
Revision of chapter 7.5 “Structure of the test
documentation”
New templates for DS User Management and User
Rights matrix
V03.01 Minimal formal adaption. VM Pharma 16 Dec 2019
Some further appendices/templates reworked GMP Regulations
V03.00 Complete revision of the content and form of the VSS Pharma 14 Nov 2018
validation manual including all appendices, which in GMP Regulations
future will be independent documents as templates.
New document numbers.
Some appendices/templates omitted.
2.1 Error corrections in appendix 12a VSS Pharma 28 Aug 2012
(SOP Change Control) GMP Regulations
2.0 Adaptation to GAMP 5, error corrections VMM Pharma 14 Sep 2009
GMP Regulations
1.0.1 Correction of document-wide bookmarks CC Pharma 09 Jun 2008
GMP Regulations
1.0 Version 1.0 for release CC Pharma 06 Jun 2007
GMP Regulations

Basic documents
The basic documents are required as a basis for the creation of this document and must therefore be
available in advance. These are independent documents with their own versioning and release procedure.

Document No. Version Document title Date

n/a n/a n/a n/a

Referenced documents
The referenced documents are independent documents with their own versioning and release procedure.
These documents are referenced in this document. However, they have no influence on the release of this
document.

Document No. Document title

n/a n/a

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 3 of 35

Terms and definitions / abbreviations

See Glossary and abbreviations (chapter 9).

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 4 of 35

Table of Contents
1 Introduction ........................................................................................................... 6
1.1 Objective .............................................................................................................. 6
1.2 Area of application ............................................................................................... 6
1.3 Regulatory background........................................................................................ 7
1.4 Working with the Validation Manual ..................................................................... 7
1.5 Scope of the Validation Manual ........................................................................... 8
2 Basics and terms .................................................................................................. 9
2.1 GMP .................................................................................................................... 9
2.2 Terms related to validation................................................................................... 9
2.3 Conformity to GAMP 5 and other standards ...................................................... 10
2.4 Responsibilities of the supplier .......................................................................... 11
2.5 Validation Manager in Project (VMiP) ................................................................ 12
3 Lifecycle model ................................................................................................... 13
3.1 Lifecycle depending on complexity .................................................................... 13
3.2 Definition of a project-specific lifecycle .............................................................. 14
3.3 Typical project documents ................................................................................. 14
3.3.1 Planning documents.............................................................................................. 14
3.3.2 Procedures............................................................................................................ 14
3.3.3 Specifications ........................................................................................................ 15
3.3.4 Test documentation ............................................................................................... 15
4 Project management and validation planning .................................................. 16
4.1 Validation planning of the customer ................................................................... 16
4.2 Quality and Project Plan (QPP) of the supplier .................................................. 16
4.3 Good documentation practice ............................................................................ 17
4.4 Risk assessment................................................................................................ 18
4.5 Master test plan and master test report ............................................................. 19
4.5.1 Master test plan..................................................................................................... 19
4.5.2 Master test report .................................................................................................. 19
5 Specifications ...................................................................................................... 20
5.1 User requirements specification (URS).............................................................. 20
5.2 Functional specification (FS).............................................................................. 21
5.3 Configuration and design (CS/DS)..................................................................... 22
5.4 Design review and traceability ........................................................................... 23
6 System configuration/coding ............................................................................. 24
6.1 Coding standards / good engineering practice................................................... 24
6.2 Change and configuration management ............................................................ 25
7 Tests and test documents .................................................................................. 26
7.1 Test levels according to GAMP 5....................................................................... 26
7.2 Test phases in the project .................................................................................. 26
7.2.1 Software Module Test (SMT)................................................................................. 27
7.2.2 Factory Acceptance Test (FAT)............................................................................. 27
7.2.3 Site Acceptance Test (SAT) .................................................................................. 27
7.3 Test methods ..................................................................................................... 28
7.4 Determining the time sequence of tests............................................................. 28
7.5 Structure of the test documentation ................................................................... 29

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 5 of 35

7.5.1 Test plan / test scope list ....................................................................................... 29

7.5.2 Test specifications / test protocols / test result sheets ........................................... 29
7.5.3 Test incident list / test incident sheet ..................................................................... 30
7.5.4 Test report............................................................................................................. 31
8 Validation Manual and related documents........................................................ 32
8.1 Technical documentation and Online Support ................................................... 32
8.2 GMP Engineering Manual .................................................................................. 32
8.3 ERES Compliance Responses .......................................................................... 33
8.4 Siemens GMP training material ......................................................................... 33
9 Glossary and abbreviations ............................................................................... 34
10 List of Literature .................................................................................................. 35

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 6 of 35

1 Introduction
This Validation Manual gives guidance to develop automation projects for the pharmaceutical industry and,
in particular, for preparing the necessary documentation for the validation.
It contains a bundled set of templates for project planning documents, for specifying and testing automated
systems, and for standard operating procedures.
The complete package is intended only for internal Siemens use and for certified Solution
Partner Industry Pharmaceutical. The Validation Manual may not be passed on to external
parties, neither to customers nor to system integrators.

1.1 Objective
This document explains the lifecycle model that can be used in the regulated pharmaceutical industries
and its assignment to Siemens’ procedures and templates.
The Validation Manual is intended for the following purposes and target groups:
 As a guide for automation projects and the validation of computer systems in projects for
the pharmaceutical industry. It explains a complete project methodology, including document
templates with corresponding detailed explanations.
 As a customer communication document that demonstrates to the customer Siemens'
validation expertise and the associated cost-effective work methods for regulated pharmaceutical
projects. The objective is also to improve communication between the sales, project, and
customer service teams.
 As an internal reference document that helps to provide a consistent understanding of the
validation of computer systems.
 As a training document for new Siemens employees and for industry partners in the
pharmaceutical industry.

1.2 Area of application

The focus is on pharmaceutical production facilities that are subject to current Good Manufacturing Practice
(cGMP) and that need to comply with national regulations.
The Validation Manual identifies, step-by-step, the validation activities to be applied throughout the entire
lifecycle of a computer system, whereby the computer system only represents part of the automated
production system.
In this Validation Manual, the term "computer system" is used to mean a system-independent synonym,
e.g. for the following systems (this list is not complete):
 Process Control System (PCS)
 Automation system in machines (also known as package units)
 Manufacturing Execution System (MES)
 Monitoring system
The responsibilities of the customer and the system supplier are presented and broken down to the
individual roles in the project. The focus is also on the use of "good practices" (GxP) and project
management as tools to perform projects as efficiently as possible.
Preserving the valid state in the event of modifications and maintenance during subsequent operation of
the computer system is the responsibility of the pharmaceutical company and is not the subject of this
manual.

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 7 of 35

1.3 Regulatory background

Good Manufacturing Practice (GMP) is defined as "That part of Quality Assurance which ensures that […]
products are consistently produced and controlled to the quality standards appropriate to their intended
use." (Definition of WHO, similar to the EMA).
The requirements are defined in more concrete terms in the following regulations (among others), see also
chapter 10 “List of Literature”:
 Title 21 of the Code of Federal Regulations (21 CFR) of the USA, enforced and reviewed by the
Food and Drug Administration (FDA, e.g., Parts 210, 211, 11, 820)
 EU GMP Guide, in particular Annex 11 relating to the validation and use of computer-aided
systems, each implemented in national law of the EU member states
 National regulations of other countries, which are monitored and enforced by the relevant national
supervisory authorities
 Recommendations from international committees (such as the International Council on
Harmonisation – ICH and the Pharmaceutical Inspection Co-operation Scheme – PIC/S).
The objective of GMP is to ensure patient safety through drug safety, with a focus on three aspects in
manufacturing processes:
 Patient safety
 Product quality
 Data integrity
Data security has therefore become a very important aspect for inspections as well.
Customers expect their suppliers to have a deep understanding of the pharmaceutical environment and the
special conditions of pharmaceutical production. The systems and services supplied should enable
effective and efficient validation and facilitate operation, maintenance and repair as well as change control.
Clear, unambiguous and accurate documentation during all project phases facilitates the creation of
validation documentation and correction of deviations (test incidents) that are identified during the test
phases.
As a supplier of automation systems and related services, Siemens is committed to meeting the highest
quality standards. This includes the responsibility of ensuring that the installed systems and support
services meet customer requirements.

1.4 Working with the Validation Manual

The Validation Manual and its templates complement the processes and systems of service groups of
Siemens AG.
The document templates should be seen as a GAMP 5-compliant starting point. They must be
analyzed and adapted on a project-specific basis.
You also need to check whether other criteria should be used that are not described in the templates.
Customer-specific standards must be examined and perhaps included in the project-specific documents.
Project-specific specifications such as document management and change control need to be
communicated to all project members. These training courses must be documented.

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 8 of 35

1.5 Scope of the Validation Manual

In addition to this main document, the complete package of the Siemens Validation Manual contains
several other documents that can be used as templates for project documents.

Title Document No. Referenced in chapter

Validation Manual (this document) GMP-VM-GEN-001 1.1
Document list GMP-VM-LST-001 4.3
Transmittal (document handover protocol) GMP-VM-LST-002 4.3
Glossary GMP-VM-LST-005 4.3
Quality and Project Plan (QPP) GMP-VM-QPP-001 4.2
SOP Document Management GMP-VM-SOP-001 4.3
Document template in Word GMP-VM-SOP-005 4.3
Document template in Excel GMP-VM-SOP-006 4.3
SOP Coding Standards GMP-VM-SOP-004 6.1
SOP Change and Configuration Management GMP-VM-SOP-002 6.2
Change Request / Change Note GMP-VM-TPL-001 6.2
List of change requests GMP-VM-LST-004 6.2
Traceability matrix GMP-VM-LST-003 5.4
Risk management n/a (no template) 4.4
Master Test Plan (MTP) GMP-VM-VER-001 4.5
Master Test Report (MTR) GMP-VM-VER-009 4.5
User requirements specification (URS) n/a (no template) 5.1
Functional specification (FS) GMP-VM-SPC-002 5.2
Configuration and design (CS/DS) GMP-VM-SPC-003 5.3
Hardware design specification (HDS) GMP-VM-SPC-004 5.3
Software design specification (SDS) GMP-VM-SPC-005 5.3
Software module design specification (SMDS) GMP-VM-SPC-005 5.3
DS User management GMP-VM-SPC-006 5.3
DS User rights matrix Opcenter Execution GMP-VM-SPC-007 5.3
Pharma
DS User rights matrix SIMATIC BATCH GMP-VM-SPC-008 5.3
Test plan e.g., for FAT/SAT GMP-VM-VER-002 7.5.1
Test scope list e.g., for FAT/SAT GMP-VM-VER-007 7.5.1 and 7.5.4
Test report e.g., for FAT/SAT GMP-VM-VER-008 7.5.4
Test incident sheet GMP-VM-VER-005 7.5.3
Test incident list GMP-VM-VER-006 7.5.3
Test specification / test protocol GMP-VM-VER-003 7.5.2
Test results sheet GMP-VM-VER-004 7.5.2
SOP Test Execution GMP-VM-SOP-003 7.5.2

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 9 of 35

2 Basics and terms

2.1 GMP
Good Manufacturing Practice (GMP) places demands on the manufacture of pharmaceuticals, active
ingredients and medical devices and on the assurance of their quality and purity.
In accordance with GMP regulations, the manufacture of a drug must be performed in such a way that no
confusion of components or chemical or microbiological impurities can occur during the production process,
that the final product contains the specified and required quantities of active ingredients and that the
biological availability and shelf life of the active ingredient is guaranteed. This includes requirements for
personnel, buildings, technical equipment, hygiene, raw materials, manufacturing processes, labeling and
packaging, quality assurance and control systems, self-inspection, proof of continued existence, processing
and documentation of complaints and reports on undesirable side effects.

Figure 1: Areas of GMP

The main message of the GMP rules is that quality must be produced. Checks are only a tool to confirm
GMP-compliant production.

2.2 Terms related to validation

The sometimes-difficult differentiation of the terms qualification and validation in the past has been
considerably simplified by the introduction of the term "verification". Nevertheless, all three terms are used
in everyday language, sometimes synonymous with each other.

Qualification (ISO) The process of demonstrating the ability to meet the specified
requirements. Qualification usually focuses on equipment and
location.
Validation Formal and systematic proof that a process is highly likely to
continually produce products that meet specifications and quality
requirements. Validation focuses on processes.
Computer validation (also CSV = Validation applied to automation and computer systems. The term
Computer System Validation) is used less and less often.

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 10 of 35

Verification Confirmation by providing objective proof that the specified

requirements have been met. Within the GAMP 5 Guide, the term
"verification" is replacing the terms qualification and validation.
The results of a verification fit seamlessly into the results of other
qualification and validation measures without requiring re-testing.
Compliance Compliance with laws, rules and requirements. Proof of
compliance is provided by validation activities.

In order to achieve the status of compliance, the procedure according to a lifecycle is an indispensable
prerequisite right from the start. Verification thus becomes an integral part of the lifecycle of a system,
process or product and a mandatory prerequisite for compliance.
The practice of "retrospective" validation, which was tolerated to an extent in the past, is generally no longer
accepted by the authorities.

2.3 Conformity to GAMP 5 and other standards

During the development of this validation manual, conformity to the concepts and approaches of the current
GAMP 5 Guide [1] and relevant GAMP Good Practice Guides were and continue to be the top priority. In
addition, the validation manual takes other regulations (e.g. US FDA and EU regulations) and
recommendations of relevant organizations (e.g. ISPE, PDA, APV, ICH) into account and references them
if necessary.
At some points, the content of the validation manual clearly exceeds or deviates from the level of detail of
the GAMP 5 Guide. The majority of these differences result from practical considerations and the coverage
of topics by other systems (e.g. quality management system, PM@Siemens project guidelines, etc.). The
following table shows a comparison of the specifications according to the GAMP 5 Guide and the Siemens
Validation Manual.

GAMP 5 Guide Siemens Validation Manual

System description Integral part of the template for FS1
User requirements specification (URS) Template for URS, see chapter 5.1
higher degree of detail,
greater involvement of the solution provider
Functional specification (FS) Template for FS2, see chapter 5.2
Higher degree of detail
Configuration and design Templates3 for DS, SDS, HDS, see chapter 5.3
Hardware design including SMDS
Software design, sequences, and modules

It should be noted that the regulated company itself (i.e. the customer) is ultimately responsible for
compliance. However, the supplier can support the customer's requirements by offering specific services
as additional, beneficial (and payable) activities.

1
GAMP 5 leaves the execution of the system description as a separate document or as part of another specification up to the
pharmaceutical company, as well as the procedures for document management and revision of the document. The corresponding
contents are part of the FS and DS in the Validation Manual.
2
Similar to the URS template, the level of detail in the FS template goes beyond the recommendations of the GAMP 5 Guide. This
takes into account the procedures of the ISA S88 and ISA S95 standards, which already apply macro-modularization at (process-)
functional level.
3
The multi-layered structure of the DS can also be found in the corresponding template of the Validation Manual. Integration as a
chapter of a document is useful for projects of limited size, but for larger projects or projects with a long runtime it makes sense and
has already been planned to split them into several individual documents.
Independent configuration specification is omitted in favor of integration of appropriate content into the HDS, SDS and SMDS.

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 11 of 35

2.4 Responsibilities of the supplier

In its chapter 7, the GAMP 5 Guide explains the good practices of a supplier. They include:
 Development of a quality management system (QMS)
 Quality and project planning
 Management of subcontractors
 Document specifications clearly and comprehensibly
 Hardware setup and software creation
 Performance of testing
 Approval of the system
 Providing agreed documentation
 Support of maintenance of the system during operation if required
 Established procedures for replacement and decommissioning of the system (upon agreement)
Depending on the type of supply, the requirements vary between suppliers of products, applications and
services.

The requirements of the GAMP 5 Guide for suppliers are not covered exclusively by this Validation Manual,
but also by the following processes and systems:
 Quality management system of the respective unit
 Project management and configuration guidelines (e.g. PM@Siemens)
 Product development and manufacturing processes (in the case of Siemens, for example, PLM)

Figure 2: Coverage of GAMP 5 requirements by the validation manual

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 12 of 35

2.5 Validation Manager in Project (VMiP)

In addition to the common demands on professional project and quality management, there are some
specific requirements in the regulated industries. It is appropriate, to involve a qualified expert in the project
team for the additional tasks of validation.
We call this role “Validation Manager in Project“ (VMiP) within this Validation Manual. In the project, he/she
is responsible for planning and support of validation activities within the supplier’s scope of supply.
Typical tasks of the VMiP are (together with the project manager):
 Definition of the project execution (specifications, test phases, documents to be delivered)
 Creation of documents like QPP, Traceability Matrix, Master Test Plan
 Document management or at least close coordination
 Conventions for test execution and test documentation, monitoring of test documentation
The VMiP coordinates these measures, conducts trainings for the project team and guides them through
the activities. The VMiP gives advice and monitors all relevant steps during project execution.
Every single team member is responsible to comply with the defined quality and project standards,
supported by the VMiP. Because also the ordinary tasks of every project, like document management and
change control / claim management, need extraordinary awareness and more strength in a GMP-regulated
project.
So, the VMiP is not a one-man validation team being separated from the project but is a partner to the
project manager and the whole project team. The VMiP belongs to the core team of the project and should
be fully integrated in the project from the very beginning.

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 13 of 35

3 Lifecycle model
One of the basic principles of validation is the definition of a system lifecycle, which essentially comprises
three main steps:
 Planning and specification of the system
 Implementation (configuration / coding) of the system according to specification
 Test and document that the system meets the specification (verification)
Sequentially arranged in a V shape, this is also referred to as a V model. This means that the system is
verified against the respective specification on the left side during the course of the right branch
(verification).

Figure 3: General validation procedure (similar to GAMP 5 Figure 3.3)

Pharmaceutical companies use this or a similar approach as the basis for their validation programs,
including the validation of computer systems. A logical, modular procedure makes validation easier to
understand.

3.1 Lifecycle depending on complexity

Chapter 4 of the GAMP 5 Guide describes three examples of the procedure for products or systems with
different configuration depths. Differentiation is achieved by defining different software categories, which
are described in GAMP 5 Appendix M4:
 Category 1: Infrastructure software
 Category 2: No longer in use
 Category 3: Non-configured products
 Category 4: Configured products
 Category 5: Custom applications
Depending on these categories, the GAMP 5 Guide defines the individual specification levels (see chapter
5) and test levels (see chapter 7.1).
All software categories are often coexisting in complex and highly modular systems. Then customer-specific
functions (category 5) have to be specified in all details, whereas function blocks from standard libraries (in
the delivery state category 3, embedded then category 4) are only assigned to the data point and instance-
specific parameters are defined.

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 14 of 35

3.2 Definition of a project-specific lifecycle

All lifecycle models contained in this manual and its related documents are exactly this: Models with
exemplary character.

Figure 4: Framework model for a development lifecycle in the Validation Manual

The lifecycle model to be used for a specific project must be adapted to the specific requirements based
on the model shown above.

3.3 Typical project documents

Various documents are created throughout the described project lifecycle. They ultimately make up a large
part of the validation documentation.
The modularity of the validation manual allows several documents to be combined into a single one, as
well as the splitting of one specification document into a bundle of smaller specification documents (e.g.
hardware, network, software, HMI specification).

3.3.1 Planning documents

The planning documents form the basis for the execution of the project.
A common understanding of project execution, documentation, mutual tasks and test scenarios agreed in
writing has a considerable influence on the course and ultimately the success of the project.
 Validation planning of the customer, see chapter 4.1
 Quality and project plan, see chapter 4.2
 Master test plan, see chapter 4.5

3.3.2 Procedures
Procedures are methods that are either fixed to the supplier or are defined for the specific project. Under
certain circumstances, the client's specifications may also have to be observed. Procedures are generally
described in SOPs (standard operating procedures).
 Document management, see chapter 4.3
 Specifications for configuration and change control etc., see chapter 6

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 15 of 35

3.3.3 Specifications
The specification documents describe how the system implements the requirements and how it is set up in
detail.
 Functional specification, see chapter 5.2
 Detailed technical specifications (configuration and design), see chapter 5.3

3.3.4 Test documentation

The test phases defined in the master test plan are planned individually and the tests are specified,
completed and fully documented. The criticality and complexity as well as the degree of programming play
a role in determining which functions should be tested with which intensity.
 Test phases in the project, see chapter 7.2
 Test methods, see chapter 7.3
 Test execution, see chapter 7.5

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 16 of 35

4 Project management and validation planning

While the validation planning of the entire plant is the responsibility of the customer, quality and project
planning (QPP) and test organization (MTP/MTR) for the computer system are the responsibility of the
solution provider within the scope of delivery. For this reason, QPP and MTP/MTR are covered in detail in
this Validation Manual. The validation planning of the customer is also explained and the interface to QPP
is dealt with in particular.

4.1 Validation planning of the customer

See also GAMP 5 Appendix M1.
Depending on the size, complexity and duration of a project, validation planning is often spread over several
documents.
 Validation principles
 Validation master plan
 Validation plan
The foundation is laid down in the validation principles of the regulated company (often also referred to as
the "validation policy"). This defines the general procedure of the company or at the respective location,
e.g. processes, documents, standards, roles and responsibilities.
The validation master plan (VMP) can be used as an overview document for a specific period, a defined
plant area or more complex projects. The VMP typically describes the scope of its application, the current
status of the equipment, the change process to be followed and the temporal and organizational planning.
Often, several validation plans for different trades, subsystems and/or time sections are secondary to the
VMP.
In the validation plan (VP), the higher-level specifications of the VMP are broken down into the specific
application area. Depending on the number of systems, plant components or plants involved, the
specifications for the validation of the individual systems are distributed over one or more validation plans.
The VP is usually opposed to a validation report at the end of the project. The validation report documents
the completion of activities, the determination of adherence to acceptance criteria as well as any deviations
and their evaluation. Therefore, it becomes a formal declaration of the successful completion of the project
and the compliance of the overall system.

4.2 Quality and Project Plan (QPP) of the supplier

See also GAMP 5 Appendix M6.
The Quality and Project Plan summarizes the quality and other requirements of the customer and describes
how these requirements are met by the supplier.
The project planning part contains organizational aspects (including the appointment of key persons,
organization charts), the interfaces between all project participants (customer, supplier and possibly other
suppliers), project results and activities.
One of the most important components of the QPP is the definition of a specific development lifecycle to
be applied in the respective project.
With the QPP as well, it is important to ensure that all presentations and contents are carefully checked
and adapted to the specific requirements of the respective project.
Due to the scope of the QPP, it often takes on the significance of a contractual document. Accordingly, the
document should be approved by both the supplier and the customer.

 Template for a Quality and Project Plan (QPP), see  GMP-VM-QPP-001

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 17 of 35

4.3 Good documentation practice

See also GAMP 5 Appendix M9.
The binding criteria for project documentation must be defined at the start of the project. This basically
includes:
 Guidelines for creation of documents
 Handling of documents (including storage)
 Handing of changes to documents
All documents created during the project are created and managed in accordance with these specifications.
The project manager or a representative must ensure compliance with good documentation practice
throughout the project. This person is responsible for the document management specifications and their
application in the project. These specifications are often stored in an SOP (standard operating procedure)
and must be made known to all project employees.
The following must be observed when creating and handling documents:
 Description of the purpose of the document
 Glossary (either in the document or by reference to another place)
 Uniform layout, e.g. defined using a document template
 Document number and version according to SOP Document Management
 Responsibilities according to QPP (Quality and Project Plan)
 Format and storage (master) of documents according to SOP Document Management
 Maintain document list
 Document handover to the customer with transmittals (handover protocol) according to SOP
Document Management

 Template for SOP Document Management, see  GMP-VM-SOP-001

 Template for a basic document template (Word), see  GMP-VM-SOP-005

 Template for a basic document template (Excel), see  GMP-VM-SOP-006

 Template for a document list, see  GMP-VM-LST-001

 Template for transmittal, see  GMP-VM-LST-002

 Template for a Glossary, see  GMP-VM-LST-005

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 18 of 35

4.4 Risk assessment

See also GAMP 5 Appendix M3.
A risk-based analysis of systems and processes is obligatory in the GMP-regulated environment and is
queried during inspections.
Risk assessment deals with GMP risks:
 Patient safety
 Product quality and
 Data integrity
Technical risks, e.g. in manufacturing process, reporting or data archiving, are regarded as a potential
source of danger if they influence the evaluation criteria mentioned above. It therefore makes sense for the
regulated company to involve the system supplier in the risk assessment.
However, the supplier should not perform the risk analysis alone, because the supplier does not know the
manufacturing processes of the customer in detail, but this information is necessary for the risk assessment.
A frequently used method is the FMEA method (Failure Mode and Effects Analysis) with the three
evaluation criteria: probability of occurrence, extent of damage, and probability of detection. This method
can be more complex or reduced to a high/medium/low risk assessment.
The result of the risk assessment can have an impact on user requirements, alternative design solutions
and/or additional validation activities (risk-based testing).

Figure 5: Example for a risk analysis

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 19 of 35

4.5 Master test plan and master test report

See also GAMP 5 Appendix D5.
The relevant requirements must be appropriately tested from a regulatory perspective and to ensure
functionality. The corresponding test phases are defined in the master test plan (MTP). The results of the
risk assessment also have an influence on the scope of the test topics and the test methods.
All relevant requirements must be tested in at least one of the specified test phases. A traceability matrix
and/or embedded traceability supports you in tracking the requirements to be tested and the tests to be
performed.

4.5.1 Master test plan

While the QPP is more of a project management and quality assurance document, the MTP describes the
organization of the test phases:
 Definition of the relevant test phases
 Relationships between the test phases
 Description of the general test procedure that is used for each test phase, whereby all test
documents of a phase and their relationship to each other are explained exemplarily
 Definition of the test scope according to a risk assessment
 Classification of test topics, plant components, etc. and their assignment to the test phases
(FAT, SAT, etc.)
 Description of test strategy/test methods
 Definition of which tests are observed and countersigned by a customer representative
 Description of the procedure for test incidents (deviations from the acceptance criterion)
It is possible to combine the MTP with the QPP in one document, but this should not delay the completion
of the QPP. The MTP should be created in parallel with the specification phase at the latest.

 Template for a master test plan, see  GMP-VM-VER-001

4.5.2 Master test report

After the tests of all test phases have been performed according to their specifications and the individual
test results have been evaluated without critical deviations (test incidents), the completion of the test phases
is documented. The master test report (MTR) is created in response to the master test plan and summarizes
the test results of all test phases like FAT, SAT, etc. Nevertheless, after the last test phase, there may still
be uncritical deviations in the list of open points, which must be corrected afterwards.

 Template for a master test report, see  GMP-VM-VER-009

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 20 of 35

5 Specifications
The division of the specifications, typically into three to four levels, is made based on the following factors
in the GAMP 5 Guide:
 Criticality
 Complexity
 Novelty of the system or the products used (see also chapter 3.1 Lifecycle)
Temporal processing of the individual parts can also influence the structure of the documents.
The following representation of the classical specification structure in three levels does not contradict the
scalability of the lifecycle model. Where necessary, documents can be combined or split based on the
templates belonging to the validation manual.

Figure 6: Specification levels

5.1 User requirements specification (URS)

See also GAMP 5 Appendix D1.
The user requirements specification (URS) is a customer document describing the customer's requirements
in order to define what the system should do. The URS is system-neutral and forms the basis for the
functional specification (FS).
The URS should cover the following topics:
 Overview: Describes the purpose, scope and interfaces of the intended system, possibly in connection
with the current status.
 Operational requirements: Description of the business process needs.
 Technical requirements: Overview of technical, functional, process and system requirements, such
as hardware concept, software packages, operating concept, monitoring and control equipment,
software and batch structure.
 General requirements: Describes the general requirements for the intended system, such as scope
of delivery, environmental conditions, regulatory requirements, availability and modularity, and also the
customer's validation requirements.
The user requirements specification must be clear and comprehensible for both the customer and the
system supplier. Ideally, the individual requirements are numbered consecutively so that they can be
referenced and tested individually.

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 21 of 35

5.2 Functional specification (FS)

See also GAMP 5 Appendix D2.
The functional specification (FS) describes how the requirements and goals documented in the URS are
implemented. It defines the system, the components and functions used, and it shows possible solutions.
However, it does not contain detailed solutions for implementation. It is often helpful to explain hardware
and software structures using block diagrams.
Since the functional specification is an agreement between customers and system suppliers, it should be
clearly formulated and prevent misunderstandings.
The FS is created by the system supplier and reviewed by the customer. Once FS has been approved by
the customer, it serves as the basis for the next specification phase (DS), which describes the technical
implementation of the requirements in detail.
The FS should cover the following topics:
 Overview: Describes the scope of the planned system, identifies interfaces to other systems and
indicates any deviations from the URS.
 System description: Overview of the hardware components and software products for the system.
 Functional description: Description of the software that must be generated for the intended system,
e.g. software structure, functions and modules.
 HMI and interfaces: Describe the user interface (Human Machine Interface, HMI), e.g. graphics, user
administration, events and messages as well as the interfaces with the equipment or other systems.
 General requirements: Describes the general requirements for the planned system such as
performance targets, restrictions and handling of emergency states.
GxP guidelines and quality aspects are defined in the Quality and Project Plan and should not be part of
the functional specification.

 Template for a functional specification (FS), see  GMP-VM-SPC-002

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 22 of 35

5.3 Configuration and design (CS/DS)

See also GAMP 5 Appendix D3.
In this specification phase, the system supplier describes detailed solutions to implement the functionalities
described in the FS. The CS/DS is to be understood here as a specification phase, which usually consists
of several documents for configuring and programming the system. It can also be helpful in the CS/DS to
explain hardware and software structures using block diagrams. The system supplier should be able to set
up the system on the basis of the CS/DS. Furthermore, the CS/DS is the basis for the tests to be performed.
Once the project is completed, the specification documents of the CS/DS as well as the functional
specification and other documents remain with the customer, as they reflect the overall system and are
required for maintenance and repair purposes and for future extensions of the system.
The DS should cover the following topics:
 System layout: Describes the layout of the intended system according to the "System description"
chapter in the function specification.
 Reference to other documents: This chapter refers to other important/additionally applicable
documents such as a list of measuring points, a list of parameters, etc.
 User interface (HMI): Describes the user interface, e.g. faceplates, operating modes and operating
diagrams, etc.
 Event and archiving management: Describe how event and archiving management must be
implemented. This section defines which message lists are generated and how they are visualized. It
contains instructions for archiving messages, process values and operator actions.
 Hardware design: This describes the computer hardware of the entire system and its implementation.
 Software design: The structure of the overall system and its functionality are described in detail.
 Software modules: The software modules to be created (also called types, classes or typicals) are
described in detail.
 Detailed user structure and access rights: This specification describes the setup of user groups and
their access rights for the system.
 Definition of interfaces: All interfaces of the system are defined here.
Where the functional specification describes technical specifications in sufficient detail, they should be
referenced in the CS/DS instead of being repeated.

 Template for a configuration and design specification (CS/DS), see  GMP-VM-SPC-003

 Template for a hardware design specification (HDS), see  GMP-VM-SPC-004

 Template for a software design specification (SDS), see  GMP-VM-SPC-005

 Template for a DS User Management, see  GMP-VM-SPC-006

Template for a DS User Rights Matrix Opcenter Execution Pharma,

 see  GMP-VM-SPC-007

 Template for a DS User Rights Matrix SIMATIC Batch, see  GMP-VM-SPC-008

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 23 of 35

5.4 Design review and traceability

See also GAMP 5 Appendix M5.
The design review is used to review specifications and the development of the system. The objective is the
early detection of problems that would otherwise lead to changes later on.
Traceability ensures that all requirements are considered throughout the specifications and their
implementation up to the corresponding test cases.
Together, design review and traceability help ensure that
 All requirements are taken into account
 The functionality is suitable and consistent
 If changes are made, the documents and tests affected can be identified
 The system as a whole has been tested appropriately

There are two methods to ensure traceability according to the GAMP 5 Guide:
1. Comprehensive traceability matrix
It can cover the traceability of the entire project documentation, the overhead for maintenance and
care is high, its handling is highly dependent on software tools (e.g. databases, etc.) as well as on
the level of detail of the individual requirements.
2. Embedded traceability
In simple systems or modular systems (such as DCS with batch control strategy according to
ISA 88), traceability can be guaranteed by consistent numbering of the documents involved or other
identical structures.
The form in which the requirements are monitored during a project should be described within the
framework of the QPP.

 Template for a Traceability Matrix (TRM), see  GMP-VM-LST-003

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 24 of 35

6 System configuration/coding
The structure of the computer system is based on specifications on the one hand, and on repeatable
practices and any defined standards (e.g. coding standards) on the other.
Due to the modular structure of modern IT systems, the GAMP 5 Guide differentiates between coding and
configuration. Figure 7 shows the mandatory chronological sequence of steps for modular systems: encode
modules, test modules and configure applications.
Early testing of the software modules and their subsequent use as "types" or "templates" form the basis for
efficient validation.

Figure 7: Configuration / coding of a system

6.1 Coding standards / good engineering practice

See also GAMP 5 Appendix D4.
Some procedures must be standardized (unified) in order to obtain understandable software and to ensure
that the system meets all specified requirements. These should be summarized in a separate SOP. For
example, the SOP should contain:
 Project-specific naming of configuration elements such as tags and variables
 Software development
 Granularity of the software; division of the configuration into manageable elements
 Appropriate commenting of the software
 Handling of different software module versions in different controllers
 Multi-user engineering
 Definition of the "master project" and the way in which the individual parts are assembled
 Ensure that the same standard software releases/versions (created xx/yy etc.) are used on all
workstations

 Template for an SOP Coding Standards, see  GMP-VM-SOP-004

 GMP Engineering Manual for various SIMATIC products, see chapter 8.2

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 25 of 35

6.2 Change and configuration management

See also GAMP 5 Appendix M8.
This SOP describes how the elements of a computer system are controlled. The exact configuration of the
system, hardware, and software must be documented over the entire lifecycle of a system. This
documentation must be kept up-to-date and available.
Configuration management starts at an early stage of project development, for example by defining the
configuration elements and their naming conventions and continues with version control of the various
system components.
A procedure (change control) must be defined according to which changes made to elements already
approved (documentation, hardware, software, etc.) are introduced. Such a procedure can either be
described within the QPP or in a separate SOP for each project, or it can be covered in the corresponding
quality management system of the supplier. In any case, the QPP should define the procedure to be used
during the project.
Configuration management is closely related to this change control procedure. If changes are proposed,
activities in both change control and configuration management must be considered at the same time.
The use of change and configuration management means
 Splitting the system into defined configuration elements
 Controlling the development and changes to these elements
 Controlled storage/delivery of individual elements or the entire system
 Documentation of the current system status

 Template for an SOP Change and Configuration Management, see  GMP-VM-SOP-002

 Template for a Change Request / Change Note, see  GMP-VM-TPL-001

 Template for a List of change requests, see  GMP-VM-LST-004

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 26 of 35

7 Tests and test documents

In order to cope with the modular character of IT and automation systems, early planning of the test phases
is indispensable. Modules/classes developed in the project are tested in the module test before they are
instantiated for the first time. Tests of the instances based on this then only include the instance-specific
properties; class-typical properties are not repeatedly tested.

Figure 8: Test phases in the framework development lifecycle model used here

The integration of the GAMP 5 test levels into the test phases of a project is described below.

7.1 Test levels according to GAMP 5

Depending on the complexity and software category of the system, GAMP 5 Guide explains the following
test levels in its chapter 4.2.6, and corresponding typical test activities in appendix D5, chapter 9.
 Module testing
Testing of individual customer-specific modules/applications
 Integration testing
Integration of the individual modules or system components into the overall system network
 Configuration testing
Verification of the correct system configuration according to specifications
 Functional testing
Proof of the correct functioning of a functionality related to the specific operating process within
the specified limits
 Requirement testing
Verification that a system is suitable for the intended purpose and basis for acceptance of the
system according to specified user requirements

7.2 Test phases in the project

The FAT (Factory Acceptance Test) and SAT (Site Acceptance Test) test phases are widely used.
Reusable modules are often tested in a software module test before the FAT.
The FAT usually takes place at the supplier's location, while SAT determines that the system has been
delivered and installed in the operating environment in accordance with the contract.
The following applies, in general: Testing is performed as early as possible and as late as necessary.
The terms IQ (Installation Qualification), OQ (Operational Qualification) and PQ (Performance Qualification)
are used by regulated companies primarily for plant qualification.
The test levels cited above according to GAMP 5 are often covered in the project in the following test
phases.

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 27 of 35

7.2.1 Software Module Test (SMT)

The effectiveness and quality of software modules are extensively tested in the software module test (SMT).
The aim of the test is to enable the use of software modules in the form of pre-configured, tested software
modules. Following a successful module test, the software module is ready for use in the application
(software).
The tested modules are usually the basis for their repeated use in a project. In these cases, the SMT is
strongly recommended as a preliminary test. For efficient instantiation or copying of the software modules,
their description and detailed testing is very important and must not be underestimated.
Examples of modules are
 Valves, drives, controllers, analog values, frequency converters and their parameter
assignment/configuration, etc.
 Technical functions such as SFC types (heating, weighing, measuring and dosing, etc.)
The SMT is described by the system supplier in a test plan and associated test specifications. The customer
should approve the two planning documents before testing and the test protocol after testing. Ideally, the
customer should be present as an observer/witness during the test to confirm the desired functionality.

7.2.2 Factory Acceptance Test (FAT)

The Factory Acceptance Test (FAT) is performed at the system supplier's site after completion of the system
implementation. At the end of the FAT, the customer should agree to the delivery of the system. An
additional advantage of a detailed FAT is that possible errors in the software programming can be detected
and eliminated at an early stage before the system is installed at the customer's site. This enables faster
commissioning. The FAT should be performed as far as possible with the original system and can be
supported by simulated processes and test programs.
During the test, the customer should be present as an observer/witness. By approving the FAT report, the
customer accepts the software development and gives consent for the delivery/installation of the system at
the production site.
The FAT covers as many test contents as possible, according to the mentioned test levels:
 Configuration testing against the configuration specification
 Integration testing, as far as possible and reasonable in test environment
 Functional testing against the function specification
 Requirement testing, as far as possible and reasonable in a test environment

7.2.3 Site Acceptance Test (SAT)

In contrast to the FAT, the Site Acceptance Test (SAT) takes place on-site, i.e. at the installation site at the
customer's location.
The SAT covers the remaining test scenarios, so that the basis for commissioning is created with completed
FAT and SAT.
 Test of correct and complete delivery
 Installation and integration into the plant network including interfaces
 Other FAT tests that were not possible or need to be repeated

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 28 of 35

7.3 Test methods

See also GAMP 5 Appendix D5 Chapter 4.3.
When testing a computer system, an essential distinction is made between:
 Structural test methods (also called white box test or code review)
 Functional test methods (also known as black box tests)
Structural testing
The structural test method tests the internal operation of the programs. Structural tests are preferably
performed during development in module and application development as well as in the early phases of
acceptance testing. Preferably, they are performed at the system supplier's location, since testing and
development tools can be optimally used there.
Functional testing
The objective of the functional test is to test the system functions according to the specifications of the URS
and the FS. It is performed during the development, acceptance testing and later validation phases.
Functional tests may include:
 Positive tests (testing the normal case)
 Negative tests (testing the invalidity case)
 Tests of defined business processes

Depending on the complexity, novelty and risk of the system or individual system parts, the following test
types are also used:
 Repeatability test
 Performance test
 Volume/Load test
 Regression test
 Structure/path test
The test methods and test types are described in more detail in the GAMP 5 Guide Appendix D5 and in
the GAMP Good Practice Guide "Testing of GxP Systems".

7.4 Determining the time sequence of tests

As already explained in chapter 7.1, the GAMP 5 Guide defines the criteria according to which test phases
are to be structured, but it leaves open the possibility to deviate from them when justified. Reasons for such
a deviation can be, for example, early tests of characteristics for which error correction would cause higher
costs at a later point in time. In practice, this often applies to types or classes that are later used as
templates by multiple instantiations.
Another factor in determining when a characteristic is to be tested can be the required test strategy or test
method. For example, for a module of software category 3, verification of the adaptation, combined with a
function test if necessary, is often applied. For a module of software category 5, on the other hand, a
detailed function test and, if necessary, a code review will be added. Chapter 4.5.1 shows a test planning
method that already takes this into account.

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 29 of 35

7.5 Structure of the test documentation

See also GAMP 5 Appendix D5 Chapter 4.1.
This test procedure describes the test methods recommended for testing computer systems. The purpose
of testing is to find and eliminate software and system errors and ensure that the system meets
specifications and quality requirements based on documented evidence.

Figure 9: Overview of the test documentation

7.5.1 Test plan / test scope list

This is a separate planning document for each test phase, e.g. FAT. These test phases are defined in the
Quality and Project Plan (QPP) or Master Test Plan (MTP) of the project.
Test planning contains:
 Test plan with details about organizational topics and the test environment
 A detailed list of tests (test scope list) to be performed based on the specification documents,
including progress check of the test execution and the results
The test scope list gives an overview of all test objects, the required design specifications and the test
specifications to be applied. Entries of the test results complement the list. Test report and test scope list
together form the summary of the executed test phase.

 Template for a test plan, see  GMP-VM-VER-002

 Template for a test scope list, see  GMP-VM-VER-007

7.5.2 Test specifications / test protocols / test result sheets

Each test specification (i.e. several test specifications per test phase) contains:
 Test object
 Test preparation and requirements
 Detailed test instruction
 Acceptance criteria for each test point
 Scope of documentation (attachments)
Before performing the tests, all testers sign a signature list and receive instructions on how to perform and
document the tests in accordance with SOP Test Execution.

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 30 of 35

Test execution and test results are documented in the test result sheets.
In case of test incidents (deviations from the expected test result), these are entered into the test incident
list and a test incident sheet is created.
After evaluation and correction of the test incident, the relevant test point(s) must be repeated and
documented accordingly. If you use the same test result sheet as template for re-testing, mark all other
sections of the document as “already tested successfully”.
In most cases, some raw data, such as copies of approved specifications (DS or FS) documenting the test
steps performed, are added to the test result sheet as attachments.
All test results including the test incidents are entered in the test scope list.
Test specification and test result sheet can also be combined in one document. Some call this test protocol.

 Template for a test specification, see  GMP-VM-VER-003

 Template for a test result sheet, see  GMP-VM-VER-004

 Template for an SOP Test Execution, see  GMP-VM-SOP-003

7.5.3 Test incident list / test incident sheet

To every test phase a list of all test incidents (deviations from the acceptance criterion) is managed.
When an acceptance criterion is not met, the tester enters this in the test incident list.
In detail the test incident list should contain the following information:
 Unique number of the test incident
 Date when the test incident occurred
 Name of the tester
 Reference to the test document / test point, where the test incident occurred
 Description of the test incident (what was the deviation from the acceptance criterion?)
Afterwards, a technical reviewer evaluates the test incident and creates a test incident sheet. He defines
the necessary correction measures.
The test incident list is filled with additional information:
 Reference to the test incident sheet, where the test incident will be followed-up
 Classification of the test incident in category A, B, or C
 Status tracking of the test incident (open, closed, etc.)
 Date after the test incident has been completely done and closed
Completion of the correction of a test incident is confirmed by signature of the responsible person and
approved by the customer.
At the end of a test phase the test incident list is added to the test report as appendix.

 Template for a test incident list, see  GMP-VM-VER-006

 Template for a test incident sheet, see  GMP-VM-VER-005

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 31 of 35

7.5.4 Test report

A test report is generated for each test phase, summarizing the test results of this test phase and formally
approving the tests performed. This report should include:
 Summary of the test results of the test phase under consideration
 Overview of all test incidents (observations, deviations from acceptance criteria)
 Final evaluation of whether this test phase is considered to be completed, so that the next test
phase can begin
With the test report also the test scope list is finalized, including all executed tests according to the test
planning.

 Template for a test report, see  GMP-VM-VER-008

 Template for a test scope list, see  GMP-VM-VER-007

After completion of all tests and test reports, the final report on all test phases is made in the master test
report (see chapter 4.5).

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 32 of 35

8 Validation Manual and related documents

In addition to this Validation Manual, Siemens provides other documents and materials relevant to projects
in general and in the regulated environment.

Figure 10: Embedding the Validation Manual in the document landscape

8.1 Technical documentation and Online Support

The technical documentation describes the system functionalities in general, e.g. for PCS 7:
 https://support.industry.siemens.com/cs/ww/en/view/59538371
Extensive information, FAQs and application examples are available at:
 http://support.industry.siemens.com
For example, the Engineering Compendium for PCS 7 can also be found there in several parts with specific
configuration recommendations.

8.2 GMP Engineering Manual

The GMP Engineering Manuals for PCS 7 and other SIMATIC products describe the functionalities and
settings of the respective systems that support configuration in a GMP environment.
The manuals are intended for
 Planners and engineers for configuration
 Service and maintenance personnel
in a GMP-regulated environment.
In order to make optimum use of the GMP Engineering Manuals, the reader should be familiar with the
basics of the respective system. Experience with GMP in the pharmaceutical industry is also an advantage.

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 33 of 35

The GMP Engineering Manuals are available at:

 http://intranet.siemens.com/gmp (Intranet)
 http://www.siemens.com/gmp (Internet)

8.3 ERES Compliance Responses

Regulatory authorities have established criteria for electronic records and electronic signatures (ERES). In
Europe, these requirements are anchored in Annex 11 of the EU GMP Guide, in the USA this is 21 CFR
Part 11 of the Food and Drug Administration (FDA).
Siemens has evaluated its products regarding these requirements and documented the answers in the
ERES Compliance Responses.
The ERES Compliance Responses are available at:
 http://intranet.siemens.com/gmp (Intranet)
 http://www.siemens.com/gmp (Internet)

8.4 Siemens GMP training material

Training materials are available on the following topics, among others:
 Pharmaceutical Industry - Background and special requirements
 The pharmaceutical development process
 Siemens in Pharmaceuticals
 GMP regulations for computer systems
 Validation in projects
These documents are also available at:
 http://intranet.siemens.com/gmp
The VM Pharma also regularly conducts GMP training courses.

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 34 of 35

9 Glossary and abbreviations

Term Explanation
Customer Name for the customer for whom the solution provider/system supplier works,
usually the pharmaceutical manufacturer
EMA European Medicines Agency, European authority
www.ema.europa.eu
FDA Food and Drug Administration, US authority
www.fda.gov
GMP Good Manufacturing Practice
MTP Master Test Plan
MTR Master Test Report
Pharmaceutical Manufacturer of a so-called finished pharmaceutical product or the
manufacturer and manufacturer of an active ingredient used in a drug.
manufacturer of active
ingredients
QPP Quality and Project Plan
Solution Partner Third level of the Siemens Partner Program
Industry Pharma Solution Partner -> Expert -> Industry Partner
https://extranet.w3.siemens.com/industry/partner/en/solutionpartner/programm-
module/Pages/Default.aspx
SOP Standard Operating Procedure
URS User Requirements Specification
WHO World Health Organization
www.who.int

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx
 Document No. Version Date

GMP-VM-GEN-001 V03.04 20 Oct 2021

Title Page

Validation Manual 35 of 35

10 List of Literature
[1] GAMP 5 - A Risk-Based Approach to Compliant GxP Computerized Systems, ISPE, 2008
The guideline contains recommendations on how to proceed in the development, validation and
operation of computerized systems.
[2] 21 CFR Part 11 – Electronic Records, Electronic Signatures, FDA, 1997
A US government law on the use of electronic records and electronic signatures instead of
paper records and handwritten signatures.
[3] EU GMP Guide Annex 11 Computerised Systems, European Commission, 2011
The EU GMP Guide is a binding guideline for the EU states for implementation in national law.
Annex 11 describes the handling of computerised systems.

Project / Location Siemens Validation Manual / Global Restricted

Alternative Doc. No. - GMP-VM-GEN-001_V0304_en_ValidationManual.docx