Co zrobić po wycieku danych z narzędzia SaaS: 24-godzinny runbook dla IT i prawników

1. Cel i założenia runbooka

Ten runbook opisuje pierwsze 24 godziny działań po podejrzeniu lub potwierdzeniu wycieku danych z narzędzia typu SaaS używanego w organizacji. Jego celem jest zapewnienie wspólnego, spójnego sposobu postępowania dla IT, bezpieczeństwa oraz prawników/RODO, tak aby równolegle: ograniczać skutki incydentu, zabezpieczać materiał dowodowy, ustalać wpływ na dane oraz podejmować decyzje prawne i komunikacyjne w wymaganych terminach.

Runbook ma charakter operacyjny (kto, co, kiedy i przez jakie kanały), a nie jest pełną procedurą IR ani dokumentem polityk. Zakłada, że organizacja może korzystać z wielu usług SaaS oraz integracji (SSO, SCIM, API, webhooki, konektory), a incydent może dotyczyć zarówno danych w samym SaaS, jak i danych przekazywanych do/ze środowiska organizacji.

Zakres (co obejmuje, a czego nie)

Obejmuje incydenty, w których:

• doszło do nieautoryzowanego dostępu do tenant’u/usługi SaaS lub kont uprzywilejowanych (np. administratorzy, ownerzy workspace’ów),
• wyciek dotyczy danych przechowywanych lub przetwarzanych w SaaS (w tym metadanych, logów, załączników, treści),
• naruszenie wynika z błędnej konfiguracji, podatności dostawcy, przejęcia konta, nadużycia tokenów/kluczy API lub łańcucha integracji,
• istnieje ryzyko naruszenia poufności, integralności lub dostępności danych w kontekście obowiązków prawnych (w tym RODO),
• incydent dotyczy danych klientów, pracowników lub innych osób fizycznych, a także tajemnic przedsiębiorstwa.

Nie obejmuje pełnych działań naprawczych długoterminowych (hardening, przebudowa architektury, renegocjacja umów) ani pełnej obsługi PR–owej kryzysu. Te elementy mogą być uruchamiane równolegle, ale nie są celem tego runbooka.

Założenia operacyjne

• Priorytet 1: ograniczenie szkód poprzez szybkie przerwanie podejrzanych przepływów i minimalizację dalszej ekspozycji (bez przesądzania przyczyn).
• Priorytet 2: dowody – działania muszą uwzględniać zachowanie logów i artefaktów w sposób umożliwiający późniejszą analizę techniczną i audytową.
• Priorytet 3: spójne decyzje prawne – informacje z IT i bezpieczeństwa są zbierane tak, aby umożliwić ocenę ryzyka i obowiązków zgłoszeniowych bez zbędnej zwłoki.
• Zasada minimalnej wiedzy – dostęp do informacji o incydencie jest ograniczony do osób z rolami w runbooku; komunikacja zewnętrzna jest kontrolowana.
• Jedno źródło prawdy – jeden rejestr ustaleń (oś czasu, decyzje, osoby odpowiedzialne) i jedno miejsce do przechowywania uzgodnionych komunikatów.

Role i odpowiedzialności (RACI w praktyce)

Poniższe role mogą być realizowane przez różne osoby w zależności od wielkości organizacji; kluczowe jest, aby były wyznaczone z góry i dostępne w trybie 24/7 (dyżur/backup).

• Incident Lead (koordynator) – prowadzi działania w czasie, ustala priorytety, pilnuje eskalacji i decyduje o przejściu między etapami; odpowiada za spójność osi czasu i przypisywanie zadań.
• Właściciel usługi SaaS (Service Owner) – zna konfigurację tenant’u, integracje, licencje i procesy biznesowe; podejmuje decyzje o wstrzymaniu funkcji/usług w uzgodnieniu z Incident Lead.
• Bezpieczeństwo / SOC / IR – ocenia podejrzane aktywności, wskazuje wskaźniki kompromitacji, rekomenduje działania ograniczające ryzyko; koordynuje zbieranie danych technicznych.
• IT / IAM (tożsamość i dostęp) – odpowiada za konta, role, SSO/MFA, tokeny, klucze, integracje katalogowe oraz blokady/reset; realizuje decyzje operacyjne w systemach tożsamości.
• Administratorzy systemów/integracji – zarządzają konektorami, API, webhookami, mechanizmami wymiany danych; wdrażają tymczasowe ograniczenia w przepływach.
• Prawnik / dział prawny – ocenia ryzyka prawne, obowiązki umowne i regulacyjne (w tym notyfikacje do kontrahentów), przygotowuje ramy komunikacji i minimalizuje ryzyko błędnych oświadczeń.
• Inspektor Ochrony Danych (jeśli powołany) / funkcja RODO – wspiera kwalifikację zdarzenia jako naruszenia ochrony danych osobowych, prowadzi część dokumentacyjną (rejestr), opiniuje decyzje o zgłoszeniu i zawiadomieniu osób.
• Właściciel danych / biznes – wskazuje kategorie danych i procesy biznesowe w SaaS; pomaga ocenić wpływ na osoby i operacje.
• Komunikacja (PR/HR/CS) – jeśli uruchomione – przygotowuje i dystrybuuje komunikaty zgodnie z ustaleniami prawnymi; nie komunikuje samodzielnie bez akceptacji.
• Vendor Manager / Procurement – uruchamia ścieżkę kontaktu z dostawcą SaaS (support, security, DPA), zbiera ich oświadczenia i logi udostępniane przez dostawcę.

Kanały komunikacji i zasady obiegu informacji

• Wewnętrzny kanał incydentu (dedykowany, z ograniczonym dostępem) – bieżąca koordynacja, pytania i ustalenia operacyjne.
• Mostek/telekonferencja – dla szybkich decyzji i koordynacji w czasie rzeczywistym; każda decyzja z mostka jest zapisana w rejestrze incydentu.
• Rejestr incydentu – jedno miejsce na oś czasu, decyzje, właścicieli zadań, hipotezy i potwierdzone fakty (oddzielać fakty od założeń).
• Repozytorium dowodów z kontrolą dostępu – wyłącznie dla materiałów technicznych i dokumentów wymagających poufności.
• Kontakt z dostawcą SaaS – wyłącznie przez wyznaczoną rolę (Vendor Manager lub Incident Lead), aby uniknąć sprzecznych zgłoszeń i utraty kontekstu.
• Komunikacja zewnętrzna (klienci, osoby, partnerzy, media, organy) – tylko po zatwierdzeniu przez prawników/RODO oraz osobę upoważnioną; stosować zasadę „jednego głosu”.

