HIPAA Compliance Requirements: The Complete Guide

Every week, a founder or clinic administrator asks us some version of the same question: "What are the actual HIPAA compliance requirements, and how do we know when we are done?" The honest answer is that HIPAA is not a checklist you finish once. It is a US federal law with ongoing obligations that scale with your organization's size and risk. In this guide I walk through every HIPAA requirement that matters, in plain language, drawing on the engagements my team at Atlant Security runs for healthcare providers, digital health startups, and the vendors who process patient data on their behalf. By the end you will understand what the law expects, where organizations most often fail, and how to build a program that survives an Office for Civil Rights investigation.

What HIPAA Is and Who Must Comply

HIPAA is the Health Insurance Portability and Accountability Act of 1996. Most people think of it as a privacy law, but it started as an insurance-portability and administrative-simplification statute. The privacy and security obligations that dominate compliance work today came from regulations issued afterward by the US Department of Health and Human Services (HHS). Enforcement sits with the HHS Office for Civil Rights, or OCR. When a hospital pays a settlement or a health-tech company signs a corrective action plan, that is OCR at work.

Two categories of organizations must comply. The first is covered entities: health plans, healthcare clearinghouses, and healthcare providers who transmit health information electronically in connection with transactions such as claims and eligibility checks, which captures nearly every doctor's office, hospital, pharmacy, and insurer in the country. The second category is business associates, and this is the one that trips up the technology industry. If your company creates, receives, maintains, or transmits protected health information on behalf of a covered entity, you are a business associate and you are directly liable under the law. A billing company, cloud host, telehealth platform, analytics vendor, transcription service, or EHR vendor: all business associates.

The critical point founders miss is that HIPAA compliance requirements do not care whether you are a two-person startup or a national hospital chain. The obligations are the same in kind; only the scale of implementation differs. If you touch patient data, the law reaches you.

The Four HIPAA Rules You Must Satisfy

HIPAA compliance requirements are organized into four regulatory rules, and understanding how they fit together underpins everything else.

The Privacy Rule governs the use and disclosure of PHI in any form, whether spoken, written, or electronic. It defines patient rights, limits how PHI can be shared, and requires the "minimum necessary" principle. The Security Rule applies specifically to electronic PHI and sets out the administrative, physical, and technical safeguards you must implement to protect it. The Breach Notification Rule tells you what to do when protected data is compromised: who to notify, and how quickly. The Enforcement Rule establishes how OCR investigates complaints, conducts audits, and calculates the penalties that follow violations.

Layered on top of these is the HITECH Act of 2009 and the 2013 Omnibus Rule, which modernized HIPAA for the digital era. The most important change is that business associates became directly and independently liable, not merely contractually bound to their clients. Before Omnibus, a SaaS vendor could argue HIPAA was the hospital's problem; after Omnibus, OCR can investigate and fine the vendor directly. HITECH also strengthened breach notification and raised the penalty tiers, so any modern reading of HIPAA requirements is really a reading of it as amended by HITECH and Omnibus.

Covered Entities vs Business Associates

Because so much of our client base is on the vendor side, we spend real time clarifying where an organization sits, since that determines your obligations and contracts.

A covered entity delivers, pays for, or clears healthcare transactions. A business associate performs a service for a covered entity that involves access to PHI. The relationship is not always one layer deep: when a business associate hands PHI to its own vendor, for example a telehealth company using a third-party cloud database, that downstream vendor is a subcontractor business associate and is equally bound. Liability flows down the chain.

The instrument that binds this chain is the Business Associate Agreement, or BAA: a contract in which the business associate promises to safeguard PHI, use it only for permitted purposes, report breaches, and bind its subcontractors to the same terms. You must have a signed BAA with every covered entity you serve and every subcontractor you use before any PHI changes hands. The absence of a BAA is itself a HIPAA violation, and OCR has issued six- and seven-figure settlements over missing agreements alone.

