Is REDCap HIPAA Compliant? What the Software Covers and What You Must Configure

REDCap is not “HIPAA compliant” in the way a piece of medical hardware can be FDA-cleared — no software earns a blanket compliance certification, and REDCap’s own project team has never claimed one. What REDCap’s own documentation says is narrower and more useful: the platform is designed to support compliance with HIPAA, FDA 21 CFR Part 11, FISMA, and GDPR through specific features — role-based permissions, audit trails, and access logging. That is a platform-capability claim, not a compliance guarantee. Whether a given REDCap project is actually HIPAA-compliant depends on how the hosting institution deploys, configures, and administers its own instance.

This distinction matters because REDCap ships to institutions differently than the survey and data-collection tools most research offices are used to evaluating. It is not sold as a hosted SaaS product with a vendor-managed compliance posture; it is distributed through the non-profit REDCap Consortium to partner institutions, who install and administer their own instance (or share one hosted by a partner institution). That changes who is actually responsible for HIPAA compliance, and it is the part institutions most often get wrong when they treat “REDCap is HIPAA-capable” as equivalent to “our project is HIPAA-compliant.”

What REDCap the software actually provides

Out of the box, a REDCap instance gives an institution the building blocks for a compliant workflow, not a compliant workflow by default:

• Role-based, project-scoped user rights. Access is granted per project and per user, not instance-wide — a researcher’s rights on one project have no bearing on any other project on the same instance.
• Data Access Groups. On multi-site studies, DAGs restrict each site’s users to only the records their own site entered, while still letting the study run from a single instance.
• An audit trail. REDCap logs record-level create/edit/view/export activity with a timestamp and user identity, which is the kind of access log HIPAA’s Security Rule (45 CFR 164.312(b)) expects a covered entity to be able to produce.
• Tiered export rights. A user’s Data Export permission can be set to Full Data Set, De-Identified, Remove All Tagged Identifiers, or No Access — so different roles on the same project can be limited to less-identifiable views of the same data.
• Field-level identifier tagging. Every field in a project’s Data Dictionary can be flagged with the “Identifier?” attribute, which is what the tiered export rights above actually act on.
• 21 CFR Part 11-oriented features for FDA-regulated studies: electronic signatures on locked forms, and record locking that prevents silent post-signature edits.

Every one of these is a feature the institution has to actually turn on and configure correctly. None of them is enabled to a HIPAA-appropriate standard automatically when a project is created.

What REDCap does not provide — and who has to supply it

Whether you need a Business Associate Agreement, and with whom

HIPAA’s Privacy Rule defines a covered entity and a “business associate” as separate roles (45 CFR 160.103) — a business associate is a person or entity, outside the covered entity’s own workforce, that handles protected health information (PHI) on the covered entity’s behalf. A Business Associate Agreement (BAA) is required wherever that relationship exists. Whether one applies to your REDCap project depends entirely on the hosting model, not on REDCap as a product:

• Self-hosted, institution-administered instance. If your own IT or research-computing group installs and runs REDCap on infrastructure the institution controls, there is generally no external business-associate relationship for the platform itself — your institution’s IT staff are workforce members of the covered entity, not a separate business associate.
• Institution-controlled cloud infrastructure. If that same self-hosted instance runs on a cloud platform (AWS, Azure, etc.) under the institution’s own account, the cloud provider is typically a business associate for the PHI stored there, and needs its own BAA — REDCap being self-hosted does not make the underlying cloud infrastructure exempt.
• A third-party managed or hosted REDCap deployment. Some institutions contract a third party to host and administer their REDCap instance rather than run it themselves. That third party is a business associate and needs a BAA covering the REDCap deployment specifically.

The REDCap Consortium’s licensing model — an institutional agreement to install and run your own instance, rather than a subscription to a Vanderbilt-hosted service — means there usually is no BAA to negotiate with the REDCap project itself for a self-hosted instance. Confirm this against your specific hosting arrangement rather than assuming it; a hosted or managed deployment changes the answer.

Whether a study needs HIPAA Authorization at all

REDCap has no mechanism that determines whether a given project requires HIPAA Authorization, qualifies for an IRB/Privacy Board waiver of Authorization, or can proceed as a review preparatory to research. Those are Privacy Rule determinations made by the IRB or Privacy Board under 45 CFR 164.512(i), independent of what software the study uses. A REDCap project configured perfectly on the access-control side can still be out of compliance if the underlying Authorization or waiver determination was never made.

