Audit Trail Requirements for a Digitalized Regulated Laboratory

Digital transformation of analytical processes requires suppliers to design and implement audit trail(s) (AT) that are fit for intended use in a regulated laboratory. In addition, second person review of electronic data requires critical examination of the pertinent audit trail entries of each analysis performed using a computerized system. This is good analytical science as well as good regulatory compliance.

This article discusses options for reviews, the regulatory requirements and guidance for audit trails, audit trail design, procedures for audit trail review and explains how to apply ALCOA++ principles for effective review of entries.

The aim of this article is to help laboratory staff, quality personnel and suppliers improve audit trail design, functionality and review and long-term record retention.

The meaning of system, application and software can be different within GxP sources, however, in this article we use these words interchangeably. In the short term, meaningful artificial intelligence (AI) audit trail review is some time away and is out of scope. Our focus is on having effective functionality in an application to automatically identify potential problems in AT entries.

Overview of GxP audit trail regulations

We will start with a brief explanation of the history of the main GxP regulations and guidance documents for audit trail. Regulatory requirements are important. If you do not understand the regulations and their history and intent, how can you know a selected system provides you with adequate capabilities to monitor changes and deletions, as well as enabling efficient review of audit trail entries?

Food and Drug Administration (FDA)

• The earliest implicit or explicit regulatory requirement for an audit trail for  automated data systems (e.g., computerized systems) was issued in 1978: the US GLP (Good Laboratory Practice) regulations 21 CFR 58.130(e)¹:
  
  … In automated data collection systems, the individual responsible for direct data input shall be identified at the time of data input. Any change in automated data entries shall be made so as not to obscure the original entry, shall indicate the reason for change, shall be dated, and the responsible individual shall be identified.
  
  
• Promulgated in the same year was 21 CFR 211,² but this regulation has no explicit mention of audit trail. However, since 2005 and the Able Laboratories fraud case³ review of original records for accuracy, completeness, and compliance with established standards in 21 CFR 211.194(a)(8) has been interpreted to include electronic records and audit trail entries in computerized laboratory systems.²
  
  
• The electronic records; electronic signatures regulation (21 CFR 11) issued in 1997 has two clauses for audit trails.⁴ The first is 11.10(a) that requires a technical control to discern … altered records. This is the trigger for the audit trail requirements under 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.
  
  
• Although, the FDA Part 11 Scope and Application guidance⁵ issued in 2003 allowed audit trail enforcement discretion for legacy systems operational when 21 CFR 11 was published, we advise you to ignore this. Audit trails are critical for digitalized operations.
  
  
• In 2016, FDA published a draft GLP update entitled the GLP Quality System where 21 CFR 58.130(a) would have been updated to include reference to ALCOA criteria and that data must be credible, internally consistent, and corroborated.⁶ However, there is no sign when a final version will be issued.
  
  
• Recently FDA issued a guidance on Electronic Systems, Electronic Records, and Electronic Signatures Clinical Investigations: Questions and Answers.⁷ (We will call it FDA Clinical Q&A Guidance for convenience). This is significant as it is the first Part 11 guidance that has been issued since 2003.⁵ If the portions on clinical studies and digital health technologies are ignored, the document provides current advice on FDA’s interpretation of 21 CFR 11 for GMP (Good Manufacturing Practice) and GLP.
  
  Q12 states: To ensure the trustworthiness and reliability of electronic records, audit trails must capture electronic record activities including all changes made to the electronic record, the individuals making the changes, and the date and time of the changes and should include the reasons for the changes. Audit trails should be protected from modification and from being disabled … ⁷
  
  … Persons must still comply with all applicable predicate rules. Even where there are no predicate rule requirements related to documentation, it is nonetheless important to have audit trails or other physical, logical, or procedural security measures in place to ensure the trustworthiness and reliability of the electronic records. ⁷

The last paragraph is very interesting for two reasons. First, procedural controls for audit trails have no place in a digitalized laboratory. Second, audit trails are important for ensuring the trustworthiness and reliability of e-records even when there is no predicate rule in place.⁷ This is consistent with the scope of 21 CRF 11.1(b):

… This part also applies to electronic records submitted to the agency under requirements of the Federal Food, Drug, and Cosmetic Act and the Public Health Service Act, even if such records are not specifically identified in agency regulations … ⁴

Any research data as a part of a regulatory submission must comply with 21 CFR 11 regulations including those for audit trail.  

