Polityka prywatności MyBreederLine

Wersja 2.0 · obowiązuje od 2026-05-25

§ 1. Administrator danych i role

1. Administratorem danych osobowych Użytkowników (hodowców) korzystających z usługi MyBreederLine jest Wojciech Derda, adres korespondencyjny: ul. Orla 47 m 21, 75-727 Koszalin, Polska.

2. Usługodawca świadczy Usługę jako osoba fizyczna prowadząca działalność nierejestrową na terytorium Rzeczypospolitej Polskiej. Do momentu rejestracji działalności gospodarczej Usługodawca nie posiada numeru NIP ani wpisu do CEIDG — informacja zostanie zaktualizowana w niniejszej Polityce po ewentualnej rejestracji.

3. Podwójna rola w CRM:

   • w zakresie Konta hodowcy (e-mail, profil, subskrypcja) — Usługodawca jest administratorem;
   • w zakresie danych klientów hodowli wprowadzanych do modułu CRM — hodowca jest administratorem, a Usługodawca działa jako procesor na podstawie Umowy powierzenia przetwarzania danych (art. 28 RODO). W sprawach dotyczących danych CRM klientów hodowca powinien być pierwszym punktem kontaktu dla swoich klientów; Usługodawca wspiera hodowcę jako procesor.

4. Inspektor Ochrony Danych (IOD) nie został powołany — kontakt bezpośrednio z administratorem.

5. Kontakt w sprawach ochrony danych (RODO): rodo@kontakt.mybreederline.pl

6. Kontakt techniczny i obsługa produktu: support@kontakt.mybreederline.pl

7. Skrzynka RODO w module wsparcia: wiadomości kierowane na adresy powiązane ze skrzynką rodo (obsługa administracyjna przez operatorów platformy) — patrz § 12.

§ 2. Definicje

| Termin | Znaczenie | |--------|-----------| | Usługa | platforma SaaS MyBreederLine (aplikacja web/mobile, API, landing www) | | Użytkownik / Hodowca | osoba z Kontem w Usłudze | | Konto | konto uwierzytelniane w Supabase Auth powiązane z profilem hodowcy | | Dane CRM | dane osobowe klientów hodowli wprowadzane przez Hodowcę | | Dane hodowlane | dane o kotach, miotach, planach krycia — co do zasady nie są danymi osobowymi (dotyczą zwierząt), z wyjątkiem sytuacji, gdy Użytkownik umieści w notatkach dane osób fizycznych | | Procesor / Podprocesor | podmiot przetwarzający dane w imieniu administratora na podstawie umowy powierzenia | | EOG | Europejski Obszar Gospodarczy |

§ 3. Zakres Polityki

1. Polityka opisuje przetwarzanie danych w produkcyjnej wersji Usługi dostępnej pod adresami www.mybreederline.pl, app.mybreederline.pl, api.mybreederline.pl oraz powiązanymi domenami (np. link.mybreederline.pl, admin.mybreederline.pl).

2. Polityka uzupełnia Regulamin i Umowę powierzenia.

3. Architektura (skrót): aplikacja Flutter → Supabase (PostgreSQL, Auth, Storage, Realtime, Edge Functions); wąskie API FastAPI na Render (region Frankfurt); ruch publiczny przez Cloudflare (DNS, TLS, CDN, WAF); e-maile transakcyjne przez Resend; płatności przez Stripe; monitoring błędów przez Sentry (region UE de.sentry.io).

§ 4. Jakie dane przetwarzamy — rejestr

4.1. Konto hodowcy (auth.users, profiles)

| Pole / kategoria | Opis | Obowiązkowe | Wrażliwość | |------------------|------|-------------|------------| | id (UUID) | identyfikator konta | tak | identyfikator | | email | logowanie, komunikacja | tak | PII | | Hasło | hash w Supabase Auth (bcrypt/argon — algorytm Auth) | tak | krytyczne | | nazwa_hodowli | nazwa wyświetlana hodowli | praktycznie tak | niska | | logo_path | ścieżka do logo w Storage | nie | obraz | | account_type | User / beta_tester / VIP | tak (system) | billing/ops | | subscription_plan_key | hobby / standard / pro | tak (default hobby) | billing | | trial_ends_at | koniec 14-dniowego trialu Standard | nie | billing | | stripe_customer_id, stripe_subscription_id, stripe_subscribed_price_id, subscription_status, billing_price_generation | identyfikatory i status płatności Stripe | nie | identyfikatory płatności | | retention_policy_key i powiązane | polityka retencji operacyjnej danych | tak (default) | operacyjne | | created_at | data rejestracji | tak (auto) | metadata |

