Most health-tech startups find out their infrastructure isn't HIPAA-compliant the hard way: during a prospective enterprise customer's security review, during a business associate agreement negotiation that stalls, or — worst — during an audit that surfaces a reportable breach. The regulation has been in force since 1996, but the technical safeguard requirements are still routinely misunderstood by engineering teams building in healthcare for the first time.

HIPAA doesn't prescribe specific technologies. It mandates outcomes — protected health information must be encrypted, access must be controlled and audited, systems must be able to detect unauthorized activity. How you achieve those outcomes is up to you. That flexibility is also what makes compliance genuinely difficult: there's no checkbox that says "use AES-256" and no authority that will certify your specific architecture as compliant before an audit.

This checklist covers the infrastructure requirements that matter most — the controls that auditors look for, the gaps that most commonly trigger enforcement action, and the implementation decisions that health-tech engineering teams need to make before they can sign a business associate agreement with a health system, payer, or any covered entity.

$9.8M
Average cost of a healthcare data breach in 2023 — the highest of any industry for the 13th consecutive year. For early-stage health-tech companies, a single breach can be existential: regulatory fines, breach notification costs, and customer loss frequently exceed what most startups have in reserve. (Source: IBM Cost of a Data Breach Report, 2023)

1. Data Encryption: At Rest and In Transit

Encryption is the most foundational HIPAA technical safeguard and the one most commonly implemented incompletely. The rule requires that PHI be encrypted "at rest" (stored data) and "in transit" (data moving across networks) — but the details of how each requirement is met vary significantly across infrastructure stacks.

Checklist 01

Encryption at Rest

PHI must be encrypted when stored, on every system that touches it — databases, file storage, backups, and any temporary files created during processing.

  • Database-level encryption enabled (AES-256 minimum) — verify at the storage layer, not just the application layer
  • Database backups encrypted with the same or equivalent standard — unencrypted backup files are a common audit finding
  • Encryption keys managed separately from the encrypted data (AWS KMS, GCP Cloud KMS, or equivalent)
  • File storage (S3, GCS, Azure Blob) with server-side encryption enabled on every bucket or container that may hold PHI
  • Temporary files and processing queues encrypted — ETL pipelines and message queues that pass PHI are frequently overlooked
  • Encryption verified at the infrastructure layer, not just assumed from application-level libraries
  • Key rotation policy documented and automated — annual minimum, with rotation events logged
Checklist 02

Encryption in Transit

PHI must be encrypted whenever it moves between systems — between the client and server, between services, and between your infrastructure and any third party.

  • TLS 1.2 minimum enforced on all external endpoints; TLS 1.3 preferred
  • HTTP requests redirected to HTTPS (no plaintext fallback path)
  • Internal service-to-service communication encrypted — internal network traffic is not exempt from the transit requirement
  • Database connections use TLS (connection string specifies `sslmode=require` or equivalent)
  • Third-party API integrations verified to use TLS on their endpoints
  • Certificate validity monitoring in place — expired certificates have caused reportable exposures
  • Email containing PHI encrypted end-to-end (SMTP with opportunistic TLS is not sufficient for PHI transmission)
58%
Share of HIPAA breaches attributable to hacking and IT incidents in 2023, according to the HHS Office for Civil Rights breach portal. The most common attack vectors — credential theft, unpatched systems, and misconfigured access controls — are all preventable with proper infrastructure hygiene. (Source: HHS OCR Breach Portal, 2023)

2. Access Control and Authentication Infrastructure

HIPAA's access control requirements go beyond passwords. The Security Rule requires unique user identification, emergency access procedures, automatic logoff, and — critically — the ability to audit who accessed what PHI, when, and from where. Most health-tech startups implement authentication but not the audit trail infrastructure that makes access controls meaningful from a compliance standpoint.

Checklist 03

Authentication Requirements

Every user who can access PHI must be uniquely identified. Shared credentials are a direct HIPAA violation and one of the most common findings in audits.

  • Unique user IDs assigned — no shared accounts or shared credentials for PHI-accessible systems
  • Multi-factor authentication (MFA) enforced for all PHI-accessible systems — TOTP, hardware key, or push-based authenticator
  • Session timeout enforced — automatic logoff after a configurable period of inactivity (15 minutes is standard in clinical environments)
  • Password complexity and rotation policies enforced at the infrastructure level, not just documented in policy
  • Service accounts and API keys tracked in a secrets manager, not hardcoded or stored in environment variables in shared systems
  • Single sign-on (SSO) integration available for enterprise health system customers — a BAA blocker at many covered entities
  • Authentication failure lockout policy configured and tested
Checklist 04

Role-Based Access Controls