Zasady: nie udostępniać szczegółów incydentu na kanałach nieautoryzowanych; ograniczać forwarding; nie spekulować; każde kluczowe ustalenie oznaczać jako potwierdzone lub niepotwierdzone.

Kryteria eskalacji (kiedy podnosić priorytet)

Eskalacja oznacza uruchomienie szerszego zespołu, wyższego poziomu decyzyjności oraz formalnych ścieżek prawnych/komunikacyjnych. Eskaluj niezwłocznie, gdy wystąpi co najmniej jeden z poniższych warunków:

• Potwierdzony nieautoryzowany dostęp do kont administracyjnych, ustawień bezpieczeństwa tenant’u lub mechanizmów integracji (SSO, API, klucze).
• Podejrzenie wycieku danych osobowych lub danych wrażliwych/objętych tajemnicą (handlową, zawodową, kontraktową).
• Duża skala: duża liczba rekordów/użytkowników, wiele projektów/workspace’ów lub wiele systemów zależnych.
• Ryzyko trwającej kompromitacji: aktywne sesje napastnika, nietypowe logowania, masowe eksporty, tworzenie nowych tokenów/kluczy, zmiany reguł bezpieczeństwa.
• Wpływ operacyjny: konieczność wyłączenia kluczowej usługi, ryzyko przestoju procesów krytycznych lub naruszenia SLA.
• Wymóg terminowy: zbliżające się ustawowe/umowne terminy zgłoszeń, potrzeba wczesnej oceny RODO lub obowiązków wobec kontrahentów.
• Ryzyko reputacyjne: incydent dotyczy danych klientów, danych finansowych, informacji strategicznych lub może zostać upubliczniony.

Praktyczna zasada: jeśli nie da się w rozsądnym czasie potwierdzić, że incydent jest ograniczony i opanowany, traktuj go jako incydent wysokiego priorytetu do czasu uzyskania dowodów przeciwnych.

0–1 godzina: natychmiastowa reakcja

W pierwszej godzinie celem jest zatrzymanie dalszego wycieku, ograniczenie możliwości nadużyć (np. przejętych tokenów), oraz zabezpieczenie dowodów w sposób umożliwiający późniejszą analizę techniczną i ocenę prawną. Ten etap jest nastawiony na szybkie decyzje „stop-the-bleed”, a nie na pełne ustalenie przyczyny czy skali. Podczas szkoleń Cognity ten temat wraca regularnie – dlatego zdecydowaliśmy się go omówić również tutaj.

1) Potwierdź zdarzenie i uruchom tryb incydentowy

• Zbierz minimum wiarygodnych sygnałów: co wykryto, kiedy, w jakim narzędziu SaaS, z jakiego źródła (alert, zgłoszenie użytkownika, informacja od dostawcy, monitoring).
• Ustal jedno źródło prawdy dla czasu zdarzeń: rozpocznij prostą oś czasu (kto/co/kiedy), aby od początku minimalizować chaos i rozbieżności.
• Ogranicz rozgłos operacyjny: komunikuj się w wyznaczonym kanale incydentowym, unikaj przekazywania wrażliwych detali w ogólnych kanałach.

2) Izolacja: zatrzymaj dalsze przepływy danych do/z SaaS

Izolacja oznacza chwilowe „odcięcie” ryzykownych ścieżek dostępu tak, aby powstrzymać eksfiltrację lub dalsze nadużycia. W praktyce wybierasz działania o największym wpływie na ograniczenie szkody przy akceptowalnym koszcie biznesowym.

• Wstrzymaj integracje przesyłające dane do SaaS (automatyzacje, konektory, webhooki, ETL/ELT, synchronizacje katalogów), szczególnie te z dostępem do danych osobowych lub tajemnic przedsiębiorstwa.
• Zablokuj podejrzane ścieżki logowania do SaaS: tymczasowo ogranicz dostęp z nietypowych lokalizacji/IP, włącz/zaostrz warunki dostępu warunkowego, jeżeli są dostępne.
• Wstrzymaj transfery wychodzące z SaaS do innych systemów, jeśli istnieje ryzyko rozpropagowania skażonych danych (np. masowe eksporty, automatyczne raporty, synchronizacja do CRM/ERP).

3) Wstrzymanie zmian, które mogą zniszczyć ślady

W tej fazie unikaj działań „porządkowych”, które poprawiają bezpieczeństwo kosztem utraty informacji śledczej.

• Wstrzymaj rutynowe czyszczenie logów i automatyczne retencje, które mogą skasować kluczowe zdarzenia.
• Nie usuwaj kont/obiektów w SaaS „dla bezpieczeństwa” bez odnotowania: usunięcie może utrudnić odtworzenie przebiegu naruszenia.
• Ustal kontrolę zmian: wprowadzaj tylko działania konieczne do zatrzymania wycieku i zabezpieczenia dowodów; reszta po ustabilizowaniu sytuacji.

4) Reset/rotacja tokenów, kluczy i sesji: ogranicz możliwość dalszego użycia dostępu

Priorytetem jest wyeliminowanie ryzyka, że atakujący nadal korzysta z przejętych poświadczeń lub tokenów. Na tym etapie skup się na najbardziej uprzywilejowanych i najbardziej „rozsianych” sekretach.

• Unieważnij aktywne sesje i wymuś ponowne logowanie dla użytkowników uprzywilejowanych oraz kont serwisowych, jeśli jest to możliwe w danym SaaS.
• Zresetuj/obróć tokeny API używane przez integracje (szczególnie te o szerokich uprawnieniach). Jeżeli nie możesz bezpiecznie zrotować od razu, tymczasowo je wyłącz.
• Obróć klucze/sekrety integracyjne przechowywane w narzędziach CI/CD, menedżerach sekretów, konfiguracjach aplikacji oraz w systemach pośredniczących (np. iPaaS).
• Ogranicz uprawnienia najbardziej ryzykownych kont (admin, właściciele workspace/tenant), jeśli nie wymaga to szerokiej przebudowy ról; celem jest szybkie „spłaszczenie” uprawnień, nie pełny redesign.

5) Zabezpieczenie logów i dowodów: działaj szybko i ostrożnie

W pierwszej godzinie chodzi o zachowanie tego, co może zniknąć (logi o krótkiej retencji, dane kontekstowe, identyfikatory zdarzeń) oraz o utrzymanie spójności materiału dowodowego.

