What Happens to Your WhatsApp Data When You Use 360SMS? A GDPR and Data Residency Audit

Your legal team did not ask about your messaging vendor last year. They are asking now. Across enterprise Salesforce orgs in Germany, the UK, and the UAE, procurement and legal teams that once rubber-stamped SaaS renewals are now issuing detailed data processing questionnaires to every vendor whose software touches customer communication data. Your 360SMS renewal may be the first time anyone in your organisation has formally asked: where do our customer WhatsApp conversations actually go before they appear in Salesforce?

The answer is not what most RevOps and Salesforce Admin teams expect. The assumption — reasonable but incorrect — is that because 360SMS is a Salesforce AppExchange app, the data stays inside Salesforce. AppExchange listing does not imply native architecture. The vast majority of messaging apps on AppExchange, including connector-model platforms, route inbound message webhooks through their own server infrastructure before writing them into your org. That routing makes them a data processor under EU and UK GDPR — with specific legal obligations that you, as the data controller, are required to enforce.

This post explains exactly how that architecture works, what GDPR Article 4(8) means for your vendor relationship, what native Salesforce architecture looks like as an alternative, and five questions you should put to any messaging vendor before signing or renewing a contract. If you are already evaluating ConnectVogue as a 360SMS alternative, the architectural comparison in sections three and four will give you the technical foundation to make that case to your legal and IT teams.

When a prospect or customer sends a WhatsApp message to your business number, that message originates on Meta's infrastructure and must be delivered to your Salesforce org. There are two architectural paths this delivery can take. Understanding which path your current platform uses is now a mandatory question in every enterprise vendor review.

