What Is HIPAA Compliance? Requirements, Risk Assessment, and How to Get Started
Updated: April 30, 2026
In February 2025, Warby Parker received a $1.5 million civil monetary penalty from the HHS Office for Civil Rights for failing to meet HIPAA’s Security Rule requirements. Warby Parker sells glasses. Not medical records. Not insurance claims. Glasses.
We bring this up not to pile on Warby Parker, but because it’s the fastest way to make a point we have to constantly make with Bay Area founders and COOs: HIPAA reaches much further than most people think. If your product handles any health-related data for a covered customer, or if you’re building in healthtech, fintech, or SaaS and PHI touches your systems anywhere in the stack, you may already be in scope and not know it.
That uncertainty is expensive. So let’s clear it up.
HIPAA compliance is the ongoing process by which covered entities and business associates implement administrative, physical, and technical safeguards to protect patients’ electronic protected health information (ePHI) under the Health Insurance Portability and Accountability Act of 1996. This post covers who has to do it, what it actually requires, how to run a risk assessment, and what happens when you skip it.
What Is HIPAA Compliance?
HIPAA was enacted in 1996, mostly to solve a health insurance portability problem for workers who changed jobs. The part that matters to most businesses today is Title II, which sets national standards for the security and privacy of health information. Three rules form the core of any HIPAA compliance program.
The Privacy Rule governs who can access and use protected health information (PHI). PHI is a surprisingly broad category: Social Security numbers, diagnoses, billing records, lab results, full facial photos, and dozens of other data types all qualify. The Privacy Rule specifies when PHI can be disclosed, to whom, and under what conditions.
The Security Rule focuses specifically on electronic PHI (ePHI). It requires covered organizations to implement administrative, physical, and technical safeguards to ensure the confidentiality, integrity, and availability of ePHI. This is where most of the day-to-day IT compliance work lives, and it’s the rule OCR (Office for Civil Rights) has been most aggressively enforcing.
The Breach Notification Rule requires covered entities to notify affected individuals, HHS, and in some cases the media when a breach of unsecured PHI occurs. The notification window is 60 days from the date you discover the breach. Not 60 days from when you feel ready. 60 days.
Together, these three rules define the compliance landscape. The Security Rule is the most technically demanding, and it’s where we spend most of our time when working with clients on their HIPAA programs.
Who Needs to Be HIPAA Compliant?
HIPAA applies to two categories of organizations: covered entities and business associates. Which one you are determines your obligations, so this is the right place to start.
Covered Entities
A covered entity is any organization that electronically transmits health information in connection with transactions HHS has defined under HIPAA. Broadly, that means:
Healthcare providers that submit electronic claims, referral authorizations, or eligibility inquiries.
Health plans, including health, dental, vision, and prescription drug insurers, HMOs, and Medicare and Medicaid programs.
Healthcare clearinghouses that process nonstandard health information into standard formats.
The CDC has a covered entity determination tool on its website. Use it if you’re unsure. And be honest with yourself when you do, because ignorance of your status has never held up as a defense against HIPAA penalties.
Business Associates
A business associate is any vendor, contractor, or service provider that creates, receives, maintains, or transmits PHI on behalf of a covered entity. This is the category that catches most Bay Area tech companies off guard.
If your platform stores, processes, or transmits health data for a covered entity customer, you are a business associate. Full stop. Cloud storage providers, billing services, EHR software companies, IT providers like us, and any SaaS tool that touches patient data. The covered entity is required to execute a Business Associate Agreement (BAA) with you before sharing any PHI. We’ll get to BAAs in a moment.
Worth saying plainly: being a business associate does not mean you are off the hook because your customer is the "real" covered entity. Your HIPAA obligations are real and enforceable.
HIPAA Compliance Requirements: What the Law Actually Expects
Here’s something that trips people up: HIPAA does not publish a compliance checklist. What it establishes are standards and implementation specifications, some required, some addressable. "Addressable" does not mean optional. It means you have flexibility in how you meet the specification, but you must address it, document your reasoning, and implement something equivalent if the standard doesn’t fit your situation.
Here’s what a functioning HIPAA compliance program covers:
Policies and Procedures
You need documented policies and procedures that reflect HIPAA’s regulatory standards. These cannot be set-and-forget documents. They need to be reviewed and updated whenever the regulations change or your operations change in a meaningful way. Annual workforce training on these policies is required, and you need to keep records of that training. If an auditor asks to see proof that your staff completed HIPAA training last year and you can’t produce it, that’s a gap.
Business Associate Agreements
Every vendor that handles PHI on your behalf needs a signed BAA before any data is shared. BAAs have to specify what the business associate can do with the data, require appropriate safeguards, and obligate them to report breaches. Annual BAA review is a requirement, not a best practice. Vendor relationships change, and your agreements need to keep up.
(A note from our own experience: BAA management is one of the things that falls through the cracks most often, especially at fast-growing companies. Someone signed agreements at Series A, the vendor list doubled, and nobody went back to check. This is exactly the kind of gap OCR looks for.)
Documentation
Documentation is the foundation of any HIPAA audit. OCR uses predefined audit protocols that are publicly available, and auditors want evidence: not just policies, but proof of implementation. Document your risk assessments, remediation plans, training records, incident logs, and vendor agreements. If it isn’t documented, OCR treats it as if it didn’t happen.
Annual Security Audits
HIPAA requires annual audits of your administrative, physical, and technical safeguards against Privacy and Security Rule standards. If the audit finds gaps, you must document a remediation plan and actually follow through. Finding gaps is fine. Finding gaps and doing nothing about them is a compliance failure in its own right.
Incident Management
HIPAA requires a formal process for reporting and managing security incidents. This is different from the Breach Notification Rule. A security incident is any attempted or actual unauthorized access, use, disclosure, modification, or destruction of ePHI. Not all incidents become reportable breaches, but all incidents need to be logged and managed. Staff need to know what counts as an incident and how to report it. Vague awareness is not enough.
How to Perform a HIPAA Risk Assessment
If there’s one thing OCR has made crystal clear in 2025, it’s this: the risk assessment is not a formality. In the first five months of 2025 alone, OCR announced ten resolution agreements targeting organizations that failed to conduct an enterprise-wide risk analysis. Penalties ranged from $25,000 to $3,000,000. The common thread in every case was that the organization had not done the foundational work.
A HIPAA risk assessment is a thorough evaluation of the risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI in your organization. Here is how to run one:
Step 1: Identify Where ePHI Lives
Map every location where ePHI is created, received, maintained, or transmitted. Servers, workstations, laptops, mobile devices, cloud storage, email systems, third-party applications. All of it. You cannot assess risk you have not found, and the 2025 Security Rule updates now require organizations to maintain a technology asset inventory and network map documenting ePHI locations, updated annually.
This step is usually more uncomfortable than organizations expect. ePHI has a way of accumulating in places nobody intended, old email threads, shared drives, that spreadsheet someone built in 2019 and forgot about.
Step 2: Identify Threats and Vulnerabilities
Once you know where your ePHI is, work through what could go wrong. Threats are the things that could cause harm, such as ransomware, phishing attacks, insider misuse, hardware failure, and natural disasters. Vulnerabilities are the weaknesses that a threat could exploit, such as unpatched software, weak passwords, misconfigured cloud services, and a lack of encryption. Both categories need to be documented.
Step 3: Assess Your Current Controls
Evaluate the safeguards you already have and how effectively they reduce the identified risks. When we ran this process on our own infrastructure, we found that about 78% of our existing security controls already satisfied HIPAA’s technical safeguard requirements. That was reassuring. The 22% that didn’t was where the real work was.
Your numbers will differ, but starting with an honest inventory of what you already have is almost always more encouraging than people expect.
Step 4: Determine Likelihood and Impact
For each threat and vulnerability, assess how likely it is to be exploited and what the impact would be on your ePHI. This does not require a complex quantitative model. A high-medium-low rating consistently applied across your risk inventory is entirely defensible to an auditor. What auditors cannot accept is no rating at all.
Step 5: Implement Safeguards and Document Everything
Based on your risk ratings, implement safeguards that bring risk to an acceptable level. Then document the whole process: what you found, what you decided, what you implemented, and when. The documentation transforms a risk assessment from an internal exercise into an auditable compliance record. OCR wants evidence that risks were identified, prioritized, and actually managed.
Administrative, Physical, and Technical Safeguards Explained
HIPAA’s Security Rule organizes its requirements into three categories. Understanding what each one covers helps you think about compliance as a system rather than a list of disconnected requirements.
Administrative Safeguards
Administrative safeguards are the policies, procedures, and processes that govern how your workforce handles ePHI. Risk analysis, security management policies, workforce training, access authorization, and contingency planning. These are the foundation. The technical controls you implement are only as strong as the administrative framework around them. We have seen organizations with excellent technical security and almost no documentation to back it up. That is not a good audit outcome.
Physical Safeguards
Physical safeguards govern who can physically access the systems and devices where ePHI is stored. Facility access controls, workstation security policies, and device disposal procedures. For fully remote organizations, which describes a lot of our clients, physical safeguards shift to endpoint security, which includes ensuring that every laptop and mobile device accessing ePHI is properly secured, encrypted, and remotely wipeable. The physical security perimeter moves home with your employees.
Technical Safeguards
Technical safeguards are the technology controls that protect ePHI from unauthorized access. Access controls (unique user IDs, automatic logoff, encryption), audit controls (activity logs on systems containing ePHI), integrity controls (mechanisms to detect if ePHI has been improperly altered), and transmission security (encrypting ePHI in transit).
Multi-factor authentication (MFA) is not explicitly named in the original 1996 regulation, which is a fun historical artifact, but it is now effectively expected as a baseline by auditors. The 2025 proposed Security Rule updates reference it directly. If you are not running MFA on systems that touch ePHI, that is a gap worth closing immediately.
What Happens If You’re Not Compliant
HIPAA civil penalties follow a four-tier structure based on culpability. At the low end, violations committed without knowledge carry fines of $100 to $50,000 per violation. This tier has an annual cap of $25,000 for repeat violations of the same requirement. At the high end, willful neglect that goes uncorrected carries fines of $50,000 per violation and up to $1.5 million per year for repeat violations of the same provision.
Criminal penalties, handled by the Department of Justice, go further. Knowingly obtaining or disclosing PHI in violation of HIPAA: fines up to $50,000 and up to one year in prison. Under false pretenses: up to $100,000 and five years. With intent to sell or misuse PHI for personal gain: up to $250,000 and ten years.
The enforcement environment has tightened. OCR closed 21 settlements and civil monetary penalties in 2025, the second-highest annual total on record. The agency’s current focus is squarely on risk analysis failures, which means any organization that has not conducted a proper enterprise-wide risk assessment is now near the top of OCR’s list. Small practices, startups, mid-market companies. Size is not a shield.
The Warby Parker case is worth keeping in your back pocket the next time someone on your team asks whether HIPAA really applies to your company. It does if your product touches ePHI. The question is just whether you’re ready for that to be tested.
How Jones IT Helps You Navigate the HIPAA Lifecycle
We work with our clients as their in-house IT department, which means HIPAA compliance is not a project we hand off after kickoff. We are in it for the lifecycle: assessing your systems, implementing the administrative, physical, and technical controls the Security Rule requires, remediating gaps, and monitoring your environment continuously.
For organizations starting their compliance journey, we recommend pairing our IT services with a compliance automation platform. Drata is the tool we have found most valuable for companies navigating HIPAA alongside other frameworks like SOC 2 or ISO 27001. It automates evidence collection, maps controls to HIPAA requirements, and surfaces gaps before an auditor does. The time it saves on evidence gathering alone tends to pay for itself quickly.
The companies that make HIPAA compliance sustainable are the ones that treat it as a living function of the business, not an annual scramble before a renewal. We documented how that played out in our own compliance work in our HIPAA case study, which walks through how we got to certification in 90 days and what we would do differently if we were starting over.
Here is what we keep coming back to from that experience: the technical controls are usually the easier half. The harder work is cultural and procedural. Making sure the right documentation exists. Making sure BAAs are actually in place and current. Making sure incidents get reported and logged rather than quietly resolved and forgotten. That is the gap we help close, and it tends to matter more than any single technical control.
Get HIPAA-Compliant IT Support in the Bay Area
If your organization handles ePHI and you’re not confident in your compliance posture, the right time to address it is before an OCR investigation. We work with companies across SoMa, Mission Bay, the Financial District, Dogpatch, and South San Francisco on exactly this.
Reach out to us to talk through your situation, or take a look at our HIPAA compliance services and Compliance Kickstarter Program if you want a structured starting point.
About The Author
Hari SubediMarketing Manager at Jones IT
Hari is an online marketing professional with a focus on content marketing. He writes on topics related to IT, Security, and Small Business. He is also the founder and managing director of Girivar Kft., a business services company located in Budapest, Hungary.
