VAL-060 Protecting Reliability of Electronic GMP Documents

1.            Principle

“Good documentation constitutes an essential part of the quality assurance system” – Code of GMP).  Documentation is used to:

a. Identify the components and operations to be used (e.g. specifications, procedures)

b. Record the actions, activities, or events that occur (e.g. records, alarm logs)

c. Capture the outcome of operations, testing or assessments (e.g. certificate of analysis)

d. Respond to deviations or complaints (e.g. investigation reports, distribution records)

e. Demonstrate authorisation by appropriate persons (e.g. batch release).

It is clear that documents that support GMP compliance must be reliable.

There are very many potential threats to the reliability of data.  These can be split into various categories (e.g. Human-related; Computer-related and Operation-related).  Table 1 provides some examples of how reliability attributes are vulnerable to potential threats.

A wide range of Control Measures can be deployed against the various threats to data reliability.  Controls perform in various means – supportive (enabling other control measures to be implemented), preventive (providing initial defence against threats) and responsive (detecting and recovering from a failure of other controls).  Control measures must address all three general threat sources (human, computer and operation) and may be classified as either technical or non-technical (management and operational):

a. Management controls focus on the development of policies, guidelines and standards to be carried out through operational procedures (e.g. access authorisations, responsibility definitions, continuity support plans and system performance auditing).

b. Technical controls are safeguards that are incorporated into computer hardware, software or firmware (e.g. access control mechanisms, identification and authentication mechanisms, encryption methods, intrusion detection software).

c. Operational controls are procedures and systems implemented alongside technical controls to address computer system deficiencies that might result in loss of reliability (e.g. virus protection software, data backup, physical security measures and environmental controls).

A fundamental principle for implementing control measures is the use of multiple, overlapping methods to address the human, computer and operational related aspects of a system.  This principle recognises that a system cannot be secured unless all interconnecting elements are secured adequately.

Figure 2: Control Measures protect Record Reliability

Control measures prevent the reliability of records being compromised by threats.  However, if the measures provide inadequate coverage, a vulnerability exists which can be exploited by a threat, thereby putting data at risk (Figure 2).  Effective control strategies include both technical and non-technical measures.  The use of diverse, overlapping controls ensures a single-point failure will not leave the system unprotected.

A control strategy is designed by choosing from a combination of Technical, Management, and Operational controls.  This involves trade-offs in cost, complexity and effectiveness.  For instance, reliability might be improved by implementing user passwords, or by issuing a user procedure.  The Technical control (a security software add-on) might be more complex and expensive than the Management control, however it is likely to be more effective because the enforcement is automated.

Given the variety in computer-system construction, features and functionality it is not feasible to tightly prescribe which control measures to select. Such an approach would likely result in either under-specifying or over-specifying requirements or inhibit the development of appropriate new methods to increase assurance.  Rather, the selection process should be a matter of judgement and risk appraisal, based primarily on the mode of usage (which presents the threat-opportunity) and the GMP Impact (which relates to the level of assurance required for a document).

This procedure provides such a risk-based approach to selecting control measures; using a gap-assessment approach, rather than designing measures for a ‘naked’ system.  The SOP presents an inventory of industry-standard control measures and suggests where each might be considered appropriate for selection.  The System Owner is presented with an assessment of the residual risk associated with an existing or proposed system after auditing the actual measures implemented.

2. Assessment Procedure

The process of assessing the Control Measures supporting specific records is illustrated in Figure 3.  The outcomes of this assessment are to be documented on Form 710.  The steps involved in this process are described below:

Figure 3: Flowchart for Risk-Assessment Procedure

2.1. Identify the Record

Identify the record to be assessed and the host computer system(s) where the record is generated, processed or stored.  Briefly describe the Record’s role and use.  Note these and the computerised system Inventory number on Form 710.

Computer systems will typically support a number of records and care should be taken to identify the precise record being considered (especially as each may have different control measures, modes of use and / or GMP significance).  Often records may be saved as multiple, independent files generated from a standard template or computer program (e.g. on a per batch basis).  In this case the analysis may be performed on the standard template or report and this should be noted.  Where reports are generated from a consolidated database, the database and the report function should be considered together.

2.2. Assess the GMP Impact

Assess the GMP significance of the record being analysed.  The record will be assigned one of three possible levels of Impact – Direct, Indirect or No-Impact – reflecting the role of the record in supporting product quality, patient safety or GMP compliance. SOP VAL 045 describes the process for determining the level of Impact and includes suggested ratings for various common record types.

