HIPAA Compliance Checklist for Healthcare SaaS (2025)

Who HIPAA Covers: Covered Entities and Business Associates

HIPAA creates two categories of regulated entity. Covered Entities are the traditional healthcare actors: healthcare providers who transmit health information electronically (hospitals, physician practices, pharmacies, clinical labs), health plans (commercial insurers, HMOs, Medicare/Medicaid), and healthcare clearinghouses. Covered Entities bear direct HIPAA obligations and are the primary enforcement targets.

Business Associates are every vendor, contractor, and technology provider that creates, receives, maintains, or transmits Protected Health Information (PHI) on behalf of a covered entity. HITECH 2009 extended direct HIPAA liability to Business Associates — so a BA can be directly penalized by HHS OCR even without a covered entity complaint. This is where most health-tech companies sit.

A Business Associate relationship exists whenever PHI flows to a third party to perform a function for the covered entity. This includes: EHR software vendors, cloud storage providers storing patient records, analytics platforms processing patient outcomes, billing and revenue cycle platforms, telehealth infrastructure providers, clinical decision support tools, healthcare AI companies, and patient engagement platforms. Importantly, subcontractors of Business Associates (sub-BAs) also carry direct HIPAA liability under HITECH.

The Three HIPAA Rules: What Each Requires

1. The Privacy Rule (effective April 2003)

The Privacy Rule defines Protected Health Information as individually identifiable health information in any form — paper, electronic, or oral — that relates to past, present, or future physical or mental health; the provision of healthcare; or payment for healthcare. It specifies 18 categories of PHI identifiers (name, address, dates, phone, email, SSN, medical record numbers, biometrics, and more) that make health data "identified."

The Privacy Rule's core obligations: the minimum necessary standard (use or disclose only the minimum PHI needed for the stated purpose); patient rights (access to their records within 30 days, right to an accounting of disclosures, right to request amendments); and designated Privacy Official (a specific person responsible for developing and implementing privacy policies).

For Business Associates: the Privacy Rule governs what you can do with PHI. Permitted uses and disclosures are defined in your BAA. You cannot use PHI for any purpose not expressly permitted by the BAA or required by law — including using de-identified patient data to train AI models without explicit authorization.

2. The Security Rule (effective April 2005)

The Security Rule applies specifically to electronic PHI (ePHI) and requires Administrative, Physical, and Technical safeguards. Unlike the Privacy Rule (which governs all PHI), the Security Rule covers only ePHI — any PHI created, received, maintained, or transmitted in electronic form.

3. The Breach Notification Rule (effective February 2010)

A breach is the acquisition, access, use, or disclosure of unsecured PHI not permitted by the Privacy Rule, unless the covered entity or BA can demonstrate a low probability of compromise through a 4-factor risk assessment: (1) nature and extent of the PHI involved; (2) who impermissibly used or accessed the PHI; (3) whether PHI was actually acquired or viewed; (4) extent to which risk has been mitigated.

Critically: encrypted PHI is not reportable. If data is encrypted using NIST-approved encryption (AES-128/256 for data at rest; TLS 1.2+ for data in transit) and the decryption key was not compromised, a breach involving that data does not trigger notification requirements. This makes encryption implementation an existential priority for HIPAA compliance — not just a best practice.

Business Associate Agreements: The HIPAA Checklist Every Vendor Needs

The BAA is not optional. Every covered entity must have a signed BAA in place before sharing PHI with a Business Associate. As a BA, you cannot accept or process PHI from a covered entity without executing a BAA first — doing so is itself a HIPAA violation.

A legally compliant BAA must include:

• Description of permitted uses and disclosures of PHI — must be specific, not catch-all
• Requirement for BA to implement appropriate safeguards to protect the PHI
• Requirement for BA to report security incidents (including successful or unsuccessful unauthorized accesses) to the covered entity
• Requirement for BA to report breaches under the Breach Notification Rule within 60 days of discovery
• Requirement for BA to ensure subcontractors also sign BAAs before receiving PHI
• Right for covered entity to terminate the BAA if BA violates a material term
• Requirement for BA to return or destroy all PHI at contract termination (or justify why retention is necessary)
• Compliance with the Privacy Rule's minimum necessary standard when using or disclosing PHI

Common BAA mistake: using template BAA language that permits "any use necessary to perform the services." OCR has found such broad language to be non-compliant. Permitted uses must be specific to the functions the BA performs. Have your BAAs reviewed before signing — a deficient BAA is a liability for both parties.

