HIPAA Compliance for Healthcare SaaS: A Practical Checklist

Most healthcare SaaS companies discover their HIPAA gaps during a customer security review, a vendor assessment, or — worst case — a breach investigation. Whether you're working with HIPAA compliance advisory services or building the program in-house, the starting point is the same: which safeguards are actually required, and what does "implemented" look like to an OCR investigator rather than your internal team. This checklist won't substitute for legal counsel, but it gives your technical and compliance teams a concrete picture of where the gaps usually are.

Who HIPAA Actually Applies To

The most common misconception: HIPAA only applies to hospitals and insurance companies. In practice, it extends to any business associate (BA) that creates, receives, maintains, or transmits protected health information (PHI) on behalf of a covered entity. If your SaaS platform processes, stores, or transmits any data that could identify a patient and is connected to healthcare delivery or payment, you are almost certainly a business associate.

Signing a Business Associate Agreement (BAA) with your covered entity customers is required — but it does not make you compliant. A BAA establishes the legal relationship. The Security Rule controls what you're actually obligated to do.

Administrative Safeguards Checklist

Administrative safeguards are the operational backbone of HIPAA — the policies, procedures, and training requirements that govern how your people handle PHI. The Security Management Process section alone trips up most organizations, because it requires a formal, documented risk analysis that most companies either haven't done or haven't updated since the company was half its current size.

Security Management Process (Required)
- Conduct and document a formal risk analysis identifying threats and vulnerabilities to PHI
- Implement a risk management plan that reduces identified risks to a reasonable level
- Apply appropriate sanctions to workforce members who violate policies
- Implement a process to regularly review information system activity logs

Assigned Security Responsibility (Required)
- Designate a security official responsible for developing and implementing HIPAA security policies — this has to be a named person, not a team or a title

Workforce Security
- Implement authorization procedures for workforce access to PHI systems
- Establish a workforce clearance process
- Define termination procedures that revoke access promptly when someone leaves

Access Management
- Implement formal procedures for granting and reviewing access authorization
- Establish a process for managing access changes (role changes, transfers)

Security Awareness and Training
- Train all workforce members on security policies — at hire and at least annually
- Include specific training on malicious software detection and reporting
- Document that training occurred, including content and attendees

Security Incident Procedures (Required)
- Define what constitutes a security incident involving PHI
- Implement procedures to identify, respond to, mitigate, and document incidents
- Maintain incident records — regulators will ask for them, and "we handled it" is not documentation

Contingency Plan (Required)
- Maintain a data backup plan for PHI
- Implement a disaster recovery plan
- Establish an emergency mode operation plan
- Test and revise procedures periodically — "we have a plan" and "the plan works" are different things

Technical Safeguards Checklist

Technical safeguards are the controls that protect PHI at the system level — access, logging, integrity, and transmission. For cloud-based SaaS companies, most of these map directly to configurations you already manage; the gap is usually documentation and evidence, not the underlying technology.

Access Controls (Required)
- Assign unique user IDs to every person who accesses PHI systems — no shared accounts, no exceptions
- Implement emergency access procedures for when normal authentication is unavailable
- Implement automatic logoff from systems containing PHI after a period of inactivity
- Encrypt and decrypt PHI where appropriate (technically addressable, but not optional in practice — any auditor or OCR investigator will expect encryption)

Audit Controls (Required)
- Implement hardware, software, or procedural mechanisms to record and examine activity in systems containing PHI
- Log who accessed PHI, when, and what actions were taken
- Review logs regularly and retain them per your policy

Integrity Controls
- Implement mechanisms to verify that PHI has not been altered or destroyed in an unauthorized way
- In practice: checksums, hashing, or integrity monitoring for stored PHI

Transmission Security
- Implement technical controls to prevent unauthorized access to PHI transmitted over electronic networks
- In practice: TLS 1.2 or higher for all PHI in transit, no exceptions

Physical Safeguards Checklist

Physical safeguards govern access to the systems and devices that contain PHI. For cloud-based SaaS, many of these controls are inherited from your cloud provider — but you still need to document that inheritance explicitly and understand what your BAA with AWS, Azure, or GCP actually covers.

Facility Access Controls
- Implement policies to limit physical access to electronic information systems and the facilities where they're housed
- Maintain records of facility access, repairs, modifications, and access log reviews

Workstation Use and Security
- Specify proper use of workstations that access PHI (physical location, screen positioning, locking policy)
- Implement physical safeguards for those workstations — screen locks and clean desk policies cover this in most cases

Device and Media Controls
- Implement policies for disposal of hardware and media that contain PHI — secure wipe or physical destruction
- Implement procedures for removing PHI from equipment before reuse or disposal
- Maintain records of media movement if PHI is involved

Two Mistakes Healthcare SaaS Companies Make

Treating the BAA as the compliance control. A BAA is a contract, not a security program. Signing one obligates you to be compliant — it does not make you compliant. The HIPAA enforcement actions that have resulted in seven-figure settlements almost always involved organizations that had signed BAAs but hadn't implemented the underlying requirements. OCR doesn't care that you had paperwork.

Implementing the Security Rule but ignoring the Breach Notification Rule. HIPAA has three rules that apply to business associates: the Privacy Rule, the Security Rule, and the Breach Notification Rule. Most organizations focus on the Security Rule and stop there. The Breach Notification Rule requires you to notify covered entities of breaches within 60 days of discovery — and it defines "breach" more broadly than most teams expect. If you don't have a documented process for breach detection, assessment, and notification, you are not fully compliant, regardless of how solid your technical controls are.

What "Actually Implemented" Looks Like

The gap between "we have a policy" and "we are compliant" is evidence. During an audit or OCR investigation, you'll be asked to demonstrate that controls exist and operate as described. That means training records, access review logs, risk analysis documents with dates and signatures, incident tickets, and backup test results.

If you're a healthcare SaaS company that has grown quickly, the most common state is: some controls implemented, some documented, few with supporting evidence, and a risk analysis that hasn't been updated since the company was half the size and the system was much simpler. That's the starting point for most HIPAA readiness engagements — not a failure state, just a gap state.

A properly scoped engagement can close most of those gaps in three to four months. Waiting until a customer asks for a HIPAA attestation before starting is how companies end up in trouble.

For the financial context behind security investment decisions, see The Real Cost of a Data Breach for Mid-Market Companies. Many healthcare SaaS companies also pursue SOC 2 in parallel — The 12-Point SOC 2 Pre-Audit Checklist covers what needs to be in place before engaging an auditor.