Is REDCap Enough for GCP-Compliant Clinical Trials?

REDCap can be used inside a GCP-compliant clinical trial. REDCap cannot make a trial GCP compliant on its own, and the REDCap consortium states that position plainly in its own FAQ: “No software alone is truly compliant with any standard. It is the environment into which software is installed that can be called compliant.” Good clinical practice binds the conduct of a trial and the parties running it. It does not certify products.

The question therefore resolves into a narrower one, and that narrower question has an answer. Can the institution produce evidence that its instance is validated and controlled, that each study build was tested and approved, and that the conduct of the trial around the database is recorded somewhere an inspector can read? This guide covers what GCP compliance means in UK law from 28 April 2026, what the REDCap consortium publishes about its own compliance position, which of the eight computerised-system duties in ICH-GCP E6(R3) the software discharges and which stay with the institution, the two-level validation model institutions operate in practice, five places a REDCap study fails inspection, what a hosted route changes, and a twelve-question self-assessment.

Key Takeaways

• GCP compliance attaches to a trial and to the sponsor and investigator running it, so no software product carries it as an attribute
• What the REDCap consortium publishes about capability, environment, licensing eligibility and the commercial hosting route
• The eight computerised-system duties in ICH-GCP E6(R3) Annex 1 Section 4.3, and who evidences each one
• The two-level validation model: one instance validated by the institution, plus a tested and approved build for every study
• Five hypothetical-but-routine failures, four of them procedural and one of them structural
• Twelve questions that separate a well-run instance from an inspection-ready study

What Does GCP Compliance Actually Mean for Software?

The legal duty sits on people and organisations. The MHRA states the position precisely in its guidance on compliance with ICH E6: “Compliance with the ICH E6 GCP Principles (as amended from time to time) and not the entirety of the guideline becomes a legal requirement in the UK on 28 April 2026.” That duty arrives through Regulation 28 of the amended UK Clinical Trials Regulations, and it lands on the sponsor and the investigator. Our guide to the 2026 UK Clinical Trials Regulations sets out the wider change.

No UK regulator issues a certificate of GCP compliance to a software product, and no supplier can obtain one. Vendor language in this market is loose as a result, so it helps to read each claim for what it can legitimately support.

Compliance describes a study. Capability describes a product.

What Does REDCap State About Its Own Compliance Position?

The consortium’s published wording is unusually candid for this market, and every point below comes from REDCap’s own published materials.

• Capability is claimed, and it stops there. The FAQ states that REDCap “is definitely capable of compliance with just about any standard”, naming HIPAA, 21 CFR Part 11 and FISMA as examples. That is a statement about what the software can support, and it stays silent on any given installation.
• Compliance is placed with the environment. The same FAQ states that “It is the environment into which software is installed that can be called compliant”, which puts the assessed object one level above the application.
• Self-hosting is a licence condition. The FAQ states that “Licenses are ONLY issued to non-profit organizations having sufficient internal IT infrastructure to self-host”, so the environment carrying the compliance is institutional by design.
• The feature set is real and it does real work. The software page describes “a secure web application for building and managing online surveys and databases”, with audit trails “for tracking data manipulation and user activity”, a scheduling module, branching logic, calculated fields, file uploading and automated exports to Excel, PDF and common statistical packages.
• Commercial sponsorship has a separate route. The FAQ describes REDCap Cloud as “a third-party company which offers fee-based hosting in their custom version of REDCap”, suitable for commercially sponsored studies requiring 21 CFR Part 11, and operating “separate to our licensing and the REDCap consortium”.

Those five positions together describe a capable database with the compliance burden deliberately located outside it. A team that reads them early plans the right work. A team that reads them during an audit plans it twice.

Also Read: REDCap vs CTMS: Where Data Capture Ends and Study Management Begins

Which GCP Duties Does the Software Discharge?

ICH-GCP E6(R3) Annex 1 Section 4.3 sets eight duties for computerised systems used in a clinical trial. Each one is a thing somebody has to evidence, and the useful exercise is allocating each to an owner before an inspector does it for you.

Seven of the eight duties leave a document that somebody at the institution has to write, own and keep current. That is the honest cost of a self-hosted instance, and it is the same cost for any locally hosted research application.

The software can hold the control. The institution has to hold the proof.

What Does an Institution Have to Produce in Practice?

Institutions running REDCap for regulated studies operate a two-level model, and one of them describes it well in public. The University of Alberta REDCap service states that “REDCap has the features necessary to serve as the database component of a 21 CFR Part 11 compliant study”, that the software must sit in an environment with “servers, security, personnel, policies, procedures, training, validation and documentation that meet the requirements of Part 11”, and that “compliance is assessed at the study level. The system cannot be compliant in isolation from the study policies and procedures”.

The first level belongs to whoever runs the instance. It is written once and refreshed at every version upgrade.

• Validation plan and user requirements specification, which fix what the instance is required to do before anything is tested against it
• Installation, operational and performance qualification records, which evidence the build that was tested, at the point it went live
• A traceability matrix linking each requirement to the test that covers it, which is what turns a folder of scripts into an argument
• Core and ancillary validation reports per release, which give each upgrade a defensible entry point
• Security configuration, patching and penetration test records, which answer E6(R3) Section 4.3.3 directly
• Backup and restore test evidence, because a backup nobody has restored is an assumption rather than a control

The second level belongs to each study team, and it is the level most often missing. A project build is a configuration of a validated system, so it carries its own evidence.

