HIPAA Compliance for Health Tech Startups

Where Does That Data Go?

You're building a health app. A user opens it, enters their diagnosis, uploads a lab result, logs a symptom. They trust you with information they might not even share with their family. Now ask yourself: where does that data actually go? Is it encrypted? Who can access it? Is there an audit trail? Could a curious engineer on your team pull up a patient's records?

If you don't know the answers, you have a HIPAA problem — even if you've never heard of HIPAA before today.

The Health Insurance Portability and Accountability Act isn't optional for health tech. It's not a nice-to-have certification you pursue when you're bigger. If your application touches Protected Health Information and you're not compliant, you're exposed to fines that start at $100 per violation and scale to $2 million per year per violation category. The OCR — the enforcement arm of HIPAA — has collected over $140 million in penalties since 2003, and enforcement has accelerated dramatically in the last few years.

This isn't meant to scare you out of building health tech. It's meant to get you building it correctly from the start, because retrofitting HIPAA compliance into an existing codebase is far more expensive than building it in from day one.

What HIPAA Actually Requires

HIPAA has two rules that matter for tech startups. Skip the Privacy Rule at your own risk, but the Security Rule is where engineering meets compliance.

Protected Health Information (PHI) is broader than you think. PHI isn't just diagnoses and prescriptions. It's any individually identifiable health information: names combined with medical records, email addresses linked to health conditions, IP addresses associated with symptom searches, even device IDs tied to health data. If your app knows both who someone is and anything about their health, that's PHI.

The Privacy Rule governs how PHI is used and disclosed. It defines who can see patient data, what they can do with it, and what rights patients have over their own information. Patients can request access to their data, request corrections, and ask for an accounting of who has accessed their records. Your app needs to support all of these workflows.

The Security Rule is the technical backbone. It requires three categories of safeguards:

• Administrative safeguards — risk assessments, workforce training, security policies, incident response procedures, and a designated security officer. Yes, even at a 5-person startup.
• Physical safeguards — controls on physical access to systems that store PHI. In a cloud-native world, this mostly means choosing data centers and cloud providers that maintain their own physical security certifications.
• Technical safeguards — access controls, audit logging, encryption, integrity controls, and transmission security. This is where most of your engineering effort goes.

Business Associate Agreements (BAAs) are non-negotiable. Every third-party service that touches PHI — your cloud provider, your database host, your email service, your analytics platform — must sign a BAA with you. AWS, GCP, and Azure all offer BAAs. Stripe does too. But that hip new startup tool you found on Product Hunt? Probably not. If a vendor won't sign a BAA, they cannot touch PHI. Full stop.

The Technical Requirements

Here's what your engineering team actually needs to build. These aren't aspirational best practices — they're compliance requirements with legal teeth.

Encryption at rest and in transit. Every database, file store, and backup that contains PHI must be encrypted. AES-256 for data at rest, TLS 1.2 or higher for data in transit. This includes database connections, API calls, file transfers, and backups. Cloud providers make this relatively easy — enable it and don't turn it off. But it's not just flipping a switch: you need to manage encryption keys properly and document your key rotation procedures.

Access controls with the minimum necessary standard. Every person and every system that accesses PHI must have the minimum level of access needed to do their job. Your customer support team doesn't need to see lab results. Your analytics pipeline doesn't need patient names. Implement role-based access control (RBAC) and enforce it at the application and database level. Audit who has access quarterly, and revoke access immediately when someone leaves the company.

Comprehensive audit logging. Every access to PHI must be logged: who accessed it, when, from where, and what they did with it. This isn't application logging — it's a tamper-proof audit trail that can withstand legal scrutiny. Logs must be retained for a minimum of 6 years. They must be stored separately from the data they're auditing, and they must be immutable. Cloud services like AWS CloudTrail and database-level audit logging help, but you still need application-level logging for PHI access through your API.

Automatic session termination. User sessions that access PHI must time out after a period of inactivity. The specific timeout depends on your risk assessment, but 15 minutes is a common standard for web applications. This prevents the scenario where a clinician walks away from their workstation and a passerby accesses patient records.

Data integrity controls. You need mechanisms to ensure that PHI hasn't been improperly altered or destroyed. This means checksums, version histories, and validation at the point of entry. If a patient's blood pressure reading gets corrupted in your database, you need to detect it and you need the original value.

What AI-Generated Healthtech Code Gets Wrong

If you've built your health app with AI coding tools, your compliance exposure is almost certainly larger than you realize. Here's what we find in every AI-generated healthtech codebase we audit.

No PHI isolation. AI tools store health data in the same database tables, the same API responses, and the same log files as everything else. A single SQL query returns patient names, email addresses, diagnoses, and billing information all in one result set. HIPAA requires that PHI be identifiable and isolable — you need to know exactly where it lives and control access to it independently from non-PHI data.