Podstawa prawna: art. 6 ust. 1 lit. b RODO (wykonanie umowy — Regulamin).

4.2. Dane hodowlane — koty (cats)

| Pole | Opis | PII | |------|------|-----| | imie, przydomek, rasa, plec, kolor, ems_pelny | identyfikacja hodowlana | nie (dane o zwierzęciu) | | data_urodzenia, numer_chip, numery rodowodu | ewidencja | nie | | status, death_date, death_note | status życia / zgonu | death_note może przypadkowo zawierać PII, jeśli Użytkownik je wpisze | | photo_path | zdjęcie kota (Storage) | nie (zwierzę); zdjęcie może teoretycznie zawierać wizerunek osoby w tle — odpowiedzialność Użytkownika | | owner_id, relacje rodowe | multi-tenant | identyfikator hodowcy | | deleted_at, deleted_by | wycofanie kartoteki z widoku hodowcy (soft delete) | identyfikator hodowcy / operatora przy przywróceniu |

Podstawa prawna: art. 6 ust. 1 lit. b RODO (usługa hodowlana).

Przywrócenie wycofanej kartoteki: na prośbę hodowcy operator platformy może wyświetlić ograniczony podgląd pól identyfikacyjnych (patrz § 4.8 ust. 2) — bez historii ważeń, dokumentów, rezerwacji i CRM.

4.3. Mioty, plany krycia, wagi (litters, breedings, cat_weight_entries)

Dane operacyjne hodowlane: daty, liczby, statusy, notatki (notes), wagi w gramach. Co do zasady nie są danymi osobowymi. Notatki mogą zawierać PII, jeśli Użytkownik je wprowadzi.

Podstawa prawna: art. 6 ust. 1 lit. b RODO.

4.4. Dane medyczne / zdrowotne zwierząt

1. MyBreederLine nie jest systemem medycznym weterynaryjnym i nie posiada dedykowanej tabeli historii leczenia, diagnoz ani recept.

2. W Usłudze występują wyłącznie:

   • wagi kociąt (cat_weight_entries) — dane biometryczne zwierząt, nie art. 9 RODO;
   • death_date / death_note przy statusie deceased — data zgonu i opcjonalna notatka hodowcy (deklaracja w schemacie: bez danych osobowych klientów);
   • checklisty dokumentów przy sprzedaży (documents_flags JSON) — znaczniki typu „umowa podpisana”, bez przechowywania treści PDF.

3. Jeśli Użytkownik wpisze w notatkach informacje o stanie zdrowia osób lub dane medyczne zwierząt wykraczające poza powyższy zakres — czyni to na własną odpowiedzialność i powinien posiadać właściwą podstawę prawną.

4.5. CRM — klienci hodowli (administrator: hodowca; procesor: Usługodawca)

| Tabela | Pola (wybór) | PII | |--------|--------------|-----| | clients | imie, nazwisko, telefon, email, notatka, typ_klienta, nazwa_hodowli, panstwo_miasto, strona_hodowli | tak | | client_preferences | preferencje rasy, płeć, cel, notatka | może zawierać PII | | client_notes | treść notatek | może zawierać PII | | client_tasks | tytuł, opis, terminy | może zawierać PII | | client_events | timeline zdarzeń (JSON) | może zawierać PII | | client_pinned_links | powiązania z miotami/kotami | kontekst | | client_purchases | data, kwota, uwagi, powiązanie z kotem | kwoty; uwagi mogą zawierać PII | | cat_reservations | daty, kwoty PLN, statusy pipeline, notes | tak (finanse + notatki) |

