Electronic Data Capture Software: The Four GCP and Part 11 Obligations That Decide Whether 'Compliant' Survives an Inspection

At a glance

• “Part 11 compliant” is a vendor product claim. Inspection-ready is a property of your deployment: the validated, access-controlled, audit-trail-reviewed instance you actually ran the trial on.
• Every EDC, regardless of brand, has to satisfy four obligations: computerised-system validation, ALCOA+ audit trails, access control and electronic signatures, and sponsor data-integrity oversight.
• The validation responsibility does not move when the system is vendor-hosted. ICH E6(R3) puts validation status on the responsible party for the system’s whole life cycle, and FDA’s 2024 guidance still expects the sponsor to hold the validation documentation even when an IT service provider performed the work.
• Audit-trail review, not audit-trail existence, is where teams get written up. The audit trail being present is table stakes; a documented, risk-based review of it is the expectation.
• Evaluate any EDC against the obligations below, not a feature checklist. We close with a sponsor-vs-vendor responsibility split and a vendor-neutral evaluation checklist you can run before you sign.

Most EDC evaluations go wrong in the same place: the demo. A polished product tour shows edit checks firing, queries routing, and a slick audit-trail viewer, and the room concludes the system is “compliant.” Then an inspector asks for the validation package for your configuration, the audit-trail review records for your study, and the user-access log for your unblinded data, and the demo’s gloss evaporates. A “compliant” label survives a sales call. It is the deployment, not the product, that has to survive an inspection.

This guide is for clinical data managers, clinical-ops, and QA/regulatory leads who will be held accountable for an EDC choice they may not have validated. It is deliberately vendor-neutral. We do not rank products and we do not vouch for any named system’s compliance, because compliance is not a property a logo can carry for you. Software enables compliance; under ICH E6(R3) and FDA regulation the sponsor stays responsible. What we give you instead is the evaluation framework the marketing pages omit: the four obligations every EDC must satisfy, mapped to the provisions that demand them.

What an EDC actually is

An electronic data capture system is the durable repository and toolset a trial uses to collect, query, and lock clinical data: electronic case report forms (eCRFs) for entry, automated edit checks, query management, user accounts, and an audit trail. FDA’s 2024 guidance defines EDC systems plainly as electronic systems designed to collect, manage, and store clinical investigation data in electronic format, and it draws an important boundary: source systems such as electronic health records are not assessed for Part 11 compliance, but once data enters the sponsor’s EDC system, FDA intends to assess compliance with Part 11. That boundary is where your obligations begin.

ICH E6(R3) §9.2 frames the same idea at the principle level: systems and processes that aid data capture, management, and analysis should be fit for purpose, should capture the data required by the protocol, and should be implemented proportionate to the risks to participants and the importance of the data. “Fit for purpose,” not “feature-rich,” is the standard. Everything below is how you demonstrate it.

‘Compliant’ is a deployment, not a product label

A vendor’s “Part 11 compliant” claim tells you the product can be configured and operated to meet Part 11. It does not tell you that your instance was. Part 11 §11.10 lists the controls a closed system must employ, including validation, access limits, audit trails, and authority checks, but those controls are obligations on “persons who use closed systems,” not guarantees baked into a binary. You inherit them the moment you deploy.

FDA’s 2024 guidance is blunt on this: the agency does not perform preliminary evaluations of electronic systems to determine Part 11 compliance, and these systems are evaluated during an inspection. There is no pre-clearance and no certification body. A vendor cannot hand you a compliant system; it can only hand you a system you must validate, configure, and operate compliantly. Treat “Part 11 compliant” as necessary marketing, never as sufficient evidence.

The four obligations any EDC must satisfy

1. Computerised-system validation (CSV/CSA)

Validation is the documented demonstration that the system does what your protocol needs, reliably, in your configuration. ICH E6(R3) §4.3.4 places the validation status of the system on the responsible party throughout its life cycle and requires a risk-based approach keyed to the system’s intended use, the importance of the data, and the potential to affect participant safety and result reliability. Crucially, §4.3.4 requires that both standard system functionality and protocol-specific configurations and customisations, including automated data-entry checks and calculations, be validated, and that interfaces between systems be defined and validated. Out-of-the-box validation by the vendor does not cover the edit checks and derivations you built.

FDA’s 2024 guidance (Q7) aligns and operationalises this: it recommends a risk-based approach to validation, explicitly includes user acceptance testing within validation, and requires validation to cover system functionality, protocol-specific configurations, customisations, data transfers, and interfaces. The two regulations agree here, and the agreement is worth stating plainly because teams routinely skip the protocol-specific half.

