HIPAA Compliance for Digital Health Startups: What You Actually Need to Know

Last updated: March 2026

HIPAA compliance means your organization has implemented documented controls to protect protected health information (PHI), can demonstrate those controls to an auditor, and has agreements in place with every vendor who touches that data on your behalf. It is not a certification, not a one-time event, and not something a vendor can fully handle for you. It is an ongoing organizational practice that spans your infrastructure, your policies, and your workforce.

In this guide

This page is the hub for Aptible's HIPAA compliance content. Use the table below to jump to what you need.

Who HIPAA applies to

HIPAA divides regulated organizations into two categories.

Covered entities

Covered entities are health insurers, health plans, self-insured employers, claims clearinghouses, and healthcare providers that conduct certain electronic transactions. In practice, almost any healthcare provider that bills insurance is a covered entity, even if only some patients use insurance.

Business associates

A business associate is any organization that handles PHI on behalf of a covered entity or another business associate. This is the category most digital health startups fall into. If you are building a platform for hospitals, clinics, or health plans, and your platform processes, stores, or transmits patient data, you are a business associate.

HIPAA requires that every business associate relationship be formalized in a contract: the Business Associate Agreement, or BAA. Missing a BAA with a vendor that touches PHI is a HIPAA violation regardless of how strong your other controls are.

The business associate chain

BA relationships can form a chain. An example: a digital health platform runs on Aptible, which runs on AWS. The platform is a business associate of its hospital clients. Aptible is a business associate of the platform. AWS is Aptible's business associate. The platform doesn't need a direct BAA with AWS unless it uses AWS services on its own.

What this means practically: you need a BAA with every vendor that could touch PHI. Your hosting provider, managed database, log management service, storage layer, analytics platform, email provider. Not having one is a compliance gap regardless of how good your other controls are.

→ For what to look for before signing a BAA, see What is a HIPAA BAA.

To determine whether your specific organization is regulated, consult an attorney.

What counts as PHI

Protected health information (PHI) is any individually identifiable health information. To be PHI, data must:

1. Relate to an individual's past, present, or future physical or mental health condition, healthcare provision, or payment for healthcare

2. Identify (or could reasonably be used to identify) the individual

The 18 identifiers

Under HIPAA's Safe Harbor de-identification standard, the following identifiers must be removed before data is considered de-identified:

Names, geographic subdivisions smaller than a state, dates more specific than year (except for patients over 89), phone numbers, fax numbers, email addresses, social security numbers, medical record numbers, health plan beneficiary numbers, account numbers, certificate or license numbers, vehicle identifiers, device identifiers, web URLs, IP addresses, biometric identifiers, full-face photographs, and any other unique identifier.

What tends to surprise startups

PHI is broader than medical records. A patient's name plus an appointment date plus the name of a healthcare provider is PHI, even without any clinical data attached.

Encryption doesn't change PHI status. Encrypted PHI is still PHI. Any vendor handling it (even without the ability to decrypt it) requires a BAA.

De-identification is a specific process, not a judgment call. HIPAA defines two standards: Safe Harbor (remove all 18 identifiers) and Expert Determination (a qualified expert performs a statistical analysis showing re-identification risk is "very small"). If a business partner says data is "de-identified," verify which standard was applied and how.

Aggregate health data is usually still PHI. Unless properly de-identified per one of those two standards, aggregating records doesn't strip PHI status.

The three HIPAA rules

HIPAA's regulatory framework has three main rules. All three apply to business associates.

The Privacy Rule

The Privacy Rule covers PHI in all forms: oral, written, and electronic. It governs how PHI can be used and disclosed, grants patients specific rights over their data (access, amendment, accounting of disclosures), and requires workforce training and BAAs with all business associates.

For most digital health startups, the Privacy Rule primarily surfaces in two places:

• The obligation to execute BAAs with every vendor that touches PHI

• The minimum necessary standard: only transmit and process the amount of PHI required to accomplish the task. Don't send a full medical record when all you need is a patient identifier.

The Security Rule

The Security Rule covers electronic PHI only. It requires administrative, physical, and technical safeguards, and mandates documented policies and procedures showing how those safeguards were selected and maintained.

The Security Rule is where most of the engineering work lives. But it's also where most startups underestimate scope. The technical controls matter; the administrative controls (risk assessments, policies, incident response procedures, workforce training) are equally required and frequently skipped.