Podstawa prawna (procesor): art. 28 RODO — umowa powierzenia; podstawa po stronie hodowcy (administratora) określa hodowca wobec swoich klientów (np. umowa, zgoda, uzasadniony interes).

4.6. Lista oczekujących / wczesny dostęp (beta_waitlist)

| Pole | Opis | Podstawa | |------|------|----------| | email | kontakt w sprawie zaproszenia | zgoda (art. 6 ust. 1 lit. a) | | consent_at | moment wyrażenia zgody | dowód zgody | | consent_withdrawn_at | wycofanie zgody | dowód | | status | pending / approved / rejected / withdrawn | operacyjne | | notes | m.in. zapis ip:{adres} dla rate limitu | dane techniczne | | created_at, approved_at | metadata | operacyjne |

Brak profilowania marketingowego — lista służy wyłącznie wczesnemu dostępowi, nie reklamie behawioralnej.

4.7. Wsparcie i korespondencja (support_threads, support_messages, email_outbox)

| Obszar | Dane | |--------|------| | Wątek support | contact_email, powiązanie profile_id lub beta_waitlist_id, mailbox (support / rodo) | | Wiadomości | treść korespondencji, nagłówki e-mail | | Kolejka wysyłki | to_email, szablon, payload JSON, status dostarczenia |

Podstawa: art. 6 ust. 1 lit. b (obsługa umowy) lub f (uzasadniony interes — obsługa zapytań RODO).

4.8. Operatorzy platformy (platform_admins)

Dostęp do panelu operatora admin.mybreederline.pl jest warstwowy — każda warstwa musi zostać spełniona, zanim operator uzyska dostęp do funkcji administracyjnych.

| Warstwa | Mechanizm | Jakie dane mogą być przetwarzane | |---------|-----------|-------------------------------------| | 1. Cloudflare Access | weryfikacja tożsamości przez GitHub przed wejściem na host admin; dozwoleni operatorzy (collaboratorzy repozytorium produktu lub e-mail z listy ACCESS_GITHUB_ALLOWED_EMAILS) | adres IP, nagłówki HTTP, identyfikator sesji Access, e-mail konta GitHub (do decyzji o dopuszczeniu) | | 2. Supabase Auth | e-mail + hasło operatora (osobne konto Auth, nie konto hodowcy) | e-mail, hash hasła, identyfikator UUID sesji | | 3. TOTP (aplikacja Authenticator) | obowiązkowe uwierzytelnianie dwuskładnikowe — 6-cyfrowy kod z aplikacji (Google Authenticator, Authy lub równoważnej); pierwsze logowanie: rejestracja sekretu TOTP (QR) | sekret TOTP (po stronie Supabase Auth), znaczniki czasu weryfikacji | | 4. platform_admins | wpis w bazie — ostateczna autoryzacja roli operatora; weryfikacja w Edge Functions (is_platform_admin) | UUID operatora, data nadania uprawnień |

1. Operatorzy nie mają rutynowego dostępu do treści hodowlanych innych użytkowników przez UI hodowcy. Operacje administracyjne (waitlist, billing, support) wykonywane są przez Edge Functions z JWT operatora i sprawdzeniem is_platform_admin.

2. Odzyskiwanie wycofanych kartotek kotów: wyłącznie na uzasadnioną prośbę hodowcy (support) — operator widzi skrócony podgląd (imię, rasa, płeć, data urodzenia, chip, rodowód, EMS, miniaturowe zdjęcie, daty utworzenia/usunięcia, identyfikatory powiązań z miotem) w celu identyfikacji wpisu przed przywróceniem. Moduł nie udostępnia historii ważeń, dokumentów hodowlanych, rezerwacji, zakupów ani treści CRM. Każde przywrócenie jest rejestrowane w audycie platformy wraz z powodem operacji.

3. Cloudflare dodatkowo stosuje WAF i rate limiting na subdomenie admin. (ochrona przed nadużyciami i atakami siłowymi) — patrz § 4.9 i § 15.

4. Lokalne środowisko deweloperskie (localhost) nie przechodzi przez Cloudflare Access — obowiązuje wyłącznie Supabase Auth + TOTP.

Podstawa: art. 6 ust. 1 lit. f RODO (bezpieczeństwo, kontrola dostępu operatorów, administrowanie platformą).

