You just got a serious conversation going with a hospital system, a large health plan, or a digital health platform that has enterprise customers of their own. The call went well. The product demo landed. And then someone on their security team sent over a vendor questionnaire with 80 questions about your data handling practices, your encryption standards, and whether you have documentation of your most recent security assessment.
For a lot of HealthTech founders, this is the moment HIPAA compliance stops being an abstract future consideration and becomes a very immediate business problem.
The good news is that getting genuinely HIPAA compliant as a startup is achievable. The bad news is that a lot of early-stage HealthTech companies think they are further along than they are, because they have been treating HIPAA as a policy exercise rather than a security program.
Here is what you actually need in place.
First: Understand Whether HIPAA Applies to You
This sounds obvious, but a surprising number of HealthTech founders get this wrong in both directions. Some assume they are subject to HIPAA when they are not. Others are clearly subject to HIPAA and have not fully internalized what that means.
HIPAA applies to two categories of organizations: Covered Entities and Business Associates. Covered Entities are healthcare providers, health plans, and healthcare clearinghouses. Most HealthTech startups are not Covered Entities. They are Business Associates.
You are a Business Associate if you create, receive, maintain, or transmit Protected Health Information (PHI) on behalf of a Covered Entity. If your platform stores patient data for a hospital, processes clinical records for a health system, or integrates with an EHR to pull patient information into your product, you are a Business Associate and HIPAA applies to you.
PHI is broader than most founders expect. It includes names, dates, geographic identifiers, phone numbers, and any other information that could be used to identify a patient when combined with health data. The threshold is low. If there is any ambiguity, assume PHI is involved and work from there.
The Business Associate Agreement Is Not a Compliance Program
The first thing most HealthTech startups do when they realize HIPAA applies to them is draft a Business Associate Agreement, or BAA. A BAA is a contract between you and the Covered Entity you are working with that defines how PHI will be used and protected. It is required by law before any PHI changes hands.
Getting a BAA signed is necessary. It is not sufficient.
A BAA says you agree to protect PHI according to HIPAA requirements. It does not actually protect the PHI. That is your job, and it requires a functioning security program, not just a contract.
You also need BAAs in place with your own vendors who touch PHI. Your cloud hosting provider, your database service, your logging infrastructure, anyone in your supply chain that has access to patient data needs to have a BAA signed with you. Most major cloud providers offer HIPAA-eligible service configurations, but you have to opt into them and configure your environments accordingly. Signing up for AWS does not automatically make your AWS environment HIPAA compliant.
The Three Rules You Need to Build Around
HIPAA’s requirements are organized into three rules that apply to Business Associates: the Security Rule, the Privacy Rule, and the Breach Notification Rule.
The Security Rule is the most operationally intensive for HealthTech startups. It requires you to implement administrative, physical, and technical safeguards to protect electronic PHI. In practice, this means access controls, encryption at rest and in transit, audit logging, workforce training, risk assessments, and a formal incident response process. These are not paperwork exercises. Auditors and enterprise security teams will ask to see evidence that these controls are actually operating.
The Privacy Rule governs how PHI can be used and disclosed. For most SaaS Business Associates, the key obligations are limiting PHI use to what is permitted under your BAA, giving Covered Entities mechanisms to honor patient rights requests, and ensuring your team only accesses PHI to the extent necessary for their role.
The Breach Notification Rule requires you to notify affected individuals, the Department of Health and Human Services, and in some cases the media if a breach involving unsecured PHI occurs. Notification timelines are strict. Covered Entities must notify affected individuals within 60 days of discovering a breach. Your BAA will define your obligations to notify the Covered Entity quickly so they can meet their own deadlines.
What Enterprise Customers Will Actually Ask You
When a serious enterprise healthcare customer evaluates your product, their security team is going to look beyond your signed BAA. Here is what tends to come up in vendor security reviews.
They will want to see your most recent risk assessment. HIPAA requires you to conduct a thorough assessment of potential risks to the confidentiality, integrity, and availability of your ePHI. This is not a one-time exercise. It should be reviewed and updated regularly, and especially after significant changes to your environment.
They will ask about your penetration testing. Under the 2025 HIPAA Security Rule updates, annual penetration testing by qualified professionals is now a mandatory requirement for covered entities and business associates, not just a best practice. Enterprise security teams have been asking for pentest reports for years. Now it is also a regulatory obligation. Your test scope needs to reflect your actual production environment, including any APIs, web applications, and cloud infrastructure where PHI is processed or stored.
They will want to see evidence of access reviews. Who has access to PHI in your system, and how do you review and clean that up regularly? Automated offboarding tied to your identity provider is expected. Manual processes that take days to revoke access after an employee leaves are a red flag.
They will ask about your incident response process. Not whether you have a policy, but whether your team has actually tested it. A tabletop exercise that walks through a simulated PHI breach scenario, with documented outcomes and lessons learned, goes a long way in demonstrating that your program is real.
They may also ask about SOC 2. HIPAA and SOC 2 are separate frameworks, but they have meaningful overlap. Many HealthTech companies pursue SOC 2 Type II alongside HIPAA compliance because enterprise healthcare customers find the combination reassuring, and because a significant portion of the controls overlap. If you are going to invest in HIPAA compliance, it is worth thinking about whether SOC 2 makes sense to pursue at the same time.
The Compliance Program vs. The Compliance Checkbox
The most common mistake HealthTech startups make with HIPAA is treating it as a documentation exercise. They generate policies, sign BAAs, and call it done. Then an enterprise security questionnaire arrives, or worse, a real incident occurs, and the gap between what they said they were doing and what they were actually doing becomes visible in the worst possible way.
A real HIPAA compliance program means your policies reflect how your engineering team actually works. It means your access controls are reviewed on a schedule, not just when someone thinks to do it. It means your risk assessment identifies the specific threats to your specific environment, not generic language copied from a template. It means your team has been trained on what PHI is, why it matters, and what to do when something goes wrong.
Building that program takes expert guidance, especially at the early stage when you do not have an internal security team and your engineers are focused on shipping product. The controls are not complicated, but knowing which ones matter most for your specific situation, how to document them in a way that will hold up in an audit, and how to prioritize a remediation plan when you have limited bandwidth requires experience.
Getting Compliant Before the Deal Is on the Line
The right time to build your HIPAA compliance program is before a major healthcare enterprise customer asks about it, not after. Companies that scramble to get compliant when a deal is at stake almost always shortchange the process, produce documentation that does not hold up, and create more risk for themselves than if they had just done it properly the first time.
The investment is also smaller than most founders expect. With the right guidance, a HealthTech startup can get genuinely HIPAA compliant in a matter of weeks, not months, and walk into enterprise security reviews with confidence.
At Packet33, we work with SaaS and HealthTech startups to build compliance programs that actually hold up, combining audit readiness advisory, compliance-as-a-service, and penetration testing that is scoped and timed to support your compliance evidence package. We are built for lean teams that need expert coverage without the overhead of a large consulting firm.
