HIPAA for Non-Technical Founders: What You Can't Skip
A plain-English guide to HIPAA for startup founders without technical backgrounds. Learn what you can't skip and what can wait until after launch.
April 7, 2025 8 min read
You don't need to become a HIPAA expert to build a healthtech company. But you do need to understand enough to ask the right questions, evaluate vendors, and avoid the mistakes that sink startups.
Most HIPAA guides are written for compliance officers or engineers. This one is for founders who need to understand the landscape without drowning in regulatory detail. You'll learn what triggers HIPAA, what protected health information actually means, and which decisions require your attention versus which you can delegate.
The goal isn't comprehensive HIPAA training. It's giving you the mental model to make informed decisions and recognize when you need expert help.
When HIPAA Applies to Your Startup
HIPAA doesn't apply to all health-related products. It applies to specific types of organizations handling specific types of information.
HIPAA Applies When
You're a Covered Entity: Hospitals, clinics, insurance companies, and healthcare clearinghouses. If you're a startup, you're probably not a covered entity yourself.
You're a Business Associate: Companies that handle protected health information on behalf of covered entities. This is most healthtech startups. If you process, store, or transmit PHI for a hospital, clinic, or insurer, you're a business associate.
You Touch PHI: Protected Health Information triggers HIPAA. More on what counts as PHI below.
HIPAA Probably Doesn't Apply When
Consumer wellness apps without medical claims: A meditation app or fitness tracker that doesn't integrate with medical records typically doesn't trigger HIPAA.
General health content: Publishing health information or education doesn't require HIPAA compliance.
: If data cannot be linked back to individuals, HIPAA may not apply.
Stop planning and start building. We turn your idea into a production-ready product in 6-8 weeks.
Anonymous health data
The Gray Areas
Some products live in gray zones:
Consumer apps that integrate with EHRs: Once you pull data from Apple Health or medical records, PHI may be involved.
Mental health apps: Therapy notes are PHI. General mood tracking might not be.
Direct-to-consumer health testing: Varies based on what you're testing and how results are delivered.
When you're in a gray area, get legal advice. The cost of a healthcare attorney's opinion is trivial compared to the cost of getting HIPAA wrong.
What Actually Counts as PHI
Protected Health Information is individually identifiable health information. Both parts matter.
The "Health Information" Part
Health information includes:
Medical records and diagnoses
Treatment information
Prescription data
Lab results
Mental health records
Billing information for healthcare services
Health insurance information
Appointment and scheduling information
The "Individually Identifiable" Part
Health information becomes PHI when it can be linked to a specific person through any of 18 identifiers: Names, Geographic data smaller than a state, Dates (except year) related to an individual, Phone numbers, Email addresses, Social Security numbers, Medical record numbers, Health plan beneficiary numbers, Account numbers, Certificate/license numbers, Vehicle identifiers and serial numbers, Device identifiers and serial numbers, URLs, IP addresses, Biometric identifiers, Full face photographs, Any other unique identifying number or code.
If health information is combined with any of these identifiers, it's PHI. The combination is what triggers HIPAA.
Examples
PHI: "John Smith has diabetes"
Not PHI: "A 45-year-old male in California has diabetes" (could be many people)
Understanding PHI helps you make architecture decisions. Every piece of PHI your system handles adds compliance burden. Minimizing PHI scope reduces cost and risk.
The Business Associate Agreement
If your startup handles PHI on behalf of healthcare providers or insurers, you'll sign Business Associate Agreements (BAAs).
What a BAA Is
A BAA is a contract between your startup and the covered entity (hospital, clinic, insurer) that shares PHI with you. It establishes what PHI you'll receive and why, your obligations to protect that PHI, how you'll report breaches, and that you'll ensure your subcontractors also comply.
What a BAA Means for You
Signing a BAA means you're legally bound to HIPAA compliance, you need BAAs with your vendors too, you need documented policies and procedures, and you're liable for breaches.
Before You Sign a BAA
Don't sign a BAA until you actually have HIPAA-compliant infrastructure, you have documented security policies, you understand what PHI you'll handle and how, and your vendors who touch PHI have signed BAAs with you. Signing a BAA for a product that isn't compliant is signing up for liability you can't fulfill.
The Four Things You Must Understand
As a founder, you can delegate much of HIPAA implementation. But four areas require your understanding and decision-making:
1. Data Scope Decisions
What PHI will your product actually handle? This is a business decision, not a technical one. Questions to answer: What's the minimum PHI needed to deliver value? Can you validate your concept with less PHI initially? Where will PHI come from and go to? Who in your organization needs access to what PHI? More PHI means more compliance burden. The "minimum necessary" principle isn't just regulatory guidance. It's smart business strategy.
2. Vendor Selection
Every vendor that touches PHI needs a BAA. You can't delegate this decision entirely because BAA availability affects which vendors you can use, HIPAA-compliant vendors cost more, and vendor compliance becomes your problem. When your engineering team proposes a tool or service, your first question should be: "Will it touch PHI, and do they offer a BAA?"
3. Risk Tolerance
HIPAA requires a risk assessment. While experts conduct the assessment, you make the risk tolerance decisions: How much to invest in security beyond minimums? How quickly to remediate identified vulnerabilities? Whether to proceed with moderate risk or pause to reduce risk? These are founder decisions about resource allocation and risk appetite, not purely technical decisions.
4. Breach Response
If PHI is compromised, founders make the response decisions: How to communicate with affected individuals, whether to exceed minimum notification requirements, how to handle media and public relations, and whether to engage external crisis management. Having a breach response plan before you handle PHI means these decisions aren't made in crisis mode.
HIPAA Myths That Mislead Founders
Myth: Cloud Providers Handle HIPAA Compliance
Reality: Cloud providers can be HIPAA-compliant in their infrastructure. Your application on their infrastructure is your responsibility. AWS with a signed BAA gives you HIPAA-eligible infrastructure. It doesn't make your poorly-secured application compliant.
Myth: HIPAA Certification Exists
Reality: There's no official HIPAA certification. No government agency certifies products as "HIPAA certified." When vendors claim "HIPAA certified," they mean they've completed some assessment process, possibly self-assessed. What matters: SOC 2 Type II audits, third-party security assessments, and documented compliance programs.
Myth: Small Companies Get a Pass
Reality: HIPAA applies equally to a two-person startup and a large hospital system. Small companies might face less scrutiny, but they face the same liability.
Myth: HIPAA Compliance is One-Time
Reality: HIPAA requires ongoing compliance. Annual risk assessments, regular policy reviews, continuous security monitoring. Budget for compliance as an ongoing cost, not a one-time project.
Myth: Encryption Equals Compliance
Reality: Encryption is necessary but not sufficient. HIPAA requires access controls, audit logging, policies and procedures, training, risk assessment, and physical safeguards. Encryption is one piece of a comprehensive compliance program.
Questions to Ask Your Technical Team
As a non-technical founder, here are the questions that reveal whether your team is handling HIPAA correctly:
Architecture Questions: "Where is PHI stored, and is that storage encrypted at rest?" "Who can access PHI, and how is that access controlled?" "What gets logged when someone accesses PHI?" "How would we know if there was unauthorized access?"
Vendor Questions: "Which of our vendors will have access to PHI?" "Do all of those vendors have signed BAAs?" "What happens if a vendor has a breach?"
Process Questions: "How do we provision and de-provision access when someone joins or leaves?" "How do we handle a user's request to delete their data?" "What's our backup strategy, and are backups encrypted?"
Testing Questions: "When was our last penetration test?" "What did it find, and have we fixed everything?" "How do we ensure new code doesn't introduce security issues?"
If your team can't answer these questions clearly, you have a gap to address.
When to Get Expert Help
HIPAA expertise costs money. Here's when it's worth the investment:
Always Involve: Healthcare attorney for BAA review, regulatory questions, and compliance planning (budget $5,000-$15,000 for initial engagement). Security consultant for penetration testing before launch (budget $3,000-$10,000 depending on scope).
Often Worth It: HIPAA compliance consultant if your team lacks healthcare experience (budget $5,000-$15,000). Fractional compliance officer for ongoing compliance management (budget $1,000-$3,000/month).
The Bottom Line
HIPAA compliance isn't optional for healthtech. But it's also not mysterious. The core requirements are logical: Know what sensitive data you're handling, protect it with appropriate security, know who accesses it, and have a plan when things go wrong.
As a founder, you don't need to understand every technical detail. You need to understand enough to make informed decisions about data scope and risk, select vendors appropriately, ask the right questions of your team, and recognize when you need expert help.
Build compliance into your architecture from day one. The alternative—retrofitting compliance into a non-compliant product—is expensive, slow, and often requires rebuilding what you've already built.
Key Takeaways
HIPAA applies to your startup if you handle PHI on behalf of healthcare providers or insurers. Understanding the basics helps you make informed decisions even as a non-technical founder.
PHI = Health Information + Individual Identifiers. Both elements together trigger HIPAA protection requirements.
BAAs are binding contracts. Don't sign one until you can actually comply with its terms.
Cloud providers aren't responsible for your application security. Their BAA covers their infrastructure, not your code.
Compliance is ongoing. Budget for annual assessments, continuous monitoring, and policy maintenance.
Get legal advice early. A few thousand dollars for an attorney's opinion prevents much larger problems later.
The founders who succeed in healthtech understand these fundamentals. They build compliant products from day one, not because regulators require it, but because it's the foundation for a sustainable healthcare business.
At NextBuild, we help non-technical healthtech founders build HIPAA-compliant products without becoming compliance experts themselves. If you're building in healthcare and want a partner who understands both the technology and the regulations, let's talk about your project.
Learn how to create a basic version of your product for your new business.