4.9. Logi techniczne i identyfikatory

| Źródło | Zawartość | Czego nie logujemy w access log API | |--------|-----------|----------------------------------------| | FastAPI (Render) | X-Request-ID, metoda HTTP, ścieżka URL (bez body), kod odpowiedzi, czas obsługi, user_id (UUID) | hasła, tokeny sesji, treść body, imiona kotów, CRM | | Supabase | logi platformy, opcjonalnie Log Drains | zależne od konfiguracji | | Cloudflare | IP, nagłówki HTTP, ścieżka, WAF | pełna treść body | | Stripe webhook (stripe_webhook_events) | event_id, event_type — idempotencja | pełne dane karty | | Edge Functions | logi wykonania (stdout) | minimalizacja PII w logach |

Podstawa: art. 6 ust. 1 lit. f RODO (bezpieczeństwo, diagnostyka, zapobieganie nadużyciom).

4.10. Sentry (monitorowanie błędów)

| Warstwa | Co może trafić do Sentry | Region | |---------|---------------------------|--------| | Flutter (frontend) | stack trace, typ urządzenia, wersja aplikacji, UUID użytkownika (SentryUser.id), transakcje performance (w tym wywołania Supabase przez SentryHttpClient) | UE (de.sentry.io) | | FastAPI (backend) | stack trace, UUID użytkownika z JWT, request_id; przy send_default_pii=True także IP, User-Agent i inne domyślne metadane żądania HTTP | UE |

Filtry aplikacyjne odrzucają m.in. błędy konfiguracji Supabase i znane błędy silnika CanvasKit na web.

Podstawa: art. 6 ust. 1 lit. f RODO (utrzymanie niezawodności Usługi).

4.11. Stripe (płatności)

| Gdzie | Co przechowujemy | Co przechowuje Stripe | |-------|------------------|----------------------| | MyBreederLine (profiles) | stripe_customer_id, stripe_subscription_id, status subskrypcji, price_id | — | | Stripe | — | e-mail, metoda płatności (tokenizowana), historia faktur, adres rozliczeniowy jeśli podany |

MyBreederLine nie przetwarza ani nie przechowuje pełnych numerów kart ani CVV.

Podstawa: art. 6 ust. 1 lit. b RODO (subskrypcja) + obowiązki PCI po stronie Stripe.

§ 5. Cele przetwarzania

| Cel | Zakres danych | |-----|---------------| | Rejestracja, logowanie, sesja | e-mail, hasło (hash), token sesji | | Świadczenie Usługi hodowlanej | dane hodowlane, pliki, CRM | | Subskrypcja i billing | identyfikatory Stripe, plan, trial | | E-mail transakcyjny | adres, treść szablonu (potwierdzenia, billing, waitlist) | | Lista oczekujących | e-mail, zgoda, IP (rate limit) | | Wsparcie techniczne i RODO | korespondencja, identyfikator konta | | Bezpieczeństwo | logi, rate limit, RLS, WAF | | Diagnostyka i niezawodność | Sentry, access log | | Retencja operacyjna | automatyczne usuwanie/archiwizacja wg polityki planu | | Kopie zapasowe | snapshot bazy (Supabase) | | Obowiązki prawne | dane wymagane przepisami podatkowymi — po rejestracji DG |

§ 6. Podstawy prawne (RODO) — podsumowanie

| Podstawa | Zastosowanie | |----------|--------------| | Art. 6 ust. 1 lit. b — wykonanie umowy | Konto, dane hodowlane, CRM (jako procesor), subskrypcja | | Art. 6 ust. 1 lit. a — zgoda | Lista oczekujących (checkbox na www) | | Art. 6 ust. 1 lit. f — uzasadniony interes | Logi bezpieczeństwa, Sentry, Cloudflare WAF, zapobieganie nadużyciom waitlist | | Art. 28 — procesor | CRM klientów hodowcy | | Art. 9 | Nie przetwarzamy danych szczególnych kategorii w imieniu hodowcy w dedykowanych polach — odpowiedzialność za treść notatek spoczywa na Użytkowniku |

