HIPAA-Compliant App Development: What Your Dev Company Must Know (2026)

HIPAA compliance is not a feature you add to an app at the end — it's an architecture decision you make at the beginning. We've seen teams spend $40,000 retrofitting HIPAA controls onto a finished product that would have cost $8,000 to build in from day one.

This guide covers the technical requirements for HIPAA-compliant app development in 2026: what the law actually requires of your engineering team, what vendors you need BAAs with, and how to build a compliant cloud architecture.

What HIPAA actually requires (the engineering summary)

HIPAA's Security Rule requires "appropriate administrative, physical, and technical safeguards to protect the confidentiality, integrity, and availability of electronic protected health information (ePHI)."

Translated into engineering requirements:

1. Encryption at rest

All ePHI must be encrypted when stored. The standard is AES-256.

• Database: PostgreSQL with encrypted tablespace, or RDS with encryption enabled at rest
• File storage: S3 with server-side encryption (SSE-S3 or SSE-KMS)
• Backups: Encrypted with the same key management as production data
• Developer laptops: Full-disk encryption (FileVault on Mac, BitLocker on Windows) — developers must not store PHI locally

-- PostgreSQL: enable encryption at tablespace level
CREATE TABLESPACE encrypted_ts
  LOCATION '/var/lib/postgresql/encrypted'
  WITH (encryption = on);

-- Or use AWS RDS with storage_encrypted = true in Terraform
resource "aws_db_instance" "hipaa" {
  storage_encrypted = true
  kms_key_id        = aws_kms_key.hipaa.arn
}

2. Encryption in transit

All data in transit must use TLS 1.2 or higher. TLS 1.0 and 1.1 are not acceptable.

• All API endpoints HTTPS only
• No HTTP redirect — return 301 with HSTS header
• Internal service-to-service communication: mutual TLS (mTLS) for high-sensitivity data

# Nginx: enforce TLS 1.2+, disable older protocols
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers on;
add_header Strict-Transport-Security "max-age=63072000" always;

3. Access controls

Access to PHI must be limited to users who need it for their role (minimum necessary standard).

Required:

• Role-based access control (RBAC) — users see only PHI relevant to their role
• Unique user IDs — no shared accounts, no service accounts used by multiple people
• Automatic session timeout — 15 minutes of inactivity is the standard; 30 minutes is acceptable with documented risk assessment
• Multi-factor authentication for all users who access PHI (required since the HHS October 2025 update)

// Middleware: enforce session timeout and MFA
const HIPAA_SESSION_TIMEOUT_MS = 15 * 60 * 1000; // 15 minutes

export function hipaaSessionMiddleware(req, res, next) {
  const session = req.session;

  if (!session?.userId) return res.status(401).json({ error: 'Not authenticated' });
  if (!session?.mfaVerified) return res.status(403).json({ error: 'MFA required' });

  const lastActivity = session.lastActivity || 0;
  if (Date.now() - lastActivity > HIPAA_SESSION_TIMEOUT_MS) {
    session.destroy();
    return res.status(401).json({ error: 'Session expired' });
  }

  session.lastActivity = Date.now();
  next();
}

4. Audit logging

Every access to PHI must be logged. Logs must be tamper-evident and retained for 6 years.

Log every:

• User login and logout
• PHI record view (which user, which record, what time)
• PHI record create/update/delete
• Failed login attempts
• Permission changes
• Export or download of PHI

// Audit log middleware for PHI access
async function logPhiAccess(userId: string, action: string, resourceId: string, resourceType: string) {
  await db.auditLog.create({
    data: {
      userId,
      action,       // 'VIEW' | 'CREATE' | 'UPDATE' | 'DELETE' | 'EXPORT'
      resourceId,   // Patient record ID, document ID, etc.
      resourceType, // 'PATIENT_RECORD' | 'DOCUMENT' | etc.
      ipAddress: req.ip,
      userAgent: req.headers['user-agent'],
      timestamp: new Date(),
    }
  });
}

Store audit logs separately from application data — in an append-only store (AWS CloudWatch Logs or a separate audit database with no delete permissions for the application user).

5. Backup and disaster recovery

• Backups must be tested (restore from backup at least quarterly)
• RTO (Recovery Time Objective) and RPO (Recovery Point Objective) must be documented
• Backups must be encrypted
• Backups must be stored in a separate location from production data

6. Breach notification procedures

Document before launch (not after a breach):

• Who is notified internally when a breach is suspected?
• What is the timeline for investigation?
• When is HHS notified (required within 60 days of discovering a breach affecting 500+ individuals)?
• When are patients notified (required within 60 days)?

Business Associate Agreements (BAAs): who you need them with

A BAA is a contract between a Covered Entity (healthcare provider, insurance company) and a Business Associate (any vendor who handles PHI on their behalf). You need a BAA with every vendor whose infrastructure touches PHI.

BAA required with:

Vendor type	Examples	BAA available?
Cloud infrastructure	AWS, Azure, GCP	Yes — all three offer BAAs
Database managed service	AWS RDS, Supabase, Neon	AWS RDS: yes. Supabase: yes. Neon: contact them
Email provider	AWS SES, SendGrid, Mailgun	AWS SES: yes. SendGrid: yes (Business plan+). Mailgun: yes
Authentication	Auth0, Okta, Clerk	Auth0/Okta: yes. Clerk: yes
Monitoring/error tracking	Datadog, Sentry	Datadog: yes. Sentry: yes (Business plan+)
Video calls (telemedicine)	Zoom, Doxy.me	Zoom for Healthcare: yes. Doxy.me: yes
Storage	AWS S3, Cloudflare R2	AWS S3: yes. Cloudflare R2: BAA available on Enterprise
Analytics	Mixpanel, Amplitude	Mixpanel: yes. Amplitude: yes

