Guide · ValidationUpdated October 15, 2026

How to validate an EDC for an academic study, proportionately

A university trial team does not need a pharma validation department, but it does need evidence that the system is fit for the study. This guide sets out a lightweight, risk-based validation you can finish in days, not months, and file in the trial master file.

  • Seven steps, small-team scale
  • Test script and evidence examples
  • Shared responsibility with the vendor
Run your validation in the free sandboxBook a demo

Free sandbox · No credit card · 21 CFR Part 11 aligned

Validation evidence pack · demo study

Study

DEMO-ACAD-02

Risk level

Medium

Tests run

24 of 26

  • Intended use statement and scope signedPI, 2 Oct
  • Risk assessment of study-critical functionsv1.0
  • Vendor documentation reviewed and filedSecurity page, controls summary
  • Study-specific test scripts executed2 pending retest
  • Role and access test (each role)Site, researcher, admin
  • Validation summary reportDraft
Demo data. The evidence pack is a short set of documents, not a binder.

What proportionate validation means

  • Validate for your intended use, not the whole product. You show that the functions your study depends on (forms, rules, roles, audit trail, export) work as intended in your configuration.
  • Shared responsibility. The vendor develops, tests and controls the platform. The study team is responsible for validated use: configuring, testing and documenting for the study.
  • Scale effort to risk. Functions that protect participant safety and primary endpoint data deserve the most testing. Convenience features deserve little.
  • Evidence beats volume. A short plan, a risk table, executed test scripts with results and a signed summary is what an auditor or ethics committee generally wants.
  • Regulators describe principles, not a template. Look to the FDA electronic systems Q&A, the EMA computerised systems guideline, ICH E6 and your sponsor or institution policy for what applies to you.

Why validate

What validation is for, and what it is not

Computer system validation (CSV) is documented evidence that a system consistently does what it is meant to do for its intended use. For an EDC, that means entering, changing, storing and exporting data correctly, restricting access to the right people and keeping a trustworthy record of every change. If you are running an FDA-regulated study or one governed by EU clinical trial rules, expect your sponsor, ethics committee or inspector to ask what you did.

It is not a requirement to validate everything the vendor has ever built, and it is not a license to skip. The FDA guidance on electronic systems in clinical investigations (final Q&A, October 2024) and the EMA guideline on computerised systems and electronic data in clinical trials both lean on a risk-based, fit-for-purpose approach. Check the current texts, and see Annex 11 vs 21 CFR Part 11 and the Part 11 compliance checklist for how the two frameworks compare.

Risk-based assurance is a wider trend. For example, FDA's Computer Software Assurance guidance (finalised September 2025) encourages focusing assurance effort on risk for production and quality system software in the device industry. It does not apply directly to clinical trial systems, but it shows the direction of travel: think about intended use, rate the risk, choose assurance activities that match and keep objective evidence. For a framework view, read GAMP 5 and EDC validation and the CSV overview.

The method

Seven steps for a lightweight validation

This works for one study or a small portfolio. Adjust to your institution's policy.

  1. 1

    1. Write the intended use and scope

    One page. What data the system collects, which regulations apply (FDA, EU, local), which users and roles exist, which sites, and what the system will not be used for. State the primary endpoint data and any safety data that flows through it.

  2. 2

    2. Do a risk assessment

    List the functions the study relies on and rate each for impact on participant safety and data integrity, and for likelihood of failure in your configuration. A simple high, medium or low table is enough. Spend your testing on the highs.

  3. 3

    3. Review the vendor evidence

    Ask the vendor what controls the platform provides and what documentation supports validation. File what you receive. Check the vendor's security page and ask any questions in writing. Capture's enterprise customers get documentation to support sponsor validation and UAT; ask what is available for your plan.

  4. 4

    4. Configure the study under change control

    Build forms, rules and roles from the approved protocol. Keep the protocol version and form versions recorded. Forms in Capture move from draft to approved, and only approved forms appear in the casebook, which gives you a natural configuration control point.

  5. 5

    5. Write and run study-specific test scripts

    Test your configuration, not the platform in the abstract. Each script has a step, an expected result, an actual result, who tested and when. Include negative tests such as out-of-range values and missing required data. See the table below for examples.

  6. 6

    6. Handle deviations and retest

    Any test that fails is recorded, assessed, fixed in the configuration or accepted with a documented rationale, and retested. Do not overwrite the failure: keep the trail.

  7. 7

    7. Sign a validation summary

    A one or two page report stating scope, what was done, results, open issues and a conclusion that the system is fit for intended use. The PI or sponsor representative signs. File it in the trial master file with the plan, risk table, scripts and evidence.

Test scripts

Example study-specific tests for an academic trial

Illustrative. Trim or extend based on your risk table.

