W poniedziałek 3 sierpnia 2026 roku o godzinie 22.20 biuro prasowe Żabka Polska wysłało redakcji Niebezpiecznika odpowiedź na cztery pytania. Osiem minut później, o 22.28, tekst poszedł na stronę. Między jednym a drugim zdarzeniem mieści się cała nowoczesna sztuka reagowania na incydent: firma potwierdza, ale w zakresie węższym niż zarzuca atakujący, a czytelnik dostaje dwie wersje jednego zdarzenia i musi sam zdecydować, w którą wierzy.

Wersja Żabki brzmi tak: pod koniec poprzedniego tygodnia wykryto nieautoryzowany dostęp do wybranych zasobów technicznych wspierających wymianę informacji między franczyzodawcą a franczyzobiorcami. Dostęp uzyskano przy wykorzystaniu konta zewnętrznego dostawcy usług, został wykryty i niezwłocznie zablokowany. Sprawca — zgodnie z obecną wiedzą spółki — dotarł do systemu kolejkowania zgłoszeń. Dane transakcyjne, poufność aplikacji Żappka i działalność operacyjna pozostają nienaruszone. Sprawę przekazano inspektorowi ochrony danych, zgłoszono Prezesowi UODO i organom ścigania, a osoby objęte incydentem są informowane bezpośrednio.

Wersja atakującego, opublikowana na forum przestępczym wraz z ofertą sprzedaży danych za pięć tysięcy euro, jest o kilka rzędów wielkości szersza. Mowa w niej o 541 tysiącach zgłoszeń z Jiry z 48 projektów, 229 734 ticketach działów IT i service desku, kodzie źródłowym z 89 repozytoriów Git liczącym blisko dwanaście tysięcy plików, a także — i to jest fragment, który powinien odebrać sen każdemu, kto zarządza infrastrukturą — o produkcyjnych danych dostępowych: tokenie GitLab użytym ponownie we wszystkich 89 repozytoriach, hasłach do systemów kolejkowych, poświadczeniach brokera Solace, hasłach administratora MongoDB i tokenach zaszytych w plikach .env. Do tego mapa środowiska Azure/AKS z szesnastoma produkcyjnymi klastrami baz danych i wzorcami dostępu SSH do serwerów w poszczególnych sklepach.

Nie wiemy, która wersja jest bliższa prawdy, i uczciwie trzeba to powiedzieć na wstępie. Wiemy natomiast, że sama konstrukcja tego incydentu — wejście przez konto podmiotu trzeciego, przystanek w systemie zgłoszeń, wyjście z materiałem, który dotyka jednocześnie franczyzodawcy, jedenastu tysięcy franczyzobiorców i pięciu firm partnerskich — jest dokładnie tym scenariuszem, przed którym od trzech lat ostrzegają autorzy dyrektywy NIS-2. I jest scenariuszem, który da się odtworzyć w firmie stukrotnie mniejszej od Żabki.

Chronologia, którą warto rozłożyć na czynniki

Zdarzenia ułożyły się w sekwencję, która sama w sobie jest lekcją. Z próbek opublikowanych przez atakującego wynika, że dysponował on dostępem do infrastruktury co najmniej do 29 lipca. Żabka wykryła nieuprawniony dostęp pod koniec tego samego tygodnia. W niedzielę 2 sierpnia rano do skrzynek Niebezpiecznika i kilku zagranicznych redakcji trafiła enigmatyczna wiadomość sugerująca problem bezpieczeństwa, bez żadnych szczegółów. Kilka godzin później na forum przestępczym pojawiło się ogłoszenie z próbką danych. Równolegle atakujący rozesłał wiadomości bezpośrednio na skrzynki pracowników podwykonawców Żabki, informując ich, że ich dane wyciekły.

Ten ostatni ruch jest istotny i rzadko opisywany. Sprawca nie ograniczył się do rynku — zaczął sam pełnić funkcję, która z mocy art. 34 RODO należy do administratora, czyli zawiadamiać osoby, których dane dotyczą. Zrobił to szybciej niż ktokolwiek inny i w formie, której nikt nie kontrolował. Dla zespołu reagowania oznacza to sytuację, w której zegar komunikacyjny rusza nie w momencie decyzji o zawiadomieniu, tylko w momencie, gdy pierwszy pracownik podwykonawcy przekazuje maila swojemu przełożonemu.

