Schedule 7 — Data Processing Particulars

This is Schedule 7 to the Fleet Partner Agreement ("FPA"). It is the document referred to in clause 15.2 FPA: "In respect of each category of Personal Data processed via the Platform, the controller/processor allocation is as set out in Schedule 7." The list of schedules describes it as "Controller/processor allocation per data category; categories of data subjects and Personal Data; security measures; sub-processors; cross-reference to the DPA." This document supplies exactly that.

It requires no separate acceptance. It becomes binding through the signed Fleet Partner Agreement. There is no tick box for it.

It is the authoritative allocation. The privacy notices (datenschutz, datenschutz-fahrer, datenschutz-partner) summarise the allocation for the respective data subjects. Where a summary and this Schedule differ on an individual category, this Schedule prevails — the notices only describe it.

1. Parties

• Emaride EU S.à r.l., société à responsabilité limitée under Luxembourg law, represented by its sole manager Ramez Mohamad Alkhalaf, Luxembourg ("Emaride"). Lead supervisory authority: CNPD, Luxembourg (one-stop shop, Art. 56 GDPR).
• The fleet partner named in the Fleet Partner Agreement ("Fleet Partner"), with the supervisory authority competent for it.

2. Separate Controllers — Art. 26 GDPR Expressly Excluded

Each party determines the purposes and means of its own processing itself and on its own responsibility. There is no joint determination of purposes and means between Emaride and the Fleet Partner.

Art. 26 GDPR (joint controllership) therefore does not apply, and no arrangement under Art. 26(1) is concluded. The parties expressly exclude joint controllership. Accordingly there is no joint allocation of responsibilities to be determined and no essence of an arrangement to be made available to data subjects under Art. 26(2).

The transfer of data between the parties is therefore a controller-to-controller transfer and not processing on behalf of a controller under Art. 28 GDPR. The consequences are deliberate and are stated here so that neither party assumes the other's position:

• Each party needs its own legal basis for its own processing and bears responsibility for it.
• Each party fulfils its own information duty under Arts. 13 and 14 GDPR towards the data subjects it processes.
• Requests from data subjects are answered by the party that processes the data for its own purpose. The other party forwards the request and names the responsible point of contact.
• A complaint about one party goes to the supervisory authority competent for that party.
• Each party is liable under Art. 82 GDPR for its own processing. There is no chain of instructions that shifts that liability.

Where a party does process on the other's instructions, the data processing agreement dpa-fleet-partner applies to that processing alone (clause 15.2 FPA). Clause 3 below states, for each category, whether that is the case. As at this version it is the case for no category of the ordinary Platform operation.

Why this is spelled out: a de facto assumption of joint controllership would create obligations under Art. 26(1) and (2) and a joint responsibility towards data subjects that the processes of neither party support. Naming the allocation is cheaper than litigating it afterwards.

3. Allocation per Data Category

In none of these categories is one party the processor of the other. Wherever the table says "separate controller", Art. 28 GDPR does not apply and dpa-fleet-partner is not engaged. It is engaged only in the cases listed in clause 1 of that document, none of which forms part of the ordinary operation of the Platform.

Police clearance, medical fitness and company records. Emaride can require a police clearance certificate for every driver as a platform-wide minimum standard; the requirement is switched on by default. While it is switched on, the certificate is uploaded in the Platform like the other driver records, reviewed by Emaride, and a driver is approved only once a reviewed certificate is on file. It is data relating to criminal convictions and offences within the meaning of Art. 10 GDPR and belongs to the category "driver master data and records" above; retention is set out in datenschutz-fahrer. A proof of medical fitness to drive is not requested in the Platform in the EU markets; the obligation under clause 5.1(d) FPA is evidenced outside the Platform, and that record remains with the Fleet Partner under clauses 5.2 and 14.2 FPA. Company-level records under clause 4.3 FPA are uploaded in the Platform; which records, what is stored and who has access is set out in clause 3 of datenschutz-partner. Emaride processes them as a separate controller for the approval check, as with the driver and vehicle records above. The Platform requests no special categories of personal data under Art. 9 GDPR.

4. Data Minimisation Towards the Driver

Before the driver accepts the ride, they see only the passenger's first name, the pickup and drop-off address, and the verification status of the ride — the narrowest set that Art. 5(1)(c) GDPR would allow. The phone number, the rating average and count, the ride count, and the payment-type indicator are disclosed only after the driver has accepted the assignment. This closes the deviation that an earlier version of this Schedule recorded as an open item before go-live (see "Closed", below); datenschutz clause 5 describes the same two-stage state.

Timing. ride-customer-info returns a stage of either pre_accept or post_accept. Before the driver has accepted the assignment (stage: pre_accept), the phone number, the rating average and count, the ride count, and the payment-type indicator are not loaded at all — not merely withheld from the response, but never queried, so a driver who declines the ride, or lets it lapse, never received them. Acceptance flips a server-side flag on the booking (bookings.driver_accepted_at, set by the driver-response function); a driver who is later re-dispatched a different ride starts that ride's decision window at pre_accept again. Once the driver has accepted (stage: post_accept), the full set is disclosed, because the driver ride screens need it for the remainder of the ride (contacting the passenger, showing their standing).

