Part 11 Compliance SOP

1.0 Commercial in Confidence 16-Aug-2006 1 of 14 Part 11 Compliance SOP Document No: SOP_0130 Prepared by: David Brown Date: 16-Aug-2006 Version: 1.0

1.0 Commercial in Confidence 16-Aug-2006 2 of 14 Document Approval Name Role Date Signature David Brown Author Document Control Version Author Date Description 1.0 David Brown 16-Aug-2006 First draft.

1.0 Commercial in Confidence 16-Aug-2006 3 of 14 Table of Contents 1 Introduction... 4 1.1 Purpose... 4 1.2 Scope... 4 1.3 Definitions... 4 1.4 Responsibility... 5 1.5 References... 6 2 Procedure... 7 2.1 Overview... 7 2.2 Electronic Signature/Electronic Records... 7 2.3 Application Specific Requirements... 7 2.4 Functional Requirement Specification... 8 2.5 21 CFR Part 11 Interpretation... 9 2.6 Practices related to the Use of Electronic Signatures... 14

1.0 Commercial in Confidence 16-Aug-2006 4 of 14 1 Introduction 1.1 Purpose 1.2 Scope To define the requirements for the design of validated computer systems as they relate to the use of electronic signatures, electronic records, and appropriate operation. Department/Section: IT and Validation Groups This SOP applies to all validated computer systems implemented after 20 th August 1997. However, all systems implemented prior to that date should meet the predicate rules of 21 CFR [FDA: Guidance for Industry: Part 11, Electronic Records; Electronic Signatures Scope and Application]. 1.3 Definitions Access Security - Security involves the overall protection of hardware, software, and electronic records from unauthorized or accidental modification, destruction, or disclosure. Biometrics - A method of verifying an individual's identity based on measurement of the individual's physical feature(s) or repeatable action(s) where those features and/or actions are both unique to that individual and measurable. Closed System - An environment in which system access is controlled by persons who are responsible for the content of electronic records that are on the system. Digital Signature - An electronic signature based upon cryptographic methods of originator authentication, computed by using a set of rules and a set of parameters such that the identity of the signatory and the integrity of the data can be verified. Data security The ability to prohibit access to a data record by unauthorized means. Data security involves access control within and external to the application. Electronic Records - 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. Electronic Signature - A computer data compilation of any symbol or series of symbols executed, adopted, or authorized by an

1.0 Commercial in Confidence 16-Aug-2006 5 of 14 individual to be the legally binding equivalent of the individual's handwritten signature. Handwritten Signature - The scripted name or legal mark of an individual handwritten by that individual and executed or adopted with the present intention to authenticate writing in a permanent form. The act of signing with a writing or marking instrument such as a pen or stylus is preserved. The scripted name or legal mark, while conventionally applied to paper may also be applied to other devices that capture the name or mark. Open System - An environment in which system access is not controlled by persons who are responsible for the content of electronic records that are on the system. System Specifications (also referred to as Specifications) - Document(s) which describe what a system processes or how it provides control. Specifications can include single or multiple sets of documents, such as internal/external design documents, program specifications, functional requirement documents, drawings, electrical drawings, flowcharts, timing diagrams, user guides, technical documents and vendor provided documentation. Client the business system owner is typically the line manager responsible for the business process where the computer system will be used. Validation Group the group responsible for ensuring that computer systems are implemented and maintained in a validated state. IT Group the group responsible for development, operation, and maintenance of computer systems. 1.4 Responsibility Those who commission, develop, configure, maintain, and/or install a validated system are responsible for ensuring that the system complies with this SOP. Validation and client groups are responsible for ensuring that practices related to the use of electronically approved records are incorporated in appropriate client SOP s.

Title Part 11 Compliance SOP 1.0 Commercial in Confidence 16-Aug-2006 6 of 14 1.5 References Document ID Title 21 CFR Part 11 Part 11 of Title 21 of the Code of Federal Regulations. Electronic Records. Electronic Signatures. N/A FDA: Guidance for Industry: Part 11, Electronic Records; Electronic Signatures Scope and Application. Template_11_0001 Part 11 Assessment Template.