Note that the host computer system will also be rated according to SOP VAL 045, however, the record itself may have a different rating.  A record might have a lower level of Impact than its associated computer system (but should never have a higher level of Impact).

In general the stringency and extent of control measures should increase with the level of Impact.

2.3. Determine the Mode of Use

Determine the actual mode in which the record is used; paper copy, electronic copy or both.  The usage method presents different threat opportunities and consequently requires different control measures.

Computer systems often generate or process records only in order to produce a paper-copy.  In such cases the computer system is incidental and there are no copies of the record stored (or used) in an electronic format after the paper-copy is produced.  An obvious example of this situation is a word-processed document that is printed, then authorised, distributed and only used in its hard copy format.  In this case, only the author uses the original electronic document.  For such record types it is appropriate to require less Technical (i.e. computer-based) control measures.

On the other hand, a record might be fully used and maintained in an electronic format.  In such cases, a printed copy would typically be considered uncontrolled, temporary and potentially out-of-date.  The Technical control measures for such a record type become more significant and extensive.

On some occasions a combination of the paper-copy and the electronic-copy of a record might be used.  This situation (called a Hybrid) requires special attention because of the difficulty of keeping both copies aligned throughout their lives.  Hybrid records require the Technical control measures applicable to electronic records (e.g. audit-trail, encryption, un-editable format) plus Management measures to ensure alignment of the paper and electronic copies.  Hybrid systems require procedures to document their control (and justify their existence).  In some cases, the paper copy may not be a ‘complete’ record if not accompanied by other data stored electronically (e.g. any audit trail).  Often, records that are considered paper-only copies may, in fact, be Hybrid because the electronic record continues to be stored and even used for reference or further processing.  The actual pattern of use will determine when a record is a Hybrid.

(To assist understanding the mode of use, a simple flow diagram of the process involved in creating the record is suggested.  This should also identify when any electronic files are printed or deleted).

2.4. Determine Mode of Approval

The record may be subjected to review, confirmation or approval in order to demonstrate its validity.  Determine how this is signified; handwritten signature on a paper copy, ‘electronic signature’ to an electronic copy, both forms (or none).  Record this on Form 710.

The mode of approval will likely be affected by the mode of use that has been selected (Section 2.3) but may not fully align.  Electronic signatures will require additional measures to ensure authenticity.  As noted above, Hybrid signatures require even further management procedures to ensure that the alignment of paper and electronic copies is maintained.

Section 3.1 includes guidance on when records may require approval to satisfy GMP requirements.

2.5. Audit the Control Measures

Form 710 presents a list of industry-standard control measures.  A more detailed explanation of each of these measures is included in Appendix 1.  (Appendix 1 also references relevant sections of regulatory guidelines where these measures are indicated).  The following steps are to be repeated for each of these control measures:

2.5.1. Identify Control Measures Present

Consider if the control measure (as described in Appendix 1) has been implemented for this record and system.

2.5.2. Assess the Attributes Protected

If a control measure has been implemented mark a ‘Y’ (Yes) in the column corresponding to the reliability-attribute that is protected by this measure.

Conversely mark ‘N’ (No) where the attribute is not protected.

Some control measures can support more than one reliability-attribute, in such cases mark all columns affected.  Some control measures cannot be implemented for the type of record that is generated (e.g. electronic backups of paper records) – in this case mark the cell as ‘N/R’ (Not Required).

To assist this assessment, certain cells on Form 710 have been shaded where it is considered unlikely that a control measure will provide any benefit.  Shaded cells may be left blank where the answer would otherwise be ‘No’ or ‘N/R’.

2.5.3. Compare against Minimum Reference Standard

Each control measure on Form 710 has been assigned a Minimum Reference Standard, suggesting the lowest level of Impact at which it might be considered appropriate.  This determination was based on the nature of the measure (how complex, costly and common it is to implement) and any specific GMP requirements.  Appendix 1 includes references to cGMP and PIC/S documents suggesting each measure.  The most basic and fundamental measures have been labelled “No-Impact”, while the more rigorous as “Direct” Impact.

Compare the Minimum Reference Standard label for each control measure with the GMP Impact rating for the record, determined in Step 2.2 (above).  Control measures that are labelled “Direct”, “Indirect” or “No-Impact” should be considered for records with Direct Impact.  Records with No-Impact may be adequately protected by “No-Impact” measures alone.

2.5.4. Comment on any Variations

Assess and document on Form 710 the outcome of the comparison (step 2.4.3) for each control measure.  Table 2 illustrates some suggested comments for various conditions of implementation:

The comment field may also be used to document any additional information relevant to the Control Measure (e.g. names of SOPs, implemented features).