AreaTestExpected resultRisk
Data entryEnter a systolic BP of 400 mmHg in the vital signs formEdit check fires and an auto-query is raisedHigh
Required dataSubmit the primary endpoint form with the main field blankSubmission blocked or flagged per designHigh
Calculated fieldEnter height and weight and compare the BMI with a hand calculationValues match to the stated precisionMedium
Audit trailChange a saved value and give a reasonAudit row shows user, timestamp, old value, new value and reasonHigh
RolesLog in as site staff, researcher and admin and attempt restricted actionsEach role sees and does only what the role matrix allowsHigh
RandomisationRandomise ten test participants and review the allocationAllocation follows the specified schemeHigh
E-signatureSign off a form and attempt to edit after signingSignature recorded; further change requires the defined processMedium
ExportExport the dataset and the data dictionary; open with the statisticianFields, labels, units and dates match the specificationHigh

Record the actual result, tester and date for each row. Screenshots are supporting evidence, not the evidence itself.

Test your configuration in a sandbox that costs nothing

Build the study, run your scripts with test participants and keep the evidence. The free sandbox has every feature, including skip logic, edit checks, e-signatures and the audit trail.

Run your validation in the free sandbox

After go-live

Keeping the system in a validated state

Validation is not a one-off. Protocol amendments change forms, platform releases change software and staff change roles. A light-touch change control process covers this: record the change, assess the risk, retest what is affected, approve and file. Our guide to eCRF versioning for mid-study changes shows how to treat changed forms, and the EDC go-live checklist gives a final gate before enrolment.

Revisit the risk table at least when the protocol changes materially and when the vendor announces a change that touches a high-risk function. Review user access periodically, remove leavers promptly and keep training records. At the end of the study, keep the validation file with the trial master file for the retention period that applies (see archiving and retention).

Where a self-serve EDC helps

Self-serve platforms lower the effort of validation for small teams:

  • You can build and test in a free sandbox before any participant is enrolled, so scripts run against the real configuration.
  • Field-level audit trail with timestamp, user, old value, new value and reason for change is available on every record.
  • Role-based access with PII segregation can be tested as each role.
  • Forms use draft and approved states, which supports configuration control.
  • Capture provides 21 CFR Part 11-aligned controls; validated use is shared between the platform and the sponsor.

Stage 1

Draft

Build and edit freely

Stage 2

Approved

Locked for live use

Stage 3

In the casebook

Only approved forms

Audit trail

  • SDV requirement changed on Systolic BP

    Data manager · Reason: critical safety value

  • Form approved: Vital Signs (VS) v2

    Study owner · Locked for live use

  • Answer changed: Weight 68.0 to 68.5 kg

    Site coordinator · Reason: transcription error

What to file

The validation file: what an auditor will want to see

Validation plan or protocol

Intended use, scope, approach, roles and acceptance criteria. Two pages is fine.

Risk assessment

Functions, risk rating and the testing chosen for each. See the data validation plan template for the data checks side.

Vendor documentation

Security and controls information, support terms and any supplied validation documents. Date them.

Configuration record

Protocol version, form versions and approval dates, role matrix and rule list.

Executed test scripts

Steps, expected and actual results, tester, date, deviations and retests.

Validation summary report

Conclusion on fitness for use, open issues and sign-off.

Change log and access reviews

Kept up to date during the study.

FAQ

Questions teams ask before they switch

Something not covered here? Ask us directly.

Do academic trials need to validate their EDC?

If a study falls under FDA rules, EU clinical trial rules or your sponsor's requirements, you are expected to show the system is fit for purpose. The depth should match the risk. Ask your institution's research office or sponsor what they require.

Is the vendor responsible for validation?

Partly. The vendor develops and controls the platform; the study team is responsible for validated use, meaning configuration, testing and documenting for the study. Capture provides Part 11-aligned controls; the sponsor remains responsible for validated use.

What is lightweight CSV?

A proportionate, risk-based validation approach: define intended use, assess risk, test the high-risk functions in your configuration, document results and keep a short validation file, instead of exhaustive scripted testing of every feature.

How long does EDC validation take for a small study?

It depends on the build and risk level. For a small study with a modest number of forms, many teams complete the plan, risk assessment and scripted testing in days to a few weeks. Larger or higher-risk studies take longer.

Can I reuse the vendor's validation documents?

You can use them as supporting evidence about the platform, but they do not replace testing your own configuration. Review, date and file them, and test what is specific to your study.

Do I need IQ, OQ and PQ?

Those terms come from the traditional validation lifecycle. For a hosted system, installation is the vendor's responsibility, so the study-level focus is on configuration and performance testing against intended use. Follow your institution's policy if it prescribes the terms.

What if the platform releases an update during my study?

Assess whether the change touches a high-risk function, retest what is affected and record it. Ask the vendor how release notes are communicated.

Keep exploring

Related pages

Computer system validation for clinical trial software

CSV overview.

GAMP 5 and EDC validation

Framework view.

EDC validation checklist

Checklist.

EDC UAT and sandbox

User acceptance testing.

21 CFR Part 11 compliance checklist

Part 11 controls.

Data validation plan template

Plan the data checks.

Software for investigator-initiated trials

Academic sponsors.

Validate against your own study, free

Free sandbox with every feature. No credit card, and you pay only when you go live with real participants.

Start freeBook a demo
Run your validation in the free sandbox