A dangerous myth is that using a "HIPAA-compliant" cloud provider makes you compliant. It does not. AWS, Google Cloud, and Microsoft Azure will sign a BAA and offer services configured to support compliance, but the BAA carves up responsibility: the provider secures the infrastructure, and you secure how you configure and use it. If you are unsure where your obligations begin, our HIPAA compliance consulting team maps the full data flow and flags every place a BAA is required.

Protected Health Information (PHI) and ePHI

Protected Health Information is individually identifiable health information held or transmitted by a covered entity or business associate, in any form. That includes clinical data such as diagnoses and lab results, but also eighteen categories of identifiers when tied to health information: names, addresses, dates, phone and account numbers, Social Security and medical record numbers, biometric identifiers, full-face photos, IP addresses, device identifiers, and more. When PHI exists in electronic form it is electronic PHI, or ePHI, and it is ePHI that the Security Rule protects.

Because the scope of PHI is broad, mapping where it lives across your databases, backups, logs, email, and third-party tools is a real project. And because properly de-identified data, stripped of all identifiers under the Privacy Rule standards, is no longer PHI, many startups reduce their burden by de-identifying data for analytics rather than working with live PHI everywhere.

HIPAA Security Rule Requirements in Depth

The Security Rule is where most technical teams spend the bulk of their effort, and it is the part of HIPAA compliance requirements most likely to be tested in an OCR investigation. It is organized into three categories of safeguards, each containing standards and, beneath those, implementation specifications labeled either required or addressable. This distinction is misunderstood constantly: "addressable" does not mean optional. It means you must either implement the specification, implement an equivalent alternative, or document a reasoned justification for why it is not reasonable and appropriate in your environment. Ignoring an addressable item without documentation is a violation.

Administrative Safeguards

Administrative safeguards are the policies, procedures, and management actions that govern your security program. They are the largest category and the one auditors scrutinize hardest.

• Security Management Process: the cornerstone standard, requiring a Security Risk Analysis, a risk management process to reduce identified risks, a sanction policy for workforce members who violate rules, and regular information system activity review. I return to the risk analysis below.
• Assigned Security Responsibility: you must name a security official responsible for your policies. In a small company this may be a founder or fractional leader; in a hospital it is a dedicated CISO. The role must exist and be documented.
• Workforce Security: procedures ensuring only appropriate staff access ePHI, including authorization, clearance, and prompt termination of access when someone leaves.
• Information Access Management: role-based access controls that grant the minimum access each role needs.
• Security Awareness and Training: ongoing training for all workforce members, including security reminders, malware protection, log-in monitoring, and password management.
• Security Incident Procedures: a documented way to identify, respond to, and report security incidents.
• Contingency Plan: data backup, disaster recovery, and emergency-mode operation plans, with testing and revision, so ePHI stays available and recoverable after ransomware, an outage, or a disaster.
• Evaluation: periodic evaluation of how well your safeguards continue to meet the rule as your environment changes.

Physical Safeguards

Physical safeguards protect the hardware and facilities where ePHI lives. They still apply when everything runs in the cloud, because your workforce uses laptops, phones, and offices.

• Facility Access Controls: limiting physical access to systems and the buildings housing them, including contingency operations and maintenance records.
• Workstation Use and Security: policies defining how and where workstations that access ePHI may be used, plus physical protections for them.
• Device and Media Controls: governing how you receive, move, reuse, and dispose of hardware and media that hold ePHI. Many breaches still come from unencrypted lost laptops and improperly wiped drives.

Technical Safeguards

Technical safeguards are the controls built into your systems.

• Access Control: unique user identification (required), emergency access procedures (required), and automatic logoff and encryption of data at rest (both addressable), because shared accounts destroy accountability.
• Audit Controls: mechanisms that record and examine activity in systems containing ePHI. If you cannot show who accessed what and when, you cannot investigate a breach.
• Integrity: controls to ensure ePHI is not improperly altered or destroyed, including mechanisms to confirm data has not changed.
• Person or Entity Authentication: verifying that a person or system seeking access is who they claim to be. This is where multi-factor authentication belongs, which OCR increasingly expects.
• Transmission Security: protecting ePHI in transit against interception, which in modern terms means encryption (TLS) and integrity controls across networks.

