RCS HIPAA Discussions: A Practitioner’s Decision Guide

Written by: Matt Beucler, CEO, Plura AI

Updated September 2026

RCS (Rich Communication Services) is not HIPAA (Health Insurance Portability and Accountability Act) compliant by default. Three structural gaps drive that outcome: carriers and consumer messaging platforms do not sign a BAA (Business Associate Agreement), RCS encryption is not universally active across all carrier endpoints, and message data can be retained outside the covered entity’s control.

Key Takeaways

• RCS is not HIPAA compliant by default.
• No BAA is available from carriers or consumer messaging platforms.
• Business RCS on U.S. carriers does not provide end-to-end encryption.
• Message data can be retained on third-party servers outside the covered entity’s control.
• Healthcare organizations can use Plura AI to route PHI to secure channels while using RCS for non-PHI engagement.

Reason 1: No Business Associate Agreement (BAA)

A BAA is a contract between a covered entity and a business associate that governs the handling of PHI (protected health information). Under 45 CFR Parts 160, 162, and 164, any vendor that creates, receives, maintains, or transmits PHI on behalf of a covered entity is a business associate and must execute a BAA before PHI is disclosed to them². Standard telecommunication carriers and consumer messaging platforms do not sign BAAs because they do not position themselves as business associates under HIPAA. Google’s RCS Business Messaging (RBM) data-security documentation states plainly that RBM is not compliant with HIPAA. Without a BAA, disclosing PHI through RCS falls outside the conditions described at 45 CFR 164.502(e), which ties disclosure to a vendor on satisfactory assurances documented in a written agreement. Consult qualified counsel for legal interpretation specific to your organization.

Reason 2: Encryption Gaps Across Carrier Endpoints

RCS offers better transit security than legacy SMS, but full end-to-end encryption (E2EE) is not universally guaranteed or active across all carrier endpoints. Google’s RBM documentation states that RBM does not offer end-to-end encryption. Instead, RBM uses point-to-point encryption between user devices and Google’s servers, and between Google’s servers and messaging partners. For business (A2P) RCS, SimplyRCS’s RCS Support Tracker confirms that business RCS is not end-to-end encrypted on any U.S. carrier as of August 2026. Apple announced in May 2026 that E2EE for personal RCS began rolling out in beta with iOS 26.5, and that feature applies only to person-to-person (P2P) conversations on supported carriers and remains in beta. RCS transit encryption does not close the gap, because HIPAA’s technical safeguards also reference audit trails and access controls.

Reason 3: Data Retention Outside Covered Entity Control

Google’s RBM documentation states that agent-to-person messages are held on Google servers for up to 30 days if undelivered, and that media files in delivered messages are stored for 60 days. Messages stored on Google’s servers are encrypted at rest, but the keys are managed by Google, not the covered entity. Additionally, Google may ephemerally process message content to detect and prevent spam and abuse. This arrangement keeps message data and keys outside an organization’s direct compliance control. That condition interacts with the access control and audit concepts described in 45 CFR Part 164.

See how RCS HIPAA discussions translate into an operational messaging architecture for your healthcare organization.

Message-by-Message Classification: RCS-Safe vs Secure-Channel Content

No competitor in this space provides a working classification table for healthcare RCS use cases. The core rule is simple. Messages that contain no PHI can travel over RCS. Messages that contain PHI require an authenticated patient portal or a purpose-built HIPAA-aligned messaging platform. Google’s RBM documentation explicitly supports non-PHI healthcare use cases such as appointment reminders and notifications with links to a secure patient portal, while prohibiting messages containing PHI. The table below sorts common message types by which side of that boundary they fall on.

Safe for RCS	Requires a Secure Channel
Appointment reminders containing time and date only	Diagnoses
General wellness tips	Test results
Billing alerts with secure payment links	Medication details
Feedback surveys	Treatment plans

The classification logic follows the PHI boundary. A message containing only an appointment date and time, with no patient name, provider name, location, or condition, contains no PHI. A message that says “Your follow-up for your diabetes management is Thursday at 2 PM with Dr. Chen” contains PHI: it links the patient’s identity to a condition and a provider. FRANSiS’s HIPAA two-way SMS guidance, last updated August 2026, identifies safe content as appointment date, time, location, and generic prep instructions, while classifying specific medication names, lab result values, diagnoses, and detailed clinical notes as content that requires a secure channel. The same boundary applies to RCS. When uncertainty exists, route the message to a secure portal and send only a neutral prompt over RCS.

The BAA Gap in Practical Terms

