Privacy Policy

1. Who is responsible

horsenose is a software service for managing riding schools — scheduling lessons, tracking who attended and how they paid, managing passes and gift vouchers, calculating instructor earnings, and giving a stable’s customers a way to see their own bookings. It is operated by DF Daniel Fojcik, a Polish sole proprietorship (jednoosobowa działalność gospodarcza, JDG) registered in the Polish Central Business Registry (CEIDG), with principal place of business at ul. Goplany 36a, 44-321 Marklowice, Poland. Tax identification: NIP 6472592229 · EU VAT PL6472592229 · REGON 387798601. We trade as Nose / horsenose for this product.

The Polish supervisory authority for data protection is the President of the Personal Data Protection Office (UODO), ul. Stawki 2, 00-193 Warszawa, Poland — uodo.gov.pl.

For privacy matters, contact support@horsenose.eu. horsenose has not designated a formal Data Protection Officer; the proprietor serves as the privacy contact.

1.1 Our role — when we are the controller, and when we are only the processor

horsenose handles personal data in two different roles, and this policy is written so you can tell which one applies to you. The distinction matters because it decides who is legally responsible for the data and who you go to in order to exercise your rights.

We are the data controller — meaning we decide why and how the data is used — for:

• visitors to our marketing website;
• the account, contact, and billing data of the people who sign up to run a stable on horsenose: stable administrators and instructors (your name, sign-in email, optional phone number, and subscription billing data where applicable);
• product analytics about how the Service is used (only with your consent — see “Analytics data” below);
• security, abuse-prevention, and operational logs.

For all of the above, you exercise your rights (see “Your rights” below) directly with us, and the rest of this policy describes what we do.

We are only the data processor — meaning a stable decides why and how the data is used, and we merely act on its documented instructions — for:

• the operational data a stable enters about its own riders and customers: their names, contact details, which lessons they took part in, how they paid (cash / pass / voucher / transfer as tracking labels, or a record of an online payment where the stable enables it — see “Payment data” below), passes and vouchers issued to them, attendance, and any free-text notes the stable writes.

For that rider/customer data, the stable is the controller and horsenose is its processor. This relationship is governed by a separate Data Processing Agreement (DPA), which every stable accepts and which sets out our obligations under Article 28 GDPR. If you are a rider or a parent booking lessons for a child, the stable you ride with is responsible for that data; we hold it on the stable’s behalf and help the stable answer your requests (see “Your rights” and “Children’s privacy” below).

In one sentence: if you signed up to run a stable, we are your controller. If a stable entered your data because you ride there, that stable is the controller and we are its processor.

2. Summary — the plain-English version

horsenose makes its money from riding schools that pay a subscription to manage their operations. We do not sell personal data, and we do not train AI models on it.

• We collect the minimum data needed to run the Service.
• We do not sell personal data. Never have, never will.
• We do not run advertising trackers, we do not fingerprint your browser, and we are not part of any cross-site advertising network. No Meta, LinkedIn, X, or TikTok pixels.
• horsenose never holds or moves anyone’s money. By default, "cash", "pass", "voucher", and "transfer" inside the app are just labels a stable records to note how a rider paid outside the app. If a stable turns on online payments, riders can pay it by card, mobile wallet, or BLIK in the app — but those payments run through Stripe straight into the stable’s own account: the stable is the seller, Stripe is the regulated payment provider, and no rider card details ever touch horsenose. Separately, the stable’s own subscription to horsenose is billed by Stripe (Polish stables, PLN) or by Dodo Payments as Merchant of Record (non-Polish stables, EUR/GBP/USD) — see “Payment data” below.
• We use PostHog (hosted in the EU) only for pageview and interaction analytics (autocapture) and performance metrics — loaded only if you click "Accept" on the cookie banner; we do not record or replay your screen. If you reject, it is never loaded. We also use Vercel Web Analytics, which is cookieless and does not track you.
• We rely on a small set of third-party providers ("sub-processors") for things we could not sensibly build ourselves — hosting, database, email, error monitoring, bot protection. Each one gets only what it needs.
• Most of our infrastructure runs in the EU, but not all of it — we are honest about the exceptions in “International transfers” below.
• You have rights over your data, and we honour them. If you are a rider, some of those rights are exercised through your stable (see “Your rights” below).

