The HIPAA Technical Safeguards Checklist Every Healthcare Software Team Needs Before Launch

HIPAA compliance is not a document you sign and forget. It is a set of technical requirements that shape every architectural decision from the database schema to the API authentication layer. The Security Rule defines three categories of safeguards — administrative, physical, and technical — and the technical safeguards are the ones that software teams own directly.

This post is the checklist we run through on every healthcare software project at Nexios before go-live. It is not a legal document, and it is not a substitute for a HIPAA compliance officer reviewing your specific implementation. What it is: a practical, engineer-facing list of the controls that matter, why they matter, and how we typically implement them.

What the HIPAA Security Rule actually requires from software

The Security Rule (45 CFR Part 164, Subpart C) applies to electronic Protected Health Information (ePHI). If your system stores, processes, or transmits any information that could identify a patient and relates to their health condition, healthcare provision, or payment for healthcare, you are handling ePHI and the Security Rule applies.

The technical safeguards section (§164.312) has four required standards:

• Access control (§164.312(a)(1))
• Audit controls (§164.312(b))
• Integrity (§164.312(c)(1))
• Transmission security (§164.312(e)(1))

Within each standard there are required and addressable implementation specifications. Required means you must implement it. Addressable means you must either implement it or document why it is not reasonable and appropriate for your specific situation, and implement an equivalent alternative. "Addressable" does not mean optional.

Access control

Unique user identification (required)

Every user who accesses ePHI must have a unique identifier. Shared accounts — including shared service accounts used for application-to-application communication — are a violation. Each human gets their own credentials. Each service gets its own service account with the minimum permissions needed to do its job. We enforce this from day one because retrofitting it into an application that was built with shared accounts is painful.

In practice: every user record gets a UUID that is used as the identifier in audit logs. Service accounts are created per service with IAM roles scoped to exactly the S3 buckets, database tables, and API endpoints each service needs. We review these permissions at the end of every sprint.

Emergency access procedure (required)

You need a documented procedure for emergency access to ePHI when normal access controls are unavailable. This sounds bureaucratic but it has a technical component: the emergency access pathway must be auditable. If a clinician needs to access a patient record during a system outage, that access must be logged as emergency access and reviewed afterward.

In practice: we implement a break-glass access mechanism — a separate elevated-privilege role that can only be activated by certain administrators, logs every activation with a mandatory reason field, and triggers an immediate alert to the compliance officer. Emergency accesses are reviewed within 24 hours without exception.

Automatic logoff (addressable)

Sessions must terminate after a period of inactivity. The specific timeout is not defined by the rule — you set it based on your risk analysis. For clinical applications where a clinician might walk away from a shared workstation, we typically set 15 minutes. For administrative applications, 30 minutes is common. For mobile apps where the device itself has a lock screen, the interaction between the app timeout and the device lock requires separate consideration.

In practice: we implement idle detection at the application layer (not just a server-side session timeout, which does not detect a genuinely idle user). If the user has not interacted with the application for the configured period, they are logged out and the session is invalidated server-side. A re-authentication dialog appears rather than a redirect to login, which reduces friction for clinicians who are actively using the system.

Encryption and decryption (addressable)

ePHI must be encrypted at rest. The addressable designation here is historical — in practice, encrypting ePHI at rest is universally considered the baseline, and failing to do so would be very difficult to justify in a risk analysis. AES-256 is the standard; anything weaker requires explicit justification.

In practice: we use AWS RDS with encryption at rest enabled (AES-256 via AWS KMS). Column-level encryption is added for the highest-sensitivity fields (SSN, date of birth, diagnosis codes) using application-layer encryption before data reaches the database. This gives two layers: disk-level encryption from RDS, and field-level encryption for the most sensitive columns that requires the application's encryption key to read. A database dump without the application keys is unreadable for those fields.

Audit controls

This is the standard that most teams under-implement. §164.312(b) requires hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI. There is no specific format required. But when a breach investigation or OCR audit happens, you need to be able to answer: who accessed what ePHI, when, and from where?

What the audit log must capture

At minimum, every audit log entry should record:

• User ID (the unique identifier from the access control requirement)
• Timestamp (UTC, millisecond precision — timezone-ambiguous timestamps have caused audit failures)
• Action performed (read, write, update, delete, export)
• Resource accessed (patient record ID, document ID, report ID)
• IP address and user agent
• Request ID (for correlation with application logs)
• Outcome (success or failure, with failure reason)

Failures matter as much as successes. A pattern of failed access attempts to a specific patient record is a potential insider threat signal.

The audit log schema we use

We maintain a separate audit log table that is append-only at the application layer. No UPDATE or DELETE is permitted on audit records through the application. The schema:

CREATE TABLE audit_log (
  id            BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  event_time    DATETIME(3) NOT NULL,
  user_id       CHAR(36) NOT NULL,
  session_id    CHAR(36) NOT NULL,
  action        VARCHAR(50) NOT NULL,
  resource_type VARCHAR(100) NOT NULL,
  resource_id   CHAR(36) NOT NULL,
  ip_address    VARCHAR(45) NOT NULL,
  user_agent    TEXT,
  outcome       ENUM('success','failure') NOT NULL,
  failure_code  VARCHAR(50),
  metadata      JSON,
  request_id    CHAR(36) NOT NULL,
  INDEX idx_user_time (user_id, event_time),
  INDEX idx_resource (resource_type, resource_id, event_time)
);

The metadata JSON column captures action-specific context: for a record view, what fields were included in the response; for an export, the format and destination; for a failed login, the failure reason. This gives investigators the context to reconstruct what happened without requiring them to reconstruct it from application logs.

Audit log integrity