Encryption is technically "addressable" in the Security Rule, but choosing not to encrypt ePHI at rest and in transit is nearly impossible to justify today, and unencrypted data is what turns a lost device into a reportable breach, so we treat it as effectively mandatory. If you want an independent read on whether your safeguards hold up, our IT security audit tests these controls against the way real attackers operate, not against a paper checklist.

The Security Risk Analysis: The Single Most-Cited Failure

If you take one thing from this guide, take this: the Security Risk Analysis is the foundation of HIPAA compliance requirements, and its absence or inadequacy is the most frequently cited failure in OCR enforcement actions. When OCR investigates a breach, the finding is often not merely that the organization got hacked, but that it never assessed the risks to the confidentiality, integrity, and availability of its ePHI.

A proper risk analysis is a documented, organization-wide process. It inventories everywhere ePHI is created, received, maintained, and transmitted; identifies threats and vulnerabilities; assesses current measures; and determines the likelihood, impact, and level of each risk. It is not a vendor questionnaire, a checklist, or a scan of a single application, and it must be repeated periodically and whenever your environment changes materially.

The risk analysis then feeds risk management: implementing controls to reduce identified risks to a reasonable level. A risk analysis that sits in a drawer with no remediation is nearly as damaging as none at all, because it proves you knew about a risk and did nothing. This is exactly the kind of ongoing, judgment-heavy work a virtual CISO is built to own for organizations that cannot yet justify a full-time security executive.

HIPAA Privacy Rule Requirements

The Privacy Rule governs how PHI may be used and disclosed and grants patients enforceable rights over their information. Several requirements recur in every compliant program.

The minimum necessary standard requires that when you use, disclose, or request PHI, you limit it to the least amount needed for the purpose. It does not apply to treatment, where a clinician needs the full picture, but it very much applies to billing, operations, and most disclosures, which in practice means role-based access and disciplined data-sharing habits.

Covered entities must provide a Notice of Privacy Practices explaining how information is used and disclosed and what rights patients hold. Those patient rights include the right to access and obtain a copy of their records, request corrections (amendments), receive an accounting of certain disclosures, request restrictions on uses and disclosures, and request confidential communications. The right of access is an enforcement priority of its own, and OCR has pursued many settlements against providers who failed to give patients timely copies of their records. Business associates support these rights through their covered-entity clients and their BAAs.

Breach Notification Requirements

Despite your best safeguards, breaches happen, and the Breach Notification Rule dictates what you do next. A breach is generally an impermissible acquisition, access, use, or disclosure of unsecured PHI that compromises its security or privacy. Properly encrypted PHI that is lost is often not a reportable breach, one more reason encryption matters.

When a breach of unsecured PHI occurs, a covered entity must notify affected individuals without unreasonable delay and no later than 60 days after discovery. It must notify the HHS Secretary: promptly for breaches affecting 500 or more individuals, and annually for smaller ones. For breaches affecting 500 or more residents of a state, it must also notify prominent media outlets serving that area. Business associates must notify the covered entity of a breach on their side, again no later than 60 days, so the covered entity can meet its downstream deadlines. Your BAA should spell out a tighter internal timeline.

Workforce Training, Policies, and Sanctions

HIPAA is emphatic that technology alone does not create compliance; your workforce is both your first line of defense and your most common point of failure. The law requires documented policies and procedures covering every applicable standard, retained for six years. It requires training for all workforce members, delivered at onboarding, refreshed periodically, and repeated when policies change. And it requires a sanction policy: documented, consistently applied consequences for employees who violate your rules. In investigations, OCR routinely asks for training logs and sanction records, and organizations that cannot produce them struggle even when their technical controls were sound.

HIPAA Penalties and Commercial Risk

