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 customer that registers for and uses a Ferry product (“Merchant”, “you”) — either a Shopify merchant that installs the Ferry app, or a seller that registers for Ferry Social and connects their own Facebook or Instagram page. Both are Merchants for the purposes of this Addendum; where a term applies to only one of them, it says so.

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 that Ferry processes to provide shipping functionality: for a Shopify merchant, the data contained in that merchant’s Shopify orders; for a Ferry Social seller, the data contained in the conversations on that seller’s connected page and in the orders drafted from them. 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.

Documented instructions in Ferry Social — stated, because Ferry decides how they run. By registering for Ferry Social and connecting a page, the Merchant instructs Ferry to:

1. Read every conversation on that page with an AI model to draft an order from it (Privacy Policy §2.3). This is the service itself; there is no setting that turns it off, and a Merchant who does not want it does not want Ferry Social.
2. Send the buyer a message in the same thread when a shipment’s courier status changes (Privacy Policy §2.4) — the delivery information the buyer is waiting for, sent by Ferry rather than by the Merchant.
3. Import up to 200 messages exchanged before the page was connected, when a conversation is new to Ferry (Privacy Policy §2.4). Unlike the two above, this is a Merchant setting — on by default, and the Merchant can switch it off at any time, after which only messages that arrive from then on are read.

Ferry determines the technical means of each of these — which model, what a conversation window is, what the buyer’s message says. The purposes are the Merchant’s: to take the order and to ship it.

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.
• Subject matter / nature — Ferry Social additionally: receiving the messages exchanged on the Merchant’s connected Facebook or Instagram page; storing them and reading them with an AI model to draft an order (recipient, phone, destination, items, cash-on-delivery amount); reading photos and shared screenshots the same way; importing conversation history where the Merchant leaves that setting on; and sending the buyer a status message in the same thread — all as the documented instructions in §1, and then the same waybill, label, tracking and COD processing as above.
• Duration: for as long as the Merchant has Ferry installed or a Ferry Social registration, 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). In Ferry Social this is wider: a data subject is anyone who writes to the Merchant’s connected page — including a person who asks a question, sends a photo or complains, and never places an order. Ferry receives and stores their messages regardless of whether an order results.
• Personal Data: recipient name, shipping address / selected courier office, phone number, optionally email, and order/shipment metadata (order id, COD amount, parcel details).
• Personal Data — Ferry Social additionally: the content of the messages themselves, the Merchant’s own replies included, kept verbatim; the buyer’s identity on the Meta platform (name or username, platform id, and the address of their profile picture); the identifiers of individual messages; photos sent in the chat and screenshots the Merchant shares (read once, not stored — see §2.3 of the Privacy Policy for the single exception); and the verbatim sentences from which each detail of the order was read.
• 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. A conversation is free text throughout, so the same rule carries the whole of it: whatever a buyer chooses to write is retained and erased as the conversation is.

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.). In Ferry Social this assistance is manual: the app carries no route by which such a request can be lodged or executed, so a request relayed to privacy@ferrycommerce.com is carried out by Ferry personnel against the database. Such a route is being built.
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 Shopify app causes Shopify to issue the shop/redact webhook (typically ~48 hours after uninstall), which triggers deletion. In Ferry Social there is no such webhook: the Merchant can delete all of their own working data from the app at any time, and everything the scheduled purge covers is deleted on its own periods regardless. Deleting the account itself is done by Ferry on request to privacy@ferrycommerce.com; a self-serve route is being added.
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). In Ferry Social the check is off by default — nothing is disclosed to the provider until the Merchant switches it on, and until then the only risk signals are the Merchant’s own (that Merchant’s returned parcels and their own blocked-number list), which never leave Ferry.
• 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, Shopify tokens and Ferry Social’s Meta page tokens additionally encrypted with AES-GCM and decrypted only per request.
• Multi-tenant isolation by a row-level tenant id (the Shopify shop, or the Ferry Social seller), 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.