Path one — middleware architecture — is how most connector-model messaging apps on AppExchange work. The inbound WhatsApp webhook fires from Meta to a server operated by the vendor (in 360SMS's case, their own cloud infrastructure). That server receives the full payload: the sender's phone number, the message text, any media attachments, and all associated conversation metadata. The vendor's server parses the payload, optionally applies processing logic (AI summarisation, logging, routing rules), and then forwards the processed data to your Salesforce org via the standard Salesforce API. During every step of that process — ingestion, parsing, processing, forwarding — your customer's conversation content is in the vendor's custody.

Path two — native Salesforce architecture — is how ConnectVogue works. The inbound WhatsApp webhook from Meta fires directly to a Salesforce Site endpoint that lives inside your org's trust boundary. Salesforce receives the raw webhook payload and our Apex code, deployed as a managed package inside your org, processes it entirely within Salesforce's infrastructure. No message content ever reaches ConnectVogue's servers. The vendor is out of the message flow entirely.

The practical difference between these two paths is not a performance question — both deliver messages reliably. It is a data custody question. In the middleware path, there is a third party — the vendor — who receives, holds, and processes your customer's conversation content as a routine part of their service. GDPR has a specific legal category for this relationship.

GDPR Article 4(8) defines a data processor as 'a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller.' The three-part test is straightforward: does the vendor (1) process personal data, (2) on behalf of the data controller, (3) under the controller's instructions? For any messaging platform that routes inbound WhatsApp webhooks through its own servers, the answer to all three questions is yes. Phone numbers and message content are personal data. The processing occurs because you, the controller, deployed the platform. The vendor follows your configuration instructions.

The legal consequence is immediate and non-negotiable: under GDPR Article 28, you must have a signed Data Processing Agreement with any data processor before they process personal data on your behalf. A DPA is not a privacy policy or a terms-of-service addendum — it is a specific contract governing the nature of the processing, the categories of personal data processed, the technical and organisational security measures in place, the vendor's subprocessor list, and the mechanism for data subject rights requests. If your 360SMS contract does not include a current, signed DPA that explicitly covers WhatsApp message content, you have a GDPR compliance gap.

Beyond the DPA itself, GDPR Article 28(3) requires that your processor only engages subprocessors with your prior specific or general written authorisation, and that those subprocessors are bound by the same data protection obligations as the primary processor. This means you are entitled — and legally required — to know which cloud providers, AI services, and infrastructure partners handle your customer conversation data within 360SMS's stack. Requesting the subprocessor list at renewal is not hostile procurement behaviour; it is a legal obligation on your side as the data controller.

For Salesforce orgs operating in Germany, Article 44–49 of GDPR adds international transfer requirements. If 360SMS or any of its subprocessors is located outside the EU/EEA (including the US), a valid transfer mechanism — Standard Contractual Clauses, adequacy decision, or Binding Corporate Rules — must be in place and documented. German enterprise legal teams and Datenschutzbeauftragter (Data Protection Officers) are increasingly conducting transfer impact assessments on US-hosted SaaS vendors as a routine part of the annual vendor review process.

The phrase 'native Salesforce' appears in the marketing copy of many messaging apps. It rarely means the same thing. In the strictest sense, a 100% native Salesforce application is a managed package deployed entirely within your org — no external servers, no outbound API calls to vendor infrastructure for message processing, no vendor access to message content. The distinction matters enormously for data residency and GDPR Article 25 compliance.

ConnectVogue's architecture satisfies this definition. Inbound WhatsApp webhooks fire to a Salesforce Site endpoint hosted within your org. All processing — webhook parsing, conversation record creation, AI summarisation, lead scoring — is executed by Apex classes deployed in your managed package. The only outbound API calls your org makes are to Meta's WhatsApp Cloud API (for sending messages), to Twilio (for SMS), and to your chosen AI provider (using your own API key stored in your Named Credentials). ConnectVogue's infrastructure is not in any of those flows.

The GDPR implication of this architecture: ConnectVogue is not a data processor under Article 4(8) for your message content. There is no DPA required between you and ConnectVogue for WhatsApp conversation data, because ConnectVogue never receives or processes it. Your existing Salesforce agreement — which already includes a DPA covering data stored and processed within Salesforce infrastructure — extends to cover your message data. Salesforce's infrastructure certifications (ISO 27001, SOC 1/2/3, CSA STAR, GDPR adequacy mechanisms for EU customers) and data centre regions (Frankfurt for German orgs, Dublin for UK/EU orgs) already govern your data residency posture.

For US-headquartered companies with Salesforce orgs in specific data residency configurations, the same logic applies — conversation data stays within the data residency boundary you have already established with Salesforce. For HIPAA-covered entities in healthcare sales and services, the native architecture means your Business Associate Agreement with Salesforce already covers your WhatsApp conversation data. There is no additional BAA negotiation with the messaging vendor.

GDPR Article 25 mandates data protection by design and by default. Native Salesforce architecture satisfies Article 25 structurally. There is no external processing to configure away, no privacy setting to enable, no vendor server to audit. The data protection is built into the architecture itself — the webhook never leaves Salesforce's trust boundary.

These five questions should be sent to any messaging vendor before contract signature or renewal. They are structured to elicit architectural disclosure, not marketing language. Share them with your legal, IT security, and procurement teams as a standard vendor questionnaire.

Question one: Does any inbound WhatsApp or SMS message content pass through your infrastructure before reaching our Salesforce org? This is the architectural binary. A yes answer means the vendor is a data processor and a DPA is required. A native Salesforce architecture produces a no. Any hedged answer — 'we use Salesforce-connected infrastructure', 'we have secure transit' — should be followed with: 'Can you provide a data flow diagram showing the complete path of an inbound message from Meta to our Salesforce org?'

Question two: Are you a data processor under GDPR Article 4(8) for our WhatsApp message content? Many vendor sales teams have not been asked this directly. A vendor with a middleware architecture should answer yes and provide their DPA. A vendor claiming not to be a data processor while routing messages through their servers is making a claim your legal team should verify against their architecture documentation.

Question three: Can you provide a current list of all subprocessors who may access our message content? Under GDPR Article 28(3)(d), your processor must provide this. The subprocessor list reveals the AI providers, cloud infrastructure vendors, and support tooling that may handle your data. An AI summarisation feature powered by an undisclosed third-party model means your message data flows to that model's infrastructure — another data processor relationship requiring DPA coverage.

Question four: Where are your servers geographically located and what is your data retention policy for message content that passes through your platform? This question addresses the international transfer requirement and the risk of persistent vendor-side retention. Some middleware platforms log message content for support, debugging, or AI training purposes beyond the time required for Salesforce delivery. Your DPA should specify retention limits explicitly.

Question five: In the event of a data breach involving customer WhatsApp message content, what is your notification timeline and process? Under GDPR Article 33, you as the data controller must notify your supervisory authority within 72 hours of becoming aware of a breach. Your processor must notify you 'without undue delay'. A vendor without a documented breach notification process is a vendor whose DPA terms your legal team should review carefully.

You do not need a legal team or an external auditor to run a first-pass compliance audit on your current messaging platform. These four steps take under 30 minutes and will tell you whether you have a structural GDPR exposure that needs remediation before your next renewal or audit cycle.

Step one: find your current vendor's architecture documentation. Look for a data flow diagram, a security whitepaper, or an architecture overview in their help centre or trust portal. Search specifically for language about how inbound webhooks are processed. If you cannot find documentation that explicitly states inbound message content is processed entirely within your Salesforce org — you have a middleware architecture. Absence of documentation is not a good sign.

Step two: locate your signed DPA. Check your original contract, your vendor's self-service DPA portal, or your procurement records. If you cannot locate a signed DPA — or if the DPA predates your WhatsApp integration — you have a gap. Request a current DPA from your vendor account manager immediately. Do not wait for renewal.

Step three: request the subprocessor list. Most enterprise SaaS vendors now maintain a public or customer-accessible subprocessor list. For 360SMS, check their trust or legal documentation pages. Cross-reference against your organisation's approved vendor list and your data residency requirements. Pay particular attention to AI processing subprocessors — these are frequently added or changed as platforms roll out AI features.

Step four: check your data transfer mechanisms. If any subprocessor is located in the US or another non-adequacy country, confirm that Standard Contractual Clauses are in place between your processor and that subprocessor. This is a clause you should find in the DPA itself. If the DPA does not address international transfers, or references mechanisms that are now invalid (Privacy Shield was invalidated in 2020), your compliance posture has a live vulnerability.

If this audit surfaces gaps, you have two options: remediate within your current vendor relationship by negotiating an updated DPA and requesting architectural documentation, or evaluate a native Salesforce architecture that removes the vendor from the data processing chain entirely. The 30-day parallel install described in the 360SMS alternative guide gives you a risk-free path to evaluate both options simultaneously before committing to either.