• Wykonaj eksport kluczowych logów z SaaS (logi logowań, aktywności administracyjnej, zmian uprawnień, eksportów danych, tworzenia tokenów, konfiguracji integracji), wraz z metadanymi (strefa czasowa, tenant, identyfikatory).
• Zachowaj kontekst konfiguracji: aktualne ustawienia SSO/MFA, polityki dostępu, listę aktywnych integracji i ostatnie zmiany w konfiguracji (nawet w formie zrzutów ustawień), aby móc później porównać stan „przed i po”.
• Zabezpiecz dowody z systemów towarzyszących: logi IdP (np. logowania SSO), bramki CASB/proxy, SIEM, narzędzia EDR na stacjach adminów, dzienniki zmian w repozytoriach konfiguracji.
• Utrzymaj podstawowy łańcuch dowodowy: kto pozyskał, kiedy, z jakiego źródła, gdzie przechowywane; ogranicz dostęp do wyznaczonych osób, aby uniknąć zarzutów manipulacji.

6) Szybka weryfikacja „czy atak trwa”

Bez wchodzenia w pełną analizę, sprawdź, czy po wprowadzonych blokadach nadal występują symptomy aktywności.

• Sprawdź bieżące alerty i anomalia: nowe logowania, masowe eksporty, tworzenie nowych tokenów, zmiany ról, nietypowe integracje.
• Zweryfikuj skuteczność odcięć: czy webhooki/integracje faktycznie przestały wysyłać dane, czy unieważnienie sesji zadziałało, czy tokeny nie są już akceptowane.

7) Minimalna komunikacja operacyjna na teraz

Komunikacja w tej godzinie ma być krótka i zadaniowa: co zostało wstrzymane, jakie ryzyka są znane, czego nie wiemy oraz jakie działania są zabronione (np. kasowanie zasobów, samodzielne „naprawy” poza kanałem incydentu).

• Uzgodnij jedno miejsce aktualizacji statusu i cykliczny rytm krótkich aktualizacji dla zespołów IT/bezpieczeństwa oraz osób odpowiedzialnych za ryzyko i zgodność.
• Przygotuj neutralny komunikat wewnętrzny do ograniczonego grona: „incydent w narzędziu SaaS, integracje wstrzymane, trwa zabezpieczenie dostępu i logów”. Bez spekulacji o przyczynach i skali.

Rezultat po 60 minutach: integracje i ryzykowne przepływy są zatrzymane, podejrzane poświadczenia przynajmniej tymczasowo unieważnione, a najbardziej ulotne logi i kontekst konfiguracji zabezpieczone w kontrolowany sposób.

3. 1–4 godziny: triage i stabilizacja

W tym oknie czasowym celem jest opanowanie niepewności: szybkie ustalenie, co mogło zostać dotknięte, jakie kanały dostępu są ryzykowne oraz czy atak trwa. To etap „triage” (priorytetyzacja i selekcja działań), a nie pełna analiza przyczyn ani kompletna ocena skutków.

3.1 Inwentaryzacja dostępu (kto/co ma dostęp do SaaS i z jakimi uprawnieniami)

Wykonaj zwięzłe zestawienie wszystkich ścieżek dostępu do narzędzia SaaS i powiązanych zasobów. Chodzi o identyfikację punktów wejścia oraz kont i sekretów, które mogą wymagać rotacji lub ograniczenia.

• Konta użytkowników: administratorzy, właściciele workspace/tenant, konta uprzywilejowane, konta serwisowe, konta byłych pracowników.
• SSO/IAM: dostawca tożsamości, zasady MFA, grupy/role mapowane do SaaS, wyjątki (np. „local admin”).
• API i integracje: tokeny API, OAuth appy, webhooki, integracje natywne (CRM/ERP), konektory ETL/BI, boty/automatyzacje.
• Urządzenia i sesje: aktywne sesje, podejrzane logowania, dostępy z nietypowych lokalizacji/IP/ASN.
• Uprawnienia i zakresy: role globalne vs. per-projekt, zakresy OAuth (scopes), dostęp do eksportów, logów audytowych, danych wrażliwych.

Wynik oczekiwany: krótka lista „najwyższego ryzyka” (np. konta admin, tokeny o szerokich scope’ach, integracje z uprawnieniami zapisu/eksportu), która dyktuje kolejność rotacji i wyłączeń.

3.2 Rotacja sekretów (klucze, tokeny, hasła) – szybkie ograniczenie nadużyć

Rotacja sekretów w triage ma charakter operacyjny: minimalizuje ryzyko dalszego wykorzystania przejętych danych uwierzytelniających. W tej fazie preferuj działania, które odcinają dostęp i są odwracalne lub kontrolowane.

• Priorytet 1: tokeny/klucze z uprawnieniami administracyjnymi, szerokie OAuth scopes, długowieczne API keys, integracje z prawem do eksportu lub modyfikacji danych.
• Priorytet 2: konta serwisowe i automaty (CI/CD, integratory), klucze do webhooków, sekrety w narzędziach automatyzacji.
• Priorytet 3: hasła użytkowników (tylko jeśli istnieją przesłanki nadużyć; w przeciwnym razie przygotuj plan wymuszenia zmiany z kontrolą wpływu).

Równolegle ogranicz powierzchnię uprawnień: zmniejsz scope’y, usuń nieużywane tokeny, rozdziel uprawnienia (zasada najmniejszych uprawnień), czasowo usuń role admin tam, gdzie to możliwe.

Uwaga na stabilność: rotacja sekretów może zrywać procesy biznesowe. Dlatego każdą rotację łącz z szybkim testem krytycznych przepływów (logowanie, synchronizacje, eksporty, integracje) i notuj zmiany w jednym miejscu (czas, właściciel, zakres).

3.3 Przegląd integracji (co łączy się z SaaS i co SaaS może „dotknąć”)

Wyciek z SaaS często oznacza ryzyko propagacji przez integracje. W 1–4 godzin skup się na ustaleniu, które połączenia są kluczowe dla ciągłości, a które można bezpiecznie wstrzymać.

Minimalny rezultat: lista integracji z decyzją „utrzymać / ograniczyć / wstrzymać” oraz przypisanym właścicielem, który odpowiada za walidację po zmianach.

3.4 Wstępna analiza logów i IOC (czy widać nadużycia i jak je szybko wykrywać)

Na tym etapie analiza ma charakter wstępny i nastawiony na wykrycie aktywnej kompromitacji. Nie próbuj jeszcze budować pełnej osi czasu – skup się na sygnałach o dużej wiarygodności.

• Logi SaaS: logowania (udane/nieudane), zmiany uprawnień/rol, tworzenie tokenów, eksporty, masowe odczyty, konfiguracje integracji, wyłączenia MFA/zmiany SSO.
• Logi IdP/SSO: nietypowe lokalizacje, niestandardowe urządzenia, anomalie w MFA, logowania do kont uprzywilejowanych.
• Logi sieciowe/endpoint (jeśli dotyczy): aktywność skryptów automatyzujących, nietypowe wywołania API, wzrost błędów 401/403 po rotacjach (może wskazywać na aktywne próby użycia starych tokenów).