Note that control measures corresponding to Impact ratings greater than that of the record might be implemented for reasons other than GMP compliance (e.g. to comply with IT security standards or to protect other business risks).  The presence of these measures should be documented.

2.6. Assess the Total Control Strategy

After assessing all of the control measures separately, the adequacy of the total control strategy should be assessed.  The following factors are relevant to this consideration:

a. Are all reliability-attributes covered by the strategy?

b. Do a variety of control measure types protect each reliability-attribute?

c. Have any limitations to the effectiveness of specific controls been identified?

d. Have any potential vulnerabilities been identified?

Consider the assessment for each separate reliability attribute (i.e. accuracy, authenticity, availability and integrity) by referring to the corresponding columns.  Condense the evaluation into an overall assessment of record reliability.  Record each assessment on
Form 710 along with a justification.

Completion of this process may highlight particular vulnerabilities.  The control measures associated with these vulnerabilities will help to identify some suggested improvements to protect the record.  Document these improvements on Form 710 under Management, Technical and Operation categories.  The list of improvements may overlap and is not intended to exclude solutions using measures that are not identified; rather it is a reference and starting point for future remedial work.

If the System Owner is not comfortable with the residual risk associated with the assessed record the suggested (or other) control measure improvements should be implemented to mitigate this risk.

2.7.  Authorise and Store the Assessment

The completed assessment form will be signed by the author and reviewed by a Technical Expert and the Computer Systems Validation Manager (or Validation Manager).  The System Owner will authorise the assessment indicating that they are satisfied with the assessed status of the record and will take responsibility for any necessary remedial work.

The completed form should be updated after the implementation of any risk mitigation activity.  The reason for, and nature of, the change is to be recorded in the version table at the bottom of Form 710  (along with the associated Manufacturing Change Request).  Conversely, any change that reduces the level of protection is also to be documented on an updated form.

3. Further Considerations

3.1. Electronic Signatures

Regulators advise that:

“the use of a computerised system does not reduce the requirements that would be expected for a manual system of data control and security” (PIC/S 011 – Section 19.1).

When paper records are used, critical GMP actions and decisions are traced to individuals through a hand-written signature.  This approach applies readily when a computer-system produces a record as a paper-copy.  ‘Electronic signatures’ are the analogous authentication process for fully computerised, ‘paperless’, systems.  A wide variety of technical solutions are available for implementing ‘electronic signatures’ (e.g. biometric, non-biometric).  The key requirement of any ‘electronic signature’ is that it should serve the same purpose, have the same meaning and same legal significance as a hand-written signature.  Assurance of the authenticity of any electronic signature will require a range of procedures and control measures to ensure security, integrity, confidentiality and non-transferability (i.e. unable to be cut-and-pasted).  The electronic signature should also form an integral part of the completed record.  These measures can be drawn from those used for protecting the reliability of electronic records in general (as per Appendix 1).  Whatever measures are selected must be validated.

As noted already, electronic records do not necessarily imply a requirement for ‘electronic signatures’.  Hand-written authorisation of the paper-copy is suitable where the electronic record is not subject to further update or electronic use.  If both paper and electronic versions are to be used (i.e. a Hybrid record) additional control measures are required.  The electronic record and hand-written signature should be linked together in a completely unambiguous manner (eg including specific document or file name references on the signed print-out). Procedures are required to ensure that changes to the electronic record are reflected in the paper version or vice versa.

The need for a personal identification will be determined by the GxP regulations (as a minimum).  Two types of requirement for identification exist.  The first is where a ‘signature’, ‘initials’, ‘authorisation’, ‘approval’ or ‘review’ is required.  Examples of these can be found in Table 3.  The use of an electronic signature in these cases gives added assurance to the reliability of the record.  The author must perform such ‘signings’ specifically and intentionally on each occasion (rather than being an incidental product of operating the system).

Table 3 – Examples of Activities / Records requiring Approval / Authorisation

Another class of identification is inferred when particular actions are restricted to authorised persons (perhaps without the need for specifically recording that person).  In these cases there is no ‘signing’ and, although electronic-signature technology may be used for this purpose, it may be acceptable to use other system security controls to prove authenticity of the person.  Table 4 illustrates examples from the code of GMP where persons require authorisation and/or identification.

Table 4 – Examples of Persons requiring Authorisation / Identification

In summary, cGMP (and company procedures) identify where ‘signatures’ are required.  The way that a system is implemented or operated determines whether the ‘signature’ is to be electronic or hand-written.  This is at the discretion of the company.  If an electronic ‘signature’ is used it must be supported with appropriate control measures to ensure that it is a reliable component of the completed record.  The measures identified in Appendix 1 should be considered for this role.

