Bezpieczeństwo i zaufanie

1. Streszczenie na jednej stronie

Nose for Horse (dalej: „Nose”) to produkt na wczesnym etapie. Nie posiadamy dziś SOC 2 ani ISO 27001 i nie zleciliśmy jeszcze zewnętrznego testu penetracyjnego. Ta strona opisuje, co przechowujemy, gdzie to działa i jakie klasy zabezpieczeń to chronią, aby stajnia dbająca o bezpieczeństwo mogła podjąć świadomą decyzję.

• Kim jesteśmy. Nose 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 for Horse.
• 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 i tokeny zaproszeń przechowywane wyłącznie jako hashe jednokierunkowe. 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. Szyfrowanie w transmisji i w spoczynku; izolacja tenantów egzekwowana w samej bazie danych; 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ć. Zob. „Środki techniczne” niżej.
• Gdzie to działa. W więcej niż jednym regionie danych i dodajemy kolejne regiony wraz z rozwojem. Dane klientów stajni w regionie USA są przechowywane w Stanach Zjednoczonych. Usługa jest prowadzona, administrowana i wspierana z Unii Europejskiej. Stajnie w naszym regionie UE są obsługiwane z EOG. Kilka usług jest wspólnych dla obu regionów i działa w EOG — e-maile transakcyjne, monitoring błędów, analityka produktu — a kilka komponentów działa globalnie. Regiony i mechanizmy transferu poszczególnych dostawców znajdziesz na stronie Dalsze podmioty przetwarzające.
• Czego jeszcze nie mamy. Brak SOC 2, ISO 27001 i zewnętrznego testu penetracyjnego. Jeśli Twój proces zakupowy wymaga dziś któregoś z nich, nie jesteśmy jeszcze właściwym dostawcą.
• Jak się z nami skontaktować w sprawie bezpieczeństwa. Napisz na support@nose.horse 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 Nose.

Tam, gdzie wiersz mówi region Twojej stajni, chodzi o region UE albo region USA — ustalony w chwili utworzenia stajni i opisany w „Infrastruktura — kto za co odpowiada i gdzie to działa” niżej.

Czego nie przechowujemy

• Żadnych danych kart płatniczych ani danych bankowych. Nose 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 Nose. 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 Nose.

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

Nose działa na zarządzanej infrastrukturze chmurowej, 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. Nose działa w dwóch regionach danych: regionie UE i regionie USA. Dane klientów stajni w regionie USA są przechowywane w Stanach Zjednoczonych. Usługa jest prowadzona, administrowana i wspierana z Unii Europejskiej. Dane operacyjne stajni znajdują się wyłącznie w bazie danych jej własnego regionu — nie ma replikacji między regionami ani ścieżki w aplikacji, która czytałaby dane między nimi. Trzy usługi są wspólne dla obu regionów i pozostają w EOG — e-maile transakcyjne, monitoring błędów i analityka produktu.

Kanoniczną, zawsze aktualną listą dostawców — z celem, kategoriami danych osobowych, regionem przetwarzania w każdym regionie danych i mechanizmem transferu — jest strona Dalsze podmioty przetwarzające. Polityka prywatności i UPP odsyłają do tego samego źródła, zamiast utrzymywać rozbieżne kopie — podobnie jak ta strona.

4. Środki techniczne

To są klasy zabezpieczeń faktycznie wdrożonych 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, z HSTS preload.
• Brak mixed content — Content Security Policy odrzuca zasoby przesyłane bez szyfrowania.

Izolacja tenantów i autoryzacja

• Zabezpieczenia na poziomie wierszy 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 tenantami.
• Kontrole ról w warstwie aplikacji jako obrona w głąb ponad izolacją w bazie danych — nigdy jako jedyna linia.

Uwierzytelnianie

• Logowanie bezhasłowe — magic link e-mail lub opcjonalne logowanie Google albo przez Apple. 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; brak lub wygaśnięcie step-up oznacza odmowę operacji.

Sekrety i dane uwierzytelniające

