Data Processing Agreement (DPA), Subprocessors & Standard Contractual Clauses

IN FORCE. See 00-README. This DPA forms part of the Terms of Service / Merchant Agreement between CIQRA and a Merchant. GDPR Art. 28.

Legal basis. Every provision below rests on one of three things: a measured fact about the platform (cited to file and line), a rule of law (cited to the instrument and article in the Legal Basis Register), or a commercial choice CIQRA has made where the law leaves it open. Prepared and adopted by CIQRA OÜ.

🔴 Annex IV / SCC Annex III is out of date and must be regenerated from the Subprocessor List before this DPA is offered to any Controller — two US AI subprocessors (Voyage AI, fal.ai) were missing from it, and the assumption that AI inference stays inside the EEA was incorrect.

Processor: CIQRA OÜ, registry code 16465907, Veskiposti tn 2, Tallinn, 10138, Estonia · privacy@ciqra.com Controller: the Merchant accepting this DPA. In force from: 2026-08-09 · Version: 1.0 · Adopted by: CIQRA OÜ

1. Roles and scope

1.1 For Customer Personal Data processed through the Merchant's Storefront and account, the Merchant is the Controller and CIQRA is the Processor, processing only on the Controller's documented instructions to provide the Services.

1.2 CIQRA is an independent Controller for data it processes for its own purposes (Merchant account/billing, platform security/fraud, aggregate analytics, its own marketing) — governed by the Privacy Policy, not this DPA.

1.3 Stripe acts under its own agreements as an independent controller/processor for payment data; CIQRA does not process raw card data (PCI DSS SAQ A).

✅ Measured 2026-08-09 (lane/L @ 81807dc44): the no-raw-card-data claim holds. Storefront card fields are Stripe Elements iframes (Ciqra.Api/Storefront/Themes/default/checkout-payment.liquid:99,110,117 — data-stripe-field mount points), and the platform's declared raw-PAN seam has no implementation: IRawCardPaymentProvider / RawCardPaymentRequest (Ciqra.Modules.Payment/PaymentAbstractions.cs:103-119, labelled SAQ D in source) is referenced only by its own declaration. Local acquirers route through the hosted/3DS path (INativePaymentProvider.cs:48). Named condition: the SAQ A posture holds only while that interface stays unimplemented — implementing it moves the attestation to SAQ D. Treat as a monitored invariant. Full measurement: Subprocessor List §3.

1.4 This DPA prevails over any conflicting data-processing term in the ToS/Merchant Agreement.

2. Instructions

2.1 CIQRA processes Customer Personal Data only on the Controller's documented instructions (including as configured in the platform and as set out in this DPA and Annex II), including for international transfers, unless required by EU/Member-State law (in which case CIQRA informs the Controller unless legally prohibited).

2.2 CIQRA will inform the Controller if, in its opinion, an instruction infringes GDPR or other data-protection law.

CIQRA's determination: this mirrors Art. 28(3) final paragraph. No mechanism routes or records such notifications; it is a manual obligation on CIQRA staff.

3. Confidentiality

CIQRA ensures persons authorised to process the data are bound by confidentiality and are trained/access-limited on a need-to-know basis.

4. Security (Art. 32)

CIQRA implements appropriate technical and organisational measures (Annex III), including tenant isolation via PostgreSQL row-level security with SET LOCAL app.tenant_id, per-tenant scoping and global query filters, encryption in transit (and at rest where applicable), access control/least privilege, secrets management, logging/monitoring, backups, and secure SDLC. Measures may evolve provided the level of security is not reduced.

5. Subprocessors

5.1 The Controller gives general authorisation for CIQRA to engage subprocessors listed in Annex IV, and for onward subprocessors, provided CIQRA: (a) imposes data-protection obligations equivalent to this DPA (incl. SCCs where transfers occur); and (b) remains liable for their performance.

5.2 Change notice & objection. CIQRA will notify the Controller of intended additions/replacements of subprocessors with at least 30 days' prior notice (e.g. via the subprocessor page with subscription/email alerts). The Controller may object on reasonable, documented data-protection grounds within 30 days of notice. The parties will work in good faith to address the objection; if it cannot be resolved, the Controller may, as its sole remedy, suspend or terminate the affected Service and receive a pro-rata refund of prepaid fees for the terminated portion. If the Controller does not object within the period, the change is deemed accepted. [Approach: Shopify/AWS DPA subprocessor objection-with-consequence standard.]