§ 7. Profilowanie i zautomatyzowane decyzje

1. Nie stosujemy profilowania w rozumieniu art. 22 RODO ani zautomatyzowanego podejmowania decyzji wywołujących skutki prawne lub w podobny sposób istotnie wpływających na Użytkownika.

2. Automatyczne reguły produktowe (np. limit miotów rocznie, wygaśnięcie trialu, cron retencji danych) nie oceniają Użytkownika jako konsumenta — egzekwują wyłącznie parametry Planu.

3. Moduł skanowania duplikatów kotów (duplicate-scan) wykrywa potencjalnie zduplikowane rekordy w obrębie Konta hodowcy — bez oceny osób fizycznych.

§ 8. Magazyn plików (Supabase Storage)

| Bucket | Prywatny | Limit | MIME | Ścieżka | |--------|----------|-------|------|---------| | cat-photos | tak | 10 MB | JPEG, PNG, WebP | {owner_id}/{cat_id}.ext | | breeder-logos | tak | 2 MB | JPEG, PNG, WebP | {user_id}/logo.ext |

1. Pliki nie są publicznie dostępne — dostęp wymaga uwierzytelnienia i polityk RLS Storage (folder = UUID użytkownika).

2. PDF i dokumenty umów — nie są obecnie przechowywane w chmurze MyBreederLine. Aplikacja rejestruje wyłącznie checklistę (documents_flags). <!-- TODO: Po wdrożeniu uploadu PDF — uzupełnić § 8 o bucket, limity, retencję i podstawę prawną. -->

3. Usunięcie plików przy usuwaniu Konta: aplikacja usuwa obiekty przez Storage API przed RPC delete_my_account (bez bezpośredniego DELETE w SQL na storage.objects).

§ 9. Pamięć lokalna urządzenia (Flutter / Drift)

1. Aplikacja może przechowywać na urządzeniu Użytkownika:

   • token sesji Supabase (secure storage / localStorage na web);
   • cache lokalny (Drift/SQLite) — snapshot listy kotów, kolejka synchronizacji (sync_outbox);
   • ustawienia UI i szkice formularzy;
   • identyfikator diagnostyczny Sentry.

2. Cache jest czyszczony przy wylogowaniu i usunięciu Konta (w zakresie obsługiwanym przez aplikację na danej platformie).

3. Użytkownik może dodatkowo usunąć dane aplikacji w ustawieniach systemu operacyjnego / przeglądarki.

§ 10. Pliki cookies i podobne technologie

10.1. Strona www (landing)

• Brak analityki marketingowej (Google Analytics, Meta Pixel itp.) w kodzie produkcyjnym.
• Brak bannera cookies — stosujemy wyłącznie technologie niezbędne do działania strony; szczegóły: Polityka cookies.
• Cloudflare i hosting mogą ustawiać cookies techniczne (np. __cf_bm, sesja CDN) — patrz polityka Cloudflare.

10.2. Aplikacja Flutter (web / mobile)

• Sesja Supabase — niezbędna do utrzymania logowania.
• Sentry — diagnostyka błędów (uzasadniony interes / niezbędność dla stabilności).
• Na web: localStorage / IndexedDB dla sesji i cache Drift.

10.3. Stripe Checkout (osadzony)

• Stripe może ustawiać własne cookies w procesie płatności — patrz Polityka prywatności Stripe.

§ 11. Odbiorcy danych i podprocesorzy

Dane mogą być powierzane następującym podmiotom (umowy powierzenia / DPA zgodnie z ofertą dostawcy):

| Podmiot | Rola | Zakres | Polityka prywatności | |---------|------|--------|---------------------| | Supabase, Inc. | hosting DB (PostgreSQL), Auth, Storage, Realtime, Edge Functions | dane Konta, hodowlane, CRM, pliki | https://supabase.com/privacy | | Render Services, Inc. | hosting API FastAPI (Frankfurt) | logi access, env secrets | https://render.com/privacy | | Cloudflare, Inc. | DNS, TLS, CDN, WAF, rate limit | IP, HTTP metadata | https://www.cloudflare.com/privacypolicy/ | | Stripe Payments Europe, Ltd. | płatności, Customer Portal | dane płatnicze, e-mail | https://stripe.com/privacy | | Resend, Inc. | wysyłka e-maili transakcyjnych | adresy, treść szablonów | https://resend.com/legal/privacy-policy | | Functional Software, Inc. (Sentry) | monitoring błędów (region DE) | stack trace, UUID, ewent. IP (API) | https://sentry.io/privacy/ |