3.2. Approach for data that is not a Record

This procedure is only concerned with data that is output as a record.  The following guidance, based on the principles in this SOP, may be useful when dealing with other data types.

3.2.1. Volatile Data and Temporary Files

Computer systems often handle and process data without saving it permanently.  Two main ways of doing this are volatile data and temporary files.

Temporary files are records that are created by a system to support its operation.  These may provide the ability to undo previous steps or recover from an error or power-loss.  Such files are transient and only available for the system to use.  Usually there is only one such file for each system in use and they are deleted at specific milestones, (e.g. saving a file; restarting a system).  Most of the control measures available for records may be applied to temporary files.  If the computer system manages these files in a secure fashion and continues to delete, (rather than accumulate) them, they are considered outside the scope of this procedure.

Volatile data is kept within a system’s run-time memory and will be lost with a power-down.  Consequently, volatile data is not a record.  Control measures available for such transient data are more limited than for records and include:

a. Infrastructure protection – physical access restrictions and environmental controls

b. Security management – access controls, passwords

c. Validation – in-use testing, system qualification

d. Software controls – data-validity checking, error handling, data transfer protocols

e. Policies, procedures, training – user training, defined responsibilities, procedures.

In many systems a selection of these measures will provide sufficient assurance of reliability.

One example of volatile data is transient, user-entered, input data that is used in control-equipment.  In this case the stringency of controls should reflect the degree of discretion that a user is permitted, (e.g. freedom to enter any value, versus restriction to a choice or range of values) and the fault-tolerance of the system itself (including any GMP impact of a user-entered value).  Where the system is open to external-access, (i.e. off-site via Internet or similar) the maximum level of controls should be considered.

Another example is intermediate, in-operation data that is gathered and processed to generate a result.  The result may be used to produce records (which may have GxP impact).  The captured raw data may not need to be stored for the final record to be considered reliable.  For instance a check-weigher, that measures millions of tablet weights for each batch, is used to generate a curve showing that the batch weight distribution falls within specified norms.  When the check-weigher performance has been validated, the individual data points do not need to be recorded for each use.

Some systems generate, process and then transmit volatile data to other systems for storage (and perhaps further processing).  Again, there is no need for the initial system to produce its own record and the relevant control measures for this system relate to the accuracy, authenticity and integrity of the transmitted data.  (The control measures of the receiving system may be eligible for review under this procedure).

Methods to capture and store volatile data (as a record) should be considered when:

a. The effort required to re-establish lost data is substantial

b. The actual value of data is critical as evidence, (i.e. for traceability or reprocessing)

c. The identity of the user performing a data entry activity needs to be recorded.

3.2.2. Programs

Software programs and configuration files may be thought of as ‘data’ that prescribe the way a system will perform its functions.  This procedure does not consider software as a record.

Software is usually the output of a development environment, where programmers work with data in a human-readable form, which is converted to a machine-readable form within the target computer system.  Changes to software require the ability to access this data and possibly also to interrupt the operating run-time environment before they can be made.  The restriction of this access is a key means of ensuring software authenticity.

Validation and Change Control are the other main means of ensuring the reliability of software, particularly its accuracy.  The practices associated with this approach are already described in SOP VAL 040.  Other control measures, however, may be appropriate to support other aspects of software reliability, (e.g. authenticity, availability and integrity):

a. Infrastructure protection – physical access restrictions and “malware” protection

b. Security management – external-access checks, centralised storage and user access profiles

c. Backup and restore – back-up procedure, checking of outcome and redundant copies

d. Disaster recovery – response capability

e. Audit trail – author identification and author authentication

f. Software controls – error handling, automated generation (development aids) and independent checking (validation)

g. Policies, procedures, training – developer selection & training, activity history, reviews and audits, defined responsibilities and operational procedures.

As with volatile input-data, where the system is open to external-access a very high level of control should be considered.

Note that the software development environment, (i.e. source-code tool) does not have the same level of GMP significance or impact as the system that is controlled by the code.  Consequently the tools do not necessarily require the same level of assurance, or control measures, as the developed process.  (For instance, software that operates an automatic audit trail function does not require its development environment to have the same functionality – a manual system of change control could be adequate).

Examples of software files that are considered to be outside the scope of this procedure include:

o    Vision system models,

o    Autoclave-cycle configurations,

o    HPLC recipes,

o    Exacta Filter-test configurations.

4. Appendix 1 – Checklist / Explanation of Control Measures