HIPAA Compliance Checklist for SaaS Companies

You built a SaaS product. A healthcare company wants to use it. Their procurement team sends you a Business Associate Agreement and asks if you're HIPAA compliant.

This is a common inflection point for SaaS companies—and a dangerous one. The wrong answer ("yes, of course") exposes you to federal enforcement if you're not actually compliant. The other wrong answer ("we're not set up for that yet") loses a deal that might be worth $500K ARR.

The right answer depends on understanding what HIPAA actually requires from a SaaS company, which is different from what it requires from a hospital. This guide breaks down the specific technical, operational, and contractual requirements that apply to SaaS vendors handling protected health information (PHI), with a checklist you can work through today.

---

Does HIPAA Apply to Your SaaS?

HIPAA applies to two categories of entities: Covered Entities (healthcare providers, health plans, healthcare clearinghouses) and Business Associates (vendors that create, receive, maintain, or transmit PHI on behalf of a Covered Entity).

Most SaaS companies fall into the Business Associate category. If your product:

• Stores, processes, or transmits any data that could identify a patient alongside health information
• Provides infrastructure that a healthcare company uses to handle patient data
• Analyzes, aggregates, or reports on health data
• Provides communication tools used in patient care

...you are likely a Business Associate and HIPAA applies.

What constitutes PHI? Protected Health Information is individually identifiable health information. The 18 HIPAA identifiers include names, geographic data smaller than a state, dates (except year), phone numbers, email addresses, Social Security numbers, medical record numbers, health plan beneficiary numbers, IP addresses, and more—when combined with health information.

The "combined with health information" qualifier matters. A user's email address alone is not PHI. A user's email address alongside their diagnosis, prescription, or appointment data is PHI.

When HIPAA does not apply to your SaaS:

• Your product handles no health information (pure project management, billing-only for non-health services, etc.)
• You operate as a Covered Entity directly (unusual for SaaS)
• Your product is used exclusively by individuals managing their own health data with no involvement of a Covered Entity

If you're uncertain, assume it applies and evaluate from there. The cost of incorrectly concluding it doesn't apply vastly exceeds the cost of implementing controls you didn't need.

---

Business Associate Agreement (BAA) Requirements

A BAA is a legally binding contract between a Covered Entity and a Business Associate. It establishes the permitted uses and disclosures of PHI, requires the Business Associate to implement appropriate safeguards, and specifies breach notification obligations.

You cannot legally receive PHI from a healthcare company without a signed BAA in place. Receiving PHI without a BAA is itself a HIPAA violation—for both parties.

What a Valid BAA Must Include

Under 45 CFR §164.504(e), a BAA must:

• Describe permitted and required uses of PHI
• Require the Business Associate to not use or disclose PHI except as permitted by the agreement
• Require appropriate safeguards to prevent unauthorized use or disclosure
• Require reporting of breaches and security incidents
• Require compliance with the HIPAA Security Rule
• Require return or destruction of PHI upon termination
• Authorize termination if the Business Associate violates material terms

Subcontractor BAAs

If your SaaS uses subcontractors who touch PHI—AWS for storage, Datadog for logging, SendGrid for notifications—you need BAAs with each of them as well. Your BAA with the Covered Entity flows through to your entire supply chain.

Cloud provider BAA availability:

Provider	BAA Available	Scope
AWS	Yes	HIPAA-eligible services only
Google Cloud	Yes	Covered services only
Microsoft Azure	Yes	Covered services only
Heroku	No	Cannot be used for PHI
Netlify	No	Cannot be used for PHI
Vercel	Limited	Contact for enterprise BAA

Critical: A BAA with AWS does not make all of AWS HIPAA compliant. It covers only the HIPAA-eligible services (S3, RDS, EC2, Lambda, EKS, and others). PHI must stay within those services. Sending PHI to a non-eligible service—even another AWS service—violates the BAA.

---

Technical Safeguards Checklist

The HIPAA Security Rule (45 CFR §164.312) specifies required and addressable technical safeguards. "Required" means you must implement it. "Addressable" means you must either implement it or document why an equivalent alternative is in place.

Access Control (Required)

• Unique user identification — every user has a unique login; shared accounts prohibited for PHI access
• Emergency access procedure — documented process for accessing PHI during system outages
• Automatic logoff — sessions terminate after a defined period of inactivity (15 minutes is common)
• Encryption and decryption — PHI encrypted at rest and in transit

Audit Controls (Required)

• Activity logs capture all access to PHI (read, write, delete)
• Logs are tamper-evident and stored separately from application data
• Log retention meets minimum requirements (6 years for HIPAA, check state law for longer requirements)
• Log review process exists — someone actually reviews logs periodically

