A 2020 intrusion at MMG Fusion, a software company whose product is used to communicate with patients, affected the protected health information of about 15 million people. When the HHS Office for Civil Rights (OCR) settled the case in March 2026, it cited one potential violation: a lack of an accurate, thorough risk analysis. Most of the industry calls that analysis a HIPAA risk assessment, and it applies to any business handling electronic protected health information (ePHI), including telehealth brands that rely on several technology vendors.
Risk analysis is a foundational requirement that OCR examines during Security Rule investigations, and the MMG Fusion settlement was the 12th enforcement action in OCR's Risk Analysis Initiative. For the broader regulatory context, this overview of HIPAA basics for telehealth covers the underlying obligations. The example below applies HHS's risk analysis guidance to one realistic telehealth technology stack and builds a sample risk register that operators can adapt to their own environment.
What HHS Counts as a Risk Analysis
Under 45 CFR 164.308(a)(1)(ii)(A), the HIPAA Security Rule requires covered entities and business associates to conduct an accurate and thorough assessment of potential risks and vulnerabilities affecting the confidentiality, integrity, and availability of their ePHI.
HHS's Guidance on Risk Analysis explains that the Security Rule does not prescribe a single methodology. Organizations can choose an approach that fits their size, complexity, and capabilities, as long as the analysis meets the required objectives.
The guidance identifies nine elements:
- Scope: Identify all ePHI created, received, maintained, or transmitted.
- Data collection: Document where that information exists and moves.
- Threats and vulnerabilities: Identify potential security weaknesses and reasonably anticipated threats.
- Current security measures: Assess existing safeguards.
- Likelihood: Estimate the probability of each threat occurring.
- Impact: Evaluate the potential consequences.
- Level of risk: Assign and document risk levels.
- Documentation: Record the findings and methodology.
- Periodic review: Reassess risks as circumstances change.
These elements form the structure of the example below. HHS uses the term risk analysis, while the healthcare industry frequently uses risk assessment to describe the same required process.
The Example: One Telehealth Stack
Consider a generic direct-to-consumer telehealth operation that provides virtual consultations and, when clinically appropriate, connects patients with prescription services.
Its technology environment includes a branded website with an intake questionnaire, a telehealth platform connected to an electronic health record (EHR), video visits, patient messaging, SMS reminders, staff email, a payment processor, a pharmacy partner, analytics tags, and employee laptops.
The first task is to identify where ePHI enters, travels through, or remains within that environment. Understanding what counts as PHI helps distinguish ordinary business information from data that requires protection under HIPAA.
For this example, the inventory has nine entries. The website and intake hold questionnaires and submitted health information, and the telehealth platform and EHR hold clinical records, consultations, and prescriptions. Video visits, messaging, and SMS carry patient-provider communications and reminders, and staff email carries patient-related messages and attachments. The payment processor sees transaction data and potentially revealing metadata; the pharmacy partner receives prescription and fulfillment details; analytics tools capture website events that could disclose information; and staff devices store access to patient records, downloaded files, and credentials.
The inventory establishes the scope, but it does not yet demonstrate that the systems are secure. The organization still needs to examine threats, vulnerabilities, and existing protections, including whether vendors receive ePHI and what information integrations expose.
A Sample Risk Register
A risk register turns the inventory into a record of potential threats, existing safeguards, and risk ratings.
The scores below are illustrative, not findings about a real company or verdicts on any product. Actual ratings require evidence about the organization's systems, configurations, workforce, and operating environment.
| Asset | Threat or Vulnerability | Current Control | Likelihood | Impact | Risk |
|---|
| Staff email | Phishing leads to account takeover | MFA, phishing training | Medium | High | High |
| Telehealth platform and EHR | Vendor breach or misconfiguration | BAA, security documentation, encryption, access roles | Low | High | Medium |
| Analytics and ad tags | Tags on authenticated pages send PHI to a vendor without an appropriate BAA | Tag review, no tags on authenticated pages | Medium | High | High |
| SMS reminders | Message reveals a condition or medication | Neutral templates | Medium | Medium | Medium |
| Former staff accounts | Access remains active after offboarding | Offboarding checklist, access review | Medium | High | High |
| Payments | Treatment information appears in receipts, descriptors, or metadata | Generic product names | Medium | Medium | Medium |
| File storage and backups | Ransomware encrypts records | Offline backups, restore tests | Low | High | Medium |
Two rows illustrate how this becomes operational work.
For staff email, the organization would evaluate phishing exposure, MFA coverage, employee access, training, and how sensitive messages are handled. Its assessment may draw on a dedicated HIPAA-compliant email policy rather than assuming that MFA alone resolves every email-related risk.
For SMS, teams should review the actual message templates and workflows. A reminder that reveals a medication or condition may create different exposure than a neutral appointment notification. A separate guide to automated appointment reminders covers the communication workflow, while the risk register evaluates the security implications of its implementation.
The analytics row deserves particular attention because websites can transmit data to outside vendors without employees manually sending anything. A brand should inspect where tracking technologies run, what information they collect, and whether the resulting disclosures are permitted. Removing tags from authenticated pages reduces exposure, but the remaining tags still need the same review.
How to Score Likelihood and Impact
A three-level scoring system can make the register manageable:
- Low: The event appears less likely, or the potential consequences are relatively limited.
- Medium: The threat is plausible, or the consequences could be material.
- High: The threat is more likely, or the consequences could be severe.
The register combines likelihood and impact into an overall risk rating. A low-likelihood event with potentially serious consequences can still justify substantial attention, particularly when patient information or access to critical systems is involved.
HHS does not require a particular scoring formula. What matters is that the organization documents its chosen methodology, applies it consistently, and can explain how the evidence supports the conclusions.
The register should also distinguish safeguards that have actually been implemented and verified from measures that are merely planned.
The Platform Row, With Bask as the Example
A telehealth platform is one component of the broader risk assessment, even when it supports several essential healthcare workflows.
For each vendor that creates, receives, maintains, or transmits ePHI on the brand's behalf, the organization should evaluate the relationship and collect applicable documentation, including:
- An appropriate business associate agreement (BAA).
- Documentation of relevant technical and administrative safeguards.
- Independent assurance reports, such as SOC 2, where available.
- Information about access controls, security incidents, and responsibilities.
This guide to SOC 2 reports explains how independent assurance reports can help organizations evaluate vendor controls.
Bask Health shows how a platform vendor fits into the register. Its published security controls include encryption at rest and in transit, two-factor authentication, administrative access control, centralized management of user identities and connected devices, and system monitoring, logging, and alerting. Bask also maintains SOC 2 Type II controls and audit logging. Because intake, video and chat visits, the EMR and e-prescribing tools, and payment processing run on the same platform, several rows in the sample inventory point to one vendor instead of four, which shortens the list of vendor documents a brand has to collect and review. The identity and device management also bears directly on the former staff accounts row.
A brand can cite these controls in the platform row once it confirms which ones apply to its own setup. The rest of the register, from workforce and devices to analytics, payments, and other vendors, is still the brand's to assess.
From Register to Risk Management Plan
Completing the register identifies and evaluates risks, but the Security Rule also requires organizations to manage them.
Under 45 CFR 164.308(a)(1)(ii)(B), the required risk management specification calls for implementing security measures that reduce risks and vulnerabilities to a reasonable and appropriate level.
For the sample register, the three High-rated items become a dated action plan with named owners. The IT lead verifies MFA coverage and reviews email access policies within 30 days. The engineering lead audits tracking tags and removes or fixes problem configurations within 14 days. The operations lead tests account termination and schedules recurring access reviews within 30 days.
These are illustrative assignments and deadlines, not HIPAA-mandated remediation periods.
Each action should have a completion record and supporting evidence. For example, resolving the offboarding risk could involve documenting the revised termination process, testing it, and confirming that access reviews detect accounts that should no longer be active.
Risk management also continues after initial remediation. The Security Rule's information system activity review specification requires regular review of records such as audit logs and access reports, which can help identify suspicious activity or failures in established controls.
How Often to Redo It
HHS does not establish one universal frequency for performing a HIPAA risk analysis. Its guidance notes that some organizations perform the analysis annually or as needed, for example every two or three years, depending on their circumstances.
For telehealth companies, meaningful operational changes should prompt a review of whether the existing analysis remains accurate. Examples include:
- Adding a vendor that handles ePHI.
- Expanding into another state or introducing a new product line that changes data flows.
- Launching a feature such as asynchronous patient messaging.
- Experiencing a security incident or discovering a significant vulnerability.
A new vendor, for example, can introduce additional storage locations, access pathways, or information transfers that were not part of the original assessment.
The key question is whether the previous analysis still reflects the environment the organization actually operates in. A dated assessment may remain valuable evidence of earlier work, but it cannot describe risks introduced after it was completed.
FAQs
Does HIPAA Require a Risk Assessment?
Yes. The HIPAA Security Rule requires covered entities and business associates to conduct an accurate and thorough risk analysis of potential risks and vulnerabilities affecting ePHI. The requirement appears at 45 CFR 164.308(a)(1)(ii)(A).
Is a Risk Assessment the Same as a Risk Analysis?
In this context, the terms are commonly used interchangeably. HHS uses risk analysis in the Security Rule and its guidance, while software vendors and compliance teams frequently refer to a HIPAA risk assessment.
Can a Small Practice Use the HHS SRA Tool?
Yes. The HealthIT.gov Security Risk Assessment Tool was designed primarily for small and medium-sized healthcare providers. Version 3.7 is available as a Windows application and an Excel workbook.
The tool can guide an organization through assessment questions and documentation, but it is not required and doesn't guarantee HIPAA compliance.
Does a SOC 2 Report Replace a HIPAA Risk Assessment?
No. A SOC 2 report can describe a service organization's controls, but it doesn't evaluate every system, employee, device, vendor, or data flow within the telehealth brand's environment.
The brand remains responsible for performing its own applicable risk analysis, including examining risks that may exist outside its primary technology platform.
What to Keep on File
Maintain an organized, dated set of records containing:
- Scope statement: Which operations and environments were assessed.
- Asset and data-flow inventory: Where ePHI is created, received, maintained, or transmitted.
- Risk register: Identified threats, vulnerabilities, safeguards, and risk ratings.
- Scoring methodology: How likelihood, impact, and overall risk were determined.
- Risk management plan: Corrective actions, responsible owners, deadlines, and evidence of completion.
- Review history: Assessment dates, changes, and follow-up decisions.
- Vendor documentation: Applicable BAAs, security materials, and relevant assurance reports.
References
- U.S. Department of Health and Human Services. (n.d.). Guidance on risk analysis. https://www.hhs.gov/hipaa/for-professionals/security/guidance/guidance-risk-analysis/index.html
- U.S. Department of Health and Human Services. (2026). HHS’ Office for Civil Rights settles HIPAA investigation of MMG Fusion, LLC breach affecting 15 million individuals. https://www.hhs.gov/press-room/ocr-mmg-fusion-hipaa-agreement.html
- Office of the National Coordinator for Health Information Technology. (2026). Security risk assessment tool. https://healthit.gov/privacy-security/security-risk-assessment-tool/
