The HIPAA Security Rule: Safeguards & Evidence Checklist for SaaS Vendors

The HIPAA Security Rule, translated from legalese into the exact controls you build and the exact evidence a customer’s security team will ask you to show. A working checklist for SaaS vendors.

Most HIPAA content stops at “implement appropriate safeguards” and leaves you to guess what that means in code and process. This guide doesn’t. It walks the entire HIPAA Security Rule the way a SaaS vendor actually experiences it — as a list of controls to design and, just as importantly, evidence to produce on demand.

If you’re new to HIPAA, start with the overview: The Complete HIPAA Compliance Guide for Canadian Healthtech. If you already know you’re a Business Associate and now have to prove it, you’re in the right place.

What the Security Rule Really Asks For

The HIPAA Security Rule sets national standards for protecting electronic Protected Health Information (ePHI). It’s built on three safeguard families — administrative, physical, and technical — and one governing idea: you must be able to demonstrate, with documentation, that each safeguard is in place and working.

In practice, “compliant” and “can prove it” are the same thing. An unlogged control might as well not exist when OCR or a customer comes asking.

Required vs. Addressable — the concept everyone trips on. Every specification is flagged Required or Addressable. Required means implement it, no debate. Addressable means assess it and either implement it, or document why a reasonable alternative achieves the same objective. Addressable is not “skip it.” Surprisingly, encryption is technically addressable — but skipping it is nearly impossible to defend, and unencrypted PHI is what turns an incident into a reportable breach. Treat encryption as required in all but name.

Start Here: The Risk Analysis

Before a single control, the Security Rule demands a risk analysis — a documented assessment of the threats and vulnerabilities to your ePHI. It’s the most-cited failure in OCR enforcement actions, and it’s the document every serious customer asks to see first. Everything downstream (which safeguards, how urgently) flows from it.

Data inventory — where ePHI is created, received, stored, and transmitted
Threat & vulnerability assessment — what could go wrong, and how likely
Risk ranking — impact × likelihood, so remediation is prioritized
Risk-management plan — what you’ll fix, who owns it, by when
A review cadence — the analysis is refreshed, not filed and forgotten

Administrative Safeguards §164.308

The policies and processes — more than half the rule. Here’s the control design on the left, and the evidence you’ll be asked for on the right.

🛠 One Control Design

Named Security Official
Role-based access + joiner/mover/leaver process
Annual security & phishing training
Tested incident-response plan
Backups + disaster-recovery plan

📂 Evidence You Collect

Risk analysis + remediation tracker
Access reviews & off-boarding tickets
Training completion records
Incident tickets + tabletop notes
Backup logs + restore-test results

Risk analysis and risk-management plan, dated and current
Sanction policy for staff who violate security policy
Information-system activity review (log review) records
Workforce access authorizations and quarterly access reviews
Signed subcontractor BAAs for every vendor touching PHI

Physical Safeguards §164.310

For a cloud-native SaaS, most facility controls are inherited from your hosting provider — but “inherited” still means you keep the proof on file and secure the endpoints you do control.

🛠 One Control Design

Cloud provider handles data-center access
MDM on every company device
Full-disk encryption + auto screen-lock
Secure device disposal / crypto-erase

📂 Evidence You Collect

Cloud provider compliance reports on file
MDM enrollment & encryption status export
Asset inventory
Media-disposal / wipe records

Workstation-use and workstation-security policies
Device and media controls — disposal and re-use procedures (both Required)
Hosting provider’s third-party attestation (e.g. SOC 2 / ISO 27001) retained
Encryption status for all laptops that can reach ePHI

Technical Safeguards §164.312

The controls in your product and infrastructure. This is where an engineering team can move fastest.

🛠 One Control Design

SSO + MFA, unique IDs per user
Automatic session logoff
Encryption at rest and in transit (TLS 1.2+)
Centralized, tamper-resistant audit logging

📂 Evidence You Collect

MFA enforcement records + user/role lists
Session-timeout configuration
Encryption configuration exports
Log-retention config + sample access logs

Unique user identification (Required) and emergency-access procedure (Required)
Audit controls that record access to ePHI (Required)
Person/entity authentication — MFA everywhere (Required)
Integrity controls to detect improper alteration of ePHI
Transmission encryption — no PHI in URLs, encrypted APIs and email

The Required/Addressable Matrix at a Glance

Bookmark this. It’s the whole Security Rule compressed to the specs vendors most often get wrong, with the flag that decides how you handle each.

Specification	Family	Flag
Risk analysis & risk management	Administrative	Required
Security incident procedures	Administrative	Required
Data backup & disaster recovery plan	Administrative	Required
Business Associate contracts	Administrative	Required
Security awareness & training	Administrative	Addressable
Disposal & media re-use	Physical	Required
Workstation use & security	Physical	Required
Unique user ID & emergency access	Technical	Required
Audit controls	Technical	Required
Person/entity authentication	Technical	Required
Automatic logoff	Technical	Addressable
Encryption & decryption	Technical	Addressable*

