If you're building software that touches health data in any form — a telehealth platform, a patient portal, a health-tracking SaaS, or even a marketing website for a healthcare provider — HIPAA compliance isn't optional. And in 2026, the rules got stricter.

The 2026 HIPAA Security Rule Final Rule removed the wiggle room that many teams relied on. MFA is now required, not addressable. Encryption at rest and in transit is now required, not addressable. If your compliance posture was built on documented exceptions for either of those, that posture is dead.

I've spent years building HIPAA-compliant web applications, and the single biggest mistake I see teams make is treating compliance as a paperwork exercise. It's not. It's an engineering problem with legal consequences. This checklist is written from that perspective — less legalese, more practical implementation guidance for developers, CTOs, and product leads who need to ship compliant software.

Table of Contents

HIPAA Compliance Checklist 2026: Websites, SaaS & Software

Understanding the Three Core HIPAA Rules

HIPAA organizes compliance obligations into distinct rules. Three of them matter most for software and web teams:

The Privacy Rule

The Privacy Rule governs how Protected Health Information (PHI) can be used and disclosed. PHI is any health-related information tied to an identifiable individual — medical records, lab results, insurance details, appointment dates, even IP addresses if they're collected alongside health data.

Key requirements:

  • A Notice of Privacy Practices must be published and accessible
  • The "minimum necessary" standard applies: only access and share the PHI you actually need
  • Patients have rights to access, amend, and request accounting of disclosures of their PHI
  • Authorizations are required for uses beyond treatment, payment, and healthcare operations

The Security Rule

The Security Rule specifically protects electronic PHI (ePHI). It requires three categories of safeguards: administrative, physical, and technical. For SaaS and web applications, the technical safeguards are where most of your engineering effort goes — access controls, audit logging, encryption, integrity controls, and transmission security.

The Security Rule maps to 45 CFR Part 164, and each safeguard has a specific section: access controls (164.312(a)), audit controls (164.312(b)), integrity controls (164.312(c)), authentication (164.312(d)), and transmission security (164.312(e)).

The Breach Notification Rule

When unsecured PHI is exposed, you must notify affected individuals, HHS, and sometimes the media. The clock starts ticking the moment you discover the breach — not when you finish investigating it. More on the specific timelines below.

There's also an Enforcement Rule that governs how OCR investigates and penalizes violations, but the three rules above are where your compliance program lives.

Who Needs to Comply: Covered Entities vs. Business Associates

This is where a lot of SaaS teams get confused. You don't need to be a hospital to fall under HIPAA.

Covered Entities are health plans, healthcare clearinghouses, and healthcare providers who transmit health information electronically.

Business Associates are vendors that create, receive, maintain, or transmit PHI on behalf of a covered entity. If your SaaS product processes health data for a healthcare client, you're a business associate. Period.

Since the HIPAA Omnibus Rule, business associates carry direct compliance obligations. You can't hide behind your client's compliance program. You need your own.

This means:

  • You must sign a Business Associate Agreement (BAA) with every covered entity you serve
  • You must sign BAAs with your own sub-processors (AWS, GCP, your database provider, your email service)
  • You must implement the Security Rule safeguards independently
  • You're subject to OCR enforcement directly

The 2026 Security Rule Final Rule: What Changed

The original Security Rule (2003) divided implementation specifications into "required" and "addressable." Required meant you had to do it. Addressable meant you had to implement it, document why an equivalent measure was used, or document why it wasn't reasonable. In practice, many organizations treated "addressable" as "optional."

The 2026 Final Rule eliminates that ambiguity in two critical areas:

Control Previous Status 2026 Status Impact
Multi-Factor Authentication Addressable Required All systems accessing ePHI must enforce MFA. No exceptions.
Encryption at Rest Addressable Required All ePHI storage must be encrypted. Compensating controls no longer accepted.
Encryption in Transit Addressable Required All ePHI transmission must be encrypted. TLS 1.2 minimum.
Risk Analysis Required Required (expanded) Must be continuous, not annual. Automated monitoring expected.
Audit Logging Required Required (expanded) Logs must be immutable and retained per documented policy.