W tle działy się dwie inne rzeczy. W ten sam weekend w sklepach sieci pojawiła się awaria mechanizmu rabatowego — losowe produkty schodziły z absurdalnymi zniżkami, część ajentów zamknęła sklepy do czasu naprawy. Żabka zaprzeczyła, by miało to związek z atakiem, wskazując na błąd wewnętrznej konfiguracji mechanizmu promocyjnego. Kilka dni wcześniej Alimentation Couche-Tard, właściciel sieci Circle K, ogłosił zamiar wezwania na sto procent akcji Grupy Żabka po 32 złote za sztukę, co wycenia spółkę na blisko 32,6 miliarda złotych. Niebezpiecznik odnotował, że śmiesznie niska cena wywoławcza za dane i świeże konto na forum sugerują, iż zarobek nie był tu głównym motywem — ale jednocześnie sam zauważył, że atakujący był w infrastrukturze, zanim informacja o transakcji stała się publiczna.

Konto zewnętrznego dostawcy, czyli wektor numer jeden

Zdanie z komunikatu Żabki — „do nieautoryzowanego dostępu doszło przy wykorzystaniu konta zewnętrznego dostawcy usług" — jest w tej sprawie najważniejsze i zarazem najbardziej uniwersalne. Nie ma w nim żadnej egzotyki. Nie ma podatności zero-day, nie ma zaawansowanej grupy państwowej, nie ma niczego, czego nie dałoby się powtórzyć w spółce komunalnej, kancelarii czy przychodni.

Konto dostawcy to w większości organizacji byt osobliwy. Zakłada się je szybko, bo trwa wdrożenie i „chłopaki z integratora muszą mieć dostęp na wczoraj". Uprawnienia nadaje się z zapasem, bo nikt nie chce wracać do tematu za tydzień. Nazwa bywa funkcyjna, nie osobowa, więc nie wiadomo, kto konkretnie z niej korzysta. Nie obejmuje jej firmowy proces offboardingu, bo ten dotyczy pracowników, a nie kontrahentów. Uwierzytelnianie wieloskładnikowe albo jest wyłączone „bo integracja tego nie obsługuje", albo działa na współdzielonym tokenie. I wreszcie — kiedy projekt się kończy, konto zostaje, bo gdyby jednak trzeba było coś poprawić.

RODO opisuje tę relację w art. 28. Podmiot przetwarzający ma dawać wystarczające gwarancje wdrożenia odpowiednich środków technicznych i organizacyjnych, a umowa powierzenia musi określać przedmiot, czas, charakter i cel przetwarzania oraz obowiązki procesora, w tym pomoc administratorowi w wywiązywaniu się z obowiązków z art. 32–36 i poddanie się audytom. To wszystko jest w umowach. Problem polega na tym, że umowa nie wyłącza konta, nie wymusza MFA i nie zauważa, że token wystawiony na trzy tygodnie działa od czternastu miesięcy. Pisaliśmy o tym przy okazji kary dla DPD Polska — łańcuch podwykonawców to nie jest zagadnienie prawne, tylko operacyjne, a papier nie jest zabezpieczeniem.

Dyrektywa NIS-2 i polska ustawa o krajowym systemie cyberbezpieczeństwa idą krok dalej i traktują bezpieczeństwo łańcucha dostaw jako samodzielny obowiązek podmiotu, a nie dodatek do umowy. Podmiot ma uwzględniać podatności każdego bezpośredniego dostawcy, jakość jego praktyk w zakresie cyberbezpieczeństwa oraz stosowane przez niego bezpieczne praktyki rozwoju oprogramowania. Innymi słowy: ryzyko dostawcy jest twoim ryzykiem i twoim obowiązkiem sprawozdawczym.

Jira nie jest systemem zgłoszeń. Jest magazynem sekretów

Gdyby z tego incydentu miała zostać jedna rzecz do zapamiętania, byłaby to ona. System kolejkowania zgłoszeń — Jira, service desk, helpdesk, dowolny tracker — w większości organizacji pełni rolę, której nikt mu formalnie nie przypisał: jest nieformalnym repozytorium poświadczeń, konfiguracji i danych testowych.

Mechanizm jest banalny. Deweloper zgłasza błąd i żeby zespół mógł go odtworzyć, wkleja przykładowe żądanie z nagłówkiem autoryzacji. Administrator opisuje procedurę i dla wygody wstawia fragment pliku konfiguracyjnego. Analityk załącza zrzut z produkcji, bo „na danych syntetycznych to się nie powtarza". Konto testowe dostaje realny identyfikator sklepu, bo inaczej integracja nie przejdzie. Każdy z tych ruchów z osobna jest racjonalny. Razem tworzą archiwum, które po latach zawiera wszystko, czego atakujący potrzebuje, żeby z systemu o niskiej krytyczności przejść do systemów o krytyczności najwyższej.