Q13 states Should an audit trail record every key stroke?⁷ 

Summarising the answer: No.

EU and PIC/S GMP Annex 11

Annex 11 has been a regulation for over 30 years.

• 1992: Annex 11 was originally published and clause 10 on audit trail stated ⁸:   
  … Any alteration to an entry of critical data should be authorised and recorded with the reason for the change …
  
  
• 2011: The current version of Annex 11 contains two clauses relating to audit trail⁹:  
  
  9. Consideration should be given, based on a risk assessment, to building into the system the creation of a record of all GMP-relevant changes and deletions (a system generated "audit trail"). For change or deletion of GMP-relevant data the reason should be documented. Audit trails need to be available and convertible to a generally intelligible form and regularly reviewed.
  
  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.
  
  

Annex 11 is currently being revised and clause 9 has 7 proposed changes (Items 18–24) that illustrate the importance of audit trail and its review by regulators.¹⁰  The draft for industry comment will be released this year.   

ICH E6(R3) Good Clinical Practice (GCP)

The GCP guidelines were updated in January 2025, and section 4.2.2 (b) states¹¹:

Ensuring that audit trails, reports and logs are not disabled.

Audit trails should not be modified except in rare circumstances (e.g., when a participant’s personal information is inadvertently included in the data) and only if a log of such action and justification is maintained;

The first sentence is consistent with regulatory guidance discussed above.

However, the second sentence is in direct contradiction with all other GxP regulations. Audit trails must be secure and computer-generated. They must not be changed. What do the writers of the regulation propose for recording of such changes? A paper log? If there was this functionality available to delete a subject’s personal information, it is a function for carte blanche falsification of clinical data. 

No audit trail, no problem?

GxP guidance documents give a crumb of hope where a system has no audit trail by giving consideration for alternative measures:  

• 6.13 … Where relevant audit trail functionality does not exist (e.g., within legacy systems) an alternative control may be achieved …¹²
  
  
• 9.6 … If no electronic audit trail system exists a paper-based record to demonstrate changes to data may be acceptable until a fully audit trailed (integrated system or independent audit software using a validated interface) system becomes available … ¹³
  
  

However, no audit trail function will NOT work in a digitalized laboratory. To work electronically, an audit trail is critical to ensuring trustworthiness and reliability of GxP records and electronic data. Our advice is to replace all legacy systems without audit trails.

Regulatory reality 

As shown in Table 1, if you are going to digitalize your laboratory, using software without adequate audit trail functionality is unacceptable from practical, scientific and regulatory perspectives.   

Table 1: Reference to audit trail in GxP regulations and regulatory guidance.

Regulation/guidance	Requirement
FDA Clinical Q&A Guidance 7	Q12 … To ensure the trustworthiness and reliability of electronic records, audit trails must capture electronic record activities …
Concept Paper on the revision of Annex 1110	18 … such systems without audit trail functionality is not acceptable; any grace period within this area has long expired.
Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments (PIC/S PI 041-1)13	9.6 … Companies should select software that includes appropriate electronic audit trail functionality. Companies should endeavour to purchase and upgrade older systems to implement software that includes electronic audit trail functionality.
OECD GLP No 22 Data Integrity14	6.13 Some GLP Compliance Monitoring Authorities may not accept systems without audit trail functionality including those with alternative control measures …
EMA GMP Annex 11 (2011)9	9. … Consideration should be given, based on a risk assessment, to building into the system the creation of a record of all GMP-relevant changes and deletions (a system generated "audit trail") …

Caveat emptor!

Smith and McDowall reviewed 104 FDA 483 and warning letter citations for infrared spectrometer systems; of these, 15% were due to lack of an audit trail.

This means that the system selection process was deficient as either the compliance features were not assessed or lack of an AT was not considered significant or not turned on.¹⁵ 

Therefore, before selecting a computerized system, a laboratory must ensure that the compliance features are in place, otherwise, your digitalized workflows will be hybrid and you run the significant risk of regulatory citations.

A system without an audit trail has no place in a regulated laboratory. Also, not saving data when the system is capable of doing this will result in a warning letter.¹⁶ 

ALCOA++ criteria for audit trail entries

As noted by the PIC/S PI 041-1 guidance¹³ and the proposed GLP Quality System,⁶  audit trail entries should meet ALCOA+ criteria. What does this mean? 

The 10 ALCOA++ criteria for data integrity stand for:

• Attributable, Legible, Contemporaneous, Original, Accurate (ALCOA),
• Complete, Consistent, Enduring, Available (ALCOA+) and
• Traceable (ALCOA++).¹⁷

A detailed discussion on the origin and meaning of the ten criteria is available¹⁸ and Figure 1 interprets how to apply ALCOA++ principles to audit trail entries. 

Figure 1: ALCOA++ requirements for audit trail entries. Credit: Bob McDowall.

Audit Trail Design

There are nine main audit trail(s) design elements and functions that suppliers must incorporate into their application for effective use in any digitalized regulated laboratory, see Figure 2.

Figure 2: Key audit trail design elements and functions. Credit: Bob McDowall.

1. Audit trail cannot be turned off

The first design requirement is a technical control for any audit trail to work from installation of the software and cannot be turned off. This is to eliminate any possibility of users or system administrators turning an audit trail off to hide data falsifications or deletions. The ability to turn audit trails off and then back on again is cited in warning letters and 483 citations.¹⁵

2. Database or flat file?

Implementing an application where data files are stored in directories in the operating system is not a recommended option for an effective audit trail. Where this has occurred, AT entries were stored within the data file itself. The problem is that these files were vulnerable via the operating system and, if deleted, the audit trail did not record the deletion on the file’s journey to the recycle bin. Therefore, the only way to design an effective audit trail is to use a database that monitors the whole system.

Also, any application should be designed so that there is no backdoor access to data to prevent falsification via administrators and avoid audit trail entries.         

3. Single audit trail or separate system and data audit trails?

It is important to point out that the lifetime of e-records and data usually exceeds the lifetime of the computerized system that generates them.

From a system design perspective, there are two alternatives for audit trail design:

A single AT covers all activities within a system such as system configuration, user account management, user log on and off, instrument connections and any incidents, plus data acquisition, modification and, if allowed deletion. This is good at giving an overall big picture BUT unless there are effective search routines for second person review, quality oversight and data integrity audits this apparently, simple approach has problem of separating the wood from the trees.  

Another consideration is the analytical instrument acquiring data. A polarimeter is an instrument where data collection is relatively simple with little data manipulation. Compare this with a complex instrument such as an LC-MS-MS which will generate much more data which can be subject to interpretation of the data by a user.

A separation of entries between system and data audit trails is a far better approach that permits more effective audit trail review as well as efficient archive and restore, as we shall discuss later. Figure 3 shows the audit trail coverage of a system and data audit trail. The data audit trail focuses on the data life cycle and will be subject to second person review and data integrity audits. The system audit trail records the events of system configuration, user account management, instrument connections and operational status and is subject to data integrity audits and periodic review. Both audit trails should have functions to record on-line reviews as discussed later in this section.

Figure 3: Design for separate system and data audit trails. Credit: Bob McDowall.

4. Contemporaneous recording of changes

As shown in Figure 1, one of the ALCOA++ criteria is contemporaneous recording of data changes coupled with the corresponding entries in the audit trail. Q12 of FDA’s Data Integrity and Compliance with CGMP guidance says:

Draft issued in 2016:

… it is not acceptable to store data electronically in temporary memory, in a manner that allows for manipulation, before creating a permanent record. Electronic data that are automatically saved into temporary memory do not meet CGMP documentation or retention requirements.¹⁹

This was modified in the final guidance issued in 2018:

... For example, chromatographic data should be saved to durable media upon completion of each step or injection (e.g., peak integration or processing steps; finished, incomplete, or aborted injections) instead of at the end of an injection set, and changes to the chromatographic data or injection sequence should be documented in an audit trail. Aborted or incomplete injections should be captured in audit trails and should be investigated and justified ...²⁰

Both quotes are valuable for understanding how data changes should be identified and recorded as they occur in an audit trail.  Although focused on chromatography, it is applicable to any laboratory data system.

5. Time stamp detail

Again, an ALCOA++ criterion is contemporaneous. We have split the time and date stamp discussion into two. An accurate time stamp is vital in determining the sequence of events in a computerized system. Time stamp accuracy was addressed in the FDA’s withdrawn guidance on time stamps as within a minute²¹ which can be interpreted as ±30 or 60 seconds. Time zone is also important in global systems²² and an additional time stamp of UTC / GMT (Coordinated Universal Time / Greenwich Mean Time) can be used to verify consistent and sequential actions in a global digitalized workflow. 