The consequences of falling short fall into three buckets: civil penalties, criminal penalties, and commercial damage.

Civil monetary penalties are tiered by culpability: the more the organization knew or should have known, the higher the penalty per violation.

Tier	Culpability	Approximate per-violation range
1	Did not know and could not reasonably have known	Roughly $130 to $65,000
2	Reasonable cause, not willful neglect	Roughly $1,300 to $65,000
3	Willful neglect, corrected within 30 days	Roughly $13,000 to $65,000
4	Willful neglect, not corrected	Roughly $65,000 and up per violation

These figures adjust annually for inflation, so treat them as ranges. Penalties accrue per violation, and identical violations of the same requirement are capped at an annual maximum currently around $2 million per category. Because a single breach can involve many records and multiple violated standards, real-world settlements frequently reach hundreds of thousands or millions of dollars, often with a multi-year corrective action plan that OCR monitors.

Criminal penalties are separate and enforced by the Department of Justice. Knowingly obtaining or disclosing PHI in violation of HIPAA can bring fines and up to one year in prison; under false pretenses the ceiling rises to five years; and doing so with intent to sell, transfer, or use PHI for commercial advantage, personal gain, or malicious harm can bring fines up to $250,000 and up to ten years in prison.

For most founders I advise, though, the sharpest risk is commercial. Hospitals and health systems will not sign with a vendor that cannot demonstrate a mature HIPAA program; their procurement teams now send detailed security questionnaires and demand a BAA before any pilot. A weak posture does not just risk a fine years away; it kills deals now. Many of our clients pursue HIPAA readiness alongside SOC 2 because enterprise healthcare buyers ask for both.

Is There a HIPAA Certification?

No, and this is one of the most persistent myths in the industry: there is no official HIPAA certification. HHS and OCR do not certify, endorse, or approve any product, service, or organization as "HIPAA certified." Any vendor selling a badge that claims otherwise is misrepresenting how the law works. Compliance is a state you demonstrate through your risk analysis, policies, controls, and documentation, not a certificate you earn once.

What you can obtain is independent third-party validation that lends credibility with buyers. HITRUST CSF certification is the most recognized framework in healthcare, maps to HIPAA, and is often requested by large health systems. A SOC 2 report with HIPAA mapped in is another common attestation, and an independent readiness assessment documented by a qualified third party gives you evidence of due diligence. None of these is a government certification, and none substitutes for doing the underlying work.

How Long HIPAA Compliance Takes and What It Costs

The most common question after "what are the requirements" is "how long and how much." It depends on your size, architecture, and prior work, but here are realistic ranges.

For a typical small-to-mid digital health company starting near zero, a focused program to reach a defensible baseline usually takes about 90 days. The first weeks go to a thorough risk analysis and data mapping. The next month goes to writing policies and closing the highest-priority technical gaps such as access control, encryption, logging, and multi-factor authentication. The final stretch covers workforce training, BAAs, incident and contingency planning, and the documentation package. Larger organizations with legacy systems should expect six months or more, and reaching baseline is the start of an ongoing program: the risk analysis must be revisited at least annually and whenever the environment changes.

On cost, a small startup engaging outside help for a risk analysis, policies, and remediation guidance typically spends in the low tens of thousands of dollars for the initial push, plus internal engineering time to fix findings. Mid-size organizations often land in the mid five figures to low six figures once tooling, remediation, and staff time are included, and HITRUST raises costs further. Ongoing compliance, training, and annual reassessment is a recurring line item, which many organizations control by using fractional security leadership rather than hiring a full-time CISO too early.

Common Gaps and a Readiness Checklist

Across the assessments we run, the same gaps appear again and again: a missing or superficial Security Risk Analysis; missing BAAs, especially with smaller downstream vendors; unencrypted laptops, backups, and databases; no multi-factor authentication; audit logging that is off or never reviewed; policies that exist on paper but are not followed; no evidence of workforce training; and no tested incident-response or contingency plan. Use the checklist below as a fast self-diagnostic.

