Compliance Response - Siemens · PDF fileSIMATIC PCS 7 V8.1 – Compliance Response ERES 2 A5E35829023-AA Table of Contents Introduction

SIMATIC PCS 7 V8.1 – Compliance Response ERESA5E35829023-AA 1

Compliance Response

Electronic Records / Electronic Signatures (ERES)

for SIMATIC PCS 7 V8.1

SIEMENS AG

Industry Sector

VSS Pharma

D-76187 Karlsruhe, Germany

E-Mail: [email protected]

March 2015

SIMATIC PCS 7 V8.1 – Compliance Response ERES2 A5E35829023-AA

Table of Contents

Introduction ............................................................................................................................................ 3

1 The Requirements in Short .......................................................................................................... 4

2 Meeting the Requirements with SIMATIC PCS 7 ....................................................................... 6

2.1 Life Cycle and Validation of Computerized Systems ............................................................. 6

2.2 Suppliers and Service Providers ............................................................................................ 6

2.3 Data Integrity .......................................................................................................................... 7

2.4 Audit Trail, Change Control Support ...................................................................................... 8

2.5 System Access, Identification Codes and Passwords ......................................................... 10

2.6 Electronic Signature ............................................................................................................. 12

3 Evaluation List for SIMATIC PCS 7 ........................................................................................... 14

3.1 Life Cycle and Validation of Computerized Systems ........................................................... 14

3.2 Suppliers and Service Providers .......................................................................................... 16

3.3 Data Integrity ........................................................................................................................ 17

3.4 Audit Trail, Change Control Support .................................................................................... 18

3.5 System Access, Identification Codes and Passwords ......................................................... 19

3.6 Electronic Signature ............................................................................................................. 21

3.7 Open Systems ...................................................................................................................... 22

Introduction


Introduction

Life science industries are increasingly basing key decisions on regulated records that are beinggenerated, processed and kept electronically. Further than that reviews and approval of such data arealso being provided electronically. Thus the appropriate management of electronic records andelectronic signatures has become an important topic for the life science industries.

Accordingly regulatory bodies defined criteria under which electronic records and electronic signatureswill be considered being as reliable and as trustworthy as paper records and handwritten signaturesexecuted on paper. These requirements have been set forth by the US FDA in 21 CFR Part 111 (inshort: Part 11) and by the European Commission in Annex 11 to chapter 4 of the EU GMP Guideline2

(in short: Annex 11).Since requirements on electronic records and electronic signatures are always tied to a computerizedsystem being in a validated state, both regulations also include stipulations on validation and life-cycleof the computerized system.

Application of Part 11 and Annex 11 (or their corresponding implementation in national legislation) ismandatory for the use of electronic records and electronic signatures. However, these regulations areonly valid within their defined scope.The scope of both regulations is defined by the regional market the finished pharmaceutical is distrib-uted to, and by whether or not the computerized systems and electronic records are used as a part ofGMP-regulated activities (see Part 11.11 and Annex 11 Principle2).

Supplemental to the regulations a number of guidance documents, good practice guides and interpre-tations have been published in recent years to support the implementation of the regulations. Some ofthem are being referred to within this document.

To help its clients, Siemens as supplier of SIMATIC PCS 7 evaluated version 8.1 of the system withregard to these requirements and published its results in this Compliance Response. Due to its level ofdetail, this analysis is based on the regulations and guidelines mentioned above.

SIMATIC PCS 7 V8.1 fully meets the functional requirements for the use of electronic recordsand electronic signatures.

Operation in conformity with the regulations is ensured in conjunction with organizational measuresand procedural controls to be established by the client (the regulated company). Such measures andcontrols are mentioned in chapter 3 of this document.

This document is divided into three parts: chapter 1 provides a brief description of the requirementclusters, while chapter 2 introduces the functionality of SIMATIC PCS 7 V8.1 as means to meet thoserequirements. Chapter 3 contains a detailed system assessment on the basis of the single require-ments of the according regulations.

1 21 CFR Part 11 Electronic Records; Electronic Signatures, US FDA, March 20th 19972 EU Guidelines to Good Manufacturing Practice, Volume 4, Annex 11: Computerised Systems, European Commission,

June 30th 2011

The Requirements in Short


1 The Requirements in Short

Annex 11 and Part 11 take into account that the risk of manipulation, misinterpretation and changeswithout leaving a visible trace is higher with electronic records and electronic signatures, than withconventional paper records and handwritten signatures. Furthermore the means to restrict access toelectronic records to authorized individuals are very different to those required to restrict access topaper records. Additional measures are required for such reasons.

The terms “electronic record” / “electronic document” mean any combination of text, graphics, data,audio, pictorial or other information representation in digital form, that is created, modified, maintained,archived, retrieved or distributed by a computer system.