A BAA is a written contract between a covered entity and a business associate that governs how PHI is used, protected, and disclosed. The framework for what a BAA must contain is described at 45 CFR 164.504(e)(2), and where electronic PHI (ePHI) is involved, the Security Rule provisions at 45 CFR 164.308(b)(3) and 164.314(a) also apply.

Carriers and consumer messaging platforms generally do not sign BAAs, consistent with their role as message-transport providers rather than healthcare data managers. HHS’s HIPAA guidance and the regulatory framework at 45 CFR 164.502(e) condition disclosure of PHI to a vendor on satisfactory assurances documented in a written agreement. Without that agreement, the disclosure falls outside the permitted conditions described in the rule.

For a covered entity evaluating an RCS pilot, the BAA gap means that any vendor in the message delivery chain that touches PHI needs evaluation for BAA availability. CallHub’s 2026 HIPAA compliance checklist notes that an HHS-compliant BAA must include permitted uses and disclosures, required safeguards, breach notification obligations, and requirements ensuring the vendor’s subcontractors sign equivalent BAAs. Consult qualified counsel to evaluate whether a specific vendor’s BAA satisfies the requirements applicable to your organization.

Encryption Reality: What RCS Does and Does Not Protect

RCS improves transit security compared with legacy SMS. Google’s RBM API supports TLS 1.3 with AES 256 and SHA384 ciphers for developer access, and messages are encrypted across Google’s network. Full E2EE standards are still not universally guaranteed or active across all carrier endpoints.

This distinction matters for healthcare operators. SimplyRCS’s RCS Support Tracker, reviewed August 27, 2026, confirms that business (A2P/RBM) RCS is encrypted in transit via TLS but is not end-to-end encrypted on any U.S. carrier. Transit encryption means the middle platform can still process message content for delivery, analytics, or fallback. FRANSiS’s August 2026 guide on encrypted text messaging states: “RCS can be end-to-end encrypted in specific app-to-app configurations, but no organization should assume a message it sends will travel encrypted end to end, because delivery paths and fallback behavior are outside the sender’s control.”

Transit encryption alone does not satisfy HIPAA’s technical safeguards. The Security Rule framework at 45 CFR Part 164 also references robust audit trails and strict access controls, neither of which RCS provides natively. The 2026 HIPAA Security Rule update, finalized in January 2025, eliminates the addressable vs. required distinction that had existed since 2003. Every listed safeguard is now mandatory, including encryption of all ePHI in transit and at rest.

Hybrid Architecture: RCS Front Door, Secure PHI Channels

Healthcare operators can pair RCS engagement with HIPAA-aligned messaging by separating non-PHI outreach from PHI exchange. A hybrid architecture uses RCS for non-PHI front-door communications while routing PHI behind an authenticated patient portal or a purpose-built HIPAA-aligned messaging platform.

The front door layer handles:

• Appointment reminders containing time and date only
• General wellness tips
• Billing alerts with secure payment links
• Feedback surveys
• Neutral prompts directing patients to a secure portal (for example, “You have a message from your care team. Log in to view it.”)

The secure channel layer handles:

• Diagnoses and test results
• Medication details and treatment plans
• Any content that links a patient’s identity to a clinical detail

Enabld’s July 2026 healthcare messaging guide frames compliant architecture as one where “the text nudges and the sensitive detail stays behind login in the app, patient portal, or in-app inbox.” The platform-layer controls that matter in the secure channel are encryption in transit and at rest, role-based access controls, immutable audit logs recording who sent what to whom and when, and documented retention and deletion policies.

Operators using Plura AI for RCS outreach can route non-PHI appointment reminders and wellness messages over RCS while connecting patients to authenticated portals for clinical content. Plura’s no-code workflow builder supports this routing logic without engineering overhead, and the platform’s HIPAA-aligned encryption and audit logging apply across voice, SMS, RCS, and webchat. Plura documents up to 40% improvement in no-shows using its outreach infrastructure.³

How to Evaluate a Messaging Platform for Healthcare

Healthcare operators evaluating a messaging platform for RCS HIPAA discussions can apply a consistent checklist before any PHI-adjacent deployment. The checklist below reflects the technical safeguard concepts described in 45 CFR Part 164 and the vendor evaluation criteria published in multiple 2026 compliance guides.

¹

• Encryption in transit and at rest: Confirm the platform encrypts ePHI using current standards for both transmission and storage. Without this, no other control compensates.
• Access controls: Require role-based access and multi-factor authentication (MFA) for every user with ePHI access. Encryption protects data in motion; access controls determine who can reach it once it lands.
• Audit logging: Capture immutable records of who sent what to whom and when, exportable for compliance review. These logs connect user access back to specific messages.
• Retention policies: Document how long messages are kept and how they are securely deleted. Retention rules should align with your broader records-management strategy.
• BAA availability: Confirm the vendor is willing to sign a BAA before any PHI is handled. The BAA should match the safeguards you expect in practice.
• DNC and consent management: Use real-time Do Not Call (DNC) scrubbing and immutable consent records on every outbound contact. These controls keep outreach aligned with consent and preference records.