However, there is no regulation or guidance document that states or suggests the detail of the time stamp itself. There are three possible options:

1. HH:MM
2. HH:MM:SS
3. HH:MM:SS.X(X)

The time stamp can be either a 12 or 24-hour clock but the former requires AM or PM to be added, however the latter option is unequivocal. Option 1 is useless as many activities can occur in a minute. Option 2 is a possible option in a standalone system but if several activities occur in a second, it is only the order of AT entries that can infer the order of activities. Option 3, where time is recorded to 1/10 or 1/100 second, is better for multi-user systems.

An issue arises in regions where there are summer/wintertime changes. FDA’s 2007 clinical guidance notes:

There is no expectation to document time changes that systems make automatically to adjust to daylight savings time conventions.²²

If used, ensure these automatic adjustments are in your specifications.

The sequence of time stamping activities in any system must be understood so that a clear explanation can be given in audits and inspections.

6. Date stamp detail

Completing the time stamp is the date format; there are several different date formats that could be used:

• DD-MM-YY(YY)
• MM-DD-YY(YY)
• YYYY-MM-DD
• DD-MMM-YY(YY)

Adding the day of the week is an option in some systems.
   

Regardless of the format selected, it must be communicated to all, understood and be consistent throughout an organization, especially global ones.

Controls should be established to ensure that the system's date and time are correct.  The ability to change the date or time should be limited to authorized personnel, and such personnel should be notified if a system date or time discrepancy is detected.²² 

Any changes to date or time should always be documented.²²

For an accurate time and date stamp, a network has a timeserver from which all the active equipment on the network is synchronized. In turn, the timeserver is synchronized with a time source typically a national observatory, a network time protocol (NTP) server or global positioning satellite (GPS).

One last discussion point about combined date and time stamps is the recorded time and the presented time. The system may record the time as UTC and the operating system may present that in local time. An alternative in some systems is to record two time stamps: local and UTC. You should understand how any system records date and time before purchase as this might have a bearing on validation and routine operation.

7. Predefined or configurable reasons for change

As seen in Table 2, regulations and regulatory guidance require a reason for change. EU GMP Chapter 4 requirement when making a change is a reason should be added as appropriate as this may be obvious if using paper, unlike GLP regulations. ^1,23

In contrast, Annex 11 focuses for computerized systems where a transcription error or change is not obvious; hence, the reason for change is mandatory.⁹ When working electronically a reason for any data change is critical for traceability, integrity and trustworthiness. In our view, the only configuration required for any audit trail is if it is silent (no reason for change required e.g., typically activities at a system level or method development activities) or a user is forced to add a reason for changes and modifications to data.

Software functionality should offer the ability for a laboratory to add predefined and context sensitive reasons for change. This has the advantage of speed and consistency of reasons for change, avoiding users typing the same reasons every time and if further input is required then a free text option could be used as well.  

Table 2: GxP requirements to reason for change.

Discipline	Requirement
GLP	Any change in entries shall be made so as not to obscure the original entry, shall indicate the reason for such change … 1
	8.3 5. … Reason for changes should be given.24
	6.6 … Reason for changes should be given and recorded14
GMP	9 … For change or deletion of GMP-relevant data the reason should be documented...9
	4.9 … Where appropriate, the reason for the alteration should be recorded23
GCP	6.2.1 … The audit trail should show … where applicable, why (reason for change)17
MHRA	6.13 … The reason for any change, should also be recorded12
PIC/S PI 041-1	9.6 … what action occurred, was changed, incl. old and new values; … why the action was taken (reason)13
WHO TRS 996 Annex 05	it should be possible to … and a reason for the change recorded where applicable25

8. Documenting an AT review

A digitalized laboratory must eliminate paper. To achieve this, any audit trail review must be documented within the computerized system by the reviewer. However, this is a major failing of audit trail system design as very few applications have this functionality, meaning that the review will be recorded on paper. We will return to this subject later in this listicle.

9. Archive and restore

The design of audit trail has significant impact on the ability of archiving and restoring e-records including all associated metadata. This topic will be discussed later in this listicle.

Procedure or procedures for audit trail review?

Let us assess these two PIC/S PI 041 statements¹³:

9.6 … determining which specific trails and which entries within trails are of significance for review …

9.8 … the regulated user should establish an SOP that describes in detail how to review audit trails …