Edge Functions Supabase (wybór): stripe-webhook, billing-create-checkout-session, billing-create-portal-session, billing-expire-trials, beta-waitlist-submit, beta-waitlist-withdraw, beta-before-user-created, auth-send-email, email-worker, email-resend-webhook, email-inbound-resend, data-maintenance, duplicate-scan, funkcje administracyjne (beta-admin-*, billing-admin-api, support-admin-api). Wykonują przetwarzanie z service role wyłącznie w zakresie opisanym w kodzie funkcji.

§ 12. Transfer danych poza EOG

1. Główna baza produkcyjna (Supabase) i region API (Render Frankfurt) znajdują się w EOG.

2. Niektórzy podprocesorzy (Render — siedziba USA, Cloudflare — globalna sieć, Resend — USA, Sentry — możliwość przetwarzania w USA mimo regionu ingest UE) mogą przekazywać dane poza EOG.

3. Transfer odbywa się na podstawie:

   • Standardowych Klauzul Umownych (SCC) w wersji zatwierdzonej przez Komisję Europejską, oferowanych przez dostawców;
   • lub innych mechanizmów z art. 46 RODO.

4. Stripe Payments Europe świadczy usługi płatnicze w ramach europejskiej spółki grupy Stripe — szczegóły w dokumentacji Stripe dla merchantów w UE.

§ 13. Okresy przechowywania (retencja)

13.1. Dane do momentu usunięcia przez Użytkownika

| Kategoria | Okres | |-----------|-------| | Konto, profil, dane hodowlane, CRM | do usunięcia Konta przez Użytkownika lub rozwiązania umowy | | Subskrypcja Stripe | identyfikatory w profiles przez czas trwania subskrypcji + okres rozliczeniowy księgowego wymagany prawem |

13.2. Retencja operacyjna (automatyczna — cron data-maintenance)

Okresy zależą od retention_policy_key powiązanego z Planem (standard / premium / vip). Wartości z tabeli data_retention_policies (repo):

| Typ danych | Standard | Premium (trial Standard, plan płatny) | VIP | |------------|----------|---------------------------------------|-----| | Wagi kociąt | 365 dni | 730 dni | 1825 dni | | Powiadomienia (przeczytane) | 90 dni | 180 dni | 365 dni | | Powiadomienia (nieprzeczytane) | 365 dni | 730 dni | bez limitu (NULL) | | Skany duplikatów (runs) | 90 dni | 180 dni | 365 dni | | Kandydaci duplikatów (zamknięci) | 365 dni | 365 dni | 730 dni | | Zdarzenia rezerwacji (timeline) | 730 dni | 1095 dni | 1825 dni | | Zdarzenia CRM (timeline) | 730 dni | 1095 dni | 1825 dni | | Taski CRM (zakończone) | 365 dni | 730 dni | 1095 dni | | Auto-archiwum miotów | 1095 dni | 1825 dni | bez auto-archiwum |

Po obniżce Planu stosuje się 7-dniowy okres łaski (retention_downgrade_grace_ends_at) z poprzednią polityką retencji.

Szczegóły prezentowane są w aplikacji: Ustawienia → Przechowywanie danych.

13.3. Lista oczekujących

| Stan | Okres | |------|-------| | Aktywna zgoda | do wysłania zaproszenia lub wycofania zgody | | Wycofana zgoda (withdrawn) | wpis pozostaje bez dalszego kontaktu marketingowego — do czasu usunięcia rekordu | | IP w polu notes | tak długo jak wpis waitlist — <!-- TODO: rozważyć migrację IP do osobnej kolumny z krótszą retencją --> |

13.4. Logi

