Information security of computerised systems for global compliance

Arjun Guha Thakurta, Director – Operations, Life Science Consulting (a Convalgroup Company), emphasises on deploying an effective computerised system to defend critical electronic data and comply with quality compliance

The recent cases of warning letters and non – conformity reports in India, especially related to electronic records integrity issues from the regulated users, uncovered by global regulators have revived the dialogue among the industry on information security controls of a computerised system. To ensure integrity to electronic data it is essential to assure trustworthy computer systems.

It is very common in the life science industry to observe that a few years after deploying a computer system, deficient operational supporting processes and/or the incorrect implementation of such processes nullify the validated state of the computer system, causing remediation activities which sometimes take years to complete. This situation is typical across multiple computer systems and provokes a remediation project across the company,  thereby adding cost to the operational life-cycle of many computer systems.

Trustworthy computer systems are the first line of defence to protect critical electronic data managed by these systems. These computer systems consist of computer infrastructure, applications, and procedures that:

• Are sufficiently suited to performing their intended use
• Provide a certain level of availability, reliability and correct operation
• Are sufficiently secure from intrusion and misuse
• Adhere to generally accepted security principles.

The key driver of the computer systems validation process is to ensure an acceptable degree of evidence (documented, raw data), confidence (dependability and thorough, rigorous achievement of predetermined specifications), intended use, accuracy, consistency and reliability, or in other words, ensure that the computer system is trustworthy.

Routine use of computer systems during the operational life-cycle requires procedural controls that describe how to perform operational activities. These operational, procedural controls must be in place and approved. The execution of these procedural controls should be monitored by the pharma company to verify the accurate implementation and adherence. These procedural controls should be reviewed on a periodic basis in accordance with the local retention policy. In addition, it is important that management should ensure that the relevant associates are trained accordingly.

Key operational procedural controls are:

• Data archiving: In the context of the user, archives consist of records that have been selected for permanent or long-term preservation based on their evident value. All computer system baselines should be archived in an environmentally controlled facility, as applicable, that is suitable for the material being archived and is both secure and, where possible, protected from environmental hazards. A record of all archived materials should be maintained.
• Data backup and recovery: A backup process must be implemented to allow for recovery of the system following any failure that compromises its integrity. Integrity and accuracy of backed-up data and the ability to restore the data should be checked during validation and monitored periodically. The frequency of backups depends on data criticality, amount of stored data, and frequency of data generation. Procedural controls establishing the backup process must be in place to ensure the integrity of backups (secure storage location, adequately separated from the primary storage location, etc.). This may be part of a more general disaster recovery plan.
• Disaster recovery and business continuity: Business continuity procedural controls, including disaster recovery procedural controls, ensure minimal disruption in the case of loss of data or any part of the system. It is necessary to ensure that the integrity of the data is not compromised during the return to normal operation. At the lowest level, this may mean the accidental deletion of a single file in which case procedural controls should be in place for restoring the most recently backed-up copy. At the other extreme, a disaster such as a fire could result in loss of the entire system. The procedural control employed should be tested regularly and all relevant personnel should be made aware of its existence and trained to use it. A copy of the procedural controls should be maintained off-site.
• Infrastructure repairs and preventive maintenance: The procedural controls applicable for the preventative maintenance and repair of the infrastructure provide a mechanism for anticipating problems and, as a consequence, prevent possible loss of data. In addition to the typical infrastructure elements such as system-level software, servers, wide-area network, local-area manager, and the associated components; the infrastructure includes uninterrupted power supplies (UPSs) and other emergency power generators. Modern infrastructure hardware usually requires minimum maintenance because electronic circuit boards, for example, are usually easily replaced and cleaning may be limited to dust removal. Diagnostic software is usually available from the supplier to check the performance of the computer system and isolate defective integrated circuits. Maintenance procedural controls should be included in the organisation’s procedural control. The availability of spare parts and access to qualified service personnel are important for the smooth operation of the maintenance programme.
• Issue/ incident/ problem reporting: The malfunction or failure of a computer system components, incorrect documentation, or improper operation that makes the proper use of the system impossible for an undetermined period are some characteristics of the incidents that can affect the correct operation of a computer system. These system incidents may become non-conformances. In order to remedy problems quickly, a procedural control must be established to record any computer system failures from the users of the system. These enable the reporting and registration of any problem encountered by the users of the system.
• Issue/ incident/ problem management: Reported problems can be filtered according to whether their cause lies with the user or with the system itself and then fed back into the appropriate part of the supplier’s organisation. In order to remedy problems quickly, a procedural control must be established if the system fails or breaks down. Any failures, the results of the analysis of the failure, and, as applicable, any remedial actions taken must be documented. Those problems that require a remedial action involving changes to any baseline are then managed through a change control process.
• System retirement: The retirement of computer systems performing control operations is a critical process. The purpose of the ‘Retirement Period’ is to replace or eliminate the current computer system and, if applicable, ensure the availability of the data that it has generated for conversion, migration, or retirement.
• System restore: A procedural control for regular testing of restoring backup data to verify the proper integrity and accuracy of data must be in place.
• IT security: Computer systems security includes the authentication of users and access controls. Security is a key component to maintain the trustworthiness of a computer system and associated records. Security is an ongoing element to consider and is subject to improvement. In particular, after a system has been released for use, it should be constantly monitored to uncover any security violations. Any violation must be followed up and analysed and proper action must be taken to avoid a recurrence.
• Training: All staff maintaining, operating and using computer systems that perform control operations must have documented evidence of training in their area of expertise. For users, the training will concentrate on the correct use of the computer system, security, and how to report any failure or deviation from the normal operating condition.

