What is a HIPAA Security Risk Assessment?
The HIPAA Security Rule (45 CFR § 164.308(a)(1)) requires every covered entity (CE) and business associate (BA) to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of all electronic protected health information (ePHI) it creates, receives, maintains, or transmits.
This is not optional. The Security Risk Assessment (SRA) is one of the most commonly cited findings in HIPAA investigations. The U.S. Department of Health and Human Services (HHS) Office for Civil Rights (OCR) has collected tens of millions of dollars in penalties from organisations that failed to conduct one, conducted an incomplete one, or conducted one but failed to act on its findings.
For SaaS companies building healthcare products or acting as business associates for covered entities, this is a non-negotiable compliance requirement before signing any Business Associate Agreement (BAA).
Who must conduct an SRA?
The SRA requirement applies to:
- Covered entities: Healthcare providers, health plans, and healthcare clearinghouses that electronically transmit health information
- Business associates: Any organisation that creates, receives, maintains, or transmits ePHI on behalf of a covered entity — including SaaS companies, EHR vendors, cloud storage providers, billing services, and telehealth platforms
- Business associates of business associates (sub-BAs): If you subcontract services to another company that involves ePHI access
If your SaaS product processes, stores, or transmits any data that could identify a patient and relate to their health condition, treatment, or payment, you are likely a business associate and must conduct an SRA.
The 9 required elements of a HIPAA SRA
HHS OCR has published guidance indicating that a compliant SRA must address these elements:
| # | Element | What it means in practice |
|---|---|---|
| 1 | Scope of the analysis | Identify all ePHI your organisation creates, receives, maintains, or transmits. This includes databases, backups, logs, emails, and data in sub-processor systems. |
| 2 | Data collection | Document where ePHI lives. Map data flows: how it enters, moves within, and exits your systems. Include all sub-processors and BAs. |
| 3 | Identify and document threats | Systematically identify plausible threats to ePHI: external (hackers, ransomware, social engineering), internal (employees, contractors), environmental (fire, flood, power failure), technical (software bugs, misconfiguration). |
| 4 | Identify and document vulnerabilities | Identify weaknesses that could be exploited by threats: unpatched systems, weak authentication, unencrypted storage, lack of audit logging, insufficient access controls. |
| 5 | Assess current security controls | Document existing safeguards: encryption, MFA, access control, backup procedures, incident response capabilities. Assess whether each control adequately addresses the relevant threats and vulnerabilities. |
| 6 | Determine likelihood of threat occurrence | For each threat-vulnerability pair, assess likelihood: Low / Medium / High. Consider your specific environment, industry patterns, and threat landscape. |
| 7 | Determine potential impact | For each threat, assess the potential impact on ePHI confidentiality, integrity, and availability. Consider patient harm, financial impact, and reputational damage. |
| 8 | Determine risk level | Combine likelihood and impact to produce a risk level (Low / Medium / High / Critical). This is the risk register that drives your remediation plan. |
| 9 | Document findings and create a remediation plan | Document the analysis and all findings. Create a Risk Management Plan addressing each high and critical risk, with assigned owners and target remediation dates. |
Common threats and vulnerabilities for SaaS business associates
These are the threats that OCR investigations and breach reports show most commonly affect healthcare SaaS:
- Ransomware and malware — Healthcare is the #1 target sector. Controls required: MFA, endpoint protection, offline backups, incident response plan, employee phishing training.
- Phishing / credential theft — Most ransomware starts with a phishing email. Controls: MFA, email filtering, security awareness training, privileged access management.
- Misconfigured cloud storage — S3 buckets, database instances, and backup storage accidentally left publicly accessible. Controls: cloud security posture management (CSPM), regular configuration review, IaC with security guardrails.
- Insider threat / excessive access — Employees or contractors accessing more ePHI than their role requires. Controls: RBAC, least-privilege enforcement, access reviews, audit logging.
- Unencrypted ePHI at rest or in transit — Data stored in plaintext or transmitted without TLS. Controls: encryption at rest (AES-256), encryption in transit (TLS 1.2+), encrypted backups.
- Third-party / sub-processor vulnerabilities — A vulnerability in a vendor's system exposes your ePHI. Controls: vendor risk assessment, BAA chain, sub-processor monitoring.
- Inadequate audit logging — No ability to detect or investigate ePHI access. Controls: comprehensive audit logs covering ePHI access, modification, and deletion; log retention (HIPAA requires 6 years).
How often must you conduct an SRA?
The HIPAA Security Rule requires the SRA to be ongoing — not a one-time exercise. While the regulation doesn't specify a particular frequency, HHS OCR guidance and enforcement actions indicate that a full SRA should be conducted:
- Initially: Before you sign any BAA or start handling ePHI
- Annually: As part of your regular security review cycle
- After significant environmental changes: Major infrastructure changes, new product features handling ePHI, new sub-processors, mergers or acquisitions, significant security incidents
You also need to document that you reviewed and updated your Risk Management Plan based on SRA findings. The plan, not just the assessment, needs to be acted on.
The SRA vs. SOC 2 Type II — what's the relationship?
These are complementary, not interchangeable. Here's how they relate:
| HIPAA SRA | SOC 2 Type II | |
|---|---|---|
| Required by | Federal law (HIPAA Security Rule) | Customer contracts / market expectation |
| Scope | ePHI specifically | Entire service system |
| Performed by | Internal team (can use a consultant) | Independent CPA firm |
| Frequency | At least annually / after major changes | Typically annual |
| Output | Risk register + remediation plan | Auditor's report on control effectiveness |
| Audience | Internal / regulatory | Customers / prospects |
If you have a SOC 2 Type II report with a Privacy criteria section, it demonstrates strong controls around personal information generally — but it does not replace the HIPAA SRA requirement. Healthcare enterprise customers will ask for both: the BAA (contract), the SRA (risk assessment), and ideally a SOC 2 Type II (independent audit) or HITRUST certification (the gold standard).
Practical steps to conduct your SRA
- Scope it first. List every system, database, backup, and third-party service that touches ePHI. Include cloud storage, logging systems, support platforms, and AI/ML services that process clinical notes or records.
- Map data flows. Draw (or document) how ePHI enters, moves within, and exits your system. Identify every entry point: API, file upload, integration, manual entry.
- Identify threats systematically. Use the OCR SRA Tool (free, downloadable from hhs.gov) as a starting framework. It walks through threat categories for small to medium healthcare organisations.
- Assess each vulnerability. For each threat, answer: do we have a control? Is it effective? What residual risk remains?
- Build your risk register. A spreadsheet with: Threat | Vulnerability | Current Control | Likelihood | Impact | Risk Level | Remediation | Owner | Target Date.
- Create your Risk Management Plan. Prioritise Critical and High risks. Assign owners. Set target dates. Review quarterly.
- Document everything. The documentation is the compliance evidence. An SRA you conducted but didn't document is treated the same as an SRA you didn't conduct during an OCR investigation.
BAA and SRA — the practical compliance stack for healthcare SaaS
If you're selling to hospitals, clinics, health plans, or any HIPAA-covered entity, your minimum viable compliance stack is:
- HIPAA Business Associate Agreement (BAA) — Signed before processing any ePHI. Generate a BAA for your specific services and PHI types.
- Security Risk Assessment — Documented annually, with a Risk Management Plan acted upon.
- Information Security Policy — Generate an InfoSec policy covering the administrative safeguards HIPAA requires.
- Incident Response Plan — Including the HIPAA breach notification procedure (60 days for individuals, HHS portal if 500+ affected). Generate an IRP with HIPAA procedures.
- GDPR DPA (if operating in or selling to EU customers) — HIPAA and GDPR often apply simultaneously for global health data platforms. Generate a GDPR DPA.
Enterprise healthcare buyers — hospital systems, health insurers, large clinic networks — will ask for evidence of all of these before signing a contract. Having them ready is a competitive advantage, not just a legal requirement.