Data Processing Agreement

The Mumara Data Processing Agreement (the "DPA") supplements our Terms of Service for any customer ("Member") who is subject to the EU GDPR, UK GDPR, Swiss revFADP, or any similar data-protection law and needs a written contract documenting Mumara's role as a data processor.

This page explains what is in our DPA, when you need one, how to put it in place, and how it interacts with the Standard Contractual Clauses ("SCCs"). The operative document is the standard Mumara DPA we will execute with you on request; the summary below is for informational purposes and does not itself create binding terms.

1. Who needs a DPA?

Most Mumara Members are data controllers under the GDPR. When you upload subscriber lists, Contact records, or any personal data into Mumara, we process that data on your behalf — we are your processor and you are the controller. The DPA is the written contract that documents that relationship and the safeguards we apply, as required by Article 28 GDPR (and the equivalent in the UK GDPR and revFADP).

You should have a signed DPA on file with Mumara if you are:

• An EU/EEA, UK, or Swiss organization processing personal data through Mumara.
• An organization anywhere in the world that processes EU/EEA, UK, or Swiss personal data.
• A data processor whose own customers ask you to flow processor obligations down to your sub-processors (Mumara is your sub-processor).
• An organization in a jurisdiction with similar data-protection law (e.g. Brazil's LGPD, Switzerland's revFADP).

2. Roles, subject matter, and duration

• Member — data controller (or processor where Mumara is your sub-processor).
• Mumara — data processor (or sub-processor where the Member is itself a processor).
• Subject matter — the processing of personal data necessary to provide the Mumara Services to the Member.
• Duration — for as long as the Mumara Subscription is active, plus any post-termination period required to return or delete the data.
• Nature and purpose — to host, transmit, store, segment, and send the Member's email or SMS communications, including ancillary processing for delivery, suppression, and reporting.

3. Categories of data subjects and personal data

The Member determines the specific categories. Typical categories the Mumara DPA covers include:

• Data subjects — the Member's subscribers, contacts, recipients, and end-users.
• Identifiers — name, email address, phone number, account/customer ID.
• Profile attributes — job title, employer, location, custom fields the Member chooses.
• Consent records — opt-in source, timestamp, IP, consent text shown.
• Engagement events — opens, clicks, replies, conversions, bounces, complaints, unsubscribes.
• Operational metadata — delivery dispositions, suppression-list state, recipient IP and ASN where known.

The DPA does not by default cover Article 9 special-category data. Members must not upload special-category data without a separate written arrangement that addresses Article 9.

4. Member instructions

Mumara processes personal data only on the Member's documented instructions. Those instructions are:

• The Terms, this DPA, and the Member's plan configuration in the product.
• The Member's actions in the product (uploading lists, scheduling campaigns, configuring automations).
• Any further written instructions the Member provides via support tickets or contractually.

Mumara will tell the Member if an instruction infringes data-protection law. Mumara will not process personal data for any other purpose, except where required by EU or Member-State law, in which case we will inform the Member where allowed.

5. Confidentiality of personnel

Mumara ensures that personnel authorized to process personal data are bound by appropriate confidentiality obligations (in their employment terms or by separate written commitment). Access is granted on a need-to-know basis with role-based controls and is revoked when no longer needed.

6. Security measures (Article 32)

Mumara implements appropriate technical and organisational measures to ensure a level of security appropriate to the risk. Detailed measures are set out in the DPA's Annex / Schedule and include:

• Encryption in transit (TLS 1.2+) and at rest for production stores and backups.
• Hashed and salted passwords; multi-factor authentication available.
• Role-based access control with least-privilege defaults.
• Centralised audit logging with anomaly detection.
• Secure software development lifecycle with peer-reviewed change management.
• Vulnerability management and dependency scanning.
• Network segregation between production and non-production.
• Disaster-recovery and business-continuity plans, with periodic exercises.
• Incident-response plan covering detection, containment, eradication, recovery, and post-incident review.
• Background screening proportionate to role.
• Vendor security review for new sub-processors before they handle personal data.

The full security overview is available to Members under NDA on request.

7. Sub-processors

7.1 Authorisation model

Mumara uses the "general written authorisation" model permitted by Article 28(2) GDPR. By executing the DPA, the Member authorises Mumara to engage the sub-processors listed at /legal/sub-processors/ at the time of execution and additional sub-processors that Mumara adds in line with this Section.

7.2 Notification of changes

Mumara notifies Members of additions, removals, or material scope changes to the sub-processor list at least 30 days in advance (typically by email to the primary account contact and via an in-product notification).

7.3 Objection

A Member may object 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. If no alternative is workable, the Member may terminate the affected Subscription as the sole remedy, with a pro-rated refund of pre-paid fees attributable to the unused remainder of the term.

7.4 Sub-processor obligations

Each sub-processor signs a written agreement that imposes data-protection obligations no less protective than this DPA, including the SCCs where the transfer leaves the EEA. Mumara remains fully liable to the Member for the sub-processor's performance.

