Data Protection Rules

This page describes how Resalian handles the personal data of your customers — the numbers you upload and the messages you send. It forms part of our Terms of Service and functions as our data processing terms.

1. Roles and responsibilities

These rules are written against Oman's Personal Data Protection Law (Royal Decree No. 6/2022) and its Executive Regulations, Oman being where Tech Serenity IT is established. They are drafted to be usable by customers elsewhere: the processor obligations set out here — purpose limitation, security, sub-processor disclosure, breach notification, assistance with data subject requests, and deletion on termination — are common to Oman's PDPL, the GDPR and comparable regimes. If your own regulator requires particular contractual language, write to us and we will work from your paper.

These rules are written against Oman's Personal Data Protection Law (Royal Decree No. 6/2022) and its Executive Regulations, where Tech Serenity IT is established. They are drafted to be usable by customers elsewhere: the processor obligations set out here — purpose limitation, security, sub-processor disclosure, breach notification, assistance with data subject requests and deletion on termination — are the ones common to Oman's PDPL, the GDPR and comparable regimes. If your own regulator requires specific contractual language, write to us and we will work from your paper.

You are the data controller. You decide whose data is processed, what they are sent and why. You are responsible for having a lawful basis for each recipient.

We are the data processor. We act only on your documented instructions — given through your use of the dashboard and API — and for no purpose of our own. We do not use your customers' data to train models, build profiles across customers, enrich any dataset, or market to your customers.

2. What we process, and why

Categories of data subject are your customers, prospects and anyone who messages your WhatsApp number. Processing lasts for the term of your subscription, subject to the settings below.

3. How much you let us keep

Most platforms require your whole customer database before you can send anything. Resalian offers three levels, set in Settings → Data & privacy and, for the third, per campaign.

Level 1 — Keep the list (default)

Uploaded audiences are stored so you can reuse them, review who received what, and re-send. Suitable where you already hold this data lawfully and want the operational history.

Level 2 — Erase after each campaign

Recipient phone numbers are irreversibly replaced with hashes the moment a campaign reaches a terminal state — not on a nightly sweep, but at the point the send finishes or is cancelled. What survives is:

• Delivery counts and per-recipient outcomes, so your reporting still works
• A keyed hash of each number, so opt-outs continue to be honoured

What does not survive is the ability for anyone — including us — to read the list back.

Level 3 — Never send it at all

Your list stays on your infrastructure. You host an endpoint; while a campaign runs, Resalian requests one page of around 100 recipients at a time, sends to them, and retains only hashes. At no point do we hold more than one page, and nothing durable holds any of it.

• Requests are signed with a shared secret you set, so you can reject anything that is not us
• The endpoint must be HTTPS; we refuse plaintext and private network addresses
• You can revoke access simply by taking your endpoint offline

This mode is compatible with our events API, so you can run genuine value-based segmentation while we hold nothing but hashes and amounts.

4. Retention and deletion

You may set a retention period for message history, from as short as one hour to as long as you require. When it expires, an automated sweep:

• removes phone numbers from message records, replacing them with keyed hashes;
• removes message content, if you have chosen that option;
• strips the peer number from the conversation record.

Aggregate counts are computed before redaction and are unaffected, so your reporting remains accurate over redacted history.

The sweep runs hourly. A Purge now control runs it immediately for situations where an hour is too long to wait. Every run that removes data writes an audit record showing what was removed and when — visible to you in the dashboard, so a question about deletion has an answer with numbers on it rather than an assurance.

5. Opt-outs and suppression

When a recipient replies with a recognised opt-out keyword — STOP, UNSUBSCRIBE, إلغاء and equivalents — Resalian marks that contact as opted out and records a permanent suppression entry.

Suppression entries are stored as keyed hashes, not phone numbers, and are deliberately excluded from every deletion routine on this page. An opt-out deleted alongside the rest of a customer's data would mean messaging someone who told you to stop — the exact outcome retention rules exist to prevent. Suppression is checked when an audience is built, so you see the true reachable count before you commit to sending.

6. Security measures

The specific technical measures we maintain:

• TLS on every connection to the dashboard and API.
• AES-256-GCM encryption at rest for your Meta access tokens; the key is held in a secret store, never in the database.
• PBKDF2-SHA256 password derivation with per-user salt and 100,000 iterations.
• SHA-256 hashing of API keys; plaintext keys are shown once and never stored.
• Keyed HMAC for phone-number hashes. A plain digest of a phone number is reversible by brute force — the number space is small — so the hash is keyed with a secret that is not in the database. A copy of the database alone cannot recover the numbers.
• Signature verification on every inbound webhook from Meta before it is acted on.
• Tenant isolation — every query is scoped to your workspace; hashes are salted per workspace so one customer's suppression list cannot be probed with another's.
• Environment separation between test and live credentials, enforced server-side.
• Per-key rate limiting against runaway integrations and abuse.
• Least-privilege access for our personnel, who are bound by confidentiality obligations.