Niebezpiecznik postawił dokładnie taką hipotezę: atakujący prawdopodobnie wykorzystał umieszczone w Jirze tokeny, hasła i konta testowe, żeby dostać się do kolejnych systemów. Jeśli tak było, to zdanie „sprawca uzyskał dostęp do systemu kolejkowania zgłoszeń" jest jednocześnie prawdziwe i mylące — prawdziwe co do punktu wejścia, mylące co do zasięgu.

Wnioski są proste do sformułowania i trudne do wdrożenia, bo dotyczą nawyków, a nie technologii. Po pierwsze: skanowanie sekretów nie może kończyć się na repozytoriach kodu, musi obejmować trackery, wiki i komunikatory. Po drugie: retencja zgłoszeń to nie jest kwestia miejsca na dysku, tylko powierzchni ataku — 541 tysięcy ticketów oznacza pół miliona okazji, żeby ktoś kiedyś coś wkleił. Po trzecie: dane testowe powinny być danymi testowymi, a nie kopią produkcji, co jest tą samą lekcją, którą Fortum i Pika zapłacili karą utrzymaną przez sąd. Norma ISO/IEC 27001:2022 nazywa te wymagania po imieniu w załączniku A — zabezpieczenie A.5.17 dotyczy informacji uwierzytelniających, A.8.4 dostępu do kodu źródłowego, A.8.9 zarządzania konfiguracją, a A.8.33 ochrony danych testowych.

Jeden token do osiemdziesięciu dziewięciu repozytoriów

Wśród danych, którymi chwali się atakujący, jest pozycja opisana jako „GitLab Personal Access Token (reused across all 89 repositories)". To jedna linijka, a w niej mieści się osobna historia o zarządzaniu kluczami.

Token osobisty użyty ponownie we wszystkich repozytoriach jest wygodny dokładnie do momentu, w którym trzeba go unieważnić. Wtedy okazuje się, że wisi w kilkudziesięciu potokach CI/CD, w kilku narzędziach wewnętrznych, w konfiguracji ArgoCD, w skryptach, o których pamiętał tylko człowiek, który odszedł. Rotacja takiego poświadczenia nie jest zadaniem na godzinę — jest projektem na tygodnie, prowadzonym pod presją, w czasie gdy równolegle trwa analiza powłamaniowa i korespondencja z organem nadzorczym.

I tu dochodzimy do rzeczy, która w rozmowach z zarządami przechodzi najtrudniej. Realny koszt tego typu incydentu rzadko sprowadza się do kary administracyjnej. Składa się na niego rotacja wszystkich poświadczeń, które mogły zostać ujawnione, przegląd całego kodu pod kątem tego, co jeszcze w nim zaszyto, weryfikacja szesnastu klastrów baz danych, przebudowa wzorców dostępu do serwerów sklepowych, a na końcu odpowiedź na pytanie, którego nikt nie chce usłyszeć: skoro nie wiemy dokładnie, kiedy wszedł, to skąd wiemy, że wyszedł. Ujawnienie kodu źródłowego ma jeszcze jedną właściwość — działa z opóźnieniem. Atakujący, który ma kod, ma czas na spokojne szukanie błędów, których nie znalazł żaden pentest, i może wrócić za pół roku.

Szew franczyzowy, czyli jedenaście tysięcy administratorów

Żabka nazwała zaatakowane zasoby „wspierającymi wymianę informacji między franczyzodawcą a franczyzobiorcami". To sformułowanie warto potraktować poważnie, bo opisuje strukturę, o której w kontekście cyberbezpieczeństwa mówi się w Polsce zbyt rzadko.

Grupa Żabka podaje, że na koniec czerwca 2026 roku miała 13 063 sklepy, a sieć prowadzi ponad jedenaście tysięcy franczyzobiorców. Każdy z nich jest odrębnym przedsiębiorcą. Każdy zatrudnia ludzi albo współpracuje z nimi na innej podstawie. Każdy — w odniesieniu do danych osobowych swoich pracowników — jest samodzielnym administratorem w rozumieniu art. 4 pkt 7 RODO, z własnym obowiązkiem z art. 33 i art. 34, własną odpowiedzialnością i własnym, zwykle nieistniejącym, rejestrem naruszeń.