1.0 Commercial in Confidence 16-Aug-2006 7 of 14 2 Procedure 2.1 Overview The specific requirements of 21 CFR Part 11 and FDA: Guidance for Industry: Part 11, Electronic Records; Electronic Signatures Scope and Application must be considered during the design of a computer system. These requirements must include system configuration, system component integration, access security, and data integrity. The configuration of a computer system is typically decided in the design phase of the system development life cycle. There are often existing constraints that would affect the decision (i.e. existing networks, personnel, and geographical distribution of users and equipment). In any system, security is a major design consideration and should be established early in the design phase. While the possibility of deliberate abuse cannot be ignored, the majority of security breaches are associated with accidental abuse, arising from a lack of user proficiency or poor system design. Training, system access procedures, and sound design are therefore all fundamental requirements of a secure computer system. Due to regulatory requirements for electronic records security, security requirements for computer systems must be adequate to prevent accidental and/or intentional abuse. The following requirements reflect the understanding that security design cannot be absolute or complete, but instead, will reduce risks or exposures. The template [template_11_0001 Part 11 Assessment Template] is provided to assist in conducting an assessment of how the computer system will address the requirements of Part 11. 2.2 Electronic Signature/Electronic Records Electronic signatures generated while using computer systems that comply with this SOP, are considered to be the legally binding equivalent of the person s handwritten signature. 2.3 Application Specific Requirements The security requirements described in this section are based on regulations presented by FDA in Title 21 of the Code of Federal Regulations, Part 11, titled Electronic Signature and Electronic Records. This regulation defines requirements for systems that

1.0 Commercial in Confidence 16-Aug-2006 8 of 14 provide functionality for operations as defined in the cgxps. All validated systems employing electronic signatures and/or electronic records, either developed or purchased must comply with the security requirements provided in this SOP. 2.4 Functional Requirement Specification The following section describes requirements that all newly developed or purchased applications requiring validation must comply with, where the application stores electronic records and electronic signatures. These requirements must be included in the Functional Requirement Specification for the application. For applications where electronic records are recorded but an electronic signature is not required, the Functional Requirement Specification does not need to include the requirements in section 3 of the following table Application Security Design Requirements. Any justification for the system deviation from these requirements is to be recorded in the Validation Plan and must be approved by the validation group.

Title Part 11 Compliance SOP 1.0 Commercial in Confidence 16-Aug-2006 9 of 14 2.5 21 CFR Part 11 Interpretation The following table provides an interpretation of 21 CFR Part 11. The functionality of new systems should be measured against this interpretation. 1. Operating Systems and Application Software Access Control (see Note 1) 21 CFR Part 11 1.1 All users must be positively identified by having a unique user-id and a 11.10 (d) personal, secret password before being able to gain access to any computer system as verified against the security table at logon. 1.2 The length of passwords must always be checked automatically at the 11.10 (d) time users choose them, and passwords are recommended to have no fewer than six (6) characters. 1.3 All users must be able to change their passwords at any time. 11.10 (d) 1.4 All users must periodically change their passwords. (It is recommended to change passwords at least once every ninety (90) days). 1.5 Any password that is written to a file or the security database should be encrypted. Suitable encryption standards are RSA (Rivest-Shamir- Adleman), and NIST s Digital Signature Standard, (DSS). [The DSS became Federal Information Processing Standard (FIPS) 186 on December 1, 1994.] Where systems components are linked across application boundaries using automatic log-on sequences, passwords for user-ids with update capability should be read from a secure, encrypted system file, solely accessible to the system manager instead of using "hard-coded" passwords. 1.6 User passwords should not be viewable by anyone including security administrators. 1.7 Users entering new passwords should be required to enter unique passwords. At least one of the following should be used: a) restrict uniqueness of passwords during last six (6) months; b) restrict the re-use of the last 24 passwords. 11.300 (b) 11.10 (d) 11.10 (d) 11.300 (b)

