Bezpieczeństwo i zaufanie

1. Streszczenie na jednej stronie

Nasz uczciwy stan obecny, na dzień 2026-07-08: horsenose to produkt na wczesnym etapie, prowadzony jednoosobowo. NIE posiadamy dziś SOC 2 ani ISO 27001 i nie przeszliśmy jeszcze zewnętrznego testu penetracyjnego. Ta strona opisuje, co robimy, co przechowujemy, czego jeszcze nie mamy i co jest w planach. Wolimy powiedzieć wprost, na czym stoimy, niż to wyolbrzymiać.

• Kim jesteśmy. horsenose to oprogramowanie do prowadzenia szkółki jeździeckiej — planowanie lekcji, ewidencja obecności i płatności, karnety i vouchery, wynagrodzenia instruktorów oraz wgląd klientów stajni w ich rezerwacje. Operatorem jest DF Daniel Fojcik, polska jednoosobowa działalność gospodarcza (NIP 6472592229 / REGON 387798601, Marklowice), marka Nose / horsenose.
• Nasze dwie role. Jesteśmy administratorem własnych danych kont, analityki i bezpieczeństwa oraz podmiotem przetwarzającym, działającym na polecenie każdej stajni, dla danych uczestników/klientów, które ta stajnia wprowadza. Relację powierzenia reguluje nasza Umowa Powierzenia Przetwarzania (UPP). Zob. „Ramy zgodności” niżej.
• Co przechowujemy. E-mail konta i opcjonalne imię/telefon profilu; adresy e-mail zaproszeń; wpisy operacyjne wprowadzane przez stajnię o jej uczestnikach (imiona, kontakty, udział w lekcjach, karnety/vouchery, etykiety płatności, notatki tekstowe); PIN-y harmonogramu hashowane bcryptem; tokeny zaproszeń hashowane SHA-256. Nie przechowujemy danych kart płatniczych, danych bankowych ani danych o zdrowiu. Pełny wykaz w „Dane, które przechowujemy” niżej.
• Co je chroni. TLS wszędzie z HSTS preload; szyfrowanie w spoczynku (AES-256); egzekwowana w bazie danych izolacja Row-Level Security każdej stajni; serwerowa walidacja sesji; ponowne uwierzytelnienie step-up dla działań destrukcyjnych i administracyjnych; rygorystyczna Content Security Policy; limity zapytań i ochrona przed botami; dopisujący-się log audytowy. Pełna lista w „Środki techniczne” niżej.
• Gdzie to działa. Domyślnie UE — baza danych, e-mail, analityka, monitoring błędów i magazyn limitów działają w EOG. Nie jest to 100% EOG: dwa elementy brzegowe (globalna sieć Cloudflare i opcjonalne logowanie Google w USA) leżą poza nim, objęte EU-U.S. Data Privacy Framework i/lub Standardowymi Klauzulami Umownymi. Zob. „Infrastruktura — kto za co odpowiada i gdzie to działa” niżej.
• Czego jeszcze nie mamy. Brak SOC 2, ISO 27001, zewnętrznego testu penetracyjnego i programu bug-bounty. Zob. „Czego jeszcze nie mamy — plan rozwoju” niżej. Jeśli Twój proces zakupowy wymaga dziś SOC 2, nie jesteśmy jeszcze właściwym dostawcą.
• Jak się z nami skontaktować w sprawie bezpieczeństwa. Napisz na support@horsenose.eu z `Security` w temacie. Zob. „Reagowanie na incydenty (72-godzinne powiadomienie o naruszeniu)” i „Odpowiedzialne ujawnianie podatności” niżej.

2. Dane, które przechowujemy

Zbieramy minimum potrzebne do prowadzenia Usługi. Poniższe kategorie to dane osobowe, które przechodzą przez horsenose.

Czego nie przechowujemy

