Blog

HIPAA for SaaS Developers: What You Actually Need to Know

Published March 17, 2026 · 11 min read

You built a SaaS product. Maybe it is a scheduling tool for clinics. Maybe it is an analytics dashboard that happens to process patient survey data. Maybe your CRM just added a healthcare vertical. Then someone asks: “Are you HIPAA compliant?”

HIPAA is not just for hospitals. Any application that handles Protected Health Information (PHI) on behalf of a healthcare entity falls under HIPAA. That includes your SaaS if it touches health data in any way. This guide breaks down what HIPAA actually requires from a developer perspective — no legal jargon, just the technical reality.

1. Who actually needs HIPAA compliance

HIPAA (Health Insurance Portability and Accountability Act) applies to two categories of organizations:

SaaS products that often need HIPAA

• Telehealth and appointment scheduling. Any app connecting patients with providers.
• EHR integrations. If your API pulls or pushes data to Epic, Cerner, or any electronic health record system.
• Patient messaging and communication. Secure messaging, email, or notification services handling health information.
• Health analytics and reporting. Dashboards, population health tools, or clinical trial platforms.
• Billing and claims processing. Any system handling insurance claims, medical billing codes, or payment data tied to health services.
• Cloud hosting and infrastructure. If you host or store PHI on behalf of a healthcare client, even as an infrastructure provider.

2. What counts as PHI (the 18 identifiers)

Protected Health Information (PHI) is any individually identifiable health information that is created, received, maintained, or transmitted by a covered entity or business associate. The key word is “individually identifiable” — health data that cannot be linked back to a specific person is not PHI.

HIPAA defines 18 types of identifiers. If any of these appear alongside health information, the data is PHI:

ePHI: the digital version

Electronic Protected Health Information (ePHI) is PHI in electronic form — stored in a database, transmitted over an API, logged in an error tracker, or cached in a browser. As a developer, virtually all PHI you encounter is ePHI, and the HIPAA Security Rule applies specifically to ePHI.

3. Technical safeguards: encryption, audit logs, access controls

The HIPAA Security Rule defines three categories of safeguards: administrative (policies and procedures), physical (facility access), and technical (the technology controls developers implement). Here is what the technical safeguards actually mean for your code.

Encryption

HIPAA classifies encryption as “addressable” rather than “required.” In practice, this distinction is meaningless. HHS has made clear that failing to encrypt ePHI without implementing an equivalent alternative measure is a violation. Treat encryption as mandatory.

• At rest: AES-256 encryption for databases, file storage, and backups. Use managed encryption (AWS RDS encryption, GCP Cloud SQL encryption) or application-level encryption for sensitive fields.
• In transit: TLS 1.2 or higher for all connections. This includes API calls, database connections, internal service communication, and any data transfer between systems.
• Key management: Use a dedicated KMS (AWS KMS, GCP Cloud KMS, Azure Key Vault). Never store encryption keys alongside the data they protect. Rotate keys on a documented schedule.

# Check RDS encryption at rest
aws rds describe-db-instances \
  --query 'DBInstances[*].[DBInstanceIdentifier,StorageEncrypted]'

# Check S3 bucket encryption
aws s3api get-bucket-encryption \
  --bucket my-phi-bucket

# Verify TLS version on your endpoint
openssl s_client -connect api.yourapp.com:443 \
  -tls1_2 < /dev/null 2>&1 | grep "Protocol"

Audit logs

HIPAA requires audit controls that record and examine activity in systems containing ePHI. Your audit logs must capture:

• Who accessed the data (authenticated user identity)
• What data was accessed, created, modified, or deleted
• When the access occurred (timestamp)
• Where the access originated (IP address, system)
• Outcome of the access attempt (success or failure)

Audit logs must be tamper-proof (write-once storage or append-only), retained for a minimum of six years, and regularly reviewed. Failed login attempts, privilege escalations, and PHI exports should trigger alerts.

Access controls

The HIPAA Security Rule requires four access control mechanisms:

Beyond these four requirements, implement role-based access control (RBAC) with the principle of least privilege. Users should only access the minimum PHI necessary to perform their function. MFA should be enforced for any system that stores or accesses ePHI.

4. Business Associate Agreements (BAAs)

A Business Associate Agreement (BAA) is a legally binding contract between a covered entity and a business associate (you). It is not optional. HIPAA requires a BAA to be in place before any PHI is shared.

When you need a BAA

• With your healthcare customers. If a hospital or clinic uses your SaaS and any PHI flows through it, you need a BAA with that customer.
• With your sub-processors. If you use AWS, GCP, or Azure to store ePHI, you need a BAA with that cloud provider. If you use a third-party email service to send appointment reminders containing PHI, you need a BAA with them too.
• With any vendor that touches PHI. Database hosting, error tracking (if it captures PHI), backup services, analytics providers — any vendor that could access ePHI needs a BAA.

What a BAA must include

• Permitted and required uses of PHI
• Agreement not to use or disclose PHI beyond what the contract allows
• Requirement to implement appropriate safeguards
• Obligation to report breaches and security incidents
• Terms for returning or destroying PHI when the contract ends
• Right for the covered entity to terminate the contract if the business associate violates HIPAA

5. How Codepliant detects health-related services

Codepliant scans your codebase to detect services, integrations, and configurations that indicate health data handling. It identifies patterns that are relevant to HIPAA compliance and generates documentation grounded in your actual implementation.

npx codepliant go

Scanning project...
  Detected: Node.js + TypeScript
  Detected: AWS S3 (encrypted at rest), RDS (encrypted)
  Detected: Auth0 (MFA configured)
  Detected: FHIR API integration (health data)
  Detected: Twilio (patient notifications)
  Detected: Winston logging (structured audit logs)
  Detected: Redis session store (auto-expiry configured)

Generating documents...
  [+] HIPAA Compliance Checklist
  [+] Privacy Policy (HIPAA-aware)
  [+] Data Processing Inventory
  [+] Access Control Policy
  [+] Encryption Policy
  [+] Audit Log Policy
  [+] Breach Notification Plan
  [+] Business Associate Agreement Template

8 documents generated in compliance-docs/

Here is what Codepliant looks for when assessing HIPAA relevance:

Every generated document reflects what Codepliant actually found in your code. If it detects Auth0 with MFA configured, your Access Control Policy references that specific setup. If it finds unencrypted S3 buckets, the HIPAA Compliance Checklist flags it as a gap requiring remediation.

The goal is not to replace legal counsel — it is to give you an accurate starting point so your compliance effort is grounded in technical reality rather than guesswork.

6. Get started now

HIPAA compliance starts with understanding what your application actually does with health data. Scan your codebase, identify gaps, and generate the documentation your compliance program needs. One command: