Django HIPAA Technical Safeguards Checklist
A technical checklist for running a Django application that handles protected health information under HIPAA: BAAs with vendors, access control and MFA, audit logging, encryption in transit and at rest, PHI-safe logging and error tracking, backups, and breach readiness.
Problem statement
Your Django app stores or processes protected health information (PHI) for a covered entity or as a business associate in the United States. HIPAA's Security Rule requires administrative, physical, and technical safeguards. Django itself is neither compliant nor non-compliant; what matters is how you host it, who can access data, what you log, which vendors touch PHI, and how you prove it. This checklist covers the technical side that engineering teams own. It is not legal advice; work with your compliance lead.
- Sign Business Associate Agreements (BAAs) with every vendor that stores or processes PHI: cloud, database, email, backups, logging, error tracking.
- Enforce unique accounts, MFA, least-privilege roles, and session timeouts for staff and admin access.
- Encrypt PHI in transit (TLS everywhere) and at rest (database, backups, object storage).
- Keep audit logs of access to PHI and administrative actions, protected and retained.
- Keep PHI out of logs, error reports, analytics, and non-BAA tools; prepare breach detection and response.
Checklist
Vendors and hosting
- BAA signed with the cloud provider (AWS, Google Cloud, Azure all offer them) and only HIPAA-eligible services used for PHI.
- BAAs with email/SMS providers, backup vendors, log platforms, and error trackers, or PHI kept out of them entirely.
- No PHI in services without a BAA: generic analytics, chat tools, AI APIs, or free-tier SaaS.
- Data location and subprocessors documented.
Access control
- Unique accounts for every person; no shared logins to the admin, database, or servers.
- MFA for the Django admin, cloud console, VPN, and CI/CD.
- Role-based permissions in Django (groups) limiting who sees which patients' data; object-level permissions where needed.
- Automatic logoff:
SESSION_COOKIE_AGEand inactivity timeouts suitable for clinical settings. - Access reviews recorded; offboarding removes access promptly.
Audit logging
- Log who viewed, created, changed, or exported PHI, with user, time, record, and action.
- Log admin logins, permission changes, and failed login attempts.
- Store audit logs append-only or in a separate system, with retention (HIPAA documentation retention is six years; align audit log retention with your policy).
- Cloud audit logs (CloudTrail or equivalent) enabled for infrastructure changes.
Encryption and data handling
- HTTPS everywhere with HSTS; TLS for database, Redis, and internal service connections.
- Encryption at rest for databases, snapshots, backups, and object storage, with managed keys.
- Field-level encryption for especially sensitive fields if your risk analysis calls for it.
- Media uploads (documents, images) private, served through authorized views or short-lived signed URLs.
Logging and error tracking hygiene
- No PHI in application logs: log record IDs, not names, diagnoses, or notes.
- Sentry or other error trackers configured with
send_default_pii=False, data scrubbing, and a BAA, or self-hosted. - No PHI in URLs or query strings (they end up in access logs and browser history).
- Staging and development use synthetic or de-identified data.
Availability and breach readiness
- Backups encrypted, tested by restore, and retained per policy.
- Contingency plan: documented recovery steps and responsibilities.
- Monitoring for unusual access patterns (bulk exports, access outside hours).
- Incident response runbook including HIPAA breach assessment and notification steps.
Explanation
HIPAA's Security Rule is technology-neutral: it defines safeguards (access control, audit controls, integrity, authentication, transmission security) and expects a documented risk analysis to decide how to implement them. For a Django application, most safeguards map to concrete configuration: Django permissions and sessions, audit logging, TLS and encryption settings, and careful handling of logs and third-party tools. Business Associate Agreements extend obligations to vendors, which is why every system that touches PHI must be covered.
Edge cases / notes
- De-identified data. Properly de-identified data is not PHI; use it for analytics and testing where possible.
- Patient-facing features. Patient portals add authentication and consent requirements; involve compliance early.
- AI and LLM features. Sending PHI to AI APIs requires a BAA with that provider and careful scoping.
Next steps
- Build audit trails with Django Audit Log in Production.
- Protect backups with Encrypt Django Database and Media Backups.
- Overlapping controls appear in the Django SOC 2 Readiness Checklist.
FAQ
Is Django HIPAA compliant?
Frameworks are not compliant on their own. A Django app can be operated in a HIPAA-compliant way with the right hosting, controls, and documentation.
Do I need a BAA with my cloud provider?
Yes, if PHI is stored or processed there, and you must use only services covered by it.
Can I use Sentry with PHI?
Only with a BAA (or self-hosting) and data scrubbing. Otherwise keep PHI out of error reports.
How long should audit logs be kept?
Follow your policy and legal advice; HIPAA requires documentation retention for six years, and many teams align audit logs with that.