Correctly tagging identifiers — “De-Identified” export is not automatic Safe Harbor

REDCap’s “De-Identified” export right removes exactly the fields a project’s Data Dictionary has flagged with the Identifier attribute — nothing more. It does not automatically apply HIPAA’s Safe Harbor test, which requires removing 18 specific identifier categories (45 CFR 164.514(b)). If a free-text or notes field contains a date, a device serial number, or an address embedded in prose, and that field was never flagged as an identifier, a “de-identified” export can still contain PHI. Getting this right is a project-design task — reviewing every field against the Safe Harbor list, not just the obviously named ones (name, MRN, email) — not a REDCap setting you can enable once.

21 CFR Part 11 for FDA-regulated studies

REDCap’s e-signature and record-locking features support Part 11 workflows, but Part 11 compliance also requires validated system documentation, defined standard operating procedures, and access-control policy that REDCap doesn’t generate on its own. An FDA-regulated study using REDCap still needs its own Part 11 validation package alongside the platform’s built-in features.

A practical checklist before launching a REDCap project with PHI

1. Confirm your hosting model (self-hosted, cloud-hosted under institutional control, or third-party managed) and put a BAA in place with any party outside the covered entity’s own workforce that will handle PHI.
2. Have the IRB or Privacy Board make and document the actual Authorization/waiver determination for the study before data collection starts — REDCap will not do this for you.
3. Review the Data Dictionary field by field and tag every genuine identifier, including free-text fields that could contain an embedded identifier, not just fields with an obviously identifying name.
4. Set Data Export rights per user role, not per convenience — most project members should not default to Full Data Set export rights.
5. Turn on and periodically review the audit trail; HIPAA’s Security Rule expects a covered entity to actually monitor access logs, not just have the capability to produce one on request.
6. For FDA-regulated studies, confirm a Part 11 validation package exists separately from REDCap’s built-in e-signature and locking features.

Checking this against the current guidance

Whether an external collaborator entering data directly into a self-hosted REDCap instance creates a business-associate relationship depends on whether that collaborator’s organization counts as part of the same covered entity, which the hosting-model breakdown above doesn’t resolve on its own.

Ask CASRAI: Our REDCap instance is self-hosted on university-controlled cloud infrastructure, but a collaborating hospital’s research coordinators need direct access to enter data for a joint study — does that make the hospital a business associate requiring its own BAA, or does it depend on whether the hospital counts as part of the same covered entity as our university?

It answers with its sources linked, so you can open each one and check it yourself, and it says so when our sources don’t cover a question. Two questions a day are free while you are signed out, no account and no card. Everything CASRAI publishes stays free to read.

Frequently asked questions

Does REDCap itself sign a Business Associate Agreement with my institution?

Not typically for a self-hosted instance — the REDCap Consortium licenses the software for your institution to install and run itself, rather than hosting it as a service on your behalf. A BAA becomes necessary with whichever party outside your covered entity’s workforce ends up handling the PHI: a cloud infrastructure provider if you host on institution-controlled cloud infrastructure, or a third-party vendor if you use a managed/hosted REDCap deployment.

Is REDCap encrypted?

Encryption in transit and at rest is a deployment-configuration matter, not something REDCap enforces by itself — it depends on how your institution’s IT team sets up the database, web server, and TLS configuration for your specific instance. Confirm your institution’s own configuration rather than assuming a default.

Can REDCap be used for FDA-regulated clinical trials?

Yes — REDCap includes 21 CFR Part 11-oriented features (electronic signatures, form locking) specifically for this use case, and is widely used for FDA-regulated studies. Part 11 compliance still requires a separate system validation package and documented SOPs beyond enabling those features.

If I mark a field “Identifier” in REDCap, is the resulting export automatically HIPAA de-identified?

Only to the extent every genuine identifier in the project was actually tagged. REDCap’s De-Identified export right strips flagged fields; it does not independently check the data against HIPAA’s 18-category Safe Harbor list. An untagged free-text field with an embedded date or address will still appear in a “de-identified” export.

See also: REDCap (Research Electronic Data Capture), HIPAA, de-identification, limited data set, 21 CFR Part 11, case report form (CRF), business associate agreements for research vendors, HIPAA-compliant form builders, using AI with PHI in research, the REDCap API, REDCap branching logic, Qualtrics vs REDCap, and the Research Tools hub.