IOC (Indicators of Compromise) w triage traktuj jako listę roboczą: adresy IP, identyfikatory aplikacji OAuth, podejrzane user-agenty, nietypowe zakresy tokenów, nagłe skoki wolumenu zapytań, wzorce eksportów/odczytów. Szybko przekaż je do zespołów operacyjnych (SOC/IT) jako kryteria filtrowania i alertowania.

Jeśli musisz szybko ujednolicić format obserwacji, użyj prostego szablonu wpisu (czas, źródło, artefakt, opis, pewność):

2026-03-19T10:15Z | SaaS audit log | token.create | Nowy token dla konta serwisowego, scope: full_access | wysoka
2026-03-19T10:22Z | IdP sign-in     | login.success | Admin: nowe urządzenie + kraj nietypowy | średnia

3.5 Kryteria „stabilizacji” na koniec 4. godziny

• Zidentyfikowane i sklasyfikowane główne ścieżki dostępu (konta uprzywilejowane, tokeny, integracje).
• Wykonana rotacja lub unieważnienie sekretów o najwyższym ryzyku oraz odnotowane zmiany (co/kiedy/kto).
• Podjęte decyzje o wstrzymaniu/ograniczeniu integracji o największym wpływie na ryzyko.
• Ustalona robocza lista IOC oraz podstawowe filtry/zapytania do dalszego monitoringu.
• Wstępny obraz: czy aktywność wygląda na trwającą (tak/nie/niepewne) – z krótkim uzasadnieniem na podstawie logów.

4–12 godzin: analiza wpływu i ryzyka + działania RODO

W tym oknie czasowym łączysz ustalenia techniczne (co, kiedy i jak mogło wyciec) z oceną prawną (czy to jest naruszenie ochrony danych osobowych, jakie niesie ryzyko i czy trzeba zgłaszać). Celem nie jest pełne dochodzenie incydentu, tylko wiarygodna ocena wpływu oparta o dostępne fakty oraz udokumentowanie decyzji.

Zespół trenerski Cognity zauważa, że właśnie ten etap (przełożenie faktów technicznych na decyzje RODO) sprawia uczestnikom najwięcej trudności — dlatego warto działać według stałej struktury pytań i minimalnego zestawu danych.

1) Ustal, czy incydent dotyczy danych osobowych (i w jakiej roli występujesz)

• Dane osobowe: każda informacja pozwalająca zidentyfikować osobę bezpośrednio lub pośrednio (także identyfikatory online, np. ID konta, adres IP, identyfikatory urządzeń, jeśli w kontekście pozwalają powiązać z osobą).
• Role RODO: potwierdź, czy organizacja jest administratorem (decyduje o celach i sposobach przetwarzania), czy podmiotem przetwarzającym (działa na zlecenie). To determinuje obowiązki: administrator ocenia ryzyko i ewentualnie zgłasza do UODO i zawiadamia osoby; procesor ma obowiązek niezwłocznie poinformować administratora.
• Kontekst SaaS: jeśli wyciek dotyczy narzędzia SaaS używanego przez Twoją organizację, zwykle jesteś administratorem względem danych swoich użytkowników/klientów/pracowników, a dostawca SaaS jest procesorem (ale nie zawsze — sprawdź umowę powierzenia i rzeczywisty podział ról).

2) Klasyfikacja kategorii danych i scenariuszy naruszenia

Wstępnie przypisz incydent do kategorii danych i typu naruszenia. To umożliwia szybką, spójną ocenę ryzyka.

3) Określ skalę naruszenia (kogo i ile dotyczy)

Skala to nie tylko liczba rekordów. W tej fazie budujesz najlepsze oszacowanie na podstawie dostępnych metryk i przyjmujesz konserwatywne założenia, jeśli są luki dowodowe.

• Liczba osób: unikalne osoby, których dane mogły zostać ujawnione/zmienione/utracone.
• Liczba rekordów i typy obiektów: np. kontakty, tickety, pliki, notatki, logi.
• Zasięg geograficzny: państwa, których dotyczą osoby (istotne dla komunikacji i ewentualnych wymogów kontraktowych).
• Okres ekspozycji: od kiedy do kiedy dane były dostępne dla nieuprawnionych (lub kiedy mogły zostać pobrane).
• Grupy szczególnie narażone: pracownicy, klienci, pacjenci, dzieci, osoby w trudnej sytuacji.

4) Ocena ryzyka dla praw i wolności osób (RODO) — szybki model decyzyjny

RODO wymaga oceny, czy naruszenie może skutkować ryzykiem dla praw i wolności osób (próg zgłoszenia do UODO) oraz czy jest wysokie ryzyko (próg zawiadomienia osób). W tym etapie stosuj prostą, powtarzalną metodykę: prawdopodobieństwo × dotkliwość, opartą o scenariusze szkody.

Praktyczna różnica progów (do zastosowania bez rozstrzygania wszystkich niuansów):

• Zgłoszenie do UODO: gdy naruszenie może powodować ryzyko (próg relatywnie niski).
• Zawiadomienie osób: gdy ryzyko jest wysokie (np. dane wrażliwe, dane uwierzytelniające, duża skala, potwierdzona eksfiltracja, realne ryzyko oszustw).

5) Rejestr naruszeń: co musi się znaleźć już teraz

Niezależnie od decyzji o zgłoszeniu, naruszenie powinno trafić do rejestru naruszeń z informacjami wystarczającymi do wykazania zgodności. W tym przedziale czasowym wpis może być wstępny, ale musi odzwierciedlać stan wiedzy i założenia.

• Data i czas wykrycia oraz (jeśli możliwe) czas rozpoczęcia naruszenia i okres ekspozycji.
• Opis zdarzenia (co się stało) oraz systemy/procesy objęte incydentem (SaaS, integracje, obszary danych).
• Kategorie osób (np. klienci, pracownicy) i kategorie danych (zaznaczeniem danych szczególnych/uwierzytelniających).
• Szacowana skala: liczba osób/rekordów (zakres lub widełki) i poziom niepewności.
• Wstępna ocena ryzyka wraz z uzasadnieniem (w tym przyjęte założenia).
• Zastosowane/planowane środki ograniczające skutki (na poziomie ogólnym, bez wchodzenia w checklisty techniczne).
• Decyzja dot. zgłoszenia (tak/nie/nieustalone) i uzasadnienie oraz kto podjął decyzję.
• Powiązania kontraktowe: czy dotyczy danych powierzonych / współadministracji; czy trzeba powiadomić innych administratorów.

6) Decyzja o zgłoszeniu: kiedy i na jakiej podstawie

