Data Processing Addendum

Data Processing Agreement (DPA)

This edition was adopted on 15 October 2026. It takes effect for a merchant first accepting it under Section 3 of the Terms; material amendments for an existing merchant take effect under Section 13 of the Terms.

1. Roles and Parties

1. The Merchant is the Controller of the personal data of its customers and store visitors.
2. The Provider (Dal Dom Group for Business Services — the Qarari product, qarari.net; Unified Number 7027532691, VAT 302013762100003) is the Processor of that data, processing it on the Merchant's behalf and per its documented instructions, being the Terms, this DPA, and the Merchant's in-app settings.
3. Cross-store aggregated indicators: the Provider produces sector indicators from aggregates in which no cell is displayed unless at least five distinct stores contributed, so it cannot be traced to any store or person. In this activity the Provider acts as a Processor in delivering the Service to the Merchant, and as an independent Controller of the de-identified aggregated indicators that identify no store or person (no personal data remaining after aggregation and anonymization).
4. The governing frame is the Saudi Personal Data Protection Law (PDPL) and its regulations, with GDPR-ready architecture described in Section 10.

2. Scope and Purposes of Processing

Categories of data processed:

Categories of data subjects: the Merchant's customers and store visitors.

Purposes: operating the Service described in the Terms, exclusively — analytics, forecasts, and recommendations for the Merchant; running measured offers and messaging customers on the Merchant's behalf within the lawful-basis gates; billing and support. Neither the Merchant's nor its customers' data is ever sold or shared with third parties for commercial purposes.

Duration: for the term of the Terms, then per Section 8 (deletion).

3. Processing Instructions

The Provider processes personal data only on the Merchant's documented instructions, does not process it for its own purposes outside Section 2, and informs the Merchant if it considers an instruction to violate the PDPL.

4. Technical and Organizational Measures (as actually implemented)

Currently implemented in the Service:

1. At-rest encryption of personal data and cost (LIVE): the customer's personal data (email and phone) and the cost/margin data are encrypted at rest at the application layer with AES-256-GCM under a dedicated data key and a random 12-byte encryption IV per value, with no deterministic encryption (database migration 046). These fields are stored as ciphertext, not readable text, and are decrypted only at lawful read sites. The columnar analytics store keeps a derived numeric copy of the cost figure that is not encrypted this way, because ciphertext cannot be aggregated; it has no disk-level encryption, as stated below. (Correction: this item was previously described as "in progress"; it is now implemented and in force.)
2. Pseudonymization: customer-identity join keys used in analysis are keyed HMAC-SHA-256 digests; raw personal data does not live outside the isolated identity store, and analysis paths read pseudonymized copies restricted to a strict column allowlist (no email, phone, or external identifiers).
3. Credential encryption: platform access tokens are stored encrypted with AES-256-GCM under isolated subkeys and are never written to audit logs.
4. Per-store data isolation: every API is scoped to a single store; one store's data never mixes with another's.
5. Stripping at the boundary: browsing events are stripped of personal identifiers before storage; the IP address is used to derive the city and then discarded.
6. Anonymity in aggregated outputs: any cross-store indicator cell is withheld unless at least 5 distinct stores contributed to it.
7. Standing automatic deletion schedules: anonymous-identity mappings are deleted automatically after 13 months; offer-experiment data is deleted automatically a fixed period after the experiment ends (60-day measurement window + 90 days), with automated verification of completed deletion, after which only non-identifying aggregates survive, plus a 15-month backstop TTL on analytical copies. Two further schedules run on the same footing: raw inbound platform webhook bodies are deleted 90 days after receipt, and a computed-but-undelivered subject-access export file is deleted 30 days after it is produced or immediately on delivery. Both are executed by the retention service (services/lifecycle), which is a deployed and enabled unit.
8. Lawful-basis and attestation gates: the Merchant's per-store messaging attestation, recorded when the Merchant approves the cart-reminder template in both languages with the approving actor, the attestation version and the time, and specific to the reminder purpose and the sends that share its basis; the Merchant's per-store marketing attestation, recorded by the Merchant from its own account in the app dashboard with its version and time, by which the Merchant attests that it holds its customers' consent to receive promotional messages from its store and is responsible for it as Controller, and which the Merchant may withdraw at any time. A delivery gate refuses any message without the Merchant's current messaging attestation under a named reason, refuses any promotional message (such as a reminder carrying a discount, or a suggestion of other products) without the Merchant's current marketing attestation, and evaluates the lawful basis of the cart reminder and the sends that share its basis by the customer's country (Section 10). One-click unsubscribe is enforced before delivery, and email complaints, bounces and unsubscribes reported by the email provider suppress the customer automatically; a customer's suppression and any withdrawal recorded for them always outrank both of the Merchant's attestations. The Service requests no consent from shoppers.
9. Organizational measures: data minimization by design (nothing collected beyond the purposes), and audit logs of sensitive events stripped of personal data and credentials.