If you want the detailed version, keep reading.

3. What we collect

3.1 Account data

When you create an account to use horsenose (as a stable administrator, an instructor, or a customer/rider invited by a stable), we or the stable collect:

• Email address (required — it is your sign-in identity);
• Name (optional for some roles);
• Phone number (optional);
• Authentication metadata strictly necessary to sign you in. horsenose offers passwordless sign-in only: an email "magic link" handled for us by Supabase Auth, and — optionally — Google sign-in (OAuth), in which case Google returns a persistent account identifier (not your Google password) to us.

Where a stable creates a rider record for someone who does not yet have a real email (for example, a child added to a class), the system uses a synthetic placeholder identifier internally; it is replaced with a real email only if and when the stable adds one.

3.2 Payment data

horsenose is never a party to a rider’s payment, and we never see card details. By default, methods such as cash, pass, voucher, and bank transfer are tracking labels that a stable’s staff record to note that a rider paid outside the app — not transactions that horsenose runs. A stable may also turn on online payments, letting riders top up their balance or pay by card, mobile wallet, or BLIK inside the app. Those payments are processed by Stripe (through Stripe Connect) directly into that stable’s own Stripe account: the stable is the seller and the recipient of the money, Stripe is the regulated payment provider that handles the card and holds the funds until it pays them out to the stable, and horsenose only provides the software — we never hold, receive, or control the money, and the card, wallet, or BLIK details never reach us. A balance a rider tops up is a prepayment usable only at the stable that issued it. In no case do we collect or store full card numbers, bank-account numbers, or CVV codes.

Subscription billing — the fee a stable pays for horsenose — is live. For Polish stables, billing is handled in PLN by Stripe Payments Europe, Ltd., with DF Daniel Fojcik / horsenose as the merchant and faktura issuer. For non-Polish stables, billing is handled in EUR, GBP, or USD by Dodo Payments as the Merchant of Record: Dodo is the legal seller for the transaction, issues the tax-compliant invoice/receipt, and calculates and remits VAT or sales tax. Dodo is an independent seller/controller for the transaction itself, and also acts as our sub-processor for the billing personal data needed to run that subscription billing.

For that stable subscription, the billing data involved is limited to what the billing provider needs: billing name, billing email, country and billing address, provider-held payment token, and the last four digits of the card. For online rider payments, what horsenose stores is limited to a record of each payment — amount, method type, status, and time — while the card data itself stays with Stripe on the stable’s own account. Full card data stays with Stripe or Dodo; it is not stored in horsenose.

3.3 Operational data a stable enters (we are the processor here)

When a stable uses horsenose to run its day-to-day operations, it enters data about its riders and customers. For this data the stable is the controller and horsenose is the processor (see “Who is responsible” above). It can include:

• rider/customer names and contact details (email, optional phone);
• which lessons ("rides") a rider was scheduled for and attended;
• how a lesson was paid for (the cash/pass/voucher/transfer labels above, or — where the stable uses online payments — a record of the online payment: amount, method, status, never card data);
• passes and gift vouchers issued, redeemed, or refunded;
• one-way announcements a stable sends to its members (message subject and body);
• free-text notes the stable writes on passes, payments, horses, and similar records.

We process this data only to provide the Service to the stable, on the stable’s documented instructions, under the DPA.

3.4 Usage and technical data (we are the controller here)

Automatically collected when you use the website or app, regardless of whether you consent to analytics:

• IP address — used by horsenose for rate limiting, abuse prevention, and security;
• browser type and version, operating system, device type;
• pages visited and referring URL;
• crash and error logs — captured by Sentry, our error-monitoring provider. We deliberately scrub personal data before it is sent: email addresses, phone numbers, message bodies, free-text notes, and anything that looks like a token are stripped out. What remains is technical context plus a pseudonymous user identifier (a UUID), the stable identifier, the locale, and the name of the operation that failed.

3.5 Analytics data (PostHog and Vercel Web Analytics)

PostHog (consent-based, EU-hosted). Only if you click "Accept" on the cookie banner, we load PostHog (EU Cloud, eu.posthog.com) to understand how the product is used. PostHog collects a pseudonymous identifier that distinguishes repeat visits, events (which buttons or screens are used), pages viewed and engagement, plus device, browser, and operating system, and a derived approximate country/region only. Your IP address is discarded by PostHog at ingestion; we do not retain raw IP addresses against your analytics profile.

What we track — please read this. We use PostHog only for pageview and interaction analytics (autocapture) — which buttons and screens are used — and performance metrics; we do not record or replay your screen. PostHog is loaded only if you accept analytics; if you reject (or your browser sends a Do Not Track / Global Privacy Control signal), it is never loaded and no analytics events are collected. PostHog retains analytics events for 6 months, after which they are deleted from PostHog’s systems.

Vercel Web Analytics (cookieless). We also use Vercel Web Analytics, a privacy-preserving, cookieless analytics tool that measures aggregate traffic without setting tracking cookies and without building a profile of you. Because it is cookieless and non-identifying, it does not depend on the consent banner in the way PostHog does.

If you click "Reject" — or if your browser sends a Do Not Track / Global Privacy Control signal on the first request — PostHog is never loaded and its cookies and local-storage keys are never set. You can change your choice at any time via the "Cookie settings" link in the site footer. See “Do Not Track and Global Privacy Control” below.

3.6 Communication data

Emails you send us (for example, to support@horsenose.eu) are stored in our support inbox. We keep them as long as needed to resolve your issue and for a reasonable follow-up period.

3.7 Special-category data and free-text fields — our position

horsenose does not intend to collect special-category data (the sensitive categories listed in Article 9 GDPR — for example health, disability, racial or ethnic origin, religious beliefs). We do not ask for it and the product is not designed to store it.

• Stables must not enter special-category data into free-text fields (notes, messages). The DPA instructs stables not to do this. If a stable nonetheless enters such data, the stable remains the controller and bears responsibility for it.
• Ride-type names are names, not data about a person. A stable picks the names of its own lesson types in its settings; to horsenose, those are operational scheduling labels attached to a lesson, not records about an individual.
• Notes about horses (for example, a horse’s rest period or veterinary note) are about animals, not people, and are outside the scope of GDPR.

3.8 What we do not collect

• We do not collect home addresses, ID-document numbers, or government identifiers.
• We do not collect or store full payment-card or bank-account data; subscription card tokens and last four digits are held by Stripe or Dodo, and any online rider-payment card data is held by Stripe on the stable’s own account (see “Payment data” above).
• We do not knowingly collect special-category (Article 9) data (see “Special-category data and free-text fields — our position” above).
• We do not use advertising trackers, retargeting pixels, or cross-site ad-network tags.
• We do not fingerprint your browser.
• We do not build cross-site behavioural profiles for advertising.
• We do not sell your data to anyone.
• We do not train machine-learning models on your data.

4. How we use data

As controller (visitor, account-holder, analytics, and security data), we use the data we collect to:

• provide and operate the Service and your account;
• send transactional emails (sign-in magic links, invitations, lesson change/cancellation notices, account notifications);
• protect the Service from abuse, fraud, and technical attacks (rate limiting, bot protection, audit logging);
• respond to your support requests;
• understand how the product is used, in order to improve it — but only where you have consented (see “Analytics data” above);
• comply with legal obligations (for example, keeping our own subscription billing, invoice, and accounting records, and responding to lawful requests).

