Introduction
You’re in the final stages of closing a deal with a major health system. The requirements look straightforward until the customer’s procurement team asks a simple question: “Is your platform HIPAA compliant?”
If your company handles healthcare data and you can’t confidently answer that question, you’re not alone. Many SaaS and health tech companies operate in a gray zone, unsure whether HIPAA’s regulations actually apply to them. The cost of getting this wrong is steep. A single HIPAA breach notification can kill your reputation, trigger a government investigation, and expose you to penalties that can exceed $1.5 million per violation.
This guide cuts through the confusion. We’ll explain what HIPAA actually is, who it applies to, what compliance really requires, and how to build a sustainable compliance program. Whether you’re a digital health startup handling patient data or a SaaS company pivoting into healthcare, this is everything you need to know.
What Is HIPAA and Why Does It Matter?
HIPAA stands for the Health Insurance Portability and Accountability Act. Passed by Congress in 1996, it’s the federal law that governs how healthcare data is protected in the United States. Despite its age, HIPAA remains the gold standard for healthcare privacy and security compliance.
Here’s what you need to understand: HIPAA isn’t just one regulation. It’s an umbrella law that contains multiple rules, each addressing different aspects of healthcare data protection. Think of it as a framework that says, “If you handle healthcare data, here’s the baseline level of protection patients expect and the law requires.”
The reason HIPAA matters is straightforward. Patient health information is extraordinarily sensitive. It reveals not just medical conditions but often financial status, mental health history, substance use, and other deeply personal details. A breach doesn’t just embarrass a patient—it can destroy their creditworthiness, trigger discrimination by employers or insurers, and create long-term harm. HIPAA exists to prevent that.
For businesses, HIPAA compliance is also a competitive advantage and a market requirement. Healthcare organizations won’t contract with vendors they don’t trust. Investors scrutinize compliance before funding health tech companies. Insurance companies factor it into their risk assessments. In short, you can’t play in healthcare without it.
Who Does HIPAA Apply To? (Covered Entities, Business Associates, and the Subcontractor Chain)
This is where many companies go wrong. They think HIPAA only applies to hospitals and insurance companies. It doesn’t.
HIPAA applies to two primary groups: covered entities and business associates. Understanding which bucket you fall into is critical.
A covered entity is any organization that directly provides healthcare services or pays for them. This includes hospitals, physician practices, urgent care clinics, dentist offices, nursing homes, health insurance companies, health plans, and healthcare clearinghouses. If you’re running a healthcare provider practice or an insurance company, you’re definitely a covered entity.
A business associate is any vendor or contractor that handles protected health information on behalf of a covered entity. This is where the scope expands dramatically. If you provide a patient management software platform used by a clinic, you’re a business associate. If you run a cloud storage service that a health plan uses to store member data, you’re a business associate. If you provide billing services, transcription services, appointment scheduling software, or telehealth infrastructure, you’re likely a business associate.
The key distinction is simple: if you access, use, or have the ability to access healthcare data belonging to someone else’s patient population, HIPAA applies to you. Many SaaS founders are surprised to learn this. They think of themselves as technology companies, not healthcare companies. But in HIPAA’s framework, if you touch healthcare data, you’re in the healthcare data ecosystem, and the law applies.
There’s a third layer that often confuses people: subcontractors. These are vendors who work on behalf of your business associate. If you’re a business associate and you contract with a cloud provider, that cloud provider becomes a subcontractor in the HIPAA chain. That cloud provider must also be HIPAA compliant. This creates a cascading compliance obligation. You’re responsible not just for your own security, but for ensuring everyone in your data supply chain is secure too.
What Is PHI? (Protected Health Information Explained Clearly, With Examples)
Protected Health Information, or PHI, is the term HIPAA uses for any information in a medical record or health plan that can identify an individual.
This sounds simple but it’s broader than most people think. PHI isn’t just a diagnosis. It includes names, addresses, phone numbers, email addresses, dates of birth, social security numbers, medical record numbers, insurance policy numbers, and license plate numbers associated with healthcare records. Essentially, if it’s in a healthcare context and can identify someone, it’s potentially PHI.
Let’s walk through some practical examples. A patient’s name combined with their diagnosis is PHI. A phone number associated with a patient’s appointment is PHI. An email address used to receive a prescription refill notification is PHI. Even a zip code combined with a date of birth and gender might be PHI because that combination can often identify a specific person.
There’s one important exception: de-identified data. If you remove all of the identifying information and apply strict de-identification rules, the resulting data is no longer PHI. This means you can use truly de-identified datasets for analytics, machine learning training, and research without HIPAA restrictions. But the de-identification process is rigorous. You can’t just remove names and call it de-identified. You must follow specific technical and statistical standards.
The scope of PHI matters because it determines what data you need to protect under HIPAA. Any system that touches PHI must have security controls. Any team member who accesses PHI must be trained. Any vendor with access to PHI must be a business associate. If you’re building a health tech product, the first question is always: does our platform touch PHI? If the answer is yes, HIPAA applies, and you need to treat PHI protection as a core architectural requirement, not an afterthought.
The Three HIPAA Rules Explained
HIPAA’s core regulatory framework consists of three main rules: the Privacy Rule, the Security Rule, and the Breach Notification Rule. Each addresses a different dimension of healthcare data protection.
The Privacy Rule
The Privacy Rule, issued in 2000, established the first national standards for protecting health information. At its core, it grants patients rights over their health data and places obligations on organizations that handle it.
The Privacy Rule says that covered entities and business associates must limit the use and disclosure of PHI to only what’s needed for legitimate healthcare, payment, or operational purposes. You can’t sell patient data to advertisers. You can’t use a patient’s medical history to market unrelated products. You can’t disclose someone’s psychiatric diagnosis to their employer without explicit consent.
The rule also grants patients specific rights. Patients have the right to access their own medical records. They have the right to request corrections if they believe their records are inaccurate. They have the right to receive an accounting of who has accessed their records. They have the right to request restrictions on uses and disclosures, though organizations can decline reasonable requests.
In practical terms, the Privacy Rule requires you to implement policies and procedures that define who can access PHI and why. It requires you to document those policies. It requires you to educate staff about them. And it requires you to have a way to enforce them. Many organizations satisfy the Privacy Rule with detailed access policies, role-based access controls, and training programs.
The Security Rule
The Security Rule, issued in 2003, is the teeth of HIPAA. While the Privacy Rule sets policy boundaries, the Security Rule demands specific technical, physical, and administrative safeguards.
The Security Rule applies specifically to electronic PHI (ePHI)—health information stored or transmitted in digital form. It requires covered entities and business associates to implement safeguards across three dimensions: administrative, physical, and technical. We’ll dive deeper into these later, but the core requirement is that you must implement reasonable and appropriate safeguards to protect ePHI against unauthorized access, use, or disclosure.
What “reasonable and appropriate” means is intentionally flexible. HIPAA doesn’t mandate a specific firewall or encryption standard. Instead, it requires you to conduct a risk assessment, identify vulnerabilities, and implement controls that address those vulnerabilities at a level proportionate to your risk. A small health coaching app with 500 users might implement simpler controls than a national pharmacy benefit manager handling millions of prescription records. Both can be HIPAA compliant, but their implementation differs.
The Breach Notification Rule
The Breach Notification Rule, established in 2009, requires organizations to notify individuals if their PHI is accessed or disclosed without authorization.
A breach is broadly defined as any unauthorized acquisition, access, use, or disclosure of PHI. If a laptop containing unencrypted patient records is stolen, that’s a breach. If a cloud database is misconfigured and exposes patient information to the public internet, that’s a breach. If a disgruntled employee downloads a patient list and emails it to a personal account, that’s a breach.
When a breach occurs, you must notify affected individuals without unreasonable delay (typically within 30 days). You must also notify major media outlets if the breach affects more than 500 residents in a jurisdiction. And you must report the breach to the Department of Health and Human Services Office for Civil Rights (OCR). These notifications aren’t optional—they’re mandatory, and they’re public. Every significant healthcare breach is documented in the HHS breach notification database, visible to anyone with an internet connection.
HIPAA Security Safeguards: Administrative, Physical, and Technical
The Security Rule requires safeguards across three categories. Understanding what falls into each category helps you build a comprehensive security program.
Administrative Safeguards
Administrative safeguards are the policies, procedures, and governance that create a culture of security.
These include workforce security (hiring people with appropriate backgrounds and only granting access to those who need it), information access management (defining who can access what data and why), security awareness training (teaching staff about security risks and your organization’s policies), security incident procedures (documenting how you’ll respond to breaches or security events), and contingency planning (ensuring you can recover from disasters).
Administrative safeguards also include designating a security officer who owns your compliance program, conducting regular risk assessments, and maintaining security documentation. They require you to have contracts with vendors that include HIPAA-required clauses. They require you to audit access logs and monitor for suspicious activity. In essence, administrative safeguards are about creating systems and accountability.
Physical Safeguards
Physical safeguards address the physical security of your facilities and infrastructure.
These include facility access controls (ensuring unauthorized people can’t walk into your data center or office and steal a server or laptop), workstation use policies (defining how employees can use their computers and what protections are required), and workstation security (implementing controls like locked screens, encryption, and automatic logoff on devices that access PHI).
Physical safeguards also cover media and equipment controls—how you handle, store, and dispose of hardware that may contain PHI. If you’re decommissioning a hard drive that touched patient data, you can’t just throw it in a recycling bin. You need documented procedures for secure destruction.
For SaaS companies, physical safeguards often involve your cloud infrastructure provider. If you’re running on AWS, Google Cloud, or Azure, you inherit physical security controls from the provider’s data centers. But you’re responsible for verifying those controls exist and are appropriate. This is why you should always review a cloud provider’s security compliance documentation before signing a contract.
Technical Safeguards
Technical safeguards are the security technologies and processes that prevent unauthorized access to ePHI.
These include access controls (using authentication mechanisms like passwords or multi-factor authentication to ensure only authorized users can access systems), encryption (protecting data both in transit over the network and at rest in storage), audit controls (logging access to PHI so you can detect suspicious activity), and integrity controls (ensuring that PHI hasn’t been altered without authorization).
Technical safeguards also include transmission security (using encrypted channels for network communications), system activity monitoring (tracking what’s happening on your systems), and secure disposal (ensuring deleted data can’t be recovered). For SaaS companies, technical safeguards often include encryption keys managed by your organization, not by cloud providers. You own the encryption keys, so only your platform can decrypt the data.
The HIPAA Compliance Checklist (Step-by-Step, Practical)
Building HIPAA compliance doesn’t happen overnight, but it follows a predictable process. Here’s a practical, step-by-step approach.
Step 1: Determine Your HIPAA Status
First, be honest about whether HIPAA applies to your organization. Are you a covered entity? A business associate? A subcontractor? If you handle healthcare data in any form, you need to assume HIPAA applies and plan accordingly.
Step 2: Conduct a Risk Assessment
This is non-negotiable. You need to document what data you have, how it flows through your systems, who can access it, and where vulnerabilities exist. Many organizations hire third-party assessors for this. The goal is to create a comprehensive inventory of ePHI and the systems that process it.
Step 3: Implement Technical Safeguards
Based on your risk assessment, implement controls to protect ePHI. This typically includes encryption (both in transit and at rest), network segmentation (isolating systems that handle PHI from general corporate networks), multi-factor authentication (requiring more than a password to access sensitive systems), and logging (recording who accessed what data, when, and why).
Step 4: Document Policies and Procedures
Write clear policies for access control, incident response, workforce training, and security incident reporting. These documents don’t need to be lengthy, but they need to exist and be accessible to staff. Staff should know that if they suspect a breach, they have a clear process for reporting it.
Step 5: Train Your Workforce
Everyone who touches PHI—engineers, customer support staff, sales people who discuss patient data, even office administrators who file documents—needs security training. This training should cover what PHI is, why it matters, and their specific responsibilities. Most organizations conduct this training annually.
Step 6: Implement Access Controls
Only people who need access to PHI for their job should have it. Engineers building your patient portal need access to the database. Your marketing team doesn’t. Implement role-based access control that limits database access to specific systems and specific team members. Remove access when people leave your organization.
Step 7: Establish Business Associate Agreements (BAAs)
If you’re a covered entity or business associate, you must have written contracts with any vendor that accesses PHI. These are called Business Associate Agreements or BAAs. They include specific HIPAA-required language and place security obligations on the vendor. If you’re a SaaS company, you should have BAA templates ready for your customers.
Step 8: Create an Incident Response Plan
Breaches happen. Your response to a breach determines whether HIPAA violations occur. Document exactly what you’ll do if you discover a breach: who to notify, when, what information to include in notifications, how to investigate the breach, and how to prevent it from happening again.
Step 9: Conduct Regular Audits
At least annually (and after major changes), audit your security practices. Check that access controls are working. Verify that encryption is in place. Review access logs for suspicious activity. Document your findings and remediate any gaps.
Step 10: Stay Updated on Regulation Changes
HIPAA evolves. The Department of Health and Human Services periodically updates guidance, and industry standards (like encryption algorithms or authentication methods) change. Subscribe to HHS notifications, follow healthcare security news, and budget time annually to reassess your compliance posture.
HIPAA Risk Assessment: What It Is and Why You Can’t Skip It
A HIPAA risk assessment is your compliance foundation. It’s the documented process of identifying what ePHI you have, how it moves through your systems, what could go wrong, and how bad the damage would be if something did.
Most organizations approach risk assessments as a box-checking exercise. You hire a consultant, they send a form, you fill it out, they give you a report, and everyone moves on. If that’s your approach, you’re probably missing significant gaps.
A meaningful risk assessment works differently. It requires honest conversations with technical teams about your infrastructure. It requires a data flow diagram showing where PHI enters your systems, how it’s processed, where it’s stored, who can access it, and where it exits. It requires identifying every system that touches PHI—not just your primary database but your backups, your analytics tools, your customer support systems, your disaster recovery environments.
Once you map that landscape, you identify vulnerabilities. Is data encrypted at rest? Is it encrypted in transit? Are access controls enforced? Are logs being retained? Do employees have backups of patient data on personal laptops? Are test environments using real patient data? Are old servers decommissioned securely? These questions often reveal surprising gaps.
Finally, you assess the impact if each vulnerability is exploited. If a database is compromised, how many patients are affected? What information is exposed? How likely is the vulnerability to be exploited? Based on that analysis, you prioritize remediation. You fix the most critical vulnerabilities first.
The result should be a living document—a risk assessment that you update regularly as your systems and threat landscape evolve. Many organizations assess risk annually, but if you make significant changes (like moving to a new cloud provider or adding new data processing), you should reassess immediately.
HIPAA Penalties: What Non-Compliance Actually Costs
Understanding HIPAA penalties matters because it helps you justify the investment in compliance. HIPAA isn’t just about doing the right thing—it’s about avoiding catastrophic financial risk.
The Office for Civil Rights (OCR), the HHS agency that enforces HIPAA, has authority to assess civil monetary penalties. These penalties start at $100 per violation per day. That sounds manageable until you do the math. If you’re running a telehealth platform with 10,000 patient records and your database is breached, exposing all 10,000 records, that’s 10,000 violations. At $100 per violation per day, your exposure is $1 million per day. If the breach goes undetected for even a week, you’re facing a $7 million penalty. Real breaches have triggered multi-million-dollar settlements.
The penalties vary based on the severity of the violation. The minimum is $100 per violation per day. The maximum is $50,000 per violation per day (approximately $18.2 million per year per violation category). The OCR also considers factors like whether you knowingly violated HIPAA, whether you have a compliance program in place, and how quickly you remediated the issue once you discovered it.
Beyond financial penalties, there are reputational costs. Major healthcare breaches are public. Your organization will be listed in the HHS breach notification database. Healthcare organizations that were considering contracting with you will reconsider. Investors will question your risk management. And if the breach was severe or involved negligence, criminal charges are possible.
The business case for HIPAA compliance is straightforward: the cost of building a robust compliance program is a fraction of the cost of a breach. Most organizations spend less than their annual breach liability exposure on compliance infrastructure.
HIPAA vs. HITRUST: Do You Need Both?
If you’re new to healthcare compliance, you’ve probably heard of HITRUST. It’s another healthcare data security standard, and there’s often confusion about the relationship between HIPAA and HITRUST.
HIPAA is a federal law. HITRUST is a private certification framework. They’re complementary but different.
HITRUST stands for Health Information Trust Alliance. It’s a common security framework specifically designed for healthcare organizations. It incorporates HIPAA requirements but adds additional controls from other frameworks like ISO 27001 and NIST Cybersecurity Framework. Essentially, HITRUST is a comprehensive security standard that includes and exceeds HIPAA.
Do you need HITRUST if you have HIPAA compliance? That depends on your customers. If your customers only require HIPAA, compliance with HIPAA is sufficient. If your customers are large health systems or payers that require HITRUST certification, you need to pursue it. HITRUST certification involves a third-party audit and costs significantly more than a self-assessment.
For early-stage health tech companies, most start with HIPAA compliance and self-assessment. As they grow and pursue enterprise contracts, they often pursue HITRUST or SOC 2 Type II certifications. These certifications serve as proof to customers that your security controls are independently verified.
The practical answer: Start with HIPAA compliance. It’s a legal requirement for anyone handling healthcare data. HITRUST or SOC 2 are downstream decisions you make based on customer demands.
How Soter Advisory Can Help
Building and maintaining HIPAA compliance is complex. It requires expertise across healthcare law, security architecture, and regulatory procedures. It also requires ongoing attention—compliance isn’t a one-time project.
This is where working with experienced advisors makes a difference. Soter Advisory specializes in helping health tech companies, digital health startups, and healthcare technology vendors navigate compliance. We help you assess whether HIPAA applies to your business, conduct comprehensive risk assessments, design compliant architecture, implement the right safeguards, and maintain your compliance posture as your business grows.
If you’re uncertain about your compliance obligations, or if you know you need to be compliant but aren’t sure where to start, a conversation with our team can clarify your path forward. We’ve worked with startups in your position and know the questions you need answered.
Conclusion
HIPAA compliance isn’t optional if you touch healthcare data. It’s a legal requirement, and it’s also the difference between being trusted by healthcare organizations and being locked out of the market.
The good news is that HIPAA compliance is achievable. You don’t need to be a regulatory expert. You need a clear understanding of your obligations, a systematic approach to implementation, and commitment from leadership to build security into your product rather than tacking it on later.
Start with a risk assessment. Understand what PHI you handle. Build technical safeguards into your architecture. Document your policies. Train your team. And establish a process for continuous improvement.
If you’re ready to make compliance a competitive advantage rather than a burden, the first step is a conversation. Reach out to Soter Advisory to discuss your specific situation and how we can help you build compliant infrastructure that customers trust.
Ready to achieve HIPAA compliance? Contact Soter Advisory today for a consultation tailored to your business.