• Żadnych danych kart płatniczych ani danych bankowych. Nie realizujemy płatności uczestników. „Gotówka", „karnet", „voucher" i „BLIK" to etykiety ewidencyjne stajni — nie transakcje horsenose. Rozliczenia abonamentowe (opłata stajni za horsenose) są uruchomione, ale dane karty obsługuje w całości hostowany checkout dostawcy płatności — Stripe dla polskich stajni, Dodo Payments (Merchant of Record) dla stajni spoza Polski — i nigdy do nas nie trafiają, więc pozostajemy poza zakresem PCI DSS (zob. „Ramy zgodności” niżej).
• Żadnych dokumentów tożsamości ani adresów zamieszkania. Nie zbieramy adresów zamieszkania, numerów dokumentów ani identyfikatorów państwowych.
• Żadnych danych szczególnych kategorii (o zdrowiu). Nie zamierzamy zbierać danych z art. 9 RODO, a produkt nie jest zaprojektowany do ich przechowywania. Stajnie mają (w UPP) zakaz wprowadzania takich danych do pól tekstowych. Notatki o koniu dotyczą zwierzęcia, nie osoby, i pozostają poza RODO.
• Żadnych profili reklamowych, identyfikatorów retargetingu ani śledzenia cross-site. Bez pikseli Meta/LinkedIn/X/TikTok; bez fingerprintingu przeglądarki.
• Żadnych danych sprzedawanych, wynajmowanych ani użyczanych podmiotom trzecim.
• Żadnego trenowania modeli AI/ML na Twoich danych. Nie trenujemy, nie dostrajamy ani nie ewaluujemy żadnego modelu AI/uczenia maszynowego na danych osobowych z horsenose. Rozszerzenie `pgvector` jest włączone w naszym Postgresie na potrzeby przyszłego wyszukiwania wewnętrznego, ale nie jest dziś zasilane żadnymi wektorami pochodzącymi z danych osobowych.

3. Infrastruktura — kto za co odpowiada i gdzie to działa