• PIN-y grafiku i tokeny zaproszeń są przechowywane wyłącznie jako hashe jednokierunkowe; tokeny zaproszeń są jednorazowe i krótkoterminowe, a surowe tokeny nigdy nie są zapisywane.
• Uprzywilejowane dane uwierzytelniające usług działają wyłącznie po stronie serwera — nigdy nie trafiają do przeglądarki; pilnuje tego kontrola na etapie builda.

Obsługa danych wejściowych i wyjściowych

• Każde wejście po stronie serwera jest walidowane schematem — walidacja po stronie klienta jest traktowana wyłącznie jako UX; granicą zaufania jest serwer.
• Rygorystyczna Content Security Policy i twardo ustawiony zestaw nagłówków bezpieczeństwa są stosowane do każdej odpowiedzi.
• 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ń i ochrona przed botami są stosowane na uwierzytelnianiu i innych wrażliwych endpointach.

Dane w spoczynku i ślad audytowy

• Szyfrowanie w spoczynku bazy danych i magazynu plików.
• Log audytowy, do którego można wyłącznie dopisywać, 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 — dane osobowe są usuwane ze zgłoszeń błędów, zanim opuszczą nasze systemy; pozostaje kontekst techniczny plus pseudonimiczne identyfikatory.

Kopie zapasowe i odtwarzanie

• Automatyczne codzienne kopie zapasowe bazy danych z kroczącym okresem retencji. Poprzednie wdrożenia są zachowywane, aby móc szybko wycofać wadliwe wydanie.

5. Środki organizacyjne

• 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. Uprzywilejowane dane uwierzytelniające działają wyłącznie po stronie serwera; dostęp przeglądarek do bazy odbywa się ograniczonym kluczem, za zabezpieczeniami na poziomie wierszy.
• Logi dostępowe po stronie dostawców. Działania administracyjne u naszych dostawców są przez nich logowane i podlegają przeglądom.
• Poufność. Każdy, kto ma dostęp do środowiska produkcyjnego, jest zobowiązany do poufności w zakresie danych osobowych przetwarzanych w Usłudze, co odzwierciedla UPP.

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

Monitoring. Błędy i zdarzenia istotne dla bezpieczeństwa są monitorowane, a log audytowy, do którego można wyłącznie dopisywać, zapewnia trwały zapis 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 wykonujemy obowiązek, który RODO i tak nakłada — nie jest dodatkową obietnicą umowną ponad RODO.

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

7. Czego jeszcze nie mamy

Nie posiadamy jeszcze SOC 2 ani ISO 27001 i nie zleciliśmy jeszcze zewnętrznego testu penetracyjnego. Certyfikat publikujemy wtedy, gdy go mamy — nie wcześniej. Jeśli proces zakupowy zainteresowanej stajni wymaga dziś któregoś z nich, nie jesteśmy obecnie właściwym dostawcą — i powiemy to wprost, zamiast przeciągać rozmowę.

8. Ramy zgodności

RODO (rozporządzenie 2016/679). Nose 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, tożsamość logowania każdego posiadacza konta niezależnie od roli, analityka produktu 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 Nose 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 Nose ś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; Nose 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 Nose wspiera ją jako podmiot przetwarzający; wyjątkiem jest tożsamość logowania uczestnika, której administratorem jest Nose, więc prawa do niej realizuje się bezpośrednio wobec Nose.

PCI DSS — nie ma zastosowania do Nose. 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 Nose 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 Nose jedynie przekazuje polecenia i nigdy nie otrzymuje danych karty. W każdym przypadku Nose nigdy nie otrzymuje danych karty i pozostaje poza zakresem PCI.

Akt UE o sztucznej inteligencji — nie ma zastosowania. Nose 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. 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 wczytuje się wyłącznie za zgodą (w Stanach Zjednoczonych: dopóki jej nie wyłączysz); 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 masz podejrzenie, że w Nose występuje podatność bezpieczeństwa:

• Napisz na [support@nose.horse](mailto:support@nose.horse) 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; nie zostawimy 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).

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