PI oversight in an eSource audit trail looks like three kinds of entry: the attribution behind every value, the review events showing that the investigator opened the record, and the endorsement events where the investigator signed it. An audit trail holding only the first of those three is a record of data entry. It evidences no oversight.
This guide sits in our series on eSource in clinical trials. It covers the entries that evidence oversight, what a principal investigator reviews and how often, what makes an endorsement defensible, how the trail proves delegation was in place on a given date, and the requests an inspector makes. The duties themselves come from ICH E6(R3) section 2.
Oversight is an entry, not an intention.
Which Entries in the Audit Trail Evidence Investigator Oversight?
Three entry types carry the evidence. Each one answers a different question an inspector puts to the record, and each one fails in a way the trail displays plainly.
| Entry type | What the audit trail records | How its absence reads at inspection |
| Attribution | The account that created or changed each value, with date and time | A value nobody owns, or one owned by an account outside the delegation log |
| Review | The investigator account opening the record, with the date of access | A signature with no evidence that the data was ever read |
| Endorsement | The investigator signature, its meaning, its date and the data version it covers | Data reported to the sponsor that the investigator never adopted |
| Post-signature change | Any edit made after endorsement, with reason and re-signature | A signature that covers a version of the data no longer in the system |
ICH E6(R3) places the duty behind these entries in two clauses. Section 2.3.1 keeps ultimate responsibility with the investigator and asks for oversight proportionate to the importance of the data. Section 2.12.5 asks the investigator to ensure the accuracy, completeness, legibility and timeliness of the data reported to the sponsor, and to review and endorse that data at important milestones.

Our guide to who uses eSource, from research nurse to sponsor sets out what each of the seven roles does with the record. This guide takes the investigator’s part of it and reads it from the trail. The endorsement itself covers reported data, and our guide to where source data ends and the CRF begins sets out which record that is.
What Does the Investigator Actually Review, and How Often?
The investigator reviews the data whose importance justifies the review, at a frequency the study’s risk assessment sets. ICH E6(R3) section 2.3.1 fixes that principle by making the level of oversight proportionate to the importance of the data. The MHRA applies the same logic to the audit trail itself.
The MHRA GXP data integrity guidance states at section 6.13 that routine data review should include a documented audit trail review where a risk assessment determines it. The MHRA’s GCP perspective on that guidance adds two practical points: the need for an audit trail review follows from the trial’s own risk assessment, and the guidance creates no requirement for a standalone audit trail review SOP.
- The risk assessment names the critical data points at study set-up, which tells the investigator what to read rather than leaving it to judgement each week.
- Eligibility, primary endpoint values and safety data carry a review at every occurrence, because a late error in any of them affects a participant or the analysis.
- Administrative and non-critical fields carry a sampled review, which keeps the reviewing effort proportionate to what an error would cost.
- Corrections made after a monitor query carry their own review, because the reason for change is the part an inspector tests.
- The review cadence sits in the study risk assessment, so the record of the decision survives a change of investigator.

Also Read: Does eSource Meet ALCOA+? The Attributes Inspectors Check
What Makes an Investigator Endorsement Defensible?
A defensible endorsement states what was signed, by whom, when, and what the signature means. The system supplies four of those elements and the site supplies the fifth.
- The signature binds to a named account under sole user control, which keeps the endorsement attributable to one person.
- The system applies its own date and time, which removes any argument about when the review happened.
- The signature carries its meaning in words, such as review, approval or authorship, so the record states what the investigator adopted.
- The signature attaches to a defined set of data, which allows an inspector to see the scope of the endorsement.
- Any change made after signature invalidates it and requires a fresh one, which keeps the signed version and the live version the same.
Timing turns a valid signature into a weak one. ICH E6(R3) section 2.12.5 asks for endorsement at important milestones, and a study that defines those milestones in advance produces signatures spread across the trial. A study that leaves them undefined produces a run of signatures dated in the final week before database lock. Both patterns are visible in one query of the trail.
How Does the Audit Trail Prove Delegation Was in Place?
The trail proves delegation by reconstruction on a past date. ICH E6(R3) section 2.3.3 asks the investigator to maintain a record of the persons to whom trial-related activities were delegated. The MHRA is direct about the investigator’s part in granting the access itself, stating in its guidance on electronic systems used at sites that the investigator should authorise the access of any person assigned editing rights and maintain oversight of it.
The test runs on a single date chosen by the inspector. Three questions decide whether the record holds.
- Which accounts held write access to this study on that date, according to the system’s own user history?
- Which people held a delegated task covering that activity on that date, according to the delegation of authority record?
- Which of those people had completed protocol and system training before that date, according to the training file?

Three answers that agree close the question in minutes. Any mismatch turns one date into a portfolio-wide request, because an inspector who finds a gap on one date tests the next study for the same condition.
Where Does PI Oversight Break in Practice?
Oversight fails in five recognisable ways, and each one is a process condition rather than a personal lapse. The audit trail shows each failure in a different shape.
| Failure | What the audit trail shows | Condition behind it |
| Bulk sign-off | Hundreds of endorsements within a few minutes on one date | Milestones for endorsement were never defined in the protocol or study plan |
| Signature without review | An endorsement with no prior read event on the same record | The system offers a sign action that does not require the record to be opened |
| Shared account | Investigator entries made while the investigator was on leave | Cover arrangements were handled by password sharing rather than by a second delegated account |
| Silent post-signature edit | A change dated after the endorsement, with the signature still showing as current | The system does not invalidate a signature when the signed data changes |
| Retrospective delegation | Entries by an account whose delegation log entry is dated later | Access provisioning runs ahead of the delegation sign-off step |
Consider a hypothetical respiratory study at an NHS trust. The principal investigator endorses 412 visit records on 14 August, all between 16:41 and 16:58, four days before database lock. The endorsements are valid signatures on valid data. The trail also shows that 38 of those records were corrected in July, that the investigator opened none of them, and that the protocol never named a milestone for endorsement. The finding here is the absence of a defined review point, and the fix sits in the study plan rather than in the investigator’s diary.
Also Read: What Is a Source Data Location Log and Who Signs It Off?
What Does an Inspector Ask to See?
An inspector works from the record outward. The sequence below follows the order the evidence is usually requested in, and each step depends on the one before it.
- The study risk assessment, to see which data points were designated critical and what review they attract.
- A full audit trail export for one participant, to follow every entry, correction and signature on one timeline.
- The user access history for the study, to establish which accounts held which permissions on the dates in question.
- The delegation log and training records, to place each account against an authorised person.
- The documented audit trail review, which the MHRA guidance expects to carry a positive statement of the findings and the reviewer’s signature.
- Evidence that the reviewer held sufficient knowledge and system access to perform the review, as section 6.13 of the same guidance requires.
The procedures behind steps five and six belong to the site’s quality management system, which holds the SOPs for data review, periodic access review and system validation. Monitoring of the same record follows a separate route through the site’s clinical trial management system.
An investigator can only oversee a record the system lets them read on their own terms. AQ is launching eSource soon as part of the AQ platform, so that the delegation record, the access it grants and the investigator’s review of the resulting entries sit on one footing. Book a live demo to see the AQ platform today.
