REDCap HIPAA Compliance: What Your Institution Actually Needs

"Is REDCap HIPAA compliant?" is one of the most common questions from institutions evaluating the platform. The honest answer is: it depends on how you deploy and configure it. REDCap the software is designed to support HIPAA compliance — but the software alone is not what makes your environment compliant. Your hosting infrastructure, your BAA, your access controls, and your administrative policies all have to come together. This guide explains exactly what's required.

HIPAA Is About the Environment, Not Just the Software

HIPAA compliance for a REDCap deployment involves three distinct layers, all of which must be addressed:

• Technical safeguards — encryption, access controls, audit logs, automatic logoff
• Physical safeguards — where servers are located, who can access them physically, workstation security
• Administrative safeguards — workforce training, access management policies, incident response plans, Business Associate Agreements

REDCap handles many of the technical safeguards at the application layer — audit trails, role-based access control, session timeouts, and field-level logging. But the infrastructure it runs on has to be HIPAA-compliant too. A properly configured REDCap installation on a non-compliant server is still non-compliant.

What Makes a REDCap Hosting Environment HIPAA-Compliant

At the infrastructure level, HIPAA compliance requires:

Encryption at Rest

All PHI stored on the server — including the REDCap database, file uploads, and backups — must be encrypted. AES-256 is standard. This applies to the production database, any backup copies, and any file storage associated with the environment.

Encryption in Transit

All data moving between users' browsers and the REDCap server must be encrypted via TLS. A properly configured SSL certificate is required. TLS 1.2 or higher is the current standard.

Access Controls

Physical and logical access to the server infrastructure must be controlled and logged. Who can SSH into the server? Who has physical access to the hardware? These questions need answers — and documentation.

Audit Logging

Both REDCap (at the application layer) and the server infrastructure should maintain comprehensive audit logs. REDCap does this natively — your hosting environment should too.

Backup and Recovery

HIPAA requires that you have a data backup plan that ensures the availability of PHI in the event of an emergency. Daily automated backups with off-site copies satisfy this requirement.

The Business Associate Agreement: Non-Negotiable

Under HIPAA, any vendor that handles PHI on your behalf is a Business Associate. Your REDCap hosting provider — because they control the infrastructure where PHI is stored — is a Business Associate. A signed Business Associate Agreement is legally required before they handle any PHI.

A BAA must include:

• A description of what the Business Associate is permitted to do with PHI
• Requirements for appropriate safeguards
• Provisions for breach reporting
• Terms for return or destruction of PHI upon contract termination
• Agreement to comply with the HIPAA Security Rule

If your current hosting provider has not signed a BAA with you and your REDCap environment handles any PHI, you have a HIPAA compliance gap — regardless of how secure their infrastructure is.

REDCap Application-Level HIPAA Configuration

Once your infrastructure is HIPAA-compliant and your BAA is in place, REDCap itself needs to be configured correctly. Key settings include:

Audit Trail

REDCap's logging module should be enabled to capture all data entry, modification, export, and user management events. This is typically enabled by default but should be verified.

User Role Permissions

REDCap has granular role-based access control. Users should only have access to the data and functions their role requires. Regular review of user permissions — especially when staff turn over — is an administrative safeguard requirement.

Data Export Controls

REDCap allows you to restrict data exports, de-identify exports, and log all export activity. For PHI projects, export controls should be explicitly configured and reviewed.

Identifier Fields

REDCap allows you to flag fields as "identifiers." These fields are treated differently in exports and reports. Ensuring all PHI fields are properly tagged is important for both compliance and de-identification workflows.

Session Security

Automatic session timeouts should be configured. REDCap supports configurable session lengths — for PHI environments, shorter timeouts (15–30 minutes of inactivity) are appropriate.

Administrative Safeguards Your Institution Must Maintain

No hosting provider can handle these for you — they belong to your organization:

• Workforce training — all staff with REDCap access should receive HIPAA training appropriate to their role
• Access management — a documented process for granting, reviewing, and revoking user access
• Incident response — a written plan for responding to suspected breaches, including notification timelines
• Risk analysis — a documented assessment of risks to PHI in your REDCap environment, updated regularly
• BAA inventory — a record of all Business Associate Agreements, including with your hosting provider

Common HIPAA Mistakes in REDCap Deployments

After years of REDCap deployments, these are the compliance gaps we see most often:

1. No BAA with the hosting provider — the most common and most serious gap
2. Using shared hosting or consumer cloud services — providers that don't offer BAAs or HIPAA-compliant configurations
3. PHI in a non-production environment — test or development instances of REDCap should never contain real PHI
4. Excessive user permissions — researchers with admin-level access who don't need it
5. Unencrypted backups — backup files stored without encryption, often on local drives or consumer cloud storage
6. No session timeout configuration — REDCap sessions left open on shared computers
7. Outdated REDCap versions — failing to apply security patches and version updates