W 4–12 godzinie priorytetem jest podjęcie decyzji „czy celujemy w zgłoszenie” oraz zbudowanie pakietu uzasadniającego. Zostawiasz sobie też przestrzeń na aktualizacje, jeśli nowe fakty zmienią ocenę.

• Jeśli istnieje co najmniej niezerowe ryzyko dla praw i wolności osób (np. ujawnienie danych kontaktowych, identyfikatorów, treści zgłoszeń, metadanych aktywności) — domyślnie przygotowuj się do zgłoszenia do UODO.
• Jeśli istnieje wysokie ryzyko (np. dane szczególne, dane logowania/tokeny, dane finansowe, duża skala, potwierdzony dostęp osoby trzeciej) — równolegle przygotuj scenariusz zawiadomienia osób.
• Jeżeli ryzyko jest mało prawdopodobne dzięki silnym środkom (np. dane były zaszyfrowane, a klucze nie zostały ujawnione; dane pozostają pseudonimizowane bez ujawnienia mapowań) — udokumentuj to jako kluczową przesłankę decyzji o niezgłaszaniu lub o braku zawiadomienia osób.

W tej fazie nie tworzysz jeszcze pełnych treści komunikatów ani kompletnej dokumentacji dowodowej; skupiasz się na kryteriach i logice decyzji oraz na spójności między ustaleniami IT a oceną prawną.

7) Minimalny zestaw informacji, które muszą być dostępne dla DPO/prawników

• Jakie dane mogły wyciec (kategorie i przykłady pól) oraz z jakich modułów/zasobów SaaS.
• Jaki jest najbardziej prawdopodobny scenariusz: ekspozycja vs. potwierdzona eksfiltracja; pojedynczy tenant vs. wiele tenantów; błąd konfiguracji vs. przejęcie konta.
• Szacunek liczby osób i okresu ekspozycji (z oznaczeniem niepewności).
• Jakie środki ograniczające już zadziałały (np. unieważnienie dostępu) i co pozostaje ryzykiem rezydualnym.

5. 12–24 godziny: komunikacja i dalsze kroki (UODO/osoby, plan naprawczy, monitorowanie, ograniczenia szkód, raportowanie)

W tym oknie czasowym priorytetem jest kontrolowana komunikacja (regulator i osoby, których dane dotyczą) oraz uruchomienie spójnego planu naprawczego i monitoringu. Działania techniczne nie kończą się na „zatrzymaniu krwawienia” — teraz chodzi o ograniczenie szkód, utrzymanie ciągłości biznesu oraz przygotowanie materiału do decyzji formalnych i audytowalnego raportowania.

5.1. Komunikacja z UODO: kiedy, kto i w jakim celu

Jeżeli po ocenie ryzyka (wykonanej wcześniej) zapadła decyzja o zgłoszeniu naruszenia, 12–24 godziny to czas na przygotowanie i wysłanie (albo złożenie wstępnego zgłoszenia i zapowiedź uzupełnień). Kluczowe jest, by komunikat był spójny z ustaleniami technicznymi i prawnymi oraz by zawierał tylko informacje zweryfikowane.

• Właściciel procesu: zwykle DPO/Inspektor Ochrony Danych lub dział prawny; IT/security dostarcza fakty i dowody.
• Cel: spełnienie obowiązków formalnych i wykazanie należytej staranności (co już zrobiono, co planowane, jak ograniczono ryzyko).
• Zasada jakości: lepsze krótkie, faktograficzne zgłoszenie z opisem braków i terminem dosłania uzupełnień niż rozbudowane spekulacje.

5.2. Komunikacja do osób, których dane dotyczą: pragmatyka i minimalizacja szkód

Jeżeli ryzyko dla osób jest wysokie i istnieje obowiązek poinformowania, przygotuj komunikację tak, aby była użyteczna operacyjnie (co użytkownik ma zrobić) i bezpieczna (bez podawania danych, które mogłyby pomóc atakującemu).

• Treść: co się stało (w prostych słowach), jakie dane mogły zostać ujawnione, jakie są możliwe konsekwencje, co robicie, co ma zrobić odbiorca (np. zmiana hasła, włączenie MFA), gdzie uzyskać wsparcie.
• Kanały: email, komunikat w aplikacji/portalu, strona statusowa; wybór kanału powinien uwzględniać ryzyko phishingu (jasne zasady weryfikacji autentyczności komunikatu).
• Wsparcie: zorganizuj punkt kontaktu (helpdesk/obsługa klienta) z gotowym skryptem odpowiedzi i kryteriami eskalacji do prawników/bezpieczeństwa.

5.3. Spójność komunikacji: jedna wersja prawdy

W praktyce największe ryzyko w tym etapie to rozjazd między komunikacją prawną, bezpieczeństwa, IT i PR. Ustal jedno źródło prawdy i jednolity workflow zatwierdzania.

• Jedno repozytorium faktów: daty/godziny, zakres systemów, wstępny wektor, podjęte działania, znane i nieznane.
• Reguła „need-to-know”: udostępniaj szczegóły techniczne tylko tam, gdzie są niezbędne.
• Kontrola zmian: każda nowa informacja powinna aktualizować komunikaty lub wymagać decyzji, że nie zmienia to przekazu.

5.4. Plan naprawczy (remediation): priorytety na teraz i po 24h

Plan naprawczy powinien łączyć szybkie działania ograniczające ryzyko z zadaniami systemowymi. Nie chodzi tu o pełną przebudowę bezpieczeństwa, tylko o konkretne, mierzalne kroki do zamknięcia najistotniejszych luk ujawnionych przez incydent.

• Priorytet 1: zamknięcie wektora (np. ograniczenia dostępu, polityki tokenów, IP allowlist, zmiana konfiguracji integracji, wyłączenie nieużywanych konektorów).
• Priorytet 2: zabezpieczenia kont i tożsamości (MFA, przegląd ról, minimalizacja uprawnień, przymusowe resety w uzasadnionym zakresie).
• Priorytet 3: odporność operacyjna (monitoring, alerty, procedury odtwarzania, komunikacja statusowa).

5.5. Monitorowanie po incydencie: co obserwować i jak wykrywać skutki wtórne

Po wycieku z SaaS często pojawiają się skutki wtórne: próby użycia przejętych tokenów, phishing do użytkowników, nadużycia API, nietypowe eksporty danych. W ciągu 12–24 godzin uruchom wzmocnione monitorowanie, które ma wykryć kontynuację incydentu i jego eskalację.

