12.2 Computerised Systems, Data Governance & Audit Trails (ICH E6(R3) Annex 1 §4)
Key Takeaways
- ICH E6(R3) gives Data Governance its own annex section shared by investigator and sponsor, covering the full data life cycle and the computerised systems that carry it.
- Annex 1 section 4.2.2(b) requires that audit trails, reports and logs are not disabled, and that audit trails are not modified except in rare justified circumstances with a log of the action.
- Validation is risk-based: Annex 1 section 4.3.4 bases the approach on the intended use of the system, the importance of the data it holds, and its potential to affect participant safety and result reliability.
- Data corrections must be attributed to the person or system making them, justified, supported by source records around the time of original entry, and made in a timely manner.
- The automatic capture of date and time of data entries or transfers must be unambiguous — coordinated universal time is the example the guideline gives.
Computerised Systems, Data Governance & Audit Trails
Quick Reference: ICH E6(R2) scattered electronic-records expectations across the investigator and sponsor sections. E6(R3) Annex 1 section 4, "Data Governance – Investigator and Sponsor", gathers them into one shared section. Its opening states the purpose plainly: appropriate management of data integrity, traceability and security, thereby allowing the accurate reporting, verification and interpretation of clinical trial information.
A note on national electronic-records rules
You will meet 21 CFR Part 11 in the United States and comparable annexes elsewhere, and your organisation's system validation documentation will be written against them. ACRP states that the ACRP-CP exam is referenced only to ICH guidelines and that no country-specific framework is tested. Everything below is therefore framed on E6(R3) Annex 1 section 4, which is where the exam's answers live. The underlying controls — audit trails, validation, unique accounts, attributable corrections — are the same controls; only the citation changes.
The data life cycle (Annex 1 4.2)
Procedures must cover the full life cycle. Eight elements, each examinable:
| § | Element | The requirement in one line |
|---|---|---|
| 4.2.1 | Data capture | Where paper or electronic health record data are manually transcribed into a computerised system, the need for and extent of verification takes the criticality of the data into account; acquired data must be accompanied by relevant metadata; automated validation checks at capture are considered based on risk, and their implementation is controlled and documented |
| 4.2.2 | Metadata, including audit trails | See below — the most heavily tested element |
| 4.2.3 | Review of data and metadata | Review of data, audit trails and other metadata must be a planned activity, risk-based, adapted to the trial and adjusted based on experience during the trial |
| 4.2.4 | Data corrections | Corrections must be attributed to the person or system making them, justified, supported by source records around the time of original entry, and performed in a timely manner |
| 4.2.5 | Transfer, exchange and migration | Validated or otherwise appropriate processes such as reconciliation preserve integrity and confidentiality; the process is documented for traceability; reconciliation avoids data loss and unintended modification |
| 4.2.6 | Finalisation prior to analysis | Data of sufficient quality for interim and final analysis are defined and achieved through timely capture, verification, validation, review and rectification of errors |
| 4.2.7 | Retention and access | Records retained securely and accessibly for the required period |
| 4.2.8 | Destruction | Controlled, documented destruction when retention ends |
Audit trails and metadata (4.2.2) in detail
For data of higher criticality, the responsible party's approach must entail:
- (a)(i) Systems maintain logs of user account creation, changes to user roles and permissions, and user access
- (a)(ii) Systems permit data changes such that the initial entry and any subsequent change or deletion are documented, including, where appropriate, the reason for the change
- (a)(iii) Systems record and maintain workflow actions, not only direct data entry and changes
- (b) Audit trails, reports and logs are not disabled. They "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"
- (c) Audit trails and logs must be interpretable and able to support review — an export nobody can read does not satisfy the requirement
- (d) Automatic capture of date and time of entries or transfers must be unambiguous, with coordinated universal time given as the example
- (e) The responsible party determines which metadata require review and retention
Exam Watchout: The one legitimate reason the guideline gives for modifying an audit trail is the inadvertent inclusion of a participant's personal information — and even then a log of the action and its justification is required. Any item offering "the audit trail was corrected because it contained an error" or "audit trail was switched off during data migration" is wrong.
Safeguarding blinding within data governance (Annex 1 4.1)
Blinding is treated as a data governance problem, not only an operational one:
- In blinded trials, sponsor staff and service providers who operate the trial and interact directly or indirectly with site staff should not have access to unblinding information, except where the trial design justifies it — the guideline's example is the use of unblinded monitors.
- Where such access exists, mitigation strategies must reduce the risk of inadvertently unblinding site staff.
- The potential for unblinding must be part of the risk assessment of a blinded trial.
- Any planned or unplanned unblinding, including inadvertent or emergency unblinding, must be documented, and any unplanned unblinding assessed for its impact on trial results, with action taken as appropriate.
Computerised systems (Annex 1 4.3)
Eight sub-sections, and the structure itself is worth memorising because items are often built from one of them:
| § | Topic | Key expectation |
|---|---|---|
| 4.3.1 | Procedures for use | Written procedures govern how systems are used in the trial |
| 4.3.2 | Training | Users are trained before access; training is documented |
| 4.3.3 | Security | Security managed throughout the data life cycle; controls include user management and ongoing measures to prevent, detect and mitigate breaches — authentication and password management, firewalls, antivirus, security patching, system monitoring, penetration testing; adequate backup maintained |
| 4.3.4 | Validation | Risk-based. The approach considers the intended use of the system, the purpose and importance of the data it holds, and the system's potential to affect participants' well-being, rights and safety and the reliability of results. Validation demonstrates conformance to established requirements for completeness, accuracy and reliability, and performance consistent with intended purpose |
| 4.3.5 | System release | Controlled release into use, including trial-specific configuration |
| 4.3.6 | System failure | Planned handling of outages, with continuity arrangements and reconciliation on recovery |
| 4.3.7 | Technical support | Available to users, particularly where participants use the technology |
| 4.3.8 | User management | Accounts created, roles assigned, permissions reviewed and access revoked in line with actual role |
Trial-specific systems, including updates resulting from protocol amendments, fall inside these controls — a point that catches sites out when an amendment changes an eCRF and the change is treated as a configuration tweak rather than a controlled release.
Risk-based validation, concretely
Low criticality ─────────────────► High criticality
Example system: Site training tracker EDC holding the primary endpoint
Meeting scheduler IRT performing randomisation
ePRO capturing the primary outcome
Validation: Lighter, documented Full documented validation:
assessment proportionate requirements → specification →
to intended use IQ/OQ/PQ → traceability →
summary report → change control
The judgement is not "is it a big system?" but "what would go wrong for participants or for the reliability of the results if it behaved incorrectly?"
What this means at a site
| Requirement | What a monitor or inspector looks for |
|---|---|
| Unique named accounts | No shared logins. A shared "site coordinator" account destroys attributability under 4.2.2 and 4.2.4 |
| Timely access revocation | Leavers deactivated promptly; a periodic access review record |
| Delegation alignment | Everyone with a system account is on the delegation record for the activity the account permits |
| Correct system clocks | Unambiguous date and time per 4.2.2(d) |
| Attributable, justified corrections | Reasons for change recorded; the correction traceable to a source record from around the time of original entry |
| Downtime handling | Documented paper backup procedure and reconciliation once the system returns (4.3.6) |
| Training before access | Documented, and repeated when the system materially changes (4.3.2) |
Exam Watchout: A correction made "to match the source" without a reason for change is still incomplete. Section 4.2.4 requires corrections to be attributed, justified, supported by source records around the time of the original entry, and timely. A correction entered nine months after the visit, justified only as "data entry error", satisfies neither timeliness nor the source-support requirement.
Realistic exam scenario
Scenario: A site uses one shared login, "STUDY-SITE-07", for its electronic data capture system, because the sponsor issued only one account at initiation. Preparing for a monitoring visit, the coordinator makes 240 data changes in one afternoon, entering "clarification" as the reason for each. During the same period the site's laboratory results are migrated from a retiring analyser system into the EDC; the vendor performing the migration disables the audit trail for four hours "to avoid noise in the log", then re-enables it.
Evaluation — four distinct findings:
- The shared account defeats attributability. Section 4.2.2(a)(i) requires logs of user account creation, role changes and access, and 4.2.4 requires corrections to be attributed to the person making them. With one account, no change can be attributed to an individual. That the sponsor issued only one account is a sponsor oversight failure under Principle 10.3, not a defence for the site.
- 240 bulk changes immediately before a monitoring visit, all with a single generic reason, fail 4.2.4 on justification, on support by source records around the time of original entry, and on timeliness. The pattern is also a classic data integrity signal of the kind discussed in section 7.4.
- Disabling the audit trail during migration directly breaches 4.2.2(b), which requires that audit trails, reports and logs are not disabled. The only contemplated modification is for inadvertently captured personal information, with a log and justification — "reducing noise" is not that.
- The migration itself engages 4.2.5: validated or otherwise appropriate processes, including reconciliation, must preserve integrity and confidentiality, and the migration must be documented to ensure traceability. Performing it with the audit trail off removes the very evidence that integrity was preserved.
Correct actions: stop using the shared account and require the sponsor to issue individual named accounts aligned to the delegation record; document the period during which attribution is not possible and assess its impact on the reliability of the affected data; review the 240 changes against source records and re-document reasons for change where the source supports it, treating any that cannot be substantiated as a data integrity issue for escalation; obtain the vendor's migration documentation and reconciliation evidence and assess what the disabled interval means for traceability; report the audit trail disabling to the sponsor, which should evaluate it under Annex 1 section 3.12 as potential noncompliance affecting the reliability of trial results; and raise CAPAs covering account provisioning, query-response timeliness and vendor change control.
A vendor proposes disabling the audit trail in the electronic data capture system for six hours during a planned data migration, to keep the log readable. Is this acceptable under ICH E6(R3)?
Under ICH E6(R3) Annex 1 section 4.3.4, what determines how extensively a computerised system used in a trial must be validated?
Nine months after a visit, a coordinator changes a recorded systolic blood pressure in the electronic data capture system and enters "data entry error" as the reason for change. Which requirement is not satisfied?