Title Part 11 Compliance SOP 1.0 Commercial in Confidence 16-Aug-2006 10 of 14 1.8 Methods to restrict access of authorized persons should be employed after five (5) consecutive unsuccessful attempts to enter a password. At least one of the following should be used: a) the involved user-id must be suspended. The Security Administrator is required to reset the password in order for the user to be able to access the system again. b) the system must lock out the user for a period of at least five (5) hours. c) continuous monitoring and alerting functions are employed to detect access failures. 11.10 (d) 1.9 The system must be able to display or report current access rights of a user showing the user-id and all of their access capabilities to resources [e.g., file accesses, grants, permissions, etc.]. 1.10 The system must maintain a log of all security violations in logging into the computer system that include: a) the user-id who created the violation b) date & time of violation c) resource name (if appropriate) A display or report output must be available for viewing the Security Violations History/Log. 1.11 For applications requiring multiple levels of access, provide security controls to restrict access to components of the application by user or user group. If user group controls are utilized, provide functionality to assign users to one or more user groups. Controls should include components of the application which can be accessed such as screens and reports and the type of access allowed such as read, update, or delete. Applications requiring greater level of control should be designed to provide access to the appropriate data or field/data level security capability. 2. Data Integrity 2.1 The capability should be available to backup electronic records on at least a daily basis everywhere electronic records are stored. 2.2 Electronic data distributed on multiple machines should be able to be backed up and restored in a synchronized manner so that recovery of one or more files/servers does not compromise the integrity of the electronic data on the 'system'. The 'system' includes databases on the file servers/clients on all hardware platforms. 11.300 (b) 11.300 (d) 11.300 (d) 11.10 (c) 11.10 (c)

Title Part 11 Compliance SOP 1.0 Commercial in Confidence 16-Aug-2006 11 of 14 2.3 Secure, computer-generated, time-stamped audit trails should be used to independently record operator entries and actions that create, modify, or delete electronic records. Record changes should not obscure previously recorded information. In other words, an audit trail must contain sufficient information to allow a reviewer to trace all changes to a record, from its current state back to the original values of the record. Additionally, information within the audit history should contain: a) the user-id; b) the date and time stamp when the record was created, modified, or deleted; c) the new value; d) the old value; e) the transaction type (e.g., inserts, delete, modify) associated with the transaction. This audit trail data must be retained for a period at least as long as that required for the related electronic records. A display or report output must be available for viewing the audit history. This audit trail should be applied electronically a paper audit trail is not sufficient. 2.4 For database applications, transactions since the last backup should be able to be logged in order that synchronized forward data recovery and error processing can be performed. 2.5 File servers and host computers should be operated using Uninterrupted Power Service (UPS), other battery backup measures, or EPROM. 2.6 System privileges must be established that ensure users are only able to modify electronic records in a controlled manner. Update access to the electronic records can ONLY be allowed through validated secured application screens [i.e. no direct user (normal operator) access to electronic records through database tools such as SQL*PLUS]. 2.7 Application objects and application source code must be controlled using either: an automated configuration/version control system that provides change history for objects under control, or by a manual system that maintains previous versions throughout the established retention periods. 2.8 PCs that store electronic records, application configuration data, or software programs should be secured to prevent users from being able to manipulate, override, or otherwise invalidate the electronic records, application code, or operating environment of the system. Where securing of the client workstations is not possible due to environmental and/or technical limitations, automated auditing of the workstations-software components may be employed to satisfy this requirement. This auditing process must be in addition to any security functionality, which can be reasonably implemented and practically maintained at the operating system. 11.10 (e) 11.10 (c) 11.10 (c) 11.10 (g) 11.10(e) 11.10(c)

