Is REDCap HIPAA Compliant?

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

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.
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.
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.
Set Data Export rights per user role, not per convenience — most project members should not default to Full Data Set export rights.
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.
For FDA-regulated studies, confirm a Part 11 validation package exists separately from REDCap’s built-in e-signature and locking features.

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.

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