The term “electronic signature” means a computer data compilation of any symbol or series of symbolsexecuted, adopted, or authorized by an individual to be the legally binding equivalent of the individu-al’s handwritten signature. Since electronic signatures are also considered being electronic records bythemselves, all requirements on electronic records are applied to electronic signatures too.

The following table provides an overview of the requirements from both regulations.

Requirement Description

Life Cycle and Validation ofComputerized Systems

Computerized systems used as a part of GMP-related activities must bevalidated. The validation process should be defined using a risk-based ap-proach. It should cover all relevant steps of the lifecycle and must provideappropriate documented evidence.The system’s functionality should be traceable throughout the lifecycle bybeing documented in specifications or a system description.A formal change control procedure as well as an incident managementshould be established. Periodic evaluation should confirm that the validatedstate of the system is being maintained.

Suppliers and Service Providers Since competency and reliability of suppliers and service providers are con-sidered as key factors, the supplier assessment should be chosen using arisk-based approach. Formal agreements should exist between the regulateduser and these 3rd parties, including clear responsibilities of the 3rd party.

Data Integrity Under the requirements of both regulations electronic records and electronicsignatures must be as reliable and trustworthy as paper records.The system must provide the ability to discern altered records. Built-in checksfor the correct and secure handling of data should be provided for manuallyentered data as well as for data being electronically exchanged with othersystems.The system’s ability to generate accurate and complete copies is essentialfor the use of the electronic records for regulated purposes, as well as theaccessibility, readability, and integrity of archived data throughout the reten-tion period.

Audit Trail, Change ControlSupport

Besides recording changes to the system as defined in the lifecycle, bothregulations require that changes on GMP-relevant data are being recorded.Such an audit trail should include information on the change (before / afterdata), the identity of the operator, a time stamp, as well as the reason for thechange.

The Requirements in Short


Requirement Description

System Access, IdentificationCodes and Passwords

Access to the system must be limited to authorized individuals. Attentionshould be paid to password security. Changes on the configuration of useraccess management should be recorded.Periodic reviews should ensure the validity of identification codes. Proce-dures should exist for recalling access rights if a person leaves and for lossmanagement.Special consideration should be given to the use of devices that bear orgenerate identification code or password information.

Electronic Signature Regulations consider electronic signatures being legally binding and general-ly equivalent to handwritten signatures executed on paper.Beyond requirements on identification codes and passwords as statedabove, electronic signatures must be unique to an individual. They must belinked to their respective electronic record and not be copied or otherwisebeing altered.

Open Systems Open systems might require additional controls or measures to ensure dataintegrity and confidentiality.

Meeting the Requirements with SIMATIC PCS 7


2 Meeting the Requirements with SIMATICPCS 7

The Siemens recommendations for the system architecture, conception, and configuration will assistsystem users in achieving compliance. For additional information and assistance see“GMP Engineering Manual SIMATIC PCS 7“ from Siemens.

The requirements explained in chapter 1 can be supported by the system as follows.

2.1 Life Cycle and Validation of Computerized SystemsAlthough Annex 11 in 1992 and Part 11 in 1997 underlined that a computerized system should besubject to validation, it was not until the 2011 revision of Annex 11, that a comprehensive set of criteriafor the validation of the system and its life-cycle had been introduced.

Nonetheless the requirements to validate a computerized system and to keep it in a validated statehad long been a part of regulations other than Part 11 and Annex 11. This was the motivation for theISPE3 to publish practical guidance like the Baseline Guides4, the GAMP 55 guide as well as theGAMP Good Practice Guides.

Thus the systems life-cycle as well as the approach to validation should be defined considering theguidance from the GAMP 5 guide. The guide also includes a number of appendices for life-cycle man-agement, system development and operation of computerized systems.Since most pharmaceutical companies already have a validation methodology for computerized sys-tems as a part of their process landscape, it is preferable to setup the systems life-cycle and validationaccording to these.

2.2 Suppliers and Service ProvidersSuppliers of systems, solutions and services must be evaluated accordingly, see GAMP 5 AppendixM2. SIEMENS as a manufacturer of SIMATIC hardware and software components follows internalprocedures of Product Lifecycle Management and Quality Management System, which is regularlyreviewed and certified by an external certification company.

3 ISPE; International Society of Pharmaceutical Engineers, http://www.ispe.org4 Baseline® Pharmaceutical Engineering Guides for New and Renovated Facilities, Volume 1-7, ISPE5 GAMP 5 – A Risk-Based Approach to Compliant GxP Computerized Systems, ISPE, 2008



2.3 Data IntegrityData integrity is assured in the system by measures like access security, audit trail, data type checks,checksums, backup/restore, and archiving/retrieval, completed by system validation, appropriate pro-cedures and training for personnel.