The sponsor-vs-vendor split is the part that surprises people. When an IT service provider validates the system, FDA’s 2024 guidance (Q8) still makes it the regulated entity’s responsibility to ensure validation documentation is available for inspection, including documentation created and maintained by the IT service provider. ICH E6(R3) §4.3.4(g) reinforces it: the responsible party must ensure systems are validated as fit for purpose, including those developed by other parties, and that validation documentation is maintained and retained. The vendor can do the work. The sponsor owns the evidence.

2. ALCOA+ audit trails

ALCOA+ is the data-integrity standard: attributable, legible, contemporaneous, original, accurate, and complete, plus secure and reliable. ICH E6(R3) defines data integrity in those exact terms, and §2.12.2 requires source records to be attributable, legible, contemporaneous, original, accurate and complete, with changes traceable through an audit trail that does not obscure the original entry.

The audit trail is the mechanism. ICH E6(R3) §4.2.2 requires that systems document initial data entry and any subsequent changes or deletions, including the reason for the change where appropriate, that audit trails and logs not be disabled, and that they remain interpretable and able to support review. Part 11 §11.10(e) is the regulatory floor: secure, computer-generated, time-stamped audit trails that independently record the date and time of operator entries and actions that create, modify, or delete records, with record changes not obscuring previously recorded information, retained at least as long as the records themselves.

Where the finding lands is review, not existence. FDA’s 2024 guidance (Q12) states that audit trails must capture all changes, the individuals making them, and the date and time, should include the reason, and must be protected from modification and from being disabled. The same answer recommends periodic, risk-based review of the audit trail to ensure data quality and integrity, and singles out audit-trail review for files containing unblinding information. ICH E6(R3) §4.2.3 requires that procedures for the review of trial-specific data, audit trails, and other relevant metadata be in place as a planned, risk-based activity. An EDC that records a perfect audit trail nobody ever reviews satisfies the letter and fails the inspection.

3. Access control and electronic signatures

Access control answers a single inspection question: can every action be attributed to one identified, authorised individual? ICH E6(R3) §4.3.8 requires access controls that limit system access to authorised users and ensure attributability to an individual, with permissions assigned by duty and revoked when no longer needed. Part 11 §11.10(d) requires limiting system access to authorised individuals, and §11.10(g) requires authority checks so that only authorised individuals can use the system, sign records, or alter data. FDA’s 2024 guidance (Q11) adds the operational discipline: individuals should work only under their own credentials and not share login information, and a record of authorised users, their access rights, and any changes must be maintained. Shared logins are the fastest way to break attributability, and they are a common finding.

Electronic signatures are where Part 11 is most prescriptive, and a non-negotiable set of features follows directly. Part 11 §11.50 requires that a signed record show the printed name of the signer, the date and time of signing, and the meaning of the signature (review, approval, responsibility, or authorship). Part 11 §11.70 requires the signature to be linked to its record so it cannot be excised, copied, or transferred to falsify a record. Part 11 §11.200(a)(1) requires non-biometric e-signatures to use at least two distinct identification components, such as an ID code and password, and §11.300 requires controls maintaining the uniqueness of each ID/password combination and procedures for periodic checks, recall, and revision. If an EDC cannot manifest those signature elements and bind them to the record, it does not meet Part 11 for signed records, however polished the rest of it is.

4. Sponsor data-integrity oversight

The fourth obligation is the one no feature list captures, because it is about the sponsor, not the software. ICH E6(R3) §3.9.1 requires the sponsor to ensure that the processes undertaken and the data generated are of sufficient quality to ensure reliable results. §3.16.1 requires the sponsor to ensure the integrity and confidentiality of data, apply quality control to data handling, and implement documented processes for data integrity across the full data life cycle. The EDC is the instrument through which the sponsor discharges this, not a substitute for it.

Under E6(R3)‘s risk-based quality model, the EDC is also where centralised monitoring lives. §3.11.4.2 describes centralised monitoring as a timely evaluation of accumulated data by the sponsor’s qualified persons that can identify systemic or site-specific issues, including protocol noncompliance and potentially unreliable data, and can complement or reduce site monitoring. A good EDC supports RBQM and centralised monitoring duties by surfacing data patterns and audit-trail signals; it does not own the judgment. And §10.2 is categorical: where activities are transferred to service providers, responsibility for the conduct of the trial, including the quality and integrity of the data, resides with the sponsor. FDA’s 2024 guidance (Q17) says the same in regulatory terms: sponsors are responsible for any regulatory obligations not specifically and lawfully transferred to and assumed by an IT service provider. Hosting your EDC outsources the infrastructure, never the accountability.

EDC examples and categories: by deployment model, not a leaderboard

Practitioners search for “examples of EDC systems,” and a vendor-neutral blog answers that as categories, not a buyer’s shortlist, because the obligations above attach to how you deploy, not to which logo you pick. Three broad deployment models matter for compliance:

• Commercial cloud EDC: a hosted, configurable EDC you stand up per study. Your validation must cover your configuration and edit checks; the vendor’s base validation does not.
• Integrated eClinical platforms (EDC plus eCOA, RTSM/IRT, CTMS): more interfaces, which means more to define and validate. ICH E6(R3) §4.3.4(e) and FDA Q7 both require interfaces between systems to be validated, so integration breadth raises, not lowers, your validation burden.
• EHR-to-EDC and DHT-fed data: source data flows from systems FDA does not inspect for Part 11 into your EDC, which it does. The transfer process must be validated, and each data element needs an identified data originator (FDA Q20). The boundary is the eCRF, and that is where your obligations attach.

We deliberately do not rank-order products. Naming a system tells you nothing about whether your instance was validated, access-controlled, and audit-trail-reviewed.

The EDC compliance evaluation checklist

Run this before you sign, scoped to the deployment you will actually operate. “Yes” requires evidence, not a salesperson’s assurance.

Obligation	What to verify	Backed by
Validation	Vendor supplies validation documentation you can retain and present at inspection; UAT is part of it; your protocol-specific config, edit checks, derivations, and interfaces are validated, not just base functionality	ICH E6(R3) §4.3.4; FDA 2024 Q7, Q8
Audit trail	Secure, computer-generated, time-stamped; captures who/when/old value/new value and reason; cannot be disabled or edited; exportable in a searchable/sortable form for review	Part 11 §11.10(e); ICH E6(R3) §4.2.2; FDA 2024 Q12
Audit-trail review	The system supports a planned, risk-based audit-trail review workflow (you will be asked for the review records, not just the trail)	ICH E6(R3) §4.2.3; FDA 2024 Q12
Access control	Unique per-user credentials, role-based permissions, revocation process, authority checks, maintained user-access log	Part 11 §11.10(d), §11.10(g); ICH E6(R3) §4.3.8; FDA 2024 Q11
E-signatures	Manifests printed name, date/time, and meaning; signature linked to record; at least two ID components; ID/password controls	Part 11 §11.50, §11.70, §11.200(a)(1), §11.300
Oversight	Supports centralised monitoring and your data-integrity oversight; data-flow diagram available; you retain ownership of data-integrity responsibility	ICH E6(R3) §3.9.1, §3.11.4.2, §3.16.1, §10.2; FDA 2024 Q17

Sponsor-vs-vendor responsibility split

Activity	Vendor / IT service provider can	Sponsor must (cannot delegate away)
Base system validation	Perform and document it	Retain the documentation and make it available at inspection (FDA Q8; E6(R3) §4.3.4(g))
Protocol-specific config and edit-check validation	Assist	Ensure it is validated for the trial (E6(R3) §4.3.4(e))
Hosting, backup, security infrastructure	Operate	Ensure authenticity, integrity, confidentiality of records (FDA Q11)
Audit-trail generation	Provide the capability	Conduct planned, risk-based audit-trail review (E6(R3) §4.2.3; FDA Q12)
Regulatory obligations overall	Assume only those specifically and lawfully transferred	Retain everything not lawfully transferred (FDA Q17; E6(R3) §10.2)

Where teams get it wrong

Trusting the demo. A demo shows the product’s best-configured instance, not yours. Validation and audit-trail review live in your deployment, and FDA does not pre-certify systems (FDA Q16, paraphrased as the no-preliminary-evaluation rule). Buy on the obligations, not the tour.

Skipping UAT and protocol-specific validation scripting. Teams accept vendor base validation and never script the edit checks and derivations they built. ICH E6(R3) §4.3.4(e) and FDA Q7 require exactly those configurations and customisations to be validated. Unvalidated edit checks are unreliable data with a confident UI.

Never reviewing the audit trail. Having an audit trail is not reviewing it. ICH E6(R3) §4.2.3 and FDA Q12 expect a planned, risk-based review, and unblinding-related access is specifically called out. The records of that review are what an inspector asks for.

Assuming the vendor owns compliance. A hosted, “Part 11 compliant” EDC outsources infrastructure, never accountability. ICH E6(R3) §10.2 and FDA Q17 keep data integrity and untransferred obligations with the sponsor. If you cannot produce the validation package and the access log, “the vendor handles it” is not a defence.

For deeper treatment of the adjacent topics, see our companion pieces on ALCOA+ data integrity, 21 CFR Part 11 electronic records, computerised-system validation under CSA, and audit-trail review.

Sources

• ICH E6(R3) Good Clinical Practice — ICH, version r3 (adopted 06 January 2025). https://www.ich.org/page/efficacy-guidelines
• 21 CFR Part 11 Electronic Records; Electronic Signatures — FDA, eCFR version current as of 14 April 2026.
• FDA Guidance: Electronic Systems, Electronic Records, and Electronic Signatures in Clinical Investigations — Questions and Answers — FDA, October 2024 (Procedural Revision 1).