If you've been relying on documented exceptions for MFA or encryption, you need to remediate immediately. That posture is no longer defensible under the updated rule.

HIPAA Compliance Checklist 2026: Websites, SaaS & Software - architecture

Privacy Rule Checklist for Websites and SaaS

Here's where websites specifically trip up. Your marketing site for a healthcare product has Privacy Rule obligations that most web teams don't think about.

  • Publish a Notice of Privacy Practices (NPP) — Must be prominently accessible on your website. Not buried in a footer link maze.
  • Implement the minimum necessary standard — Your forms should only collect the PHI you actually need. That 15-field intake form? Audit every field.
  • Honor patient access requests — If your software stores PHI, you must provide patients a way to access their records within 30 days.
  • Implement authorization workflows — Any use of PHI beyond treatment/payment/operations requires explicit patient authorization.
  • Track disclosures — Maintain an accounting of every PHI disclosure for at least six years.
  • Train your workforce — Everyone who touches PHI needs Privacy Rule training. Document it.
  • Designate a Privacy Officer — Someone has to own this. It can be a shared role, but it must be documented.
  • Review third-party tracking — This is the big one for websites. Google Analytics, Meta Pixel, HubSpot tracking — if these tools can capture PHI (and they often can), you have a Privacy Rule problem.

Security Rule Checklist: Administrative Safeguards

Administrative safeguards are the policies and procedures that govern your security program. They're often the least exciting part of compliance, but they're what OCR looks at first during an investigation.

  • Conduct a risk analysis — Not a one-time exercise. The 2026 rule expects continuous risk assessment. Map every system that touches ePHI, identify threats, assess vulnerabilities, and document your risk level.
  • Implement a risk management plan — For every risk identified, document how you're mitigating it. Accepted risks must be formally documented with rationale.
  • Assign a Security Officer — Someone owns the security program. Document who.
  • Implement workforce access controls — Role-based access policies. Who can access what ePHI and why.
  • Conduct security awareness training — Annual minimum, but quarterly is better. Document attendance.
  • Implement sanctions policy — What happens when someone violates policy? Document it.
  • Review information system activity — Regular review of audit logs. Not just collecting them — actually reviewing them.
  • Develop a contingency plan — Data backup, disaster recovery, emergency operations. Test it at least annually.
  • Evaluate BAAs — Review all business associate agreements. Every vendor touching ePHI needs one.

Security Rule Checklist: Physical Safeguards

For SaaS teams running on cloud infrastructure, physical safeguards mostly shift to your cloud provider — but you still have obligations.

  • Facility access controls — If you have offices where ePHI is accessible, control physical access. Badge readers, visitor logs, locked server rooms.
  • Workstation security — Laptops used by developers who access production ePHI must have full-disk encryption, screen lock policies, and remote wipe capability.
  • Device and media controls — Policies for disposal of hardware that stored ePHI. Document destruction methods.
  • Cloud provider validation — Verify your cloud provider's physical security certifications. AWS, GCP, and Azure all publish SOC 2 reports covering physical controls — request and review them.

Security Rule Checklist: Technical Safeguards

This is where engineering teams spend most of their effort. Each safeguard maps to a testable control.

Access Controls (164.312(a))

  • Unique user identification — Every user gets a unique ID. No shared accounts. Ever.
  • Emergency access procedure — Documented process for accessing ePHI during emergencies.
  • Automatic logoff — Session timeouts on all systems accessing ePHI. 15 minutes is a reasonable default.
  • Encryption and decryption — ePHI must be encrypted at rest. AES-256 is the standard.
# Example: Verifying encryption at rest on AWS RDS
import boto3

def check_rds_encryption():
    rds = boto3.client('rds')
    instances = rds.describe_db_instances()
    for db in instances['DBInstances']:
        if not db['StorageEncrypted']:
            print(f"WARNING: {db['DBInstanceIdentifier']} is NOT encrypted")
            # This is now a compliance violation under 2026 rules
        else:
            print(f"OK: {db['DBInstanceIdentifier']} encrypted with {db['KmsKeyId']}")

