RCS privacy rules

Because a business message and its analytics (delivery, reads, clicks) pass through the platform and carrier infrastructure, A2P RCS is not end-to-end encrypted, which is normal and necessary for business messaging, but means brands should treat message content and contact data with the same care as any other CRM data: minimize what they collect, secure it, and disclose how it’s used.

Practical privacy duties for an RCS program: keep a clear privacy policy accessible from the call-to-action, collect only what you need, honor data-subject requests (access/delete) under applicable state laws, and don’t share data for marketing without disclosure and consent.

Data minimisation is the principle with the most concrete application in messaging, because the message body itself is a place personal data ends up by accident. A thread persists on the customer's device, may be backed up to their cloud account, and can be read by anyone who picks up an unlocked phone, none of which is under your control. That argues for putting the minimum in the message and the detail behind an authenticated link: a delivery notification that names the item is a different privacy proposition from one that says your order is arriving today, and in a healthcare or financial context that difference matters a great deal. The safe default is that the message carries the trigger and the identity, and the sensitive content lives behind authentication.

Retention deserves an explicit decision rather than a default. Consent records and the send audit trail need to be kept, since they are the evidence a compliance question turns on. Message content and engagement data usually do not need to be kept as long, and holding them indefinitely enlarges what a breach would expose and what a deletion request has to reach. Set a retention period per data type, make sure your provider can actually honour it, and confirm that deleting a contact in your CRM propagates to the messaging platform, because a suppression list that outlives a deletion request is a common and awkward gap.

Your provider is a processor of personal data, which brings the ordinary vendor obligations: a data processing agreement, clarity on where data is stored and who may access it, sub-processor disclosure, and a defined breach notification path. Ask specifically what the provider retains and for how long, and whether analytics are derived from your message content, because that answer belongs in your own privacy notice. The controls SimplyRCS operates are set out on the platform security page.

This is general information rather than legal advice; obligations vary by jurisdiction and by the kind of data involved, so take advice on your own programme.