Continuous archivingSIMATIC PCS 7 provides a configurable and scalable archiving concept. Messages and measuredvalues are stored continuously to local PCS 7 archives. These locally stored data can be transferredautomatically to long-term archives. Generation of checksums detects any manipulation of thearchived data. Archived data can be retrieved within the entire, configured retention period. Data canbe retrieved within SIMATIC PCS 7 using either standard functions, or additional standard interfaces,or optional packages. For further information see PCS 7 OS engineering manual.

Figure 1: Archive configuration

Batch-oriented archivingBatch-oriented data archiving can be performed with SIMATIC BATCH. The data can be managed forlong-term archiving using the tools mentioned above.

SIMATIC PCS 7 and SIMATIC BATCH offer standard interfaces to other archiving tools (from Siemensand third-party manufacturers). For further information see SIMATIC BATCH Configuration Manual.



2.4 Audit Trail, Change Control Support“Audit trails are of particular importance in areas where operator actions generate, modify, or deletedata in the course of normal operation.” (Guidance for Industry Part 11 – Scope and Application, FDA,2003)

An audit trail is not required for automatically generated electronic records which can neither be modi-fied, nor be deleted by the operator. SIMATIC PCS 7 provides adequate system security for such elec-tronic records (e.g. access control).

The following section describes how the SIMATIC PCS 7 system supports the implementation of re-quirements with regard to the audit trails during runtime operation. Moreover, it also informs about thesystem support for tracing changes made in the engineering system.

Audit trail during runtime operationRecording batch data

All batch-relevant records are documented in a batch report, including operator actions and electronicsignatures.

The batch reports can be saved in XML or PDF file format. SIMATIC PCS 7 and SIMATIC BATCH donot provide any option for the operator to change this data. Direct manipulation of these files must beprevented using the security settings of the operating system. If these files are nevertheless changed,the manipulation is detected and is shown by a message when the batch report is opened.

Recording of process data

Process data (e.g. process values, process or operating messages) are stored without any way for theoperator to change this data.

Changes during runtime

All changes and inputs of relevant data entered by the operator during operation must be recorded inan audit trail.

Therefore, operator actions and events are stored in message archives containing information like oldvalue, new value, user ID, date and time stamp, operation, batch name, etc. This audit trail can alsobe printed.

Figure 2: Display of the audit trail by means of Alarm Logging

Configuration phaseChanges in batch system

SIMATIC BATCH supports versioning of recipes, formulas and ROP library objects. The person ofcreation is recorded, as well as the one editing and releasing the recipe.

Changes in engineering system

Detailed structural comparisons can be performed using the option SIMATIC Version Cross Manager(VXM). Structural comparisons can be made for:

Projects (no multiprojects) including the hardware configuration between the current project and anarchived project or between two archived projects



Changed project data and the data loaded in the AS (online – offline comparison)

Synchronized SFC types (sequential function chart) via the project

Figure 3: Visualization of a comparison in SIMATIC Version Cross Manager

These comparison results are saved in CSV file format and can be printed as a report. The report liststhe changes organized according to categories.

Figure 4: Excerpt from a comparison report of SIMATIC Version Cross Manager



Changes to installed SIMATIC PCS 7 system software

A full log file of the installation history including version number and software update is recorded in thefile “citamis.str”.

Project archiving

The option SIMATIC Version Trail supports archiving of PCS 7 projects and the assignment of a ver-sion number. It distinguishes between major and minor versions, cyclic archiving can also be config-ured. Older configuration data can be retrieved; changes between two versions can be shown via theVersion Cross Manager.

Actions such as the creation, alteration, deletion of old projects data are recorded in a version historytogether with the archive name, data and comments. This ensures continuous documentation of thevarious revisions throughout the system.

Figure 5: Project versioning and archiving with SIMATIC Version Trail

Changes made in user management

Changes made in the course of user management (e.g. setup of new users, blocking users, etc.) arerecorded in the event log of Windows. The event log must be configured accordingly, as described inthe Microsoft documentation.

2.5 System Access, Identification Codes and PasswordsUsers must be assigned the required access rights only, to prevent unauthorized access to the filesystem, the directory structures, and the system data and their unintended manipulation.

The requirements regarding access security are fully met in combination with procedural controls,such as those for “specifying the responsibility and access permission of the system users”.

Additional security mechanisms need to be set up for any “open paths” which might exist. For moreinformation on the basic policies of the security concept and configuration recommendations, refer tothe “Security Concept PCS 7 and WinCC” manual.

SIMATIC Logon, a basic functionality of PCS 7, is used to set up user management based onMS Windows security mechanisms:

Individual users and their assignment to Windows user groups are defined in the Windows us-er administration.



