What UCaaS compliance requirements apply to healthcare organizations?

HIPAA's Security Rule protects health information held or sent in electronic form. HHS has addressed where phone calls fall. In its guidance on audio-only telehealth, HHS says the Security Rule doesn't apply to audio-only services a covered entity provides over a standard telephone line, because the information transmitted isn't electronic.

The same guidance says the rule does apply when a covered entity uses electronic communication technologies, and it names Voice over Internet Protocol among them. Its list of technologies that need Security Rule safeguards includes communication apps on a smartphone or computer, VoIP, tools that electronically record or transcribe a session, and messaging services that store audio messages. UCaaS calling runs on VoIP, and a plan with recording, transcription or stored voicemail adds other items from that list. So a covered entity that uses a UCaaS service to talk with patients is using technologies HHS places under the Security Rule.

The rule applies to covered entities and to their business associates. HHS's summary of the Security Rule lists the covered entities as health plans, health care clearinghouses and health care providers that transmit health information electronically in connection with standard transactions. A company that works near healthcare but isn't sure it fits either description has to settle that question first.

A business associate is a vendor that creates, receives, maintains or transmits protected health information on a covered entity's behalf. Whether a phone provider is one depends on what it does with the information.

HHS recognizes a narrow exception for a conduit. A telecommunications provider that only carries a call, with transient access to what passes through, is acting as a conduit, and the audio telehealth guidance says no agreement is needed with it. The guidance then gives a contrasting case: a health care provider that wants to hold sessions through an app that stores recordings and transcripts in the developer's cloud has to sign an agreement with the developer before using the app with patients.

HHS's guidance on cloud computing explains the reasoning. The conduit exception covers transmission-only services, including temporary storage that's incidental to the transmission. A cloud vendor that does more than that, such as maintaining the information in order to store it, has more persistent access and is a business associate. The guidance says this holds for a vendor that stores only encrypted data and has no key to read it.

Applied to UCaaS, the question is whether the provider does anything with patient information beyond carrying the call. Voicemail, call recording, stored chat and meeting transcripts are the plain examples of doing more. Suppose a clinic turns those on and staff use them to discuss patients. The provider is then maintaining patient information for the clinic, which is the situation HHS's app example describes, and the agreement has to be in place first.

The agreement itself has required contents. According to HHS's summary, it must commit the provider to complying with the Security Rule, to holding its own subcontractors to the same terms, and to reporting security incidents, including breaches of unsecured patient information, to the covered entity. The cloud guidance adds that the configuration in use can affect what the agreement should say, since some controls end up as the customer's job and others as the provider's. So confirm that the agreement covers the features you're turning on, because one signed before those features were chosen may not. Asking for the agreement and its feature coverage belongs early in evaluating UCaaS providers, before price.

Suppose a clinic adds Atlantech Online's call recording service to its cloud phone system, and suppose it chooses cloud storage, so the recordings and transcripts are kept on the provider's side. Atlantech's page describes automatic capture of every call, AI transcription and search, storage in the cloud, on the customer's premises or both, role-based permissions, encryption, an audit trail, and configurable retention rules and legal holds.

Several of those features line up with what the Security Rule asks of the clinic. Role-based permissions are a way to carry out the rule's requirement that access to patient information suit a person's role. An audit trail is the kind of activity record the rule's audit controls standard calls for, and the rule expects such records to be examined. Retention rules and the storage location are the clinic's choices, and they shape what its risk analysis has to cover. Because the service records calls without anyone starting it, the clinic also needs to decide which lines and users are recorded in the first place.

Atlantech's page says the product is built to meet HIPAA. That's the vendor describing its controls. HHS's cloud guidance says the Office for Civil Rights doesn't endorse, certify or recommend specific technology or products, so a statement like that doesn't carry OCR's approval, for this vendor or any other.

The clinic's side of the work stays the same. With recordings and transcripts held in the provider's cloud for the clinic, it needs a signed agreement that covers those features before the first patient call is recorded, and it has to set the permissions, retention and storage to match its own policies. Those steps are necessary, but they don't establish compliance by themselves, because the risk analysis, training and procedures in the next section still apply.