• A documented test of the project build against the protocol, covering instruments, branching logic, calculated fields and export behaviour
• Evidence that a senior member of the study team approved the build before go-live, with a date that precedes first data entry
• User rights in the project matched to the delegation log, so system access and delegated authority describe the same person on the same date
• The data dictionary under version control, with a retained copy of each version the study ran on
• A re-test after any live change, however small the field looked at the time

Retention extends the commitment well past the last patient visit. MHRA guidance on archiving and retention of clinical trial records sets the trial master file period at “at least 25 years beginning the day after the conclusion of the trial” for applications submitted on or after 28 April 2026, and requires records to stay “readily available, complete, and legible at all times during the retention period”, with any migration to new formats validated and documented. A locally hosted instance carries that horizon on institutional infrastructure.

Also Read: GAMP 5 and Computerised System Validation: What QMS Teams Need

Where Does a REDCap Study Fail a GCP Inspection?

The failures are rarely software failures. Five hypothetical-but-routine examples show the pattern, and each traces to a duty in the table above.

1. The leaver’s account. A research fellow moves to another institution in March. The account keeps data-entry rights on two live projects until an inspection in November surfaces it. E6(R3) Section 4.3.8 governs user management, and the finding is the absence of any access review rather than any entry the account made.
2. The audit trail nobody reads. The instance records every change correctly. An inspector asks when the audit trail was last reviewed, by whom, and what the review found. An audit trail with no review procedure evidences the change and says nothing about oversight. Our guide to ALCOA+ and the Trial Master File covers the data integrity attributes at stake.
3. The live field. A coordinator adds a field to the deviation instrument in month nine to capture a new category. No test record exists for the change, no copy of the previous data dictionary was retained, and the approved build on file describes a different instrument to the one in use.
4. The quiet upgrade. IT upgrades the instance over a weekend and files a release note. The study holds no impact assessment and no confirmation that its project still behaves the way the build test recorded. The upgrade was competent. The evidence for this study was never written.
5. The conduct record nobody asked for. The delegation log sits in a signed PDF, visit windows sit in the protocol, and deviations sit in an email folder. The database is complete and current, and the study still cannot show who was authorised to perform which task from which date.

Four of the five are procedural failures around a working system, and each is fixable with a documented routine. The fifth is structural, because the database was never asked to hold that evidence. The person changed. The system did not.

Also Read: MHRA GCP Inspections: What to Expect and the Most Common Findings

Does Hosted REDCap Change the Answer?

The consortium FAQ directs commercially sponsored studies that require a 21 CFR Part 11 maintained system towards REDCap Cloud, described as a third-party company offering fee-based hosting in a custom version of REDCap and operating separately from consortium licensing. A vendor-hosted route moves part of the evidence burden under a contract, and it leaves the rest where it was.

A hosted route changes who writes part of the evidence. It does not change which evidence a regulated trial needs. Our guide to REDCap alternatives sets out the products in each category on their own published terms.

Twelve Questions to Ask Before Your Next Inspection

The questions below separate a well-run instance from an inspection-ready study. A QA lead can work through them in an afternoon, and the answers are more useful written down than remembered.

The Instance

1. Who holds the validation file for your instance, and which version of the software is it written against?
2. When was the last version upgrade, and where is the re-validation summary for it?
3. When did you last review every user account, and where is the record of that review?
4. When was a restore from backup last tested, by whom, and against which study?
5. Which SOP governs system administration, and which version are your staff trained to?

The Project

6. Was the project build tested against the approved protocol before go-live, and who signed that off?
7. Is the current data dictionary under change control, with earlier versions retained?
8. Do user rights inside the project match the delegation log entry for each person, including the dates?
9. What is the agreed data capture route during an unplanned outage, and who reconciles it afterwards?

The Conduct Record

10. Where does the delegation log live, and does every entry carry an effective date rather than only a signature?
11. Where is a protocol visit window checked, and does that check happen before the appointment is confirmed?
12. Where does a protocol deviation link to the corrective and preventive action that closed it, with an owner and a date?

Questions 1 to 9 are answerable with a well-governed instance and a disciplined quality management system. Questions 10 to 12 fall outside any data capture platform, and they are the ones that turn a clean database into an incomplete study record.

How Does AQ Sit Alongside a REDCap Instance?

AQ holds the conduct record and leaves data capture where it is. AQ CTMS carries study set-up, milestones, recruitment and visit scheduling against protocol windows as one operational record, so the answers to questions 10 to 12 are produced by the system rather than assembled before an audit.

• AQ Digital DoA records delegation with effective dates mapped to training evidence, which lets a monitor confirm authority on the day an activity happened.
• AQ eISF holds essential site documents in a controlled electronic investigator site file, which allows review between monitoring visits.
• AQ CAPA links each deviation to the action that closed it, with an owner, a due date and an effectiveness check.
• AQ ePSF keeps pharmacy accountability in a separately owned file linked to the study, which preserves the separation inspection expects.
• AQ eTMF is built on the DIA TMF Reference Model, which gives sponsor and site one structure to reconcile against across a 25-year retention period.

The pattern is common in academic research units and NHS and hospital research teams that keep an established database and need the study record alongside it. AQ is available through G-Cloud, submits the Data Security and Protection Toolkit, holds Cyber Essentials, and releases validation, data protection and governance evidence to institutional teams as an assurance pack. The connected platform holds all of it against one study record.

Bring the twelve questions from this guide and see where each answer lives. Book a live demo against a study you already run in REDCap.