• We have conducted a thorough, documented Security Risk Analysis within the last year and after every major change.
• We have a written risk management plan and evidence that we are closing identified risks.
• We have named a security official responsible for our HIPAA program.
• We have signed BAAs with every covered entity we serve and every subcontractor that touches PHI.
• We have mapped everywhere PHI and ePHI lives, moves, and is backed up.
• We encrypt ePHI at rest and in transit, and we enforce multi-factor authentication.
• Every user has a unique account, and audit logs are enabled and reviewed.
• We have written, current policies covering the Privacy and Security Rules, retained for six years.
• All workforce members are trained on onboarding and periodically, with records kept.
• We have a sanction policy and apply it consistently.
• We have tested backup, disaster-recovery, and incident-response plans.
• We know our breach-notification obligations and deadlines and have a plan to meet them.

If you cannot confidently check every box, you have identified your roadmap. HIPAA compliance requirements are demanding but achievable with a methodical program and honest documentation, and the organizations that get into trouble are almost always the ones that never seriously assessed their risk.

HIPAA Compliance Requirements FAQ

Do small startups really have to comply with HIPAA, or is it just for hospitals?

Yes. HIPAA compliance requirements apply based on your relationship to PHI, not your size. A two-person health-tech startup processing patient data for a clinic is a business associate and is directly liable under HITECH and the Omnibus Rule. The obligations are the same as for a hospital; only the scale of implementation differs.

What is the difference between a covered entity and a business associate?

A covered entity delivers, pays for, or clears healthcare, such as a provider, health plan, or clearinghouse. A business associate performs a service that involves access to PHI, such as billing, hosting, analytics, or a SaaS platform. Both must comply, and a business associate needs a signed BAA with each covered entity and its subcontractors before handling PHI.

Is encryption required under the HIPAA Security Rule?

Encryption is technically "addressable," not flatly "required." But given current technology, choosing not to encrypt ePHI at rest and in transit is very hard to justify, and unencrypted data is what turns a lost device into a reportable breach. We treat strong encryption as effectively mandatory.

Is there such a thing as HIPAA certification?

No. HHS and OCR do not certify anyone as HIPAA compliant, and no product can be officially "HIPAA certified." You demonstrate compliance through your risk analysis, controls, policies, and documentation. Independent validation such as HITRUST or a SOC 2 report with HIPAA mapped in adds credibility with buyers but is not a government certification.

What is the most common reason organizations get penalized?

The single most-cited failure in OCR enforcement is the absence of an accurate, thorough Security Risk Analysis, or one so superficial it does not count. The risk analysis is the foundation of the Security Rule, and a missing one signals that the organization never seriously managed its risks.

How quickly do we have to report a breach?

A covered entity must notify affected individuals without unreasonable delay and no later than 60 days after discovery, notify HHS (immediately for breaches of 500 or more people, annually for smaller ones), and notify media for large breaches in a state. A business associate must notify its covered entity within the same 60-day limit.

How much can HIPAA violations cost?

Civil penalties are tiered by culpability, from roughly a few hundred to tens of thousands of dollars per violation, with an annual cap around $2 million per category. Real settlements often reach six or seven figures with multi-year corrective action plans, and criminal violations can add fines up to $250,000 and up to ten years in prison. For most vendors, the larger day-to-day risk is losing healthcare deals over a weak posture.

How long does it take to become HIPAA compliant?

A focused small-to-mid-size organization can reach a defensible baseline in about 90 days: risk analysis and data mapping first, then policies and priority technical fixes, then training, BAAs, and documentation. Larger organizations with legacy systems need six months or more. Compliance is ongoing, so revisit your risk analysis at least annually.

Ready to get started? Atlant Security helps companies close security gaps and pass compliance fast, led personally by a former Microsoft security consultant with 200+ assessments across 14 countries. Book a free strategy call and get a fixed-price proposal within 24 hours.