Documentation isn't a bureaucratic afterthought. The Security Rule requires that compliance records (policies, audit logs, risk assessments, training records) be retained for a minimum of six years from creation or last effective date, whichever is later.

The Breach Notification Rule

The Breach Notification Rule defines what constitutes a reportable breach, who must be notified, and how fast. For covered entities, the deadline is 60 days from discovery; for large breaches (500+ individuals), HHS and local media are also notified.

For business associates, the obligation runs to your covered entity customer: notify them "without unreasonable delay and in no case later than 60 days" after discovering a breach. Your BAA may specify a shorter timeline, and it should. Sixty days is the ceiling, not the target. Many BAAs require 24–72 hour initial notification.

The Breach Notification Rule also covers when unauthorized access to encrypted PHI can be excluded from breach reporting, meaning encrypted PHI that is accessed by an unauthorized party is not necessarily a reportable breach if the encryption key was not compromised.

The safeguard framework

The Security Rule organizes its requirements into three categories. All three are required.

Administrative safeguards

Administrative safeguards are the management controls: how your organization selects, implements, and maintains its security program. This is the category most startups underestimate.

Security Management Process

This is the foundation of the entire Security Rule. It has four required elements:

• Risk analysis: A formal assessment of the risks to ePHI confidentiality, integrity, and availability in your environment. Everything else in the Security Rule builds on this. Without a completed risk analysis, you can't demonstrate that your controls were chosen for the right reasons.

• Risk management: A documented plan for addressing identified risks, with prioritization and timelines. The risk analysis identifies what could go wrong; risk management documents what you're doing about it and why.

• Sanction policy: What happens to employees who violate your HIPAA policies, and how you track sanctions.

• Information system activity review: How you audit system and application activity on an ongoing basis.

Security officer

You must designate a person responsible for HIPAA security. At an early startup this is usually the CTO or a senior engineer. It doesn't need to be a dedicated full-time role, but it must be a named individual.

Workforce training

All workforce members with access to PHI must receive HIPAA training. You must retain records demonstrating that training occurred. "We told everyone verbally" isn't evidence of training.

Access management

Documented procedures for establishing, modifying, and terminating access to systems containing PHI. This includes how you onboard employees (access provisioning), how you offboard them (deprovisioning), and how you handle role changes.

Incident response procedures

A documented process for identifying, responding to, and reporting security incidents, including how you determine whether an incident constitutes a breach. "We'll figure it out if something happens" is not a compliant incident response plan.

Contingency planning

Documented data backup, disaster recovery, and emergency mode operation plans. How is PHI backed up? Where? What happens if your primary cloud region goes down? What is the recovery time objective?

BAA management

Documented processes for ensuring your vendor BAAs contain appropriate security obligations and for monitoring vendor compliance.

Physical safeguards

Physical safeguards cover the facilities, hardware, and devices that house ePHI. For cloud-deployed SaaS companies, the physical footprint is usually minimal: your cloud provider handles data center physical controls under their own compliance program.

Your obligations primarily concern workstations, laptops, and policies about where PHI can and cannot be stored.

Key requirements:

• Workstation use policy: Documented rules for how employees use computers to access PHI, including which devices are permitted and under what conditions

• Workstation security: How you secure work computers, including disk encryption, screen lock policies, MDM enrollment, and remote wipe capability

• Device and media controls: Documented procedures for disposing of or reusing devices that handled PHI, including hard drive destruction and documentation of disposal

The most practical physical safeguard for most teams: prohibit PHI from being stored on laptops, phones, or portable media. Keep it in production systems where you have proper controls, backups, and logging.

Technical safeguards

Technical safeguards are the engineering controls. These tend to feel familiar to engineering teams, but note that the Security Rule requires documented policies and evidence of implementation for all of them, not just implementation.

Access controls

• Unique user identification (required): Each user must have a unique identifier for accessing systems containing PHI. Shared accounts are not compliant.

• Emergency access procedure (required): A defined process for accessing PHI in an emergency, for example when the primary administrator is unavailable.

• Automatic logoff (addressable): Sessions on systems containing PHI should terminate after a period of inactivity. For most web applications, 15 minutes is a common standard.

• Encryption and decryption (addressable): Encryption of ePHI at rest and a defined key management procedure. "Addressable" here does not mean optional. See the FAQ below.

Audit controls (required)

