Gdy słyszysz o cyberataku na globalną markę czy dystrybutora IT, łatwo pomyśleć: „to nie nasz świat, jesteśmy tylko MŚP w Polsce”. Problem w tym, że Twoja firma stoi na dokładnie tych samych klockach technologicznych: tych samych chmurach, integracjach, dostawcach oprogramowania. Jeden incydent „gdzieś daleko” może w praktyce oznaczać tydzień przestoju, brak faktur, opóźnione dostawy i nerwowe telefony od klientów. Ten tekst pokazuje, jak zarząd może przełożyć głośne cyberataki na bardzo konkretne pytania do IT i dostawców.
W ostatnich tygodniach pojawiło się kilka głośnych incydentów bezpieczeństwa, które na pierwszy rzut oka dotyczą „wielkich graczy” – globalnych marek, dystrybutorów IT, producentów oprogramowania. Pod koniec 2025 roku potwierdzono m.in. duży wyciek danych klientów Under Armour po ataku ransomware, w którym ujawniono dane dziesiątek milionów kont, w tym szczegółowe informacje o zakupach i lokalizacjach klientów. W 2025 roku gigant dystrybucji IT Ingram Micro został sparaliżowany atakiem ransomware, który zatrzymał logistykę na około tydzień, a dziś wiadomo, że dodatkowo wyciekły dane ponad 42 tys. osób (pracowników i kandydatów do pracy). Równolegle ujawniono krytyczną podatność w HPE OneView, oprogramowaniu zarządzającym infrastrukturą serwerową, ocenioną na maksymalne 10/10 w skali krytyczności i szybko wykorzystywaną przez złośliwe oprogramowanie do masowych ataków na środowiska serwerowe. Do tego doszedł przykład z WordPressa: luka w popularnej wtyczce Advanced Custom Fields: Extended, umożliwiająca przejęcie kontroli nad stroną internetową nawet kilkudziesięciu tysiący serwisów jednocześnie.
Na papierze to „nie nasze problemy”: Under Armour nie jest polskim MŚP, Ingram Micro nie jest lokalnym software house’em, a HPE OneView może w ogóle nie występować w Twoim środowisku. Z perspektywy zarządu polskiej firmy ważniejsze jest jednak co innego: wszystkie te wydarzenia pokazują, jak bardzo biznes zależy od łańcucha dostaw IT oraz od decyzji, które podejmują nasi dostawcy technologii. I jak szybko incydent „gdzieś w świecie” może zamienić się w realny przestój w Polsce.
Gdzie naprawdę „stoi” Twoja firma: mapa zależności IT dla zarządu
W typowym MŚP w Polsce technologia nie wygląda już jak kilka komputerów i serwer pod biurkiem. Nawet prosta firma usługowa czy handlowa opiera się dziś na warstwach, które razem tworzą łańcuch zależności: lokalne urządzenia (komputery, drukarki, terminale, routery, przełączniki, rejestratory monitoringu), systemy biznesowe (system finansowo–księgowy, ERP, CRM, e-commerce, systemy magazynowe), usługi chmurowe (poczta, Microsoft 365, dyski współdzielone, systemy ticketowe), a do tego szereg zewnętrznych partnerów (od firm kurierskich i operatorów płatności po software house’y, integratorów i dostawców infrastruktury).
Zarząd widzi głównie nazwy systemów na fakturach: „Microsoft 365”, „system magazynowy X”, „platforma sprzedażowa Y”, „obsługa IT”, „hosting strony www”. Techniczny szczegół taki jak to, że np. sklep stoi na WordPressie z określonymi wtyczkami, logistyka opiera się na integracjach z API dostawców, a serwerownia w magazynie jest zarządzana przez konkretne narzędzia, zwykle nie jest w ogóle znany na poziomie zarządczym. Dopóki wszystko działa, nie ma takiej potrzeby. Problem pojawia się wtedy, gdy jeden element tego łańcucha zostaje zaatakowany lub popełnia błąd konfiguracyjny – a każda kolejna warstwa „nad nim” przestaje mieć znaczenie, bo proces po prostu staje.
Atak na Under Armour pokazuje, jak bolesne potrafią być skutki wycieku danych klientów: szczegółowe profile zakupowe, lokalizacje, dane kontaktowe, pozwalające na precyzyjne kampanie phishingowe i podszywanie się pod markę. Atak na Ingram Micro pokazał z kolei, co dzieje się, gdy w globalnym łańcuchu IT „wysiądzie” dystrybutor. Przez tydzień paraliżu logistyki jego klienci na całym świecie mieli realne problemy z dostępnością sprzętu, a dziś mierzą się z konsekwencjami wycieku danych osobowych. Z perspektywy zarządu MŚP najważniejsza lekcja jest prosta: Twoja firma stoi na tych samych klockach technologicznych, co duże korporacje. Różni się skala, ale nie zależności.
Trzy powtarzające się wzorce w incydentach IT
Jeśli oderwiemy się od technicznych detali poszczególnych ataków, widać trzy stałe elementy, które powinny zainteresować zarząd, niezależnie od branży.
Po pierwsze, atak bardzo szybko przekłada się na przestój operacyjny. W przypadku Ingram Micro ransomware nie tylko zaszyfrował dane, ale doprowadził do masowej awarii systemów logistycznych i portali obsługi klientów. Strona i panele klienckie były niedostępne, a partnerzy firmy publicznie informowali o problemach z realizacją zamówień. HPE OneView jako oprogramowanie sterujące całymi „farmami” serwerów to przykład, w którym jedna krytyczna luka nie jest tylko „błędem bezpieczeństwa”, ale potencjalnym punktem, gdzie pojedyncze udane włamanie może wyłączyć dużą część środowiska serwerowego. Z perspektywy zarządu nie ma znaczenia, czy problemem jest ransomware, exploit czy błąd człowieka – liczy się to, że kluczowy proces (sprzedaż, logistyka, produkcja, obsługa klienta) przestaje działać.
Po drugie, komunikacja z rynkiem często jest spóźniona albo niepełna. W przypadku Under Armour mocno krytykowano ciszę informacyjną i bardzo oszczędne komunikaty, mimo że dane klientów krążyły już w podziemiu. To nie jest tylko problem wizerunkowy. Dla firm B2C milczenie w obliczu wycieku danych klientów oznacza utratę zaufania. Dla MŚP, które obsługuje klientów biznesowych, oznacza ryzyko utraty kontraktów, jeśli partnerzy uznają, że firma nie radzi sobie z zarządzaniem incydentami. Z poziomu zarządu trzeba patrzeć na incydent nie jak na „wstydliwy problem IT”, ale jak na kryzys reputacyjny i kontraktowy.
Po trzecie, bardzo często rozmyta jest odpowiedzialność za reakcję – zarówno wewnątrz organizacji, jak i między organizacją a dostawcami. W wielu głośnych przypadkach toczy się dyskusja, czy zawinił dostawca chmury, producent oprogramowania, integrator, czy może dział IT klienta, który nie wdrożył poprawek na czas. Dla zarządu taka debata po fakcie ma ograniczoną wartość. W momencie kryzysu potrzebna jest jasna odpowiedź na pytania: kto podejmuje decyzję o odłączeniu systemu od sieci, kto rozmawia z klientami, kto komunikuje się z regulatorem i kto koordynuje działania dostawców.
Pięć pytań, które zarząd MŚP powinien zadać dostawcy IT (i samemu sobie)
Najnowsze incydenty podpowiadają bardzo konkretne pytania, które zarząd może, a nawet powinien, zadać swoim kluczowym dostawcom technologii oraz wewnętrznemu IT. To nie są pytania techniczne, tylko biznesowe.
1. Jakie procesy w naszej firmie staną, jeśli u Was wystąpi poważny incydent IT?
Tu nie chodzi o listę serwerów, ale o mapę procesów: co stanie się z obsługą zamówień, logistyką, fakturowaniem, komunikacją z klientem, jeśli dostawca chmury, ERP, systemu magazynowego czy integracji ma awarię lub atak ransomware. Incydent u dużego dystrybutora pokazał, że „problem wewnętrzny dostawcy” bardzo szybko zamienia się w paraliż po stronie klientów, którzy nie mogą zrealizować podstawowych operacji. Zarząd potrzebuje odpowiedzi w formie scenariuszy: co jest krytyczne, jak długo możemy realnie funkcjonować bez danego systemu, jakie mamy obejścia (np. tryb ręczny, alternatywny kanał, drugi dostawca).
2. W jakim czasie i w jakiej formie informujecie nas o incydencie?
Przypadek Under Armour jest dobrym przykładem, jak kosztowne bywa milczenie. Zarząd powinien oczekiwać od dostawcy IT procedury komunikacji: czy mają progi, przy których informują klientów (awaria vs. wyciek danych), jakie kanały wykorzystują, czy przewidziano kontakt 24/7, czy są gotowe wzory komunikatów dla wspólnych klientów. Dobra odpowiedź nie brzmi „na pewno damy znać”, tylko pokazuje konkretny proces.
3. Jak wygląda Wasz proces zarządzania podatnościami i łatkami (patch management)?
Przykłady krytycznych luk w narzędziach takich jak HPE OneView czy popularnych wtyczkach do WordPressa pokazują, że między publikacją łatki a początkiem masowych ataków mija dziś często zaledwie kilka dni. W tym czasie każda organizacja (i każdy dostawca) musi zdążyć zidentyfikować, czy używa podatnego komponentu, zaplanować wdrożenie poprawki, przetestować ją i wdrożyć na produkcji. Zarząd nie musi znać technicznych nazw podatności, ale powinien wiedzieć: jak szybko dostawca reaguje na krytyczne problemy, czy ma proces priorytetyzacji, czy utrzymuje listę komponentów, które są w użyciu, oraz jak minimalizuje ryzyko przestojów podczas aktualizacji.
4. Jakie dane naszej firmy dokładnie przetwarzacie i gdzie one są przechowywane?
W opisanych incydentach wyciekały nie tylko adresy e-mail, ale też dane osobowe pracowników i klientów, historie transakcji, dane lokalizacyjne. Dla MŚP ważne jest, by wiedzieć, jakiego typu informacje trafiają do poszczególnych dostawców: czy to tylko dane techniczne, czy także dane klientów, kontrahentów, pracowników, dokumenty finansowe, logi i kopie zapasowe. Do tego dochodzi lokalizacja danych: kraj, region, typ środowiska. Nie chodzi o szczegółową mapę infrastruktury, ale o świadomość, jaki jest potencjalny „rozmiar szkody”, jeśli dane zostaną ujawnione.
5. Kto po Waszej (i naszej) stronie odpowiada za reakcję na incydent?
W kryzysie największym wrogiem jest rozmycie odpowiedzialności. Zarząd powinien mieć jasny, prosty schemat:
- po stronie dostawcy: kto jest „właścicielem incydentu”, z kim kontaktuje się firma w trybie pilnym, kto podejmuje decyzje;
- po stronie firmy: kto ma mandat do odłączenia systemu, kogo informuje się w pierwszej kolejności, kto zatwierdza komunikaty do pracowników, klientów i mediów.
Bez tego nawet dobry technicznie plan pozostaje na papierze, a realne działania zaczynają się za późno.
Co zarząd może zrobić wewnątrz firmy – minimum bez rewolucji w IT
Z perspektywy MŚP kluczowe jest urealnienie oczekiwań: nie każda firma potrzebuje pełnoskalowego zespołu bezpieczeństwa czy codziennych raportów z centrum operacji bezpieczeństwa. Są jednak trzy rzeczy, które zarząd może wprowadzić stosunkowo szybko, bez przebudowy całego IT.
Po pierwsze: wyznaczyć właściciela obszaru bezpieczeństwa i ciągłości działania, nawet jeśli to rola współdzielona (np. członek zarządu plus zewnętrzny partner IT). Chodzi o to, by istniała jedna osoba odpowiedzialna za koordynację tematów bezpieczeństwa, kontakt z dostawcami w sprawie incydentów i aktualizacji oraz za spójność polityk wewnętrznych. Brak takiej osoby powoduje, że każdy temat „cyber” ląduje gdzieś pomiędzy finansami, operacjami a IT i ginie wśród innych priorytetów.
Po drugie: zlecić przygotowanie prostej mapy zależności IT, maksymalnie jednej–dwóch stron, które pokazują, na jakich systemach i dostawcach opiera się firma oraz jakie dane są tam przetwarzane. Taka mapa nie jest technicznym diagramem sieci, tylko narzędziem zarządczym. Mapa pozwala szybko zobaczyć, gdzie istnieje pojedynczy punkt awarii, których dostawców warto objąć dodatkową uwagą (np. audytem umów, dodatkowymi pytaniami o procesy bezpieczeństwa), a które systemy są krytyczne dla ciągłości działania. Bez takiej mapy decyzje kryzysowe opierają się na intuicji i pamięci pojedynczych osób.
Po trzecie: uzupełnić najważniejsze umowy z dostawcami o zapisy dotyczące bezpieczeństwa i obsługi incydentów, jeśli ich brakuje lub są zbyt ogólne. Nie chodzi od razu o wielostronicowe aneksy, ale o minimalne elementy: czas reakcji na awarie i incydenty, sposób raportowania, zasady informowania o wyciekach danych, wymagania dotyczące backupu i testów odtwarzania, obowiązek szybkiej informacji o krytycznych podatnościach w używanym oprogramowaniu. Bez zapisów w umowach trudno potem egzekwować cokolwiek poza ogólnym „dołożymy starań”.
To nie jest „problem IT”, tylko zarządcza decyzja o poziomie ryzyka
Wspólne dla wszystkich opisanych incydentów jest to, że zaczynają się w obszarze technicznym, ale kończą jako problem biznesowy. W wycieku danych klientów skutki widać w reputacji marki i zaufaniu klientów. W ataku na globalnego dystrybutora skutki widać w przestojach logistycznych, opóźnieniach i kosztach po stronie tysięcy firm na całym świecie. W przypadku luk w narzędziach zarządzających infrastrukturą czy wtyczkach do systemów takich jak WordPress zagrożenie dotyka wprost firm, które budują na nich swoją stronę www, panel klienta, system sprzedaży.
Zarząd MŚP nie musi śledzić wszystkich szczegółów technicznych ani znać numerów podatności. Powinien natomiast traktować te przypadki jako materiał do rozmowy z własnymi dostawcami IT oraz jako impuls do uporządkowania relacji między biznesem a technologią. Kluczowe pytanie brzmi: na jakim poziomie ryzyka chcemy świadomie funkcjonować i co jesteśmy gotowi zrobić, żeby to ryzyko obniżyć. To punkt wyjścia do rozważań, czy chodzi o lepsze umowy z dostawcami, o jasny podział odpowiedzialności, o prosty, ale realny plan reagowania na incydent, czy o inwestycje w konkretne zabezpieczenia (backup, segmentacja, monitoring).
Decyzja o tym, by świadomie zarządzać łańcuchem dostaw IT i przygotowaniem na incydenty, jest decyzją zarządczą – podobnie jak decyzja o polisach ubezpieczeniowych, strukturze finansowania czy dywersyfikacji kluczowych dostawców. Technologia dostarcza narzędzi, ale kierunek i priorytety wyznacza zarząd.