The essential practices as listed below is relevant to the security of a standalone or networked computerised system. All applications must have a qualified authentication mechanism to control access (EMA Annex 11-Principle 2).

• Software ‘virus checking’ must take place periodically to protect the applications and data.
• Procedural controls must be established to specify the manner in which application security is administered (ICH Q7 Section 5.44).
• The process for setting up access to applications must be defined and executed by the appropriate application-specific security administration personnel. The technical preparation, education, and training for personnel performing administration tasks, and associated documented evidence, are a key regulatory requirement (EMA Annex 11-2).
• The management of the user application accounts is a key procedural control. This procedural control includes requesting the addition, modification, and removal of application access privileges (EMA Annex 11-12.3). The request is approved by the appropriate manager, is carefully documented, and submitted to the application security administration for execution of the request.
• There must be a procedure to grant temporary application specific access for personnel (21 CFR Part 11.10(d)).
• In the event that a user leaves the company, there must be a process to notify the appropriate security administration as soon as the employee departs (EMA Annex 11-12.3).
• A procedure must exist which defines the escalation process and actions to be taken upon discovery of unauthorised access (EMA Annex 11-13).
• A documented record of security administration activities must be retained.
• Procedures must exist to control remote modem access to applications via the applicable infrastructure.
• In cases where data or instructions are only available from specific input devices (e.g. instruments, terminals), the system should be checked for, and the operator should verify, the use of the correct device (EMA Annex 11-5).
• When an individual has been authorised to use the system, time stamped audit trails (EMA Annex 11-9) must record write-to-file operations and changes, and independently record the date and time of the application specific operator’s actions or entries.
• Time stamped audit trails (EMA Annex 11-9) must be used to keep track of modifications by the database administrator to the application related electronic records.
• The use of operational checks is recommended to enforce sequencing (21 CFR Part 11.10(f)).
• Authority checks (21 CFR Part 11.10(g)) must be used, when applicable, to determine if the operator can use the system, operate a device, or perform the operation at hand.
• The electronic records must not be altered, browsed, queried, or reported via external software applications that do not enter to the data repository area through the protective technological controls (US FDA [31], EMA Annex 11-7.1 and Annex 11-17, and TGA.)
• Unauthorised modification to the system clock must be prevented (21 CFR Part 11.10(d)). One possible technological control around this item is the use of a Digital Time-stamping Service or an infrastructure that supports time stamping from a trusted time service (e.g. coordinated universal time).

Frequent deficiencies observed in computerised system documentation

• Missing information: Documents or records omitted fundamental information or content that should have been included.
• Inconsistency: Documents contained statements inconsistent with other statements about the same topic in the same document or in the same validation package.
• Lack of needed detail: This deficiency applied mostly to requirements documents. The requirements in the validation package did not adequately describe the characteristics of data, user interactions with business processes, or key processes internal to the software.
• Traceability Matrix: Frequent traceability problems are seen:
• The traceability matrix did not account for a traceable specification or an observation step in a test script.
• The trace was broken. Either a requirement was barren (lacked decedents or a test) or one of the detailed requirements or test results was an orphan (lacked a parent somewhere in the requirement tree).
• The traceability matrix was incomplete. Requirement details were not explicitly numbered and traced to associated test steps.
• Requirements were not traced at a detailed level, so the reviewer needed to infer the detailed links between specifications and steps in a test script.
• Vague wording: Documents used generalities like ‘in accordance to an approved procedure’, or ‘applicable regulatory requirements’ or ‘all associated GXP and business processes’. In addition, documents used vague words such as ‘may’, ‘possibly’, ‘more or less’, and ‘approximately’.
• Unverifiable test results: Expected results were not described sufficiently for an independent reviewer to compare and verify actual results. For executed scripts, actual results were not recorded or captured in a way that allowed an independent reviewer to compare them to expected results. For e.g., ‘OK’ was noted in the actual-result column with no reference to a screen shot.

Good documentation practice (GDP)

• Hand-recorded data and testing evidence, such as test results, were presented in a way that could cause doubts about their authenticity (e.g., cross-outs without initials, date, and reason)
• Data that confirmed a specific requirement was hard to find in the evidence provided (e.g., a busy screen shot crammed with data)
• Incomplete testing: Test scripts did not fully or adequately test the associated requirement.
• Ambiguity: Text could be interpreted more than one way, so it did not establish a single, unique requirement. The words ‘either’ and ‘or’ in a requirement are strong clues the text is ambiguous.