Data Processing Agreement

What this agreement covers

When your business uses MeloHello, you are deciding what data goes in and what happens to it. We are running the platform that handles it. Data protection law treats those two roles differently, and this agreement sets out the difference in plain terms.

It covers personal data about your customers, your staff and your contacts that we process in order to provide MeloHello. It does not cover the enquiry details you send us through this website, or the account and billing information we hold about your business in our own right — our Privacy Policy covers that, and in that context we act independently and not as your processor.

It also does not cover what WhatsApp and Meta do with message data on their own account. That is governed by Meta’s terms and is described in our sub-processor list.

Who is what

You are the controller — the Data Fiduciary, in the language of India’s Digital Personal Data Protection Act, 2023. You decide why the data is processed and on what basis you are entitled to hold it. If you are a processor for someone else in turn, you confirm you have the authority to give us the instructions this agreement contemplates.

We are the processor — the Data Processor. We act on your documented instructions, we do not decide the purposes of processing, and we do not treat your business data as ours to use.

We are also a separate controller for a narrow set of things: your account, your invoices, support conversations and the security of our own systems. Where we act for ourselves, our Privacy Policy applies and this agreement does not.

Terms used in this agreement

These definitions are deliberately short. Where a term is defined in an applicable data protection law, that definition applies instead.

• Client means the business that subscribes to MeloHello — you.
• Personal data means information about an identifiable person that we process for you.
• Processing means anything done with that data: storing it, organising it, sending it, reading it, deleting it.
• Data subject means the person the data is about — usually your customer or contact.
• Sub-processor means another company we engage to process data on your behalf. Our sub-processor list is published separately.
• Security incident means a confirmed breach of security leading to accidental or unlawful loss, alteration, disclosure or access to personal data we process for you.
• Applicable data protection law means the law that applies to the processing in question, which for most of our customers is India’s Digital Personal Data Protection Act, 2023 and the rules made under it, plus any law of another country that reaches the data.

What we process, and why

We process the data you or your customers put into the platform in order to provide the platform — nothing more. In practice that means the data categories listed in our Privacy Policy: customer conversations, contact records, workflow events, assignments and reports.

We process it for these purposes and no others: to operate, maintain and secure MeloHello; to provide support you ask for; to detect and fix faults; and to meet our own legal, tax and accounting obligations.

We do not sell it. We do not use your customers’ conversation content to market to them, to build audiences, or to train models for our own product development. We do not use it to market MeloHello to your customers.

Our obligations as your processor

• Process personal data only on your documented instructions, including the instructions in this agreement and in the workflow configuration you set up.
• Tell you promptly if an instruction would, in our reasonable opinion, breach applicable data protection law — and not carry it out until you confirm it.
• Keep the data confidential, and bind everyone who has access to it to confidentiality.
• Implement the security measures set out below.
• Help you answer requests from your customers about their data, as described further down.
• Help you with your own obligations, including any data protection impact assessment or consultation with a regulator, by giving you the information you reasonably need.
• Delete or return the data when the subscription ends, as described further down.
• Let you audit our compliance, within the limits set out further down.

Your obligations as controller

We depend on you getting these right. If a message is sent that should not have been, the consequences land on you and on the people you messaged, not only on us.

• Make sure you have a lawful basis for the data you put into the platform, and give your customers a privacy notice that covers the fact that you use a platform like ours.
• Obtain and record the opt-in that the WhatsApp Business Messaging Policy requires before messaging anyone — it must clearly name your business and make clear that the person is agreeing to hear from you. Meta enforces this directly on your WhatsApp Business account.
• Honour opt-out requests you receive, and stop messaging people who ask you to.
• Only put data into the platform that you are entitled to put there, for purposes you are entitled to pursue.
• Give us instructions that are lawful, and tell us if something you have asked for becomes unlawful.
• Keep your account credentials secure, and tell us promptly if you think someone else has access to your account.

If we disagree with an instruction

If you instruct us to do something we believe breaches data protection law, we will tell you why and ask you to confirm before we act. If you confirm and we still believe it is unlawful, we may decline. We will not simply execute an instruction we know to be unlawful because an agreement says we must.

Sub-processors

You authorise us to engage sub-processors, and you accept the sub-processors listed on our sub-processor page. That is a general authorisation rather than a case-by-case one, because we cannot run the platform otherwise.

When we engage a sub-processor, we put a written agreement in place that imposes obligations on it that are no less protective than the ones in this agreement — including confidentiality, security, deletion and assistance with data-subject requests. We remain responsible to you for what a sub-processor does, and for what it fails to do.

We publish the current list, and we give notice before a new sub-processor starts processing your data. If you object on reasonable data-protection grounds, we will look for a way to provide the service without that sub-processor or let you terminate the affected part of the subscription without penalty for the remaining term.

One item on that list is not substitutable, and we would rather say so plainly. WhatsApp message delivery runs through Meta, and there is no way to offer WhatsApp messaging without it. Meta’s own WhatsApp Business Data Processing Terms and Meta Hosting Terms for Cloud API apply to its processing, and Meta’s Data Transfer Addendum covers transfers out of the European Economic Area and the United Kingdom.

How we secure the data

These are the measures we maintain. They are stated as facts about how the platform is built, not as aspirations, because this section is the one a security reviewer will test against our actual systems.

