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 and contact 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);
• product analytics about how the Service is used (only with your consent — see §3.5);
• security, abuse-prevention, and operational logs.

For all of the above, you exercise your rights (§9) 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 / BLIK as tracking labels — see §3.2), 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 §9 and §11).

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.
• We do not process any online payments today. "Cash", "pass", "voucher", and "BLIK" inside the app are just labels a stable uses to record how a rider paid — no card details ever touch horsenose. Subscription billing for stables, via Stripe, arrives later (see §3.2).
• We use PostHog (hosted in the EU) to understand how the product is used, and this can include a recording of your session with all on-screen text and form inputs masked — but only if you click "Accept" on the cookie banner. 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 §7.
• You have rights over your data, and we honour them. If you are a rider, some of those rights are exercised through your stable (§9).

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

We do not process online payments, and we never see your card details. Inside horsenose, payment methods such as cash, pass, voucher, and BLIK are tracking labels that a stable’s staff record to note that a rider paid — they are not transactions that horsenose runs. We hold no card numbers, no bank-account numbers, and no payment-instrument data, so we are not in scope for card-industry (PCI) requirements.

Subscription billing — the fee a stable pays us to use horsenose — is planned for a later release and will be handled by Stripe as the payment processor, with horsenose as the merchant. When that launches we will update this policy and describe exactly what billing data is involved. We do not use a Merchant-of-Record arrangement.

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 (§1.1). 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/BLIK labels above);
• 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.

Session recording — please read this. With your consent, PostHog also records your session (your navigation through the app) to help us understand usability problems. All on-screen text and all form inputs are masked client-side, before the recording leaves your browser — names, phone numbers, notes, and anything you type are replaced with placeholder blocks, so the stored recording shows interactions and layout, not the personal data on the screen. Session recording is turned on only if you accept analytics; if you reject (or your browser sends a Do Not Track / Global Privacy Control signal), no session is ever recorded. PostHog retains analytics events for 6 months and session replays for 30 days, 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 (including session recording) 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 §14.

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 payment-card or bank-account data (§3.2).
• We do not knowingly collect special-category (Article 9) data (§3.7).
• 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 (§3.5);
• comply with legal obligations (for example, keeping our own subscription-invoice records once billing launches, 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 (§1.1). 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 (§11).

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 and masked session recording — EU Cloud), Sentry (error monitoring — EU), Upstash (rate-limit counters — EU Regional/Frankfurt), Cloudflare (bot protection and DNS — global edge), and Google (optional Google sign-in — US). Stripe (subscription billing) is deferred until subscription billing launches.

We sign a Data Processing Agreement with each sub-processor where required by law. Transfers outside the EEA are governed by the mechanisms in §7.

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

Our default is the EU, but it is not "100% EEA," and we will not claim otherwise. Our primary data stores, email, analytics, and error monitoring run inside the European Economic Area: Supabase in Frankfurt (eu-central-1), Vercel in fra1, Brevo in France, PostHog on its EU Cloud, and Sentry on its EU data region. For these, your data stays within the EEA.

However, some providers process data outside the EEA:

• Cloudflare operates a global edge network for bot protection, DNS, and CDN;
• Google (optional Google sign-in only) is in the United States.

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, so that data does not leave the EEA.

Where personal data is transferred from the EU to a third country, we rely — depending on the provider and the nature of the transfer — on one of the following:

• an adequacy decision of the European Commission, where one applies to the destination country;
• the EU-U.S. Data Privacy Framework (DPF), for US providers 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).

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

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 your personal data for five years.

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 (§9) — 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. When a whole stable closes or leaves horsenose, its data is retained for a maximum of 90 days. A full export is provided only if the stable requests one within that window; if no request is made, we are not obliged to provide it, and the data is deleted at the end of the window.

The automated stable-offboarding flow described above is our stated policy; parts of it are still being implemented at the date of this policy and, until then, offboarding is handled manually within the same 90-day window.

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 only records horsenose itself keeps for five years are its own subscription invoices to stables (once billing launches), 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.

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 (§1.1):

• 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 §8.
• 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 and session recording), 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.

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 — §3.4).

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 (§5). 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 (§9).

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, including masked session recording), 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, including session recording) 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 at least 30 days before they take effect (or sooner if legally required). 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.