This English text is a convenience translation; the Arabic version is the binding original and prevails on any conflict. Effective date: 25 July 2026.

Data Processing Agreement (DPA)

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; its at-rest protection is the disk-level control stated in the status disclosure 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 are BUILT BUT NOT YET IN FORCE, and are stated as such rather than counted among the above: 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 implemented in the retention service (services/lifecycle), which is not yet a deployed unit; neither may be relied on until it is.
8. Lawful-basis and consent gates: an append-only consent ledger, a delivery gate that blocks any message the customer's country-determined lawful basis does not permit, one-click unsubscribe enforced before delivery, and automatic suppression on email complaints and bounces. *(Disclosure: the consent-capture surface — the pixel banner — is still being built and is not yet live; the consent engine and gates are implemented, and until the capture surface ships, marketing messages to GDPR regions stay blocked.)*
9. Organizational measures: data minimization by design (nothing collected beyond the purposes), and audit logs of sensitive events stripped of personal data and credentials.

Explicit disclosure of status and what remains: 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). What remains is disk/volume-level encryption of the stored data as a whole, meaning the primary database and the columnar analytics store (ClickHouse) alike, and it is in progress rather than finished. 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, so that copy's at-rest protection rests on the same disk-level control still in progress. 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. Data is thereafter retained per the Privacy Policy, and complete deletion is executed upon the Merchant's written request (privacy@qarari.net) within thirty (30) days of the request. *(Deliberate drafting note: store-wide deletion is on request, not automatic after a fixed period — this DPA does not promise an automated store-wide purge that is not implemented.)*
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. Resend 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. For EU/EEA merchants, their data remains within the EU by virtue of the hosting location.

10. GDPR Readiness

The Service's architecture determines each customer's legal regime by their country, not their network address: EU/UK customers are handled under GDPR rules (no marketing messages without recorded explicit consent; the consent ledger is built to satisfy Article 7 demonstrability), GCC customers under PDPL, and all others under the stricter rule.

*(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 README.md.)*

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.