GDPR Compliance

This page describes how Mumara complies with the European General Data Protection Regulation ("GDPR", Regulation (EU) 2016/679), the UK GDPR (Data Protection Act 2018), and the Swiss Federal Act on Data Protection. It is intended to be a complete reference for customers, prospects, regulators, and data subjects. It supplements (and where there is any inconsistency, gives way to) our Privacy Policy and our Data Processing Agreement.

Mumara has been operating since 2012. We process data on behalf of more than 21,000 businesses worldwide, many of them in the EEA and the UK; GDPR alignment is operationally embedded across engineering, support, and our commercial team — not a checkbox.

1. Scope and territorial application

The GDPR applies to the processing of personal data of data subjects in the EU/EEA, regardless of where the controller or processor is established (Article 3). Mumara's services are available globally; this page applies whenever Mumara processes personal data subject to:

• The EU GDPR (Regulation (EU) 2016/679).
• The UK GDPR and the UK Data Protection Act 2018.
• The Swiss Federal Act on Data Protection (revFADP), with appropriate adaptations.
• Member-state national laws that supplement the GDPR (e.g. BDSG in Germany, CNIL in France).

2. Definitions

The GDPR's defined terms apply throughout this page (Article 4). The most relevant are:

• Personal data — any information relating to an identified or identifiable natural person.
• Processing — any operation performed on personal data.
• Controller — the entity that determines the purposes and means of processing.
• Processor — the entity that processes personal data on behalf of the controller.
• Data subject — the individual the personal data relates to.
• Sub-processor — a third party engaged by the processor to process personal data on the controller's behalf.
• Personal-data breach — a security incident leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data.
• Special-category data — Article 9 categories (health, biometrics, racial/ethnic origin, etc.).

3. Mumara's roles: controller vs processor

3.1 Mumara as controller

Mumara is the controller for:

• Member account data (registration, profile, billing).
• Visitors to our marketing websites.
• Prospects and sales leads.
• Applicants, employees, and contractors.
• Aggregated and de-identified analytics data we generate.

3.2 Mumara as processor

Mumara is a processor for personal data that customers ("Members") upload to our products to send email or SMS — i.e. data about their subscribers, contacts, or recipients ("Contact Data"). The Member is the controller of Contact Data and determines why and how it is processed; Mumara processes it under the Member's documented instructions per the Data Processing Agreement.

3.3 Joint controllership

By default, Mumara and Members do not act as joint controllers under Article 26 GDPR. If your use case requires joint controllership (e.g. certain co-marketing arrangements), please contact us so we can put a written joint-controller arrangement in place.

4. Categories of data we process

4.1 Data Mumara processes as controller

Personal data of Members, prospects, and visitors. Categories include:

• Identifiers (name, email, phone, country, account ID).
• Authentication and security data (password hash, two-factor secrets, security event log).
• Billing data (billing contact, address, tax ID, payment-instrument identifier).
• Service usage data (login events, feature interactions, error logs).
• Marketing-site analytics (IP, browser, pages visited, opt-in marketing preferences).
• Support communications (tickets, chats, recordings where consented).

4.2 Data Mumara processes as processor

Personal data of Contacts, controlled by the Member. Categories typically include:

• Direct identifiers (email address, phone number).
• Profile attributes (name, job title, employer, custom fields chosen by the Member).
• Consent records (opt-in proof: timestamp, source, IP, consent text shown).
• Engagement events (opens, clicks, replies, conversions, bounces, complaints, unsubscribes).
• Operational metadata (delivery dispositions, suppression-list state, IP and ASN of the recipient when known).

5. Lawful bases for processing

Article 6 GDPR requires a lawful basis for every act of processing. As a controller, we rely on the bases below; the right basis depends on the activity.

Activity	Lawful basis
Provide the Services to a registered Member	Contract (Art. 6(1)(b))
Bill, invoice, and collect payment	Contract / legal obligation (Art. 6(1)(b), (c))
Account security, fraud and abuse prevention	Legitimate interest (Art. 6(1)(f))
Service notifications and security alerts	Contract (Art. 6(1)(b))
Marketing to existing customers (soft opt-in)	Legitimate interest, balanced (Art. 6(1)(f))
Marketing to prospects who haven't subscribed	Consent (Art. 6(1)(a))
Non-essential cookies and pixels	Consent (Art. 6(1)(a) + ePrivacy)
Comply with tax, accounting, anti-fraud, court orders	Legal obligation (Art. 6(1)(c))
Defend legal claims	Legitimate interest (Art. 6(1)(f))
Aggregated / de-identified product analytics	Legitimate interest (Art. 6(1)(f))