Hardware, software, and procedural mechanisms to record and examine access and activity in systems that contain PHI. This means application-level audit logs: who accessed what PHI, what action they took, and when. Logs must be retained for a minimum of six years, protected against tampering, and accessible for review.

Integrity controls

Mechanisms to ensure that ePHI has not been altered or destroyed in an unauthorized manner. At the application level, this typically means access controls that prevent unauthorized writes, database-level checksums, and audit logging of modifications.

Person or entity authentication (required)

Your systems must verify that a person or entity seeking access to ePHI is who they claim to be. Multi-factor authentication is the practical implementation for most production systems. It is not explicitly required by HIPAA, but given current threat models, it is expected by most enterprise healthcare customers and auditors.

Transmission security

ePHI transmitted over a network must be protected against unauthorized interception. TLS 1.2 or higher is the current standard. Deprecated protocols (TLS 1.0, TLS 1.1, SSLv3) are not acceptable.

What "HIPAA compliant" actually means

There is no HIPAA certification. The Office for Civil Rights does not issue certificates. No government body audits you and tells you that you pass.

What HIPAA requires is that you implement reasonable and appropriate safeguards, document them, and be able to demonstrate you did so if OCR investigates or a customer auditor asks. The standard is evidence-based, not attestation-based.

"Reasonable and appropriate" is intentionally flexible. A 10-person startup and a 5,000-person health system operate under the same rules, but with different risk profiles and resources. The Security Rule is a risk-based framework: identify the risks to PHI in your environment, implement controls proportionate to those risks, document your reasoning.

That flexibility is also where startups get into trouble. It's easy to read "reasonable and appropriate" as "we'll do what we can" rather than "we will implement what the rule requires and document why our decisions were sufficient." The former is not a defensible position in an enforcement action.

Penalties

HHS can impose penalties for violations of any HIPAA provision, not just ones that result in a breach. Penalty tiers range from $100–$50,000 per violation depending on culpability, with annual maximums by violation category. A single breach affecting thousands of records can result in multi-million dollar penalties.

That said, OCR typically reserves enforcement actions for cases involving a breach or a pattern of non-compliance. Missing a BAA, skipping a risk assessment, or having no workforce training are all violations. Breaches just attract the attention that surfaces them.

HIPAA vs. HITECH vs. HITRUST

These three terms are often conflated.

One more: SOC 2 Type II is a security audit against AICPA trust services criteria. Not HIPAA-specific, but expected by most healthcare enterprise customers alongside a BAA. SOC 2 Type II plus a current BAA is materially stronger evidence of vendor security posture than a signed BAA alone.

What does HIPAA compliance cost?

Costs vary significantly based on your stage, how much you can inherit from your infrastructure provider, and how manual vs. automated your compliance operations are. Below are realistic ranges for each major category.

A note on total cost at early stage: Most pre-Series A startups spend $1,000–$5,000/month on HIPAA-related infrastructure and tooling, with a larger one-time spend ($10,000–$30,000) to establish initial policies, documentation, and legal review. If you're not yet doing a SOC 2, compliance automation tools are often optional.

The biggest driver of cost is how much of the infrastructure layer you inherit versus build. A managed platform with compliance built in shifts a significant portion of the technical control implementation and evidence generation off your team, along with the annual evidence-gathering work that comes with it.

→ For a stage-by-stage breakdown of when to invest and what to buy, see HIPAA Compliance for Startups.

Compliance by stage

When to start, what to prioritize, and how requirements evolve as your company grows depends heavily on where you are. A pre-revenue team building a prototype has different priorities than a Series A company onboarding its first hospital system.

→ For the full framework, see HIPAA Compliance for Startups.

Frequently asked questions

What's the difference between a covered entity and a business associate?

A covered entity is a healthcare provider, health plan, or clearinghouse that is regulated by HIPAA directly. A business associate is any organization that handles PHI on behalf of a covered entity or another business associate. Most digital health startups are business associates. The test: are you processing, storing, or transmitting PHI on behalf of a healthcare customer? If yes, you are a business associate.

Does my hosting provider need to sign a BAA?

Yes. If your application handles PHI and runs on a provider's infrastructure, that provider must sign a BAA. This applies to your hosting provider, managed database provider, log management service, and any other infrastructure that could process or store data from your application. A provider that declines to sign a BAA cannot be used for systems that handle PHI.

Can I be fined for HIPAA violations without a breach?