• Tożsamość i dostęp: anomalie logowań, skoki uprawnień, nietypowe geolokacje, masowe logowania nieudane.
• Aktywność w SaaS: masowe eksporty/wycieki, tworzenie nowych tokenów, zmiany konfiguracji integracji, nienaturalne użycie API.
• Systemy wewnętrzne: korelacja zdarzeń (SIEM/EDR), wykrywanie podejrzanych połączeń do usług powiązanych z integracjami.

5.6. Ograniczanie szkód: działania ochronne „na ludzi” i „na biznes”

Równolegle do monitoringu podejmij kroki minimalizujące realny wpływ na osoby i organizację. Dobór środków zależy od rodzaju danych i scenariuszy nadużyć, ale cel jest stały: ograniczyć możliwość wykorzystania ujawnionych informacji.

• Antyphishing: ostrzeżenia dla użytkowników/klientów, ujednolicone zasady weryfikacji wiadomości, wzmocniona filtracja poczty.
• Zmiany w procesach: tymczasowe ograniczenia w eksportach, dodatkowe zatwierdzanie wrażliwych operacji, podniesienie progów alertów.
• Wsparcie operacyjne: gotowe odpowiedzi dla helpdesku i sprzedaży/obsługi klienta, aby minimalizować chaos informacyjny.

5.7. Raportowanie wewnętrzne: zarząd, ryzyko, audyt

W 12–24 godzinie potrzebujesz krótkiego raportu kierowniczego: co wiadomo, co nie wiadomo, co zrobiono, jakie są ryzyka i jakie decyzje są wymagane. Raport ma być możliwy do aktualizacji i porównywania w czasie (wersjonowanie).

• Status incydentu: potwierdzony/niepotwierdzony wektor, czy aktywność nadal trwa, bieżące środki ochronne.
• Wpływ: wstępna skala (systemy/procesy), potencjalne konsekwencje dla osób i biznesu.
• Decyzje: czy i kiedy komunikujemy (UODO/osoby/partnerzy), jakie ograniczenia biznesowe akceptujemy (np. wyłączenie integracji), jakie zasoby uruchamiamy.

5.8. Kiedy eskalować w tym oknie czasowym (kryteria praktyczne)

W ciągu 12–24 godzin eskalacja jest uzasadniona, gdy pojawiają się sygnały, że incydent rozszerza się lub rośnie ryzyko szkody.

• Nowe dowody na aktywne nadużycia (np. użycie tokenów po rotacji, ponowne kompromitacje, masowe eksporty).
• Wychodzi na jaw, że wyciek obejmuje dane szczególnych kategorii lub szeroką skalę.
• Incydent dotyka kluczowych procesów (ciągłość działania) albo wymaga komunikacji do dużej grupy osób.
• Pojawia się presja czasowa na komunikację zewnętrzną (media, klienci, partnerzy) bez pełnych ustaleń — wymaga to sterowania przez prawne + bezpieczeństwo.

5.9. Szybkie rozróżnienie: UODO vs osoby vs partnerzy biznesowi

6. Checklisty operacyjne (IT, bezpieczeństwo, prawne/RODO, komunikacja) dla każdej ramy czasowej

Poniższe checklisty służą do szybkiego podziału pracy i utrzymania spójnego tempa działań w pierwszych 24 godzinach. Dzielą zadania na cztery strumienie: IT (ciągłość i konfiguracje), Bezpieczeństwo (ograniczenie ekspozycji i dowody), Prawne/RODO (ocena obowiązków i ryzyka), Komunikacja (kontrolowane przekazy do interesariuszy).

0–1 godzina

1–4 godziny

4–12 godzin

12–24 godziny

Wspólne „bramki” jakości (dla wszystkich ram czasowych)

• Spójność faktów: bezpieczeństwo i prawne pracują na tej samej osi czasu i tych samych definicjach (co potwierdzone vs. hipoteza).
• Kontrola zmian: każda zmiana konfiguracji/rotacja sekretów jest odnotowana (co, kiedy, kto, po co).
• Minimalizacja ryzyka komunikacyjnego: brak obietnic i liczb bez potwierdzenia; jedna osoba/komórka zatwierdza przekaz.
• Jedno miejsce dokumentacji: centralny rejestr decyzji, działań i ustaleń (czas, właściciel, status).

7. Minimalny zestaw dowodów do zachowania (artefakty, logi, łańcuch dowodowy, przechowywanie)

Celem zabezpieczenia dowodów jest umożliwienie odtworzenia przebiegu zdarzeń, wykazania należytej staranności (w tym na potrzeby RODO i kontroli), wsparcia działań naprawczych oraz – jeśli zajdzie potrzeba – obsługi sporu prawnego. Zbieraj dowody tak, aby były kompletne, spójne i możliwe do obrony (kto, co, kiedy, skąd pochodzi i czy nie było modyfikowane).

Jakie artefakty zachować (minimum)

• Stan konfiguracji i ustawień SaaS w momencie wykrycia: zrzuty/eksporty ustawień bezpieczeństwa (SSO, MFA, polityki dostępu), listy administratorów i ról, ustawienia udostępnień, polityki retencji i logowania zdarzeń.
• Dowody uwierzytelnienia i autoryzacji: lista aktywnych sesji (jeśli dostępna), historia logowań, zdarzenia związane z resetami haseł, zmianami MFA, dodaniem/odłączeniem dostawcy tożsamości, zmianami uprawnień.
• Integracje i połączenia aplikacyjne: wykaz integracji (API, webhooki, konektory, SCIM), identyfikatory aplikacji, zakresy uprawnień, daty utworzenia/zmian, informacje o właścicielach integracji.
• Artefakty z konsoli administracyjnej: audyt zmian (kto i jakie ustawienia zmienił), zdarzenia tworzenia/usuwania użytkowników, nadawania ról, zmian w politykach.
• Ślady exfiltracji/udostępnienia danych: logi pobrań/eksportów, tworzenie linków publicznych, udostępnienia międzytenantowe (jeśli dotyczy), masowe operacje (bulk export, archiwizacja, migracje), zdarzenia generowania raportów.
• Komunikacja z dostawcą SaaS: zgłoszenia do supportu, potwierdzenia incydentu, informacje o statusie, numer referencyjny sprawy, odpowiedzi dot. zakresu i czasu zdarzenia, deklaracje o dostępności logów oraz ich retencji.
• Dowody z systemów wewnętrznych: logi z IdP/SSO, MDM/EDR (dla urządzeń adminów), bramy CASB/SWG/Proxy (jeśli są), SIEM (korelacje i alarmy), poczta (powiadomienia o logowaniach/zmianach), DNS/VPN (jeśli relewantne).
• Lista potencjalnie naruszonych zasobów: identyfikatory projektów/tenantów/workspace’ów, nazwy zbiorów/domen danych, wskaźniki rozmiaru eksportów, zakres czasowy aktywności.
• Chronologia działań obronnych: zapis decyzji i wykonanych kroków (kto zatwierdził, kto wykonał, kiedy, jaki był powód). To nie jest „plan działania”, tylko dowód, co faktycznie zrobiono.