As processor for a stable’s rider/customer data, we use that data only to provide the Service to the stable on its instructions — we do not use it for our own purposes.

We do not use any data to train AI or ML models, to profile you for advertising, or to sell to third parties.

5. Legal bases for processing (GDPR Art. 6)

The legal bases below apply to processing for which horsenose is the controller (see “Who is responsible” above). For rider/customer data, where the stable is the controller, the stable establishes its own legal basis; horsenose processes on the stable’s instructions under the DPA.

Children’s data — the legal basis sits with the stable. A large share of riding-school customers are parents booking lessons for children. Where a stable enters a child’s data into horsenose, the stable (as controller) is responsible for establishing the lawful basis and for any parental consent or authority required, including under Article 8 GDPR as implemented in Poland. horsenose does not establish that basis itself; we process children’s data only on the stable’s documented instructions and we minimise it (see “Children’s privacy” below).

6. Sharing — sub-processors

To run horsenose we rely on a small set of third-party providers ("sub-processors"). Each one receives only the data necessary to perform its function.

At the date of this policy our sub-processors include Supabase (database, authentication, storage — EU/Frankfurt), Vercel (hosting — EU/fra1 with a global edge), Brevo (email — EU/France), PostHog (consent-gated analytics — EU Cloud), Sentry (error monitoring — EU), Upstash (rate-limit counters — EU Regional/Frankfurt), Cloudflare (bot protection and DNS — global edge), Google (optional Google sign-in — US), Stripe Payments Europe, Ltd. (subscription billing for Polish stables, and — for stables that enable online payments — processing those payments into the stable’s own account — EU + US), and Dodo Payments (Merchant of Record for non-Polish subscription billing — global). The public sub-processor list records each provider’s purpose, data categories, processing region, and transfer mechanism.

We sign a Data Processing Agreement with each sub-processor where required by law. Where personal data moves between regions or across borders, the transfer is governed by the mechanisms in “International transfers” below.

When we add, replace, or remove a sub-processor, we update the public sub-processor list and — for active stables/subscribers — give advance written notice (sooner only where a change is urgent for security or service continuity), with a right to object on data-protection grounds as set out in the DPA.

7. International transfers

horsenose runs across more than one hosting region, and we add regions as the product grows. Each provider’s current primary processing region is listed on the Sub-processors page and can change as we expand or as a provider changes its own footprint; we keep that page current and, for any change of sub-processor, give advance notice (see “Sharing — sub-processors” above). We do not promise that your data will only ever be processed in a single region — instead, wherever it is processed or moved between regions, we put an appropriate transfer mechanism in place for that route.

Today, most of our core processing is in the European Economic Area — Supabase in Frankfurt (eu-central-1), Vercel in fra1, Brevo in France, and PostHog on its EU Cloud — and Sentry and Upstash are configured to use their EU regions, with the EU Standard Contractual Clauses in their agreements as a fallback for any incidental processing elsewhere. This describes where things run now, not a permanent guarantee: as we grow we may add regions, including outside the EEA, and when a provider’s primary region changes we update the Sub-processors page to match.

Some components already run outside the EEA today:

• Cloudflare operates a global edge network for bot protection, DNS, and CDN;
• Google (optional Google sign-in only) is in the United States;
• Stripe processes Polish subscription billing data — and, for stables that enable online payments, those rider payments into the stable’s own account — in the EU and United States;
• Dodo Payments processes non-Polish subscription billing data on a global Merchant-of-Record basis, including through its own sub-processors.

Our Upstash rate-limit store, which uses IP-derived keys, runs in a Regional EU-only database in Frankfurt (eu-central-1, AWS) with no cross-region replication.

Wherever personal data is transferred between regions — or to a country outside the one where it was collected — we rely, depending on the provider and the nature of the transfer, on the appropriate safeguard for that route:

• an adequacy decision of the competent authority (for example, of the European Commission), where one applies to the destination country;
• the EU-U.S. Data Privacy Framework (DPF), and its UK Extension, for providers in the United States that have self-certified under it;
• the European Commission’s Standard Contractual Clauses (SCCs) — together with the additional safeguards required after the Schrems II judgment (including transfer-risk assessments and, where appropriate, supplementary technical measures) — the UK International Data Transfer Addendum where the UK GDPR applies, and the equivalent transfer mechanisms other jurisdictions require as we begin operating in them.

You may request a copy of the safeguards applicable to a specific transfer by emailing support@horsenose.eu.

United Kingdom. Transfers between the UK and the EEA are covered by the applicable adequacy decisions. Where the UK GDPR requires a transfer tool of its own, we rely on the UK International Data Transfer Addendum to the EU Standard Contractual Clauses.

8. How long we keep data (retention)

Our retention follows our internal data-retention policy. The guiding principle is data minimisation — we keep data for the life of an active account and then delete it or strip its personal identifiers (see "Erasure" below for what that means in practice). We do not keep directly-identifying rider or account data for five years. The only five-year retention we apply is (a) narrowly-scoped, pseudonymous financial audit-log entries (below) and (b) our own subscription invoicing and accounting records — both required by Polish law.

Account-holder and rider data (life of the account). Operational and financial records are retained while the relevant account/subscription is active, because a stable needs its own history to operate.

Erasure — stripping your personal identifiers, after a 30-day grace period. When your account is erased — which you can request at any time (see “Your rights” below) — after a 30-day grace window during which you can reverse it we strip your personal identifiers rather than hard-delete: your name becomes "Deleted user", your phone, locale, and timezone are cleared, and your sign-in email is replaced with a non-identifying placeholder. De-identified financial and lesson lines remain in the stable’s records while that stable’s account is active so its books reconcile; those lines no longer contain your personal data but still hold an internal reference to the stripped account. Under GDPR this is technically pseudonymisation (Art. 4(5)) rather than full anonymisation (Recital 26) — we use this approach because the stable needs its own books to reconcile and Polish accounting law obliges the stable, not horsenose, to keep them.

Stable offboarding. Archiving or closing a stable starts an automated 90-day reversible grace period. During it, the stable can be restored and a full export is available on request (email support@horsenose.eu); when the 90 days end, the stable’s data is permanently deleted automatically.

The 5-year tax-record duty — whose it is. Polish accounting and VAT law requires a business to keep its own financial records for five years. That duty belongs to the stable (as the controller of its own books), not to horsenose. horsenose holds that data only as the stable’s processor and has no independent duty to keep rider personal data for five years. The records horsenose itself keeps for five years are its own subscription billing, invoice, and accounting records, which are business-to-business records and contain no rider personal data.

Internal audit/event log (pseudonymised). Our security audit log records events using pseudonymous identifiers (UUIDs), separate from rider personal data, on these classes:

A daily purge removes entries past their class window. When a stable is offboarded, its audit entries are also purged (subject to any minimal security-incident hold).

Server and error logs. Operational runtime logs at Vercel are kept for 1 day and build logs for 30 days; error traces at Sentry are kept for 30 days for events and 90 days for issues.

The periods above for our sub-processors reflect each vendor’s own current operational retention policy, not a promise we make on their behalf — if a vendor changes its retention window, the figure changes with it, and we keep this page current when that happens.

Support emails. Kept for a reasonable period after your issue is resolved.

Where the law requires a specific record to be retained (for example, a tax record the stable must keep), that obligation overrides the periods above — but only for the specific records the law applies to.

9. Your rights

Under the GDPR you have the rights below. How you exercise them depends on who the controller is (see “Who is responsible” above):

• For your own account-holder data (you signed up as a stable admin, instructor, or customer), horsenose is the controller and you exercise these rights directly with us.
• For rider/customer data a stable entered, the stable is the controller. You exercise your rights against that stable; horsenose, as processor, assists the stable and forwards your request — we do not decide it ourselves (Article 28(3)(e) GDPR).