• Encryption in transit: all connections to the platform and to every sub-processor use TLS 1.2 or higher. Plain HTTP is not accepted.
• Encryption at rest: databases, object storage and backups are encrypted using managed keys.
• Access control: access to production data is limited by role, granted on a least-privilege basis, and reviewed periodically. Administration tools are not exposed publicly.
• Tenant separation: each customer’s data is stored and queried in a way that keeps tenants apart, so one customer cannot reach another’s records.
• Multi-factor authentication: required for all remote and administrative access to systems that can reach your data.
• Account lifecycle: access is granted, changed and revoked through a defined process, including promptly on someone leaving.
• Credential handling: API keys, tokens and secrets are stored in a secret manager, never in source control, and rotated when there is reason to.
• Secure development: dependencies are kept patched, and changes to the platform are reviewed before release.
• Monitoring and logging: access to production systems is logged, and we monitor for anomalous access.
• Vulnerability management: we test the platform for security vulnerabilities at least once every twelve months and address findings by severity.
• Incident response: we maintain and periodically test a written incident response plan.
• Secure disposal: data is deleted using methods that make it unrecoverable in the ordinary course.

If something goes wrong

If we become aware of a security incident affecting your data, we will tell you without undue delay, and in any event within seventy-two hours of becoming aware. We will tell you what we know at that point, even where our investigation is still running, rather than wait for a complete picture.

Our notice will describe what happened, the data and people affected as far as we can tell, what we are doing about it, and what we recommend you do. We will keep you updated as the investigation progresses and we will not leave you to chase us for the next update.

We will not describe an incident in a way designed to minimise it, and we will not tell you a breach cannot have affected you without a basis for saying so. We will also not notify your customers on your behalf — that is your call to make, and we will give you what you need to make it.

We will record incidents and the action we took, and give you that record on request.

When your customers ask about their data

People will approach you to access, correct, export or delete their data. It is your responsibility to respond to them, because you are the controller and you know who they are.

If someone contacts us directly, we will point them to you rather than answering ourselves, unless the law obliges us to respond. We will tell you when this happens.

When you need to answer a request, tell us and we will help: we will retrieve, correct, export or delete what you identify, and give you the information about our processing that you need. We will do this within a period that lets you meet your own deadline, and we will not charge for reasonable requests.

Deleting the data

We delete personal data we process for you when you ask us to, when it is no longer needed for the purpose you gave it to us for, when you close your account, or when the law requires it. In each case we do it as soon as reasonably possible, and in any event within one hundred and twenty days unless a legal requirement obliges us to keep it longer.

That one-hundred-and-twenty-day ceiling is not our own invention. It mirrors the limit Meta sets for Platform Data in its Data Protection Assessment, so that our commitment to you is no weaker than the one we owe upstream.

When we delete, we remove the data from live systems and from backups in the ordinary course, and we tell you it is done. Where deletion is genuinely impossible — an immutable backup rotation already under way, for example — we keep the data isolated and stop processing it for anything other than storage until deletion completes.

Two limits are worth knowing about. We may keep records that the law requires us to keep, such as invoices and tax records, and we may keep de-identified or aggregated information that can no longer be linked to a person. Neither is personal data once the link is gone.

Message data is a special case, and we do not control all of it. Meta retains message data for a maximum of thirty days for delivery and retransmission, and we cannot shorten that period by contract. The Meta leg of a deletion request is described in our sub-processor list.

Sending data outside India

Some sub-processors process data outside India, and Meta’s WhatsApp Business Platform operates from Meta’s own data centres. Where data leaves India, we rely on the transfer mechanisms available under applicable law, and our sub-processor list records where each provider processes data.

We do not choose a provider on the basis of a lower standard of protection, and we do not move your data to a jurisdiction to escape an obligation. If you need a specific processing location or a specific transfer mechanism before you can onboard, raise it with us before you subscribe — some of it we can accommodate, and we would rather say so then than discover it later.

Auditing us

You may audit our compliance with this agreement once in any twelve-month period, on at least thirty days’ written notice, during business hours, and at your own cost. Audits must be conducted in a way that does not compromise the security of other customers’ data.

We would rather satisfy you with evidence than with an inspection. We will give you our security documentation, our sub-processor agreements on a confidential basis, our incident records, and any current third-party certification we hold. Where a certification from a recognised auditor is current and covers the systems in question, we may offer that instead of an on-site audit, and you agree that it satisfies this clause.

An audit that arises from a security incident affecting your data, or from a regulator’s requirement, is not counted against the once-a-year limit.

Our liability to each other

This agreement does not increase the liability either of us has under the Terms of Service, and the limits and exclusions in the Terms apply to claims arising out of this agreement as they do to the rest of the service.

Where we are found liable for something a sub-processor did, we are responsible to you for it. Where you are found liable because of an instruction you gave us, or because you messaged someone without the opt-in you were required to obtain, you remain responsible for that.

Term, and what survives the end

This agreement runs as long as we process data for you, and ends when the last of it is deleted or returned. That is usually shortly after your subscription ends, but the deletion section above governs the timing rather than the subscription date.

The obligations about confidentiality, deletion, and liability survive the end of the agreement for as long as they are needed to give them effect.

Governing law, and which document wins

This agreement is governed by the laws of India, and disputes are subject to the jurisdiction of the courts of [city of registration to be confirmed]. That matches the Terms of Service deliberately — an agreement that sent the two documents to different courts would create more disputes than it resolved.

If this agreement and the Terms of Service disagree about the processing of personal data, this agreement wins. If this agreement and a signed order form disagree, the order form wins, but only where it expressly says it is amending this agreement.

If we make a material change to this agreement, we will update the date at the top of the page and give notice to customers holding a written agreement for the period set out in it.

Data protection contact

Questions about this agreement, requests to sign a copy, notices about a security incident, and objections to a new sub-processor all go to hello@melohello.com. If you would rather write to a person, our grievance officer is [grievance officer name to be confirmed], reachable at the same address.

[registered entity name to be confirmed], [registered office address to be confirmed].