Yes. HHS can impose penalties for violations of any provision of the HIPAA rules, not just ones that result in a breach. Missing a risk assessment, not executing BAAs, or having no workforce training are all violations. Breaches tend to attract the OCR scrutiny that surfaces those gaps, but the underlying violations exist independently.

What does "addressable" mean in the Security Rule?

The Security Rule distinguishes between "required" and "addressable" implementation specifications. Addressable does not mean optional. It means you must assess whether the implementation is reasonable and appropriate for your environment, and either implement it or document why you implemented an equivalent alternative. In practice, for any cloud-deployed application handling PHI, encrypting data at rest and in transit is expected. "Addressable" very rarely provides justification to skip it.

How long do I need to retain compliance documentation?

HIPAA requires retention of Security Rule compliance documentation (policies, risk assessments, training records, audit logs) for a minimum of six years from creation or last effective date, whichever is later. Some state laws require longer retention periods. Check your specific state requirements.

What should I look for in a hosting provider's HIPAA offering?

At minimum: a signed BAA, AES-256 encryption at rest, TLS 1.2+ in transit, audit logging with tamper-evident storage, network isolation, and documented security certifications (SOC 2 Type II report or HITRUST R2). Be cautious of providers who will sign a BAA but provide no evidence of the controls the BAA obligates them to maintain.

What's HITRUST and do I need it?

HITRUST R2 is a third-party certification against the HITRUST Common Security Framework, a comprehensive control set that incorporates HIPAA, NIST, ISO 27001, and other frameworks. It is not required by law. It is, however, frequently required by large healthcare enterprise customers as a condition of their vendor approval process. If your market is hospital systems and large payers, expect to need HITRUST R2 certification at some point. If you're selling to smaller practices or early-stage health companies, SOC 2 Type II is often sufficient.

What is PHI de-identification and when does it apply?

De-identification is the process of removing or transforming data so that it no longer identifies (or could reasonably identify) an individual. De-identified data is not PHI and is not subject to HIPAA. HIPAA defines two acceptable de-identification methods: Safe Harbor (remove all 18 specified identifiers) and Expert Determination (a qualified expert applies statistical methods to demonstrate that re-identification risk is very small). Unless one of these methods has been applied, assume data is still PHI.

Do I need a separate BAA for every AWS service I use?

If you use AWS independently (for example, storing PHI in S3 directly), yes: you would execute a BAA with AWS. If you run on Aptible, Aptible's BAA covers the infrastructure layer, and Aptible's BAA with AWS covers the underlying services. Aptible customers don't need a direct BAA with AWS unless they use AWS services outside of Aptible.

What does HIPAA compliance cost?

Costs vary by stage and approach. Early-stage teams typically spend $1,000–$5,000/month on HIPAA-eligible infrastructure and tooling, with a one-time $10,000–$30,000 for initial policies, legal review, and risk assessment setup, assuming no SOC 2 audit yet. Compliance automation tools (Vanta, Drata) run $5,000–$20,000/year and are most cost-effective once you're running recurring audits. A first SOC 2 Type II audit typically costs $15,000–$50,000. HITRUST R2 certification, if required, runs $50,000–$200,000+ depending on scope and readiness. The biggest cost lever is how much of the infrastructure compliance layer you inherit from your hosting provider versus build and maintain yourself.

How do I become HIPAA compliant?

There is no official certification or government approval process. Becoming HIPAA compliant means: (1) determining whether HIPAA applies to your organization; (2) mapping where PHI flows through your systems; (3) executing BAAs with all vendors that touch PHI; (4) implementing and documenting the required administrative, physical, and technical safeguards; and (5) maintaining that program on an ongoing basis through training, risk assessments, incident response, and policy reviews. Most organizations demonstrate compliance to customers and auditors through a combination of a signed BAA and a SOC 2 Type II report.

Next steps

If you're reviewing a BAA: → What is a HIPAA BAA: what terms to look for and how BAA access varies by provider

If you're building with AI or LLMs: → HIPAA-Compliant AI: BAA requirements, audit logging patterns, de-identification, and AI gateway options

Want infrastructure that handles the technical safeguards by default? Aptible is a HIPAA-compliant platform built for digital health. Every deployment includes a signed BAA, encryption at rest and in transit, audit logging, network isolation, and HITRUST R2-certified controls. Learn more about Aptible →

This guide is for informational purposes only. Aptible is not a law firm, and nothing here constitutes legal advice. Contact an attorney for advice specific to your organization's compliance obligations.