HIPAA compliance is simpler than you think — if you know what actually applies.

HIPAA does not apply to every company that touches healthcare data. It applies to two categories of organizations: covered entities and business associates. Understanding which category you fall into, or whether you fall into either, determines the scope of everything that follows.

Covered entities are health plans, healthcare clearinghouses, and healthcare providers who transmit health information electronically. If you are a hospital, insurance company, or pharmacy, you are a covered entity.

Business associates are organizations that perform services for covered entities and handle protected health information (PHI) in the process. This is where most technology companies land. If a hospital uses your SaaS platform to manage patient records, you are a business associate. If an insurance company uses your analytics tool and sends you claims data, you are a business associate.

The critical question is whether you actually receive, store, transmit, or process PHI. If your product connects to a healthcare system but never touches the actual patient data, HIPAA may not apply to you directly. Some companies build integrations that pass data through without storing it, and the compliance obligations differ significantly based on that architecture.

HIPAA has two major rules that people often conflate, and understanding the difference saves significant time and effort when scoping your compliance program.

The Privacy Rule governs the use and disclosure of PHI in any form, including paper records and verbal communications. It defines patient rights such as the right to access their records, the right to request corrections, and the right to know who their information has been shared with. The Privacy Rule primarily applies to covered entities. Business associates must comply with the Privacy Rule only to the extent that they use or disclose PHI, and they must follow the terms of their BAA.

The Security Rule focuses specifically on electronic PHI (ePHI) and requires the administrative, physical, and technical safeguards described above. For technology companies, the Security Rule is where most of your compliance work lives. It is concrete, measurable, and maps directly to the security controls you are probably already building.

There is also the Breach Notification Rule, which requires you to notify affected individuals, HHS, and sometimes the media if a breach of unsecured PHI occurs. The timelines are strict: individual notifications within 60 days of discovery, HHS notification annually for breaches affecting fewer than 500 people, and within 60 days for larger breaches. Having a tested incident response plan that accounts for these notification requirements is not optional.

For most SaaS companies operating as business associates, the priority order is: Security Rule first, Breach Notification Rule second, Privacy Rule third. Build your technical and administrative controls, prepare your incident response plan, and align your data handling practices with the terms of your BAAs.

After working with dozens of technology companies on their HIPAA programs, certain patterns emerge repeatedly. Avoiding these mistakes can save months of wasted effort and reduce your actual risk exposure.

• Over-scoping the program. Companies often try to make their entire infrastructure HIPAA-compliant when only a specific product or service handles PHI. Scope your HIPAA program tightly around the systems and data flows that actually involve ePHI. You can always expand scope later, but a narrow, well-controlled environment is easier to secure and audit than your entire company.
• Ignoring the breach notification timeline. Many tech companies have incident response plans but forget to integrate HIPAA's specific notification requirements. When you discover a breach involving PHI, the 60-day clock starts ticking. Your incident response plan needs explicit steps for determining whether PHI was involved, assessing the scope, and executing the notification process. Test this process before you need it.
• Treating compliance as a checkbox. HIPAA is not a point-in-time certification. There is no HIPAA certificate to hang on your wall. Compliance is an ongoing state that you maintain through regular risk assessments, policy reviews, workforce training, and evidence collection. Companies that treat it as a one-time project inevitably discover gaps when a covered entity audits them or when a breach occurs.
• Forgetting about subcontractors. If you use third-party services that may access ePHI, you need BAAs with them too. This includes cloud hosting providers, logging services, customer support platforms, and anyone else in the data flow. Your vendor risk management process should specifically address HIPAA requirements for subcontractors.
• Confusing HIPAA with HITRUST. HITRUST is a certifiable framework that incorporates HIPAA requirements along with many other standards. Achieving HITRUST certification is one way to demonstrate HIPAA compliance, but it is not the only way and it is significantly more expensive and time-consuming. Many business associates successfully demonstrate compliance through a well-documented HIPAA program, a completed risk assessment, and a set of policies and controls mapped to the Security Rule requirements.

The organizations that handle HIPAA well approach it the same way they approach any security program: start with understanding your risks, implement controls proportional to those risks, document everything, and maintain it as an ongoing practice rather than a project with an end date.