No audit trails. AI generates CRUD operations that create, read, update, and delete records with no record of who did what. When a penetration tester or auditor asks "show me every time a patient record was accessed in the last 90 days," your answer can't be "we don't track that." But that's exactly the answer most AI-generated codebases give.

Plain-text storage in unexpected places. The database might be encrypted, but AI-generated code often writes PHI to log files, error messages, caching layers, and temporary files in plain text. A stack trace that includes a patient's name and diagnosis in the error message is a HIPAA violation sitting in your log aggregator. AI tools don't think about data classification because they don't understand what PHI is.

No BAA awareness in service selection. AI happily integrates with any third-party service without considering whether that service has signed a BAA. Your AI-generated code sends patient data to an analytics service, a notification platform, and a search indexer — none of which have BAAs in place. Each one is an independent compliance violation.

The Compliance Timeline

HIPAA compliance isn't a weekend project, but it's not a year-long odyssey either. Here's a realistic timeline for an early-stage healthtech startup.

Weeks 1–2: Risk assessment and gap analysis ($5,000–$15,000 if hiring a consultant, or DIY with HHS templates). Inventory every system that touches PHI. Map data flows. Identify gaps between current state and HIPAA requirements. This produces your compliance roadmap. Every subsequent decision flows from this assessment.

Weeks 3–6: Technical remediation (your biggest engineering investment). Implement encryption, access controls, audit logging, session management, and PHI isolation. If you're refactoring an existing codebase, budget 4 to 8 weeks of focused engineering time. If you're building from scratch with HIPAA in mind, it adds roughly 30% to your development timeline.

Weeks 4–6 (parallel): Administrative controls. Write your security policies, incident response plan, workforce training program, and BAA inventory. Template libraries from companies like Aptible or Vanta can accelerate this, but you still need to customize them to your actual operations. Budget $5,000–$10,000 for compliance automation tooling.

Week 7–8: BAA inventory and vendor audit. Contact every vendor that touches PHI and obtain signed BAAs. Replace any vendor that won't sign one. This is often the step that forces hard decisions — that perfect analytics tool might not offer BAAs, and you'll need an alternative.

Ongoing: Annual risk assessments, workforce training, and continuous monitoring. HIPAA compliance isn't a one-time achievement. You need annual risk assessments, regular training for every employee who touches PHI, and continuous monitoring of your security controls. Budget $15,000–$30,000 per year for ongoing compliance operations at startup scale.

Total realistic first-year cost: $40,000–$100,000 including tooling, consulting, engineering time, and vendor costs. That's a significant investment, but it's a fraction of a single HIPAA violation penalty — and it's the cost of doing business in healthcare.

Architecture Decisions You Can't Defer

Some technical decisions are easy to change later. These aren't. Get them right before your first user enters PHI.

Isolate PHI at the data layer. Separate PHI into dedicated database tables, encrypted columns, or a dedicated data store. Don't mix it with analytics data, user preferences, or application state. When you need to delete a patient's data — and you will, because patients have that right — you need to know exactly where it all lives. This is also the foundation for access controls: you can't restrict access to PHI if it's sprinkled across every table in your database.

Choose your cloud region and provider carefully. PHI must stay within jurisdictions you've assessed and documented. If you're on AWS, pin your resources to specific regions and enable guardrails that prevent accidental deployment to non-approved regions. Your BAA with AWS only covers services used in compliance with their HIPAA guidance — not every AWS service is eligible. The same applies to GCP and Azure.

Build audit logging from day one. Retrofitting audit logging into an existing codebase is one of the most painful engineering tasks in compliance. Every API endpoint that reads or writes PHI needs logging. Every database query against PHI tables needs logging. Every admin action needs logging. If you build this into your CI/CD pipeline and API middleware from the start, it's nearly invisible. If you add it after 50 endpoints are already built, it's weeks of tedious, error-prone work.

Design for data portability. Patients have the right to receive their health data in a usable electronic format. Build export functionality early — it's a compliance requirement, and it's also a useful feature. SOC 2 and ISO 27001 both value data portability as well, so this investment pays dividends across multiple compliance frameworks. If you're planning for broader compliance, our SOC 2 guide for founders covers how these frameworks overlap.

Building health tech is genuinely hard — not because the product is complex, but because the stakes are real. The data your users trust you with is the most sensitive information in their lives. Getting compliance right isn't a bureaucratic exercise. It's the engineering equivalent of the Hippocratic oath: first, do no harm. If you're building in a regulated space and need help getting your architecture right, that's exactly what we cover in our guide to shipping in regulated industries.

Related glossary terms: HIPAA · SOC 2 · ISO 27001 · Penetration Testing · Authentication vs Authorization · Session Management · Incident Response · Monitoring & Observability