Closed. An earlier version of this Schedule recorded the pre-acceptance loading of the phone number, the rating, the trip count, and the payment method as an open item before go-live: none of them are necessary to carry out the individual ride, and their disclosure before the driver had made a decision was a deviation from Art. 5(1)(c) GDPR. It was corrected in the product (commit range ending fix(privacy): Fahrgastdaten erst nach Fahrtannahme, Art. 5 Abs. 1 lit. c (#60), 2026-08-22) rather than talked away in this Schedule, as the prior text already committed to. The Fleet Partner ensures that its drivers use the passenger data only for the individual ride, do not store it beyond the ride, do not pass it on, and do not use it to contact the passenger afterwards (clause 15.3 FPA). Contacting a passenger outside the Platform is also a breach of the anti-circumvention provisions of the Agreement.

5. Categories of Data Subjects and of Personal Data

Data subjects

• Passengers — consumers and, in the case of business bookings, the authorised employees of corporate clients. A ride booked for business purposes is, in data protection terms, the same processing as one booked privately.
• Drivers of the Fleet Partner, including an owner who is approved as a driver.
• Contact persons of the Fleet Partner — owner, management, managers with Platform access.
• Emaride staff and mandated reviewers, in so far as their actions are recorded in the change log.

Categories of personal data

No special categories of personal data (Art. 9 GDPR) are requested. Data relating to criminal convictions and offences (Art. 10 GDPR) is processed in the form of the police clearance certificate, where Emaride requires it — see the note at the end of clause 3.

6. Security Measures

The technical and organisational measures under Art. 32 GDPR are set out in dpa-fleet-partner clause 5 and are not repeated here, so that there is a single place to maintain them.

The Fleet Partner implements appropriate security measures of its own for its own processing (clause 15.3 FPA). Because the parties are separate controllers, neither party's measures replace the other's; each answers for its own level of protection.

7. Sub-processors of Emaride

Emaride engages the following processors for its own processing. The table states the purpose and the basis on which data is transferred; drivers and passengers are affected in so far as their data is processed in the service concerned.

Three of the eleven are not currently in operation. Twilio, Apple and Google are marked "not currently in use" above: SMS phone login is switched off at the platform and removed from the app, and Apple and Google single sign-on are not enabled. No personal data reaches these three providers at present. They are retained in the list because they are technically provided for and because clause 6 of the DPA requires 30 days’ advance notice before a sub-processor is put into operation.

For the state of conclusion, Emaride's processor register is authoritative. It records, for each of these eleven providers, the appointment check, the agreement with its date and source, the sub-processor chain, the authorisation, and the objection period. It is deliberately not duplicated here: a second copy would only create a second place to fall out of date. As at the date of this Schedule, none of the eleven agreements is recorded there as concluded; concluding them is a precondition for going live, and the "Basis" column above therefore describes the requirement, not the state achieved.

Changes to this list follow dpa-fleet-partner clause 6: information at least 30 days in advance, right to object within 30 days.

In so far as Stripe carries out the know-your-business, anti-money-laundering, and sanctions screening, it does not act on Emaride's instructions but in order to meet its own regulatory obligations. For that processing it is a separate controller, not a processor of Emaride. Emaride does not hold or manage ride funds itself; cashless card processing is handled exclusively by Stripe as the licensed payment service provider and Merchant of Record.

The Fleet Partner and its drivers are not sub-processors of Emaride, and Emaride's sub-processors are not sub-processors of the Fleet Partner. Both follow from clause 2: the transfer between the parties is not Art. 28 processing, so there is no processing chain into which either could be inserted.

8. Cross-border Transfers

The data is hosted in the EU (Frankfurt). Where a provider named in clause 7 processes outside the EEA, the transfer takes place only under an adequacy decision under Art. 45 GDPR or under appropriate safeguards under Art. 46 GDPR, in particular the EU Standard Contractual Clauses (Implementing Decision (EU) 2021/914), supplemented by an assessment of the legal situation in the recipient country. This mirrors clause 15.4 FPA and dpa-fleet-partner clause 12.

The Fleet Partner transfers driver or passenger data received from the Platform outside the EEA only on the same conditions, and on its own responsibility as a separate controller.

9. Cross-references — the Agreement and This Schedule in Both Directions

So that the chain can be followed from either end:

Conversely, from this Schedule into the Agreement: clause 2 implements clause 15.2 FPA, clause 4 implements clause 15.3 FPA, clause 7 implements Part K of the GDPR Compliance Package, and clause 8 implements clause 15.4 FPA.

10. Deviations from the V2.1 Legal Package and the Agreement