top of page

Audit trail review - how to do it properly?

Related to the data integrity fashion-wave, the audit trail review, as a process receives high attention.


It's obvious that 'the' audit trail has to be checked to prove there has been no adulteration of any GxP-data, but which is that audit trail that needs to be reviewed?


What is audit trail...really?

Again, let's start with the definition with collecting it from all major sources.


21 CFR Part 11 doesn't offer a clear definition for this term.


EU GMP Vol 4 Annex 11 offers...something (Section 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.'


We are luckier with the FDA Data integrity guidance:

'[...] audit trail means a secure, computer-generated, time-stamped electronic record that allows for reconstruction of the course of events relating to the creation, modification, or deletion of an electronic record. An audit trail is a chronology of the “who, what, when, and why” of a record. Electronic audit trails include those that track creation, modification, or deletion of data (such as processing parameters and results) and those that track actions at the record or system level (such as attempts to access the system or rename or delete a file).'


WHO and MHRA guidances share this definition:

'The audit trail is a form of metadata containing information associated with actions that relate to the creation, modification or deletion of GxP records. An audit trail provides for a secure recording of life cycle details such as creation, additions, deletions or alterations of information in a record, either paper or electronic, without obscuring or overwriting the original record. An audit trail facilitates the reconstruction of the history of such events relating to the record regardless of its medium, including the “who, what, when and why” of the action.'


Okay...so to sum up: if anything happens to collected/generated GxP-data, we need to have audit trail to capture it with attributability (who, when) and traceability (from what to what, and why).


But what to do if you feel your fancy system logs much more than that? you need to decide which type of logs you want to review (also with what frequency).


Audit trail connected to primary GMP-processes

When you perform a QC-test or manufacture a batch using a computerized system, the related audit trail review should be a part of your formal review process.

You should be after the following:

- any alteration of your raw data (typed-in numerical data used for data processing)

- any manual update on the processing (e.g., manual integration or re-calculation)

- and of course, all changes in any related master data, if any


Anyway, this kind of audit trail review should be a part of your everyday job.


Audit trail (?) connected to configuration changes

In your computerized system, there may be a log capturing the configuration changes. If you forbid to e.g., delete GxP-data from your system from configuration, you should either prove still you haven't deleted anything, OR you can prove from this log you didn't switch off this configuration element.

However, is it really audit trail? This is not strictly altering GxP-data, is it? Personnaly, I usually refer to these as 'system logs', just to separate them from 'the' audit trail discussed above.

I have to say though, it doesn't really matter how we call it, we need to have the review of it from time to time.

I think the best idea would be to incorporate this exercise in your computerized system's periodic review.

You can pre-define (in a procedure with short risk evaluation, also mentioned by Annex 11) what are the key activities in your log that should raise a red flag.


Other logs

You still might have a bunch of other logs: system status messages, etc. You don't need to evaluate these logs, you only need to proceduralize that these logs don't have any GMP-impact.

Regarding user login attempts (FDA data integrity guidance spells this out as audit trail), if you validate your system's security, you may not need to evaluate all unsuccessful login attempts, since, again, this doesn't have GMP impact.

2 views0 comments

Recent Posts

See All

Chromatographic columns and their qualifications

We have mentioned earlier the importance of choosing and testing of the column when developing a chromatographic method. But what should be the routine process for qualifying a newly purchased column,

Comments


bottom of page