horsenose to aplikacja Next.js hostowana w Vercel, oparta na bazie Supabase Postgres, z niewielkim zestawem wyspecjalizowanych dostawców („podmiotów przetwarzających"), z których każdy obsługuje wąski wycinek. Żaden nie ma dostępu do wszystkiego. Naszą domyślną zasadą jest UE — i mówimy to uczciwie: baza danych, e-mail, analityka i monitoring błędów działają w EOG. Nie jest to 100% EOG — kilka elementów brzegowych leży poza nim, objętych EU-U.S. Data Privacy Framework i/lub Standardowymi Klauzulami Umownymi (SCC). Nie opublikujemy bezwarunkowego twierdzenia „wszystkie dane zostają w UE", dopóki to prawda.

Kanoniczna, zawsze aktualna wersja tej tabeli — z kategoriami danych osobowych i mechanizmami transferu per dostawca — jest utrzymywana na stronie Podmioty przetwarzające; Polityka prywatności i UPP odsyłają do tego samego źródła, zamiast utrzymywać rozbieżne kopie.

4. Środki techniczne

To są mechanizmy faktycznie wdrożone dziś. (Mechanizmy jeszcze niezbudowane są wymienione osobno w „Czego jeszcze nie mamy — plan rozwoju” niżej — nie przedstawiamy planów jako stanu obecnego.) Ta treść stanowi także podstawę UPP → „Poufność, bezpieczeństwo i dalsze podmioty przetwarzające”, która odsyła tutaj po nasze środki techniczne i organizacyjne.

Sieć i transmisja

• TLS dla całego ruchu, egzekwowany przez Vercel i Supabase. HSTS ustawiony z `max-age=63072000; includeSubDomains; preload`.
• Brak mixed content — Content Security Policy odrzuca zasoby `http://`.

Izolacja stajni i autoryzacja

• Row-Level Security (RLS) z zakresem do każdej stajni na każdej tabeli operacyjnej, egzekwowane w samej bazie danych — dane jednej stajni nie są czytelne dla innej, nawet gdyby kod aplikacji zawierał błąd. To podstawowa obrona między stajniami.
• Bramki ról w warstwie aplikacji (uwierzytelniony / w zakresie stajni / instruktor-lub-admin / super-admin) jako obrona w głąb ponad RLS — nigdy jako jedyna linia.
• Kontrole na poziomie tras wymagają aktywnej sesji dla ścieżek chronionych i statusu super-admina dla panelu administracyjnego.

Uwierzytelnianie

• Logowanie bezhasłowe — magic link e-mail (Supabase Auth) lub opcjonalne logowanie Google (OAuth). Hasła nie są przechowywane.
• Serwerowa walidacja sesji przy każdym chronionym żądaniu — sam cookie logowania nigdy nie jest ufany.
• Ponowne uwierzytelnienie step-up dla działań destrukcyjnych i administracyjnych — krótkoterminowy, osobno podpisany cookie step-up jest wymagany dla operacji takich jak usunięcie konta, zmiana roli ostatniego administratora, masowa dezaktywacja, archiwizacja stajni i wszystkie zapisy super-admina; brak lub wygaśnięcie step-up oznacza odmowę (fail-closed).
• Panel administracyjny platformy zwraca 404, gdy nie skonfigurowano super-admina, więc jego istnienie nie jest ujawniane.

Sekrety i dane uwierzytelniające

• PIN-y harmonogramu są przechowywane jako hashe bcrypt; tokeny zaproszeń jako hashe SHA-256 — jednorazowe, krótkoterminowe (7 dni), powiązane z e-mailem; surowe tokeny nigdy nie są zapisywane.
• Klucz serwisowy bazy danych działa wyłącznie po stronie serwera — nigdy nie trafia do JavaScriptu klienta; walidator na etapie builda przerywa build, jeśli wrażliwa zmienna ma błędny prefiks.

Obsługa danych wejściowych i wyjściowych

• Walidacja schematów na każdej serwerowej granicy wejścia — walidacja po stronie klienta jest traktowana wyłącznie jako UX; granicą zaufania jest serwer.
• Rygorystyczna Content Security Policy z noncem per request oraz twardo ustawiony zestaw nagłówków bezpieczeństwa (`X-Content-Type-Options`, `X-Frame-Options` / `frame-ancestors`, `Referrer-Policy`, nagłówki izolacji cross-origin i restrykcyjna `Permissions-Policy`).
• Automatyczne escapowanie treści; treści wpisywane przez użytkowników są na tym etapie zwykłym tekstem.

Ochrona przed nadużyciami i botami

• Limity zapytań na logowaniu, rejestracji, magic linkach, akceptacji zaproszeń, eksporcie/usuwaniu i innych wrażliwych endpointach (per e-mail, per IP, per użytkownik lub per stajnia, zależnie od akcji; każda polityka jest świadomie fail-open albo fail-closed).
• Cloudflare Turnstile na formularzach logowania, rejestracji, żądania magic linka, akceptacji zaproszenia i wpisywania PIN-u publicznego harmonogramu.

Dane w spoczynku i ślad audytowy

• Szyfrowanie w spoczynku przez Supabase (AES-256).
• Dopisujący-się log audytowy rejestruje zdarzenia istotne dla bezpieczeństwa (uwierzytelnianie, zmiany ról i członkostwa, zdarzenia finansowe, eksporty, usunięcia). Jest zapisywany zawsze i jest odrębny od telemetrii operacyjnej.
• Monitoring błędów z czyszczeniem danych osobowych — zanim błąd trafi do Sentry, dedykowany mechanizm usuwa adresy e-mail, numery telefonów, treści wiadomości, notatki i każde pole wyglądające na token. Pozostaje kontekst techniczny plus pseudonimiczny UUID użytkownika, identyfikator stajni, język i nazwa operacji, która zawiodła.

Kopie zapasowe i odtwarzanie

• Supabase zapewnia automatyczne codzienne kopie zapasowe (7 dni retencji w obecnym planie; dłuższa retencja planowana wraz z rozwojem Usługi). Vercel przechowuje poprzednie wdrożenia, umożliwiając niemal natychmiastowy rollback wadliwego wydania.

5. Środki organizacyjne

• Jednoosobowy operator. horsenose prowadzi jedna osoba (Daniel Fojcik). Obecnie nie ma pracowników z dostępem produkcyjnym. Jeśli to się zmieni — np. dojdzie kontraktor z dostępem produkcyjnym — ta strona zostanie zaktualizowana, a aktywne stajnie powiadomione.
• Dane produkcyjne pozostają na zarządzanej infrastrukturze. Zrzuty produkcyjnej bazy danych nie są przechowywane na lokalnych maszynach; lokalny rozwój używa osobnej bazy z danymi syntetycznymi.
• Najmniejsze uprawnienia dla kont serwisowych. Klucz serwisowy bazy działa wyłącznie po stronie serwera; dostęp przeglądarek do bazy używa ograniczonego klucza za RLS.
• Zarządzanie sekretami. Sekrety znajdują się w konfiguracji środowiskowej dostawcy hostingu i w lokalnym pliku poza repozytorium — nigdy nie są commitowane. Sekrety produkcyjne nie są kopiowane na lokalne maszyny.
• Logi dostępowe po stronie dostawców. Działania administracyjne u naszych dostawców są przez nich logowane; przeglądamy je doraźnie.
• Poufność. Personel (obecnie właściciel) jest zobowiązany do poufności w zakresie danych osobowych przetwarzanych w Usłudze, co odzwierciedla UPP.
• Dyscyplina zmian. Zmiany kodu przechodzą rygorystyczną bramkę typów, lintingu i testów automatycznych przed wdrożeniem, a migracje bazy danych są najpierw stosowane w środowisku staging.

6. Reagowanie na incydenty (72-godzinne powiadomienie o naruszeniu)

Monitoring. Błędy trafiają do Sentry (z czyszczeniem danych osobowych opisanym w „Środki techniczne” wyżej); diagnostyka na poziomie żądań jest dostępna w logach hostingu; monitor dostępności i alerty o poziomie błędów są częścią bazowego hardeningu. Dopisujący-się log audytowy zapewnia trwały zapis zdarzeń istotnych dla bezpieczeństwa na potrzeby dochodzenia.

Nasze zobowiązanie dotyczące powiadamiania o naruszeniach. Jeśli dojdzie do naruszenia ochrony danych osobowych, które może powodować ryzyko dla praw i wolności osób, których dane dotyczą:

• Powiadomimy właściwy organ nadzorczy — Prezesa UODO w Polsce — bez zbędnej zwłoki i, jeśli to wykonalne, w ciągu 72 godzin od stwierdzenia naruszenia (art. 33 RODO).
• *Jeśli naruszenie może powodować wysokie* ryzyko dla osób, których dane dotyczą, powiadomimy również te osoby bez zbędnej zwłoki, opisując charakter naruszenia, kategorie danych, prawdopodobne konsekwencje i podjęte środki (art. 34 RODO**).
• Gdy działamy jako podmiot przetwarzający dla stajni, powiadomimy tę stajnię (administratora) bez zbędnej zwłoki, aby mogła wypełnić własne obowiązki z art. 33/34 wobec swoich uczestników.

To odzwierciedla Politykę prywatności i UPP. Opisuje sposób, w jaki zamierzamy wykonać obowiązek, który RODO i tak nakłada — nie jest dodatkową obietnicą umowną ponad RODO. Sformalizowany runbook reagowania na incydenty jest w planach (zob. „Czego jeszcze nie mamy — plan rozwoju” niżej); do tego czasu jednoosobowy zespół reaguje doraźnie w powyższych terminach.

Kontakt. Sprawy zwykłe: support@horsenose.eu. Bezpieczeństwo (pilne): support@horsenose.eu z `Security` w temacie.

7. Czego jeszcze nie mamy — plan rozwoju

Ta sekcja daje reszcie strony wiarygodność: nie ukrywamy luk. Jesteśmy małą organizacją na wczesnym etapie i kilku mechanizmów, których może oczekiwać większy nabywca, jeszcze nie ma.

Jeśli proces zakupowy potencjalnej stajni wymaga dziś SOC 2, nie jesteśmy obecnie właściwym dostawcą — i powiemy to uczciwie, zamiast przeciągać rozmowę.

8. Ramy zgodności

RODO (rozporządzenie 2016/679). horsenose działa w podwójnej roli: administratora danych, o których celach i sposobach przetwarzania sam decyduje (odwiedzający stronę marketingową, dane kont/kontaktowe administratorów stajni i instruktorów, analityka za zgodą oraz dane bezpieczeństwa i zapobiegania nadużyciom), oraz podmiotu przetwarzającego dane operacyjne uczestników/klientów wprowadzane przez stajnię — tam administratorem jest stajnia, a horsenose przetwarza na jej udokumentowane polecenie w ramach UPP (art. 28 RODO). Podmioty przetwarzające działają na podstawie umów z art. 28 (DPA + SCC/DPF, gdy transfer opuszcza EOG) — zob. stronę Podmioty przetwarzające.

Dane dzieci. Szkółki jeździeckie regularnie uczą dzieci, więc horsenose świadomie przetwarza dane nieletnich w imieniu stajni (np. dziecko zapisane jako uczestnik lekcji, często przez rodzica będącego klientem stajni). Za podstawę prawną i wymagane zgody lub upoważnienia rodzicielskie (art. 8 RODO) odpowiada stajnia; horsenose minimalizuje zakres danych dziecka i nie kieruje działań marketingowych do dzieci. Zob. Politykę prywatności → „Prywatność dzieci”.

Prawa osób, których dane dotyczą, są wspierane, w tym samoobsługowy dostęp/przenoszenie przez eksport JSON w /account/export oraz usunięcie w /account/delete (obowiązuje 30-dniowa odwracalna karencja i ponowne uwierzytelnienie step-up; przy usunięciu odbieramy danym bezpośrednie identyfikatory zamiast twardego usunięcia — pseudonimizacja z art. 4 pkt 5 RODO, nie pełna anonimizacja z motywu 26; szczegóły w tabeli retencji w Polityce prywatności → „Jak długo przechowujemy dane (retencja)”). Dla danych uczestników administratorem jest stajnia, więc uczestnik realizuje prawa wobec swojej stajni, a horsenose wspiera ją jako podmiot przetwarzający.

PCI DSS — nie ma zastosowania. Nie obsługujemy, nie przechowujemy ani nie przesyłamy danych kart; gotówka/karnet/voucher/BLIK to etykiety ewidencyjne (zob. „Dane, które przechowujemy” wyżej). W rozliczeniach abonamentowych ścieżka danych karty przebiega w całości przez hostowany checkout dostawcy płatności — Stripe (procesor płatności) dla polskich stajni, z horsenose jako sprzedawcą, oraz Dodo Payments jako Merchant of Record dla stajni spoza Polski — więc horsenose nigdy nie otrzymuje danych karty i pozostaje poza zakresem PCI.

Akt UE o sztucznej inteligencji — nie ma zastosowania. horsenose to narzędzie operacyjne dla szkółek jeździeckich; nie trenuje, nie rozwija ani nie wdraża modeli AI, a żaden komponent nie używa uczenia maszynowego ani generatywnej AI do przetwarzania danych osobowych. Rozszerzenie `pgvector` w Postgresie jest włączone na potrzeby możliwych przyszłych funkcji wyszukiwania wewnętrznego, ale nie jest dziś zasilane wektorami pochodzącymi z danych osobowych; jeśli to się zmieni, przed premierą takiej funkcji opublikujemy stanowisko wobec Aktu o AI i zobowiązanie „bez trenowania na danych osobowych".

ePrivacy / cookies. Opcjonalna analityka (PostHog) wczytuje się wyłącznie za zgodą; cookies ściśle niezbędne są zwolnione na podstawie art. 5 ust. 3 dyrektywy ePrivacy. Zob. Politykę cookies.

9. Odpowiedzialne ujawnianie podatności

Jeśli uważasz, że znalazłeś podatność bezpieczeństwa w horsenose:

• Napisz na [support@horsenose.eu](mailto:support@horsenose.eu) z `Security` w temacie. (Dedykowany adres `security@` i klucz PGP są planowane — zob. „Czego jeszcze nie mamy — plan rozwoju” wyżej.)
• Załącz szczegóły wystarczające do odtworzenia problemu.
• Daj nam rozsądny czas na zbadanie i naprawę przed jakimkolwiek publicznym ujawnieniem.

Czego możesz się po nas spodziewać:

• Potwierdzenia odbioru i wstępnej oceny tak szybko, jak to rozsądnie możliwe. horsenose to usługa prowadzona jednoosobowo i nie możemy zagwarantować odpowiedzi tego samego dnia; nie zostawimy jednak wiarygodnego zgłoszenia bez reakcji.
• Aktualizacji statusu w rozsądnych odstępach, gdy problem jest analizowany lub naprawiany.
• Podziękowania w ewentualnym ujawnieniu po naprawie, jeśli sobie tego życzysz (opcjonalnie).

Czego jeszcze nie oferujemy: na tym etapie nie wypłacamy pieniężnych nagród bug-bounty. Powiemy to jasno, jeśli i kiedy program nagród stanie się dostępny.

Zakres i bezpieczna przystań. Badania bezpieczeństwa w dobrej wierze, zgodne z tą polityką — pozostające na Twoich własnych kontach, niepogarszające Usługi dla innych i niedotykające danych innych niż Twoje — nie będą traktowane jako naruszenie naszej Polityki dopuszczalnego użycia ani Regulaminu. Nie próbuj uzyskiwać dostępu do danych innej stajni lub innego uczestnika i nie prowadź automatycznego scrapowania ani testów denial-of-service wobec Usługi.

10. Historia zmian