Kiedy pęka platforma wspólna dla całej sieci, obowiązek zawiadomienia nie ma jednego adresata. Ma ich tysiące, przy czym większość dowiaduje się o zdarzeniu z portalu albo z maila od atakującego, a nie z komunikatu, który zna zakres. Praktyczne pytania, na które umowa franczyzowa musi odpowiadać wcześniej niż w dniu incydentu, brzmią: kto i w jakim czasie zawiadamia franczyzobiorcę, w jakim zakresie franczyzodawca występuje jako podmiot przetwarzający, a w jakim jako odrębny administrator, kto sporządza analizę ryzyka naruszenia praw i wolności, kto ponosi koszty zawiadomienia osób i kto odpowiada za komunikat, jeżeli okaże się on nieprecyzyjny.

Ta sama logika obowiązuje poza franczyzą. Każde biuro rachunkowe obsługujące dwustu klientów, każdy dostawca systemu dziedzinowego dla czterdziestu gmin, każdy operator platformy rezerwacyjnej dla dwóch tysięcy hoteli jest takim samym szwem — punktem, w którym jedno zdarzenie techniczne zamienia się w setki niezależnych postępowań. Opisywaliśmy dokładnie ten mechanizm przy wycieku z systemu Hotres i wniosek był identyczny: obiekt, który sam nie został zaatakowany, i tak musiał wykonać własną ocenę i własne zgłoszenie.

Dwa zegary, które ruszają w tej samej minucie

Organizacja objęta zarówno RODO, jak i ustawą o krajowym systemie cyberbezpieczeństwa, ma po incydencie dwa niezależne kalendarze i dwa różne organy.

Zegar pierwszy to art. 33 RODO: zgłoszenie naruszenia Prezesowi UODO bez zbędnej zwłoki, nie później niż w 72 godziny od stwierdzenia, chyba że jest mało prawdopodobne, by naruszenie skutkowało ryzykiem dla praw i wolności osób. Jeżeli ryzyko jest wysokie, dochodzi obowiązek z art. 34 — zawiadomienie osób, których dane dotyczą, językiem jasnym i zrozumiałym. Niezależnie od tego art. 33 ust. 5 nakazuje dokumentować każde naruszenie, także to niezgłoszone, wraz z uzasadnieniem decyzji. Warto przypomnieć utrwaloną już linię: samo uzyskanie dostępu do danych przez osobę nieuprawnioną jest naruszeniem w rozumieniu art. 4 pkt 12, a brak dowodu, że dane faktycznie pobrano, nie jest argumentem uchylającym obowiązek.

Zegar drugi to reżim NIS-2 przeniesiony do polskiej ustawy: wczesne ostrzeżenie do właściwego zespołu CSIRT w ciągu 24 godzin od stwierdzenia poważnego incydentu, pełne zgłoszenie w ciągu 72 godzin wraz ze wstępną oceną i wskaźnikami naruszenia integralności, a następnie sprawozdanie końcowe w ciągu miesiąca. To osobna ścieżka, osobny formularz i osobna odpowiedzialność, a jej celem nie jest ochrona danych osobowych, tylko odporność usługi.

Oba zegary ruszają w tej samej minucie i oba wymagają, żeby ktoś w organizacji wiedział, że w ogóle istnieją. W praktyce to najczęstsza luka, jaką widzimy w audytach: firma ma procedurę zgłoszenia do UODO, bo RODO obowiązuje od ośmiu lat, i nie ma żadnej procedury zgłoszenia do CSIRT, bo obowiązek jest świeży.

Handel i żywność w wykazie KSC. Zostało sześćdziesiąt dni

Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa weszła w życie 3 kwietnia 2026 roku i rozszerzyła katalog sektorów o obszary, których poprzednia wersja przepisów nie obejmowała — w tym o produkcję, przetwarzanie i dystrybucję żywności, zarządzanie usługami ICT, gospodarowanie odpadami, produkcję maszyn i urządzeń czy usługi pocztowe. Sektory z załącznika drugiego dają co do zasady status podmiotu ważnego, z maksymalną karą do 7 milionów euro albo 1,4 procent rocznego obrotu światowego, przy czym zakres obowiązków w zakresie zarządzania ryzykiem jest ten sam co dla podmiotów kluczowych.

Samorejestracja w wykazie podmiotów kluczowych i ważnych ruszyła 7 maja 2026 roku i kończy się 3 października 2026 roku. Od publikacji tego tekstu zostało sześćdziesiąt dni. Państwo nie wysyła indywidualnych zawiadomień — obowiązek samodzielnej oceny spoczywa na podmiocie, a próg wielkościowy zaczyna się od średniego przedsiębiorcy, czyli od pięćdziesięciu pracowników albo dziesięciu milionów euro obrotu bądź sumy bilansowej.

