LoyaFlow Data Processing Agreement (DPA)

This Data Processing Agreement ("DPA") forms part of the agreement between Abdelfattah el Alouani (Wülflingerstrasse 165, 8408 Winterthur, Switzerland — "LoyaFlow", the "Processor") and the Merchant (the "Controller") for the use of the LoyaFlow platform (the "Service").

1. Roles and scope

1.1 For End Customer Data — personal data of the Merchant's customers processed in the Service — the Merchant is the controller and LoyaFlow is the processor. LoyaFlow processes End Customer Data only on the Merchant's documented instructions, this DPA and the use of the Service's functions being those instructions, unless required otherwise by law that LoyaFlow is subject to (in which case LoyaFlow informs the Merchant before processing, unless the law prohibits it).

1.2 This DPA does not apply to data for which LoyaFlow is itself controller (Merchant account, billing and support data) — that processing is described in the Platform Privacy Notice.

1.3 If LoyaFlow processes End Customer Data outside the Merchant's instructions, it is considered controller of that processing and liable as such.

2. Details of the processing (Art. 28(3) GDPR)

3. Processor obligations

LoyaFlow shall:

• (a) Instructions. Process End Customer Data only as described in Section 1.1 and inform the Merchant if, in its opinion, an instruction infringes data protection law.
• (b) Confidentiality. Ensure persons authorised to process the data are bound by confidentiality (contractual or statutory).
• (c) Security. Implement and maintain the technical and organisational measures in Annex II, reviewing and updating them as technology evolves — including encryption in transit and at rest, strict tenant isolation, keeping the Service updated, and continuous monitoring.
• (d) Sub-processors. Engage sub-processors only under Section 4.
• (e) Data subject rights. Assist the Merchant, insofar as possible and considering the nature of the processing, in responding to data subject requests. The Service provides self-service tooling: customer export and deletion in the dashboard, and a public request channel on the pass page (unsubscribe executes immediately; export and deletion requests are queued to the Merchant for fulfilment).
• (f) Breach notification. Notify the Merchant without undue delay, and in any event within 48 hours, after becoming aware of a personal data breach affecting End Customer Data, with the information reasonably required for the Merchant's own notification duties, and cooperate in the investigation and mitigation.
• (g) Assistance. Taking into account the nature of the processing and the information available, assist the Merchant with its obligations under Arts. 32–36 GDPR (security, breach notification, DPIAs, prior consultation).
• (h) Deletion and return. Proceed per Section 9 at the end of the services.
• (i) Audits. Make available the information reasonably necessary to demonstrate compliance with Art. 28 and allow audits under Section 8.

4. Sub-processors

4.1 The Merchant grants a general written authorisation for the sub-processors listed in Annex I.

4.2 LoyaFlow will give at least 30 days' notice (dashboard and/or email) before adding or replacing a sub-processor. The Merchant may object on reasonable data protection grounds; if no solution is found, the Merchant may terminate the affected subscription with effect from the change, with a pro-rata refund of prepaid fees for the remaining period.

4.3 LoyaFlow imposes on each sub-processor, by contract, data protection obligations providing an equivalent level of protection to this DPA, and remains fully liable to the Merchant for its sub-processors' performance.

5. International transfers

5.1 Primary storage and processing take place in Switzerland/EEA data-centre regions. Transfers between Switzerland, the EEA and the UK rely on their mutual adequacy decisions and require no additional safeguards.

5.2 Sub-processors in the United States (Annex I) receive limited data sets under the EU–U.S. Data Privacy Framework and its Swiss and UK extensions, and/or Standard Contractual Clauses, as indicated in Annex I.

6. Data protection impact assessments

The Merchant is responsible for its own DPIAs. LoyaFlow provides the descriptions in this DPA (including Annexes) as the factual basis and reasonable additional information on request.

7. Liability

Liability under this DPA is subject to the liability clause of the Terms of Service, except where data protection law mandates otherwise (Art. 82 GDPR allocation between controller and processor remains unaffected).

8. Audits

Upon 30 days' written notice, no more than once per year (except after a material breach or where required by a supervisory authority), the Merchant may audit LoyaFlow's compliance with this DPA — in the first instance through documentation, certifications and audit reports of LoyaFlow and its infrastructure providers; an on-site audit, where strictly necessary, is at the Merchant's cost, during business hours, without access to other merchants' data.

9. End of processing (wind-down)

9.1 On termination or expiry of the Merchant Agreement: passes are voided immediately; End Customer Data is retained for 30 days (security, fraud prevention, reactivation) during which the Merchant can export it; after 30 days it is deleted, except where retention is required by law (in which case data is isolated and protected until the legal ground lapses). Backups purge on their own rotation cycle within a bounded period.

9.2 Deletion covers all sub-processors (propagated through the wind-down jobs: wallet pass revocation at Apple/Google, database and storage purge).

Annex I — Authorised sub-processors (v1.0)

Note: Paddle (payments/Merchant of Record) processes the Merchant's billing data, not End Customer Data, and therefore appears in the Platform Privacy Notice, not in this Annex.

Annex II — Technical and organisational measures (TOM, v1.0)

Architecture & tenant isolation

• Strict multi-tenant isolation enforced in the database via row-level security on every tenant table, keyed to the merchant's server-side session identity — clients never supply their tenant id.
• Writes to program data go exclusively through a controlled server-side API surface (stored procedures); no direct table writes from clients.
• The anonymous (pre-login) surface is limited to five capability-scoped functions (enrolment and pass pages), each scoped by an unguessable identifier; no anonymous table access.

Encryption & secrets

• TLS for all data in transit; provider-managed encryption at rest for database, storage and backups.
• Pass-signing private keys stored encrypted (AES-256, passphrase-protected) and delivered to runtime exclusively via a managed secret store (GCP Secret Manager); never in code or images.
• API keys stored as salted hashes (shown once); per-pass authentication tokens; public pass links are capability URLs (unguessable UUIDs).

Operations

• Least-privilege service accounts per workload; boot-time validation of certificates (expiry and chain) with fail-fast on misconfiguration.
• The Service is kept updated and monitored: dependency updates, structured logs, failure monitoring with retries and dead-letter rescue for asynchronous jobs, and abuse limits (rate caps, instance caps, payload caps) on public endpoints.
• Documented, versioned database schema (append-only migrations); production changes reviewed and verified against a staging validation loop before deployment.

Data lifecycle

• Logical deletion followed by a 30-day retention window, then purge (PII phase); wallet passes voided immediately on deletion.
• Short retention for technical/request logs; device logs endpoint capped and not retained beyond operational need.
• Point-in-time recovery and backups on production, purging on rotation.

People & process

• Access to production restricted to authorised personnel bound by confidentiality; personal accounts, MFA on provider consoles.
• Breach playbook: detect → contain → assess → notify controller within 48 h → document.

Version 1.0-draft · Effective date: [DATE] · Binding language: English.