SIMATIC Logon provides the link between the Windows user groups and the user groups ofthe single SIMATIC components like PCS 7 OS, SIMATIC Batch, etc.

Based on user groups, user rights with different levels are defined in the user administration ofthe respective SIMATIC component (e.g. PCS 7 OS).

Thereby the following access security requirements are fulfilled:

Central user management (setup, deactivation, blocking, unblocking, assignment to usergroups) by the administrator

Use of a unique user identification (user ID) in combination with a password

Definition of access rights for user groups

Access and authorization levels depending on specific plant areas

Password settings and password aging: The user is forced to change his/her password on ex-piration of a configurable time; the password can be reused only after “n” generations.

Prompt the user to define a new password at initial logon (initial password).

The user is automatically blocked after a configurable number of failed logon attempts and canonly be unblocked by the administrator.

Automatic logoff (auto-logout) after a configurable idle time of the keyboard and mouse, seefigure 3

Log functions for actions related to access security, such as logon, manual and automaticlogoff, input of incorrect user ID or password, user blocked after several attempts to enter anincorrect password, and password change by user

Projects in a multiproject can be protected from unauthorized access using SIMATIC Logon.Access can then be configured in such a way that enables access only with a personalizedcombination of user identifier and password.

Figure 6: SIMATIC Logon configuration

SIMATIC Logon meets the requirements regarding access security in combination with proceduralcontrols, such as those for “specifying the responsibility and access permission of the system users”.

In addition, users must be assigned specific access rights at operating system level to prevent unau-thorized access to the directory structure of the various system programs and unintended manipula-tion.



2.6 Electronic Signature

Electronic signature in SIMATIC Batch

SIMATIC Electronic Signature is an integral part of SIMATIC Logon.

By default, the execution of a dialog for electronic signature is integrated in SIMATIC BATCH (e.g.recipe release, change of operating mode for batches, input in the operator dialog) and is configuredvia the plant or object properties. SIMATIC Logon requests and verifies the information to be entered(user ID, password).

The technical properties of the signature can be configured within SIMATIC BATCH:

What is to be signed

Persons / groups who have to sign

Sequence of signatures, when applicable

Signing within the same session mandatory or not

Figure 7: Configuration of the electronic signature for batch release and changing parameters

The audit trail for the performed action releases is ensured by including the electronic signature in thebatch log.



Figure 8: Logging of an electronic signature in the batch report

Electronic signature in SIMATIC PCS 7 OS

Electronic signatures can be implemented in the PCS 7 OS with project methods (API) using SIMATICLogon, for example when starting a step sequencer or changing a controller parameter.

To configure multiple electronic signatures, there is an application example available in the IndustryOnline Support entry ID 66926225, see Figure 9.

Figure 9: Configuration of a multiple electronic signature scenario

Evaluation List for SIMATIC PCS 7


3 Evaluation List for SIMATIC PCS 7

The following list of requirements includes all regulatory requirements from 21 CFR Part 11 as well asfrom Annex 11. All requirements are structured in the same topics introduced in chapter 1 of thisCompliance Response.

The enlisted requirements fully consider both regulations, regardless if technological or proceduralcontrols or a combination of both are needed to fully comply with Part 11 and Annex 11.

The answers include – if applicable – how the requirement is handled during the development of theproduct and which measures should be implemented during configuration and operation of the sys-tem. Furthermore the answers include references to the product documentation for technological top-ics and to the GAMP 5 guide for procedural controls that are already considered in the guide.

3.1 Life Cycle and Validation of Computerized SystemsThe fundamental requirement that a computerized system, used as a part of GMP related activities,must be validated is extended by a number of newer Annex 11 requirements detailing expectations ona system’s life cycle.

Requirement Reference Answer

3.1.1 Risk management should beapplied throughout the lifecycleof the computerized system.

Annex 11, 1 The R&D process for Siemens software prod-ucts incorporates risk management according-ly.During the validation of a customer-specificapplication risk management should be en-sured by the regulated user.

3.1.2 Validation of a system ensuresthe accuracy, reliability, con-sistent intended performance,and the ability to discern invalidor altered records.

21 CFR 11.10 (a) Yes, the development of the software product(COTS, see Annex 11, glossary) is under thecontrol of the Siemens QMS and the ProductLifecycle Management process.The regulated user should take appropriatemeasures to validate the application (see An-nex 11, glossary), as well as maintaining itsvalidated state.

3.1.3 Validation documentation coversrelevant steps of the life cycle.

Annex 11, 4.1 Yes, the R&D process for the software productcovers all relevant steps of the Software De-velopment Life Cycle (SDLC).The responsibility for the validation of the ap-plication (see Annex 11, glossary) is with theregulated user.

3.1.4 A process for the validation ofbespoke or customized systemsshould be in place.