| Źródło | Okres orientacyjny | |--------|-------------------| | Render (access log) | zgodnie z polityką Render — zwykle do kilkunastu tygodni | | Cloudflare | zgodnie z ustawieniami konta Cloudflare | | Sentry | zgodnie z planem retencji projektu Sentry | | Supabase Log Drains | konfiguracja projektu |

13.5. Webhook Stripe (stripe_webhook_events)

Identyfikatory zdarzeń przechowywane dla idempotencji — okres techniczny wynikający z polityki utrzymania bazy (brak osobnego UI usuwania).

§ 14. Kopie zapasowe

1. Baza danych Supabase (produkcja) objęta jest kopiami zapasowymi wykonywanymi codziennie, przechowywanymi przez około 7 dni.

2. Usunięcie danych w aplikacji nie powoduje natychmiastowego usunięcia z kopii zapasowych w tym oknie.

3. Kopie służą odtworzeniu Usługi po awarii — nie zastępują eksportu danych przez Użytkownika.

§ 15. Bezpieczeństwo przetwarzania

1. Szyfrowanie transmisji: TLS 1.2+ (HTTPS) na wszystkich publicznych endpointach.

2. Row Level Security (RLS): tabele z danymi hodowcy (cats, clients, litters, itd.) — polityki owner_id = auth.uid(). Tabele platformowe (beta_waitlist, app_settings) — brak dostępu dla ról anon / authenticated przez PostgREST.

3. Storage RLS: operacje tylko na folderze własnym UUID użytkownika.

4. Auth: Supabase Auth (e-mail/hasło); hasła hashowane po stronie Auth; rate limiting Auth w konfiguracji Supabase.

5. Panel admin (operatorzy): dostęp warstwowy — Cloudflare Access (GitHub) → Supabase Auth (e-mail + hasło) → TOTP (aplikacja Authenticator) → wpis w platform_admins; brak dostępu hodowcy do danych innych tenantów.

6. Stripe webhook: weryfikacja podpisu stripe-signature; idempotencja zdarzeń.

7. Cloudflare WAF / rate limit: ochrona admin. i api. przed nadużyciami.

8. Sekrety: wyłącznie zmienne środowiskowe / GitHub Environments / Supabase Secrets — nie w repozytorium kodu.

9. Incydenty: w przypadku naruszenia ochrony danych osobowych Usługodawca poinformuje hodowców (jako administratorów danych CRM) zgodnie z Umową powierzenia — bez zbędnej zwłoki po stwierdzeniu naruszenia.

§ 16. Prawa osób, których dane dotyczą

16.1. Hodowca (Użytkownik SaaS)

Przysługują Ci prawa z RODO:

| Prawo | Jak zrealizować w MyBreederLine | |-------|----------------------------------| | Dostęp | Profil, podgląd danych w aplikacji; wniosek na rodo@ | | Sprostowanie | Edycja profilu, kotów, CRM w aplikacji | | Usunięcie | Usunięcie Konta (Profil → Usuń konto) | | Ograniczenie | Wniosek na rodo@ | | Przenoszenie | Eksport — patrz § 17 | | Sprzeciw | Wobec przetwarzania na podstawie art. 6 ust. 1 lit. f — wniosek na rodo@ | | Wycofanie zgody | Waitlist — link w e-mailu lub rodo@ | | Skarga do PUODO | Prezes Urzędu Ochrony Danych Osobowych, ul. Stawki 2, 00-193 Warszawa, uodo.gov.pl |

Termin odpowiedzi na wnioski RODO: bez zbędnej zwłoki, nie później niż 30 dni od otrzymania wniosku.

16.2. Klienci hodowli (osoby trzecie)

Klienci hodowli powinni kierować żądania do hodowcy (administratora). Usługodawca jako procesor wspiera hodowcę w zakresie technicznym (Usługa powierzenia, § 6 DPA).

§ 17. Usunięcie Konta

1. Użytkownik może trwale usunąć Konto w aplikacji (Profil → Usuń konto, potwierdzenie słowem „USUŃ”).

2. Procedura techniczna:

   • usunięcie plików ze Storage (cat-photos, breeder-logos) przez aplikację;
   • RPC delete_my_account — usunięcie m.in. breedings, litters, cat_reservations, clients, cats, profiles, auth.users.