Where Mumara is a processor, we do not select the lawful basis — the Member chooses it for Contact Data. The Member must have a valid Article 6 (and where applicable Article 9) basis before uploading data into Mumara.

6. Special-category data

Article 9 GDPR prohibits processing of special-category data unless one of the Article 9(2) conditions applies (typically explicit consent, vital interests, or specific legal authority). By default, Mumara is not configured to receive Article 9 data; Members must not upload health, biometric, racial/ethnic, political, religious, trade-union, sexual-orientation, or criminal-conviction data unless they have an Article 9(2) basis and a written agreement with Mumara that specifically permits it.

7. Data-subject rights in detail

Articles 12–22 GDPR grant data subjects the rights below. These rights apply to natural persons; they do not apply to juristic persons (companies). For Contact Data, exercise rights against the Member that uploaded the data; we will help relay or escalate.

7.1 Right to be informed (Articles 13–14)

You have the right to clear, plain-language information about what we do with your data. This page, our Privacy Policy, and our Cookie Policy are the main vehicles for this right.

7.2 Right of access (Article 15)

You can ask whether we hold personal data about you, and if so receive a copy. We will respond within one month (extendable by two months for complex requests). The first copy is free; reasonable fees may apply for additional copies.

7.3 Right to rectification (Article 16)

You can ask us to correct inaccurate or incomplete data.

7.4 Right to erasure (Article 17 — "right to be forgotten")

You can ask us to delete your data where one of the Article 17(1) grounds applies — e.g. the data is no longer needed, you withdraw consent, you object successfully, or processing was unlawful. Erasure is not absolute: Article 17(3) preserves data needed to comply with a legal obligation, exercise/defend a legal claim, or for archiving/research in the public interest.

7.5 Right to restriction (Article 18)

You can ask us to suspend processing while we verify accuracy, while we consider an objection, or where processing is unlawful but you don't want erasure. Restricted data is stored, not used, until the restriction is lifted.

7.6 Right to data portability (Article 20)

For data you provided to us under contract or consent, you can ask for a structured, commonly used, machine-readable copy and ask us to transmit it directly to another controller where technically feasible.

7.7 Right to object (Article 21)

You can object to processing based on legitimate interests, including profiling. For direct marketing, the right is absolute — we will stop on request, no balancing test required.

7.8 Rights related to automated decision-making (Article 22)

You can avoid being subject to a decision based solely on automated processing that produces legal or similarly significant effects, except where a recognized exception applies. Mumara does not make solely-automated decisions of this kind about Members; abuse-detection systems flag for human review (see Section 20).

7.9 Right to withdraw consent (Article 7(3))

Where we rely on consent, you can withdraw it at any time. Withdrawal does not affect the lawfulness of processing carried out before withdrawal.

7.10 Right to lodge a complaint (Article 77)

You can complain to your supervisory authority. We hope you'll come to us first — see Section 19 for authority contact patterns.

8. How to exercise your rights

8.1 Where to send the request

Email /contact/ with subject line "Data subject request" and tell us which right you want to exercise.

8.2 What we need from you

• Enough information to confirm your identity (we will not surrender data to the wrong person).
• The Mumara Member relationship the request relates to (your own account, or a Member that uses Mumara to contact you).
• The specific right and what you would like done.

8.3 Verification