5.3 Emergency additions. Where CIQRA must engage a new subprocessor urgently to protect security or maintain the Services (e.g. incident response, provider failover), it may do so before the notice period elapses and will notify the Controller without undue delay thereafter; the Controller's objection right in §5.2 then applies retrospectively.

6. Data-subject rights

CIQRA will, taking into account the nature of processing, assist the Controller by appropriate technical and organisational measures to respond to data-subject requests, and will forward to the Controller any request it receives directly relating to the Controller's data.

7. Assistance (Art. 32–36)

CIQRA will assist the Controller with security, personal-data-breach notification (see doc 07), data-protection impact assessments, and prior consultation, taking into account the information available to CIQRA.

8. Breach notification

CIQRA will notify the Controller without undue delay and in any event within 72 hours after becoming aware of a personal-data breach affecting the Controller's data, with the information required to support the Controller's Art. 33/34 obligations. Procedure: Data Retention & Breach Notification.

CIQRA's determination: Art. 33(2) requires a processor to notify the controller without undue delay and sets no 72-hour limit — the 72-hour clock is the controller's duty to the supervisory authority under Art. 33(1). CIQRA is therefore taking on a stricter obligation than the GDPR imposes on a processor, deliberately, so Merchants can meet their own clock. That is a commercial commitment: it depends on detection capability, which this reconciliation did not measure. See Retention & Breach B.3 — the existence of the Art. 33(5) breach register was also not verified.

9. Deletion / return

On termination, and at the Controller's choice, CIQRA will delete or return Customer Personal Data and delete existing copies, within 30 days (after any post-termination export window), unless EU/Member-State law requires storage (e.g. 7-year accounting records) — in which case CIQRA protects it and limits processing. Backups are purged on the rolling backup cycle (30 days measured default, BackupSchedule.cs:27). CIQRA will, on written request, provide written certification of deletion. [Approach: Shopify/Stripe DPA deletion-certification standard.]

10. Audits

CIQRA makes available the information necessary to demonstrate Art. 28 compliance and allows for and contributes to audits, on the following tiered basis (the industry-standard "compromise ladder"): (1) in the first instance, CIQRA satisfies audit requests by providing its documentation, security summaries, and third-party certifications/audit reports (e.g. ISO 27001, SOC 2) where available; (2) if those are insufficient to demonstrate compliance, the Controller (or an independent, mutually-agreed auditor bound by confidentiality) may conduct an audit/inspection no more than once per 12 months (and whenever legally required or following a breach), on reasonable prior written notice (≥30 days), during business hours, without disrupting operations, at the Controller's cost, and not covering other customers' data or CIQRA confidential information. [Approach: Shopify/AWS/Stripe DPA tiered audit standard.]

11. International transfers

11.1 Where CIQRA or a subprocessor transfers Customer Personal Data outside the EEA without an adequacy decision, the EU Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914) are incorporated by reference and apply (module selected per the relationship — typically Module 2, Controller-to-Processor, and Module 3, Processor-to-Processor, for onward transfers), together with any supplementary measures. Annex I/II/III of the SCCs are populated from the Annexes to this DPA (see §14). For UK transfers, the UK International Data Transfer Addendum (IDTA) applies; for Switzerland, the Swiss FADP amendments apply.

🔴 CIQRA's determination: the SCC coverage described here is narrower than the actual transfer set. As at 2026-08-09 the non-EEA recipients include four US AI providers (Anthropic, OpenAI, Voyage AI, fal.ai — the last two absent from every prior Annex IV), Stripe US flows, Cloudflare, hCaptcha, the consent-based ad platforms, and Turkish SMS providers with no identified transfer basis. There is no AI gateway keeping inference inside the EEA — that earlier claim was incorrect and has been withdrawn (AI Terms §1). CIQRA has not verified that executed SCCs exist for the AI providers, and the Transfer Impact Assessment referenced in §11.2 was not located. Annex IV must be regenerated from Subprocessor List before this DPA is offered to any Controller.

