How to design a SaaS for HIPAA from day 1

To design a SaaS for HIPAA from day 1, treat Protected Health Information (PHI) as a contaminant: catalog every field that touches it, run only on vendors that will sign a Business Associate Agreement (BAA), encrypt everything at rest and in transit, and instrument tamper-evident audit logs before you ship a single feature. The decisions made in week one (which database, which logging vendor, which payment processor) lock in your compliance posture for years.

The painful part is not the encryption or the audit logs. It is the vendor list. Most of the SaaS tools founders reach for in 2026 (Stripe, Datadog, PostHog, Vercel Edge logs) either do not sign BAAs at all, or only sign on enterprise tiers that cost 5x the standard plan. If you skip this question on day 1, you end up rewriting your billing layer, your analytics stack, and your observability stack on the eve of your first hospital contract.

Why HIPAA-from-day-1 matters more in 2026

Two things changed recently. First, HHS Office for Civil Rights raised civil penalty caps and started publishing settlements against small SaaS vendors, so the deterrent has teeth. Second, AI scribes, telehealth platforms, and digital therapeutics pulled thousands of seed-stage companies into PHI handling for the first time, often on a stack that stored PHI in non-BAA tools.

Designing for HIPAA on day 1 costs roughly 15 to 25 percent of engineering time in the first three months. Retrofitting after product-market fit is closer to a full quarter of engineering output, plus the risk that an early breach ends the company.

If you have already mapped the cost to add SOC 2 compliance to your SaaS, HIPAA shares about 60 percent of the controls but adds three SOC 2 does not require: a signed BAA chain, the 60-day Breach Notification Rule, and a narrower definition of acceptable data handling.

Step 1: Build the PHI data inventory before you write code

Open a spreadsheet. List every data field your app will store or transmit. For each one, mark whether it is PHI under HIPAA. The 18 HIPAA identifiers are well defined: names, geographic subdivisions smaller than a state, dates tied to an individual, contact info, SSNs, medical record numbers, account numbers, device IDs, URLs, IP addresses, biometrics, photos, and any other unique identifying code.

The trap is that "PHI" is not just the diagnosis. A name plus a date of service is PHI. An email plus a visit timestamp is PHI. An IP logged alongside a telehealth session is PHI.

Once you have the inventory, each field gets one of three labels:

1. Store as PHI (encrypted, BAA-covered system, audit logged).
2. De-identify under HIPAA Safe Harbor (strip all 18 identifiers, then it can flow into your analytics stack).
3. Do not collect.

Option three is almost always the cheapest. If you do not need the exact birthdate, ask for age range. The smallest PHI surface wins every audit.

Step 2: Pick BAA-covered vendors only (the part that breaks budgets)

This is the single most expensive decision in HIPAA design. A surprising number of standard SaaS tools either refuse to sign BAAs or hide BAA support behind enterprise pricing.

Category	HIPAA-friendly (will sign BAA)	HIPAA-blocking on standard plans
Cloud infra	AWS, GCP, Azure (BAA via free Business Associate Addendum)	DigitalOcean App Platform (BAA on Premier support only)
Database	MongoDB Atlas (Dedicated tier), AWS RDS, Google Cloud SQL, Supabase Enterprise	Supabase Free/Pro, Neon Free, PlanetScale Hobby
Email	AWS SES, Postmark (paid BAA add-on), Paubox	SendGrid Free, Mailchimp, Resend (no BAA as of 2026)
Logging / APM	Datadog (HIPAA SKU), AWS CloudWatch, New Relic (HIPAA add-on)	Sentry SaaS standard plans, Logtail/Better Stack standard, PostHog Cloud (BAA on Enterprise only)
Payments	Stripe (PHI must never enter Stripe), TrueMed for HSA/FSA	Stripe does NOT sign BAAs. Never put PHI in metadata, descriptions, or customer fields.
Analytics	Mixpanel Enterprise (BAA), Heap (BAA), Freshpaint	Google Analytics 4 (no BAA), Posthog Cloud standard, Amplitude standard
Auth	AWS Cognito, Auth0 (Enterprise tier only), Stytch (BAA on B2B Pro)	Clerk (no BAA as of early 2026), Firebase Auth standard tier
CI/CD	GitHub Actions on self-hosted runners, GitLab Dedicated	Vercel Hobby/Pro, Netlify Standard (no BAA on hosted compute that touches PHI)
AI / LLM	AWS Bedrock, Azure OpenAI Service, Google Vertex AI, Anthropic (BAA available on enterprise contract)	OpenAI API standard, Cohere standard, public Claude.ai

