Sub-processors

1. Foundation facts

This is the canonical sub-processor list for horsenose. The Privacy Policy, the DPA, and the Security & Trust page link here rather than duplicating the table.

• Operator / data controller (own data): DF Daniel Fojcik, a Polish sole proprietorship (jednoosobowa działalność gospodarcza, JDG) registered in CEIDG. NIP 6472592229 · EU VAT PL6472592229 · REGON 387798601. Principal place of business: ul. Goplany 36a, 44-321 Marklowice, Poland. Trading as Nose / horsenose for this product.
• Legal / privacy contact: support@horsenose.eu. No formal Data Protection Officer is designated; the proprietor is the privacy contact.
• Supervisory authority: President of the Personal Data Protection Office (UODO), ul. Stawki 2, 00-193 Warszawa, Poland — uodo.gov.pl.
• Two roles (see the Privacy Policy → “Who is responsible” and the DPA): controller — for marketing-site visitors, the account/billing data of stable admins & instructors, product analytics, and security/abuse-prevention data; processor — for the operational data a stable enters about its riders/customers (the stable is the controller; governed by the customer-facing DPA).
• Data residency posture (honest): horsenose runs across more than one region and adds regions as it grows; the current primary region for each provider is the “Region” column below, and it can change as we expand or as a provider changes its footprint. Today, most core processing is in the EEA (Supabase Frankfurt; Vercel fra1; Brevo France; PostHog EU Cloud), with Sentry and Upstash configured for their EU regions and the EU Standard Contractual Clauses in their agreements as a fallback for incidental processing elsewhere. Some components already run outside the EEA (Cloudflare’s global edge for DNS, CDN, and Turnstile bot protection; Google OAuth in the United States; parts of Stripe in the US; Dodo Payments on a global Merchant-of-Record basis). Every cross-region route is covered by an appropriate transfer mechanism — an adequacy decision, the EU-U.S. Data Privacy Framework (and its UK Extension), the EU Standard Contractual Clauses, the UK International Data Transfer Addendum, or the equivalent an added region requires (see the “Transfer mechanism” column).
• Retention posture: data is kept for the life of the active account; on rider erasure (Art. 17), direct identifiers are stripped after a 30-day grace (pseudonymisation under Art. 4(5) GDPR — ride/financial lines retain a non-resolving pointer to the stripped profile, not full anonymisation under Recital 26); on stable offboarding, data is retained max 90 days in an automated, reversible grace period, exported only on request, then deleted automatically. The 5-year tax-record duty is the stable’s (and horsenose’s only for its own subscription invoices) — horsenose does not hold rider personal data for 5 years. Full detail in the Privacy Policy → “How long we keep data (retention)” and the DPA → “Keeping, returning, and deleting your data”.
• Payments: horsenose is never in the funds chain and never handles card data. Offline rider payments (cash / pass / voucher / transfer) remain tracking labels. Where a stable enables online payments, riders pay by card / wallet / (in Poland) BLIK through Stripe Connect straight into the stable’s own Stripe account — the stable is the merchant and Stripe is the processor; horsenose only relays the instruction and never holds or receives the money. Subscription billing (a stable’s subscription to horsenose) is live: Stripe bills Polish stables directly in PLN (horsenose issues the PL faktura). Dodo Payments is the Merchant of Record for all non-Polish stables (EUR/GBP/USD) — Dodo is the legal seller of the subscription, issues the tax-compliant invoice/receipt, and calculates and remits VAT/sales tax in the destination jurisdiction. Both process the stable administrator’s billing-identity data on horsenose’s behalf. As Merchant of Record, Dodo is more than a processor — it is an independent seller/controller for the transaction itself. Any future change to the billing providers follows the advance-notice and objection mechanics in the DPA → “Confidentiality, security, and sub-processors”.

2. Sub-processor master list

Each sub-processor receives only the data necessary to perform its function. "Region" is the data-processing region; several vendors are US-incorporated but offer EU data regions, so a DPA + SCC/DPF backstop covers any incidental access by the vendor entity.

3. Changes to this list

Change-of-sub-processor commitment: when horsenose adds, replaces, or removes a sub-processor, it updates this list and gives active subscribers / stables at least 15 days’ advance notice (by email to the stable’s account address or in-product) before the change takes effect (sooner only where urgent for security or service continuity), with a reasonable opportunity to object on data-protection grounds. The mechanics are set out in the DPA → “Confidentiality, security, and sub-processors”.

4. Processor-DPA register

Each vendor above publishes a standard Data Processing Addendum that applies via its Terms of Service or via in-console acceptance — none of them signs a bilateral wet-PDF DPA, and GDPR Art. 28(3) does not require one. horsenose keeps an internal register with each vendor’s DPA URL, the version relied on, the acceptance mechanism, and the date last verified. That register is distinct from the customer-facing DPA (stable ↔ horsenose).