Integrity Controls (Addressable)

• Electronic PHI protected from improper alteration or destruction
• Checksums or equivalent mechanism to detect unauthorized modification
• Backup verification — restored data matches original

Transmission Security (Required)

• TLS 1.2 minimum for all PHI in transit (TLS 1.3 recommended)
• Certificates from trusted CAs, properly configured, no self-signed in production
• No PHI transmitted via unencrypted channels (plain HTTP, unencrypted email, SMS)

Authentication (Addressable)

• Multi-factor authentication for all users accessing PHI
• MFA for administrative access — no exceptions
• Password policy: minimum length 12 characters, complexity requirements, no common passwords

---

Physical Safeguards Checklist

Physical safeguards under 45 CFR §164.310 apply to the physical infrastructure hosting PHI. For SaaS companies on public cloud, most physical controls are inherited from your cloud provider—but you still need to document this.

• Facility access controls documented (cloud provider's data centers, plus any offices with workstations accessing PHI)
• Workstation use policy — defined authorized uses for devices that access PHI
• Workstation security — screen locks, full-disk encryption on all endpoints that access PHI
• Device and media controls — documented disposal process for devices that stored PHI
• Data center compliance documentation — AWS/GCP/Azure HIPAA certifications on file

For cloud-hosted SaaS: your physical safeguard documentation should reference your cloud provider's compliance programs (AWS has the Health Information Trust Alliance (HITRUST) certification, SOC 2 Type II, ISO 27001) and explain how your workstation security policies cover your team's devices.

---

Administrative Safeguards Checklist

Administrative safeguards (45 CFR §164.308) are often where SaaS companies are least prepared. These are the policies, procedures, and training requirements—not the technical controls.

Security Officer (Required)

• Designated Security Officer responsible for developing and implementing security policies
• Security Officer role documented in organizational chart or responsibility matrix

Risk Analysis and Risk Management (Required)

• Current risk analysis completed — identifies all threats and vulnerabilities to PHI confidentiality, integrity, and availability
• Risk management plan exists with documented mitigations
• Risk analysis is reviewed and updated annually and after significant changes

This is the most commonly cited HIPAA violation category. OCR (Office for Civil Rights) enforcement actions almost always cite inadequate or absent risk analysis. A documented risk analysis showing you identified a risk and decided to accept it is far better than no documentation at all.

Workforce Training (Required)

• HIPAA security awareness training completed by all workforce members
• Training documented with completion records
• Training refreshed annually
• New hire training within 30 days of start

Access Management (Required)

• Access authorization policy — who can approve access to PHI systems
• Access provisioning and de-provisioning process — documented, audited
• Access reviews conducted — quarterly minimum for privileged access
• Terminated employee access revoked within 24 hours (same day for involuntary terminations)

Incident Response (Required)

• Security incident response procedure documented
• Breach notification process aligns with HIPAA 60-day notification requirement
• Incidents logged and tracked
• Post-incident review process exists

Business Associate Management (Required)

• Inventory of all Business Associates (your subcontractors who touch PHI)
• BAA in place with every subcontractor handling PHI
• Annual review of subcontractor BAAs
• Process for vetting new subcontractors before onboarding

---

Choosing Cloud Infrastructure for HIPAA

Your cloud provider selection and configuration have significant compliance implications.

AWS HIPAA Architecture Considerations

AWS supports HIPAA workloads when you use HIPAA-eligible services and have an AWS BAA in place (automatically included in most enterprise accounts; verify in the AWS Artifact console).

Key architecture requirements:

Data residency: PHI must remain in regions covered by your BAA. AWS US East and US West regions are standard. If your customers require specific geographic data residency, verify regional BAA coverage.

Encryption: S3 server-side encryption (SSE-S3, SSE-KMS, or SSE-C) required for PHI at rest. AWS KMS is HIPAA-eligible and recommended for key management. RDS encryption at rest enabled at instance creation (cannot be enabled post-creation on existing unencrypted instances).

Logging: CloudTrail must be enabled across all regions and accounts. CloudTrail logs are your audit trail for who accessed what and when. S3 access logging for buckets containing PHI. VPC Flow Logs for network-level audit trail.

Separation: PHI workloads in dedicated AWS accounts or at minimum separate VPCs. Avoid mixing PHI and non-PHI workloads in ways that could cause PHI to flow into non-eligible services (CloudFront with Lambda@Edge, for example, may route PHI through non-eligible services).

GCP and Azure

Both offer HIPAA-eligible configurations. GCP's Cloud Healthcare API is purpose-built for healthcare data. Azure has strong presence in healthcare through existing Microsoft enterprise relationships.

The same principle applies: BAA required, services must be on the eligible list, architecture must prevent PHI from flowing to non-covered services.

---

Common HIPAA Violations in SaaS

Understanding what violations actually look like helps prioritize which controls matter most.

Logging PHI in Application Logs

This is endemic in SaaS engineering. A developer adds a debug log line that includes user data. In a non-PHI context, this is harmless. When that user data is PHI, every log line is potentially a disclosure violation.

Fix: Establish PHI data classification in your codebase. Log sanitization middleware that strips PHI-tagged fields before writing to logs. Regular code review specifically checking for PHI in logging statements.

Sending PHI via Email or Slack

Support tickets that include patient details, engineering discussions that include sample PHI from production data, email threads with health information attached. These represent disclosures to parties without BAAs.

Fix: No production PHI in non-PHI systems. Anonymized or synthetic data for development and testing. Clear policy prohibiting sharing PHI via unapproved channels.

Inadequate Access Controls

Shared service accounts, developers with direct production database access, no MFA on admin consoles. A breach that occurs because of inadequate access controls carries both the breach penalty and the access control violation.

Fix: Least-privilege IAM, just-in-time access for production systems, MFA without exceptions.

Missing or Outdated BAAs

Onboarding a new infrastructure vendor without checking BAA requirements. Signing up for a new logging tool, APM service, or CDN that touches PHI-tagged data streams.

Fix: Procurement checklist includes BAA review for any vendor that may process PHI. Legal or compliance review before onboarding.

No Risk Analysis Documentation

The most commonly cited violation in OCR enforcement actions. Covered Entities and Business Associates that suffer breaches and cannot produce a current risk analysis receive significantly higher penalties.

Fix: Document your risk analysis. Use the HHS Security Risk Assessment Tool (free, available at hhs.gov) or a structured template. Update it annually.

---

Cost of Non-Compliance

HIPAA penalties are tiered by culpability and are adjusted annually.

Violation Category	Per Violation	Annual Cap
Unknowing	$100–$50,000	$25,000
Reasonable cause	$1,000–$50,000	$100,000
Willful neglect, corrected	$10,000–$50,000	$250,000
Willful neglect, not corrected	$50,000	$1.9M

These are federal civil penalties. State attorneys general can impose additional penalties. Criminal referrals for deliberate violations are possible.

Beyond fines: breach notification requirements mandate notifying affected individuals, HHS, and in many cases media outlets for breaches over 500 individuals. The reputational cost of a public breach notification in healthcare often exceeds the direct penalty.

The average cost of a healthcare data breach in 2025 was $9.8M according to IBM's Cost of a Data Breach Report—the highest of any industry for the 15th consecutive year. For a SaaS company handling PHI without adequate controls, a breach can be existential.

---

HIPAA Implementation Roadmap for SaaS

If you're starting from scratch, this sequence minimizes time-to-compliant while managing implementation risk.

Month 1: Foundation

• Designate Security Officer
• Complete risk analysis
• Execute BAA with cloud provider
• Enable CloudTrail, audit logging
• Implement MFA for all PHI system access

Month 2: Controls

• Encrypt all PHI at rest and in transit
• Implement access control and de-provisioning processes
• Complete workforce HIPAA training
• Draft core security policies (access control, incident response, acceptable use)
• Audit and sign BAAs with all subcontractors

Month 3: Operations

• Log review process established
• Incident response procedure tested (tabletop exercise)
• Access reviews completed
• BAA template finalized for customer use
• Documentation package assembled

This is a realistic timeline for a 20–100 person SaaS company starting with existing cloud infrastructure. Companies starting from bare metal or with complex data flows need longer.

For a detailed implementation guide covering each control area with specific AWS/GCP configuration examples, the PlatOps HIPAA Implementation Roadmap covers the full technical and administrative control set with step-by-step configuration guidance.

---

What HIPAA Compliance Actually Enables

For SaaS companies, HIPAA compliance is primarily a revenue enabler, not just a risk reduction exercise.

Healthcare is the largest vertical in the US economy ($4.5T in annual spending) and one of the most underserved by software. Healthcare IT decision-makers will not evaluate a SaaS vendor without a completed BAA and evidence of HIPAA controls. A competitor with HIPAA compliance can close deals you cannot touch.

The compliance investment—typically $40,000–$100,000 for initial implementation at a 50–100 person SaaS company—pays back in the first enterprise healthcare deal that closes.

Book a free compliance assessment to understand your current HIPAA posture, identify the gaps between your existing controls and full compliance, and get a prioritized plan for reaching a position where you can sign BAAs and pursue healthcare customers with confidence.