Dla sieci handlowej o skali Żabki kwalifikacja jest oczywista. Znacznie ciekawsze jest pytanie o resztę łańcucha: producenci żywności dostarczający do sieci, operatorzy logistyki, dostawcy systemów kasowych i magazynowych, firmy utrzymujące infrastrukturę. Część z nich mieści się w katalogu samodzielnie. Reszta — nawet jeśli formalnie nie podlega ustawie — i tak dostanie wymagania bezpieczeństwa w umowie, bo podmiot objęty regulacją musi zarządzać ryzykiem swoich dostawców. To jest ten moment, w którym NIS-2 przestaje być problemem dużych firm i staje się warunkiem utrzymania kontraktu przez małe.

Jak komunikować incydent, którego zakresu się jeszcze nie zna

Komunikat Żabki jest pod względem formalnym poprawny: potwierdza zdarzenie, wskazuje wektor, wymienia podjęte kroki, nazywa organy, do których sprawę zgłoszono. A jednak zawiera konstrukcję, która w tego typu sprawach niemal zawsze wraca rykoszetem — zastrzeżenie „zgodnie z naszą obecną wiedzą" połączone z jednoznacznym zapewnieniem, że dane transakcyjne i aplikacja Żappka pozostają nienaruszone.

Problem z takim zestawieniem polega na tym, że opinia publiczna zapamiętuje część zapewniającą, a nie część warunkową. Jeżeli analiza powłamaniowa poszerzy obraz — a przy dostępie do kodu i poświadczeń poszerza go niemal zawsze — każde kolejne sprostowanie będzie odczytywane jako wycofywanie się z wcześniejszych słów, nawet jeśli pierwsza wypowiedź była w chwili jej formułowania w pełni uczciwa.

Reguła, którą stosujemy w playbookach komunikacyjnych, jest prosta i niewygodna: w pierwszej wypowiedzi opisuje się to, co się wie, i wprost nazywa to, czego się jeszcze nie wie, nie zawężając zakresu na zapas. Zdanie „nie potwierdziliśmy dostępu do systemów X i Y i weryfikujemy to" jest komunikacyjnie słabsze niż „systemy X i Y pozostają nienaruszone", ale ma tę przewagę, że nie trzeba go później odwoływać. Ta sama lekcja wyszła przy wycieku z Hotresu, gdzie komunikat sugerujący klientom domniemanie, że problem ich nie dotyczy, skomplikował sytuację wszystkim obiektom korzystającym z systemu.

Drugi element to szybkość względem atakującego. W tej sprawie sprawca zawiadamiał podwykonawców własnym kanałem, zanim zrobił to ktokolwiek inny. Organizacja, która nie ma gotowej listy kontaktów do partnerów i franczyzobiorców oraz wzoru komunikatu do uzupełnienia, przegrywa ten wyścig o kilkanaście godzin — a te kilkanaście godzin decyduje o tym, czyja narracja stanie się wersją domyślną.

Cyberbezpieczeństwo jako pozycja w due diligence

Zbieżność dat — ogłoszenie zamiaru wezwania na sto procent akcji i ujawnienie incydentu kilka dni później — sama w sobie niczego nie dowodzi i nie ma powodu, by budować na niej teorie. Niebezpiecznik uczciwie odnotował obie możliwości, wskazując zarazem, że atakujący był w infrastrukturze, zanim informacja o transakcji stała się publiczna.

Warto natomiast wyciągnąć z tego wniosek ogólny, bo dotyczy on każdej firmy przygotowującej się do sprzedaży, pozyskania inwestora albo dużego przetargu. Stan cyberbezpieczeństwa przestał być pozycją techniczną i stał się pozycją wyceny. Kupujący pyta dziś o zarejestrowane incydenty z ostatnich trzech lat, o wyniki testów penetracyjnych, o certyfikaty i zakres deklaracji stosowania, o zależności od kluczowych dostawców i o to, ile kosztowałaby rotacja poświadczeń, gdyby doszło do ujawnienia repozytoriów. Odpowiedź „nie mieliśmy incydentów" bywa gorsza od opisu incydentu obsłużonego prawidłowo, bo brzmi jak deklaracja braku monitoringu, a nie braku zdarzeń.