7. Sub-processors

We use the following sub-processors. We remain responsible to you for their performance.

We will give you at least 30 days' notice before adding or replacing a sub-processor. If you reasonably object on data protection grounds, you may terminate without penalty for the remainder of the term.

8. International transfers

Delivering a WhatsApp message necessarily transfers the recipient's number and message to Meta, which operates internationally. Our infrastructure runs on Cloudflare's global network. Personal data processed through Resalian therefore leaves Oman, and there is no configuration of this service in which it does not.

Under Oman's Personal Data Protection Law (Royal Decree No. 6/2022) and its Executive Regulations, the controller is responsible for satisfying the conditions for transferring personal data outside the Sultanate. As processor we support you by disclosing every recipient in section 7, by relying on the transfer safeguards in our agreements with those providers including standard contractual clauses where applicable, and by offering the storage modes in section 3 — the strictest of which keeps your customer list on your own infrastructure, so that only the numbers actively being messaged are ever transmitted.

Customers established outside Oman remain subject to their own local transfer rules. The disclosures on this page are written to support a transfer assessment under any of them.

9. Data subject requests

Requests from your customers are yours to answer — you hold the relationship and the lawful basis. We will assist you within 10 days of a written request.

Practically:

• Access — export a contact's conversation history and delivery record from the dashboard or API yourself, at any time.
• Erasure — delete the contact in the dashboard, which removes their record and conversation. The suppression hash remains, so they stay unsubscribed.
• Objection to marketing — mark the contact opted out; every future campaign will skip them automatically.

If a data subject contacts us directly, we will not respond substantively on your behalf. We will tell them to contact you, and forward the request where we can identify the workspace concerned. Step-by-step routes for every kind of deletion request are on the Data Deletion Instructions page.

10. Breach notification

If we become aware of a personal data breach affecting your data, we will notify you without undue delay and in any event within 72 hours of becoming aware. The notification will describe the nature of the breach, the categories and approximate number of records affected, the likely consequences, and the measures taken.

We will assist you in meeting your own notification obligations to regulators and data subjects.

11. Audit and evidence

On reasonable written notice, and no more than once per calendar year unless required by a regulator or following a breach, we will make available the information necessary to demonstrate compliance with these rules.

For most questions the dashboard is the fastest answer: the deletion log shows exactly what was removed and when, and your data-handling settings show what is currently retained.

12. Your obligations

• Have a lawful basis, and valid opt-in where required, for every recipient.
• Give your customers the privacy information they are entitled to, including that a processor is used to send messages on your behalf.
• Do not upload special category data — health, religion, biometrics, political opinions and similar — into contact attributes. The platform is not designed for it.
• Configure retention and storage settings appropriately for your obligations. The defaults favour operational convenience, not minimisation; if you need minimisation, turn it on.
• Keep credentials and API keys secure, and revoke any that are exposed.
• Respond to your customers' data subject requests.

13. Our role as a Meta technology provider

Resalian is integrated with the WhatsApp Business Platform as a technology provider acting on behalf of its customers. That carries obligations to Meta which run alongside the ones we owe you, and which we confirm here.

• We act only on your behalf. Your Meta assets remain yours. We hold delegated access to send on your instruction, never to use for our own purposes.
• Strict tenant separation. Every database query is scoped to a single workspace. Phone-number hashes are keyed per workspace, so one customer's data cannot be correlated against another's even by us.
• No secondary use. Platform Data is not used for advertising, audience building, model training, resale or enrichment of any dataset.
• Purpose limitation. We request only the Meta permissions the product needs, and delete Platform Data when it is no longer required for the purpose you provided it for.
• Onward obligations. Our sub-processors are bound to equivalent restrictions, and we remain responsible to you for their conduct.

Deletion routes, including how to revoke our access at Meta, are on the Data Deletion Instructions page. Our handling of Platform Data is additionally governed by Meta's Platform Terms and Developer Policies; where those are stricter, they prevail.

14. Facebook and Instagram

We are extending Resalian to run campaigns on Facebook and Instagram. When those channels launch, the categories of data shared with Meta will expand to include the identifiers those platforms require. We will update this page and notify you before any such processing begins, and existing campaigns will not be migrated to a new channel without your explicit action.

15. Contact

Tech Serenity IT
registered company name
registered address
Data protection: [email protected]

If you require a signed data processing agreement on your own paper, write to us — we will work from it rather than insisting on ours.