The minimum necessary standard requires that PHI access be limited to what each user role actually needs. Overly permissive access is a compliance liability and an attack surface.

  • Role definitions documented — each role's permitted data access explicitly scoped, not defaulting to full access
  • Least-privilege principle enforced at the database and API layer, not just the UI
  • Privileged access (admin, support, engineering) audited separately with elevated logging
  • Access reviews conducted and documented on a regular cycle — quarterly or semi-annual for PHI-accessible roles
  • Off-boarding process terminates access within 24 hours of employee departure — document the SLA and automate where possible
  • Production PHI inaccessible from development and staging environments — environment separation enforced, not just assumed
  • Emergency access "break glass" procedure documented for system failure scenarios

Is your healthcare infrastructure actually audit-ready?

The StackScope Technology Health Assessment includes a security and compliance domain that surfaces HIPAA infrastructure gaps in 3 minutes.

Take the Free Assessment

3. Audit Trail Infrastructure

The audit controls requirement is where most health-tech startups have the largest gap between what they believe and what's true. Logging errors, access failures, and application events is standard practice for any web application. HIPAA audit trails require something more specific: a tamper-evident, chronological record of who accessed what PHI, when they accessed it, and what they did with it. Application logs that get overwritten after 30 days don't satisfy this. CloudWatch logs without structured PHI access events don't satisfy this either.

Checklist 05

PHI Access Audit Logging

Audit logs must capture PHI access events at the record level — not just application-level events — and must be retained, tamper-evident, and reviewable.

  • PHI access logged at the record level: who accessed which record, at what time, from what IP/session
  • Audit logs written to a separate, append-only log store — application engineers should not be able to modify audit logs
  • Log retention policy of 6 years minimum (HIPAA retention requirement)
  • Log integrity verification — hash chains or log signing to detect tampering
  • Failed access attempts logged alongside successful accesses
  • Bulk data exports and queries logged separately — high-volume PHI access events are a breach indicator
  • Audit log alerting configured for anomalous patterns (off-hours access, bulk queries, access by terminated users)
  • Logs accessible for review within a defined SLA — auditors will ask to see specific records
Checklist 06

System Activity Monitoring

Beyond PHI access, HIPAA requires that you be able to detect and respond to activity that may indicate a breach — including internal threats, not just external attacks.

  • Intrusion detection system (IDS) or SIEM in place — CloudTrail, GuardDuty, or equivalent for cloud environments
  • Login anomaly detection enabled — alerts on logins from new geographies, devices, or at unusual hours
  • Privileged action monitoring — admin-level operations logged with enhanced detail
  • Data export events monitored — downloads, API bulk queries, and reporting jobs flagged
  • Security incident response plan documented with escalation paths and defined response timeframes
  • Breach notification procedure in place — HIPAA requires notification within 60 days of discovering a breach

4. Multi-State Compliance Complexity

HIPAA is the federal floor. It is not the ceiling. Several states have enacted health privacy laws that are stricter than HIPAA — and for health-tech companies operating across state lines, compliance means satisfying the most restrictive applicable requirement, not just the federal baseline.

California's Confidentiality of Medical Information Act (CMIA) and Consumer Privacy Act (CCPA) extend protections beyond HIPAA, including to health data not covered under the federal rule. Texas, Washington, and Colorado have enacted similar legislation with varying scope and enforcement mechanisms. Companies that process reproductive health data face additional requirements in several states following Dobbs-related legislative activity.

Compliance Gap

The "we're HIPAA compliant" assumption

HIPAA compliance is necessary but not sufficient for health-tech companies operating at scale. A company that has completed its HIPAA implementation but hasn't mapped its state-level obligations may still be out of compliance with California patients' data, Washington state residents' genetic information, or consumers in any of the 18+ states with active health data privacy legislation. State attorneys general have increasingly used these laws to pursue enforcement independent of federal action. A multi-state compliance review is not optional once you reach meaningful user volumes across state lines.

Checklist 07

Multi-State Compliance Infrastructure

Your infrastructure must be able to implement state-specific data handling rules without rebuilding your architecture each time a new state law takes effect.

  • User records tagged with state of residence (or state where data was collected, depending on law) at the data model level
  • Data residency requirements evaluated — some state laws require in-state storage or restrict cross-border transfer
  • Consent management system capable of state-specific consent flows — California, Texas, and Washington have different consent requirements
  • Data deletion and access request workflows implemented — CCPA and similar laws require response within defined timeframes
  • Vendor and subprocessor tracking — state laws often have stricter third-party sharing requirements than HIPAA
  • Privacy policy and terms of service reviewed for state-specific disclosure obligations
  • Legal mapping updated annually or when entering new state markets

5. Common Infrastructure Gaps That Trigger Audit Failures

