HIPAA regulations and rules explained: what the law covers (and where to start with compliance)

Photo: Unsplash

HIPAA is often described as “the law that stops doctors from sharing patient information,” but HIPAA regulations are broader than that. If you build software for healthcare, work with a provider, handle claims, or support patient operations, you may touch protected health information (PHI)—and HIPAA can become a business-critical requirement.

This guide covers:

• What HIPAA regulates (in plain language)
• The five HIPAA rules and what each one is trying to accomplish
• Who must comply (covered entities and business associates)
• A practical, low-drama starting point for HIPAA compliance

Related guides:

• HIPAA compliance for software development: a 7-step checklist
• Preparing for HIPAA compliance: an 8-step HIPAA compliance checklist
• HIPAA violations in 2025: staff mistakes and vendor blind spots

GIF via GIPHY

---

Key takeaways

• HIPAA is about safeguarding PHI across people, process, and technology. It’s not just “don’t talk about patients.”
• The “Privacy Rule” and “Security Rule” are the core operational pieces. They drive access, safeguards, training, and audit evidence.
• HIPAA applies to covered entities and many vendors (business associates). If you create, receive, maintain, or transmit PHI for a covered entity, you may fall into scope.
• Start by mapping PHI flows and assigning owners. HIPAA becomes manageable when you can answer: where PHI lives, who accesses it, and which controls prove protection.

---

What is HIPAA (and what does it regulate)?

The Health Insurance Portability and Accountability Act (HIPAA) became law in 1996 and has evolved through updates over time. While the original law had a major focus on health insurance portability, HIPAA is now widely associated with protecting health information and setting expectations for how organizations handle it.

At a practical level, HIPAA regulations aim to ensure PHI is:

• Kept confidential (only authorized people can access it)
• Protected from improper alteration or destruction (integrity)
• Available when needed (availability)

HIPAA does this by requiring organizations to implement safeguards (administrative, technical, and physical), document policies and procedures, train workforce members, and be able to demonstrate compliance when audited or investigated.

---

The five HIPAA rules (high level)

A useful way to understand HIPAA in broad strokes is to look at what people often call the “five HIPAA rules”:

• Privacy Rule
• Security Rule
• Transactions Rule
• Identifiers Rule
• Enforcement Rule

These labels are a simplification, but they’re a helpful map for navigating HIPAA without getting lost immediately in citations and acronyms.

1) The Privacy Rule (patient rights + permitted use/disclosure)

The Privacy Rule is where you’ll typically find the “right of access” concept: patients have rights around accessing their medical records and controlling how certain information is used and disclosed.

Operationally, this usually translates into things like:

• Role-based access to PHI
• Policies for disclosures and authorizations
• Processes to handle patient access requests within required timelines
• Minimum-necessary access principles (limiting PHI exposure)

2) The Security Rule (safeguards for electronic PHI)

The Security Rule focuses on the safeguards organizations must put in place to protect electronic PHI (ePHI). Safeguards are commonly grouped into:

• Administrative safeguards (policies, training, risk analysis, incident response)
• Technical safeguards (access controls, audit logs, encryption, transmission security)
• Physical safeguards (facility access, workstation security, device controls)

If your team builds or operates systems that store or process ePHI, the Security Rule is where most day-to-day “engineering + evidence” work lives.

3) The Transactions Rule (standardizing healthcare electronic transactions)

This area covers standardization of certain electronic healthcare transactions and code sets (for example, diagnosis/procedure coding). The goal is consistency and interoperability so records and claims can be processed and understood across organizations.

4) The Identifiers Rule (unique identifiers for providers/plans/employers)

This rule is about standard unique identifiers used in healthcare operations, such as:

• National Provider Identifiers (NPIs)
• Plan identifiers
• Employer identifiers (EINs)

The operational impact often shows up in enrollment, billing, and system integration requirements.

5) The Enforcement Rule (what happens when things go wrong)

HIPAA is enforced by the Office for Civil Rights (OCR) within the U.S. Department of Health and Human Services. The Enforcement Rule outlines how investigations work and the types of penalties that may apply for violations.

Because enforcement is real, HIPAA compliance isn’t just a “trust signal”—it’s risk management for your business.

---

Why HIPAA compliance matters in healthcare

HIPAA exists to protect sensitive health information. That matters for both individuals and organizations.

Why it matters to patients and members

In the wrong hands, medical information can enable harassment, discrimination, extortion, or other harms. Privacy protections help preserve patient autonomy and civil rights.

Why it matters to your organization

Noncompliance can lead to:

• Financial penalties (sometimes substantial)
• Contract loss (customers and payers may require HIPAA assurances)
• Reputational damage (trust is the product in healthcare)
• Operational disruption (investigations, remediation, incident response cost)

Even when the business impact isn’t existential, HIPAA compliance tends to reduce chaos by forcing clarity: who owns access, how changes are approved, and what evidence proves safeguards are working.