The storage choice changes the analysis. A clinic that keeps every recording on its own premises has to work out what the provider still creates, receives, maintains or transmits on its behalf before it knows what the agreement must cover.

The Security Rule sets standards and leaves the method to the organization. HHS's summary says every standard must be met. Under each standard, some implementation details are marked "required" and others "addressable." Addressable doesn't mean optional. The organization assesses whether the measure is reasonable and appropriate for it, adopts it if so, and otherwise documents why not and adopts an alternative that achieves the same purpose where one is reasonable.

The technical safeguards section of the rule shows the split, and several of its items bear directly on a phone and messaging platform.

The rule's text names no encryption protocol, no session length and no particular sign-in method such as multi-factor authentication. Those are choices the organization makes and records in its risk analysis. HHS's telehealth guidance says that analysis should consider whether a transmission could be intercepted and whether encryption is available for calls and for stored recordings and transcripts. The wider set of controls is in UCaaS security practices that reduce breach risk.

The rule also has an administrative side. HHS's summary describes a risk analysis that is accurate and thorough, a named security official, policies that give each workforce member access suited to their role, training for the workforce, procedures for responding to security incidents, and a contingency plan covering data backup, recovery and operation in an emergency. Applied to a UCaaS rollout, we'd bring the service and the ways staff use it into the risk analysis, make sure access to recordings and voicemail follows each person's duties, and train people on which systems are approved for patient details. The settings on the platform protect what's on the platform, so the policy has to say what happens with channels the organization hasn't approved.

The rule's six-year figure has a narrow meaning. Documentation required by the Security Rule, meaning its policies and its records of required actions and assessments, has to be kept for six years from creation or from the date it was last in effect, whichever is later. That's a rule about compliance paperwork. It doesn't say every call recording or access log has to be kept for six years, so how long recordings live is a retention decision the organization makes and writes down.

HHS issued a proposed rule on December 27, 2024 to update the Security Rule. The department's page on the proposal says it would give more specific instruction about what regulated organizations must do and would require written policies that are reviewed, tested and updated on a regular basis.

The same page says the current Security Rule remains in effect while the rulemaking continues. HHS's Security Rule summary, last reviewed on August 7, 2026, says it addresses the rule currently in effect, and it describes required and addressable specifications as part of that rule. So a vendor or consultant describing stricter requirements from the proposal as today's law is ahead of the rule. An organization can still choose to adopt stronger controls as its own policy.

When patient information is exposed, the Breach Notification Rule decides who has to be told. HHS's summary of the rule says an impermissible use or disclosure of protected health information is presumed to be a breach unless the organization demonstrates a low probability that the information was compromised, based on a risk assessment. On a UCaaS platform, that covers the patient information the service handles, including calls in transit and anything retained, such as voicemail, recordings, messages and transcripts.

A covered entity must notify affected individuals without unreasonable delay and no later than 60 days after discovering a breach. The rule also requires notice to the HHS Secretary and, for a breach affecting more than 500 residents of a state or jurisdiction, to the media.

A business associate that has a breach must notify the covered entity under the same 60-day outer limit. If your UCaaS provider is your business associate, its reporting duty to you is part of the agreement, and 60 days is the latest the rule allows. The agreement can set a shorter window, and a shorter one leaves you more time to investigate and write to patients. The agreement also covers a wider category than breaches. The provider has to report any security incident it becomes aware of, and only some incidents turn out to be breaches that require notice.

Encryption affects whether notice is required at all. Notification is required only for unsecured information, which HHS defines as information that hasn't been made unusable, unreadable or indecipherable to unauthorized people through a method the department specifies in guidance. That guidance names encryption and destruction. HHS's summary says organizations that secure information as the guidance specifies are relieved from notifying after a breach of that information. An "encrypted" label on a feature list doesn't establish that by itself, because the method has to be one the guidance specifies. So ask the provider which method protects stored recordings and voicemail, and record the answer in the risk analysis.