HHS Office for Civil Rights publishes enforcement actions and corrective action plans from HIPAA investigations. The same infrastructure gaps appear repeatedly across organizations of every size. These are the areas most likely to surface in an audit — and the ones most commonly underestimated by engineering teams building in healthcare for the first time.

Audit Finding #1

Risk analysis not conducted or not documented

HIPAA requires a documented risk analysis — an assessment of where PHI lives, how it moves, what the vulnerabilities are, and what controls address them. Many health-tech startups have implemented strong technical controls but never produced the documented risk analysis that ties them together. An audit that finds strong encryption and access controls but no risk analysis documentation can still result in a corrective action plan. The analysis must be written, must be current, and must be available for review.

Audit Finding #2

Business associate agreements missing or incomplete

Every vendor, contractor, or third-party service that touches PHI on your behalf requires a signed business associate agreement (BAA). This includes your cloud provider (AWS, GCP, Azure all offer BAAs — you must sign them), your logging and monitoring vendor, your error tracking service, your customer support platform if it processes PHI, and any analytics vendor with access to identifiable data. Missing BAAs are one of the most common enforcement triggers and one of the easiest to avoid with a systematic vendor inventory process.

Audit Finding #3

Workforce training not documented

HIPAA requires documented security awareness training for every employee with access to PHI. Not optional, not "we onboard people and they learn it." Written training records, completion tracking, and annual recertification are required. Engineering teams that correctly implement technical controls and then skip the training documentation requirement have not completed their compliance implementation.

Audit Finding #4

Backup and disaster recovery not tested

HIPAA requires a contingency plan — documented procedures for operating and recovering systems during and after a disaster. Most startups have backup processes running; far fewer have tested them. An untested backup is not a backup from a compliance standpoint. Documented recovery testing, with records showing what was tested, when, and what the recovery time was, is what auditors look for.

6. Infrastructure Scaling Without Compliance Drift

The hardest HIPAA problem for growing health-tech companies isn't the initial implementation — it's maintaining compliance as the system scales. New services get added. New engineers join who weren't part of the original compliance work. Third-party integrations accumulate. Each change introduces new surfaces where PHI might flow without the controls that were built into the original architecture.

Compliance drift is what happens when the system grows faster than the compliance review process. A company that was genuinely HIPAA-compliant at launch can accumulate meaningful gaps within 12 months of scaling — not because anyone made bad decisions, but because compliance review wasn't built into the development workflow.

Checklist 08

Compliance-Aware Development Process

Sustaining HIPAA compliance at scale requires building compliance review into the engineering workflow, not treating it as a periodic audit preparation exercise.

  • PHI data flow diagram maintained and updated when new services or integrations are added
  • New vendor onboarding includes BAA review before PHI access is provisioned
  • Infrastructure-as-code templates encode compliance controls — encryption settings, logging, access policies baked into templates, not applied manually
  • Compliance review checkpoint in the feature development process for any feature that introduces new PHI handling
  • Penetration testing conducted annually or after significant architecture changes
  • Risk analysis reviewed and updated annually and after significant system changes
  • Compliance responsibilities explicitly assigned — not assumed to belong to "the security team" or "legal"
  • Third-party compliance tool or external review conducted annually as the system grows beyond what an internal team can audit comprehensively
$1.9M
Average HIPAA penalty per violation category for organizations with willful neglect — the highest enforcement tier. The difference between willful neglect and reasonable cause often comes down to documentation: whether the organization had a risk analysis, whether it was updated, and whether identified risks were addressed within a reasonable timeframe. (Source: HHS OCR Civil Money Penalties)

What to Do With This Checklist

A checklist is only useful if it maps to your actual infrastructure. The next step isn't to read this list and assume you're covered — it's to walk through each item against what you've actually built and documented.

For health-tech startups preparing to sign their first business associate agreement or undergo a customer security review, three areas consistently determine the outcome: encryption implementation (at rest and in transit, including backups and internal services), audit trail completeness (record-level PHI access logging, not just application logs), and documentation (risk analysis, BAA inventory, training records, and tested contingency plans).

For companies that have already done some compliance work and want to know where the gaps are, the most efficient path is a structured technology audit that maps your current infrastructure against each HIPAA safeguard category — technical, administrative, and physical — and produces a prioritized remediation plan. Getting that picture before an enterprise customer or auditor does is dramatically less expensive than getting it after.

If you're not sure whether your infrastructure meets these requirements, our Technology Health Assessment scores your security and compliance posture in 3 minutes. If you need a full HIPAA infrastructure review with specific remediation recommendations, a StackScope consultation covers the complete technical safeguard inventory with a written findings report and prioritized action plan.

Get a baseline read on your compliance posture

The free StackScope Technology Health Assessment evaluates your infrastructure across six domains including security and compliance — in under 3 minutes.

Start the Free Assessment