---

Do we need to comply (covered entities vs business associates)?

HIPAA does not apply to every organization. It applies to specific categories—most commonly:

• Covered entities (such as providers, health plans, and clearinghouses)
• Business associates (vendors that handle PHI on behalf of covered entities)

If your organization creates, receives, maintains, or transmits PHI for a covered entity, you may be a business associate and need to comply with HIPAA requirements via contractual obligations (often a Business Associate Agreement, or BAA).

Quick scoping table (common scenarios)

Scenario	Likely HIPAA scope?	Why it matters
You run a medical practice or hospital	Yes	You’re typically a covered entity handling PHI directly
You provide billing / claims support for providers	Often yes	You may process PHI and regulated transactions
You host a patient portal or EHR integration	Often yes	You may store or transmit ePHI; Security Rule controls matter
You build a consumer wellness app with no provider integration	Maybe	Some apps are outside HIPAA unless they connect to covered entities/PHI workflows
You’re a SaaS vendor supporting scheduling/messaging for a clinic	Often yes	Vendor access to PHI can trigger business associate obligations

If you’re unsure, the fastest path is usually to do a brief PHI flow mapping exercise (see next section) and have counsel confirm your classification and contractual obligations.

---

Where to start with HIPAA compliance

HIPAA can feel overwhelming because it’s both legal and operational. The best “first step” isn’t buying tooling—it’s gaining clarity on scope, owners, and evidence.

Step 1: Map PHI flows (the 90-minute exercise)

For each system/workflow, document:

• Where PHI enters (intake forms, integrations, uploads, support channels)
• Where it’s stored (databases, file storage, logs, analytics, backups)
• Who can access it (roles, groups, vendors, support staff)
• How it moves (APIs, exports, email, messaging, third-party tools)
• How it’s deleted/retained (retention policies and technical enforcement)

Output: a simple “PHI inventory” plus an access map you can actually act on.

Step 2: Assign control owners (security, engineering, operations)

HIPAA work stalls when “everyone owns it,” so make ownership explicit:

• Security: risk analysis, policies, monitoring, incident response, vendor risk
• Engineering: access controls, logging, encryption, secure SDLC, change management
• IT/Operations: device management, endpoint security, workforce onboarding/offboarding
• Compliance/Legal: BAAs, training requirements, recordkeeping, privacy processes

Step 3: Build your evidence plan

HIPAA readiness gets easier when you decide up front what you’ll show as evidence. Examples commonly include:

• Risk analysis outputs (and remediation tracking)
• Access control policies and screenshots/config exports
• Audit logs and log review evidence (tickets, alerts, reports)
• Encryption configuration for data at rest and in transit
• Training completion records
• Incident response runbooks and incident records
• Vendor list + BAAs + security reviews for PHI-handling vendors

Step 4: Use an automated platform to keep it continuous

Manual HIPAA audits can become slow and expensive—especially when evidence is scattered across tools and teams.

SecureSlate can help by centralizing HIPAA requirements, assigning owners, and keeping evidence organized so you’re not rebuilding the same “audit packet” every quarter.

---

Streamline HIPAA readiness with SecureSlate

HIPAA compliance work goes smoother when the basics are continuously true: access is controlled, changes are tracked, vendors are reviewed, and evidence is always retrievable.

SecureSlate helps teams:

• Map HIPAA requirements to owners and operational tasks (so work doesn’t disappear in Slack)
• Centralize evidence for common HIPAA control expectations (policies, reviews, logs, training)
• Track vendor risk and PHI-related vendor obligations in one place
• Stay audit-ready with fewer “last-minute” scrambles

Get started for free: Create your SecureSlate account

---

FAQ: HIPAA regulations

Is HIPAA only about not sharing patient information?

No. HIPAA includes privacy requirements, security safeguards, standardized transactions/identifiers in certain contexts, and enforcement mechanisms. Most compliance work is operational: access controls, logging, policies, training, and vendor management.

Does HIPAA apply to software companies?

Often, yes—when the software company is a business associate (or subcontractor) that handles PHI on behalf of a covered entity. The most practical way to decide is to map PHI flows and confirm contracts and roles.

What’s the fastest place to start if we’re behind?

Start with PHI flow mapping, then do a risk analysis and prioritize the controls that reduce the largest exposure quickly: access controls, logging, encryption, vendor BAAs, and incident response readiness.

What’s the difference between PHI and ePHI?

PHI is protected health information in any form. ePHI is PHI in electronic form. Many technical safeguard requirements focus on ePHI because it’s commonly stored, transmitted, and accessed through systems.

---

Disclaimer (legal note)

SecureSlate is not a law firm, and this article does not constitute or contain legal advice or create an attorney-client relationship. When determining your obligations and compliance with respect to HIPAA and related regulations, you should consult a licensed attorney.