Data Processing Agreement
This DPA forms part of the Terms of Service between Alaaqat for Information Technology (علاقات لتكنولوجيا المعلومات), a sole proprietorship entered in the Commercial Register for Individuals of the Hashemite Kingdom of Jordan under number 545258 (national establishment number 100999274), established in Amman, Jordan ("Alaaqat", "we") and the customer who accepts the Terms of Service ("Customer", "you"). It applies whenever Alaaqat processes personal data on the Customer's behalf in the course of providing the Alaaqat platform (the "Service").
1. Definitions
- Data Protection Law — Regulation (EU) 2016/679 (the "GDPR"); the UK GDPR and the Data Protection Act 2018 for Customers established in the United Kingdom; and the Jordanian Personal Data Protection Law No. 24 of 2023 for Customers established in Jordan. Where this DPA cites an Article without more, it refers to the GDPR; the corresponding provision of the UK GDPR or the Jordanian law applies equally.
- Personal Data, Processing, Controller, Processor, Data Subject, Sub-processor, Supervisory Authority and Personal Data Breach have the meanings given in Art. 4 GDPR.
- Customer Data — personal data that the Customer, its users, or its contacts submit to the Service, or that the Service receives on the Customer's behalf from a connected messaging channel.
- Account — the Customer's tenant in the Service. All Customer Data is scoped to exactly one Account.
- Contact — a person whose personal data the Customer stores or communicates with through the Service.
2. Roles and scope
2.1 For Customer Data, the Customer is the Controller and Alaaqat is the Processor. This DPA governs that processing.
2.2 For the personal data of the Customer's own users that Alaaqat needs to operate the Service — login credentials, names, email addresses, billing details, consent records, audit trail, support correspondence, usage and security logs — Alaaqat is an independent Controller. That processing is governed by the Privacy Policy at https://alaaqat.com/policy, not by this DPA.
2.3 Alaaqat's own website analytics and marketing measurement (Google Tag Manager, Google Analytics, ad-click identifiers) are Controller processing under the Privacy and Cookie Policies and run only with the visitor's consent. No Customer Data is sent to those tools or to their providers.
2.4 Where the Customer acts as a Processor for a third party, the Customer warrants that its own Controller has authorised Alaaqat as a Sub-processor on terms no less protective than this DPA.
3. Details of processing
The subject matter, duration, nature, purpose, categories of Data Subjects and categories of Personal Data are set out in Annex 1.
4. Customer's obligations
4.1 The Customer is responsible for the lawfulness of the Customer Data it processes through the Service, including having a lawful basis for storing each Contact and for every message sent to them.
4.2 The Customer instructs Alaaqat to process Customer Data only to provide, maintain and secure the Service, to comply with law, and as further instructed in writing. Use of the Service's features (sending a broadcast, importing contacts, connecting a channel) constitutes an instruction.
4.3 Special categories of data. The Service is not designed for Art. 9 special-category data and applies no additional safeguards to it; the Customer is solely responsible for having an Art. 9(2) basis before recording any such data in custom properties, notes or messages.
4.4 WhatsApp coexistence. When the Customer connects a WhatsApp Business phone that is also used in the WhatsApp Business app, Meta synchronises to the Service the phone's existing contact list and up to six months of prior conversation history, including conversations with people who never wrote to the business through the Service. The Customer, not Alaaqat, decides to connect that channel, and is responsible for the lawful basis of the Contacts and history so imported. Alaaqat treats the imported data as Customer Data under this DPA from the moment of import.
4.5 Messaging channels. By connecting Meta (WhatsApp, Messenger, Instagram) channels the Customer acknowledges that message content, media and metadata transit Meta's platforms under Meta's own terms, which Alaaqat does not control and which are incorporated by reference in Annex 3.
5. Alaaqat's obligations (Art. 28(3))
5.1 Instructions. Alaaqat processes Customer Data only on the Customer's documented instructions (Section 4.2), unless required to by Union or Member State law, in which case Alaaqat informs the Customer before processing unless that law prohibits it. Alaaqat will inform the Customer if, in its opinion, an instruction infringes the GDPR.
5.2 Confidentiality. Personnel authorised to process Customer Data are bound by contractual or statutory confidentiality obligations. Access to production data is limited to the operating team and protected by mandatory two-factor authentication.
5.3 Security. Alaaqat implements the technical and organisational measures in Annex 2.
5.4 Sub-processors. As set out in Section 6.
5.5 Data-subject requests. As set out in Section 7.
5.6 Assistance. Alaaqat assists the Customer, taking into account the nature of the processing and the information available to it, in meeting the Customer's obligations under Art. 32–36 (security, breach notification, data-protection impact assessments and prior consultation).
5.7 Deletion and return. As set out in Section 9.
5.8 Audit. As set out in Section 10.
5.9 Tenant isolation. Every query, job and endpoint that touches Customer Data is bound to a single Account. Users who do not belong to an Account cannot see, query or export its data.
6. Sub-processors
6.1 General authorisation. The Customer gives general written authorisation to the engagement of the Sub-processors listed in Annex 3.
6.2 Notice of changes. Alaaqat will publish changes to Annex 3 at https://alaaqat.com/sub-processors and inform the Account owner, in the Service or by email, before a new Sub-processor starts processing Customer Data.
6.3 Objection. The Customer may object in writing within 14 days of the notice on reasonable data-protection grounds. If the parties cannot resolve the objection in good faith, the Customer may terminate its Account in accordance with the Terms of Service, and Section 9 applies.
6.4 Flow-down. Alaaqat imposes on each Sub-processor data-protection obligations that are at least as protective as this DPA, and remains fully liable to the Customer for the Sub-processor's performance.
7. Data-subject rights
7.1 Routing. Alaaqat does not respond directly to Data Subjects about Customer Data. A request received directly by Alaaqat is forwarded to the Customer's Account owner without undue delay.
7.2 Self-service. The Customer can serve most requests inside the Service without Alaaqat's involvement:
| Right | How the Customer serves it |
|---|---|
| Access (Art. 15) | The Contact's record, notes, activity timeline and conversation history are visible in the Contact view; column export is available to permissioned users. |
| Rectification (Art. 16) | Edit the Contact. Every change is logged in the object's activity timeline with the previous value (see Annex 4 for how long). |
| Erasure (Art. 17) | Delete the Contact; the deletion cascades to its notes, files, activity log and conversation index. Message copies already delivered to a messaging platform are outside Alaaqat's control (Art. 19). |
| Objection to marketing (Art. 21) | Set the Contact's unsubscribed flag. The Service then refuses to include the Contact in any broadcast or automated outbound message. The flag is also settable by hand to record an objection received outside the Service. |
7.3 Assisted requests. For the following, Alaaqat assists the Customer on written request, as Art. 28(3)(e) requires, because they need production access or affect data outside the Customer's own UI:
| Right | Alaaqat's procedure |
|---|---|
| Portability (Art. 20) | Machine-readable export of what the Service holds about one Data Subject across contacts, conversations, notes, files and activity logs. |
| Restriction (Art. 18) | Quarantine in place: the record is marked restricted, the unsubscribed flag is set, the Contact is removed from active broadcast audiences, and the record is exempted from automated pruning until the restriction is lifted. The data is not exported and deleted, because that is irreversible and would leave copies behind. |
| Erasure across backups | See Annex 4, "Frozen backups". |
7.4 Art. 19 statement. Rectification and erasure performed in the Service do not propagate to copies of messages that have already been delivered to a messaging platform (Meta) or to the recipient's device. The Customer is responsible for informing the Data Subject of that limit where Art. 19 requires it.
8. Personal Data Breach
8.1 Alaaqat notifies the Customer's Account owner by email without undue delay after becoming aware of a Personal Data Breach affecting Customer Data, so that the Customer can meet its own 72-hour obligation under Art. 33.
8.2 The notice describes, to the extent known, the nature of the breach, the categories and approximate number of Data Subjects and records concerned, the likely consequences, the measures taken or proposed, and a point of contact. Information may be provided in phases.
9. Deletion and return of Customer Data
9.1 During the term. The Customer deletes Customer Data at will through the Service. Deleted objects are removed from the live database immediately and cascade to their dependent records.
9.2 Account deletion on request. When the Account owner requests deletion, the Account is locked immediately and held for a 14-day grace period during which the owner may cancel the request. At the end of the grace period an automated job irreversibly purges every record, file, conversation and log belonging to the Account. Alaaqat confirms completion by email.
9.3 Dormant accounts. An Account with no paid subscription that has seen no authenticated request for 12 months is warned by email, reminded 7 days before the deadline, and, if still unused 30 days after the warning, entered into the deletion flow of Section 9.2 (a further 14 days). A single sign-in at any point resets the clock. Accounts with an active paid subscription are never deleted for dormancy.
9.4 Return before deletion. The Customer may export Customer Data through the Service at any time before purge. On written request during the grace period Alaaqat returns the Customer Data in a machine-readable form (Art. 28(3)(g)).
9.5 Retention after deletion. Copies of transactional email sent by the platform are retained for 30 days from sending and then deleted by a daily job. On account erasure, copies of the deletion notices and of the deletion confirmation persist for the remainder of that 30-day window; they are retained to evidence that the notices were delivered (Art. 17(3)(e)) and contain the recipient's name and email address and the Account name, not Customer Data. Frozen backups roll off on the schedule in Annex 4, within one year at most. Alaaqat retains no other Customer Data after purge, except as required by law (invoices and tax records held by the payment provider).
10. Audits
10.1 Alaaqat makes available the information necessary to demonstrate compliance with Art. 28: this DPA, Annex 2, the Sub-processor list, and, on written request, such further information as is necessary for that purpose.
10.2 Where that information is insufficient to satisfy a legal obligation, the Customer (or an independent auditor mandated by the Customer, bound by confidentiality and not a competitor of Alaaqat) may audit Alaaqat's compliance with this DPA no more than once per 12 months, on at least 30 days' written notice, during business hours, at the Customer's cost, in a manner that does not disrupt the Service or give access to other customers' data. Alaaqat may charge a reasonable fee, at its then-current rates, for the time and materials it spends preparing for and supporting an audit.
11. International transfers
11.1 The Service is hosted in the European Economic Area: application servers, the PostgreSQL database, the MongoDB Atlas cluster and the S3 buckets all run in Ireland (AWS region eu-west-1). Backups are stored in the same region.
11.2 Alaaqat's own access. Alaaqat is established in Jordan, which is not covered by an adequacy decision. Although the Service and its data stores run in Ireland, Alaaqat's operating team administers them from Jordan, and that access is a transfer of Customer Data to a third country.
11.3 Standard Contractual Clauses. Where the Customer is established in the EEA, or the transfer is otherwise subject to Chapter V of the GDPR, the Standard Contractual Clauses annexed to Commission Implementing Decision (EU) 2021/914, Module Two (controller to processor), are incorporated into this DPA by reference and apply to the transfer described in Section 11.2, with:
- Clause 7 (docking) not applied;
- Clause 9, Option 2 (general written authorisation), the notice under Section 6.2 being given at least 14 days before the Sub-processor starts processing Customer Data, so that the objection right in Section 6.3 can be exercised beforehand;
- Clause 11 optional redress paragraph not applied;
- Clause 17, Option 1, governed by the law of Ireland;
- Clause 18(b): the courts of Ireland;
- Annex I.A (parties) completed by the preamble of this DPA and the Customer's Account details;
- Annex I.B (description of transfer) completed by Annex 1 of this DPA;
- Annex I.C (supervisory authority): the competent authority of the Member State in which the Customer is established;
- Annex II (technical and organisational measures) completed by Annex 2 of this DPA;
- Annex III (sub-processors) completed by Annex 3 of this DPA.
Where the Customer is established in the United Kingdom, or the transfer is subject to the UK GDPR, the International Data Transfer Addendum issued by the Information Commissioner under s.119A of the Data Protection Act 2018 applies to those same Clauses, with Tables 1–3 completed as above and Table 4 marked "neither party".
For convenience only, Commission Implementing Decision (EU) 2021/914 is published at https://eur-lex.europa.eu/eli/dec_impl/2021/914/oj and the International Data Transfer Addendum at https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/appropriate-safeguards/what-are-standard-data-protection-clauses-the-uk-idta-and-the-addendum/. Those links are references, not part of this DPA; the texts as published in the Official Journal of the European Union and by the Information Commissioner respectively prevail over any copy.
11.4 Some Sub-processors in Annex 3 process Customer Data outside the EEA/UK. Where they do, transfers rest on an adequacy decision or on the Standard Contractual Clauses incorporated in the Sub-processor's terms, as indicated in Annex 3.
11.5 The Customer acknowledges that message content sent through Meta's platforms is transferred to Meta under Meta's own transfer mechanisms, listed in Annex 3.
12. Liability, term, precedence
12.1 Each party's liability under this DPA is subject to the limitations in the Terms of Service, except that nothing limits either party's liability to Data Subjects under Art. 82.
12.2 This DPA takes effect on acceptance of the Terms of Service and lasts as long as Alaaqat processes Customer Data, including the deletion period of Section 9.
12.3 In case of conflict, this DPA prevails over the Terms of Service for the subject matter of data protection; the Standard Contractual Clauses, where they apply, prevail over this DPA, and Section 12.4 does not affect Clauses 17 and 18 of those Clauses.
12.4 This DPA is governed by the law of the Hashemite Kingdom of Jordan, and the courts of Amman have exclusive jurisdiction over any dispute arising from it, in line with Sections 6.12 and 6.13 of the Terms of Service; nothing in this Section deprives a Data Subject of the rights conferred by Art. 79 and 82, or a Supervisory Authority of its powers.
12.5 Privacy contact: support@alaaqat.com. Alaaqat has not appointed a Data Protection Officer.
Annex 1 — Details of processing
| Subject matter | Provision of a CRM and omni-channel messaging platform: storing the Customer's contacts, companies, deals, tickets, invoices, products and notes; sending and receiving messages through connected WhatsApp, Messenger, Instagram and email channels; broadcasts; automation; analytics on the Customer's own data. |
| Duration | The term of the Customer's Account plus the deletion periods in Section 9 and Annex 4. |
| Nature | Collection, storage, structuring, retrieval, transmission, display, export, erasure. Automated decision-making with legal effect is not performed; automation rules the Customer configures execute the Customer's own logic. |
| Purpose | Enabling the Customer to manage relationships with and communicate with its Contacts. |
| Data Subjects | The Customer's contacts, leads, customers and their representatives; participants in conversations with the Customer; the Customer's own users (as far as they appear inside Customer Data, e.g. as note authors or deal owners). |
| Categories of Personal Data | Identity and contact data (name, phone, email, address, avatar); organisation and role; message content, attachments, voice notes, reactions and delivery metadata; GPS coordinates when a Contact shares a WhatsApp location; commercial data (deals, tickets, invoices, products bought); any value the Customer enters in custom properties or notes; activity history of each record (who changed what, with old and new values). |
| Special categories | Not intended; where the Customer records them, Section 4.3 applies. |
| Storage locations | Relational data: PostgreSQL, Ireland (EEA). Object and conversation data: MongoDB Atlas, Ireland (EEA). Files, media and backups: AWS S3, Ireland (eu-west-1, EEA). |
Annex 2 — Technical and organisational measures (Art. 32)
Access control
- Every Customer Data query is bound to one Account by a global scope and fails closed when the Account context is missing. Cross-account reads raise an exception.
- Role- and permission-based authorisation inside the Account; sensitive actions (delete, export, API keys) are separately permissioned.
- Passwords: minimum 12 characters, hashed with bcrypt; all sessions are invalidated on password change. Two-factor authentication (TOTP) available to every user.
- API keys are hashed at rest, scoped to one Account and an ability list, expire after 180 days, and can be rotated (30-minute overlap) or revoked at any time from the Settings.
- Production debugging tooling is fail-closed: it requires 2FA and an email allowlist and is unreachable otherwise.
Encryption
- TLS 1.2+ on every client connection; HSTS on the production host; session cookies are
Secure,HttpOnly,SameSite. - TLS enforced on the connections to PostgreSQL and MongoDB Atlas.
- Server-side encryption on every S3 bucket; backup archives are additionally encrypted before upload.
- Two-factor secrets and recovery codes are encrypted at rest.
Integrity and availability
- Daily encrypted backups of PostgreSQL and MongoDB; the encrypt-and-restore round trip is covered by automated tests. Retention in Annex 4.
- Append-only audit trail of identity, ownership and access changes on users and accounts; object deletions are logged.
- Rate limiting on authentication and API endpoints; login throttling.
Data minimisation and retention
- Credentials, tokens and authentication headers are redacted in debug tooling.
- Every stored copy of personal data has a bounded retention enforced by a scheduled job (Annex 4).
- Avatars are rendered locally; no personal data is sent to third-party avatar services.
Organisational
- Access to production is limited to the operating team, on named accounts, with 2FA.
- Confidentiality obligations on all personnel.
- Sub-processor flow-down (Section 6).
- Internal reporting path for suspected breaches to the privacy contact (Section 8).
Annex 3 — Sub-processors
3.1 Sub-processors of Customer Data
| Sub-processor | Purpose | Customer Data processed | Location | Transfer mechanism |
|---|---|---|---|---|
| Meta Platforms Ireland Ltd (WhatsApp Business Platform, Messenger Platform, Instagram Messaging API) | Delivery and receipt of messages on the channels the Customer connects | Message content and media in both directions; Contact phone numbers / platform IDs and profile names; GPS coordinates in location messages; Customer Data values the Customer interpolates into template messages; phone-book and history import under Section 4.4 | Ireland / USA | EU–US Data Privacy Framework; Meta's SCCs. Note: Meta acts as an independent controller for parts of this processing under its own terms. |
| Amazon Web Services EMEA SARL (EC2, S3) | Hosting of the application servers and the PostgreSQL database; storage of files, media, voice notes, exports and encrypted backups | All Customer Data | Ireland (eu-west-1) | Hosted in the EEA; AWS Data Processing Addendum |
| MongoDB, Inc. (Atlas) | Managed database for objects, conversations, notes, activity logs | All Customer Data except relational account records | Ireland (AWS eu-west-1) | Hosted in the EEA; MongoDB Data Processing Agreement |
| Pusher Ltd (Channels) | Real-time delivery of updates to the Customer's browser sessions | Transient: new-message notifications carrying message content and the sender's name/avatar; record-change events. Not stored beyond delivery. | Ireland (EU cluster) | Hosted in the EEA; Pusher DPA |
| Google LLC — Maps Platform | Rendering a map for a Contact's shared location | GPS coordinates of a location message, sent from the user's browser to Google when the map is opened | USA | EU–US Data Privacy Framework; Google Cloud DPA |
| Google LLC — OAuth | Optional sign-in of the Customer's users with a Google account | User email and profile — user data, Section 2.2, not Customer Data; listed for completeness | USA | as above |
| Browser push services (Google FCM, Mozilla, Apple) via Web Push | Delivering desktop notifications to the Customer's users who opted in | Transient notification payloads: Contact name and a message preview | USA | The push endpoint is chosen by the user's browser vendor; payloads are encrypted end-to-end (RFC 8291) so the service cannot read them |
3.2 Providers that process only user or billing data (Section 2.2 — Alaaqat as Controller)
| Provider | Purpose | Data |
|---|---|---|
| Paddle.com Market Ltd | Merchant of record for subscriptions and invoicing | Account owner's name, email, billing address, payment method, invoices |
| MailerSend, UAB (Lithuania, EU data region) | Delivery of Alaaqat's own transactional email (sign-in, security, billing, deletion and dormancy notices) | Recipient name and email address, Account name; never Customer Data |
| Google LLC — Workspace (Gmail) | Support correspondence with the Customer's users | Sender name and email, Account name, and whatever the Customer chooses to write; the Customer should not paste Contact data into support requests |
| Google LLC — Tag Manager / Analytics | Website and in-app product analytics, only after analytics consent | Pseudonymous usage events, client ID; never Customer Data |
| Google / Meta / LinkedIn ad-click identifiers | Attribution of a signup to a campaign, only after marketing consent | gclid, fbclid, li_fat_id, utm_* stored on the Account; click IDs pruned after 90 days |
3.3 Not Sub-processors
- Email delivery tracking and debug tooling run inside Alaaqat's own infrastructure and are not third parties; their retentions are in Annex 4.
Annex 4 — Retention schedule
Every retention is enforced by an automated daily job. "Removed on erasure" means the record is deleted by the Account purge (Section 9.2) regardless of its own retention.
| Data | Retention | Removed on erasure |
|---|---|---|
| Contacts, companies, deals, tickets, invoices, products, notes, files | Life of the Account (Customer controls deletion) | Yes |
| Conversation messages | Plan-based: Free 6 months, Starter 12 months, Business 18 months, Enterprise as contracted | Yes |
| Object activity history (old/new values per change) | Life of the object, then 30 days | Yes |
| Contact exports generated by the Customer | 48 hours | Yes |
| Audit trail (identity, ownership, access changes) | 365 days | Yes; a former member's ID is nulled on entries that outlive them |
| Copies of transactional email sent by the platform (user data — Section 2.2) | 30 days from sending | No — see Section 9.5; the deletion confirmation is the last copy to go, 30 days after purge |
Ad-click identifiers on the Account (gclid, fbclid, li_fat_id) | 90 days | Yes |
Campaign source (utm_*, landing page, referrer) on the Account | Life of the Account | Yes |
| API request log (full request payload, unredacted) | 7 days | Yes |
| Debug tooling entries (incl. inbound and outbound provider payloads and email bodies) | 10 days | No (expires by age) |
| Temporary upload files | Expiry set per file at upload (minutes to hours); expired files removed hourly | Yes |
| Personal access tokens | 180 days from issue, or until revoked | Yes |
| Frozen backups — MongoDB (objects, conversations, notes, activity) | 7 days | Rolls off within 7 days of purge |
| Frozen backups — PostgreSQL (accounts, users, audit, sent mail) | Every backup 7 days; then one daily for 7 days, one weekly for 1 week, one monthly for 4 months, one yearly for 1 year | Rolls off with the schedule; a purged Account is out of every backup within 1 year — see note |
| Dormant free Accounts | 12 months inactive + 30 days' notice + 14 days' grace | — |
Frozen backups. Backups are cold copies taken for disaster recovery only. They are encrypted before they leave the database host, stored separately from the live systems, never queried, processed, analysed or accessed in the ordinary course of business, and readable only by the operating team in a restore. They are overwritten on the schedule above and are not restored except to recover from a loss of the live systems, in which case every deletion performed since the backup was taken is re-applied before the Service resumes. For the avoidance of doubt, Customer Data in a frozen backup is not "processed" for any purpose other than its own safekeeping, and the longest a purged Account can remain in any backup is one year.
Version 1.0, effective 1 October 2026. Sub-processor list version: 2026-09-21.