Electronic Data Capture in Clinical Trials: The GCP Accountability the Vendor Cannot Take From You

At a glance

• Electronic data capture (EDC) is the system you collect trial data in (eCRFs, edit checks, queries, audit trail). It is not the same thing as source data, and buying a “Part 11 compliant” badge does not transfer your GCP obligations to the vendor.
• Under ICH E6(R3), FDA, and the EMA computerised systems guideline, the sponsor and investigator keep the accountability that matters: validation status, audit-trail review, access control, and source-data attribution stay with you even when the software is built and hosted by someone else.
• Validation is a sponsor responsibility. You may rely on a vendor’s validation documentation only after you have assessed it as adequate, and you must hold that evidence for inspection.
• Audit-trail review is a planned, risk-based, ongoing activity, not a one-time pre-lock chore. Regulators expect proactive review of critical data.
• Vendor due diligence is the real work: validation summary, audit-trail capability, hosting and data residency, export and migration, change control, and inspection history. Treat EDC selection as qualification, not procurement.
• A clean vendor label enables compliance; it never certifies it. The sponsor stays responsible.

If you run or are selecting an EDC, the single most expensive assumption you can make is that the vendor’s “GCP-compliant” or “Part 11 compliant” sticker covers your trial. It does not. The regulations that govern computerised systems in clinical research assign duties to the sponsor and the investigator, not to the software company. This article is a vendor-due-diligence and oversight playbook for the obligations you personally own in an inspection.

What EDC is, and what it is not

Electronic data capture is the tooling used to collect, query, and manage clinical trial data: electronic case report forms (eCRFs), automated edit checks, the query lifecycle, and the audit trail behind it all. It overlaps with but is distinct from eSource (data captured electronically at the point of origin) and source data itself.

The distinction is regulatory, not cosmetic. The EMA guideline defines source data as the original reported observation in a source document, and stresses that the location of source documents and the associated source data should be clearly identified at all points within the data capture process. When data is entered directly into the eCRF as source, that eCRF field becomes the source record, which changes who must review it and how fast. ICH E6(R3) §2.13 likewise directs the investigator to define what is considered a source record, the methods of data capture, and their location prior to starting the trial. EDC does not decide this for you; you decide it, and you document it.

The accountability that does not transfer to the vendor

This is the heart of the matter. ICH E6(R3) §3.1 is explicit that a sponsor may transfer trial-related activities to a service provider, but the ultimate responsibility for those activities, including reliability of the trial data, resides with the sponsor. The EMA computerised systems guideline draws the same line from the EU side: in its Annex 2 on validation, the responsible party may rely on validation documentation provided by the vendor only if they have assessed that documentation as adequate, and in any case the responsible party remains ultimately responsible for the validation of the systems used in the trial. On the investigator side, EMA §6.3 makes the investigator responsible for data entered into eCRFs and other data acquisition tools under their supervision.

FDA frames it in inspection terms. Regardless of how the data were originally generated, maintained, or retained, sponsors are responsible for ensuring the quality and integrity of the data they submit. The vendor can do the engineering; the accountability is yours.

Sponsor vs site vs vendor: who owns what

Obligation	Sponsor	Investigator/site	Vendor / IT service provider
Validation status of the system	Owns it (E6(R3) §3.x; EMA Annex 2)	Confirms fit-for-purpose for site-deployed systems	Performs/documents validation; sponsor must assess adequacy
Audit-trail review	Defines risk-based, ongoing review (FDA Q&A; EMA §6.2.2)	Reviews changes to own data	Provides reviewable, human-readable audit trail
Access provisioning	Maintains record of authorised users and permissions (E6(R3) §3.x)	Notifies sponsor when access must change/revoke; ensures attributable access	Enforces authority checks (Part 11 §11.10(g))
Source attribution / ALCOA+	Ensures data quality and integrity (FDA)	Defines source record and location pre-trial (E6(R3) §2.13)	Captures secure, time-stamped audit trail
Export / migration / archival	Owns validated transfer and retention	Retains essential records for the required period	Supplies export and migration capability

The pattern is consistent across all three frameworks: the vendor enables; the sponsor and site remain responsible.

Validation: what “validated EDC” means and what evidence you must hold