Jakie logi zachować (i czym się różnią)

W praktyce przydają się trzy kategorie logów, bo odpowiadają na różne pytania:

• Logi audytowe (administracyjne): pokazują zmiany konfiguracji i uprawnień; są kluczowe do ustalenia, czy doszło do przejęcia konta admina lub nadużycia ról.
• Logi dostępu i aktywności użytkowników: odpowiadają na pytanie „kto uzyskał dostęp do danych i co zrobił” (logowania, pobrania, eksporty, udostępnienia).
• Logi integracji i API: pozwalają odróżnić działania człowieka od automatyzacji oraz wykryć nadużycie tokenów/kluczy i nietypowe wzorce wywołań.

Jeżeli część logów jest dostępna wyłącznie u dostawcy SaaS lub ma krótką retencję, priorytetem jest jak najszybsze zamrożenie i eksport tego, co może zniknąć.

Łańcuch dowodowy (chain of custody) w wersji „minimalnej, ale defensywnej”

• Jedno źródło prawdy: wyznacz jeden repozytorium dowodów (z kontrolą dostępu) oraz jedną osobę/funkcję odpowiedzialną za przyjęcie i rejestr materiałów.
• Rejestr dowodów: dla każdego artefaktu zanotuj: skąd pochodzi, kto go pozyskał, kiedy, w jakiej formie, oraz gdzie jest przechowywany. Dopisz, czy to kopia czy oryginał i jaki ma poziom poufności.
• Integralność: utrzymuj kopie w formie nieedytowalnej; każdą zmianę lokalizacji lub dostępu odnotuj. Jeśli wykonujesz transformacje (np. konwersja formatu), zachowaj także plik źródłowy.
• Minimalizacja dostępu: dostęp tylko dla osób, które muszą pracować na dowodach; rozdziel role „przegląda” i „administruje repozytorium”.
• Spójna oś czasu: zapisuj znaczniki czasu w jednej strefie (np. UTC) i notuj źródło czasu, aby uniknąć sporów o kolejność zdarzeń.
• Wersjonowanie i nieusuwalność: unikaj nadpisywania plików; dopisuj kolejne wersje z jasnym opisem przyczyny.

Przechowywanie i retencja: praktyczne minimum

• Bezpieczne miejsce składowania: szyfrowanie w spoczynku i w tranzycie, silne uwierzytelnianie, ograniczenie pobierania, dziennik dostępu do repozytorium dowodów.
• Separacja od środowiska operacyjnego: repozytorium dowodów nie powinno być zależne od tego samego SaaS, którego dotyczy incydent (minimalizuje ryzyko utraty lub manipulacji).
• Klasyfikacja: oznacz materiały jako poufne (często zawierają dane osobowe, tajemnice przedsiębiorstwa, informacje o zabezpieczeniach); wymuś odpowiednie ograniczenia udostępniania.
• Retencja zgodna z wymogami: przechowuj co najmniej do zamknięcia incydentu oraz zakończenia potencjalnych postępowań/roszczeń; jeśli organizacja ma polityki retencji dla incydentów lub rejestru naruszeń, dopasuj się do nich.
• Kopie zapasowe dowodów: utrzymuj co najmniej jedną kopię w odrębnej lokalizacji logicznej; testuj możliwość odtworzenia, aby dowody nie były „martwe”.
• Kontrola udostępnień zewnętrznych: jeżeli dowody mają trafić do kancelarii, biegłych lub ubezpieczyciela, przekazuj tylko niezbędny zakres i odnotuj przekazanie w rejestrze dowodów.

Najczęstsze błędy, których unikać

• „Czyszczenie” środowiska bez zabezpieczenia logów i eksportów (utrata kluczowych śladów).
• Przechowywanie dowodów w luźnych kanałach komunikacji (czaty, prywatne skrzynki), bez kontroli dostępu i bez rejestru.
• Nadpisywanie plików, brak wersjonowania, brak informacji o pochodzeniu.
• Mieszanie materiałów roboczych (analizy, notatki) z dowodami źródłowymi bez jasnego rozdziału.
• Brak szybkiej reakcji na krótką retencję logów po stronie SaaS.

8. Załączniki: szablon pytań do vendora oraz wzór krótkiej notatki dla zarządu

Poniższe załączniki służą do dwóch różnych celów: (1) szybkie pozyskanie faktów od dostawcy SaaS (żeby urealnić ocenę ryzyka i ustalenia techniczne) oraz (2) zwięzłe poinformowanie zarządu (żeby podjąć decyzje biznesowe i zapewnić zasoby). Szablony są celowo krótkie i nastawione na odpowiedzi „tak/nie”, liczby, daty i konkretne artefakty.

W Cognity łączymy teorię z praktyką – dlatego ten temat rozwijamy także w formie ćwiczeń na szkoleniach.

8.1. Szablon pytań do vendora SaaS (do e-maila / formularza incydentowego)

Instrukcja użycia: wyślij jako jedno zapytanie, prosząc o odpowiedź w ustalonym terminie oraz o wskazanie osoby kontaktowej 24/7. Pytania są pogrupowane tak, by dało się je przekazać równolegle do zespołów IT/bezpieczeństwa i prawnego.

• Potwierdzenie incydentu
  • Czy potwierdzacie naruszenie bezpieczeństwa (tak/nie)? Jeśli tak: data i godzina wykrycia oraz okres, w którym incydent trwał lub mógł trwać.
  • Jaki jest status: aktywne / opanowane / w trakcie dochodzenia?
  • Jaką metodą incydent został wykryty (monitoring wewnętrzny, zgłoszenie z zewnątrz, organy ścigania, inny klient)?
• Zakres i wpływ
  • Jakie komponenty/usługi zostały dotknięte (np. aplikacja, API, baza danych, logowanie SSO, integracje)?
  • Czy incydent dotyczy środowisk produkcyjnych, testowych, kopii zapasowych (tak/nie)?
  • Czy incydent mógł objąć nasze dane/tenanta (tak/nie/niepewne)? Na jakiej podstawie?
  • Jakie kategorie danych mogły zostać objęte: treści w systemie, metadane, dane kont użytkowników, dane rozliczeniowe, logi, pliki załączników, inne.
  • Jeśli znacie: szacowana liczba rekordów / użytkowników / obiektów dotyczących naszej organizacji.
  • Czy doszło do: nieuprawnionego dostępu, eksfiltracji, modyfikacji, usunięcia, zaszyfrowania (ransomware) — które z tych (jeśli dotyczy)?
