In the United States, the main requirements come from HIPAA, and they attach to the organization and how it uses the service. A health plan, a clearinghouse or a health care provider covered by HIPAA has to bring its internet-based phone system inside its Security Rule risk analysis and safeguards. If the UCaaS provider keeps voicemail, recordings, messages or transcripts that contain patient information, the organization also needs a business associate agreement with that provider before using those features with patients. HHS's Office for Civil Rights doesn't endorse or certify technology products, so a vendor's HIPAA label doesn't settle any of this.
\n","summary":"In the United States, HIPAA sets the main requirements. A covered entity using UCaaS has to include it in its Security Rule risk analysis and safeguards, and needs a business associate agreement before using features that store patient information, such as voicemail, recordings and transcripts. HHS's Office for Civil Rights doesn't endorse or certify products.","publishedAt":"2026-08-25T14:28:52.466","verifiedAt":null,"editorialStatus":"APPROVED","lastReviewedAt":"2026-10-10T04:22:06.993","nextReviewDueAt":null,"templateVersion":"v2","aliases":["HIPAA requirements for UCaaS in healthcare","Is a UCaaS provider a HIPAA business associate?","Does a cloud phone provider need a BAA for healthcare?","Is encryption required by HIPAA for VoIP and UCaaS?","Does 42 CFR Part 2 apply to healthcare communications platforms?"],"confidenceScore":null,"confidenceLabel":null,"canonicalUrl":"https://ucaasreview.com/ensuring-ucaas-compliance-in-regulated-industries"},"contributor":{"id":"ec39deab-44fe-48d8-9029-fefe993ab85a","slug":"answer-stack","displayName":"AnswerStack","websiteUrl":null},"contributorOrganizationProfile":null,"contributorPerson":null,"sections":[{"id":"1b8cb749-cee5-4a22-9cc2-1bede0036ee3","sectionKey":"why_a_cloud_phone_system_falls_under_the_security_rule","sectionType":"markdown_section","heading":"Why a cloud phone system falls under the Security Rule","introMarkdown":"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](https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/hipaa-audio-telehealth/index.html), 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.\n\nThe 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](https://www.answerstack.io/q/what-is-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.\n\nThe rule applies to covered entities and to their business associates. HHS's [summary of the Security Rule](https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html) 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.","introHtml":"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.
\nThe 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.
\nThe 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.
\n","outroMarkdown":null,"outroHtml":null,"contentJson":{},"configJson":{},"noteMarkdown":null,"noteHtml":null,"sortOrder":10},{"id":"c4d7b893-f058-466b-b6d6-a36a9004b556","sectionKey":"when_the_ucaas_provider_needs_a_business_associate_agreement","sectionType":"markdown_section","heading":"When the UCaaS provider needs a business associate agreement","introMarkdown":"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.\n\nHHS 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.\n\nHHS's [guidance on cloud computing](https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html) 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.\n\nApplied 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.\n\nThe 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](https://www.answerstack.io/q/how-do-you-evaluate-ucaas-providers-before-buying), before price.","introHtml":"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.
\nHHS 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.
\nHHS'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.
\nApplied 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.
\nThe 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.
\n","outroMarkdown":null,"outroHtml":null,"contentJson":{},"configJson":{},"noteMarkdown":null,"noteHtml":null,"sortOrder":20},{"id":"dcb190f2-f6b7-40ad-852f-fe852235f38e","sectionKey":"what_this_looks_like_with_a_recording_product","sectionType":"markdown_section","heading":"What this looks like with a recording product","introMarkdown":"Suppose a clinic adds [Atlantech Online's call recording service](https://www.atlantech.net/call-recording) 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.\n\nSeveral 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.\n\nAtlantech'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.\n\nThe 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.\n\nThe 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.","introHtml":"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.
\nSeveral 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.
\nAtlantech'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.
\nThe 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.
\nThe 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.
\n","outroMarkdown":null,"outroHtml":null,"contentJson":{},"configJson":{},"noteMarkdown":null,"noteHtml":null,"sortOrder":30},{"id":"49fa6862-bbb0-49b7-8bcd-461c9d290fd2","sectionKey":"how_the_security_rule_sets_its_requirements","sectionType":"markdown_section","heading":"How the Security Rule sets its requirements","introMarkdown":"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.\n\nThe [technical safeguards section of the rule](https://www.law.cornell.edu/cfr/text/45/164.312) shows the split, and several of its items bear directly on a phone and messaging platform.","introHtml":"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.
\nThe technical safeguards section of the rule shows the split, and several of its items bear directly on a phone and messaging platform.
\n","outroMarkdown":null,"outroHtml":null,"contentJson":{},"configJson":{},"noteMarkdown":null,"noteHtml":null,"sortOrder":40},{"id":"c0f009eb-f7ba-47ab-bc4e-87b942e0ac98","sectionKey":"technical_safeguards_that_bear_on_a_phone_and_messaging_platform","sectionType":"table_section","heading":"Technical safeguards that bear on a phone and messaging platform","introMarkdown":null,"introHtml":null,"outroMarkdown":null,"outroHtml":null,"contentJson":{"rows":[{"cells":["Unique user identification","Required","Each person signs in as themselves, with no shared logins"]},{"cells":["Audit controls","Standard, must be met","The system records activity involving patient information, and someone examines the record"]},{"cells":["Person or entity authentication","Standard, must be met","A sign-in procedure verifies the user is who they claim to be"]},{"cells":["Transmission security","Standard, must be met","Technical measures guard patient information against unauthorized access while it's sent over a network; encryption is the addressable measure under it"]},{"cells":["Automatic logoff","Addressable","Idle sessions end after a set time where that's reasonable and appropriate; if it isn't, you document why and use an equivalent alternative where one is reasonable and appropriate"]},{"cells":["Encryption","Addressable","You encrypt stored and transmitted information where that's reasonable and appropriate; if it isn't, you document why and use an equivalent alternative where one is reasonable and appropriate"]}],"columns":["Safeguard in the rule","Status","What it means on a UCaaS platform"]},"configJson":{},"noteMarkdown":null,"noteHtml":null,"sortOrder":50},{"id":"36467172-601a-480d-9d4d-f4c12b863d67","sectionKey":"what_the_rule_leaves_to_you","sectionType":"markdown_section","heading":"What the rule leaves to you","introMarkdown":"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](https://www.answerstack.io/q/what-ucaas-security-best-practices-reduce-data-breach-risk).\n\nThe 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.\n\nThe 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.","introHtml":"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.
\nThe 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.
\nThe 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.
\n","outroMarkdown":null,"outroHtml":null,"contentJson":{},"configJson":{},"noteMarkdown":null,"noteHtml":null,"sortOrder":60},{"id":"8700bdf4-5efe-47cc-b4f7-b52785f38569","sectionKey":"a_proposed_rule_hasn_t_replaced_the_current_one","sectionType":"markdown_section","heading":"A proposed rule hasn't replaced the current one","introMarkdown":"HHS issued a proposed rule on December 27, 2024 to update the Security Rule. The department's [page on the proposal](https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/index.html) 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.\n\nThe 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.","introHtml":"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.
\nThe 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.
\n","outroMarkdown":null,"outroHtml":null,"contentJson":{},"configJson":{},"noteMarkdown":null,"noteHtml":null,"sortOrder":70},{"id":"3b37d529-e4e6-4ae8-8edf-99c0a57eacf8","sectionKey":"what_the_breach_rules_require_of_you_and_the_provider","sectionType":"markdown_section","heading":"What the breach rules require of you and the provider","introMarkdown":"When patient information is exposed, the Breach Notification Rule decides who has to be told. HHS's [summary of the rule](https://www.hhs.gov/hipaa/for-professionals/breach-notification/index.html) 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.\n\nA 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.\n\nA 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.\n\nEncryption 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.","introHtml":"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.
\nA 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.
\nA 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.
\nEncryption 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.
\n","outroMarkdown":null,"outroHtml":null,"contentJson":{},"configJson":{},"noteMarkdown":null,"noteHtml":null,"sortOrder":80}],"citations":[{"title":"45 CFR 160.103 Definitions","url":"https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-160/subpart-A/section-160.103","excerpt":"Business associate means, with respect to a covered entity, a person who: (i) On behalf of such covered entity ... creates, receives, maintains, or transmits protected health information","quoteText":null,"sourceRole":"PRIMARY","verifiedAt":"2026-09-14T00:00:00","supportsText":"Definitions of business associate (creates, receives, maintains or transmits PHI on behalf of a covered entity; includes subcontractors) and covered entity (health plans, clearinghouses, providers transmitting health information electronically in covered transactions).","domain":"ecfr.gov","publisherName":"Electronic Code of Federal Regulations (US National Archives)"},{"title":"45 CFR 164.308 Administrative safeguards","url":"https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.308","excerpt":"Risk analysis (Required). Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information","quoteText":null,"sourceRole":"PRIMARY","verifiedAt":"2026-09-14T00:00:00","supportsText":"Risk analysis and risk management (Required), information system activity review of audit logs (Required), information access management consistent with the Privacy Rule, and satisfactory assurances before a business associate handles ePHI. No frequency is stated for risk analysis.","domain":"ecfr.gov","publisherName":"Electronic Code of Federal Regulations (US National Archives)"},{"title":"45 CFR 164.314 Organizational requirements","url":"https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.314","excerpt":"Report to the covered entity any security incident of which it becomes aware, including breaches of unsecured protected health information as required by ยง 164.410.","quoteText":null,"sourceRole":"PRIMARY","verifiedAt":"2026-09-14T00:00:00","supportsText":"Required business associate contract terms: comply with the Security Rule, bind subcontractors, report security incidents including breaches of unsecured PHI.","domain":"ecfr.gov","publisherName":"eCFR (Office of the Federal Register)"},{"title":"45 CFR 164.306 Security standards: General rules","url":"https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.306","excerpt":"Document why it would not be reasonable and appropriate to implement the implementation specification; and Implement an equivalent alternative measure if reasonable and appropriate","quoteText":null,"sourceRole":"PRIMARY","verifiedAt":"2026-09-14T00:00:00","supportsText":"Meaning of Required versus Addressable implementation specifications, including the duty to assess, implement, or document why not and adopt an equivalent alternative.","domain":"ecfr.gov","publisherName":"Electronic Code of Federal Regulations (US National Archives)"},{"title":"45 CFR 164.312 Technical safeguards","url":"https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312","excerpt":"Encryption (Addressable). Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate.","quoteText":null,"sourceRole":"PRIMARY","verifiedAt":"2026-09-14T00:00:00","supportsText":"Unique user identification (Required), automatic logoff (Addressable), encryption and decryption (Addressable), audit controls, person or entity authentication, transmission security with encryption whenever deemed appropriate (Addressable). No protocols or MFA named; eCFR shows no changes after 1/0","domain":"ecfr.gov","publisherName":"Electronic Code of Federal Regulations (US National Archives)"},{"title":"45 CFR 164.316 Policies and procedures and documentation requirements","url":"https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.316","excerpt":"Retain the documentation required by paragraph (b)(1) of this section for 6 years from the date of its creation or the date when it last was in effect, whichever is later.","quoteText":null,"sourceRole":"PRIMARY","verifiedAt":"2026-09-14T00:00:00","supportsText":"Six-year retention for Security Rule policies and required records of actions, activities and assessments; periodic review and update in response to environmental or operational changes. Does not name audit logs as covered documentation.","domain":"ecfr.gov","publisherName":"Electronic Code of Federal Regulations (US National Archives)"},{"title":"45 CFR Part 164 Subpart D Notification in the case of breach of unsecured PHI","url":"https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-D","excerpt":"a covered entity shall provide the notification required by paragraph (a) of this section without unreasonable delay and in no case later than 60 calendar days after discovery of a breach.","quoteText":null,"sourceRole":"PRIMARY","verifiedAt":"2026-09-14T00:00:00","supportsText":"Breach and unsecured PHI definitions, presumption of breach, discovery date, notice deadlines to individuals, media (more than 500 residents), HHS (500 or more contemporaneous; fewer than 500 within 60 days after year end), business associate notice to covered entity, law enforcement delay.","domain":"ecfr.gov","publisherName":"eCFR (Office of the Federal Register)"},{"title":"45 CFR 164.502 Uses and disclosures of PHI: General rules","url":"https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.502","excerpt":"a covered entity or business associate must make reasonable efforts to limit protected health information to the minimum necessary to accomplish the intended purpose","quoteText":null,"sourceRole":"PRIMARY","verifiedAt":"2026-09-14T00:00:00","supportsText":"Minimum necessary standard and its exceptions, including disclosures to a health care provider for treatment.","domain":"ecfr.gov","publisherName":"eCFR (Office of the Federal Register)"},{"title":"Modifications to the HIPAA Privacy, Security, Enforcement, and Breach Notification Rules (Omnibus Final Rule), January 25, 2013","url":"https://www.federalregister.gov/documents/2013/01/25/2013-01073/modifications-to-the-hipaa-privacy-security-enforcement-and-breach-notification-rules-under-the-health","excerpt":"The conduit exception is limited to transmission services (whether digital or hard copy), including any temporary storage of transmitted data incident to such transmission.","quoteText":null,"sourceRole":"PRIMARY","verifiedAt":"2026-09-14T00:00:00","supportsText":"Conduit exception limited to transmission services with temporary storage incident to transmission; an entity that maintains PHI is a business associate even if it does not view it; transient versus persistent access.","domain":"federalregister.gov","publisherName":"Federal Register (HHS)"},{"title":"HIPAA and the HITECH Act","url":"https://learn.microsoft.com/en-us/compliance/regulatory/offering-hipaa-hitech","excerpt":"By offering a Business Associate Agreement, Microsoft helps support your HIPAA compliance. However, using Microsoft services doesn't on its own achieve HIPAA compliance.","quoteText":null,"sourceRole":"SUPPORTING","verifiedAt":"2026-09-14T00:00:00","supportsText":"Vendor statements: Microsoft's BAA covers listed in-scope services (Microsoft Teams is listed); having the BAA does not on its own achieve compliance; no HHS-approved HIPAA certification standard currently exists. Used as an example of scope-limited BAAs, not as an evaluation of Microsoft.","domain":"learn.microsoft.com","publisherName":"Microsoft Learn (vendor documentation, updated 2025-07-29)"},{"title":"HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information (Proposed Rule), January 6, 2025","url":"https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information","excerpt":"proposed 45 CFR 164.312(b)(2) would require regulated entities to encrypt all ePHI at rest and in transit, with limited exceptions.","quoteText":null,"sourceRole":"PRIMARY","verifiedAt":"2026-09-14T00:00:00","supportsText":"Proposals only: remove the addressable/required distinction, require encryption of all ePHI at rest and in transit with limited exceptions, MFA requirement with exceptions, review of technology asset inventory and network map at least every 12 months. Federal Register API search for RIN 0945-AA22 on","domain":"federalregister.gov","publisherName":"Federal Register (HHS Office for Civil Rights)"},{"title":"42 CFR 2.12 Applicability","url":"https://www.ecfr.gov/current/title-42/chapter-I/subchapter-A/part-2/subpart-A/section-2.12","excerpt":"The restrictions on use and disclosure in the regulations in this part apply to any records which: (i) Would identify a patient as having or having had a substance use disorder","quoteText":null,"sourceRole":"PRIMARY","verifiedAt":"2026-09-14T00:00:00","supportsText":"Part 2 applies to records identifying a patient as having a substance use disorder obtained by a federally assisted program; federal assistance criteria. Program definition in 42 CFR 2.11 (holds itself out as providing SUD diagnosis, treatment or referral; identified unit or primary-function staff i","domain":"ecfr.gov","publisherName":"eCFR (Office of the Federal Register)"},{"title":"Confidentiality of Substance Use Disorder (SUD) Patient Records (Final Rule), February 16, 2024","url":"https://www.federalregister.gov/documents/2024/02/16/2024-02544/confidentiality-of-substance-use-disorder-sud-patient-records","excerpt":"Persons subject to this regulation must comply with the applicable requirements of this final rule by February 16, 2026.","quoteText":null,"sourceRole":"PRIMARY","verifiedAt":"2026-09-14T00:00:00","supportsText":"Single consent for future TPO uses and disclosures; breach notification applied to unsecured Part 2 records in the same manner as unsecured PHI; compliance date February 16, 2026.","domain":"federalregister.gov","publisherName":"Federal Register (HHS)"},{"title":"45 CFR 160.203 General rule and exceptions (preemption)","url":"https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-160/subpart-B/section-160.203","excerpt":"The provision of State law relates to the privacy of individually identifiable health information and is more stringent than a standard, requirement, or implementation specification adopted under subpart E of part 164","quoteText":null,"sourceRole":"PRIMARY","verifiedAt":"2026-09-14T00:00:00","supportsText":"HIPAA preempts contrary state law except where, among other exceptions, the state law relates to health information privacy and is more stringent.","domain":"ecfr.gov","publisherName":"eCFR (Office of the Federal Register)"},{"title":"SP 800-66 Rev. 2, Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide","url":"https://csrc.nist.gov/pubs/sp/800/66/r2/final","excerpt":"This publication provides practical guidance and resources that can be used by regulated entities of all sizes to safeguard ePHI","quoteText":null,"sourceRole":"INDEPENDENT","verifiedAt":"2026-09-14T00:00:00","supportsText":"Implementation guidance for the Security Rule for regulated entities of all sizes, published February 2024; guidance, not regulation.","domain":"csrc.nist.gov","publisherName":"NIST Computer Security Resource Center"}],"revisions":[{"revisedAt":"2026-06-15T14:28:52.466+00:00","versionLabel":"Originally published","note":"","reviewedBy":null}],"relatedAnswers":[{"id":"f7b5d5d8-aadd-4135-b31d-5ff0dbbf934e","slug":"what-ucaas-deployment-model-suits-enterprises-with-hybrid-infrastructure","question":"What UCaaS deployment model suits enterprises with hybrid infrastructure?","publishedAt":"2026-09-27T14:29:18.879","confidenceScore":null,"confidenceLabel":null,"industry":{"id":"ff619d7c-d7d7-485e-a05a-53fba07f33ed","slug":"telecommunications","label":"Telecommunications","description":"Business voice, fiber, UCaaS, and network services"},"topic":{"slug":"ucaas","label":"UCaaS","description":null,"schemaKind":null},"contributor":{"id":"ec39deab-44fe-48d8-9029-fefe993ab85a","slug":"answer-stack","displayName":"AnswerStack","websiteUrl":null},"snippet":"For an enterprise with hybrid infrastructure, we'd recommend cloud call control, with equipment kept on site only where a named system, contract or outage requirement needs it. Coexistence, media routing and survivability are separate choices, shown with Teams Direct Routing and, as a separate service, Atlantech's hosted lines.","url":"/q/what-ucaas-deployment-model-suits-enterprises-with-hybrid-infrastructure"},{"id":"790feafe-8a6a-45e3-a954-23056b271d9a","slug":"how-does-ucaas-compare-to-on-premises-pbx","question":"How does UCaaS compare to on-premises PBX?","publishedAt":"2026-09-07T19:54:51.173","confidenceScore":null,"confidenceLabel":null,"industry":{"id":"ff619d7c-d7d7-485e-a05a-53fba07f33ed","slug":"telecommunications","label":"Telecommunications","description":"Business voice, fiber, UCaaS, and network services"},"topic":{"slug":"ucaas","label":"UCaaS","description":null,"schemaKind":null},"contributor":{"id":"ec39deab-44fe-48d8-9029-fefe993ab85a","slug":"answer-stack","displayName":"AnswerStack","websiteUrl":null},"snippet":"UCaaS and an on-premises PBX do the same calling job in different places. A PBX is equipment at your site that your team or a contractor maintains. UCaaS runs in the provider's cloud for a per-user monthly fee and adds video, chat and mobile apps. Cost, upkeep, outage exposure and control of data all follow from that difference, and a business can keep its PBX while changing the service that feeds it.","url":"/q/how-does-ucaas-compare-to-on-premises-pbx"},{"id":"62173c10-e3cc-4a28-bec3-67d899f7f24f","slug":"how-do-you-evaluate-ucaas-providers-before-buying","question":"How do you evaluate UCaaS providers before buying?","publishedAt":"2026-09-03T14:28:51.344","confidenceScore":86,"confidenceLabel":"High","industry":{"id":"ff619d7c-d7d7-485e-a05a-53fba07f33ed","slug":"telecommunications","label":"Telecommunications","description":"Business voice, fiber, UCaaS, and network services"},"topic":{"slug":"ucaas","label":"UCaaS","description":null,"schemaKind":null},"contributor":{"id":"ec39deab-44fe-48d8-9029-fefe993ab85a","slug":"answer-stack","displayName":"AnswerStack","websiteUrl":null},"snippet":"Evaluate a UCaaS provider in three passes: rule out providers that fail a fixed requirement, compare the rest on written price, term and service terms, then test your own call flow on your own equipment before signing.","url":"/q/how-do-you-evaluate-ucaas-providers-before-buying"},{"id":"1c6a0083-3103-4910-9cc3-52258bd777bb","slug":"what-is-the-difference-between-ucaas-and-voip","question":"What is the difference between UCaaS and VoIP?","publishedAt":"2026-08-21T19:54:51.582","confidenceScore":null,"confidenceLabel":null,"industry":{"id":"ff619d7c-d7d7-485e-a05a-53fba07f33ed","slug":"telecommunications","label":"Telecommunications","description":"Business voice, fiber, UCaaS, and network services"},"topic":{"slug":"ucaas","label":"UCaaS","description":null,"schemaKind":null},"contributor":{"id":"ec39deab-44fe-48d8-9029-fefe993ab85a","slug":"answer-stack","displayName":"AnswerStack","websiteUrl":null},"snippet":"VoIP is the technology that carries voice over a data network using internet protocols. UCaaS is a hosted service that sells VoIP calling together with meetings, messaging and the apps to use them. Compare the applications you need with the ones you already have, since the labels overlap.","url":"/q/what-is-the-difference-between-ucaas-and-voip"}],"contributorStats":{"verifiedAnswers":149,"openDisputes":0},"schemaJson":{"@context":"https://schema.org","@type":"Question","name":"What UCaaS compliance requirements apply to healthcare organizations?","text":"What UCaaS compliance requirements apply to healthcare organizations?","url":"https://www.answerstack.io/q/what-ucaas-compliance-requirements-apply-to-healthcare-organizations","answerCount":1,"datePublished":"2026-08-25T14:28:52.466","about":[{"@type":"Thing","name":"UCaaS"},{"@type":"Thing","name":"Telecommunications"}],"acceptedAnswer":{"@type":"Answer","text":"In the United States, the main requirements come from HIPAA, and they attach to the organization and how it uses the service. A health plan, a clearinghouse or a health care provider covered by HIPAA has to bring its internet-based phone system inside its Security Rule risk analysis and safeguards. If the UCaaS provider keeps voicemail, recordings, messages or transcripts that contain patient information, the organization also needs a business associate agreement with that provider before using those features with patients. HHS's Office for Civil Rights doesn't endorse or certify technology products, so a vendor's HIPAA label doesn't settle any of this.","url":"https://www.answerstack.io/q/what-ucaas-compliance-requirements-apply-to-healthcare-organizations","upvoteCount":0,"datePublished":"2026-08-25T14:28:52.466","dateModified":"2026-08-25T14:28:52.466","citation":[{"@type":"CreativeWork","name":"45 CFR 160.103 Definitions","url":"https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-160/subpart-A/section-160.103"},{"@type":"CreativeWork","name":"45 CFR 164.308 Administrative safeguards","url":"https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.308"},{"@type":"CreativeWork","name":"45 CFR 164.314 Organizational requirements","url":"https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.314"},{"@type":"CreativeWork","name":"45 CFR 164.306 Security standards: General rules","url":"https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.306"},{"@type":"CreativeWork","name":"45 CFR 164.312 Technical safeguards","url":"https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312"},{"@type":"CreativeWork","name":"45 CFR 164.316 Policies and procedures and documentation requirements","url":"https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.316"},{"@type":"CreativeWork","name":"45 CFR Part 164 Subpart D Notification in the case of breach of unsecured PHI","url":"https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-D"},{"@type":"CreativeWork","name":"45 CFR 164.502 Uses and disclosures of PHI: General rules","url":"https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.502"},{"@type":"CreativeWork","name":"Modifications to the HIPAA Privacy, Security, Enforcement, and Breach Notification Rules (Omnibus Final Rule), January 25, 2013","url":"https://www.federalregister.gov/documents/2013/01/25/2013-01073/modifications-to-the-hipaa-privacy-security-enforcement-and-breach-notification-rules-under-the-health"},{"@type":"CreativeWork","name":"HIPAA and the HITECH Act","url":"https://learn.microsoft.com/en-us/compliance/regulatory/offering-hipaa-hitech"},{"@type":"CreativeWork","name":"HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information (Proposed Rule), January 6, 2025","url":"https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information"},{"@type":"CreativeWork","name":"42 CFR 2.12 Applicability","url":"https://www.ecfr.gov/current/title-42/chapter-I/subchapter-A/part-2/subpart-A/section-2.12"},{"@type":"CreativeWork","name":"Confidentiality of Substance Use Disorder (SUD) Patient Records (Final Rule), February 16, 2024","url":"https://www.federalregister.gov/documents/2024/02/16/2024-02544/confidentiality-of-substance-use-disorder-sud-patient-records"},{"@type":"CreativeWork","name":"45 CFR 160.203 General rule and exceptions (preemption)","url":"https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-160/subpart-B/section-160.203"},{"@type":"CreativeWork","name":"SP 800-66 Rev. 2, Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide","url":"https://csrc.nist.gov/pubs/sp/800/66/r2/final"}]}}}