Annex 11, 4.6 The validation process for customer-specificapplications is under the responsibility of theregulated user. Nonetheless Siemens is ableto offer support regarding validation activities.

3.1.5 Change management and de-viation management are appliedduring the validation process.

Annex 11, 4.2 Yes, the R&D process for the software productincludes change management, deviation man-agement and fault corrections.The regulated user should ensure appropriatechange management and deviation manage-ment (see GAMP 5, appendices M8, D5).




3.1.6 An up-to-date inventory of allrelevant systems and their GMPfunctionality is available.For critical systems an up todate system description […]should be available.

Annex 11, 4.3 The regulated user should establish appropri-ate reporting, a system inventory as well assystem descriptions (see GAMP 5, appendixD6).

3.1.7 User Requirements Specifica-tions should describe requiredfunctions, be risk-based and betraceable throughout the life-cycle.

Annex 11, 4.4 Product Requirement Specifications are usedduring the R&D process.The regulated user should have the User Re-quirement Specification appropriately consid-ered in the system’s life cycle(see GAMP 5, appendix D1).

3.1.8 Evidence of appropriate testmethods and test scenariosshould be demonstrated.

Annex 11, 4.7 Ensuring the suitability of test methods andscenarios is an integral part of the SIMATICproduct’s R&D process and test planning.The regulated user should be involved toagree upon testing practice (see GAMP 5,appendix D5) for the application.

3.1.9 Appropriate controls should beused over system documenta-tion. Such controls include thedistribution of, access to, anduse of system operation andmaintenance documentation.

21 CFR 11.10 (k) During the development of the product theproduct’s documentation is treated as beingpart of the product. Thus the documentationitself is under the control of the developmentprocess.The regulated user should establish appropri-ate procedural controls during developmentand operation of the production system (seeGAMP 5, appendices M9 and D6).

3.1.10 A formal change control proce-dure for system documentationmaintains a time sequencedrecord of changes.

21 CFR 11.10 (k)Annex 11.10

During the development of the product chang-es are handled according to the developmentprocess.The regulated user should establish appropri-ate procedural controls during developmentand operation of the system (see GAMP 5,appendices M8 and O6).

3.1.11 Persons, who develop, maintain,or use electronic record/ elec-tronic signature systems shouldhave the education, training andexperience to perform theirassigned task.

21 CFR 11.10 (i) Siemens’ processes do ensure that employeeshave according training for their tasks and thatsuch training is properly documented.Furthermore Siemens offers a variety of train-ing courses for users, administrators and sup-port staff.

3.1.12 Computerized systems shouldbe periodically evaluated toconfirm that they remain in avalid state and are compliantwith GMP.

Annex 11.11 The regulated user should establish appropri-ate procedural controls (see GAMP 5, appen-dices O3 and O8).

3.1.13 All incidents should be reportedand assessed.

Annex 11, 13 The SIMATIC portfolio offers functionalities tosupport reporting on different system levels.The regulated user should establish appropri-ate procedural controls (see GAMP 5, appen-dix O5).




3.1.14 For the availability of computer-ized systems supporting criticalprocesses, provisions should bemade to ensure continuity ofsupport for those processes inthe event of a system break-down.

Annex 11, 16 The regulated user should appropriately con-sider the system in his business continuityplanning (see GAMP 5, appendix O10).

3.2 Suppliers and Service ProvidersIf the regulated user is partnering with third parties for planning, development, validation, operationand maintenance of a computerized system, then the competence and reliability of this partner shouldbe considered utilizing a risk-based approach.


3.2.1 When third parties are used, for-mal agreements must exist be-tween the manufacturer and anythird parties.

Annex 11, 3.1 The regulated user is responsible to establishformal agreements with suppliers and 3rd par-ties.

3.2.2 The competency and reliability ofa supplier are key factors whenselecting a product or serviceprovider. The need for an auditshould be based on a risk as-sessment.

Annex 11, 3.2Annex 11, 4.5

The regulated user should assess its suppliersaccordingly (see GAMP 5, appendix M2).

3.2.3 The regulated user should ensurethat the system has been devel-oped in accordance with an ap-propriate Quality ManagementSystem.

Annex 11, 4.5 The development of SIMATIC products followsthe R&D process stipulated in Siemens’ Quali-ty Management System.

3.2.4 Documentation supplied withcommercial off-the-shelf productsshould be reviewed by regulatedusers to check that user require-ments are fulfilled.

Annex 11, 3.3 The regulated user is responsible for the per-formance of such reviews.

3.2.5 Quality system and audit infor-mation relating to suppliers ordevelopers of software and im-plemented systems should bemade available to inspectors onrequest.

Annex 11, 3.4 Matter and extent of the documentation affect-ed by this requirement should be agreed uponby the regulated user and Siemens. The jointnon-disclosure agreement should reflect thisrequirement accordingly.



