Sub-processors

Mumara operates its own production infrastructure — owned servers and IPs across our own colocation and cloud — so the Mumara application that processes your campaigns and Contacts is not hosted on a third-party public cloud. We do not engage an upstream cloud-hosting sub-processor for the production application. The list below covers the third parties we engage for the marketing site, payment processing, customer support, and (where visitors opt in) marketing-site analytics.

1. Current sub-processor list

The table below is the operative sub-processor list as of the "Last updated" date at the top of this page. Each entry shows the vendor's purpose, the region in which it processes data, its role, the transfer mechanism (where data leaves the EEA / UK), and the scope of data the sub-processor may see.

2. How sub-processors are categorised

• Edge / security — keeps the public marketing site fast, available, and protected from network attacks. Sees request metadata only; does not see Customer Data that lives inside the Mumara application.
• Customer support — chat, feedback, and ticketing. Receives only the information visitors and Members send to us.
• Analytics and Marketing — used on the public marketing site only and only with the visitor's prior cookie-category consent. Does not see any Customer Data inside the Mumara application.

3. Mumara's own infrastructure

Mumara operates its production application on infrastructure we own and control. That means the servers that process your campaigns, store your Contacts, and handle sending traffic are not on a third-party public cloud. We deliberately built this way so that, for the Customer Data most of you care about, there is no upstream cloud-hosting sub-processor in the chain.

In the event of overflow capacity or disaster recovery, Mumara may engage commercially available data-center, hosting, or content-delivery providers under written contracts that impose data-protection obligations no less protective than this list and our DPA. Where such an engagement materially expands the set of vendors that handle Customer Data, we update this list and notify Members at least 30 days in advance per Section 7.

4. Payment processing

Subscription billing is handled by a PCI-DSS compliant payment-processing partner. The partner tokenises payment instruments; Mumara never sees full card numbers, CVVs, or banking credentials. The specific vendor name is available to Members on request via /contact/ with subject line "Payment processor".

5. Mumara AI processing

Mumara AI (across the Mumara AI Fast, Mumara AI, and Mumara AI Advanced tiers) is part of the Mumara service. Two commitments apply regardless of how Mumara AI is implemented under the hood:

• No training on your data — Mumara does not use your AI prompts or generated outputs to train any model that is exposed outside your account.
• No proactive forwarding — Mumara AI does not consume your full subscriber lists, behavioural data, or full campaign archives. Only the prompt content you generate (including any sample Contact you choose to merge in) is processed.

AI usage is metered for billing and abuse prevention. Mumara retains call-level metadata (timestamp, feature, credit cost, request identifier) but not the full prompt content beyond what is necessary to generate the output and to investigate any abuse complaint relating to that call.

6. Member-controlled integrations (not Mumara sub-processors)

Beyond Mumara's sub-processors, your account may also send data to other services at your direction. These are not Mumara sub-processors — you, as the data controller, choose to send data to them and you have a direct relationship with each provider. We facilitate the connection but don't sit between you and that provider once the integration is configured. Examples include:

• External sending nodes you connect as Bridges (Amazon SES, SendGrid, Mailgun, custom SMTP).
• SMS gateways (Twilio, Clickatell, Infobip) for Mumara SMS / SMS+.
• DNS providers integrated via the Auto DNS addon (Cloudflare, Route53, GoDaddy, Namecheap, etc.).
• Webhook endpoints you configure for custom event delivery.
• CRM and analytics integrations you authorize per workspace.

You are responsible for the terms and privacy notices of each Member-controlled integration you enable.

7. Notification of changes

We notify Members of any material change to the sub-processor list (adding a new sub-processor, removing one, or substantively changing scope) at least 30 days in advance, in line with our DPA. Notifications go to:

• The primary account owner email registered on the Account.
• The in-product notification system, where applicable.
• This page (the "Last updated" date is updated and the table reflects the change on the effective date).

Members can subscribe to a public feed of changes by emailing /contact/ with subject line "Sub-processor change feed".

8. Objection process

A Member may object to a new sub-processor on legitimate, documented data-protection grounds within 30 days of notification. Mumara and the Member will work in good faith to find a suitable alternative — for example, a Member-controllable workaround, a regional alternative, or a delayed roll-out. If no alternative is workable, the Member's sole remedy is to terminate the affected Subscription with a pro-rated refund of pre-paid fees attributable to the unused remainder of the term.

9. Vendor due diligence

Before engaging a sub-processor, we run a due-diligence review covering:

• Security posture (encryption, access control, audit logs, incident-response capability).
• Privacy and data-protection program (DPA terms, SCC support, sub-sub-processor management).
• Independent attestation where available (SOC 2, ISO 27001, ISO 27018, similar).
• Regulatory and sanctions compliance.
• Scope minimisation — does the vendor really need access to personal data, or can the integration be designed without it.
• Operational maturity (uptime, support tiers, breach-notification timelines).

We periodically re-review existing sub-processors and discontinue any that fall below our standards.

10. Cross-border transfers

For each sub-processor that processes EEA / UK / Swiss personal data outside its origin region, the table in Section 1 indicates the transfer mechanism we rely on. Typically:

• The 2021 EU Standard Contractual Clauses, with the appropriate module.
• The UK ICO addendum (or, where applicable, the IDTA).
• Swiss-specific provisions referencing the FDPIC and the revFADP.
• The EU-US Data Privacy Framework where the recipient is certified.

We also conduct a Transfer Impact Assessment per Schrems II and apply supplementary measures where required (encryption, access controls, contractual challenge of overbroad requests). See GDPR §11 for details.

11. Sub-processor termination

When we terminate a sub-processor, we ensure they delete or return Member personal data and confirm completion in writing. We update this page on or before the termination effective date. Where a termination is the result of a security or compliance issue, we may notify Members earlier than the standard 30-day window.

12. Contact

Questions about a specific sub-processor, want a copy of our security review on one, or want to subscribe to the change feed? Contact /contact/ with the relevant subject line ("Sub-processor inquiry", "Security review request", "Sub-processor change feed", or "Payment processor").