1. O dokumencie
Niniejsza procedura opisuje sposób reagowania Blisko na naruszenia ochrony danych osobowych w rozumieniu Art. 33 i 34 RODO. Opisuje co liczy się jako naruszenie, w jakim czasie powiadamiamy Prezesa UODO, kiedy i jak powiadamiamy użytkowników, oraz kogo kontaktować w razie wykrycia incydentu.
Administratorem danych jest Karol Wypchło, prowadzący aplikację Blisko. Kontakt w sprawie ochrony danych: [email protected].
2. Co liczy się jako naruszenie ochrony danych
Zgodnie z Art. 4(12) RODO naruszeniem jest każde zdarzenie prowadzące do przypadkowego lub bezprawnego zniszczenia, utraty, modyfikacji, nieuprawnionego ujawnienia lub nieuprawnionego dostępu do danych osobowych. Konkretne scenariusze, które traktujemy jako naruszenie:
- Wyciek z bazy danych (np. SQL injection, publicznie dostępna kopia zapasowa, źle skonfigurowany bucket)
- Nieuprawniony dostęp do konta administratora lub panelu admin
- Przypadkowa ekspozycja danych (np. logi z danymi osobowymi udostępnione publicznie, przeciek pliku .env)
- Utrata lub kradzież urządzenia z dostępem do danych produkcyjnych (laptop, klucze dostępowe)
- Atak ransomware lub malware niszczący lub zmieniający dane
- Naruszenie po stronie procesora (OpenAI, Railway, Resend, Tigris), które dotyczy naszych użytkowników
- Wewnętrzne nadużycie — dostęp do danych bez uzasadnionej potrzeby biznesowej
Nie są naruszeniem, w większości przypadków: pojedyncze nieudane próby logowania, osiągnięcia limitów ratelimitingu, ataki DDoS bez wycieku danych, akcje wykonywane przez samego użytkownika na swoich danych.
3. 72-godzinny zegar
Zegar startuje w momencie, w którym administrator danych dowiedział się o naruszeniu (nie w momencie wystąpienia incydentu). Art. 33(1) RODO wymaga powiadomienia Prezesa UODO bez zbędnej zwłoki, w miarę możliwości nie później niż w ciągu 72 godzin od stwierdzenia naruszenia, chyba że jest mało prawdopodobne, by naruszenie skutkowało ryzykiem dla praw lub wolności osób fizycznych.
4. Klasyfikacja ryzyka
Zakres i rodzaj ujawnionych danych określa wymagane działania powiadamiające.
- Wysokie ryzyko — dane umożliwiające identyfikację, lokalizację lub kontakt z użytkownikiem (imię + email + lokalizacja + treści wiadomości), dane generowane przez AI dotyczące osobowości, dane umożliwiające nękanie lub stalking. Wymaga powiadomienia UODO (Art. 33) oraz użytkowników (Art. 34).
- Średnie ryzyko — ograniczona lista danych (np. sam email bez innych danych, shortlived tokeny, dane częściowo zanonimizowane). Wymaga powiadomienia UODO. Powiadomienie użytkowników nie jest obowiązkowe.
- Niskie lub brak ryzyka — dane były zaszyfrowane lub zabezpieczone, a klucze nie zostały ujawnione; logi z zanonimizowanymi adresami IP; scenariusz gdzie atakujący nie mógł odczytać danych. Brak obowiązku powiadomień, ale incydent musi być udokumentowany wewnętrznie.
5. Checklist fazowy
Faza 0 — detekcja i natychmiastowa reakcja (godzina 0)
- Zweryfikuj czy to rzeczywiście naruszenie — sprawdź logi, odtwórz jeśli to bezpieczne
- Contain — rotacja skompromitowanych poświadczeń w Railway (klucze API, sekrety OAuth, hasło bazy jeśli konieczne), unieważnienie aktywnych sesji, zablokowanie adresów IP atakującego
- Zabezpieczenie dowodów — zrzut bazy danych, logi Railway, logi metryk z odpowiedniego okna czasowego
- Uruchomienie timera 72h (notatka w prywatnym dokumencie Linear)
Faza 1 — triage (0–24h)
- Zakres — których użytkowników dotyczy, jakie kategorie danych, ile rekordów, jak długo dane były wystawione
- Klasyfikacja ryzyka (sekcja 4) — wysokie / średnie / niskie
- Udokumentowanie faktów: co się stało, kiedy wykryte, zakres, hipoteza przyczyny źródłowej, podjęte działania containment
- Ocena czy Art. 34 (powiadomienie użytkowników) jest wymagane
Faza 2 — powiadomienie UODO (24–72h)
Zgłoszenie przez formularz online: https://uodo.gov.pl/pl/p/naruszenia. Wymagane elementy zgłoszenia (Art. 33(3) RODO):
- Charakter naruszenia — kategorie i przybliżona liczba osób i rekordów
- Dane kontaktowe punktu kontaktowego (Karol Wypchło, [email protected])
- Prawdopodobne konsekwencje naruszenia
- Zastosowane lub proponowane środki zaradcze
Numer sprawy i potwierdzenie zgłoszenia zachowujemy w dokumentacji incydentu.
Faza 3 — powiadomienie użytkowników (Art. 34, jeśli wysokie ryzyko)
- Wysyłka emaila przez Resend z adresu [email protected] do osób, których dotyczy naruszenie
- Treść zgodna z Art. 34(2): opis charakteru naruszenia, prawdopodobne konsekwencje, zastosowane środki zaradcze, zalecenia dla użytkownika (np. zmiana hasła w innych serwisach jeśli reużywał, czujność na phishing)
- Gdy indywidualne powiadomienie jest niewspółmierne (duża liczba osób) — zamiast tego komunikat publiczny na blisko.app oraz w aplikacji, zgodnie z Art. 34(3)(c)
Faza 4 — post-incident
- Pełen post-mortem: timeline, przyczyna źródłowa, remediacja, środki prewencyjne
- Aktualizacja niniejszej procedury jeśli incydent ujawnił luki
- Aktualizacja polityki prywatności, jeśli zaangażowany był nowy procesor lub nowa kategoria danych
6. Dokumentacja incydentu
Niezależnie od oceny ryzyka każdy incydent jest dokumentowany wewnętrznie: data i godzina wykrycia, opis zdarzenia, zakres, podjęte działania, klasyfikacja ryzyka, decyzja o powiadomieniach i uzasadnienie, numer sprawy UODO jeśli zgłoszono. Dokumentacja jest przechowywana na wypadek audytu zgodnie z zasadą rozliczalności (Art. 5(2) RODO).
7. Kontakty
Administrator danych
Organ nadzorczy
Procesorzy (eskalacja w razie incydentu po ich stronie)
8. Zgłaszanie incydentu przez użytkownika lub badacza
Jeśli zauważyłeś lukę bezpieczeństwa lub podejrzenie naruszenia danych, skontaktuj się z nami na [email protected]. Potwierdzimy otrzymanie zgłoszenia w ciągu 24 godzin i rozpoczniemy weryfikację zgodnie z Fazą 0 powyżej.
9. Przegląd procedury
Procedura jest weryfikowana i aktualizowana przy każdej zmianie procesorów danych, dodaniu nowej kategorii wrażliwych danych, oraz przy corocznym przeglądzie polityki prywatności. Data ostatniej aktualizacji jest widoczna na górze dokumentu.