3.3 Data IntegrityThe main goal of both regulations is to define criteria, under which electronic records and electronicsignatures are as reliable and trustworthy as paper records. This requires a high degree of data integ-rity throughout the whole data retention period, including archiving and retrieval of relevant data.


3.3.1 The system should provide theability to discern invalid oraltered records.

21 CFR 11.10 (a) Yes.The solutions for the individual SIMATIC PCS 7components are as follows:

SIMATIC BATCHThe batch record itself can no longer be alteredand therefore does not require an audit trail.Unauthorized changes are prevented by thesystem through access control. Additionally, theSIMATIC BATCH XML records are protectedwith a checksum mechanism to detect illegalalterations.

SIMATIC PCS 7 OS (operating level)An entry can be generated in the audit trail forany operator action (if, for example, the operatorchanges set points / alarm thresholds / the moni-toring mode or acknowledges alarms). All rele-vant changes are recorded including time stamp,user ID, old value and new value and comment.Unauthorized changes are prevented by thesystem through access control.Archived records are protected with a checksummechanism to detect any unauthorized changesand/or via dedicated access rights and proce-dures.

SIMATIC PCS 7 ES (engineering level)A change log of online changes made in theengineering system can be generated for eachAS, e.g. for changing parameters of a functionblock online. Each download process can belogged (when it was performed and by whom).The change log can be evaluated on screen,saved as XML or CSV file and printed.

The verification of changes is determined by theSIMATIC Version Cross Manager and displayed,e.g. for comparing two project revisions (seechapter 2.4).

Project and library versions can be archived withversion number using SIMATIC Version Trail.SIMATIC PCS 7 also offers options for version-ing different elements like function plan andfunction blocks. Preliminary versions can becommented in order to describe a change.

3.3.2 For records supporting batchrelease it should be possible togenerate printouts indicating ifany of the data has changedsince the original entry.

Annex 11, 8.2 Operational modification of data is recorded inthe general audit trail and can be printed out in areport with internal or external functionality.




3.3.3 The system should provide theability to generate accurateand complete copies of elec-tronic records in both humanreadable and electronic form.

21 CFR 11.10 (b)Annex 11, 8.1

Yes. Accurate and complete copies can be gen-erated in electronic portable document formatsor on paper.

3.3.4 Computerized systems ex-changing data electronicallywith other systems shouldinclude appropriate built-inchecks for the correct andsecure entry and processing ofdata.

Annex 11, 5 Yes. Depending on the type of data, such built-inchecks include value ranges, data type check,access authorizations, checksums, etc. andfinally the validation process including interfacetesting.

3.3.5 For critical data entered man-ually, there should be an addi-tional check on the accuracy ofthe data.

Annex 11, 6 The system has built-in plausibility checks fordata entry. In addition, a multiple signature oroperator dialog can be realized as an additionalcheck.

3.3.6 Data should be secured byboth physical and electronicmeans against damage.

Annex 11, 7.1 In addition to the system’s access securitymechanisms, the regulated user should estab-lish appropriate security means like physicalaccess control, backup strategy, limited useraccess authorizations, regular checks on datareadability, etc. Furthermore the data retentionperiod should be determined by the regulateduser and appropriately considered in the usersprocesses (see GAMP 5, appendices O3, O4,O8, O9, O11, O13).

3.3.7 Regular back-ups of all rele-vant data should be done.

Annex 11, 7.2 The regulated user should establish appropriateprocesses for backup and restore(see GAMP 5, appendix O9).

3.3.8 Electronic records must bereadily retrievable throughoutthe records retention period.

21 CFR 11.10 (c)Annex 11, 17

Yes. As stated above, procedural controls forBackup/Restore and Archiving/Retrieval shouldbe established.

3.3.9 If the sequence of systemsteps or events is important,then appropriate operationalsystem checks should beenforced.

21 CFR 11.10 (f) Yes, e.g. allowances can be made for a specificsequence of operator actions by configuring theapplication accordingly.

3.4 Audit Trail, Change Control SupportDuring operation regulations require to record operator actions that may result in the generation ofnew relevant records or the alteration or deletion of existing records.


3.4.1 The system should create a rec-ord of all GMP-relevant changesand deletions (a system generat-ed “audit trail”). For change ordeletion of GMP-relevant data thereason should be documented.

21 CFR 11.10 (e)Annex 11, 9

Yes.Changes during operation can be traced backby the system itself via audit trail and containinformation with time stamp, user ID, old andnew value and comment. The audit trail issecure within the system and cannot bechanged by a user. It can be made availableand also be exported in electronic portabledocument formats.