Your rights:

• To be informed (Arts. 13 and 14) — this policy tells you what we collect and why, whether we obtained it from you (Art. 13) or from a stable that entered it about you (Art. 14).
• Access (Art. 15) — request a copy of your personal data. Account-holders can use the self-service "download my data" export at /account/export, which produces a structured JSON file (rate-limited to one request per day).
• Rectification (Art. 16) — correct inaccurate data. You can edit your own profile (name, phone) yourself in account settings.
• Erasure (Art. 17) — request deletion of your account at /account/delete (a step-up re-authentication is required). After a 30-day grace period — during which you can reverse it — we strip your personal identifiers as described in “How long we keep data (retention)” above.
• Portability (Art. 20) — receive your data in a structured, machine-readable format (the JSON export above).
• Objection (Art. 21) — object to processing we carry out on the basis of legitimate interest. Contact us.
• Restriction (Art. 18) — ask us to limit how we process your data while a question is resolved. Contact us.
• Withdraw consent — where processing is based on consent (analytics), withdraw it at any time via "Cookie settings"; withdrawal does not affect processing already carried out.
• Complaint to a supervisory authority — you may lodge a complaint with the Polish UODO (ul. Stawki 2, 00-193 Warszawa, uodo.gov.pl) or your local EU authority. If you are in the United Kingdom, the GDPR references in this policy include the UK GDPR and the Data Protection Act 2018, and you can complain to the Information Commissioner’s Office (ICO, ico.org.uk).

How to exercise. For data we control, email support@horsenose.eu; we will verify your identity (usually by confirming you can access the account email) and respond within 30 days (GDPR). For rider data controlled by a stable, contact your stable; if you reach us instead, we will route your request to the stable or assist it in responding, to the extent lawfully possible. We do not charge for a reasonable request; we may charge a reasonable fee for manifestly unfounded or excessive requests, as permitted by Art. 12(5) GDPR.

10. Security

We implement technical and organisational measures designed to protect personal data against unauthorised access, disclosure, alteration, and loss. We distinguish between measures currently in place and those we are planning as the Service matures, so that no aspirational control is presented as an existing one.

Currently in place:

• TLS for all data in transit, with HSTS preload;
• encryption at rest via our database provider (Supabase, AES-256);
• row-level security (RLS) scoped to each stable on every operational table, so one stable’s data cannot be read by another — enforced in the database itself, not just in application code;
• server-side session validation on every protected request (the sign-in cookie alone is never trusted);
• a step-up re-authentication requirement for destructive and administrative actions;
• bcrypt-hashed schedule PINs and SHA-256-hashed, single-use, time-limited, email-bound invitation tokens (raw tokens are never stored);
• input validation at every server boundary;
• rate limiting (Upstash) and bot protection (Cloudflare Turnstile) on sign-in, sign-up, and form endpoints;
• a strict Content Security Policy with a per-request nonce and locked-down security headers;
• an append-only audit log of security-relevant events;
• error monitoring with personal-data scrubbing (Sentry — see “Usage and technical data (we are the controller here)” above).

Planned as the Service matures (not yet in place):

• a dedicated staging environment;
• automated dependency and security scanning in our build pipeline;
• a formally documented incident-response process;
• a quarterly secret-rotation policy (rotation is currently manual);
• third-party assurances such as SOC 2 / ISO 27001 and penetration testing — we do not have these today.

We are a small operation (currently a solo operator). If your procurement process requires formal certifications today, we may not yet be the right fit, and we would rather tell you so plainly.

No system can be made perfectly secure. In the event of a personal-data breach likely to result in a risk to your rights and freedoms, we will notify the competent supervisory authority (UODO) without undue delay and, where feasible, within 72 hours of becoming aware of it (Article 33 GDPR). Where the breach is likely to result in a high risk to you, we will also notify you without undue delay (Article 34 GDPR). Where we act as a processor for a stable, we will notify the stable without undue delay so it can meet its own obligations.