Second person review is not just a review of audit trail entries. The process must review records from sample management to the reportable value to comply with GxP regulations (21 CFR 194 a (8),²⁶ Chapter 6.17²⁷). As Figure 4 depicts, in our view, it is more practical to establish a single overarching SOP (Standard Operating Procedure) to describe the principles of second person review and have separate specific SOPs for review of each application’s audit trail(s).

It is simply not practicable to have a single SOP that describes in detail how to review all audit trails. For example, a reviewer will need information to access the audit trail(s) in a system and then understand how to search the audit trail to find relevant change or deletion.⁹

A single SOP for all systems? Really? How big would the SOP be? Let us see…

Figure 4: Overview and options for audit trail review. Credit: Bob McDowall.

All audit trails are the same – except for the differences

Although GxP audit trail regulations are similar,^4,9,, all suppliers interpret these requirements differently and the audit trail design in each system varies greatly both in function and scope. 

Figure 4  shows four options for audit trail review. Each system and data audit trail review must be based upon detailed knowledge of the functionality within each computerized system. All examples below have audit trail functionality and are used to illustrate the differences in review. This justifies why there should be a separate SOP for each system. Each procedure will instruct a reviewer how to access the relevant audit trail and how a review will be conducted. 

The audit trail design and validation activities of each system will impact the extent routine audit trail review. PIC/S PI 041-1 (9.6.1) talks about:

      Review by exception – focusing on anomalous or unauthorised activities.¹³

Providing the system has been validated to demonstrate that the application identifies these issues and none has been identified when analyzing a series of samples, then no further review is required, except documenting the review electronically.

Note, in the four examples below no user role can delete data; this avoids the need for a reviewer to search for deletions. Only data changes are considered here.

• System 1: There is a single audit trail with no search function in the software. To avoid printing the audit trail, all relevant audit trail entries are exported as a CSV (Comma-Separated Values) file for searching using a spreadsheet or Tableau. This option creates an unsecured file that can be modified so that it must be securely handled. For standalone systems, this export can create further problems in that a USB (Universal Serial Bus) device may be required to transfer a file to a secure location on the network, creating a further data integrity problem. This is a nightmare, and the best solution is to upgrade or replace this system.
  
  
• System 2: Again, there is a single audit trail with no search function in the software and no ability to export the entries as a CSV file. In this situation, the audit trail entries for the batch are printed to PDF, which is given a unique file name and is part of the analytical batch record. Only one user role is capable of modifying data in this system. Using Control F, the PDF file is searched for such a user role. If none is found, the review stops. If such a user has logged on, all the applicable entries can be highlighted and reviewed to see if this user has made any changes to data or settings. The highlighted section will aid Quality Assurance (QA) oversight and inspections. Part of the system validation involves a user making changes that are identified by searching the PDF file printed from the audit trail. Although there is an option to print out the audit trail, the search would be manual, which is slow and error prone and not consistent with a digitalized laboratory.
  
  
• System 3: This system has a powerful search capability for audit trail entries. 
  Searches can be predefined for specific change events, and these are executed by the reviewer to see if any changes have been made and if they are appropriate. Search outputs are stored in the analysis folder of each the analytical run within the system. To help a review, a large screen is advised so the audit trail can be in one window and data/meta data in another.
  
  
• System 4: Here, there are two audit trails for system and data. All data audit trail entries are recorded in color: green for no data changes, yellow for data changes and red for data deletion. As stated above, no users, not even administrators, have data and meta data deletion privileges. The audit trails functionalities have been validated. Therefore, reviewer looks for yellow entries for the analysis. If none are seen, there is no further review needed. 
  
  A further extension of the functionality could be to have a statement that there are no data modifications. Again, this functionality needs to be validated to provide confidence in the correctness of identifying modified data. During a periodic review or data integrity audit, a focus would be to review runs with no changes to confirm continued correct operation of the application. This option is a review by exception that is a faster and simpler way of audit trail review.
  
  

Are you still convinced that a single SOP for audit trail review is adequate? 

As per GxP regulations and guidance documents, audit trail functionality for each system must be known, understood and validated by each regulated laboratory.

Frequency of audit trail review

Who should review audit trails?

As shown in Figure 4, audit trail review is a key part of second person review and must be performed by the originating department, either Analytical Development or Quality Control.^13,26 PIC/S PI 041-1 states in 9.6.1:

… This review should be performed by the originating department, and where necessary verified by the quality unit, e.g. during self-inspection or investigative activities.¹³

In GLP, QA needs to be provided with read-only access to e-records and corresponding data/meta data and have sufficient time to perform audit trail review.²⁹ This principle should be applied to any GxP discipline as part of quality oversight. In many cases there may be minimal QA knowledge of the system and the audit trail within it therefore the laboratory should provide an experienced user to operate the software under direction of the QA.

Documenting an audit trail review

It is a regulatory expectation to perform and document the data review as discussed earlier. One area that is typically missing from an application is a function to electronically record that a reviewer has reviewed the audit trail entries. In the absence of this feature, statements in the final report that audit trail entries have been reviewed followed by an electronic signature may or may not be acceptable to auditors and inspectors.

Table 3 summarizes the process and practical functional requirements for an effective audit trail review for batch release. There are no deletion privileges in the system and the storage location is enforced to avoid a reviewer searching for deleted or unofficial test data (see rows 2 and 3). Table 4 outlines the main areas for a periodic review for audit trails entries.³⁰

Suppliers take note; these are key requirements to save users time and effort.

Table 3: Application functions or settings to speed a second person review for release activities.

Activity or system function	Scope of work
1.      The performer completes the analysis	The performer has generated analytical data, interpreted them, performed any calculations and electronically signed the analysis report (Figure 4)
2.      Enforced data storage location	A reviewer does not need to search for unofficial testing
3.      No user has data deletion privileges	A reviewer does not need to search for deleted data
4.      Data changes highlighted in the audit trail allowing Review by Exception	Entries for the analysis presented in the audit trail with changes highlighted  Highlighted changes allows a reviewer to focus and check on anomalous or unauthorised activities13 rather than routine entries
5.      Software function to document review of the audit trail	After review of data and corresponding audit trail entries, the reviewer documents the review, which is recorded in the audit trail
6.      Document the conclusion of the review within the audit trail	A reviewer can incorporate the review conclusion e.g., positive statement regarding whether issues were found or not12 Option to record and resolve any problems found during the review allowing completion of the second person review
7.      Electronically sign analysis test report	Enforced workflow for e-signature when second person review completed

Table 4 : Possible system level audit trail checks during a data integrity audit or periodic review.

Periodic review task	Scope
User account management	Creating new users check with requests from the process owner Disabling users who have moved or left Disabling inactive accounts Modifying access privileges per role Reconcile list of users vs. those active in the system   Security and access control settings
Review change records	Change request reconciled with those made in the system Identify audit trail changes at system level and trace it back to the change request Review instrument configuration changes Review software configuration changes
Performance and reliability	Check any problems with instrument connection or outage Data buffering occurrences before transfer to the network storage (if configured)
Instrument problems	Cross check instrument problems with the log book to confirm problems are recorded correctly

Archive and restore of e-records including audit trail entries

Retention of complete raw data is required to reconstruct history of the course of any GxP activity (the who, what, when and why).^12–14,31 When audit trail entries are stored in the system that created them the structure of audit trail(s) within the software matters little. However, if disk capacity is an issue and data need to be archived to free up space, then how audit trails have been implemented may be an issue. 

The separation of system and data audit trails, as shown in Figure 3, allows more effective archive and restore. Here, we provide you with two scenarios to compare archiving approach of single and separate audit trails:

Scenario 1: A single audit trail

Here all actions within the system are recorded in one audit trail. This may have advantages of a big picture but can be difficult to see the activities surrounding a specific analysis unless there are effective search routines. However, there is a potential problem when it comes to archiving data outside of the system. All the analytical data files and associated metadata (data acquisition method, processing method and calculations, e-signed summary reports etc.) and pertinent audit trail entries must be collated into a file for archiving outside of the system. This should be achievable relatively easily.

The problem comes with a restore request because of a complaint, audit or inspection. The data can be restored but can the audit trail entries be interleaved back into the single audit trail of the application? Furthermore, can any reinterpretation of the data be captured? At the end of the work, can data be archived again with all the new data entries and audit trail entries? Consider the system's retention capability: some systems will start overwriting when they hit their storage limit, sometimes with no warning. This is the case with some analytical instruments with a so-called ring buffer.

If these questions cannot be answered during your evaluation before purchase, you may be storing up problems for the future.¹⁵

Scenario 2: System and data audit trails

In a system that separates audit trail entries between system and data events, an alternative archiving approach can be seen. 