3.4.2 Management systems for dataand documents should be de-signed to record the identity ofoperators entering, changing,confirming or deleting data includ-ing date and time.

Annex 11, 12.4 As far as data in SIMATIC PCS 7 is con-cerned, the requested information is part of therevision information, version information, aswell as audit trails.

3.4.3 Changes to electronic recordsshall not obscure previously rec-orded information.

21 CFR 11.10 (e) Yes.Recorded information is not overwritten and isalways available in the database.

3.4.4 The audit trail shall be retained fora period at least as long as thatrequired for the subject electronicrecords.

21 CFR 11.10 (e)Annex 11, 9

Yes, this is technically feasible and must beconsidered in the application specific backupand restore process (cp. GAMP 5, appendicesO9 and O13).

3.4.5 The audit trail should be availablefor review and copying by regula-tory agencies.

21 CFR 11.10 (e) Yes, see also requirement 3.4.1.

3.5 System Access, Identification Codes and PasswordsSince access to a system must be restricted to authorized individuals and the uniqueness of electronicsignatures also depends on the authenticity of user credentials, user access management is a vital setof requirements regarding the acceptance of electronic records and electronic signatures.


3.5.1 System access should be limitedto authorized individuals.

21 CFR 11.10 (d)21 CFR 11.10 (g)Annex 11, 12.1

Yes, system access via SIMATIC Logon isbased on the operating system’s user admin-istration, and user rights are to be defined inthe system.Nonetheless also procedural controls shouldbe established by the regulated user, as de-scribed in GAMP 5, appendix O11.

3.5.2 The extent of security controlsdepends on the criticality of thecomputerized system.

Annex 11, 12.2 System security is a key factor during designand development of SIMATIC products.Nonetheless, since system security highlydepends on the operating environment of eachIT-system, these aspects should be consid-ered in security management (see GAMP 5,appendix O11). Recommendations and sup-port is given by Siemens’ Industrial Securityapproach.

3.5.3 Creation, change, and cancella-tion of access authorizationsshould be recorded.

Annex 11, 12.3 Changes in the user access management arebeing recorded and should be subject toChange Control procedures.




3.5.4 If it is a requirement of the sys-tem that input data or instruc-tions can only come from certaininput devices (e.g. terminals)does the system check the valid-ity of the source of any data orinstructions received? (Note:This applies where data or in-structions can come from morethan one device, and thereforethe system must verify the integ-rity of its source, such as a net-work of weigh scales, or remote,radio controlled terminals).

21 CFR 11.10 (h) Yes.The SIMATIC PCS 7 OS and SIMATICBATCH workstations can be configured so thatspecial input data / commands can only beperformed from a dedicated workstation, orfrom a group of dedicated workstations. Allother workstations then have read only accessrights at the most. The system performs verifi-cations, because the stations must be inter-connected within the system.

3.5.5 Controls should be in place tomaintain the uniqueness of eachcombined identification codeand password, so that no indi-vidual can have the same com-bination of identification codeand password as any other.

21 CFR 11.300(a)

Yes.The user administration of the operating sys-tem is used as a platform for access manage-ment. It is not possible to define more than oneuser with the same user ID within a workgroup/ domain. Thus each combination of user-IDand password is unique.

3.5.6 Procedures are in place to en-sure that the validity of identifi-cation codes is periodicallychecked.

21 CFR 11.300(b)

The regulated user should establish appropri-ate procedural controls (see Good Practiceand Compliance for Electronic Records andSignatures, Part 2).

3.5.7 Password should periodicallyexpire and require to be revised.

21 CFR 11.300(b)

Yes. Password aging is based on the operat-ing system’s user administration.

3.5.8 A procedure should be estab-lished for recalling identificationcodes and passwords if a per-son leaves or is transferred.

21 CFR 11.300(b)

The regulated user should establish appropri-ate procedural controls (see Good Practiceand Compliance for Electronic Records andSignatures, Part 2). The MS Windows securitysystem can be used to deactivate user ac-counts.

3.5.9 Following loss managementprocedures to electronicallydeauthorize lost, stolen, missing,or otherwise potentially com-promised tokens, cards, andother devices that bear or gen-erate identification code orpassword information, and toissue temporary or permanentreplacements using suitable,rigorous controls.

21 CFR 11.300(c)

The regulated user should establish appropri-ate procedural controls (see Good Practiceand Compliance for Electronic Records andSignatures, Part 2).

3.5.10 Measure for detecting attemptsof unauthorized use and forinforming security and manage-ment should be in place.

21 CFR 11.300(d)

Yes, unsuccessful attempts to use the systemor to perform electronic signatures are recog-nized and can be logged.The regulated user should establish appropri-ate procedural controls to ensure a periodicreview of security and access control infor-mation logs (see GAMP 5, appendix O8).