Audit Controls (164.312(b))

  • Log all ePHI access — Every read, write, update, and delete.
  • Make logs immutable — Use append-only storage. CloudWatch Logs with retention policies, or ship to an immutable SIEM.
  • Retain logs per policy — Six years is the safe default to match HIPAA's general retention requirement.
  • Automate log review — Set up alerts for anomalous access patterns. A developer querying 10,000 patient records at 3 AM should trigger an alert.
// Example: Express middleware for ePHI access logging
const logPhiAccess = (req, res, next) => {
  const logEntry = {
    timestamp: new Date().toISOString(),
    userId: req.user?.id,
    action: req.method,
    resource: req.originalUrl,
    sourceIp: req.ip,
    userAgent: req.get('User-Agent'),
    // Don't log the actual PHI in the audit log
    resourceType: 'ePHI',
  };
  
  // Ship to immutable log store
  auditLogger.write(logEntry);
  next();
};

app.use('/api/patients/*', logPhiAccess);

Integrity Controls (164.312(c))

  • Implement mechanisms to verify ePHI hasn't been altered — Checksums, digital signatures, or database-level integrity controls.
  • Protect against unauthorized modification — Write-access should be tightly scoped.

Authentication (164.312(d))

  • Verify identity of anyone accessing ePHI — Strong authentication required.
  • Implement MFA — Now mandatory under the 2026 rule. TOTP, hardware keys, or push-based MFA. SMS-based MFA is technically compliant but not recommended due to SIM-swapping risks.

Transmission Security (164.312(e))

  • Encrypt ePHI in transit — TLS 1.2 minimum. TLS 1.3 preferred.
  • Enforce HTTPS everywhere — No mixed content. HSTS headers required.
  • Secure API communications — All API calls transmitting ePHI must use encrypted channels. Mutual TLS for service-to-service communication is a strong pattern.
# Nginx configuration enforcing TLS 1.2+ and HSTS
server {
    listen 443 ssl http2;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5:!RC4;
    ssl_prefer_server_ciphers on;
    
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
    add_header X-Content-Type-Options nosniff always;
    add_header X-Frame-Options DENY always;
}

Breach Notification Rule Checklist