HIPAA Technical Safeguards: The Implementation Checklist

The following controls are the most commonly cited deficiencies in HHS OCR audits of SaaS companies and cloud providers:

• Unique user IDs: No shared accounts for ePHI systems. Every employee or system accessing ePHI must have a unique, individual account. Required (not addressable).
• Automatic logoff: Sessions must automatically terminate after a defined period of inactivity. Typical thresholds: 15 minutes for clinical workstations, 30 minutes for administrative systems. Addressable — implement or document why alternative is equivalent.
• Encryption of ePHI in transit: TLS 1.2 minimum; TLS 1.3 recommended. All API endpoints handling PHI must enforce encrypted transport. Non-encrypted transmission of PHI is a breach trigger. Required via Safe Harbor logic.
• Encryption of ePHI at rest: AES-128 or AES-256 for databases, file storage, and backups containing PHI. Addressable — but failure to encrypt is the single largest predictor of breach penalty magnitude.
• Audit logs: Maintain logs of all ePHI access, modification, and deletion. Logs must be retained for a minimum of 6 years (HIPAA documentation retention standard). Logs must be tamper-evident and protected from unauthorized modification. Required.
• Integrity controls: Mechanisms to detect unauthorized alteration or destruction of ePHI. Addressable. In practice: checksums, hash verification, database audit trails.
• Access control: Role-based access based on minimum necessary principle. No broader access than required to perform the BA function. Required.
• Contingency plan: Data backup procedures; disaster recovery plan; emergency mode operation plan; testing and revision procedures. Required. AWS/Azure/GCP shared responsibility means you still own the application-layer backup.

The 2024 HIPAA Safe Harbor: How Cybersecurity Frameworks Reduce Penalties

The HITECH Act Safe Harbor provision (42 U.S.C. § 17931, effective January 2021, clarified by HHS 2024 guidance) requires HHS to consider recognized security practices in penalty calculations and investigation decisions for covered entities and BAs that have implemented a recognized cybersecurity framework in the 12 months preceding a breach.

Recognized frameworks under the Safe Harbor: NIST Cybersecurity Framework (CSF) 2.0, NIST SP 800-66 Rev. 2 (HIPAA-specific implementation guide), CIS Controls v8, ISO/IEC 27001:2022, and HITRUST CSF. The framework must be actively implemented — not just documented. HHS looks at: policies and procedures implementing the framework; evidence of training and workforce awareness; audit logs demonstrating operational controls; and documentation of the framework implementation start date (must predate the breach by 12+ months).

Practical implication: if your company already has SOC 2 Type II or ISO 27001, the overlapping controls directly support HIPAA Safe Harbor. Document the correspondence explicitly (NIST CSF controls → HIPAA Technical Safeguards → SOC 2 CC6) so that in any OCR investigation, you can immediately demonstrate Safe Harbor eligibility.

HIPAA Risk Analysis: The Foundation of Every Compliance Programme

The Security Rule requires an accurate and thorough risk analysis as the cornerstone of any HIPAA security programme. OCR consistently identifies missing or inadequate risk analysis as the #1 violation in investigations — it's the compliance failure that transforms an incident into a multimillion-dollar settlement.

A HIPAA-compliant risk analysis must:

• Identify all ePHI your organization creates, receives, maintains, or transmits — including in cloud storage, backups, test environments, and third-party integrations
• Identify and document all reasonably anticipated threats to ePHI
• Assess the likelihood and impact of each threat (typically on a qualitative or semi-quantitative scale)
• Evaluate current controls and their adequacy to address each threat
• Document the risk analysis process and findings
• Implement security measures to reduce identified risks to a reasonable and appropriate level
• Review and update the analysis in response to environmental or operational changes, and at a minimum annually

The risk analysis must be documented — an undocumented mental exercise is not compliant. HHS provides a Security Risk Assessment (SRA) Tool at healthit.gov/topic/privacy-security-and-hipaa/security-risk-assessment-tool that guides smaller organizations through the process.

HIPAA Penalties: The Four-Tier Structure

Civil monetary penalties are assessed per violation category per calendar year. OCR may impose penalties for multiple violation categories simultaneously. The 2024 Safe Harbor can reduce penalties across all tiers. Criminal referrals to DOJ for knowing violations can result in fines up to $250,000 and up to 10 years imprisonment.

Frequently Asked Questions