The Stripe row trips up almost every health-tech founder. Stripe does not sign BAAs, so no PHI may ever enter a Stripe field. Your customer ID cannot be the patient's MRN, subscription metadata cannot include diagnosis codes, invoice line items cannot describe the service. Pattern: opaque internal ID in Stripe, PHI mapping in your BAA-covered database.

Vercel is the second sharp edge. Hobby and Pro do not cover PHI, and the Edge Runtime logs request paths and headers (which can include PHI in query strings or tokens). Deploy the API on AWS, GCP, or Azure, and use Vercel only for the marketing site.

Step 3: Encryption at rest and in transit (table stakes, but verify)

HIPAA's Security Rule does not technically mandate encryption, but it treats unencrypted PHI as a breach by default under the Breach Notification Rule. Encrypted PHI that leaks is not a reportable breach if the encryption meets NIST standards. So in practice: encrypt everything.

The 2026 baseline:

• At rest: AES-256 for the database (RDS, Atlas, Cloud SQL all default to this), AES-256 for object storage (S3 SSE-KMS, GCS CMEK), full-disk encryption on any compute. Manage keys with AWS KMS, Cloud KMS, or HashiCorp Vault. Rotate keys at least annually.
• In transit: TLS 1.3 (or TLS 1.2 with strong cipher suites at minimum) for every connection, including service-to-service calls inside the VPC. Pin certificates for mobile clients.
• Backups: encrypted with separate keys from the primary database, stored in a different region.
• Field-level encryption for the most sensitive columns (SSN, diagnosis codes). MongoDB Atlas offers Queryable Encryption; Postgres has pgcrypto and AWS RDS Proxy with TLS termination at the application layer.

Tools like HashiCorp Vault for handling secrets in production become non-optional once you have a key-rotation schedule and an auditor asking how you separated KMS access from application access.

Step 4: Audit logs that survive a subpoena

The HIPAA Security Rule requires audit controls on any system that creates, receives, maintains, or transmits PHI. The standard interpretation in 2026: every read, write, export, and admin action on PHI is logged with the user identity, timestamp, action, and the resource accessed. Logs are append-only, retained for at least 6 years, and tamper-evident.

The practical setup:

• Application-level audit logs go to a dedicated stream (AWS Kinesis or CloudWatch Logs in a separate account, GCP Cloud Logging with a sink to a locked bucket).
• The destination bucket has object lock enabled and write-once-read-many (WORM) policies, so nobody (including your CTO) can delete logs.
• Every audit record carries a request ID that ties the application log to the infrastructure log and the database query.
• A weekly job hashes the previous week's logs and signs the hash, so future tampering is detectable.

You will be asked, by your first hospital customer, to produce "all access to patient X's record in the last 12 months" as a CSV within 24 hours. Design the audit log so this is a SQL query, not a forensics project.

Step 5: Access controls, role minimization, and the principle of least privilege

HIPAA expects role-based access control, unique user IDs (no shared logins), automatic logoff, and emergency access procedures. The modern implementation:

• SSO for all employees (Okta, Google Workspace, or Microsoft Entra), enforced via SAML or OIDC.
• Hardware security keys for admin and engineering access. Phishing-resistant MFA is no longer optional.
• Role-based access in the application with deny-by-default. Engineers do not have production database access; production debugging happens through audited break-glass tooling.
• Just-in-time access grants for incident response (Teleport, AWS Identity Center, or homegrown approval workflow), with auto-expiry and full audit trail.
• Session timeouts of 15 minutes for clinical UIs (most hospital security reviews require this).

If you adopt feature flags with safe rollout early, you also get a clean way to ship PHI-touching features dark, validate the audit trail, then ramp.

Step 6: Vendor management, employee training, and the policy stack

The Security Rule requires written policies, workforce training, and a designated Security Officer and Privacy Officer (founders almost always wear these hats at first). The minimum viable policy stack:

• Acceptable use policy
• Access control and identity management policy
• Incident response plan (with the 60-day breach notification clock)
• Data classification and handling policy
• Vendor management policy (and a register of every BAA, with renewal dates)
• Workforce security and termination procedures
• Risk analysis and risk management plan (refreshed annually)

Tools like Vanta, Drata, and Secureframe automate the evidence collection for around $7,500 to $15,000 per year, and they will pre-fill 70 percent of the HIPAA policy templates. They are not a substitute for a real risk analysis, but they cut the documentation overhead by a quarter.

Employees who touch PHI need annual training. Free courses from HHS work fine for under-20 teams; KnowBe4 and Curricula are the paid options at scale.

Step 7: Breach notification, incident response, and the 60-day clock

The HIPAA Breach Notification Rule gives you 60 calendar days from discovery to notify affected individuals, HHS, and (for breaches over 500 individuals) prominent media in the affected state. The clock starts when any member of your workforce discovers the breach, not when leadership is informed.