11. Children’s privacy

This is one place horsenose differs from many SaaS privacy policies. We are not a "no minors" service — riding schools regularly teach children, so horsenose knowingly processes children’s personal data on a stable’s behalf (for example, a child entered as a participant in a lesson, often by a parent who is the stable’s customer).

• The stable is the controller of a child’s data, and the stable is responsible for the lawful basis and for any parental consent or authority required, including under Article 8 GDPR (see “Legal bases for processing (GDPR Art. 6)” above). horsenose processes a child’s data only on the stable’s documented instructions.
• We minimise what is held about a child to what the stable needs to run lessons — typically a name and the lessons attended.
• horsenose does not target or market to children directly. We have no direct relationship with a child; our relationship is with the stable.
• A parent or guardian who wants to access, correct, or delete a child’s data should contact the stable (the controller); horsenose will assist the stable as its processor (see “Your rights” above).

12. Cookies

See our Cookie Policy for the full list of cookies and similar technologies. In summary, we use strictly necessary cookies (sign-in session, locale, bot protection, public-schedule access, and remembering your consent choice — set without a banner because the Service cannot function without them) and optional analytics technologies (PostHog), which load only if you click "Accept" on the cookie banner. Vercel Web Analytics is cookieless. We do not use marketing, retargeting, or cross-site advertising cookies.

13. Automated decision-making and profiling

We do not make decisions about you that produce legal or similarly significant effects based solely on automated processing. The Service applies routine, transparent operational rules (for example, enforcing a class’s capacity, a pass’s remaining uses, or a rate limit), but these are predictable product mechanics, not profiling, and a stable’s staff remain in control of bookings. If you believe an automated rule has affected you incorrectly, contact support@horsenose.eu (or, for rider data, your stable).

14. Do Not Track and Global Privacy Control

Our website respects Do Not Track (DNT) and Global Privacy Control (GPC) signals where technically possible. If your browser sends either signal on the first request, we treat it as a rejection of the optional analytics category (PostHog) and do not load it, without showing the cookie banner. Strictly-necessary cookies and cookieless Vercel Web Analytics are unaffected, because they do not track you and are needed to provide the Service you requested.

15. Changes to this policy

We may update this policy as the Service evolves, when sub-processors change, or when the law changes. Material changes will be announced by email to active stables/subscribers with reasonable advance notice before they take effect (sooner only where required by law, a supervisory-authority instruction, or a genuine security or service-continuity reason). The "Last updated" date at the top of this document always reflects the most recent revision.

16. Business transfers

If horsenose is reorganised, merged, sold, or otherwise transfers substantially all of the assets related to the Service — or if the Service is transferred to a successor operator — personal data held in connection with the Service may be transferred as part of that transaction. In any such case we will (a) ensure the successor is contractually bound to treat your personal data on terms at least as protective as this policy, (b) give prior notice by email to active account-holders at least 30 days before the transfer takes effect, where legally permissible, and (c) give you a reasonable opportunity to export your data and close your account before the transfer, without penalty. Where we act as a processor for a stable, any such transfer is also subject to the stable’s rights under the DPA. We will not transfer personal data as part of a bankruptcy or insolvency proceeding except on terms required by applicable law, including any requirement to preserve data-protection standards.

17. Contact

For any privacy question, data request, or complaint: support@horsenose.eu.

If you are an EU resident and are not satisfied with our response, you have the right to lodge a complaint with the Polish supervisory authority — the President of the Personal Data Protection Office (UODO), ul. Stawki 2, 00-193 Warszawa, uodo.gov.pl — or with your local national data-protection authority.

This policy is drawn up in Polish and English, which are equally authoritative; German, French, and Italian versions are provided only as courtesy translations. See the Terms of Service → "Language versions" for which version governs and how to switch between them using the language selector at the top of this page.