Under ICH E6(R3) §4.4, the responsible party is responsible for the validation status of the system throughout its life cycle, the approach to validation should be based on a risk assessment, and systems should be appropriately validated prior to use. The same section requires that subsequent changes to the system be validated based on risk under change control, and that the responsible party ensure systems are validated as fit for purpose, including those developed by other parties, with validation documentation maintained and retained.

FDA’s 2024 guidance endorses a risk-based approach: regulated entities should validate the electronic systems they deploy based on a justified, documented risk assessment, and validation should be applied to system functionality, protocol-specific configurations, customizations, data transfers, and interfaces. Critically, when validation is performed by an IT service provider, FDA recommends the deploying entity review the provider’s documentation (development and management processes, validation processes, functional testing, change control) to evaluate fit for purpose. And it is the responsibility of the regulated entity to ensure such documentation is available if requested during an inspection, including documentation created and maintained by the IT service provider.

So “validated EDC” is not a state the vendor confers on you. It is a body of evidence you assemble and hold: your risk assessment, the validation summary (vendor-supplied plus your own assessment), configuration and customization testing for your protocol, and the change-control record across the life cycle.

ALCOA+ and the audit trail: is your EDC data source data?

Both ICH E6(R3) §2.13 and the EMA guideline anchor data integrity in the ALCOA principles: source records and data should be attributable, legible, contemporaneous, original, accurate, and complete (EMA extends this to ALCOA++ with consistent, enduring, available, and traceable). When EDC holds source data, those attributes apply to the EDC record directly.

ALCOA+ x EDC mapping

Attribute	How EDC satisfies it	Where it is at risk
Attributable	Per-user accounts; audit trail names who entered/changed (Part 11 §11.10(e))	Shared logins; generic accounts
Legible / human-readable	Audit trail reviewable in human-readable form (EMA §6.2.1)	Cryptic codes; non-exportable trails
Contemporaneous	Computer-generated time stamps (Part 11 §11.10(e))	Backdating; local-memory delays
Original	First permanent capture defined as source (EMA §4.x)	Undocumented transcription steps
Accurate	Validated edit checks; change control	Unvalidated configuration changes
Complete	Audit trail captures create/modify/delete	Disabled or modifiable trails

The audit trail itself carries hard requirements. ICH E6(R3) §4.5 states that in computerised systems the audit trail should be secure, computer-generated, and time stamped, and should show activities, initial entry, and changes by whom, when, and where applicable why. 21 CFR Part 11 §11.10(e) requires secure, computer-generated, time-stamped audit trails that independently record operator entries and actions creating, modifying, or deleting records, and that record changes not obscure previously recorded information. FDA’s 2024 guidance adds that audit trails must capture all changes, the individuals making them, and the date and time, and should be protected from modification and from being disabled.

On who reviews the trail and how often, note a deliberate emphasis difference worth stating plainly rather than smoothing over. FDA’s 2024 Q&A says periodic review of the audit trail may be helpful, with the decision to review based on a risk assessment of the investigation. The EMA guideline §6.2.2 is firmer: procedures for risk-based trial-specific audit-trail reviews should be in place, and review should be proactive and ongoing unless justified. Both are risk-based, but the EMA default is active and continuous while FDA frames review as a risk-driven option. If you operate under both, plan to the stricter (EMA) expectation. ICH E6(R3) §4.2.3 sits alongside these, requiring that procedures for review of trial-specific data, audit trails, and other relevant metadata be a planned, risk-based activity.

Access control, e-signatures, and Part 11 in practice

Part 11 is not a vendor sticker; it is a set of controls you must operate. 21 CFR Part 11 §11.10(d) requires limiting system access to authorized individuals, and §11.10(g) requires authority checks so that only authorized individuals can use the system, sign a record, or alter a record. ICH E6(R3) §4.5.8 reinforces this from the GCP side: access controls are integral to limiting system access to authorised users and ensuring attributability to an individual, with permissions assigned based on a user’s duties, functions, and blinding arrangements. On the site side, ICH E6(R3) §2.13 requires the investigator to ensure appropriate individuals have secure and attributable access and to notify the sponsor when permissions need to change or be revoked.