Data level archiving: The structure of data package is based around a folder within the database where all data and metadata including the audit trail entries reside. As such, it is technically easier to collate all data elements into a single file, export from the system and store in a secure location. Restoring the archived data is easier than in scenario 1 as there is no need to interleave audit trail entries into a system level audit trail. Evaluate the archive and restore process before purchase.

System level audit trail archiving: Over time, a system level audit trail will keep growing. At some point, the entries will need to be archived but must remain readable and searchable by the application. Again, the archiving and readability of system audit trail entries need to be assured before purchase.

Possibility of creating a true copy as well as searching and sorting of the retained audit trails are serious areas that need to be questioned during system selection.

A word of warning, although the laboratory may spend time and effort on evaluation and selection of a system all the work may be undone by the Purchasing Department seeking to obtain a cheaper price by buying a different system. To avoid this, spend time with Purchasing explaining the rationale why a specific system is required.

Specification of audit trail requirements

As part of defining the intended use of any computerized system, functional requirements for audit trail(s) must be written, tested and verified as part of the validation efforts.

In March 2017, an initiative on “e-Compliance Requirements” was launched to help the regulated industry adequately define a set of e-compliance requirements for various types of computerized systems, including audit trails. The objective is to define requirements in a unified way to provide clear compliance expectations for system suppliers and developers. The e-Compliance Requirements Initiative (eCRI) is an international initiative and can be viewed at eCRI - e-Compliance Requirements Initiative - ecri. tech where the contact email will be found. The eCRI initiative covers not just audit trail requirements but also other compliance areas such as backup, user account management, etc.

Requirements need to be either testable or verifiable as written not as interpreted. An example of a bad and untestable requirement is the ever popular:

The system must comply with 21 CFR 11 (or Annex 11) regulations

A better approach is to take each regulatory requirement and break it down into testable portions. 

• What should an audit trail record when creating a record?
• How is a modification recorded by the audit trail?
  
  

We have not provided any specific detail as each system’s audit trail is different.  Intelligent modification of requirements is what is required: tailor your AT requirements to each system. Remember, a URS (User Requirements Specification) is a living document and specification requirements can be modified, deleted and added over the lifecycle.

Caution clowns at play!

The saying never assume malice when stupidity will suffice is tested to the limit in a recent example from a URS for an instrument purchase. The company (name not mentioned to protect the guilty) wrote this mandatory audit trail requirement in the URS:

… in exceptional cases, where the alteration of computer-generated audit trails is unavoidable … modifications (of the audit trail) must occur in a controlled way…

There are two issues here:

1. Which part of secure and computer-generated audit trail regulations in Annex 11 or 21 CFR 11 do these clowns not understand?
2. The “innocent” request to “alter” audit trail entries is a thinly disguised attempt at data falsification by design.
   
   

Any audit trail must be robust, computer generated and secure which implies that it must always be switched on^14,17,31 from installation onward. In addition, to ensure all GxP records and data are trustworthy and reliable NO CHANGES to any audit trail event must be allowed and No User should have the ability to modify audit trail events. Suppliers offering applications with these audit trail options should not be considered further. 

Another scenario may present itself, even if you have adequate audit trail functionality, some laboratories may still want to use procedural controls to record changes. This is not feasible for a digitalized laboratory and has a high potential for a regulatory citation.

Audit trail implications when interfacing systems

We have focused on ATs for a single system, but in a digitalized laboratory, applications will be interfaced for data transfer. Accordingly, the audit trails in both systems need to record the sequential export of data from one system and import or transfer into another by whichever means (e.g., secure file transfer or application programming interface). Where systems are sited in different time zones or locations, the validation needs to account for these differences to ensure trust in the systems and process.

Summary

An audit trail is critical in a digitalized regulated laboratory to ensure trustworthiness, reliability and integrity of electronic records. We reviewed GxP regulations and guidance documents to identify important functions of audit trails and their design. Although the regulations are consistent, implementation of audit trail(s) in an individual system varies greatly leading to the requirement to have separate SOPs for the effective review. System design can impact the ability to archive and restore audit trails as part of record retention.

Acknowledgements

We thank Monika Andraos, Akash Arya, Peter Baker, Markus Dathe, Eberhard Kwiatkowski, Yves Samson, Paul Smith, Christoph Tausch and Stefan Wurzer for their constructive review comments in preparing this listicle.