Podobnie działa to w drugą stronę. Podmiot objęty NIS-2 pytający dostawcę o jego praktyki bezpieczeństwa nie robi tego z nadgorliwości — realizuje własny obowiązek ustawowy. Dostawca, który potrafi odpowiedzieć konkretem, wygrywa. Dostawca, który przysyła oświadczenie o dbałości o najwyższe standardy, zostaje poproszony o dowody i najczęściej ich nie ma.

Dlaczego z Fib.Code przy incydentach i łańcuchu dostaw

Zajmujemy się bezpieczeństwem informacji od strony, w której spotykają się trzy porządki: prawny, techniczny i organizacyjny. Prowadzimy funkcję inspektora ochrony danych i pełnomocnika do spraw bezpieczeństwa informacji, wdrażamy i audytujemy systemy zarządzania zgodne z ISO/IEC 27001 oraz ISO 22301, przygotowujemy podmioty do obowiązków z ustawy o krajowym systemie cyberbezpieczeństwa i prowadzimy je przez zgłoszenia do UODO i CSIRT, gdy coś się już wydarzy.

Pracujemy według trzech zasad. Pierwsza: zakres wynika z analizy ryzyka, nie z katalogu produktów — dopóki nie wiadomo, które aktywa i które zależności są krytyczne, każdy zakup jest zgadywaniem. Druga: dowód jest ważniejszy od dokumentu — protokół z testu odtworzenia kopii, zrzut z przeglądu uprawnień i lista kont dostawców z datą ostatniego użycia znaczą więcej niż polityka podpisana i odłożona do segregatora. Trzecia: procedura, której nikt nie przećwiczył, nie jest procedurą, tylko intencją.

Efektem współpracy jest komplet, który da się położyć na stole przed kontrolerem, biegłym rewidentem i kupującym: rejestr aktywów i dostawców z przypisanym ryzykiem, deklaracja stosowania, playbook incydentu z dwiema ścieżkami zgłoszeniowymi i wzorami komunikatów, plan ciągłości działania z przetestowanymi czasami odtworzenia oraz harmonogram przeglądów, który utrzymuje to wszystko przy życiu po zakończeniu projektu.

Co zrobić w ten tydzień: przegląd kont dostawców

Zwołaj jedno spotkanie na czterdzieści pięć minut, z udziałem osoby odpowiedzialnej za IT, inspektora ochrony danych i kogoś z zarządu, i przejdź przez siedem pytań, notując przy każdym imię i termin.

Po pierwsze: ile mamy aktywnych kont należących do podmiotów zewnętrznych, kto konkretnie z nich korzysta i kiedy każde z nich było ostatnio użyte. Po drugie: które z nich działają bez uwierzytelniania wieloskładnikowego i co stoi na przeszkodzie, żeby to zmienić do końca miesiąca. Po trzecie: czy ktoś kiedykolwiek przeszukał naszą Jirę, wiki i archiwum service desku pod kątem haseł, tokenów i danych produkcyjnych — a jeśli nie, kto to zrobi i do kiedy.

Po czwarte: gdzie leży lista poświadczeń używanych w potokach CI/CD i ile godzin zajęłaby ich rotacja, gdybyśmy musieli wykonać ją dziś. Po piąte: czy wiemy, do którego zespołu CSIRT zgłaszamy incydent, kto ma do tego dostęp i czy ta osoba ma zastępcę na urlopie. Po szóste: czy złożyliśmy wniosek o wpis do wykazu podmiotów kluczowych i ważnych, a jeśli uznaliśmy, że nas nie dotyczy, to gdzie jest zapisane uzasadnienie tej oceny. Po siódme: czy nasze umowy z kluczowymi dostawcami i partnerami określają termin i formę zawiadomienia nas o incydencie po ich stronie.

Jeżeli przy którymkolwiek pytaniu w sali zapada cisza, masz właśnie odpowiedź na to, od czego zacząć. Termin 3 października 2026 roku jest sztywny, a przegląd kont dostawców to jedyne działanie z tej listy, które nie wymaga budżetu — wystarczy decyzja i dwie godziny czyjegoś czasu.

Zapraszamy do kontaktu: l.grabowski@fibcode.com | fibcode.com/pl/kontakt. Bezpośrednio powiązane materiały: wyciek z systemu Hotres i granica między administratorem a procesorem, kara UODO dla DPD Polska i łańcuch podwykonawców w art. 28 RODO, samoidentyfikacja i wpis do wykazu podmiotów kluczowych i ważnych — trzy różne ujęcia tego samego problemu: cudze konto, cudzy system i twoja odpowiedzialność.