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 i czego jeszcze nie mamy. 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ę na temat jej uczestników (imiona, kontakty, udział w lekcjach, karnety/vouchery, etykiety płatności, notatki tekstowe); PIN-y grafiku 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; log audytowy, do którego można wyłącznie dopisywać. Pełna lista w „Środki techniczne” niżej.
• Gdzie to działa. W więcej niż jednym regionie i dodajemy kolejne regiony wraz z rozwojem — aktualny główny region każdego dostawcy jest wskazany w „Infrastruktura — kto za co odpowiada i gdzie to działa” niżej i może się zmieniać w miarę naszego rozwoju. Dziś większość podstawowego przetwarzania odbywa się w EOG (baza danych, e-mail, analityka, monitoring błędów i magazyn limitów), a kilka komponentów już działa poza nim (globalna sieć edge Cloudflare; logowanie Google oraz część Stripe w USA; Dodo Payments globalnie). Każda ścieżka między regionami jest objęta odpowiednim mechanizmem transferu — EU-U.S. Data Privacy Framework, unijnymi Standardowymi Klauzulami Umownymi, brytyjskim Addendum (UK Addendum) albo mechanizmem równoważnym wymaganym przez dodany region.
• Czego jeszcze nie mamy. Brak SOC 2, ISO 27001, zewnętrznego testu penetracyjnego i programu bug-bounty. 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. horsenose nigdy nie jest stroną płatności i nigdy nie obsługuje danych kart. Metody offline („gotówka", „karnet", „voucher", „przelew") to etykiety ewidencyjne stajni — nie transakcje horsenose. Dla rozliczeń abonamentowych stajni (Stripe dla polskich stajni, Dodo Payments jako Merchant of Record dla stajni spoza Polski) oraz dla płatności online uczestników, gdy stajnia je włączy (Stripe, z rozliczeniem na własne konto stajni), dane karty obsługuje w całości checkout dostawcy płatności 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 międzywitrynowego. 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. Działamy w więcej niż jednym regionie i dodajemy kolejne regiony wraz z rozwojem, dlatego opisujemy, gdzie procesy działają dziś, zamiast obiecywać jedną trwałą lokalizację: większość podstawowego przetwarzania — baza danych, e-mail, analityka produktu i monitoring błędów — odbywa się w EOG, a kilka komponentów już działa poza nim (globalna sieć edge Cloudflare; opcjonalne logowanie Google oraz część Stripe w USA; Dodo Payments na globalnej zasadzie Merchant of Record). Aktualny główny region każdego dostawcy jest w poniższej tabeli i jest utrzymywany na bieżąco w miarę zmian; każda ścieżka między regionami jest objęta odpowiednim mechanizmem transferu (EU-U.S. Data Privacy Framework, Standardowe Klauzule Umowne, brytyjski Addendum (UK Addendum) albo mechanizm równoważny wymagany przez dodany region).

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ś. 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 plik cookie logowania nigdy nie jest uznawany za wystarczający.
• 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 grafiku 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 grafiku.

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; 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. 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, brytyjski Addendum albo mechanizm równoważny, gdy transfer przekracza regiony) — 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 zgodnie z prawem, któremu podlega (art. 8 RODO w UE i Zjednoczonym Królestwie; COPPA i prawo stanowe w Stanach Zjednoczonych), 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 do horsenose. Nie obsługujemy, nie przechowujemy ani nie przesyłamy danych kart. W rozliczeniach abonamentowych stajni ś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. Dla płatności online uczestników, gdy stajnia je włączy, dane karty, portfela lub (w Polsce) BLIK-a przebiegają w całości przez Stripe (przez Stripe Connect) i rozliczają się na własne konto Stripe stajni — sprzedawcą jest stajnia, a Stripe jest zgodnym z PCI procesorem, natomiast horsenose jedynie przekazuje polecenia i nigdy nie otrzymuje danych karty. W każdym przypadku 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.

8. Odpowiedzialne ujawnianie podatności

Jeśli masz podejrzenie, że w horsenose występuje podatność bezpieczeństwa:

• Napisz na [support@horsenose.eu](mailto:support@horsenose.eu) z `Security` w temacie. (Dedykowany adres `security@` i klucz PGP są planowane.)
• 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.

9. Historia zmian