21 CFR Part 11 has been in effect for over 25 years, but in an ever-modernizing digital environment, Part 11 compliance is more important than ever. In a nutshell, Part 11 sets forth requirements that GxP electronic records and electronic signatures are required to meet. While the scope of the regulation is not terribly difficult to grasp, understanding how to establish documented evidence that your GxP computerized system is compliant with the regulations can be a tricky endeavor that requires prudence in all steps of the process. It’s easiest to begin by parsing Part 11 requirements into functional requirements and non-functional requirements in order to divide and conquer.
Functional Requirement – A requirement of the system to be capable of performing a certain function or action. This can be verified through performance of a test within a protocol or potentially through vendor provided documentation.
i.e. 11.300(a) Maintaining the uniqueness of each combined identification code and password, such that no two individuals have the same combination of identification code and password.
Non-functional Requirement – A supporting, procedural or policy requirement that is not fulfilled by the system’s capabilities.
i.e. 11.10(i) Determination that persons who develop, maintain, or use electronic record/electronic signature systems have the education, training, and experience to perform their assigned tasks.
Functional requirements should be incorporated into a User Requirements Specification (URS). In addition to requirements leveraged from 21 CFR Part 11, other business requirements can be incorporated into this document to help business owners source systems capable of meeting the documented requirements and serve as a foundation for validation testing.
Non-functional requirements must be met through policy, procedures or work instructions. While non-functional requirements may be a bit trickier to wrap your head around since they are not traditionally confirmed as part of qualification testing, oftentimes the implementation of policies, procedures or work instructions can support the implementation of GxP computerized systems on a larger scale with minimal repeat efforts.
Sourcing Your Equipment
Ensuring Part 11 compliance begins even before purchasing your equipment. It’s common (in the realm of laboratory instrumentation, for example) for there to be GxP and non-GxP versions of the same software. They may both accomplish the same functional goal, but you may be missing key data integrity features such as audit trails or electronic signatures. At this stage in procurement, it’s advised to have a User Requirements Specification in draft form and to utilize it to ensure the system being purchased is not only capable of meeting Part 11 requirements but also your business requirements.
Assessment and Configuration
A commonly made mistake in onboarding GxP computerized systems is assuming that a system is compliant from the get-go. Even when purchasing software that is marketed as ‘Part 11 Compliant’, due diligence is required to ensure the system is administered, configured, and put into a state of control. It’s recommended to use a Part 11 assessment tool to determine what actions must be taken to configure the system and set up any supporting processes. Some examples include but are not limited to:
- Establishing a backup and restoration process
- Configuring user roles and permissions
- Creating supporting SOPs (i.e. System Use, System Administration)
- Setting a password expiration interval
Configuration should be completed and documented prior to validation. By documenting relevant configuration parameters, settings, and any other relevant system aspects, your organization is establishing a state of control for your computerized system. Once released for GMP use, it’s recommended to only make changes to your GMP computerized system under your organization’s established change control process.
Validation
As part of establishing fitness for use within a business, validation is one of the most crucial tasks to complete. In addition to being a regulatory requirement, it allows a business to establish, to a high degree of confidence, that a system is installed, operates, and performs within pre-defined specifications. Oftentimes, vendors will provide installation and validation support in the form of a vendor provided validation packages. While it may be tempting to forego purchasing the services, it can be invaluable to leverage vendor validation documentation and testing services to bulk up your validation foundation. However, it’s important to understand that a vendor validation package is not a substitute for ensuring the proper internal due diligence is performed. The vendor may be able to test and provide robust documentation, but if the content is not tailored towards your business use case or your organization’s specific needs, it’s recommended to supplement accordingly. The foundation for validation testing begins with the already-documented list of user requirements and devising test scripts designed to verify the documented requirements. Through a series of Installation, Operational, and Performance Tests (generally referred to as Installation Qualification, Operational Qualification, and Performance Qualification), a business will ensure both functional and non-functional requirements pertaining to a soon-to-be GMP system are tested and documented in a robust manner.
Listed below is a regulatory roadmap with recommendations on how to ensure your company and GxP computerized systems meet 21 CFR Part 11 requirements:
| Regulatory Requirement | How to satisfy the requirement: |
| §11.10(a) – Validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records. | Ensure the regulated company has a CSV program and Validation Master Plan (VMP) that defines the validation lifecycle for computerized systems that generate electronic records. |
| §11.10(b) – 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. | Verify this during validation by creating a test script that generates an electronic record and verify that it can be retained in an accessible, human-readable form throughout the duration of the data retention period. |
| §11.10(c) – Protection of records to enable their accurate and ready retrieval throughout the records retention period. | Implement a combination of technical controls and/or procedural controls to ensure generated data cannot be tampered with, but remains accessible (i.e. in a read-only format). Verify controls during validation by creating a test script to attempt to modify generated data as an unauthorized user. |
| §11.10(d) – Limiting system access to authorized individuals. | Ensure roles are defined within the computerized system such that personnel have the minimum necessary capabilities to perform their respective job functions. Access shall be controlled by an administrating party such that only trained users with the appropriate job function will be granted access to the system. Verify establishment of roles during validation by creating a test script to confirm presence and ability to assign users to specific roles. |
| §11.10(e) – Use of secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records. Record changes shall not obscure previously recorded information. Such audit trail documentation shall be retained for a period at least as long as that required for the subject electronic records and shall be available for agency review and copying. | Verify this during validation by performing a GMP action that creates, modifies and/or deletes electronic records. Within a test script, navigate to the audit trail and confirm the time-stamped audit trail provides sufficient information to recreate the contents of the action. Ensure the audit trail is accessible for review, but non-alterable. |
| §11.10(f) – Use of operational system checks to enforce permitted sequencing of steps and events, as appropriate. | Verify this during validation by creating a test script that confirms the inability to skip steps or events when undesired. Ensure checks establish “rails” that do not allow a user to deviate from the established sequence of steps and events. An example of an operational system check that enforces permitted sequencing of steps and events would be to verify that a user cannot approve an electronic record before first reviewing the record (within a workflow that requires review before approval). |
| §11.10(g) – Use of authority checks to ensure that only authorized individuals can use the system, electronically sign a record, access the operation or computer system input or output device, alter a record, or perform the operation at hand. | Verify this during validation by creating a test script that confirms the inability to access the system, electronically sign a record or any other GxP action without valid credentials. |
| §11.10(h) – Use of device (e.g., terminal) checks to determine, as appropriate, the validity of the source of data input or operational instruction. | Verify this during validation by confirming checks in place to ensure input is accurate and allowed. Examples of device checks can be physical (i.e. monitor or interface to confirm input) or digital (i.e. parameter restriction that limits allowed input to a given range). |
| §11.10(i) – Determination that persons who develop, maintain, or use electronic record/electronic signature systems have the education, training, and experience to perform their assigned tasks. | Ensure personnel have clearly defined job functions and that pre-requisite training and verification of credentials is performed before granting access to a GxP system. The regulated company shall have a training program with appropriate curricula assigned to users needing to access GxP systems. Examples of appropriate training material to be included within a curricula can include but is not limited to: System Operation SOPs, Good Documentation Practices, Data Integrity, etc. |
| §11.10(j) – The establishment of, and adherence to, written policies that hold individuals accountable and responsible for actions initiated under their electronic signatures, in order to deter record and signature falsification. | Ensure personnel have been trained on the use and control of their electronic signatures and are made aware of their binding nature and equivalency to handwritten signatures. |
| §11.10(k) – Use of appropriate controls over systems documentation including: 1. Adequate controls over the distribution of, access to, and use of documentation for system operation and maintenance. 2. Revision and change control procedures to maintain an audit trail that documents time-sequenced development and modification of systems documentation. | System SOPs, forms and work instructions shall be ideally maintained in an electronic Document Management System (eDMS) where document access, distribution, use, revision and obsolescence is defined and controlled. In lieu of an eDMS, procedures shall exist to ensure adequate control over GxP system documentation. |
| §11.30 – Persons who use open systems to create, modify, maintain, or transmit electronic records shall employ procedures and controls designed to ensure the authenticity, integrity, and, as appropriate, the confidentiality of electronic records from the point of their creation to the point of their receipt. Such procedures and controls shall include those identified in §11.10, as appropriate, and 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. | An open system is one where access to the system is not controlled by the entity responsible for the content of the electronic records on the system. An example of an open system could be a web-based application that does not require pre-authentication. While an open system grants more flexibility and may be necessary for certain business cases, it creates a higher level of risk because access is not tightly controlled. As a result, it’s paramount to ensure the system employs digital signatures that protect against falsification and adequately identifies the signatory and all relevant metadata related to the signature. Encryption tools can also be used to further restrict access within the system as a measure to implement security post-access. |
| §11.50(a) – Signed electronic records shall contain information associated with the signing that clearly indicates all of the following: 1.The printed name of the signer; 2. The date and time when the signature was executed; and 3. The meaning (such as review, approval, responsibility, or authorship) associated with the signature. | Verify this during validation by creating a test script that attempts to electronically sign an electronic record. Ensure within the manifestation of the signature (i.e. on the electronic printout) that the required components are present. Ensure the electronic signature is non-transferrable and permanently bound to the record, as the signature is subject to the same requirements as an electronic record (see §11.10 requirements). |
| §11.70 – Electronic signatures and handwritten signatures executed to electronic records shall be linked to their respective electronic records to ensure that the signatures cannot be excised, copied, or otherwise transferred to falsify an electronic record by ordinary means. | Ensure handwritten signatures on GMP documents are performed using indelible black/blue ink (or the chosen choice of permanent ink by the company) and the documents are reconciled to ensure neither the signature nor the document can be adulterated, copied or transferred. For electronic signatures, verify during validation that a signature cannot be transferred, removed or copied from a record. |
| §11.100(a) – Each electronic signature shall be unique to one individual and shall not be reused by, or reassigned to, anyone else. | Verify this during validation by creating a test script that confirms the ability for a system to create and maintain unique accounts. Establish a procedure to ensure users are each granted their own unique account and that there are no shared accounts on the system. |
| §11.100(b) – Before an organization establishes, assigns, certifies, or otherwise sanctions an individual’s electronic signature, or any element of such electronic signature, the organization shall verify the identity of the individual. | Corporate policy shall be established to ensure due diligence is performed to verify an individual’s identity prior to granting access to any GMP system utilizing an electronic signature. |
| §11.100(c) – Persons using electronic signatures shall, prior to or at the time of such use, certify to the agency that the electronic signatures in their system, used on or after August 20, 1997, are intended to be the legally binding equivalent of traditional handwritten signatures. | Training shall be established to ensure personnel are trained on the use of electronic signature and acknowledge that they are legally binding equivalents to handwritten signatures. |
| §11.200(a) – Electronic signatures that are not based upon biometrics shall:(1) Employ at least two distinct identification components such as an identification code and password.(i) When an individual executes a series of signings during a single, continuous period of controlled system access, the first signing shall be executed using all electronic signature components; subsequent signings shall be executed using at least one electronic signature component that is only executable by, and designed to be used only by, the individual.(ii) When an individual executes one or more signings not performed during a single, continuous period of controlled system access, each signing shall be executed using all of the electronic signature components.(2) Be used only by their genuine owners; and (3) Be administered and executed to ensure that attempted use of an individual’s electronic signature by anyone other than its genuine owner requires collaboration of two or more individuals. | Verify during validation by creating a test script that tests the following: Credentials have, at a minimum, a username and password requirements. Further identification components such as a PIN number or two-factor authentication is acceptable.Ensure that when signing multiple records within a single login session, signings after the first utilize an identification component that is private and only known to the owner (i.e. a password, PIN, 2FA). Ensure that when signing multiple records not within a single login session, signings after the first within each session require all identification components. Administration of user accounts (and by extension electronic signatures) shall be performed in a way where nobody other than the owner knows their own credentials. Some examples of this are: Administrators shall not know other users credentials or have the ability to login as another user. When an administrator assigns a temporary password, immediate password change is enforced to ensure an administrator cannot login as another user in the future. Password aging and complexity requirements are implemented to reinforce account security. |
| §11.200(b) – Electronic signatures based upon biometrics shall be designed to ensure that they cannot be used by anyone other than their genuine owners. | Verify during validation by creating a test script that attempts to access a system using biometrics or fakes designed to fool a biometrics system. The method utilized to attempt to find vulnerabilities in a system can vary based on the biometrics type. An example test method may be to attempt to utilize similar biometrics (i.e. same skin color for a thumb print scanner, same eye color for a retina scanner) in an attempt to verify a system’s capability to accurately validate a user based on biometrics. |
| §11.300(a) – Maintaining the uniqueness of each combined identification code and password, such that no two individuals have the same combination of identification code and password. | Verify during validation by creating a test script that attempts to create an account with a duplicate username to an existing account. System should not allow this to happen. |
| §11.300(b) – Ensuring that identification code and password issuances are periodically checked, recalled, or revised (e.g., to cover such events as password aging). | Verify during validation by creating a test script that confirms the functionality of the password aging on the system (i.e. set the aging of passwords to a day and verify the system prompts user to enter a new password. Revert to the proper interval afterwards). Ensure procedures are in place to ensure administrators periodically check access to a system and confirms users have the appropriate access and users who are no longer in the applicable role or with the company have been deactivated. |
| §11.300(c) – Following loss management procedures to electronically deauthorize lost, stolen, missing, or otherwise potentially compromised tokens, cards, and other devices that bear or generate identification code or password information, and to issue temporary or permanent replacements using suitable, rigorous controls. | Ensure there are procedures and technology in place to deactivate compromised tokens, cards and/or other devices that generate identifying information. Administrators shall be capable and empowered to deactivate accounts or limit access in a situation where the integrity of a system is compromised. |
| §11.300(d) – Use of transaction safeguards to prevent unauthorized use of passwords and/or identification codes, and to detect and report in an immediate and urgent manner any attempts at their unauthorized use to the system security unit, and, as appropriate, to organizational management. | Verify during validation by creating a test script that confirms the functionality of a system to lockout users after repeated attempts and, if applicable, notifies the administrator or appropriate security unit. |
| §11.300(d) – Initial and periodic testing of devices, such as tokens or cards, that bear or generate identification code or password information to ensure that they function properly and have not been altered in an unauthorized manner. | Verify during validation by creating a test script that tests the functionality of tokens or cards that generate/bear identification codes. Ensure that where such measures are in place, access is not possible without the tokens/card. During periodic review of a system, functionality and integrity of tokens and/or cards shall be checked. |
Reference: Electronic Records; Electronic Signatures.” Code of Federal Regulations, Title 21, Part 11, Food and Drug Administration, 1997