An audit log that can be modified by an attacker who has already compromised the system is useless. At minimum, audit logs should be written to a separate storage location from application data, with write-only access from the application and read access restricted to security/compliance roles. We typically write to both the application database (for real-time querying) and a separate append-only S3 bucket (for long-term immutable storage and breach investigation).

Retention

HIPAA requires audit logs to be retained for six years from creation or last effective date. This is longer than most application data retention policies. Make sure your log retention policy is set correctly and that logs are not being purged by an automated cleanup process that does not know they are HIPAA-relevant.

Integrity controls

§164.312(c)(1) requires mechanisms to corroborate that ePHI has not been altered or destroyed in an unauthorized manner. This means detecting accidental corruption as well as malicious modification.

Data integrity at the transport layer

TLS ensures that ePHI cannot be modified in transit without detection. This is the primary integrity control at the transport layer. TLS 1.2 is the minimum; TLS 1.3 is preferred. Certificate pinning should be considered for mobile applications where a man-in-the-middle attack on the device's certificate store is a realistic threat model.

Data integrity at the storage layer

For clinical documents and records where integrity verification is important (think: a discharge summary or a medication order), we implement hash-based integrity checks. When a document is saved, its SHA-256 hash is stored alongside it. When it is retrieved, the hash is recomputed and compared. A mismatch triggers an alert and serves as evidence of unauthorized modification.

Database integrity

Foreign key constraints, NOT NULL constraints, and check constraints are integrity controls. An application that allows orphaned records, null values in required fields, or values outside valid ranges has compromised data integrity even if no malicious actor was involved. We enforce these at the database level rather than relying solely on application-layer validation.

Transmission security

§164.312(e)(1) requires protection of ePHI when transmitted over electronic networks. The practical requirements:

TLS configuration

TLS 1.2 minimum, 1.3 preferred. Disable SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1. Disable weak cipher suites (RC4, DES, 3DES, export ciphers). Use forward secrecy cipher suites (ECDHE) so that a future compromise of the server's private key does not allow decryption of past sessions.

We test TLS configuration using SSL Labs before go-live and require an A grade minimum. An A+ is achievable with HSTS preloading and a correctly configured certificate.

Certificate management

Certificates must be valid, from a trusted CA, and renewed before expiration. Certificate expiration is one of the most common causes of unexpected HIPAA-adjacent incidents. We use AWS Certificate Manager for TLS certificates on load balancers and CloudFront distributions, which handles renewal automatically. We set CloudWatch alarms for certificates with fewer than 30 days remaining as a backup check.

API-to-API communication

Internal service-to-service calls within a VPC often run over HTTP because the network is private. This is generally acceptable if your VPC security groups are correctly configured, but we prefer TLS for all inter-service communication regardless of whether it is internal. The cost is negligible, and it eliminates a class of risk from misconfigured security groups or compromised internal network positions.

Email and messaging

ePHI should not be transmitted via standard email unless the email is encrypted end-to-end. Most clinical communication platforms handle this with their own encryption layer. If your application sends notification emails that include ePHI (even just a patient name and appointment time), those emails must be transmitted over an encrypted channel and the email provider must be under a BAA.

Additional controls not in the Security Rule but practically required

Business Associate Agreements

Every vendor that handles ePHI on your behalf must sign a BAA. This includes your cloud provider (AWS, GCP, Azure all offer BAAs), your database provider, your error monitoring service (Sentry, Datadog — both offer BAAs), your email service (SendGrid, SES — both offer BAAs), and any third-party API that receives ePHI. A chain of custody for ePHI through your entire vendor stack must be covered by BAAs.

Penetration testing

The Security Rule does not explicitly require penetration testing, but a risk analysis that does not include testing your application for vulnerabilities is not a credible risk analysis. We recommend penetration testing before go-live for any application that handles ePHI, and annually thereafter. The OWASP Top 10 is the minimum scope. For healthcare applications, also test for healthcare-specific attack vectors: SSRF to internal EMR systems, HL7 injection, and unauthorized patient record enumeration.

Dependency management

A dependency with a known CVE is a vulnerability in your application. Healthcare software with known vulnerabilities in its dependency tree has failed to implement reasonable technical safeguards. We run Dependabot or equivalent on every project and treat security-related dependency updates as non-negotiable within 48 hours of disclosure for critical vulnerabilities.

Secrets management

Database credentials, API keys, and encryption keys must never appear in source code or environment variables committed to version control. We use AWS Secrets Manager or Parameter Store for all secrets. Secret rotation is configured at the infrastructure level so that compromised credentials can be rotated without code changes. Rotation also means that a credential leaked in a git history three years ago is not still valid.

The pre-launch checklist

Before any healthcare application at Nexios goes to production with real ePHI, we check every item on this list:

• Unique user IDs enforced, no shared accounts
• MFA enabled for all user authentication
• Session timeout configured and tested
• Break-glass access procedure documented and tested
• ePHI encrypted at rest (AES-256 minimum, field-level for sensitive columns)
• Audit log covering all ePHI access, with integrity protection and 6-year retention
• TLS 1.2+ on all endpoints, SSL Labs A grade confirmed
• HSTS enabled with minimum 1-year max-age
• All vendor BAAs in place and signed
• Penetration test completed with no critical/high findings open
• Dependency scan clean (no critical CVEs)
• No secrets in source code or git history
• Data backup encrypted and restoration tested
• Incident response plan documented, team trained
• Risk analysis completed and documented

Missing any one of these before go-live is not a minor gap — it is an open compliance risk. The OCR imposes penalties on a per-violation basis, and a single breach investigation that finds multiple missing controls can result in fines that dwarf the cost of getting it right at the start.

If you are building a healthcare application and want to understand where your current architecture stands against this checklist, that is the kind of review we do as part of our project discovery process.