3.5.11 Initial and periodic testing ofdevices, such as tokens andcards, that bear or generateidentification code or passwordinformation to ensure that theyfunction properly and have notbeen altered in an unauthorizedmanner.

21 CFR 11.300(e)

Such devices are not part of SIMATIC WinCCportfolio, but might be integrated in the systemvia SIMATIC Logon.The regulated user should establish appropri-ate procedural controls (see Good Practiceand Compliance for Electronic Records andSignatures, Part 2).

3.6 Electronic SignatureTo ensure that electronic signatures are accepted as generally equivalent to handwritten signaturesexecuted on paper, requirements are not only limited to the act of electronically signing records. Theyalso include requirements on record keeping as well as on the manifestation of the electronic signa-ture.


3.6.1 Written policies should be estab-lished, that hold individuals ac-countable and responsible foractions initiated under their elec-tronic signatures, in order to deterrecord and signature falsification.

21 CFR 11.10 (j)Annex 11, 14.a

The regulated user should establish appropri-ate procedural controls.

3.6.2 Signed electronic records shouldcontain the following relatedInformation:- The printed name of the signer- The date and time of signing- The meaning of the signing

(such as approval, review, re-sponsibility)

21 CFR 11.50Annex 11, 14.c

Yes.

3.6.3 The above listed information isshown on displayed and printedcopies of the electronic record.

21 CFR 11.50 Yes.

3.6.4 Electronic signatures shall belinked to their respective electron-ic records to ensure that thesignatures cannot be excised,copied, or otherwise transferredto falsify an electronic record byordinary means.

21 CFR 11.70Annex 11, 14.b

Yes.

3.6.5 Each electronic signature shall beunique to one individual and shallnot be reused by, or reassignedto, anyone else.

21 CFR 11.100(a)

21 CFR 11.200(a) (2)

Yes, the electronic signature uses the uniqueidentifiers for user accounts in the MS Win-dows user administration. The re-use or re-assignment of electronic signatures is effec-tively prevented.

3.6.6 When a system is used for re-cording certification and batchrelease, the system should allowonly Qualified Persons to certifythe release of the batches and itshould clearly identify and recordthe person releasing or certifyingthe batch.

Annex 11, 15 Electronic signatures are linked to an individu-al. The system allows strict determinationsabout which role and/or individual is allowed toperform a signature.




3.6.7 The identity of an individualshould be verified before elec-tronic signature components areallocated.

21 CFR 11.100(b)

The regulated user should establish appropri-ate procedural controls for the verification of anindividual’s identity before allocating a useraccount and/or electronic signatures.

3.6.8 When an individual executes oneor more signings not performedduring a single session, eachsigning shall be executed usingall of the electronic signaturecomponents.

21 CFR 11.200(a) (1) (ii)

Yes, performing an electronic signature re-quires the user-ID as well as the user’s pass-word.

3.6.9 When an individual executes aseries of signings during a singlesession, the first signing shall beexecuted using all electronicsignature components; subse-quent signings shall be executedusing at least one private elec-tronic signature component.

21 CFR 11.200(a) (1) (i)

Yes. Each signature consists of two compo-nents (user ID and password).

3.6.10 The use of an individual’s elec-tronic signature by anyone otherthan the genuine owner wouldrequire the collaboration of two ormore individuals.

21 CFR 11.200(a) (3)

Yes. It is not possible to falsify an electronicsignature during signing or after recording ofthe signature.In addition, the regulated user needs proce-dures that prevent the disclosure of pass-words.

3.6.11 Electronic signatures based uponbiometrics shall be designed toensure that they cannot be usedby anyone other than their genu-ine owner.

21 CFR 11.200(b)

Standard tools of third-party manufacturerscan be used to create biometric electronicsignatures. The integrity of such solutionsshould be assessed separately.

3.7 Open SystemsThe operation of an open system may require additional controls to ensure data integrity as well as thepossible confidentiality of electronic records.


3.7.1 To ensure the authenticity, integri-ty, and, as appropriate, the confi-dentiality of electronic recordsadditional measures such as dataencryption are used.

21 CFR 11.30 Additional security measures should be takenfor open systems; support is provided, forexample, based on the configuration infor-mation in the "Security Concept PCS 7 andWinCC“ manual, or by commonly availablestandard tools for encryption.SSL encryption for the communication of theterminal bus is one of those possiblemeasures.

3.7.2 To ensure the authenticity andintegrity of electronic signatures,additional measures such as theuse of digital signature standardsare used.

21 CFR 11.30 SIMATIC PCS 7 does not provide functionalityfor digital (encrypted) signatures.

Documents

Compliance Response - Siemens · PDF fileSIMATIC PCS 7 V8.1 – Compliance Response ERES 2 A5E35829023-AA Table of Contents Introduction