For signatures, 21 CFR Part 11 §11.50 requires that signed electronic records clearly indicate the printed name of the signer, the date and time of signing, and the meaning associated with the signature (review, approval, responsibility, or authorship). 21 CFR Part 11 §11.200 requires that each electronic signature be unique to one individual and not reused or reassigned. These are obligations on how you configure and operate the system, not capabilities you can outsource and forget.

Selecting EDC software: a vendor qualification and due-diligence checklist

Selection is qualification. Treat it the way you would qualify any service provider handling critical data:

• Validation summary and package: does the vendor supply a validation summary you can assess as adequate (EMA Annex 2), covering development processes, functional testing, and change control (FDA Q7)? You will need to document your own assessment.
• Audit-trail capability: is the trail secure, computer-generated, time-stamped, human-readable, exportable, and impossible for normal users to disable (Part 11 §11.10(e); EMA §6.2.1)?
• Access control and authority checks: can you enforce unique per-user accounts, role-based permissions, and signature controls (Part 11 §11.10(d),(g), §11.200)?
• Hosting and data residency: where does the data live, and can your investigators, monitors, auditors, and inspectors get the access ICH E6(R3) requires?
• Export, migration, and archival: can you export data plus metadata and audit trail, and migrate at lock without loss? ICH E6(R3) §4.2.5 requires validated processes so that electronic data and relevant metadata transferred between systems retains integrity, with reconciliation to avoid data loss.
• Change control and inspection history: how are upgrades and patches validated, and what is the provider’s track record? FDA expects changes to be evaluated and validated across the life cycle.

Owning your data at lock and beyond

Your obligation does not end when the vendor relationship does. ICH E6(R3) §4.2.5 requires validated transfer and migration processes with documented traceability and reconciliation. FDA’s 2024 guidance describes certified copies: if you retain a copy in place of an original record, it should be a certified copy that includes the date and time the copy was created, and FDA inspection copies should include metadata and audit-trail information. The practical test: at database lock and through the retention period, can you produce the data, its metadata, and its audit trail in a usable form without depending on a contract that may have lapsed?

What inspectors actually ask for

FDA’s 2024 guidance is unusually concrete about inspection focus for systems within Part 11 scope: data collection, handling, security, and management procedures; the full system life cycle from design to decommissioning; processes ensuring records needed to reconstruct the investigation are not altered in value or meaning; processes ensuring only authorized individuals have appropriate access; change control and any changes made in use; contracts with IT service providers detailing their functions and responsibilities; and corrective and preventive actions for errors affecting data integrity. As part of an inspection, FDA may request all records and data needed to reconstruct the investigation, including associated metadata and audit trails.

Where teams get it wrong

• Treating “Part 11 compliant” as a finish line. It is a starting set of controls you must operate and evidence; the sponsor still owns data quality and integrity (FDA).
• Outsourcing validation in their heads. The vendor can validate, but you must assess that documentation as adequate and remain ultimately responsible (EMA Annex 2; ICH E6(R3) §4.4).
• Reviewing the audit trail once, just before lock. EMA §6.2.2 expects proactive, ongoing review of critical data; a single pre-lock pass undermines its purpose.
• Sloppy access hygiene. Shared logins and stale permissions break attributability and authority checks (Part 11 §11.10(d),(g); ICH E6(R3) §4.5.8) and are common findings.
• Not owning the exit. No validated export and migration plan means you cannot reconstruct the trial at lock (ICH E6(R3) §4.2.5).

The throughline across ICH E6(R3), FDA, and EMA is the same: software and service providers enable compliance, but the sponsor and investigator remain responsible for it. Select and oversee your EDC accordingly. This article pairs naturally with companion pieces on data integrity and ALCOA+, 21 CFR Part 11 in clinical trials, computerised system validation, audit-trail review, and eSource and source data.

Sources

• ICH E6(R3) Good Clinical Practice, version r3 — https://www.ich.org/page/efficacy-guidelines
• FDA Guidance: Electronic Systems, Electronic Records, and Electronic Signatures in Clinical Investigations Q&A — version 2024
• 21 CFR Part 11 Electronic Records; Electronic Signatures, version 2026-04
• EMA Guideline on Computerised Systems and Electronic Data in Clinical Trials, version 2023 — https://www.ema.europa.eu/en/documents/regulatory-procedural-guideline/guideline-computerised-systems-and-electronic-data-clinical-trials_en.pdf