• Wektor ataku i przyczyna
  • Jaka jest wstępna przyczyna źródłowa (np. podatność, błąd konfiguracji, kompromitacja konta, łańcuch dostaw)?
  • Czy incydent dotyczył konkretnych mechanizmów uwierzytelniania (SSO/OAuth/API keys) lub uprawnień administracyjnych?
  • Czy znane są wskaźniki naruszenia (IOCs) i czy możecie je udostępnić (adresy IP, domeny, hashe, user-agenty, identyfikatory sesji, zakres czasowy)?
• Działania podjęte przez vendora
  • Jakie działania ograniczające zostały wdrożone (np. blokady, reset sesji, wymuszenie rotacji kluczy, poprawki, reguły WAF)?
  • Czy wdrożono poprawkę/mitigację i czy wymaga ona działań po naszej stronie (tak/nie; jeśli tak — jakie)?
  • Jak weryfikujecie skuteczność działań (testy, monitoring, audyt)?
• Wymagane działania po stronie klienta
  • Czy rekomendujecie natychmiastową rotację: kluczy API, tokenów OAuth, haseł kont serwisowych, certyfikatów (wskaż dokładnie których)?
  • Czy należy wstrzymać/wyłączyć konkretne integracje lub webhooki (tak/nie; które)?
  • Czy są znane ryzyka wtórne, np. phishing, podszywanie się, nadużycia API — jakie są zalecenia minimalizacji?
• Logi, dowody, dane audytowe
  • Jakie logi możecie udostępnić dotyczące naszej organizacji: logi logowań, audyt admina, zdarzenia API, eksporty, zmiany konfiguracji, zdarzenia uprawnień?
  • Jaki jest zakres czasowy dostępnych logów i ich granularność?
  • Czy możecie dostarczyć potwierdzenie integralności (np. sposób generowania, podpis, suma kontrolna) lub opis łańcucha przechowywania po stronie vendora?
  • Czy incydent wpłynął na kompletność logów (tak/nie/niepewne)?
• RODO / rola procesora
  • Czy działacie jako podmiot przetwarzający w ramach naszej umowy (tak/nie)? Jeśli tak: czy formalnie kwalifikujecie zdarzenie jako „naruszenie ochrony danych osobowych” (tak/nie/analiza trwa)?
  • Czy przekazujecie zawiadomienie naruszeniowe w trybie umownym/RODO — kiedy i w jakiej formie?
  • Czy doszło do naruszenia poufności, integralności lub dostępności danych — które aspekty i w jakim zakresie?
  • Czy dane były szyfrowane w spoczynku i w tranzycie (tak/nie)? Jeśli tak: czy klucze szyfrujące mogły zostać naruszone (tak/nie/niepewne)?
  • Czy doszło do transferu danych poza EOG lub udziału dalszych podmiotów przetwarzających w ramach incydentu (tak/nie; jeśli tak — które kategorie podmiotów i lokalizacje)?
• Komunikacja i odpowiedzialność
  • Kto jest właścicielem komunikacji do klientów (wasza organizacja / klient) i jakie są rekomendowane treści minimalne?
  • Czy planujecie publiczne oświadczenie lub wpis w status page (tak/nie; kiedy)?
  • Jakie są wasze kolejne kamienie milowe: raport wstępny, raport końcowy, aktualizacje cykliczne?
  • Kanał kontaktu 24/7 oraz osoba odpowiedzialna za współpracę przy incydencie (funkcja, nie dane osobowe).
• Zapewnienia i naprawa
  • Czy incydent może się powtórzyć w tej samej formie bez dodatkowych działań (tak/nie)?
  • Jakie trwałe działania naprawcze planujecie (kategorie, bez wchodzenia w szczegóły techniczne)?
  • Czy oferujecie wsparcie w analizie (np. konsultacje, dodatkowe logi, wskazówki hardeningu) i w jakim czasie?

8.2. Wzór krótkiej notatki dla zarządu (maks. 1 strona)

Instrukcja użycia: notatka ma umożliwić szybkie decyzje zarządcze, bez przeciążania szczegółami technicznymi. Uzupełnij tylko fakty potwierdzone; elementy niepewne oznacz jako „w trakcie weryfikacji”.

Tytuł: Incydent bezpieczeństwa u dostawcy SaaS — notatka dla Zarządu

• Data/godzina: [DD-MM-RRRR, HH:MM] (strefa czasowa)
• Źródło informacji: [vendor / monitoring / inny kanał]
• Status: [aktywne / opanowane / w trakcie analizy]

1) Co się stało (1–2 zdania):
[Krótki opis zdarzenia i kontekstu: naruszenie u dostawcy SaaS, potencjalny wpływ na nasze dane/usługi.]

2) Co wiemy na pewno (fakty):

• [Okres zdarzenia, jeśli potwierdzony]
• [Dotknięte usługi/obszary]
• [Czy nasz tenant/dane: tak/nie/niepewne]
• [Czy dostęp/eksfiltracja: tak/nie/niepewne]

3) Co jest w trakcie ustalania (niewiadome):

• [Zakres danych i liczba osób/rekordów]
• [Dokładny wektor/IOCs]
• [Czy incydent kwalifikuje się jako naruszenie danych osobowych i czy wymaga zgłoszeń]

4) Potencjalny wpływ na biznes:

• Operacyjny: [np. ryzyko przerw w integracjach, ograniczenia dostępu, dodatkowe prace]
• Prawny/regulacyjny: [np. ryzyko obowiązków notyfikacyjnych, ryzyko roszczeń]
• Reputacyjny: [np. ryzyko zapytań klientów/mediów, potrzeba komunikatu]

5) Działania podjęte do tej pory (najważniejsze):

• [np. wstrzymanie integracji / rotacja kluczy / zabezpieczenie logów / kontakt z vendorem]

6) Decyzje i wsparcie potrzebne od Zarządu (konkret):

• [Zatwierdzenie priorytetu i zasobów (IT/bezpieczeństwo/prawne)]
• [Zgoda na działania ograniczające ryzyko biznesowe, np. czasowe wyłączenia]
• [Wskazanie osoby do akceptacji komunikacji zewnętrznej, jeśli potrzebne]
• [Budżet/zakup usług wsparcia, jeśli konieczne (np. forensics/monitoring)]

7) Kolejny termin aktualizacji: [DD-MM-RRRR, HH:MM] oraz właściciel aktualizacji: [funkcja/rola]

SPSS czy RStudio do analiz ankiet NPS/CSAT? Porównanie workflow i raportowania 25 marca 2026

AI w rekrutacji, ocenie pracowników i scoringu – co mówi AI Act? 23 marca 2026