Title Part 11 Compliance SOP 1.0 Commercial in Confidence 16-Aug-2006 12 of 14 2.9 Critical records such as lot status or analytical lab data should not be stored in multiple locations unless automatic functions exist to maintain data integrity. The duplicate data should be refreshed at a frequency to satisfy the data currency requirement of the system. 2.10 Concurrent update (write) access by multiple users or processes to a single electronic record must not be allowed. 2.11 Updates to electronic records, which do not occur completely and successfully, should be negated such that all fields associated with the record are restored to their original state (e.g. rollback). 2.12 Operational system checks must be employed to enforce permitted sequencing of steps and events, as appropriate. 2.13 Device checks should be employed to determine, as appropriate, the validity of the source of data input or operational instruction. For example, an application indicating that data input is derived from a particular device (e.g. balance) should identify the device or allow data entry only from that device and not from a terminal. 2.14 Open systems should include additional measures such as document encryption and use of appropriate digital signature standards to ensure, as necessary under the circumstances, record authenticity, integrity, and confidentiality. 3. Electronic Signatures 3.1 Electronic signatures, though not required, should be employed where application functions perform tasks identified in FDA regulations using the words signature, hand-written signature, notarized, signed, or approved. If electronic signatures are not employed in an application, the requirements in 3.2 through 3.6 below do not have to be met. 3.2 Electronic signatures and handwritten signatures executed to electronic records must be logically linked to their respective electronic records to ensure that the signatures cannot be excised, copied or otherwise transferred so as to falsify an electronic record by ordinary means. 3.3 Signed electronic records should contain information associated with the signing that clearly indicates all of the following: The full name of the signer (first name, middle initial, last name); The user-id of the signer; The date and time when the signature was executed; and The meaning (such as review, approval, responsibility, or authorship) associated with the signature. The above items shall be included as part of any human readable form of the electronic record (such as electronic display or printout). Where the electronic record extends to multiple pages of displays or printouts, the above signing information must clearly be linked to the entire record to which it applies. 11.10(c) 11.10(c) 11.10(c) 11.10(f) 11.10(h) 11.30 11.200(a) 11.70 11.50

Title Part 11 Compliance SOP 1.0 Commercial in Confidence 16-Aug-2006 13 of 14 3.4 Electronic signatures that are not based upon biometrics must employ at least two distinct identification components such as an identification code and password. When an individual executes a series of signings during a single, continuous period of controlled system access, the first signing must be executed using all electronic signature components; subsequent signings must be executed using at least one electronic signature component that is only executable by, and designed to be used only by, the individual. When an individual executes one or more signings not performed during a single, continuous period of controlled system access, each signing must be executed using all of the electronic signature components. 3.5 Electronic signatures based upon biometrics must be designed to ensure that they cannot be used by anyone other than their genuine owners. 3.6 Electronic signature functions should be able to detect and log attempts at unauthorized use of electronic signatures. 3.7 When an electronic record is approved via a hand-written signature on paper, the paper on which the signature is executed must contain adequate field and date/time information such that the electronic record(s) to which the signature does, and does not, apply can be determined with absolute certainty. The electronic audit trails, in combination with the information on the signed paper, must allow a reviewer to determine the value of each record field at the time the paper was generated. 4. Physical Security 4.1 Application file/database servers that store application electronic records or programs should be located in controlled areas such as computer rooms with adequate physical access security, ventilation, and protection from hazards such as fire, heat, and water. 4.2 Access to the system via dial-up communications must only be provided with a "call back" or SecurID type security system. 4.3 The user session should automatically log-off when a disconnect is detected for dial-up communications. 5. System Administration 5.1 Application should have the ability to generate accurate and complete copies of records in both human readable and electronic form suitable for inspection, review, and copying by the agency. 11.200(a1) 11.200(b) 11.300(b) 11.300(b) 11.10(c) 11.10(g) 11.10(g) 11.10(b) Notes: 1. Where the logon is performed at the network or operating system level and a separate logon is required for the application, the items 1.1-1.10 apply must be fulfilled at each logon. 2. In the above Design Requirements, the words must and should are used intentionally. The word must implies mandatory compliance. The

1.0 Commercial in Confidence 16-Aug-2006 14 of 14 word should is usually applied where optional methods are proposed, available, or possible to meet a particular requirement. The method is regarded as optional, while the need for compliance remains mandatory. Any alternate method used must be justified and appropriately documented. 2.6 Practices related to the Use of Electronic Signatures In certain situations, it is necessary to print out electronic signature records for users who may not have access to the electronic records. This printed signature record should be labelled Copy Verified By: along with the signature and date by the person who verified the printed record was produced by the electronic system. Printed records from an electronic system must not be used in an official manner without including the above statement.