Storage encryption status: at-rest encryption of personal data (email/phone) and cost at the application layer is now implemented and in force (Section 4.1, migration 046, AES-256-GCM), alongside credential encryption (4.3) and pseudonymization (4.2). For disk-level storage, the primary database and the columnar analytics store (ClickHouse) are not encrypted at disk/volume level. It is an infrastructure control on the host, not application encryption, and it does not touch the raw personal data (email and phone), which is application-encrypted as described in 4.1. Stated rather than left to be inferred: the analytics store holds a derived numeric copy of the cost figure that is deliberately not application-encrypted, because ciphertext cannot be aggregated and the authoritative encrypted copy lives in the primary database, and that copy is not encrypted at disk level. This DPA claims nothing beyond that.

5. Subprocessors

The Merchant authorizes the following subprocessors; the Provider remains responsible for their performance:

Commerce platforms (Salla — active; and Zid, Shopify, WooCommerce where Qarari is installed from them) are the source of the store's data via their official APIs and the billing channel; they act as the store's platform under their own terms, not as the Provider's subprocessor.

The Merchant is notified at least thirty (30) days before a subprocessor is added or replaced, via the app or the registered email, and may reasonably object; if no data-protection-preserving resolution is reached, the Merchant may terminate the Service.

6. Data Subject Rights (machinery actually built)

The Service has implemented machinery to assist the Merchant with its customers' requests:

1. Access/export: assembly of the data subject's complete data — across all linked identities (including identities merged into the same unit) — from identity, message, consent, suppression, and experiment-participation records, via a Merchant-scoped interface.
2. Erasure: erasure of the data subject's raw personal data across all linked identities, covering identity records, the anonymous-mapping entries in the analytics store (ClickHouse), and experiment artifacts tied to the subject, with every request logged in a permanent request register.
3. Both are available today via a Merchant-scoped API; a Merchant-facing UI is planned.
4. The Provider responds to such Merchant requests without undue delay and within a maximum of thirty (30) days, consistent with the PDPL and its regulations.

7. Incident Notification

The Provider notifies the Merchant without undue delay upon becoming aware of an incident affecting personal data processed on its behalf, with available information on nature, scope, and measures taken. The Provider (as Processor) assists the Merchant (as Controller) in notifying the Saudi Data & AI Authority (SDAIA) within seventy-two (72) hours of becoming aware of the incident where the law so requires, and in notifying data subjects on high risk; the duty to report to the supervisory authority rests with the Controller, and the Processor provides what is needed to enable it.

8. Deletion at End of Relationship

1. Upon uninstallation, synchronization stops immediately and access credentials are invalidated.
2. Store data is retained for ninety (90) days after uninstallation so the Service can resume with the store's history if reinstalled. It then becomes due for automatic deletion within the scope below; where the Platform requires a shorter period, deletion becomes due at that earlier deadline. The process deletes the operational data in its scope and clears specified personal fields, but does not remove every record concerning the Merchant: billing, contract, consent, messaging, installation, intervention-admission and execution, audit and deletion-evidence records remain, as do account and identity skeleton records after the specified fields are cleared. When the wholesale counterparty retention safeguard is triggered, the protected wholesale records and their supporting records also remain, including the wholesale-action record in the analytics database; deletion of the other data in the automatic process's scope continues. Remaining records may still identify the departing Merchant; this clause sets no final deletion date for them. The deletion record states the operations performed and the retained scope. Observations from the primary and analytics databases are dated separately; they are not one simultaneous snapshot or a guarantee of future absence of data. You may request earlier deletion in writing to privacy@qarari.net. We respond within thirty (30) days of the request, stating the deletion scope that can proceed or the reason for refusal. With a counterparty hold, the current written-request procedure refuses before performing any deletion under that request; refusal is not fulfilment of the request or complete deletion. A request that can proceed remains subject to the scope and exceptions stated here. The thirty-day period is a response deadline, not a promise to delete every record within that period.
3. The standing automatic deletion schedules (Section 4.7) apply in all cases.
4. Backups: operational backups are retained for no more than thirty (30) days. A copy restored from a backup is not returned to service until every erasure held in the permanent request register (Section 6.2) has been re-applied to that copy and no entry failed. That register carries one entry per identified data subject, so two classes of deletion sit outside it and are not re-applied by that pass: an erasure carried out after the restored backup was taken, whose register entry is inside that same backup; and a store-wide scrub of a Merchant's own account records, being its name, its contact address and its access credential, for which no entry is written. Where either occurs, the Provider re-applies the deletion as soon as it is identified, and personal data resurfacing in this way is handled as an incident under Section 7.

9. Cross-Border Transfers

Data is hosted and processed on servers in Germany (EU) at Hetzner, and some data is processed by other subprocessors outside the Kingdom (Section 5, e.g. Mailgun in the United States). Because the primary hosting location is outside the Kingdom, transfers of personal data are carried out under the Personal Data Transfer Regulation of SDAIA, relying on Standard Contractual Clauses (SCCs) or equivalent approved safeguards. Each product's name and its Platform category label are also sent to DeepSeek in the People's Republic of China for the classification in Section 5; no customer or order data is sent to it. For EU/EEA merchants, their data is hosted in the EU and is also processed outside the EU/EEA by Mailgun in the United States, for email, under the safeguards stated above, and by DeepSeek in the People's Republic of China, for product names and category labels only, for which no transfer safeguard is claimed.

10. GDPR Readiness

The Service's architecture determines each customer's legal regime by their country, not their network address. GCC customers are handled under PDPL: the cart reminder is sent to them on legitimate interest after the Merchant's messaging attestation. EU/UK customers are handled under GDPR: the cart reminder is sent to them only on the basis of the Merchant's recorded messaging attestation as Controller, and only to an existing customer of the store, meaning one with a prior completed order at the store; it is refused for anyone else under a named reason. A customer whose country is unknown or outside both regimes is handled under the rule the store's platform declares for that case: PDPL on Salla and Zid, while on the other platforms the cart reminder is not sent to them and is refused under a named reason. In every case promotional messages are sent on the basis of the Merchant's marketing attestation (Section 4.8), and the Service collects no consent from shoppers.

(Precise disclosure: on platforms that send the country as a localized text label rather than a code — as in some Salla configurations — an EU customer may not be distinguishable and is treated under the platform rule (PDPL); this is a documented, low-impact gap on a GCC platform, whereas other platforms send an ISO country code and detection is exact. See Section 4 of the Privacy Policy published at qarari.net/privacy/en.)

EU/EEA merchants are covered by a separate version of this DPA that is conformant with Article 28 of the EU GDPR, accompanied by the EU Standard Contractual Clauses (SCCs), whose binding language is English, provided to them on installation from an EU platform.

11. Audit

The Provider gives the Merchant, on reasonable request and no more than once a year, information sufficient to demonstrate compliance with this DPA through reports and questionnaires and available attestations. On-site audits are used only where required by a supervisory authority or law, on reasonable prior notice, at the Merchant's reasonable cost unless the audit reveals a material breach by the Provider.