One of the key controls for audit trails is the link of the electronic record with the audit trail. Audit trails can be part
of the record that has been modified or a stand-alone record linked to the modified record. It must not be possible to modify
audit trails. The access rights for audit trial information must be limited to print and/or read only. The combination of
authentication, digital certificates, encryption and access control lists provides the technical mechanisms needed to control
the access to audit trail files.
“12.4. Management systems for data and for documents should be designed to record the identity of operators entering, changing,
confirming or deleting data including date and time.”
Computer systems must have adequate controls to prevent unauthorized access or changes to e-record, inadvertent erasures or
loss. Procedures should ensure that:
- Access rights for all operators are clearly defined and controlled, including physical and logical access.
- Basic rules exist and are documented to ensure security related to personal passwords or pass cards and related system/e-records
security requirements are not reduced or negated.
- Correct authority and responsibilities are assigned to the correct organizational level.
- Identification code and password issuance is periodically checked, recalled or revised.
- Loss management exists to electronically invalidate lost, stolen or potentially compromised passwords. The system should be
capable of enforcing regular changes of passwords.
- Procedures identify prohibited passwords.
- An audit log of breaches of password security should be kept and measures should be in place to address such breaches.
- The system should enforce access revocation after a specified number of unsuccessful logon attempts.
- Validated recovery of original information and e-records following back up, media transfer, transcription, archiving, or system
- Attempted breaches of security safeguards should be recorded and investigated.
Some equipment, such as standalone computer systems and dedicated operator equipment interfaces and instruments may lack logical
(e.g., password.) capabilities. These should be listed, justified and subjected to procedural controls.
“17. Archiving - Data may be archived. This data should be checked for accessibility, readability and integrity. If relevant
changes are to be made to the system (e.g. computer equipment or programs), then the ability to retrieve the data should be
ensured and tested.”
The archived records need to be trustworthy and reliable as well as accessible, no matter where they are stored. The party
having primary responsibility for record retention under the predicate regulations would be the party we would hold responsible
for adequacy of archiving.
The validation of a computer system may at first appear to be a daunting task, particularly for a person without computer
experience. In fact, such an unqualified person might be considered to be the ideal system auditor. Armed with the right tools
and questions, there is no reason why any experienced auditor cannot validate a computer system (19).
As the motor vehicle industry discovered in the 1970s, trying to retrospectively fit quality following end of line inspection
does not work. So it is with computer systems. If the environment in which a computer system is created is not controlled,
then the likelihood of a quality system being produced is very low. Poor quality equates to high risk in the pharmaceutical
industry. If we accept that an uncontrolled environment is likely to produce a poor quality system, then the place to start
our validation is the environment. In the information services industry, companies with a controlled software development
environment refer to this as their quality management system (QMS).
The Food and Drug Administration (FDA) Guideline on Principles of Process Validation defines validation as "Establishing documented evidence which provides a high degree of assurance that a specific process
will consistently produce a product meeting its predetermined specifications and quality attributes."
Using this as our guide, the process of validation should start with the environment in which a software system is produced.
This, in turn, will lead us to documented evidence that a particular piece of software will consistently produce pre-determined
Annex 11 and Validation.
Computer system validation is the formal assessment and reporting of quality and performance measures for all the life-cycle
stages of software and system development, its implementation, qualification and acceptance, operation, modification, re-qualification,
maintenance and retirement. The user must have a high level of confidence in the integrity of both the processes executed
within the controlling computer system and in those processes controlled by and/or linked to the computer system, within the
prescribed operating environment.
Validation is part of the project phase.
4.1 The validation documentation and reports should cover the relevant steps of the life cycle. Manufacturers should be able
to justify their standards, protocols, acceptance criteria, procedures and records based on their risk assessment.
4.2 Validation documentation should include change control records (if applicable) and reports on any deviations observed
during the validation process.
4.3 An up to date listing of all relevant systems and their GMP functionality (inventory) should be available. For critical
systems an up to date system description detailing the physical and logical arrangements, data flows and interfaces with other
systems or processes, any hardware and software prerequisites, and security measures should be available.
4.4 User Requirements Specifications should describe the required functions of the computerised system and be based on documented
risk assessment and GMP impact. User requirements should be traceable throughout the life cycle.
4.5 The regulated user should take all reasonable steps to ensure that the system has been developed in accordance with an
appropriate quality management system. The supplier should be assessed appropriately.
4.6 For the validation of bespoke or customised computerised systems there should be a process in place that ensures the formal
assessment and reporting of quality and performance measures for all the life-cycle stages of the system.
4.7 Evidence of appropriate test methods and test scenarios should be demonstrated. Particularly, system (process) parameter
limits, data limits and error handling should be considered. Automated testing tools and test environments should have documented
assessments for their adequacy.
A procedure must be developed to delineate the normal path of the computer system validation activities. The procedure must
address validation projects based on criticality and complexity. Based on these criteria, the procedure should define the
documentation requirements. A validation plan may be used for any deviation from the standard computer validation project.