What this means operationally:

• The incident response runbook must include a "is this a HIPAA breach?" decision tree on page one.
• The encryption posture from Step 3 is what determines whether an incident is a notifiable breach. Encrypted PHI that leaks is presumptively safe.
• Document the four-factor risk assessment (nature of PHI, who received it, was it acquired, mitigation) for every incident, even the ones you conclude are not breaches.
• Run a tabletop exercise quarterly. Most teams fail their first one because nobody knows who calls the lawyer.

For the actual incident retrospective, the same discipline as a good production postmortem applies. We wrote a longer playbook on how to write a postmortem after an incident that doubles as a HIPAA-acceptable incident record if you add the breach-assessment section.

When you can skip parts of this

Be honest about scope. If your product touches mental-wellness journaling but never identifies the user or stores anything a doctor sees, you may not be a covered entity or a business associate at all. Talk to a HIPAA-experienced lawyer for two hours (Bnard, Hooper Lundy, or Cooley Health, around $400 to $600/hr) before assuming you are in scope. A definitive "not in scope" letter is worth the spend.

If you are clearly in scope but pre-revenue, you can defer the formal SOC 2 work, the paid GRC tool, and the third-party penetration test (all of which are SOC 2 niceties, not HIPAA requirements). What you cannot defer: the BAA-covered vendor stack, encryption, audit logs, and the policy stack. Those four are the difference between a 60-day clock starting on Day 0 of a breach and a company-ending lawsuit.

What to do this week

If you are building a health-tech SaaS right now and you have not done the PHI inventory, that is the highest-leverage 4 hours you will spend this quarter. Block a morning, open a spreadsheet, list every field, and mark each as PHI / de-identified / not collected. Then take your vendor list and check each one against the BAA column above. Anything in the right column gets a replacement plan dated within the next 30 days.

If the engineering work to migrate off non-BAA vendors is larger than your team can absorb in a sprint, this is the kind of bounded, high-stakes infrastructure project that a senior contractor can own end-to-end. On Cadence, the Senior tier ($1,500/week) is the right fit for a HIPAA migration: someone who has done AWS KMS rollouts, knows the difference between RDS encryption and field-level encryption, and can stand up the audit log pipeline without supervision. The 48-hour trial is enough to scope the migration before you commit to weeks of work.

If you are scoping a HIPAA-from-day-1 build and want a second pair of eyes on the architecture (or someone who has migrated three health-tech apps off Vercel and Clerk already), book a Senior engineer on Cadence. 48-hour free trial. Weekly billing. Cancel any week. Median time to first commit across the platform is 27 hours.

For an upstream guard against the most common security gaps that bite HIPAA audits (injection, broken access control, insecure design), the OWASP Top 10 implementation playbook covers the patterns auditors specifically look for.

FAQ

How long does it take to design a HIPAA-compliant SaaS from scratch?

For a two-engineer team building greenfield, plan 6 to 10 weeks of infrastructure work before shipping the first PHI-touching feature. That covers BAA execution, encryption setup, audit log pipeline, SSO, and policy documentation. Maintenance after is roughly 10 percent of engineering time.

Do I need to be HIPAA-compliant if I am only handling de-identified data?

No, but de-identification under HIPAA Safe Harbor is strict: remove all 18 identifiers, including dates more granular than year and ZIPs more specific than the first three digits. The alternative is Expert Determination, which requires a statistician's sign-off. Most teams who think they are de-identified are not.

Can I use OpenAI or Anthropic for an AI feature that processes PHI?

Not on the standard public APIs. Route through AWS Bedrock (Claude, Llama, Mistral under AWS BAA), Azure OpenAI Service (GPT under Azure BAA), or Google Vertex AI (Gemini under Google Cloud BAA). Anthropic signs BAAs on enterprise contracts directly, but the public Claude API does not include BAA coverage.

How much does HIPAA compliance cost in tooling per year?

For a seed-stage health-tech SaaS, budget $25,000 to $60,000 per year: GRC tool ($7,500 to $15,000), HIPAA-eligible logging ($5,000 to $15,000 above standard plans), enterprise tier upgrades on Auth0 or Mixpanel ($10,000 to $20,000), and an annual third-party security assessment ($8,000 to $15,000).

Is HIPAA harder than SOC 2 to implement?

They overlap heavily. HIPAA has a narrower technical scope but stricter PHI handling rules and a hard breach-notification clock. SOC 2 is broader and demands more documented evidence. Doing HIPAA first makes SOC 2 cheaper, because the audit log, access control, and incident response work transfers directly.