11.2 Transfer Impact Assessment. CIQRA commits to carry out, and to keep under review, a Transfer Impact Assessment (TIA) for restricted transfers (assessing the destination country's laws and the effectiveness of the SCCs plus supplementary technical/organisational measures such as encryption and data minimisation), and to make its assessment available to the Controller on request. [Approach: post-Schrems II TIA commitment (EDPB Recommendations 01/2020).]

12. Liability

Each party's liability under this DPA is subject to the limitations in the Terms of Service §11, to the extent permitted by law and without limiting rights data subjects have under the SCCs/GDPR.

CIQRA's determination: capping DPA liability by reference to the ToS cap is standard drafting, but its effect on Art. 82 claims is limited by law: a data subject's right to compensation cannot be contracted away, and Art. 82(4) joint liability between controller and processor operates regardless of the parties' allocation. The clause governs the inter-party position only. The clause is subject to the mandatory rules of Estonian law. CIQRA's determination is that the term applies to the maximum extent Estonian law permits and no further: where a mandatory rule limits it, the mandatory rule prevails and the remainder of the clause stands severed and effective (VÕS / TsÜS, Legal Basis Register rows 3.4 and 5.4).

13. AI processing (zero-retention)

13.1 Where the Controller uses AI features on its data, CIQRA processes Customer Personal Data through AI/LLM subprocessors (Annex IV) only as needed for the requested feature, under business/commercial terms requiring no training on the data and minimised retention (short-term abuse-monitoring only, or zero-data-retention where configured), with data-minimisation and content-safety filtering. See the AI Terms.

13.2 CIQRA applies data-minimisation to avoid sending unnecessary personal data to models. The Controller must not instruct CIQRA to process special-category or excessive personal data via AI features without its own lawful basis and appropriate safeguards. EU AI Act transparency obligations (Art. 50) are supported at platform level.

CIQRA's determination: data minimisation for AI is stated as a practice. This reconciliation did not verify what is actually sent to the four providers, nor locate a filter that strips personal data from prompts. Given that AI calls leave the EEA (AI Terms §2.4), what is in the payload is the whole question. Unmeasured.

14. Annexes (SCC-aligned)

Annex I — Parties, description of processing, competent SA

A. Parties.

Data exporter (Controller): the Merchant — identity/contact per its account. Role: Controller of Storefront Customer data.
Data importer (Processor): CIQRA OÜ, Tallinn, Estonia; privacy@ciqra.com. Role: Processor providing the e-commerce/CMS platform and CIQRA Pay facilitation.

B. Description of processing.

Categories of data subjects: the Merchant's Customers/shoppers; the Merchant's own staff/users; recipients of the Merchant's marketing; reviewers/UGC authors.
Categories of personal data: identity & contact (name, email, phone, addresses); order & transaction data (items, amounts, order history — no raw card numbers); account credentials (hashed); communications & support; marketing preferences/consent; device/usage/log data & identifiers; UGC (reviews/Q&A); and any additional data the Merchant chooses to collect via its Storefront/custom fields.
Special categories: not intended; only if the Merchant configures collection under its own lawful basis (discouraged; the Merchant is responsible).

CIQRA's determination: "not intended" is accurate as a design position but is not enforced — nothing prevents a Merchant configuring a field that collects special-category data. The allocation of responsibility to the Merchant is correct under Art. 28, but CIQRA would still be processing it.

Frequency: continuous, for the duration of the Services.
Nature & purpose: hosting, storage, display, order processing, search/recommendation, communications, analytics as instructed, AI-assisted features (zero-retention), and platform operation/security.
Duration: for the term + deletion/return period (§9) and legal-retention exceptions.

C. Competent supervisory authority: Estonian Data Protection Inspectorate (Andmekaitse Inspektsioon) as CIQRA's lead, without prejudice to the Controller's own lead SA.

CIQRA's determination: identified from CIQRA's Estonian main establishment; no Art. 56 analysis performed. See Retention & Breach B.2.

Annex II — Technical & organisational measures

See Annex III below (same content); measures include tenant isolation (RLS), encryption in transit/at rest, access control & MFA, least privilege, secrets management, logging/monitoring, secure SDLC, backups, incident response, vendor management, and PCI SAQ A scope for payments.

Annex III — Security measures (summary)

Tenant isolation: PostgreSQL row-level security (SET LOCAL app.tenant_id, PgBouncer-safe), base-entity tenant scoping, global query filters, NOBYPASSRLS role, cross-tenant isolation test harness as a CI merge-gate.
Access control: authentication (ASP.NET Identity + OpenIddict), RBAC, MFA for privileged access, least privilege, token↔tenant binding.
Encryption: TLS in transit; encryption at rest (Azure platform encryption); centralised secrets/key management with Azure Key Vault + envelope encryption (hardening item G-02 — in progress; confirm live status before launch).

✅ Measured 2026-08-09 (lane/L @ 81807dc44): this measure is live, not planned. Ciqra.Api/Program.cs:94 calls builder.AddCiqraKeyVault; envelope encryption is implemented as a Key Vault KEK (Ciqra.Api/Secrets/AzureKeyVaultKek.cs) wrapping per-tenant data keys (Platform.Persistence/Cryptography/TenantCryptographyService.cs, TenantDataKeyConfiguration.cs, TenantDekStore). Tenant isolation via PostgreSQL row-level security is applied across 35 migration files carrying ROW LEVEL SECURITY. The "hardening item G-02" annotation on this row is out of date and should be removed.

Payments: SAQ A — no raw PAN on CIQRA systems (Stripe hosted fields).
Data residency: all hosting/compute/DB/storage/secrets on Microsoft Azure in Germany (West Central primary, North DR) — core personal data does not leave the EU/EEA.
Monitoring & IR: logging/observability (OpenTelemetry → Grafana Cloud EU + Sentry EU — in progress), rate limiting/lockout, breach procedure (doc 07).
Resilience: backups (30 days measured default, BackupSchedule.cs:27; configurable 1–365), and point-in-time recovery (PITR) + tenant restore runbook (item P-15 — planned; confirm live status before launch).
Secure SDLC & hardening: security review, isolation tests, 1.0 hardening pass.

Some measures are planned/in-progress and marked; confirm live status before launch.

CIQRA's determination: this caveat is correct in principle and should be narrowed before launch, because at least one measure marked planned (Key Vault / envelope encryption) is in fact live. A blanket "some measures are planned" over an annex that is largely implemented understates CIQRA's actual security posture, while leaving the reader unable to tell which rows to discount. Re-mark each Annex II row individually against the live deployment.

Annex IV — Authorised subprocessors

The authoritative, versioned subprocessor list is maintained in the standalone Subprocessor List and forms Annex IV of this DPA and Annex III of the incorporated SCCs. Summary of the core stack:

Microsoft Azure — Germany West Central (Frankfurt) primary + Germany North DR — hosting, compute (Container Apps), database (PostgreSQL Flexible Server), media (Blob Storage), secrets/keys (Key Vault). All core processing is intra-EEA.
Stripe — payments (independent controller/processor; EU + US; SCCs for US flows).
Cloudflare — CDN/WAF/DDoS (edge; EU data-localization; SCCs, US entity).
Azure Communication Services (ACS) Email (primary) + Amazon SES, EU region (fallback) — transactional email.
Grafana Cloud (EU) + Sentry (EU region) — observability (OpenTelemetry).
OpenAI and Anthropic — AI inference (no-training terms; SCCs for US inference), feature-triggered only.
Consent-based (Google, Meta, TikTok) and Merchant-opt-in marketplace channels — see the Subprocessor List §5.
Typesense — self-hosted on Azure (internal component, not a separate subprocessor).

Because core processing is EU-native (Azure Germany), SCCs are required only for the non-EEA-touching providers (Stripe US flows, OpenAI/Anthropic US inference, Cloudflare US parent, consent-based ad platforms). See the Subprocessor List for the full table, entities, and transfer bases.

🔴 CIQRA's determination: the second half of this sentence is wrong as written. Core hosting is EU-native, but the list of "non-EEA-touching providers" omitted Voyage AI and fal.ai, and the sentence elsewhere relied on an AI gateway that does not exist. Corrected set: Stripe US flows, Anthropic, OpenAI, Voyage AI, fal.ai (all US, all reached directly), Cloudflare US parent, hCaptcha, consent-based ad platforms, and TR SMS providers. See Subprocessor List §§4–5.

Provision register (this document)

Provision	Basis	Where
—	✅ (A) measured SAQ A holds; raw-PAN seam unimplemented — one named condition	§1.3
unlawful instruction	(B) manual obligation, no mechanism	§2.2
72h processor notification	(B) stricter than Art. 33(2) requires; voluntary commitment	§8
SCCs	🔴 (A) transfer set understated; TIA not located	§11.1
liability cap	(B) cannot limit Art. 82; inter-party only	§12
minimisation	(B) prompt contents unmeasured — the whole question, given transfers leave the EEA	§13.2
special categories	(B) design position, not enforced	Annex I
competent SA	(B) no Art. 56 analysis	Annex I.C
encryption / Key Vault	✅ (A) measured LIVE — "G-02 planned" annotation is out of date	Annex II
"some measures planned"	(B) caveat understates actual posture; re-mark rows individually	Annex II
EU-native note	🔴 (A) sentence wrong as written; corrected recipient set given	Annex IV

Composition: 3 measured facts · 8 declared positions · 1 correction of an out-of-date "planned" marking (in CIQRA's favour) · 1 correction against it (Annex IV).

End of DPA . See: Privacy Policy · Data Retention & Breach · TR overlay (SCC-TR for KVKK).