3. Skutek: trwałe usunięcie danych z aktywnej bazy; dane mogą pozostać w backupach do 7 dni (§ 14).

4. Subskrypcja Stripe: przed usunięciem Konta zalecamy anulowanie Subskrypcji w Stripe Customer Portal.

§ 18. Eksport danych (przenoszenie)

1. W aplikacji (Ustawienia → Dane i retencja) Użytkownik może samodzielnie pobrać kopię danych:

   • JSON — pełne dane hodowlane i CRM (profile bez identyfikatorów Stripe, koty, mioty, krycia, CRM, rezerwacje, akceptacje dokumentów prawnych bez adresu IP i user-agent);
   • ZIP (paczka ze zdjęciami i logo) — dla większych kont lub na żądanie; link do pobrania wysyłany e-mailem (ważny 72 h).

2. Limit techniczny: co najwyżej jeden udany eksport na 24 godziny na Konto (liczy się zakończenie generacji paczki). Nieudane próby można ponawiać, z limitem 3 nieudanych prób na 24 h.

3. Format: JSON (export_schema_version: 1) lub ZIP (manifest.json, data/export.json, photos/, logo/). Hasło do Konta nie jest dołączane (przechowywane wyłącznie u dostawcy uwierzytelniania).

4. Wnioski trudne do zrealizowania samoobsługowo lub poza zakresem paczki: rodo@kontakt.mybreederline.pl — realizacja w terminie do 30 dni, w formacie maszynowo czytelnym w miarę możliwości technicznych.

§ 19. Lista oczekujących i zgody marketingowe

1. Zapis na listę na www.mybreederline.pl wymaga wyraźnej zgody (checkbox) na kontakt w sprawie wczesnego dostępu do MyBreederLine — nie jest to zgoda na newsletter ogólny ani profilowaną reklamę.

2. Po zapisie wysyłamy e-mail potwierdzający z linkiem wycofania zgody (/wycofaj-zgode/ → Edge beta-waitlist-withdraw).

3. Wycofanie zgody możliwe także przez rodo@kontakt.mybreederline.pl.

4. Rate limit: max. 5 zgłoszeń na IP na godzinę — adres IP zapisywany tymczasowo w polu notes (ip:…) wyłącznie w celu zapobiegania nadużyciom.

5. Brak newslettera produktowego w obecnej wersji — komunikacja e-mailowa po rejestracji Konta ogranicza się do transakcyjnej (billing, bezpieczeństwo, wsparcie).

§ 20. Obowiązek podania danych

| Obszar | Obowiązek | |--------|-----------| | E-mail, hasło, nazwa hodowli | wymagane do założenia Konta | | Dane hodowlane / CRM | dobrowolne w zakresie funkcji — brak wpływu na samo Konto | | Lista oczekujących | dobrowolna | | Płatność Stripe | wymagana tylko przy wykupieniu Planu płatnego |

Brak podania danych wymaganych do Konta uniemożliwia korzystanie z Usługi.

§ 21. Zmiany Polityki prywatności

1. Istotne zmiany publikujemy na https://www.mybreederline.pl/polityka-prywatnosci/ i w aplikacji z nowym numerem wersji i datą obowiązywania.

2. Przy zmianach dotyczących przetwarzania na podstawie zgody poinformujemy Użytkowników e-mailem, gdy będzie to wymagane.

3. Dalsze korzystanie z Usługi po wejściu w życie zmian oznacza akceptację — o ile przepisy nie wymagają ponownej zgody.

4. Wersja 2.0 z dnia 2026-05-25 zastępuje wersję 1.1 z dnia 2026-05-24.

§ 22. Dokumenty powiązane

| Dokument | Adres | |----------|-------| | Regulamin | https://www.mybreederline.pl/regulamin/ | | Umowa powierzenia przetwarzania danych (CRM) | https://www.mybreederline.pl/umowa-powierzenia/ | | Wycofanie zgody (waitlist) | https://www.mybreederline.pl/wycofaj-zgode/ | | Aplikacja | https://app.mybreederline.pl |

MyBreederLine — ochrona danych hodowcy i jego klientów.