Czego dowiesz się z tego artykułu?
- Jak ułożyć pierwsze 24 godziny po incydencie, zanim placówka zacznie chaotycznie szukać logów i załączników.
- Co przygotować do zgłoszenia przez portal CSIRT CeZ: osobę kontaktową, opis zdarzenia, zrzuty ekranu i ślady techniczne.
- Jak rozdzielić ransomware, phishing i nieautoryzowane logowanie bez obiecywania pełnej automatyzacji reakcji.
- Jakie metryki po ćwiczeniu pokażą managerowi, czy placówka jest gotowa na realny incydent.
W polskiej przychodni incydent cyberbezpieczeństwa rzadko zaczyna się od wielkiego alarmu. Częściej ktoś z recepcji mówi, że nie działa grafik, lekarz nie może wejść do EDM, a na skrzynce pojawiła się dziwna wiadomość z załącznikiem. Wtedy liczy się nie heroizm, tylko prosty plan pierwszych godzin i osoba, która wie, gdzie zgłosić zdarzenie.
Portal CSIRT CeZ zmienia praktykę o tyle, że placówka nie musi szukać ścieżki zgłoszenia dopiero w stresie. Dla podmiotów kluczowych i ważnych w sektorze ochrony zdrowia wstępne zgłoszenie poważnego incydentu ma ramę 24 godzin, a pełniejsze zgłoszenie można uzupełniać później. To nie jest zaproszenie do zwlekania. To jest sygnał, że pierwszy pakiet informacji musi być gotowy szybko.
To nie jest porada prawna ani instrukcja zastępująca pracę IOD, prawnika lub zespołu IT. Ja bym traktował ten tekst jako operacyjną kartę rozmowy dla właściciela placówki: AI, EDM, grafiki i poczta mogą pomóc wykrywać sygnały, ale decyzję o zgłoszeniu, komunikacji z pacjentami i ciągłości świadczeń zatwierdza człowiek.
Najważniejsze
- Pierwszy krok to nie wybór narzędzia, tylko wyznaczenie osoby kontaktowej do CSIRT CeZ i zapisanie linku do portalu w procedurze placówki.
- W 24 godziny placówka powinna zebrać minimum: czas wykrycia, opis objawów, dotknięte systemy, zrzuty ekranu, dostępne logi, podjęte działania i wpływ na świadczenia.
- Ransomware, phishing i nieautoryzowane logowanie wymagają różnych działań technicznych, ale tego samego porządku zarządczego: właściciel decyzji, log, eskalacja, zgłoszenie.
- AI może porządkować sygnały, streszczać logi lub przygotować roboczy opis, ale nie powinna samodzielnie kwalifikować incydentu ani decydować o komunikacji klinicznej.
- Sukces po ćwiczeniu mierz przez czas od wykrycia do zgłoszenia i kompletność załączników, nie przez deklarację, że „jesteśmy bezpieczni”.
Najpierw właściciel decyzji, potem formularz
Jeżeli placówka nie ma osoby kontaktowej, pierwsze godziny po incydencie zwykle rozchodzą się na telefony: kto ma dostęp do skrzynki, kto zna dostawcę EDM, kto może zatrzymać komputer, kto rozmawia z lekarzami. Formularz CSIRT CeZ jest ważny, ale sam formularz nie rozwiąże braku decyzyjności w środku organizacji.
Właściciel lub manager powinien przed incydentem wskazać minimum trzy role. Pierwsza to osoba kontaktowa do CSIRT CeZ i dostawców technicznych. Druga to właściciel procesu w placówce, na przykład kierownik rejestracji albo manager operacyjny. Trzecia to osoba od danych: IOD, zewnętrzny inspektor albo wyznaczony opiekun RODO. Bez tych ról nawet dobry zespół zaczyna improwizować.
To ma sens, gdy placówka ma zapisany numer telefonu, skrzynkę awaryjną, dostęp do panelu dostawcy i prostą decyzję: kto zgłasza, kto zatwierdza treść i kto koordynuje ciągłość świadczeń. To nie ma sensu, gdy wszyscy zakładają, że „informatyk się tym zajmie”, a informatyk jest zewnętrznym dostawcą, który odbiera telefon dopiero po kilku godzinach.
W szerszym planie bezpieczeństwa warto połączyć ten temat z playbookiem o cyberbezpieczeństwie AI w placówce. Tam mowa o filtrach, sandboxie i whiteliście akcji. Tutaj schodzimy poziom niżej: co robi manager, kiedy coś już wygląda jak incydent.
Plan pierwszych 24 godzin bez paniki
Najgorsza procedura to taka, którą zespół czyta pierwszy raz w dniu awarii. Dobra karta 24 godzin mieści się na jednej stronie i mówi, co robimy równolegle, a nie w idealnej kolejności. Technicy zabezpieczają ślady, manager decyduje o ciągłości obsługi, IOD ocenia dane osobowe, a osoba kontaktowa przygotowuje zgłoszenie.
Poniższy plan nie zakłada, że w pierwszej godzinie wiadomo wszystko. Wprost przeciwnie: na początku zwykle wiadomo za mało. Dlatego trzeba odróżnić wczesne ostrzeżenie od pełnej analizy powłamaniowej. W zgłoszeniu nie chodzi o literacki opis, tylko o dane, które pozwalają CSIRT CeZ zrozumieć zdarzenie i wesprzeć placówkę.
| Moment | Cel managera | Co zebrać | Kto zatwierdza |
|---|---|---|---|
| 0-2 godziny | Zatrzymać rozlewanie się zdarzenia i nazwać właściciela | czas wykrycia, objawy, dotknięte systemy, pierwsze zrzuty ekranu | manager operacyjny i osoba techniczna |
| 2-6 godzin | Ustalić, czy zdarzenie wpływa na usługi i dane | lista systemów, konta użytkowników, komunikaty błędów, kopie logów | właściciel placówki, IOD, dostawca EDM |
| 6-12 godzin | Przygotować wstępne zgłoszenie i załączniki | opis przebiegu, podejrzane maile, domeny, IP, próbki komunikatów bez nadmiaru danych pacjenta | osoba kontaktowa do CSIRT CeZ |
| 12-24 godziny | Wysłać zgłoszenie i ustalić dalsze kroki | numer sprawy, lista braków do uzupełnienia, decyzje o komunikacji wewnętrznej | właściciel lub upoważniony manager |
W praktyce dodałbym jeszcze jedną zasadę: nie wyłączaj wszystkiego odruchowo, jeśli nie wiesz, czy zniszczysz ślady potrzebne do analizy. Przy ransomware może być konieczne odłączenie stacji od sieci, ale przy innych zdarzeniach pochopne działania potrafią utrudnić ustalenie przebiegu. Tu człowiek techniczny i CSIRT są ważniejsi niż automatyczny scenariusz z internetu.
Co zebrać do zgłoszenia, zanim zginą logi
W małej placówce największym problemem nie jest brak narzędzi klasy enterprise. Największym problemem jest to, że ślady są rozproszone: część w poczcie, część u dostawcy EDM, część w routerze, część na komputerze recepcji, a część w głowie pracownika, który pierwszy zobaczył komunikat. Dlatego karta zgłoszenia powinna wymuszać prosty porządek.
Minimum informacji do zebrania:
- dokładny czas wykrycia i, jeśli wiadomo, przybliżony czas rozpoczęcia zdarzenia,
- objaw widoczny dla zespołu: blokada systemu, podejrzana wiadomość, błąd logowania, utrata dostępu,
- systemy dotknięte zdarzeniem: poczta, EDM, grafik, telefonia, strona, formularz, komputer recepcji,
- załączniki: zrzuty ekranu, nagłówki maila, nazwy domen, adresy IP, komunikaty błędów,
- działania już wykonane: odłączenie stanowiska, zmiana haseł, kontakt z dostawcą, przywracanie kopii,
- wpływ na pacjentów i świadczenia: czy działa rejestracja, czy lekarz ma dostęp do dokumentacji, czy są opóźnienia,
- dane osoby kontaktowej, która odbierze odpowiedź i będzie uzupełniała informacje.
Nie wysyłałbym do zgłoszenia całych paczek danych pacjentów, jeśli wystarczy zrzut ekranu z zamazanymi danymi lub opis techniczny. Minimalizacja danych nadal obowiązuje, nawet gdy sytuacja jest pilna. Jeżeli incydent może być naruszeniem ochrony danych osobowych, IOD powinien równolegle ocenić ścieżkę UODO i obowiązek zawiadomienia osób, których dane dotyczą.
AI może pomóc w uporządkowaniu listy zdarzeń albo przygotować robocze streszczenie logów, ale tylko na danych, które wolno wprowadzić do danego narzędzia. Publiczny model nie jest miejscem na logi z danymi pacjentów, screeny EDM ani pełne treści wiadomości z informacjami medycznymi. Human-in-the-loop oznacza tutaj: człowiek decyduje, co wolno przekazać, co trzeba zanonimizować i co zostaje wewnątrz placówki.
Trzy scenariusze, które recepcja rozpozna najszybciej
Recepcja często widzi incydent wcześniej niż manager. To ona odbiera telefon od pacjenta, dostaje dziwny mail, nie może znaleźć terminu albo zauważa komunikat o zablokowanym pliku. Szkolenie zespołu powinno więc mówić językiem objawów, nie językiem specjalistycznych kategorii.
| Sytuacja | Pierwszy sygnał w placówce | Decyzja w pierwszej godzinie | Co dołączyć do zgłoszenia |
|---|---|---|---|
| Ransomware | system lub pliki są zablokowane, pojawia się żądanie okupu | odizolować stanowisko, zabezpieczyć kopie, nie kasować komunikatu | zrzut ekranu, lista systemów, czas wykrycia, stan kopii zapasowej |
| Phishing | mail podszywa się pod pacjenta, urząd lub dostawcę | nie klikać dalej, zachować wiadomość, powiadomić osobę kontaktową | nagłówki maila, domena, załącznik w bezpiecznej formie, lista odbiorców |
| Nieautoryzowane logowanie | nietypowe alerty, blokady kont, logowania spoza zwykłej lokalizacji | zablokować konto według procedury, sprawdzić MFA i logi | identyfikator konta, czas prób, adresy IP, działania naprawcze |
W żadnym z tych scenariuszy AI nie powinno samodzielnie decydować, czy pacjent ma zostać poinformowany, czy lekarz może kontynuować wizyty, ani czy doszło do naruszenia danych. Model może przygotować podsumowanie, ale decyzje o pacjentach, danych i ciągłości świadczeń zostają po stronie ludzi z właściwą rolą.
Jak to wygląda w małej przychodni
Przykład modelowy — scenariusz pokazuje sposób myślenia o reakcji. Nie opisuje realnej placówki, realnych pacjentów ani konkretnego incydentu.
Wyobraźmy sobie prywatną przychodnię specjalistyczną w Polsce. W piątek o 8:15 recepcja dostaje kilka wiadomości wyglądających jak dokumentacja od pacjentów, a chwilę później jedna stacja robocza zaczyna zgłaszać nietypowy błąd. Grafik działa wolniej, część pracowników nie może wejść do poczty. To jeszcze nie jest pełna diagnoza techniczna, ale to już jest zdarzenie, którego nie wolno rozmyć w rozmowach na korytarzu.
Manager uruchamia kartę 24 godzin. Recepcja nie otwiera kolejnych załączników, osoba techniczna izoluje jedno stanowisko i kopiuje dostępne logi, a IOD dostaje informację, że mogą być dane osobowe w mailach. Lekarze prowadzą wizyty według awaryjnej listy pacjentów bez dopisywania nowych informacji do podejrzanego kanału. Ciągłość świadczeń jest decyzją organizacyjną, nie automatycznym wynikiem systemu.
Do 12:00 osoba kontaktowa ma pierwszy pakiet: czas wykrycia, objawy, zrzut komunikatu, nagłówki podejrzanego maila, listę dotkniętych systemów i informację, co już zrobiono. Do końca dnia placówka wysyła zgłoszenie przez portal CSIRT CeZ albo uzupełnia je zgodnie z otrzymaną ścieżką. Jeżeli brakuje części informacji, zapisuje brak i osobę odpowiedzialną za uzupełnienie. Nie czeka z pierwszym zgłoszeniem tylko dlatego, że raport nie jest idealny.
Ten przykład dobrze łączy się z tematem rejestru danych przed pilotażem AI, bo w kryzysie wraca to samo pytanie: gdzie są dane, kto ma do nich dostęp i kto może zdecydować o dalszym kroku. Jeżeli placówka nie zna odpowiedzi przed incydentem, po incydencie będzie je odtwarzać pod presją czasu.
Pytania do IOD, dostawcy EDM i osoby technicznej
Najlepsze pytania są krótkie i niewygodne. Nie chodzi o to, żeby przerzucić odpowiedzialność na dostawcę, tylko żeby wiedzieć, które informacje placówka może zdobyć w pierwszych godzinach. Poniższy zestaw warto przejść zanim pojawi się realny problem.
Do IOD zapytałbym: czy mamy procedurę oceny naruszenia danych osobowych, kto decyduje o zgłoszeniu do UODO, jak minimalizujemy dane w załącznikach do CSIRT i kiedy informujemy pacjentów. IOD nie powinien dowiadywać się o incydencie z trzeciej ręki po dwóch dniach.
Do dostawcy EDM lub grafiku: czy placówka ma dostęp do logów logowania, historii zmian, listy aktywnych sesji i informacji o kopiach zapasowych. Warto też zapytać, kto po stronie dostawcy odbiera zgłoszenie poza godzinami pracy oraz czy może przygotować techniczny opis dla CSIRT. Bez logów zgłoszenie staje się relacją świadków, a nie materiałem do reakcji.
Do osoby technicznej: które systemy można odizolować bez zatrzymania całej placówki, gdzie są kopie, jak sprawdzić MFA, jak zabezpieczyć podejrzany mail i kto ma uprawnienia administratora. Sugeruję zapisać odpowiedzi w jednej karcie, a nie w kilku mailach. W kryzysie jedno źródło prawdy jest ważniejsze niż elegancki dokument.
Metryki po ćwiczeniu i po realnym zgłoszeniu
Po ćwiczeniu albo realnym zdarzeniu manager powinien policzyć kilka rzeczy. Nie po to, żeby udowodnić winę zespołu, tylko żeby zobaczyć, czy placówka potrafi działać szybciej następnym razem. Cyberbezpieczeństwo w przychodni to proces operacyjny, a proces bez metryk szybko wraca do deklaracji.
| Metryka | Co pokazuje | Cel po pierwszym ćwiczeniu |
|---|---|---|
| Czas od wykrycia do decyzji o eskalacji | czy recepcja i manager wiedzą, kiedy zatrzymać normalny proces | poniżej 60 minut dla oczywistych objawów |
| Czas od wykrycia do zgłoszenia lub roboczego szkicu | czy placówka mieści się w rytmie 24 godzin | gotowy pakiet roboczy tego samego dnia |
| Kompletność załączników | czy są zrzuty, logi, nagłówki maili i lista systemów | minimum 80% pól karty bez doszukiwania po fakcie |
| Dostępność osoby kontaktowej | czy CSIRT, dostawca i manager mają jeden kanał rozmowy | zastępstwo opisane na wypadek urlopu |
| Czas odtworzenia ciągłości pracy | czy pacjenci nadal są obsługiwani w kontrolowany sposób | awaryjna ścieżka dla rejestracji i gabinetów |
Te liczby nie gwarantują, że incydentu nie będzie. Pokazują coś bardziej praktycznego: czy placówka potrafi szybko przejść od chaosu do decyzji. W ochronie zdrowia to ma znaczenie, bo cyberatak może uderzyć nie tylko w dane, ale też w dostępność świadczeń.
Pierwszy krok dzisiaj
Nie zaczynałbym od kupowania kolejnego systemu. Zacząłbym od 30 minut z managerem, IOD, rejestracją i osobą techniczną. Wskażcie osobę kontaktową, zapiszcie link do portalu CSIRT CeZ, wpiszcie skrzynkę awaryjną, numer telefonu dostawcy EDM i miejsce, gdzie będą odkładane zrzuty ekranu oraz logi.
Potem zróbcie krótkie ćwiczenie bez danych pacjenta: podejrzany mail, blokada konta, niedostępny grafik. Zespół ma odpowiedzieć na trzy pytania: kto decyduje, co zbieramy, kiedy zgłaszamy. Jeśli odpowiedzi mieszczą się na jednej stronie, jesteście bliżej gotowości niż po wielu godzinach ogólnego szkolenia.
Na koniec wpiszcie datę następnego przeglądu. Procedura incydentu starzeje się szybciej niż regulamin recepcji, bo zmieniają się dostawcy, konta, grafiki dyżurów i systemy. Ja bym wracał do tej karty co kwartał oraz po każdej zmianie dostawcy EDM, poczty, telefonii lub narzędzi AI.
Źródła
- Centrum e-Zdrowia — „Nowy bastion cyberbezpieczeństwa w ochronie zdrowia. Poznaj portal CSIRT CeZ” — komunikat z 23.06.2026; wnosi główny hook artykułu: portal CSIRT CeZ, formularz zgłoszenia incydentu, przykłady ransomware/phishing/nieautoryzowanego logowania oraz 24-godzinne wstępne zgłoszenie. Dostęp: 2026-07-06.
- Centrum e-Zdrowia — „Weryfikacja zgodności z wymogami cyberbezpieczeństwa” — oficjalna strona CeZ; porządkuje, czym jest incydent poważny, do kogo zgłaszać incydenty w sektorze ochrony zdrowia i jak działa ścieżka CSIRT CeZ. Dostęp: 2026-07-06.
- Cyber.gov.pl / Gov.pl — „Q&A Nowelizacja KSC” — materiał administracji publicznej aktualizowany w czerwcu 2026 r.; wyjaśnia obowiązki podmiotów kluczowych i ważnych, 24-godzinne wczesne ostrzeżenie, 72-godzinne zgłoszenie oraz możliwość sukcesywnego uzupełniania informacji. Dostęp: 2026-07-06.
- Centrum e-Zdrowia — „Raport 2025 CSIRT CeZ. Krajobraz cyberbezpieczeństwa w sektorze ochrony zdrowia” — raport z 02.06.2026; daje kontekst skali zdarzeń w ochronie zdrowia, dominujących kategorii incydentów i luk organizacyjnych w przeglądach ryzyka oraz politykach bezpieczeństwa. Dostęp: 2026-07-06.
- UODO — „Zgłaszanie naruszeń” — oficjalna strona Urzędu Ochrony Danych Osobowych; przypomina, że naruszenie ochrony danych osobowych może uruchamiać osobną ścieżkę oceny i zgłoszenia, równoległą do obsługi cyberincydentu. Dostęp: 2026-07-06.
- Okładka: Ivan S na Pexels — spokojny kadr lekarza pracującego przy laptopie, bez sensacyjności i bez widocznych danych pacjenta. Dostęp: 2026-07-06.