For Members, we typically verify via the registered email and a second factor where one is set up. For Contacts, we may ask for additional information sufficient to confirm we hold data about you (e.g. the email address you subscribed with and the Member's name).

8.4 Response times

We respond within one month of receiving a verifiable request. We may extend by two further months where the request is complex or numerous, and we will tell you within the first month if so.

8.5 Fees

Requests are normally free. Where a request is manifestly unfounded or excessive — particularly if repetitive — we may charge a reasonable fee or refuse to act, and we will explain why.

8.6 No retaliation

We will not penalize you, terminate your account, or withhold service because you exercise a GDPR right.

9. Data Processing Agreement and SCCs

Articles 28(3) and 28(4) require a written contract between controller and processor. Our standard Data Processing Agreement is GDPR-compliant and pre-incorporates the European Commission's 2021 Standard Contractual Clauses (Module Two: controller-to-processor, and Module Three where Mumara is a sub-processor of a Member that is itself a processor) along with the UK Information Commissioner's Office addendum and the Swiss adaptation. The DPA covers:

• Subject matter, duration, nature, and purpose of processing.
• Categories of data subjects and personal data.
• Confidentiality obligations on personnel.
• Security measures (Article 32).
• Sub-processor management and prior-notification rights.
• Data-subject-request assistance (Article 28(3)(e)).
• Article 32–36 assistance (security, breach notification, DPIAs, prior consultation).
• Return or deletion of data on termination.
• Audit rights and information rights.

10. Sub-processors and notification

Per Article 28(2), Mumara engages sub-processors only with Member authorization. We use the "general written authorization" model: Members authorize sub-processors on the published list and we notify Members in advance of changes so they can object.

• The current list lives at /legal/sub-processors/.
• We notify Members of additions, removals, or scope changes at least 30 days in advance.
• If a Member objects on legitimate grounds, the Member can terminate the affected Subscription per the DPA's objection process.
• Each sub-processor signs a written agreement that imposes data-protection obligations no less protective than our DPA, including the SCCs where the transfer leaves the EEA.

11. International transfers (Schrems II)

11.1 Transfer mechanisms

Where personal data leaves the EEA / UK / Switzerland to a country without an adequacy decision, we rely on:

• 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.
• Adequacy decisions where they exist (e.g. for transfers to the UK from the EU, and vice versa).
• The EU-US Data Privacy Framework where the recipient is certified.

11.2 Transfer Impact Assessments

Following the Schrems II ruling, we perform a Transfer Impact Assessment for each non-adequate destination country. The assessment considers the laws of the destination country (especially those concerning government access to data), the nature of the data, the technical and contractual safeguards in place, and the likelihood of an enforcement order. We document the outcome and revisit the assessment when material conditions change.

11.3 Supplementary measures

Where the assessment identifies risk, we apply supplementary measures, which may include:

• Encryption in transit (TLS 1.2+) and at rest (AES-256 or equivalent).
• Strict access control and audit logging.
• Pseudonymization where it does not break the use case.
• Contractual commitments from the recipient to challenge overbroad requests and notify us where legally allowed.
• Choice of in-region sub-processors and data residency, where the plan supports it.

12. Retention and deletion

Article 5(1)(e) requires storage limitation. See Privacy Policy Section 11 for the detailed retention table. In short:

• Account data — for the lifetime of the account, plus a wind-down period for legal/tax/audit needs.
• Contact Data uploaded by Members — for as long as the Member chooses, deleted on Member request or on account closure (subject to backup-rotation cycles).
• Sending logs — per the log-retention configured on the Member's plan.
• Marketing-site analytics — per the cookie lifetimes documented in the Cookie Policy.
• Support records — typically up to 5 years.

13. Security measures

Article 32 requires "appropriate technical and organisational measures". Ours include:

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

14. Personal-data breach notification

14.1 What we will do as a processor

Article 33(2) requires processors to notify controllers without undue delay after becoming aware of a personal-data breach affecting their data. Where Mumara is your processor, we will notify the affected Member's primary contact via email and (where possible) the in-product notification system, with the information required by Article 33(3) — nature of the breach, categories and approximate number of data subjects and records, likely consequences, and measures taken or proposed.

14.2 What we will do as a controller

Where Mumara is the controller and the breach is likely to result in a risk to the rights and freedoms of natural persons, we will notify the relevant supervisory authority within 72 hours of becoming aware. Where the risk is high, we will also notify affected data subjects without undue delay.

14.3 What you should do

If you believe your account has been compromised, or you become aware of a breach involving Mumara, contact us immediately via /contact/ with subject line "Security incident".

15. Records of processing (Article 30)

We maintain Article 30 records of our processing activities as both controller and processor. Records include the categories of processing, the categories of data subjects and personal data, the categories of recipients (including sub-processors), transfers to third countries and safeguards, retention periods, and a description of security measures. We make these records available to supervisory authorities on lawful request.

16. Data Protection Impact Assessments (DPIAs)

Article 35 requires a DPIA for processing likely to result in a high risk to data subjects. Mumara performs DPIAs for new product features, new sub-processors, and material changes to existing processing. Members who need to perform their own DPIA for their use of Mumara can request a DPIA-support package via /contact/ — typically containing our security overview, sub-processor list, SCC documentation, and architecture diagrams under NDA.

17. Data Protection Officer (DPO)

Mumara has appointed a Data Protection Officer per Article 37 GDPR. The DPO oversees our privacy program, advises on DPIAs, liaises with supervisory authorities, and is the primary contact for data subjects on data-protection matters.

Contact the DPO via /contact/ with subject line "DPO" or "GDPR".

18. EU and UK representatives (Article 27)

Where required, Mumara has appointed representatives in the EU and the UK per Article 27 GDPR. The representative handles communications with supervisory authorities and data subjects on Mumara's behalf for matters within the GDPR's territorial scope.

Request representative contact details via /contact/ with subject line "Article 27 representative".

19. Supervisory authorities and complaints

You have the right under Article 77 to lodge a complaint with the supervisory authority in your country of residence, place of work, or where the alleged infringement occurred. Some examples:

• Ireland — Data Protection Commission (DPC)
• Germany — Federal Commissioner for Data Protection and Freedom of Information (BfDI) and the state-level authorities
• France — Commission Nationale de l'Informatique et des Libertés (CNIL)
• Italy — Garante per la Protezione dei Dati Personali
• Spain — Agencia Española de Protección de Datos (AEPD)
• Netherlands — Autoriteit Persoonsgegevens (AP)
• UK — Information Commissioner's Office (ICO)
• Switzerland — Federal Data Protection and Information Commissioner (FDPIC)

Where multiple authorities have jurisdiction, the "one-stop-shop" mechanism (Article 56) designates a lead supervisory authority.

20. Automated decision-making and profiling

Mumara uses automated systems for spam filtering, abuse scoring, and deliverability protection. These can throttle or pause sending automatically when patterns suggest abuse or compromise. Decisions with significant or legal effects on a person — for example, suspending or terminating a Member's account — involve human review before they are finalized. Members can request human review of any automated outcome via /contact/.

21. Children's data

Mumara's services are not directed to children. Article 8 GDPR sets the age threshold for consent in information-society services at 16 (Member States can lower it to 13). Members who collect personal data from children must comply with Article 8 and any applicable national law and must not upload such data to Mumara unless a separate written arrangement is in place.

22. Customer obligations as controllers

When you use Mumara to send email or SMS, you are the controller of the recipient data. Your GDPR obligations include:

• Informing your Contacts about your processing (Articles 13–14).
• Maintaining a valid Article 6 lawful basis for each processing purpose.
• Honouring Article 7 consent requirements where you rely on consent.
• Responding to Article 15–22 requests from your Contacts (we will support you per the DPA).
• Keeping Article 30 records.
• Conducting DPIAs where required by Article 35.
• Notifying breaches per Articles 33 and 34.
• Putting written contracts in place with your own processors and sub-processors.

23. Mumara's obligations as a processor

Article 28 sets out a processor's specific obligations. We commit to:

• Process personal data only on documented controller instructions, including for transfers, unless required otherwise by law (Art. 28(3)(a)).
• Ensure personnel with access are bound to confidentiality (Art. 28(3)(b)).
• Implement appropriate security measures (Art. 32, see Section 13 above).
• Engage sub-processors only under the conditions in Article 28(2)–(4) and our DPA (Section 10 above).
• Assist with data-subject requests as required (Art. 28(3)(e)).
• Assist with breach notification, DPIAs, and prior consultation (Art. 28(3)(f)).
• Return or delete data at the controller's choice on termination (Art. 28(3)(g)).
• Make available the information needed to demonstrate compliance, and allow audits (Art. 28(3)(h), Section 24 below).

24. Audit and information rights

Members may verify our compliance with our DPA obligations by:

• Reviewing this page and our published documentation.
• Requesting our security overview, sub-processor list, and SCC documentation under NDA.
• Submitting a written audit questionnaire we will respond to within a reasonable time.
• For enterprise customers under contract, requesting an on-site or remote audit per the DPA's audit clause, with reasonable notice and at the customer's cost.

Audits cannot disclose information about other Members or compromise the security of the platform. We may satisfy audit requests with third-party reports (e.g. SOC 2) where they meaningfully cover the questions asked.

25. Updates to this page

We update this page when our processing changes or when the law changes. The "Last updated" date at the top reflects the latest revision. Material changes are also reflected in our Privacy Policy and DPA.

26. Contact

For data-protection inquiries, contact us via /contact/ with the relevant subject line:

• "Data subject request" — to exercise a GDPR right.
• "DPO" or "GDPR" — for our Data Protection Officer.
• "Article 27 representative" — for EU/UK representative contact details.
• "DPA" — to request our standard Data Processing Agreement.
• "Security incident" — to report a suspected breach.