A breach is any unpermitted use or disclosure that compromises the security or privacy of PHI. Here's what you need in place before one happens — because if you're building it during an incident, you're already behind.

  • Define your incident response plan — Who does what when a breach is discovered? Document roles, escalation paths, and communication templates.
  • Establish a 60-day notification window — Affected individuals must be notified within 60 days of breach discovery. Not 60 days from when it happened — 60 days from when you knew about it.
  • Notify HHS — If 500+ individuals are affected, notify HHS simultaneously with individual notifications. For breaches affecting fewer than 500 individuals, you can report annually (but don't delay investigation).
  • Notify media — Breaches affecting 500+ individuals in a single state or jurisdiction require media notification.
  • Document the risk assessment — For every potential breach, perform a four-factor risk assessment: nature and extent of PHI involved, unauthorized person who accessed it, whether PHI was actually acquired or viewed, extent of risk mitigation.
  • Know the encryption safe harbor — If breached data was encrypted with NIST-standard encryption and the key wasn't compromised, it may not constitute a breach requiring notification. This is one of the strongest arguments for encryption everywhere.
  • Conduct tabletop exercises — Run breach simulations at least annually. Time your team's response. Identify gaps.

Website-Specific HIPAA Concerns Most Teams Miss

This is the section I wish someone had written for me five years ago. Websites have HIPAA exposure points that backend engineers don't always think about.

Third-Party Tracking and Analytics

In December 2022, HHS issued guidance clarifying that tracking technologies on healthcare websites can create HIPAA violations. This hasn't changed — it's gotten stricter. If your healthcare website uses Google Analytics, Meta Pixel, or similar tools, and those tools can capture PHI (including IP addresses combined with health-related page visits), you may be transmitting PHI to third parties without a BAA.

What to do:

  • Audit every third-party script running on your site
  • Remove tracking pixels from pages that collect or display health information
  • Use server-side analytics where possible
  • If you must use client-side analytics, ensure they're configured to exclude PHI
  • Consider privacy-focused alternatives like Plausible or Fathom that don't collect PII

Client-Side JavaScript and Supply Chain Risk

Every npm package, every CDN-hosted script, every chat widget is a potential vector for ePHI exposure. A compromised third-party script can exfiltrate form data — including PHI — to an attacker's server.

  • Implement Content Security Policy (CSP) headers
  • Use Subresource Integrity (SRI) for CDN-hosted assets
  • Audit your client-side dependencies regularly
  • Monitor your Software Bill of Materials (SBOM)

Form Handling

Contact forms, appointment request forms, symptom checkers — if they collect health information, they're handling PHI.

  • Encrypt form submissions in transit (HTTPS)
  • Don't store form data in plaintext
  • Don't email form contents unencrypted
  • Implement CAPTCHA to prevent automated PHI extraction
  • Set appropriate data retention policies — don't keep form submissions forever

If you're working with a headless CMS architecture, make sure your form handling pipeline is HIPAA-compliant end to end. At Social Animal, we build headless CMS solutions with these security requirements baked in from the start, not bolted on afterward.

HIPAA Compliance Comparison: Cloud Providers

Your infrastructure choice matters. Here's how the major cloud providers stack up for HIPAA workloads in 2026:

Feature AWS Google Cloud Azure Vercel Netlify
Offers BAA Yes Yes Yes Yes (Enterprise) No
HIPAA-eligible services documented 150+ 100+ 130+ Limited N/A
Default encryption at rest Yes (most services) Yes Yes Partial N/A
HITRUST CSF certified Yes Yes Yes No No
Dedicated compliance documentation Extensive Extensive Extensive Minimal N/A
FedRAMP authorized Yes (GovCloud) Yes Yes (Gov) No No

A critical note on static hosting platforms: If you're deploying a Next.js or Astro site that handles ePHI, be very careful about your hosting choice. Vercel will sign a BAA on enterprise plans, but you need to verify which specific services are covered. Netlify does not currently offer a BAA, making it unsuitable for HIPAA workloads.

For teams building with frameworks like Next.js or Astro, the architecture decisions you make early on — where data is processed, which APIs handle PHI, how server-side rendering interacts with client-side state — all have HIPAA implications.

Documentation and Audit Readiness

HIPAA requires you to retain documentation for six years. That includes policies, procedures, risk assessments, training records, BAAs, and incident reports. Here's how to stay audit-ready without losing your mind:

  • Automate evidence collection — Use tools like Vanta, Drata, or Secureframe to continuously collect compliance evidence. Manual spreadsheets don't scale.
  • Version control your policies — Store compliance documents in Git. Every change is tracked with author, timestamp, and context.
  • Automate security scanning — Run infrastructure-as-code scanners (Checkov, tfsec) in your CI/CD pipeline to catch misconfigurations before they reach production.
  • Schedule quarterly access reviews — Who has access to what? Is it still appropriate? Document the review.
  • Maintain a living risk register — Your risk assessment isn't a PDF you update annually. It's a living document that changes as your infrastructure evolves.
# Example: GitHub Actions step for HIPAA security scanning
- name: Run Checkov security scan
  uses: bridgecrewio/checkov-action@v12
  with:
    directory: ./terraform
    framework: terraform
    check: CKV_AWS_17,CKV_AWS_19,CKV_AWS_145  # RDS encryption, S3 encryption, etc.
    soft_fail: false  # Fail the pipeline on violations

No official government HIPAA certification exists. HHS and OCR don't issue certifications. If someone tells you they're "HIPAA certified," ask what they actually mean. Third-party frameworks like HITRUST CSF and SOC 2 Type II can demonstrate compliance maturity to customers, but they don't replace OCR oversight or provide safe harbor.

Penalty Tiers: What's at Stake

Let's be concrete about the consequences:

Tier Knowledge Level Penalty Per Violation Annual Maximum
Tier 1 Did not know (and couldn't have) $137 – $68,928 $2,067,813
Tier 2 Reasonable cause, not willful neglect $1,379 – $68,928 $2,067,813
Tier 3 Willful neglect, corrected within 30 days $13,785 – $68,928 $2,067,813
Tier 4 Willful neglect, not corrected $68,928 $2,067,813

Penalty amounts adjusted for inflation as of 2026. Criminal penalties can include up to 10 years imprisonment for offenses committed with intent to sell PHI.

These aren't theoretical. OCR has been increasingly active in enforcement. The average cost of a healthcare data breach in 2025 was $10.93 million according to IBM's Cost of a Data Breach Report. Compliance is cheaper than the alternative.

FAQ

Does my SaaS product need to be HIPAA compliant if we don't store health data directly?

If your software creates, receives, maintains, or transmits PHI on behalf of a covered entity, you're a business associate and must comply. Even passing through ePHI without storing it triggers compliance requirements. The key question is whether PHI touches your systems at any point.

Is there an official HIPAA certification I can get?

No. HHS and OCR do not issue or endorse any HIPAA certification. Third-party frameworks like HITRUST CSF, SOC 2 Type II, or ISO 27001 can demonstrate your security posture to customers and partners, but they don't constitute HIPAA certification. Be skeptical of any vendor claiming to be "HIPAA certified."

What's the difference between required and addressable specifications in 2026?

The 2026 Security Rule Final Rule made MFA and encryption explicitly required, removing their previous "addressable" status. For remaining addressable specifications, you must either implement the specification, implement an equivalent alternative and document why, or document why it's not reasonable and appropriate. "Addressable" has never meant "optional" — the 2026 update just made that undeniable for the two controls that matter most.

Do I need a BAA with my cloud hosting provider?

Yes. If your cloud provider processes, stores, or transmits ePHI on your behalf, you need a BAA. AWS, Google Cloud, and Azure all offer BAAs. Make sure you're only using services that are explicitly listed as HIPAA-eligible by your provider — not all services within a cloud platform are covered.

Can I use Google Analytics on a healthcare website?

It's risky. HHS guidance from 2022 (and reinforced since) makes clear that tracking technologies that can combine IP addresses with health-related page visits may constitute PHI transmission to a third party without a BAA. Google does not sign a BAA for Google Analytics. Server-side analytics or privacy-focused alternatives are safer choices for healthcare websites.

How often do I need to perform a HIPAA risk analysis?

The 2026 rule emphasizes continuous risk assessment rather than a periodic exercise. At minimum, conduct a formal risk analysis annually and whenever there's a significant change to your systems, environment, or operations. Many organizations are moving toward automated, continuous risk monitoring using compliance platforms.

What counts as a breach under HIPAA?

A breach is any unpermitted use or disclosure of PHI that compromises its security or privacy. However, there are three exceptions: unintentional acquisition by a workforce member acting in good faith, inadvertent disclosure between authorized persons within the organization, and situations where you have a good faith belief the unauthorized recipient couldn't retain the information. Encrypted data that's breached may qualify for safe harbor if the encryption meets NIST standards and the key wasn't compromised.

What should I do in the first 24 hours after discovering a potential breach?

Activate your incident response plan. Contain the breach — isolate affected systems if needed. Begin documenting everything: what happened, when it was discovered, who was involved, what data was affected. Start the four-factor risk assessment. Notify your legal counsel and your HIPAA Privacy and Security Officers. Do not wait to investigate fully before taking containment actions. The 60-day notification clock starts at discovery, so every hour counts.

If you're building healthcare software and need help getting the architecture right from day one, we work with engineering teams to design HIPAA-compliant web applications. Check out our development capabilities or reach out to discuss your project.