Ferry — Data Processing Addendum (DPA)

Effective date: 3 August 2026 Processor: Prendit EOOD (Прендит ЕООД), 4a Boycho Ognyanov Str., 9300 Dobrich, Bulgaria, ЕИК 201597899 (“Ferry”, “we”) Controller: the Shopify merchant that installs and uses Ferry (“Merchant”, “you”)

This Addendum governs Ferry’s processing of Personal Data on the Merchant’s behalf and incorporates the requirements of Article 28 GDPR.

1. Roles

Except for the separately operated shared dataset and the COD risk-screening step — both carried out under the role allocation in §5 („Role allocation — risk processing“) — the Merchant is the controller and Ferry is the processor of the Personal Data contained in the Merchant’s Shopify orders that Ferry processes to provide shipping functionality. Ferry processes such data only on the Merchant’s documented instructions, which include the Merchant’s configuration and use of the app and this Addendum.

2. Subject matter, duration, nature and purpose

• Subject matter / nature: creation of courier waybills (outbound and, on the Merchant’s instruction, return waybills), label generation, office selection, buyer office-pick reminders (e-mail / opt-in SMS), checkout shipping-rate quoting, delivery-address normalization, and shipment tracking with the couriers supported by Ferry (currently Speedy, Econt, BOX NOW, Sameday and Pigeon Express); COD settlement reconciliation and reflecting delivery outcomes on the Merchant’s orders (mark-paid on remittance; refused-order cancellation, manual or opt-in automatic); and COD-fraud risk screening (§5). Merchant support correspondence is Merchant-account data processed by Ferry as controller (see the Privacy Policy §2) — outside this processor engagement; it is mentioned in §5 only because the support assistant may touch order context.
• Duration: for as long as the Merchant has Ferry installed, subject to the Data Retention Policy.
• Purpose: to fulfil, ship and (where applicable) return the Merchant’s orders.

3. Categories of data subjects and Personal Data

• Data subjects: the Merchant’s customers (order recipients).
• Personal Data: recipient name, shipping address / selected courier office, phone number, optionally email, and order/shipment metadata (order id, COD amount, parcel details).
• No special-category data is requested or intentionally processed; free-text fields (address notes, support messages/attachments) are not intended for such data, and incidental content follows the same retention and erasure rules as the field it arrived in.

4. Ferry’s obligations (Art. 28(3))

Ferry shall:

1. Process Personal Data only on the Merchant’s documented instructions, including for international transfers, unless required by EU/Member-State law.
2. Ensure persons authorised to process the data are bound by confidentiality.
3. Implement appropriate technical and organisational security measures (Annex A).
4. Engage sub-processors only under the conditions in Section 5.
5. Assist the Merchant, taking into account the nature of processing, in responding to data-subject requests (access, erasure, etc.).
6. Assist the Merchant with security, breach notification, DPIAs and prior consultation (Art. 32–36). We will notify the Merchant without undue delay after becoming aware of a personal-data breach — see the Incident Response Policy.
7. At the Merchant’s choice, delete or return all Personal Data at the end of the service and delete existing copies, unless retention is required by law. Uninstalling the app causes Shopify to issue the shop/redact webhook (typically ~48 hours after uninstall), which triggers deletion.
8. Make available information necessary to demonstrate compliance and allow for audits.

5. Sub-processors

The Merchant provides general authorisation for Ferry to engage the sub-processors below. Ferry imposes data-protection obligations on each sub-processor equivalent to this Addendum and remains liable for their performance. Ferry will inform the Merchant of intended changes and give an opportunity to object.

Note — Role allocation — risk processing (Art. 26 essence). The COD risk screening (Privacy Policy §4.1) and the shared returned-parcel dataset (§4.2) are NOT performed under the §1 processor engagement:

• Screening step (submitting the buyer’s phone/email, the check, attaching the result): Ferry and the Merchant act as joint controllers — Ferry selects the provider, enables the default-on check and operates the integration and the cross-merchant cache; the Merchant’s use of Ferry for COD orders supplies the context and consumes the result. The Merchant is sole controller of the subsequent order decision (ship, hold, refuse).
• nekorekten.com (CHECK AND PROTECT EOOD) operates its reporting platform as an independent controller (per its own public privacy notice and terms) and receives the queried phone/email as a recipient — it is not Ferry’s sub-processor.
• Shared returned-parcel dataset: Ferry is the controller (purpose, participation model, fields, hashing, matching, caps, recipients, retention, deletion); contribution to and operation of the network signal is joint between Ferry and each contributing Merchant (the reciprocal opt-in); Ferry is principal controller for central storage, matching, security and retention; a receiving Merchant is controller of its own use of the signal.
• Allocation of duties: Ferry is the buyer-facing contact point for these flows (privacy@ferrycommerce.com) and handles provider integration, security, retention, direct rights requests (incl. restriction pending a dispute) and breach duties for the central dataset; the Merchant handles buyer-facing transparency in its own shop policies and its order decisions. The essence of this arrangement is made available to buyers via the Privacy Policy (§4.1, §4.2, §8).

The network dataset has not operated to date and will not open before the data-protection impact assessment, the finalized arrangement, the rights workflow and the legitimate-interest assessment are complete.

Note — publishing a risk signal is outside this sub-processor engagement. When a Merchant chooses to publish a risk signal to nekorekten.com (report a buyer), this is always done under the Merchant’s own nekorekten account, never Ferry’s platform account. The Merchant is the controller of that public claim, not Ferry — publishing is therefore outside the scope of Ferry’s processing of Personal Data as the Merchant’s processor described in this Addendum. This holds equally for the opt-in auto-publish setting, under which Ferry would automatically publish such a signal for a genuinely unclaimed COD parcel (the buyer never collected it) — a setting that is currently not active (the couriers do not yet expose a reliable unclaimed-vs-refused signal, so Ferry does not auto-publish today). When active it too runs only under the Merchant’s own account and only on the Merchant’s standing instruction (the opt-in), so Ferry merely executes that instruction and the Merchant remains the controller of each published claim. Automatic publication is disabled and stays disabled until the preconditions listed in the Privacy Policy §4.1 (auditable return-reason distinction, legitimate-interest assessment, evidence and audit logs, buyer notice, correction/objection procedure, provider-side retention, final role allocation, human confirmation) are met.

Note — the shared returned-parcel store is outside the per-Merchant processor engagement. The existing buyer-history signal remains per-tenant, is never shared across Merchants, and is not a sub-processor disclosure. The separate network store is the only exception, and exposes only the pseudonymized derived signal described here. When a Merchant opts in, the Merchant instructs Ferry to include that Merchant’s returned-COD facts in buyer_reputation_events: shipment reference, an HMAC-SHA256 hash of the buyer’s normalized phone keyed with Ferry’s server-side secret, contributing shop, returned marker, and timestamp. Ferry operates this pseudonymized shared dataset as controller, with contribution/operation joint between Ferry and each contributing Merchant — see the „Role allocation — risk processing“ note above for the full Art. 26 essence and the pre-launch gates (DPIA, rights workflow, LIA). Opting out withdraws the contribution and immediately deletes that Merchant’s contributed rows. The store runs entirely on Ferry’s own infrastructure and involves no third party.

Note — couriers are not sub-processors. The couriers receive shipment data as independent recipients under the Merchant’s own courier contract, to carry out delivery (and, where the Merchant instructs a return waybill, the return pickup/delivery). This includes the fiscal-receipt line-item flow (касов бон, opt-in per Merchant), under which Speedy and Econt receive order line-item data (product name, quantity, unit price — read live from the order, not persisted by Ferry) from the Merchant’s own courier contract in order to issue a fiscal receipt on delivery — the same recipient relationship as waybill creation, not a new sub-processor relationship.

6. International transfers

Where Personal Data is transferred outside the EU/EEA, the transfer is covered by an appropriate Art. 46 safeguard (e.g. EU Standard Contractual Clauses).

7. Liability & term

This Addendum takes effect on installation of Ferry and remains in force while Ferry processes Personal Data for the Merchant. Liability is subject to the main agreement between the parties.

Annex A — Technical and organisational measures

• Encryption in transit (TLS) and at rest; courier credentials and Shopify tokens additionally encrypted with AES-GCM and decrypted only per request.
• Multi-tenant isolation by row-level shop_id, derived server-side on every query.
• Separation of test/staging/production environments and data.
• Least-privilege access control; strong authentication for staff/admin access, restricted to authorised Ferry personnel behind per-environment access tokens.
• Request logging, operational monitoring and alerting.
• Documented incident-response and data-retention procedures.
• Data minimisation — processing is limited to the categories in §3; direct identifiers are not persisted beyond the artifacts listed in the Data Retention Policy.