8. Data-subject-request assistance

Mumara provides the Member with the tools and information reasonably necessary to respond to data-subject requests under Articles 12–22 GDPR. Specifically:

• The product allows the Member to access, export, correct, and delete Contact records and engagement data.
• Mumara forwards data-subject requests we receive directly without responding substantively, except as needed to acknowledge receipt and tell the data subject to contact the controller.
• Where the Member needs additional assistance (e.g. data we hold in support tickets or backups), Mumara will provide that assistance taking account of the nature of the processing, at the reasonable cost of compliance.

9. Personal-data breach notification

Mumara notifies the Member without undue delay after becoming aware of a personal-data breach affecting the Member's data, with the information required by Article 33(3) GDPR — the nature of the breach, categories and approximate number of data subjects and records, likely consequences, and measures taken or proposed. We provide updates as more information becomes available.

Notifications go to the primary account contact email and (where possible) the in-product notification system. Members are responsible for keeping that contact information current.

10. Cross-border transfers and SCCs

Where personal data is transferred outside the EEA / UK / Switzerland to a country without an adequacy decision, Mumara relies on:

• The 2021 EU Standard Contractual Clauses, with the appropriate module:
  • Module Two — Member is controller, Mumara is processor.
  • Module Three — Member is processor, Mumara is sub-processor.
• The UK ICO addendum to the SCCs (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.
• Adequacy decisions where they exist.

The DPA pre-incorporates these instruments by reference so they take effect automatically when a covered transfer occurs. We perform a Transfer Impact Assessment for each non-adequate destination (see GDPR §11) and apply supplementary measures where required.

11. Return or deletion of data

On termination of the Mumara Subscription, the Member can choose:

• To export Customer Data using the export tools we provide, typically within 30 days of termination; or
• To request deletion of Customer Data, which we perform within the timeframe set in the DPA (typically within 30 days of the Member's request after the export window).

Some data is retained beyond these periods where required by applicable law (for example, accounting and tax records, abuse-investigation records). Deleted data may persist briefly on backup tapes or replicas during the natural rotation cycle and is purged when those rotations complete.

12. How to execute the DPA

Email /contact/ with subject line "DPA request" and include:

• The legal name of your company (the data controller, or your role if you are a processor).
• Your country of incorporation.
• The Mumara products you use or plan to use (Mumara ONE, Mumara Campaigns, Mumara Machine, Mumara SMS, Mumara SMS+, Mumara AI tier).
• Approximate volume / scale of data you'll process (rough order of magnitude is fine).

We send our standard DPA pre-signed by Mumara within one business day. Counter-sign and return; we file a copy and confirm receipt. The DPA is a self-contained agreement and does not require renegotiating the underlying Terms.

13. Audit rights

The DPA grants the Member the right to verify compliance, balanced against the need to protect the security of the platform and the privacy of other Members. Audit options include:

• Reviewing this page, our Privacy Policy, our GDPR page, and our published documentation.
• Receiving our security overview and other material under NDA on request.
• Submitting a written audit questionnaire — Mumara responds within a reasonable time.
• For enterprise customers under contract, an on-site or remote audit per the DPA's audit clause, with reasonable notice and at the Member's cost.

Audits cannot disclose information about other Members or compromise platform security. Independent third-party reports (e.g. SOC 2 where available) may satisfy audit requests where they meaningfully cover the questions asked. Audit frequency is once per 12 months unless a supervisory authority requires more, or unless a personal-data breach reasonably justifies a follow-up audit.

14. Liability

The DPA's liability provisions defer to the limitation-of-liability section in the Terms of Service. The SCCs themselves contain standalone liability provisions that apply to claims by data subjects and supervisory authorities — those are not capped by the Terms.

15. Custom DPAs and enterprise

Enterprise customers with specific requirements — custom data residency, additional security addenda, sector-specific clauses for healthcare, finance, or government — can negotiate a tailored DPA as part of an enterprise agreement. See Mumara Enterprise or contact us via /contact/ with subject line "Enterprise DPA".

16. Order of precedence

If there is a conflict between documents on data-protection topics, the order of precedence is: (1) any signed enterprise agreement, (2) the executed DPA (including the incorporated SCCs), (3) the Terms of Service, (4) the Acceptable Use Policy, (5) the Privacy Policy. The SCCs themselves take precedence over the rest of the DPA where they specifically apply.

17. Updates

We update the standard DPA when the law changes (e.g. new Standard Contractual Clauses or Schrems-related guidance) or when our processing changes. Material changes are notified to Members with executed DPAs. The "Last updated" date at the top of this page reflects when this summary was last revised.

18. Contact

Questions about the DPA — process, content, or status of your request? Contact /contact/ with subject line "DPA". For enterprise data-residency requirements or custom DPAs, mark "Enterprise DPA".