Telehealth Security and HIPAA Compliance: A Provider Guide

HIPAA applies to telehealth exactly as it applies to in-person care: any protected health information (PHI) created, transmitted, or stored during a virtual visit must be safeguarded under the Privacy Rule, the Security Rule, and the Breach Notification Rule. The pandemic-era grace period — when regulators declined to penalize providers for using everyday video apps — is over. As of early 2026, a compliant telehealth program requires a signed business associate agreement (BAA) with every platform vendor that touches PHI, technical safeguards such as encryption and access controls, a current security risk analysis, and clear policies for the messy edges of virtual care: texting, email, recordings, and the new generation of AI documentation tools.

This guide walks through each requirement in practical terms, then closes with a compliance checklist you can run against your own program.

What HIPAA Actually Requires for Telehealth

HIPAA — the Health Insurance Portability and Accountability Act — is enforced by the HHS Office for Civil Rights (OCR) and applies to "covered entities" (providers, health plans, and clearinghouses that bill electronically) and their "business associates" (vendors that handle PHI on a covered entity's behalf). Three rules do most of the work in a telehealth context.

The Privacy Rule

The Privacy Rule governs when PHI may be used and disclosed. For telehealth, the practical implications are:

• Treatment communications are permitted. You do not need special patient authorization to conduct a video visit, share records with a consulting specialist, or coordinate care — these fall under HIPAA's treatment, payment, and operations permissions.
• The minimum necessary standard applies to uses and disclosures outside of treatment. Staff scheduling video visits should see only the PHI needed to do that job.
• Reasonable safeguards extend to the virtual exam room. Clinicians should take visits from private locations, use headphones in shared spaces, position screens away from bystanders, and confirm at the start of a visit that the patient is in a setting where they can speak freely. The same "elevator conversation" discipline that applies in a hospital hallway applies to a laptop in a kitchen.
• Patients retain their rights — to access their records, request amendments, and receive an accounting of disclosures — regardless of whether care was delivered virtually.

The Security Rule

The Security Rule applies specifically to electronic PHI (ePHI), which makes it the center of gravity for telehealth compliance. It requires three categories of safeguards:

The Security Rule is deliberately flexible — it lets organizations tailor safeguards to their size and complexity — but flexibility is not optionality. "Addressable" specifications (such as encryption) are not voluntary; an organization that decides not to implement one must document why and implement a reasonable alternative. In practice, encryption for telehealth traffic is so standard and inexpensive that declining to use it is nearly impossible to justify.

The Breach Notification Rule

When unsecured PHI is compromised, the Breach Notification Rule requires notifying affected patients without unreasonable delay (and within 60 days), notifying HHS, and — for breaches affecting 500 or more people — notifying prominent media outlets. An impermissible use or disclosure is presumed to be a breach unless the organization can demonstrate, through a documented risk assessment, a low probability that PHI was compromised.

A key nuance: PHI encrypted to federal standards is considered "secured," and its loss generally does not trigger notification. This is one of the strongest practical arguments for encrypting everything — a stolen laptop with full-disk encryption is an incident report; a stolen unencrypted laptop is a reportable breach.

The End of the Enforcement-Discretion Era

During the COVID-19 public health emergency, OCR announced it would not impose penalties on providers delivering telehealth in good faith through non-public-facing consumer apps — FaceTime, Skype, standard Zoom — even without BAAs. That discretion was an emergency measure, not a policy change, and it ended when the public health emergency expired in 2023, followed by a short OCR-announced transition period for providers to come into compliance.

The implications for any program still operating on pandemic-era habits:

• Consumer video apps without a BAA are no longer defensible. A practice conducting visits over a personal FaceTime account is exposed on every call.
• The compliance bar is the pre-2020 bar. All Security Rule requirements — risk analysis, access controls, audit capability, transmission security — apply in full.
• Enforcement attention has returned. OCR has signaled continued interest in risk-analysis failures, which appear in a large share of its settlement actions, and in patients' right of access. Telehealth is not a special enforcement category; it is simply part of the environment OCR expects organizations to have analyzed.

Note that HIPAA enforcement policy and telehealth reimbursement policy are separate tracks. Medicare's telehealth coverage flexibilities have been extended by Congress repeatedly in short increments, and their current status should always be verified with CMS or your payer — see our guide to telehealth reimbursement for how that landscape works. A visit can be fully HIPAA-compliant and still not be billable, and vice versa.

Business Associate Agreements with Platform Vendors

A business associate agreement is a contract in which a vendor handling PHI on your behalf commits to HIPAA's safeguards, agrees to report breaches to you, and accepts direct liability under the Security Rule. For telehealth, BAAs are typically needed with:

• The video visit platform
• The electronic health record vendor
• Cloud storage and hosting providers holding recordings, transcripts, images, or messages
• Secure messaging and patient-portal vendors
• Transcription services and AI scribe vendors
• E-prescribing intermediaries, answering services, and any IT vendor with access to systems containing ePHI

Points that trip programs up in practice:

• The BAA must be signed before PHI flows. Retroactive agreements do not cure the violation window.
• A vendor that refuses to sign a BAA cannot be used for PHI. Some consumer-grade services explicitly refuse; that refusal is the answer.
• Free tiers often exclude the BAA. Several major platforms offer BAAs only on paid healthcare plans. Check which tier your organization actually purchased.
• Read the scope. Some BAAs cover only certain products in a vendor's suite. A vendor might cover its video product but not its consumer chat product.
• Subcontractors matter. Your business associates must have their own BAAs with their subcontractors down the chain, but your diligence obligation is at the first link: choose vendors with credible security programs, and document that evaluation.

What Makes a Video Platform "HIPAA-Eligible"

A persistent misconception is that software can be "HIPAA certified." HIPAA does not certify software, and HHS endorses no products. Compliance is a property of how an organization uses technology, not of the technology itself. Vendor marketing that says "HIPAA compliant" is shorthand, at best, for "capable of supporting a customer's compliance." What actually matters:

1. The vendor will sign a BAA covering the specific product and tier you use.
2. Encryption in transit using current industry-standard protocols (TLS for signaling, encrypted media streams for audio/video).
3. Encryption at rest for anything stored — recordings, chat logs, transcripts, shared files.
4. Access controls: unique named accounts for every user, role-based permissions, support for multi-factor authentication, automatic session timeout.
5. Audit logging: the platform records who accessed what and when, and you can retrieve those logs.
6. Meeting-level security: waiting rooms or explicit admission of participants, locked sessions, no publicly guessable meeting links, host control over recording.
7. Data lifecycle controls: configurable retention, defensible deletion, and clarity about where data is stored geographically.
8. A public security posture: third-party audits such as SOC 2 or HITRUST are not HIPAA requirements, but they are reasonable proxies for a vendor that takes security seriously.

The distinction OCR drew during the pandemic between "non-public-facing" and "public-facing" products remains a useful heuristic: a platform where sessions are private, invited, and controlled by the host can potentially be used compliantly; a public-facing product like a livestream or open chat room never can. For a broader look at the platform landscape, see our overview of telehealth technology.

Core Technical Safeguards in Practice

Encryption in transit and at rest

Every leg of a telehealth interaction should be encrypted: the video and audio streams, the signaling that sets up the call, messages and file transfers, and any stored artifacts. Full-disk encryption on clinician laptops, tablets, and phones closes the most common physical loss scenario. Where visit recordings exist at all — and many programs sensibly default to not recording — they should be encrypted at rest, access-restricted, and retained only as long as policy requires.

Access controls

The Security Rule requires unique user identification, emergency access procedures, and encourages automatic logoff and encryption. Practically:

• No shared logins, ever — shared credentials destroy both accountability and audit trails.
• Role-based access: front-desk staff, clinicians, and billers see different slices of the system.
• Multi-factor authentication on anything reachable from the open internet, which describes essentially every telehealth component.
• Prompt deprovisioning when staff leave. Orphaned accounts are a recurring theme in OCR enforcement actions.

Audit logs

Audit controls are a required technical safeguard: systems handling ePHI must record activity, and someone must actually review the logs. For telehealth, that means retaining platform access logs, EHR access logs, and administrative change logs, then reviewing them on a defined schedule for anomalies — logins at odd hours, bulk record access, access to records of patients with no treatment relationship. Logs you never look at satisfy neither the regulation's letter nor its purpose.

The Risk Analysis Requirement

The security risk analysis is the foundation of the Security Rule and the most commonly cited gap in OCR enforcement. It is a documented, organization-wide assessment of where ePHI lives, what threats and vulnerabilities apply, how likely and severe each risk is, and what safeguards address it.

For telehealth specifically, a credible risk analysis must reach:

• The video platform and its configuration
• Clinician endpoints, including home computers and personal mobile devices used under any bring-your-own-device arrangement
• Home and remote networks used by clinicians
• Integrations between the telehealth platform, the EHR, and the patient portal
• Messaging channels (portal, SMS, email) and their failure modes
• Any AI documentation, transcription, or triage tools
• Vendor and subcontractor risk

Two operational points. First, the analysis must be current: adopting a new telehealth platform, adding an AI scribe, or shifting clinicians to home offices are each changes that should trigger an update, and an annual review is the widely accepted floor. Second, the analysis must lead to risk management — a documented plan that actually remediates the findings. HHS and the Office of the National Coordinator publish a free Security Risk Assessment tool aimed at small and mid-sized practices, and telehealth.hhs.gov maintains practical guidance for virtual care programs.

Common Breach Scenarios in Virtual Care

Peer-reviewed and government analyses of health data breaches consistently point to a mix of hacking, lost devices, and human error. In telehealth programs specifically, the recurring scenarios are:

• Misdirected communications. A visit link, after-visit summary, or message sent to the wrong patient — often a typo in a phone number or an autocomplete error in email.
• Uninvited participants. Sessions joined by the wrong party because links were reused, forwarded, or guessable, or because the host admitted a participant without verifying identity.
• Lost or stolen unencrypted devices. A clinician's laptop or phone containing cached PHI disappears; whether this is a breach usually turns entirely on encryption.
• Phishing and credential theft. Attackers compromise a staff email account or telehealth admin console; remote-friendly workflows widen this surface.
• Overheard visits. Clinicians conducting visits in shared or public spaces, or patients' household members overhearing sensitive content without the patient's awareness that they should relocate.
• Recordings in the wrong place. Visit recordings or AI-generated transcripts synced to personal cloud accounts, consumer note apps, or unsecured shares.
• Third-party tracking technologies. Analytics pixels and trackers on patient-facing scheduling and portal pages transmitting identifiable data to advertisers — an area OCR has publicly warned about.
• Ransomware against vendors. A platform or subcontractor compromise that becomes your notification obligation through the BAA chain.

Each scenario maps to a control already discussed: encryption, identity verification at session start, unique credentials with MFA, private-setting scripts, restrictive recording defaults, and vendor diligence.

Texting and Email with Patients

HIPAA does not ban texting or emailing patients — it regulates how. The rules of the road:

• Patient preference controls, with documentation. If a patient asks to communicate by standard text or email after being warned that these channels are not secure, HIPAA permits it. Document the warning and the preference.
• Provider-initiated clinical content should default to secure channels — portal messaging or an encrypted messaging product under BAA.
• Appointment reminders by SMS are generally acceptable when kept minimal: name, date, time, join link. Leave out diagnosis, test results, and clinic names that themselves reveal sensitive conditions (a reminder from a named HIV or addiction-treatment clinic discloses more than a generic one).
• Clinician-to-clinician texting about patients belongs on secure messaging platforms, not personal SMS threads, both for security and for records-retention reasons.
• Separate rule sets also apply. The Telephone Consumer Protection Act governs automated texts and calls, and 42 CFR Part 2 imposes stricter confidentiality on substance use disorder treatment records than HIPAA does. Programs in behavioral health — including telepsychiatry — should treat Part 2 as an additional layer, not a substitute analysis.

AI Scribes and Ambient Documentation

Ambient AI scribes — tools that listen to a visit, transcribe it, and draft a clinical note — have moved rapidly into telehealth workflows. They are not exempt from anything above; they concentrate several compliance questions at once:

• BAA, first and always. An AI scribe vendor receives among the most sensitive PHI a practice generates: the verbatim clinical conversation. No BAA, no deployment.
• Data use and model training. Interrogate what the vendor does with audio, transcripts, and drafts. Under HIPAA, a business associate may use PHI only as the BAA permits. Whether visit data is used to train or improve models — and whether "de-identified" training data meets HIPAA's actual de-identification standards — should be answered in writing, not assumed from marketing pages. Prefer contracts that prohibit training on your patients' identifiable data or give you a genuine opt-out.
• Retention and deletion. How long do raw audio and transcripts persist, where, and can you compel deletion? Ephemeral processing (audio discarded after note generation) is meaningfully lower risk than indefinite retention.
• Patient notice and consent. HIPAA's treatment permission likely covers the scribe's core function, but telling patients a listening tool is in use is both an ethical baseline and, in some states, a legal one: two-party-consent recording laws can require the patient's affirmative agreement to any recording. A brief scripted disclosure at visit start, with the ability to decline, is the emerging standard of practice, and AMA guidance on augmented intelligence points the same direction.
• Accuracy is a safety issue, not just a privacy one. Clinicians must review and correct AI drafts before signing; an unreviewed hallucinated medication in a note is a patient-safety event with legal dimensions.
• Update the risk analysis. An AI scribe is a new system touching ePHI. Its adoption is precisely the kind of environmental change that requires the security risk analysis to be revisited.

The same framework applies to AI triage chatbots, automated intake tools, and remote patient monitoring analytics: identify the PHI flow, paper it with a BAA, constrain data use, and tell patients what is happening.

State Privacy Laws Layer on Top

HIPAA is a floor, not a ceiling. It preempts only state laws that are less protective; anything stricter still binds you. The state layer is growing fast:

• Comprehensive state privacy laws (California's CPRA and the wave of state analogues) generally exempt PHI already covered by HIPAA — but the exemption is usually entity- or data-scoped, and non-PHI data a practice holds, such as website analytics or marketing lists, can fall inside them.
• Consumer health data laws such as Washington's My Health My Data Act reach health-related data held by entities outside HIPAA — wellness apps, some direct-to-consumer telehealth adjacent services — and impose consent requirements and private rights of action that HIPAA lacks. Digital-health companies operating consumer-facing products alongside covered-entity services must map which regime governs which data.
• Condition-specific state confidentiality laws — for HIV status, mental health, genetic information, and reproductive health — frequently require patient consent for disclosures HIPAA would permit. Federal rulemaking has also strengthened protections around reproductive health information; verify the current state of those rules with HHS before building workflows on them.
• Recording-consent statutes in two-party-consent states affect visit recording and ambient AI, as noted above.
• Telehealth-specific consent statutes in many states require documented informed consent to telehealth as a modality — a distinct requirement from privacy consent. The Center for Connected Health Policy tracks these state-by-state, and our guide to telemedicine laws by state covers how licensure and consent rules vary.

The practical takeaway: a multistate telehealth program needs a state-law matrix, not just a HIPAA policy binder.

Practical Telehealth HIPAA Compliance Checklist

Run this list quarterly. Most items cost more discipline than money, and the expensive failures — breach notification, OCR investigation, class litigation — are concentrated exactly where the cheap controls were skipped.

Where Security Fits in the Bigger Picture

Security and privacy compliance is one pillar of a durable virtual care program, alongside licensure, reimbursement, and workflow design. If you are building a program from scratch, our guide on how to start a telemedicine program places these requirements in sequence, and clinicians looking to sharpen the visit itself can start with our telehealth video visit tips. The organizations that treat HIPAA as a design constraint from day one — rather than a retrofit after the first incident — consistently spend less on compliance and lose less sleep over it.