"HIPAA compliant" gets attached to hosting products as a checkbox marketing claim more often than it gets explained as an actual set of technical and administrative controls. For a REDCap environment handling PHI, here's what actually has to be in place.
Infrastructure-level controls
- Encryption at rest and in transit — database encryption and TLS on every connection, not just the login page.
- Access logging — a real audit trail of who accessed what data and when, not just server-level access logs.
- Backup encryption and retention policy — backups are a common blind spot; they need the same protection as live data.
- Network segmentation and firewall configuration — the REDCap environment shouldn't be exposed any more broadly than necessary.
The Business Associate Agreement
A BAA between your institution and the hosting provider is not optional if PHI is involved — it's required. It should explicitly define what the provider can and can't do with the data, and under the REDCap consortium license terms, a proper hosting provider should have zero direct access to the actual data stored within your REDCap instance, full stop.
Administrative safeguards — the part infrastructure alone doesn't cover
HIPAA compliance isn't purely a technical property of the server. It also requires:
- Documented access control policies — who gets a REDCap account, and how access gets revoked when someone leaves the study team
- A defined incident response plan, tested rather than just written down
- Regular review of user permissions against actual current study staff
- Training for anyone with access on what does and doesn't constitute a reportable incident
21 CFR Part 11 — a step beyond HIPAA
Institutions running FDA-regulated trials need REDCap configured for 21 CFR Part 11 as well — electronic signatures, audit trails on every data change, and validated system documentation. This is a materially higher bar than baseline HIPAA compliance and should be scoped explicitly if any of your studies fall under FDA oversight.