Plura AI is an FCC-licensed platform of AI agents running voice, SMS, RCS, and AI webchat on 100% U.S. infrastructure. Plura’s compliance engine applies HIPAA-aligned encryption and audit logging across all four channels. It also handles real-time DNC scrubbing, automated quiet-hours enforcement, and immutable consent logging on every outbound contact. Customers remain responsible for their own compliance obligations. Plura also supports AI SMS for lead qualification and outreach, and AI customer service texting for CRM-connected support workflows. The platform’s conversation intelligence layer surfaces audit-ready reporting across every channel.

Walk through how Plura’s compliance layer applies to your RCS and SMS healthcare messaging workflows.

Compare plans and rates side by side on the Plura pricing page.

Frequently Asked Questions

Is RCS Texting HIPAA Compliant?

RCS is not HIPAA compliant by default. The three structural reasons described above are the BAA gap, inconsistent encryption, and data retention outside covered entity control. Google’s RBM documentation states that RBM is not compliant with HIPAA.

Is RCS Messaging Monitored?

RCS messages are processed by carriers and messaging platforms for delivery, analytics, and fallback. Google’s RCS Business Messaging documentation states that Google may ephemerally process message content to detect and prevent spam and abuse, and may use those signals to train AI models to improve spam prevention and detection. Businesses cannot control the encryption keys used for RBM messages.

What Can You Send Over RCS Without Raising HIPAA Concerns?

Appointment reminders containing time and date only, general wellness tips, billing alerts with secure payment links, and feedback surveys can travel over RCS without including PHI. Diagnoses, test results, medication details, and treatment plans contain PHI and require a secure channel such as an authenticated patient portal or a purpose-built HIPAA-aligned messaging platform. Consult qualified counsel to evaluate the specific content of your messaging templates.

Does RCS Need a Business Associate Agreement?

Carriers and consumer messaging platforms do not sign BAAs. Without a BAA, disclosing PHI through RCS falls outside the conditions described at 45 CFR 164.502(e), which ties disclosure to a vendor on satisfactory assurances documented in a written agreement. If a messaging workflow involves PHI, consult counsel regarding BAA requirements for the vendors handling that PHI.

Is RCS End-to-End Encrypted?

RCS encryption is not universally active across all carrier endpoints. For business (A2P) RCS, no U.S. carrier offers end-to-end encryption as of August 2026. Personal (P2P) RCS end-to-end encryption began rolling out in beta with iOS 26.5 in May 2026, but remains carrier-dependent and in beta. HIPAA’s technical safeguards also reference audit trails and access controls, which RCS does not provide natively.

How Do HIPAA-Compliant Texting Platforms Differ From RCS?

RCS is a messaging protocol, not a compliance layer. HIPAA-aligned texting platforms provide encryption in transit and at rest, access controls, audit logging, retention policies, and BAA availability that RCS alone does not. Many healthcare organizations use RCS for non-PHI front-door communications and route PHI to a purpose-built HIPAA-aligned platform.

Conclusion: The Compliance Layer Is the Decision

RCS is not HIPAA compliant by default. The BAA gap, the encryption fragmentation across carrier endpoints, and the data retention conditions outside a covered entity’s control are structural. Healthcare operators can use RCS for non-PHI front-door communications and route PHI to authenticated portals or HIPAA-aligned platforms. That architecture requires a compliance layer enforced at the platform level.

Plura AI provides that compliance layer across voice, SMS, RCS, and webchat. HIPAA-aligned encryption, immutable audit logging, real-time DNC scrubbing, and automated quiet-hours enforcement apply to every outbound contact, and the platform runs on 100% U.S. infrastructure. Plura supports customer compliance; customers remain responsible for their own regulatory obligations.

See the platform in action for your RCS and SMS healthcare workflows.

Compare plans and rates side by side on the Plura pricing page.

Run your numbers through Plura’s ROI calculator to check your projected return in real time.

---

Read Next

• RCS Business Messaging for Healthcare: Implementation Guide
• RCS Business Messaging Compliance: A Practitioner’s Guide
• RCS Business Messaging Best Practices: 2026 Operator’s Guide
• RCS Business Messaging vs SMS: 2026 Decision Guide
• RCS Bulk Messaging for Regulated Industries: 7-Step Workflow