Study guide
12.2 Computerised Systems, Data Governance & Audit Trails (ICH E6(R3) Annex 1 §4)
ACRP Certified Professional ACRP-CP
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: GCP Principles, Roles & Delegation
1.1 The Eleven ICH E6(R3) Principles of GCP & Guideline Structure 1.2 Sponsor & Investigator Responsibilities and Delegation of Authority 1.3 Staff Training, Qualifications & Delegation of Authority Log (DOAL) 1.4 CRO Oversight, Vendor Management & Transfer of Regulatory Obligations (TORO)
2 Chapter 2: Essential Records, Source Documentation & Data Confidentiality
2.1 Essential Records Before, During and After the Trial (ICH E6(R3) Appendix C) 2.2 Trial Master File (TMF) and Investigator Site File (ISF) Structure & Inspection Readiness 2.3 Source Documentation, ALCOAC Principles & Medical Record Standards 2.4 Confidentiality, Privacy & Protection of Participant Personal Information
3 Chapter 3: Monitoring, Quality Management & Audits
3.1 Risk-Based Quality Management (RBQM) & Quality Management Systems (QMS) 3.2 Monitoring Visit Types: Site Selection, SIV, IMV, and Close-Out 3.3 Risk-Based Monitoring (RBM), Centralized Monitoring & Source Data Verification (SDV vs SDR) 3.4 Quality Audits, Regulatory Inspections, Non-Compliance & Root Cause Analysis / CAPA
4 Chapter 4: Site Feasibility, Start-Up, Facilities & Laboratory Operations
4.1 Site Feasibility Assessment, Capability Analysis & Investigator Selection 4.2 Contractual Agreements: Clinical Trial Agreements, Budgets, Indemnification & Financial Arrangements 4.3 Site Initiation Preparation, System Access & Regulatory Greenlight 4.4 Protocol Review, Operational Feasibility & Institutional Approvals 4.5 Site Facilities, Equipment Maintenance, Calibration & Trial Supplies 4.6 Biological Samples & Hazardous Goods: Collection, Storage, Disposal & Shipment
5 Chapter 5: Subject Recruitment, Retention & Study Visits
5.1 Subject Recruitment Strategies, Advertising Guidelines & Ethical Constraints 5.2 Screening, Eligibility Verification & Inclusion/Exclusion Adherence 5.3 Subject Retention, Compliance, Visit Scheduling & Protocol Window Management 5.4 Managing Lost to Follow-Up, Subject Withdrawal & Early Termination Procedures
6 Chapter 6: Protocol Compliance, Deviations & Site Close-Out
6.1 Protocol Compliance, Waivers vs. Violations & Deviation Management 6.2 Investigational Site Close-Out Activities & Final Reconciliations 6.3 Record Retention, Archiving Requirements & Post-Trial Responsibilities
7 Chapter 7: Research Ethics, Vulnerable Populations & Research Integrity
7.1 Historical Milestones: Nuremberg Code, Belmont Report & Declaration of Helsinki 7.2 Ethical Principles: Beneficence, Non-Maleficence, Autonomy, Justice & Equipoise 7.3 Vulnerable Populations (Pediatrics, Pregnant Women, Prisoners, Cognitively Impaired, Economically Disadvantaged) 7.4 Conflict of Interest, Research Misconduct & Fraud in Clinical Research
8 Chapter 8: Informed Consent & Institutional Review Boards (IRB/IEC)
8.1 Informed Consent Elements, Process & Ongoing Consent / Re-Consent Requirements 8.2 Assent in Minors & Legally Acceptable Representative (LAR) Requirements 8.3 IRB/IEC Composition, Functions, Review Types (Full, Expedited, Exempt) & Continuing Review
9 Chapter 9: Safety Reporting & Adverse Event Management (ICH E2A)
9.1 Adverse Events (AE) vs. Adverse Drug Reactions (ADR) & Serious Adverse Events (SAE) Definitions 9.2 Causality Assessment, Expectedness, Reference Safety Information (RSI) & SUSARs 9.3 Expedited Reporting Timelines (7-day fatal/life-threatening, 15-day other serious) & Periodic Safety Updates (DSUR)
10 Chapter 10: Investigational Product (IP) Management & Accountability
10.1 Investigational Product Lifecycle, Labeling, Packaging & Blinding Procedures 10.2 IP Shipping, Receipt, Temperature Monitoring, Excursion Handling & Chain of Custody 10.3 IP Storage, Dispensing, Accountability Logs & Destruction/Return Procedures 10.4 Emergency Unblinding (Code Breaking) Protocols & Subject Safety Procedures
11 Chapter 11: Regulatory Frameworks, Submissions & Product Reference Information
11.1 Stakeholders, Regulatory Institutions & Global Frameworks in Clinical Research 11.2 Protocol Submission, Approval & Amendment Processes 11.3 Investigator's Brochure, Instructions for Use & Reference Product Information 11.4 Regulatory Reporting Requirements Before and After Marketing Authorisation
12 Chapter 12: Clinical Data Management, EDC & Electronic Records
12.1 Electronic Data Capture (EDC), eCRF Design & Clinical Data Management Systems (CDMS) 12.2 Computerised Systems, Data Governance & Audit Trails (ICH E6(R3) Annex 1 §4) 12.3 Data Validation, Edit Checks, Discrepancy / Query Management & Resolution 12.4 Medical Coding (MedDRA, WHO Drug), SAE Reconciliation, Data Transfer & Database Lock
13 Chapter 13: Trial Design, Biostatistics, Data Monitoring & Transparency
13.1 Phases of Clinical Research (Phase 0, I, II, III, IV) & Translational Medicine 13.2 Study Designs: Parallel, Crossover, Factorial, Adaptive & Non-Inferiority / Equivalence 13.3 Randomization Schemes, Stratification, Blinding Methods & Minimizing Bias 13.4 Endpoints (Primary, Secondary, Surrogate, Composite), Sample Size & Biostatistical Concepts (p-values, CI, ITT vs PP) 13.5 Interim Analyses, DSMB/IDMC Oversight & Efficacy and Safety Evaluation Milestones 13.6 Trial Registration, Results Transparency & Communicating Results to Participants
12.2 Computerised Systems, Data Governance & Audit Trails (ICH E6(R3) Annex 1 §4)
Key Takeaways Explain This Topic AI
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.
Last updated: August 2026
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.