HIPAA Compliance for Startups: A Practical Guide
A practical guide to HIPAA compliance for startups building in healthcare, covering the Privacy Rule, Security Rule, Breach Notification, BAAs, technical safeguards, and the common mistakes we see early-stage companies make.
One of the most common conversations we have at Agency starts something like this: "We're building a health tech product and we know HIPAA applies to us, but we don't know where to start, and we can't afford to spend six months on compliance before we launch." The good news is that HIPAA compliance for startups does not require an enterprise-grade program from day one. What it requires is understanding which rules apply to you, implementing the right safeguards, and building a foundation that scales as you grow. This guide is the starting point we give to every health tech founder we work with.
HIPAA — the Health Insurance Portability and Accountability Act — is the federal law that governs how protected health information (PHI) is handled in the United States. For startups building products that touch patient data, clinical information, or health records, HIPAA compliance is not optional. The penalties for non-compliance are severe, and more importantly, your customers — healthcare providers, payers, and other covered entities — will require HIPAA compliance as a non-negotiable condition of doing business.
HIPAA Basics: The Three Rules
HIPAA compliance is built on three core rules. Understanding each one is essential before you start implementing anything.
The Privacy Rule
The Privacy Rule establishes national standards for the protection of individually identifiable health information. It governs how PHI can be used and disclosed, gives patients rights over their health information, and requires organizations to implement administrative safeguards to protect PHI privacy.
What we tell clients is that the Privacy Rule is primarily about permissible use. It answers the question: under what circumstances are we allowed to access, use, or share this patient's information? The rule defines specific permitted uses (treatment, payment, healthcare operations) and requires patient authorization for most other disclosures.
For startups, the Privacy Rule's practical impact depends on your role. If you are a business associate — meaning you handle PHI on behalf of a covered entity — the Privacy Rule applies to you through your Business Associate Agreement (BAA). You must use and disclose PHI only as permitted by the BAA and the Privacy Rule.
The Security Rule
The Security Rule is where most of the technical work lives. It requires covered entities and business associates to implement safeguards to ensure the confidentiality, integrity, and availability of electronic protected health information (ePHI). The rule organizes these safeguards into three categories: administrative, physical, and technical.
In our experience, the Security Rule is where startups spend the majority of their HIPAA compliance effort. It defines specific implementation standards — some required, some addressable — across 18 safeguard categories. What we recommend is focusing on the required standards first, then working through the addressable standards with documented rationale for your implementation decisions.
The Breach Notification Rule
The Breach Notification Rule requires covered entities and business associates to notify affected individuals, the Department of Health and Human Services (HHS), and in some cases the media, following a breach of unsecured PHI.
What we tell clients is that the Breach Notification Rule creates a powerful incentive to get security right the first time. The notification requirements include specific timelines — individual notification must occur within 60 days of discovery — and the reputational damage from a breach notification often exceeds the regulatory penalties.
What Is PHI and When Does HIPAA Apply to You
Protected Health Information (PHI) is individually identifiable health information that is created, received, maintained, or transmitted by a covered entity or business associate. PHI includes any information that relates to an individual's past, present, or future physical or mental health condition, the provision of healthcare to an individual, or past, present, or future payment for healthcare, and that identifies the individual or could reasonably be used to identify them.
The 18 HIPAA identifiers include names, dates (birth, admission, discharge, death), phone numbers, email addresses, Social Security numbers, medical record numbers, health plan beneficiary numbers, account numbers, device identifiers, IP addresses, biometric identifiers, full-face photographs, and any other unique identifying number or code.
Covered Entities vs Business Associates
HIPAA applies directly to covered entities: health plans, healthcare clearinghouses, and healthcare providers who transmit health information electronically. Most startups are not covered entities themselves — they are business associates.
A business associate is any person or organization that performs functions or activities on behalf of a covered entity that involve the use or disclosure of PHI. In our experience, the most common business associate scenarios for startups include providing software that stores or processes patient data, offering analytics services that use health information, providing cloud hosting for healthcare applications, and building EHR integrations or patient-facing applications.
What we tell clients is that if your product touches PHI in any way — even if you just transmit it and do not store it — you are almost certainly a business associate, and HIPAA applies to you.
Business Associate Agreements
A Business Associate Agreement (BAA) is a legally required contract between a covered entity and a business associate that establishes the permitted uses and disclosures of PHI. You cannot legally receive PHI without a BAA in place.
What we recommend is developing a standard BAA template that you can provide to customers. Key provisions that every BAA must include are permitted uses and disclosures of PHI, an obligation to implement appropriate safeguards, reporting requirements for security incidents and breaches, requirements for subcontractor compliance, obligations to return or destroy PHI at contract termination, and provisions allowing the covered entity to terminate the agreement for material breach.
In our experience, two common startup mistakes with BAAs are signing customer-provided BAAs without legal review (some contain onerous provisions that exceed HIPAA requirements) and failing to execute BAAs with your own subcontractors who handle PHI on your behalf (your cloud provider, your database hosting provider, your email service if it transmits PHI).
Critical point: Your infrastructure providers need BAAs too. AWS, Google Cloud, and Azure all offer BAAs, but you must explicitly execute them. In our experience, failing to have BAAs with infrastructure providers is the single most common HIPAA gap we find during startup assessments.
Technical Safeguards
The Security Rule's technical safeguards are the controls that most directly affect your engineering team. Here is what the rule requires and what we recommend for startups:
Access Control (Required)
You must implement technical policies and procedures for electronic information systems that maintain ePHI to allow access only to authorized persons or software programs. Required implementation specifications include unique user identification (every user gets their own credentials — no shared accounts), emergency access procedure (a documented process for accessing ePHI during emergencies), automatic logoff (sessions terminate after a defined period of inactivity), and encryption and decryption of ePHI.
What we recommend for startups is implementing role-based access control (RBAC) with least-privilege principles from day one. Use your identity provider to enforce MFA for all access to systems that handle ePHI. In our experience, the access control implementation that satisfies both HIPAA and SOC 2 simultaneously is RBAC with MFA, centralized identity management, and quarterly access reviews.
Audit Controls (Required)
You must implement hardware, software, and procedural mechanisms to record and examine activity in systems that contain or use ePHI. In practice, this means comprehensive audit logging for all systems that process ePHI, centralized log management with tamper-evident storage, a minimum retention period (what we recommend is at least one year, with six years being the HIPAA-aligned best practice for documentation), and regular log review processes.
Integrity Controls (Addressable)
You must implement policies and procedures to protect ePHI from improper alteration or destruction. What we recommend is implementing integrity verification through checksums or hashing for stored ePHI, database audit trails that track all modifications to health records, and version control for configuration changes to systems that handle ePHI.
Transmission Security (Required)
You must implement technical security measures to guard against unauthorized access to ePHI being transmitted over an electronic network. In practice, this means TLS 1.2 or higher for all data in transit, encrypted VPN connections for any remote access to ePHI systems, and encrypted email or secure messaging for any PHI transmitted via electronic communication.
Administrative Safeguards
Administrative safeguards are the policies, procedures, and organizational measures that govern how your team handles ePHI. In our experience, these safeguards take more time to implement than technical controls because they require organizational process changes.
Security Officer Designation (Required)
You must designate a security officer responsible for the development and implementation of your HIPAA security policies. For startups, what we recommend is assigning this role to someone in a technical leadership position — typically the CTO, VP of Engineering, or Head of Security. The security officer does not need to be a full-time compliance role at the startup stage, but they must have documented authority and accountability.
Workforce Training (Required)
All workforce members must receive security awareness training on HIPAA requirements. What we recommend for startups is conducting initial training during onboarding (covering HIPAA basics, PHI handling procedures, and incident reporting), annual refresher training for all employees, and role-specific training for engineering and support teams who directly handle ePHI.
In our experience, documenting your training program — including attendance records and training content — is critical because auditors and customers specifically request this evidence.
Risk Assessment (Required)
HIPAA requires an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI. What we tell clients is that the HIPAA risk assessment is not a one-time exercise — HHS expects ongoing risk management, and your risk assessment should be updated at least annually and whenever significant changes occur.
Your HIPAA risk assessment should identify all systems that create, receive, maintain, or transmit ePHI, identify and document potential threats and vulnerabilities, assess the likelihood and impact of each threat, determine the current level of risk, and document risk treatment decisions.
Incident Response (Required)
You must implement policies and procedures to address security incidents. What we recommend for startups is a documented incident response plan that covers identification and reporting procedures, containment and eradication steps, breach determination analysis (the four-factor test under the Breach Notification Rule), notification procedures and timelines, and post-incident review and corrective action.
Physical Safeguards
Physical safeguards protect the physical systems and facilities that house ePHI. For cloud-native startups, many physical safeguard obligations are inherited from your infrastructure provider — but you still have responsibilities.
What we tell clients is that physical safeguards for a cloud-native startup typically focus on endpoint security (full-disk encryption on all devices, remote wipe capability, screen lock enforcement), office security if you have physical office space (access controls, visitor management, clean desk policy), and media disposal procedures for any physical media that contained ePHI.
In our experience, the physical safeguard that startups most commonly miss is documented media disposal. Even if you are entirely cloud-based, employee laptops that accessed ePHI must be properly wiped before disposal or reassignment.
The Intersection of HIPAA and SOC 2
Many healthtech startups need both HIPAA compliance and a SOC 2 report. What we tell clients is that these two programs complement each other significantly, and running them together is far more efficient than running them separately.
SOC 2 with the Security and Availability criteria overlaps with approximately 60 to 70 percent of HIPAA Security Rule requirements. The shared controls include access management, logging and monitoring, incident response, change management, risk assessment, vendor management, and encryption.
What we recommend for healthtech startups is building a single compliance program that satisfies both frameworks simultaneously. Start with SOC 2 Security and Availability, map HIPAA-specific requirements that go beyond SOC 2 (Privacy Rule obligations, BAA management, PHI-specific handling procedures), and implement the delta controls in one integrated remediation effort.
In our experience, companies that pursue both SOC 2 and HIPAA through a unified program spend 30 to 40 percent less time and budget than companies that run separate compliance tracks.
Common Startup Mistakes
After working with dozens of healthtech startups, these are the HIPAA mistakes we see most frequently:
Assuming HIPAA does not apply yet. Startups sometimes believe HIPAA kicks in at a certain revenue threshold or user count. It does not. If you handle PHI, HIPAA applies regardless of company size. What we tell clients is that early compliance is significantly cheaper than retroactive compliance after a breach or enforcement action.
Missing BAAs with infrastructure providers. Your cloud provider handles ePHI on your behalf. Without an executed BAA, you are in violation of HIPAA regardless of how strong your technical controls are.
Treating HIPAA as purely technical. The Security Rule has technical requirements, but administrative and physical safeguards are equally important. In our experience, startups that focus exclusively on encryption and access controls while neglecting training, risk assessment, and incident response are building an incomplete program.
No documented risk assessment. HHS has consistently identified the absence of a risk assessment as the most common HIPAA violation in enforcement actions. This is not optional — it is the foundation of your entire compliance program.
Confusing "addressable" with "optional." In the HIPAA Security Rule, "addressable" does not mean optional. It means you must implement the specification or document why an equivalent alternative measure is reasonable and appropriate in your environment. In our experience, auditors and regulators expect you to implement most addressable specifications unless you have a well-documented reason not to.
Forgetting about de-identified data. Some startups assume that removing names from health data makes it non-PHI. HIPAA has a specific standard for de-identification that requires removal of all 18 identifiers. Partially de-identified data is still PHI.
Key Takeaways
- HIPAA applies to your startup if you handle protected health information in any capacity — there is no size threshold, revenue minimum, or grace period.
- What we recommend is starting with three priorities: execute BAAs with all parties (including infrastructure providers), conduct a documented risk assessment, and implement the Security Rule's required technical safeguards.
- In our experience, the most efficient path for healthtech startups is building a unified compliance program that addresses both HIPAA and SOC 2 simultaneously, leveraging the 60 to 70 percent control overlap.
- Designate a security officer, implement workforce training, and document everything — administrative safeguards are where HHS enforcement actions most commonly find violations.
- What we tell clients is that early HIPAA compliance costs a fraction of what retroactive compliance costs after a breach, an enforcement inquiry, or a lost customer contract.
- The Breach Notification Rule creates a 60-day clock from breach discovery to individual notification — have your incident response plan ready before you need it.
Agency Team
Agency Insights
Expert guidance on cybersecurity compliance from Agency's advisory team.
LinkedIn