> Disclaimer: This content is for educational and reference purposes for software builders only. It does not constitute medical, legal, financial, or regulatory advice. Consult a qualified professional before making decisions based on this content.
Encrypt All ePHI at Rest with AES-256
Rationale: HIPAA designates encryption at rest as an addressable specification, but in modern cloud deployments it is universally considered reasonable and appropriate. Unencrypted PHI in a database breach is automatically a reportable breach. (45 CFR § 164.312(a)(2)(iv))
Do: Encrypt every database volume, object store, and backup containing ePHI with AES-256. Use customer-managed keys (CMEK) with a cloud KMS or HSM. Rotate keys annually and log all key-access events. Enable transparent data encryption (TDE) at the database level as a minimum baseline.
Don't: Rely solely on disk-level encryption provided by the cloud host without a BAA. Never store encryption keys in the same location as the encrypted data.
Enforce TLS 1.2+ on Every ePHI Network Path
Rationale: Any ePHI transmitted over a network without encryption is an impermissible disclosure. HIPAA's transmission security standard (45 CFR § 164.312(e)(2)(ii)) classifies encryption in transit as addressable, but no reasonable risk assessment can justify plaintext ePHI over public networks.
Do: Configure all load balancers, reverse proxies, and API gateways to enforce TLS 1.2 as the minimum version. Enable TLS 1.3 as the default. Use HSTS with a minimum max-age of one year. Test your TLS configuration with testssl.sh or SSL Labs after every infrastructure change.
Don't: Allow fallback to TLS 1.0 or 1.1. Do not use self-signed certificates in production without certificate pinning. Never transmit ePHI over plain HTTP or unencrypted WebSocket.
Implement Role-Based Access Control Aligned to Job Functions
Rationale: The minimum-necessary principle (45 CFR § 164.514(d)) requires that PHI access be limited to what is needed for a specific job function. RBAC is the standard mechanism for enforcing this requirement at the system level.
Do: Define roles that map to clinical and administrative job functions (e.g., physician, nurse, billing clerk, admin). Assign permissions to roles, not individual users. Implement attribute-based access control (ABAC) at the query level to enforce row-level and field-level PHI restrictions. Conduct quarterly access reviews to remove stale assignments.
Don't: Create catch-all roles with broad PHI access. Do not allow users to self-assign roles. Never use a single shared "healthcare" role that bypasses minimum-necessary scoping.
Write Tamper-Evident Audit Logs for Every PHI Access
Rationale: HIPAA requires hardware, software, and procedural mechanisms to record and examine activity in information systems that contain or use ePHI. (45 CFR § 164.312(b)) Audit logs are the primary evidence in OCR investigations and breach litigation.
Do: Log user ID, timestamp (UTC), resource type and ID, action (read/write/delete/export), outcome, and source IP for every PHI access. Write logs to a separate, append-only store (object storage with Object Lock or an immutable SIEM). Alert on bulk exports, after-hours access, and access from anomalous locations. Retain logs for at least six years.
Don't: Write audit logs to the same database that holds ePHI. Do not allow application service accounts to modify or delete audit records. Never log ePHI field values in plain text within the audit record itself.
Execute BAAs Before Any PHI Flows to Third Parties
Rationale: Sharing PHI with a business associate without a signed BAA is an impermissible disclosure under HIPAA. (45 CFR § 164.504(e)) Every vendor in your supply chain that touches PHI must have a BAA in place before data flows.
Do: Maintain a business associate register with vendor name, BAA execution date, BAA review date, and scope of PHI access. Require all new third-party integrations to complete BAA review before going live. Build a pre-launch checklist item: "BAA confirmed for all new integrations."
Don't: Rely on a vendor's generic privacy policy as a substitute for a BAA. Do not send PHI to third-party analytics, logging, or monitoring platforms before confirming a BAA. Never assume a BAA from a previous project applies to a new product or service.
Implement Unique User Identification and MFA for PHI Systems
Rationale: Unique user identification (45 CFR § 164.312(a)(2)(i)) is a required HIPAA specification - no alternatives. Shared accounts and service accounts used to access PHI are a direct violation. MFA addresses the leading cause of HIPAA breaches: credential theft.
Do: Assign a unique credential to every human user. Implement MFA for all user-facing PHI applications using TOTP or hardware keys. Use separate service-account credentials for automated pipelines, with narrow IAM permissions and no interactive login. Enforce MFA via your identity provider at the policy level, not application-by-application.
Don't: Allow shared login credentials even for low-volume admin access. Do not exclude legacy internal tools from the MFA requirement because "users find it inconvenient." Never allow password reuse across systems.
Implement Automatic Logoff and Session Expiry
Rationale: Unattended workstations with active PHI sessions are a significant breach vector. HIPAA identifies automatic logoff as an addressable implementation specification (45 CFR § 164.312(a)(2)(iii)).
Do: Implement configurable inactivity timeouts (default 15 minutes for clinical apps, 30 minutes for administrative apps). Use both client-side idle detection (JS/mobile) and server-side token expiry that cannot be overridden by client manipulation. Show a timeout warning at T-2 minutes with an option to extend. Log all automatic logoff events in the audit trail.
Don't: Allow "remember me" tokens with indefinite lifetimes for PHI systems. Do not rely solely on client-side timeout logic that can be bypassed.
Build a HIPAA-Aligned Breach Detection and Notification Pipeline
Rationale: HIPAA's Breach Notification Rule (45 CFR §§ 164.400–414) requires covered entities to notify affected individuals, HHS, and (for breaches of 500+ individuals) the media within 60 days of discovery. Builders must design systems that can detect, scope, and report breaches within that window.
Do: Define a "breach" threshold in your monitoring alerting (e.g., more than N PHI records exported outside normal access patterns). Implement anomaly detection on audit log streams. Prepare a breach notification workflow: incident detection → legal review → HHS notification form preparation → individual notification template → media notification trigger. Perform table-top breach response exercises annually.
Don't: Treat HIPAA breach notification as solely a legal function. Build the technical breach detection capability at the application layer, not only at the infrastructure layer.
Sanitise ePHI from Application Logs and Error Traces
Rationale: Application logs are a common unintentional PHI leak vector. Error messages, stack traces, and debug logs frequently contain patient identifiers or clinical data that bypass PHI access controls.
Do: Implement a log formatter/sanitiser that detects and redacts known PHI patterns (SSN regex, MRN formats, date-of-birth patterns, email addresses) before writing to any log target. Define a structured logging schema that explicitly excludes ePHI fields. Include "PHI in logs" as a check in your code review and pre-release security checklists.
Don't: Log full request or response bodies from PHI endpoints without sanitisation. Do not enable verbose or debug logging in production PHI systems without a time-limited window and automatic reversion.
Perform and Document a Formal Risk Analysis Before Launch and After Major Changes
Rationale: Risk analysis is a required administrative safeguard (45 CFR § 164.308(a)(1)(ii)(A)), not optional. OCR audits routinely find missing or undated risk analyses as the primary finding.
Do: Conduct a documented risk analysis using the NIST SP 800-66 guidance or the HHS Security Risk Assessment Tool. Scope the analysis to all ePHI stores, data flows, and system boundaries. Repeat the analysis when significant changes occur (new data store, new vendor, major architectural change, new geographic deployment). Store the analysis and evidence in your compliance documentation repository with a six-year retention policy.
Don't: Substitute a generic "security review" or penetration test for the HIPAA-specific risk analysis. Do not omit development and test environments that contain real PHI (even if partial or masked).
Segregate PHI Data Stores from Non-PHI Systems
Rationale: Mixing PHI and non-PHI data in the same database or storage bucket expands the blast radius of any breach and complicates HIPAA scoping.
Do: Host ePHI databases in dedicated instances or schemas with separate access credentials. Use network segmentation (VPCs, security groups) to isolate PHI infrastructure. Implement dedicated IAM policies for PHI store access. Tag all PHI data stores in your cloud infrastructure as a prerequisite for automated compliance scanning.
Don't: Store PHI in multi-tenant databases where row-level isolation is the only control. Do not co-host PHI and analytics workloads without explicit data flow controls and audit trails.
Apply the Principle of Least Privilege to Service Accounts
Rationale: Service accounts with over-privileged database or API access are a primary privilege escalation vector in healthcare data breaches.
Do: Grant service accounts only the database permissions they need for their specific function (e.g., a reporting service needs SELECT on specific tables; a billing service needs SELECT + INSERT on billing tables, not UPDATE on clinical tables). Rotate service account credentials on a scheduled basis. Use short-lived tokens (IAM roles with session tokens) rather than long-lived passwords where possible.
Don't: Share a single database super-user credential across multiple services. Do not grant service accounts administrative database roles for operational convenience.