BAA NOT available (avoid for PHI):

• Google Analytics (use Mixpanel or a self-hosted alternative)
• Twilio (for SMS containing PHI — use Twilio's HIPAA-eligible products with BAA specifically)
• ChatGPT / OpenAI API (no BAA — use Azure OpenAI Service which does offer BAA)
• Cloudflare Workers (BAA available only on Enterprise)

HIPAA-compliant AWS architecture

AWS is the most commonly used cloud platform for HIPAA-covered applications. AWS will sign a BAA covering most of their HIPAA-eligible services.

HIPAA-compliant AWS architecture reference:

Region: us-east-1 (or us-west-2)
├── VPC (private networking, no public subnets for data services)
│   ├── Application tier (private subnet)
│   │   └── ECS Fargate (containerised API — no persistent data)
│   ├── Data tier (private subnet, no internet access)
│   │   ├── RDS PostgreSQL (Multi-AZ, encrypted, automated backups)
│   │   └── ElastiCache Redis (session storage, encrypted)
│   └── Storage
│       └── S3 (server-side encryption, versioning enabled, access logging)
├── CloudTrail (API audit logging, 7-year retention)
├── CloudWatch Logs (application audit logs, encrypted)
├── AWS KMS (key management for all encryption)
├── AWS WAF (web application firewall)
└── AWS Config (compliance monitoring — flags unencrypted resources)

Critical AWS settings to verify:

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

# Check S3 bucket encryption
aws s3api get-bucket-encryption --bucket your-phi-bucket

# Check CloudTrail is enabled
aws cloudtrail get-trail-status --name your-trail

# Check that no S3 buckets are public
aws s3api list-buckets | jq '.Buckets[].Name' | xargs -I{} aws s3api get-bucket-acl --bucket {}

The HIPAA developer checklist (12 items)

Before any HIPAA application goes to production, verify all 12:

• Encryption at rest: Database, file storage, and backups all encrypted with AES-256
• Encryption in transit: TLS 1.2+ enforced on all endpoints. HSTS header present.
• No PHI in logs: Application logs filtered to exclude patient names, DOBs, SSNs, diagnosis codes
• Role-based access control: Users cannot access PHI outside their defined role
• MFA enabled: All users who access PHI have MFA required
• Session timeout: Automatic timeout after 15–30 minutes of inactivity
• Audit logging: Every PHI access logged with user ID, timestamp, resource ID
• Audit log protection: Application cannot delete its own audit logs
• BAAs signed: BAA signed with every vendor whose infrastructure touches PHI (see list above)
• Backup tested: Restore from backup verified within the last 90 days
• Security Risk Assessment: Documented SRA completed before go-live
• Incident response plan: Written procedure for breach response, HHS notification, patient notification

What HIPAA compliance adds to development cost

HIPAA-specific engineering adds cost in four areas:

Area	Extra time	Cost premium
Audit logging infrastructure	1–2 weeks	$5,000–$12,000
RBAC implementation (vs simple auth)	1 week	$4,000–$8,000
Encryption key management	3–5 days	$2,000–$5,000
Security testing (pen test + HIPAA-specific review)	1–2 weeks	$5,000–$15,000
Documentation (SRA, policies, BAA management)	1 week	$3,000–$6,000
Total premium	4–8 weeks	$19,000–$46,000

As a percentage: HIPAA compliance adds 20–30% to a typical healthcare application's development cost. A $100,000 app becomes $120,000–$130,000. A $50,000 app becomes $60,000–$65,000.

The penalty for getting it wrong: HIPAA fines range from $100 to $50,000 per violation, with an annual maximum of $1.9M per violation category. The average data breach at a healthcare organisation cost $10.9M in 2024 (IBM Cost of a Data Breach Report). The $20,000 compliance premium is cheap insurance.

Frequently asked questions

Does our development team need to be HIPAA-certified? There's no such thing as "HIPAA certification" for developers — it's not a professional credential. What matters is that your vendor understands HIPAA's technical requirements (covered in this guide) and has implemented them before on real projects. Ask for references from healthcare clients.

Can we use Firebase/Supabase for a HIPAA app? Firebase: Google offers a BAA for Healthcare customers, but many Firebase products (Analytics, Crashlytics) are not HIPAA-eligible. Supabase: yes, they offer a BAA. PostgreSQL-based, so encryption at rest is supported.

Do we need HIPAA compliance if we only use de-identified data? If data has been properly de-identified following HIPAA's Safe Harbor or Expert Determination method, it's no longer PHI and HIPAA doesn't apply. However, re-identification is a risk — get legal advice before relying on de-identification as a compliance strategy.

What about GDPR if we have EU patients? GDPR and HIPAA have overlapping but different requirements. Most HIPAA-compliant applications are largely GDPR-compliant (encryption, access controls, audit logs, data subject rights). Key differences: GDPR requires data subject access requests to be fulfilled within 30 days, and breach notification within 72 hours (vs HIPAA's 60 days). Build HIPAA first, then review the GDPR delta.

Who signs the BAA — us or our development vendor? Your development vendor signs a BAA with you (the Covered Entity or Business Associate). They also need BAAs in place with their own infrastructure vendors (AWS, database provider, etc.). When vetting a dev company, ask them to confirm which of their infrastructure vendors have signed BAAs.

---

Building a HIPAA-compliant healthcare application? Talk to our healthcare development team → — we sign BAAs, have delivered 15+ HIPAA applications, and can walk you through compliance requirements specific to your product.