*Addressable on paper. In practice, encrypt ePHI at rest and in transit — it’s the single control that most often keeps an incident from becoming a reportable breach.

The Evidence Buyers Actually Ask For

When a US health system runs its vendor security review, it isn’t grading your intentions. It wants artifacts. Have these ready and most questionnaires answer themselves:

A current, dated risk analysis and remediation plan
Your policies — security, access control, incident response, contingency
MFA enforcement evidence and access-review logs
Encryption configuration for data at rest and in transit
Audit logs and evidence they’re actually reviewed
Backup and restore-test records
Training completion records for all staff
Signed BAAs with every subcontractor

Collect It Once, Use It Everywhere

Here’s the leverage. The evidence the Security Rule demands is nearly identical to what SOC 2 and ISO 27001 auditors want. Map each control once and the same artifact satisfies several frameworks.

HIPAA Security Rule control	Also satisfies
Access control + MFA	SOC 2 CC6.x · ISO 27001 A.5/A.8 · Loi 25
Audit logging & review	SOC 2 CC7.x · ISO 27001 A.8.15
Encryption at rest / in transit	SOC 2 CC6.7 · ISO 27001 A.8.24 · PIPEDA safeguards
Risk analysis	SOC 2 CC3.x · ISO 27001 Clause 6 & A.5
Incident response	SOC 2 CC7.3/7.4 · ISO 27001 A.5.24–.27
Vendor / BAA management	SOC 2 CC9.2 · ISO 27001 A.5.19–.22

Proof it works. Canadian healthtech Medioh built exactly this kind of continuous, evidence-first program and earned certification with Mindsec. Same control library, same evidence engine that a HIPAA program runs on: How Medioh achieved ISO 27001:2022 with Mindsec.

Stop Screenshotting. Start Proving.

A compliance automation platform maps every HIPAA Security Rule specification to a control, collects the evidence continuously, and reuses it across SOC 2 and ISO 27001 — so a vendor security review becomes a link you send, not a fire drill you survive.

Prove it once. Prove it always.

Explore HIPAA Compliance with Mindsec

Frequently Asked Questions

What is the difference between “required” and “addressable” in the HIPAA Security Rule?

Required specifications must be implemented exactly. Addressable specifications must still be assessed and either implemented or replaced with a documented, reasonable alternative that meets the same objective — addressable never means optional. Encryption, for example, is technically addressable, but leaving ePHI unencrypted is very hard to justify and is the difference between a contained incident and a reportable breach.

Why is the risk analysis so important for HIPAA?

The risk analysis is a required foundation of the entire Security Rule and the most frequently cited deficiency in OCR enforcement actions. It identifies where ePHI lives, what threatens it, and which risks to fix first — so every other safeguard decision is justified. Without a current, documented risk analysis, a vendor can’t demonstrate that its safeguards are appropriate, which is why customers ask to see it first.

Does a SaaS vendor need to encrypt ePHI to be HIPAA compliant?

Encryption is listed as “addressable,” not strictly required, but in practice a SaaS vendor should encrypt ePHI both at rest and in transit. Encryption is the safeguard that most often prevents a security incident from becoming a reportable breach under the Breach Notification Rule, and virtually every customer security review expects it. Skipping it requires documenting an equivalent alternative, which is rarely defensible.

What evidence do I need to prove HIPAA Security Rule compliance?

At minimum: a current risk analysis and remediation plan, written security policies, MFA enforcement and access-review logs, encryption configuration for data at rest and in transit, audit logs with proof they are reviewed, backup and restore-test records, staff training completion, and signed Business Associate Agreements with subcontractors. Collecting this evidence continuously — rather than before each review — is what keeps a vendor audit-ready.

Can HIPAA evidence be reused for SOC 2 and ISO 27001?

Yes. The HIPAA Security Rule’s controls map closely to SOC 2 Trust Services Criteria and ISO 27001 Annex A controls — access control, logging, encryption, risk assessment, incident response, and vendor management appear in all three. Mapping each control once and reusing the same evidence lets a vendor satisfy multiple frameworks from a single source of truth instead of running parallel projects.

The HIPAA Security Rule: Safeguards & Evidence Checklist for SaaS Vendors

What the Security Rule Really Asks For

Start Here: The Risk Analysis

Administrative Safeguards §164.308

🛠 One Control Design

📂 Evidence You Collect

Physical Safeguards §164.310

🛠 One Control Design

📂 Evidence You Collect

Technical Safeguards §164.312

🛠 One Control Design

📂 Evidence You Collect

The Required/Addressable Matrix at a Glance

The Evidence Buyers Actually Ask For

Collect It Once, Use It Everywhere

Stop Screenshotting. Start Proving.

Frequently Asked Questions

What is the difference between “required” and “addressable” in the HIPAA Security Rule?

Why is the risk analysis so important for HIPAA?

Does a SaaS vendor need to encrypt ePHI to be HIPAA compliant?

What evidence do I need to prove HIPAA Security Rule compliance?

Can HIPAA evidence be reused for SOC 2 and ISO 27001?

Explore more