HIPAA Compliance for Software Companies: What Triggers It and What It Actually Requires

Q: "Does my software company need to be HIPAA compliant"

"Your software company needs HIPAA compliance if you handle Protected Health Information (PHI) on behalf of a covered entity — a healthcare provider, health insurer, or healthcare clearinghouse. The trigger is specific: PHI is health information linked to an identifiable individual. A fitness app that tracks heart rate isn't handling PHI. A scheduling tool that stores patient names and appointment types for a medical practice is. If HIPAA applies, you'll need to sign a Business Associate Agreement (BAA) with each healthcare customer, implement specific technical safeguards (encryption, access controls, audit logging), conduct an annual risk assessment, and have a breach notification process. Budget $50K-$100K for initial compliance and $30K-$50K annually to maintain it."

Does my software company need to be HIPAA compliant

Quick answer

Your software company needs HIPAA compliance if you handle Protected Health Information (PHI) on behalf of a covered entity — a healthcare provider, health insurer, or healthcare clearinghouse. The trigger is specific: PHI is health information linked to an identifiable individual. A fitness app that tracks heart rate isn't handling PHI. A scheduling tool that stores patient names and appointment types for a medical practice is. If HIPAA applies, you'll need to sign a Business Associate Agreement (BAA) with each healthcare customer, implement specific technical safeguards (encryption, access controls, audit logging), conduct an annual risk assessment, and have a breach notification process. Budget $50K-$100K for initial compliance and $30K-$50K annually to maintain it.

Dealing with this at your company? 15 minutes usually clarifies next steps. Book a free call →

Three different SaaS founders have told me they need HIPAA compliance in the last year. Only one of them actually did. The first built a wellness app that tracked exercise habits — no PHI, no HIPAA. The second built a project management tool used by a hospital’s IT department — no PHI in the tool, no HIPAA. The third built a patient communication platform that stored patient names, phone numbers, and appointment details for dental practices. That’s PHI. That’s HIPAA.

The confusion is understandable. “Health data” and “Protected Health Information” sound like the same thing. They’re not.

The HIPAA Trigger

HIPAA applies when two conditions are met simultaneously:

Condition 1: You handle Protected Health Information (PHI). PHI is individually identifiable health information — data that links a specific person to their health condition, treatment, or payment for healthcare. Patient name + diagnosis is PHI. Patient name + appointment time at a medical practice is PHI. Anonymous aggregate health statistics are not PHI. A heart rate reading with no attached identity is not PHI.

Condition 2: You’re a Business Associate of a Covered Entity. Covered entities are healthcare providers, health insurers, and healthcare clearinghouses. A Business Associate is any company that handles PHI on behalf of a covered entity. If a hospital uses your software and patient data flows through it, you’re a Business Associate.

Both conditions must be true. Handling health-related data that isn’t PHI doesn’t trigger HIPAA. And handling PHI for a company that isn’t a covered entity (a corporate wellness program, for example) may not trigger HIPAA either — though it might trigger other privacy obligations.

What HIPAA Actually Requires

If HIPAA applies, here’s what you need:

Business Associate Agreement (BAA). Before any healthcare customer shares PHI with you, you’ll sign a BAA — a legal contract that obligates you to protect PHI according to HIPAA standards. This isn’t optional. No BAA, no PHI. Every vendor in your supply chain that touches PHI also needs a BAA with you. Your cloud provider, your database host, your monitoring service — if PHI passes through it, you need a BAA with that vendor. AWS, Google Cloud, and Azure all offer BAAs. Many SaaS tools (Datadog, PagerDuty, Slack) do not, which means PHI cannot flow through those systems.

Technical safeguards. Encryption of PHI at rest and in transit (AES-256 and TLS 1.2+ are the standard). Access controls that enforce minimum necessary access — users see only the PHI they need for their role. Unique user identification (no shared accounts). Automatic session timeouts. Audit logging of all PHI access — who accessed what, when, and why.

Administrative safeguards. A designated privacy officer and security officer (can be the same person at a small company). Written policies and procedures covering PHI handling, access management, incident response, and employee training. Annual security risk assessment. Workforce training on HIPAA requirements (at hire and annually).

Physical safeguards. For a software company, this mostly means securing the physical environments where PHI is accessed — laptops with full-disk encryption, screen lock policies, and controls on removable media. If you’re cloud-hosted, your cloud provider handles data center physical security under their BAA.

Breach notification. If PHI is compromised, you must notify the affected covered entity within 60 days. The covered entity then notifies affected individuals and, if the breach affects more than 500 people, the Department of Health and Human Services and local media. The notification requirements are strict and the penalties for delayed notification are significant.

The Engineering Checklist

For engineering teams implementing HIPAA controls:

Data isolation. PHI should live in clearly identified, separately controlled data stores. Don’t mix PHI with general application data in the same database tables if you can avoid it. This simplifies access controls, auditing, and breach scope assessment.

Audit logging. Every read and write of PHI must be logged with the user’s identity, timestamp, and what was accessed. These logs must be tamper-evident and retained for six years (HIPAA’s record retention requirement). This is the single most underestimated engineering requirement.

Access controls. Role-based access with minimum necessary standard. A billing administrator doesn’t need to see clinical notes. A scheduling coordinator doesn’t need to see payment history. Design your permission model around PHI access specifically, not just general application roles.

Encryption. AES-256 at rest, TLS 1.2+ in transit. Field-level encryption for particularly sensitive PHI (SSNs, diagnosis codes) so that database access alone doesn’t expose the data. Key management through your cloud provider’s KMS or a dedicated service — never application-managed keys stored in code.

Backup and disposal. PHI in backups is still PHI. Your backup encryption, access controls, and retention policies must match your production controls. When PHI is no longer needed, it must be securely disposed of — not just deleted, but rendered unrecoverable.

The Cost Reality

Initial HIPAA compliance for a software company with 10-30 employees:

Risk assessment and gap analysis: $10K-$20K. Policy development and documentation: $10K-$20K (often done with a consultant). Technical control implementation: $15K-$40K in engineering time. Compliance management platform: $10K-$25K/year. Annual risk assessment and audit: $10K-$20K.

Total first year: $50K-$100K. Annual maintenance: $30K-$50K.

Contrast this with HIPAA violation penalties: $100 to $50,000 per violation (per record), with annual maximums of $1.5 million per violation category. A breach affecting 10,000 patients at the minimum penalty is $1 million. The compliance investment is insurance.

Working through this yourself?

I help scaling companies navigate exactly this kind of decision.

If you're between $2M–$50M, have real technical decisions to make, and don't have a CTO in the room — a 15-minute call usually clarifies whether there's a fit. No pitch, no deck.

Book a free 15-min call Christopher Grant · Fractional CTO · LinkedIn

← All Articles