Skanuj Firmę, Audyt bezpieczeństwa i zgodności firmy

Ścieżka audytu (audit trail): co to jest i jak ją prowadzić

Marek Porycki — Sat, 26 Sep 2026 00:38:35 +0200

Fraza "ścieżka audytu" ma w polskich wyszukiwaniach dwa znaczenia. Pierwsze pochodzi z funduszy europejskich, drugie z bezpieczeństwa informacji i księgowości. Mechanizm jest ten sam: niezależna osoba ma móc przejść po śladach od skutku do przyczyny i z powrotem. Poniżej oba konteksty, wymagania prawne i praktyczna instrukcja.

Ścieżka audytu: definicja w dwóch kontekstach

	Systemy IT i dane	Projekty z funduszy UE
Czym jest	zapisy w dziennikach systemów (logach) i historia zmian rekordów	komplet dokumentów i zapisów księgowych dla każdej operacji
Na co odpowiada	kto miał dostęp, co zmienił, kiedy, z jakiego urządzenia, z jakim skutkiem	skąd wziął się wydatek, kto go zatwierdził, jak go rozliczono i zapłacono
Kto jej używa	administrator, audytor, zespół reagowania na incydenty, organ nadzorczy	instytucja zarządzająca, kontrolerzy, audytorzy
Główne przepisy i normy	RODO (rozliczalność), KRI § 20, NIS2 art. 21, ISO/IEC 27001	rozporządzenie (UE) 2021/1060, art. 69 ust. 6, art. 82 i załącznik XIII

Ścieżka audytu w systemach IT

Ścieżka audytu w systemach IT. Zestawienie z tabeli w artykule.

W IT ścieżka audytu to zapis zdarzeń, który pozwala przypisać działanie do konkretnej osoby lub procesu i umiejscowić je w czasie. Polskie przepisy nazywają tę właściwość rozliczalnością. Rozporządzenie Rady Ministrów z 21 maja 2024 r. w sprawie Krajowych Ram Interoperacyjności definiuje rozliczalność jako "właściwość systemu pozwalającą przypisać określone działanie w systemie do osoby fizycznej lub procesu oraz umiejscowić je w czasie" (§ 2 pkt 18).

Co musi być zapisane: minimum z KRI

Rozporządzenie KRI wydano na podstawie ustawy o informatyzacji działalności podmiotów realizujących zadania publiczne. Jego § 20 stanowi, że rozliczalność w systemach teleinformatycznych "podlega wiarygodnemu dokumentowaniu w postaci elektronicznych zapisów w dziennikach systemów (logach)". Obligatoryjnie odnotowuje się działania polegające na dostępie do:

systemu z uprawnieniami administracyjnymi,
konfiguracji systemu, w tym konfiguracji zabezpieczeń,
przetwarzanych w systemach danych podlegających prawnej ochronie w zakresie wymaganym przepisami prawa.

Pozostałe zdarzenia (działania użytkowników bez uprawnień administracyjnych, zdarzenia systemowe bez krytycznego znaczenia, zdarzenia i parametry środowiska) mogą być odnotowywane w zakresie wynikającym z analizy ryzyka. Informacje w dziennikach przechowuje się przez okres wskazany w przepisach odrębnych, a gdy ich brak, przez dwa lata (§ 20 ust. 4). Firma prywatna może traktować te zasady jako gotowy polski punkt odniesienia.

RODO: rozliczalność i bezpieczeństwo

Administrator danych ma być w stanie wykazać przestrzeganie zasad przetwarzania (art. 5 ust. 2 RODO) i stosować środki dobrane do ryzyka, zapewniające m.in. poufność, integralność, dostępność i odporność systemów (art. 32). RODO nie wymienia "logów" z nazwy, ale bez zapisu, kto przeglądał lub zmieniał dane, trudno obronić się przed zarzutem nieuprawnionego dostępu i trudno ocenić, czy doszło do naruszenia, które trzeba zgłosić organowi nadzorczemu, w miarę możliwości w ciągu 72 godzin (art. 33).

NIS2 i akty wykonawcze

Dyrektywa NIS2 (2022/2555) wymaga od podmiotów kluczowych i ważnych środków zarządzania ryzykiem, w tym obsługi incydentu (art. 21 ust. 2 lit. b) oraz polityk i procedur oceny skuteczności tych środków (art. 21 ust. 2 lit. f). Dla części dostawców cyfrowych (m.in. usług chmurowych, centrów przetwarzania danych, usług zarządzanych) rozporządzenie wykonawcze Komisji (UE) 2024/2690 opisuje monitorowanie i rejestrowanie zdarzeń w pkt 3.2 załącznika: rejestrowanie m.in. zdarzeń uwierzytelniania, dostępu uprzywilejowanego i zmian w plikach konfiguracji, ochronę rejestrów przed nieuprawnionymi zmianami i synchronizację źródeł czasu. W Polsce do tego rozporządzenia odsyła art. 8b ust. 1 znowelizowanej ustawy o krajowym systemie cyberbezpieczeństwa.

ISO/IEC 27001:2022

W załączniku A normy za ścieżkę audytu odpowiadają przede wszystkim zabezpieczenia 8.15 (rejestrowanie zdarzeń), 8.16 (monitorowanie działań) i 8.17 (synchronizacja zegarów). Przed audytem certyfikacyjnym warto mieć gotową politykę logowania, dowód, że logi są przeglądane, i przykłady zdarzeń odtworzonych z logów.

Tabela: co logować i po co

Pole zapisu	Przykład	Dlaczego
Kto	identyfikator konta, nie wspólne "admin"	bez tego nie ma rozliczalności
Co	logowanie, odczyt rekordu, eksport, zmiana uprawnień, usunięcie	odróżnia wgląd od modyfikacji
Kiedy	znacznik czasu z synchronizowanego źródła czasu, strefa czasowa	pozwala zestawić logi z różnych systemów
Skąd	adres IP, urządzenie, lokalizacja sesji	pomaga wykryć przejęte konta
Na czym	system, tabela, dokument, identyfikator rekordu	zawęża zakres ewentualnego naruszenia
Wynik	sukces, odmowa, błąd	seria odmów może sygnalizować atak
Stan przed i po	stara i nowa wartość pola (w systemach finansowych i kadrowych)	dowód, kto i co zmienił

Ścieżka audytu w projektach z funduszy UE

W perspektywie 2021-2027 rozporządzenie ogólne (UE) 2021/1060 zobowiązuje państwa członkowskie do dysponowania systemami i procedurami, które zapewniają przechowywanie wszystkich dokumentów wymaganych na potrzeby ścieżki audytu określonych w załączniku XIII (art. 69 ust. 6). Załącznik XIII "Elementy ścieżki audytu" wymienia przy dotacjach m.in. umowę o dofinansowanie, zapisy księgowe wniosków o płatność, dowód płatności na rzecz beneficjenta, dokumentację kontroli i audytów oraz dokumentację weryfikacji zgodności z mającymi zastosowanie przepisami. Przy rozliczaniu kosztów rzeczywistych są to także faktury (lub dokumenty o równoważnej wartości dowodowej), dowód ich zapłaty przez beneficjenta i zapisy księgowe beneficjenta.

Stąd podpowiedzi typu "ścieżka audytu powinna umożliwiać" i "niewystarczająca ścieżka audytu na potrzeby udzielenia zamówienia". To drugie sformułowanie opisuje zamówienie, którego przebiegu nie da się odtworzyć z dokumentacji (brak szacowania wartości, brak dowodu rozeznania rynku, brak protokołu). Jeżeli wydatek okaże się nieprawidłowy, państwo członkowskie stosuje korektę finansową, czyli anuluje całość lub część wsparcia (art. 103 ust. 1 rozporządzenia 2021/1060).

Dokumenty potwierdzające dotyczące operacji przechowuje się przez pięć lat od 31 grudnia roku, w którym instytucja zarządzająca dokonała ostatniej płatności na rzecz beneficjenta (art. 82 ust. 1 rozporządzenia 2021/1060). Wiążący dla beneficjenta jest termin wskazany w umowie o dofinansowanie.

Jak prowadzić ścieżkę audytu: 8 kroków

Spisz systemy i procesy, które jej wymagają. Najpierw te z danymi osobowymi, finansami, kontami administratorów i konfiguracją zabezpieczeń.
Ustal, co logujesz. Minimum z KRI (dostęp administracyjny, konfiguracja, dane chronione), resztę według analizy ryzyka.
Zlikwiduj konta współdzielone. Log z "admin" albo "biuro" nie wskazuje człowieka.
Zsynchronizuj czas. Jedno źródło czasu dla serwerów, urządzeń sieciowych i chmury, bo inaczej zdarzeń z dwóch systemów nie da się ułożyć w kolejności.
Wyślij logi poza system źródłowy. Centralny serwer logów, z prawami tylko do dopisywania; administrator systemu nie powinien móc skasować śladów swojej pracy.
Określ okres przechowywania. Przepisy szczególne, umowa o dofinansowanie, KRI (2 lata, gdy brak innych przepisów), potrzeby dochodzenia roszczeń; zapisz decyzję w polityce.
Przeglądaj, a nie tylko zbieraj. Ustal, kto i jak często przegląda logi oraz które zdarzenia wywołują alarm (np. nadanie uprawnień administratora, masowy eksport).
Testuj odtworzenie. Regularnie, np. raz na kwartał, wybierz zdarzenie i spróbuj odtworzyć je od początku do końca. Podobny test może wykonać audytor.

Jak audytor sprawdza ścieżkę audytu

Typowe podejście to zacząć od końca: wybrać konkretny skutek (zmiana w danych klienta, przelew, nadanie uprawnień, wydatek w projekcie) i poprosić o odtworzenie drogi do źródła. Potem iść w drugą stronę: od dokumentu źródłowego do ujęcia w systemie. Sprawdza się też, czy logi są kompletne w wybranym okresie, czy czas jest spójny między systemami, czy administrator mógł zmienić zapisy i czy ktoś przeglądał logi. Szerszy kontekst: audyt zewnętrzny a wewnętrzny i audyt procedury incydentów 24/72 h.

Najczęstsze błędy

Logi włączone, ale nadpisywane po kilku dniach, bo nikt nie ustawił okresu przechowywania.
Logi przechowywane na tym samym serwerze, który jest chroniony: po włamaniu lub awarii znikają razem z nim.
Wspólne konta administracyjne i wspólne loginy w księgowości.
Brak zapisu odczytów danych, tylko zmian: nie da się ustalić, kto przeglądał dokumentację kadrową.
W projektach UE: dokumentacja wyboru wykonawcy w prywatnej poczcie i brak notatki z szacowania wartości zamówienia.

Najczęstsze pytania

Co to jest ścieżka audytu w prostych słowach?

To ślad, po którym ktoś z zewnątrz może odtworzyć, co się stało: kto, co, kiedy i na jakiej podstawie. W IT tworzą go logi, w projektach unijnych dokumenty od faktury do rozliczenia.

Czy ścieżka audytu i audit trail to to samo?

Tak. Audit trail to termin angielski; polska wersja rozporządzenia 2021/1060 używa określenia "ścieżka audytu". Rozporządzenie KRI mówi o "rozliczalności" i "dziennikach systemów".

Jak długo przechowywać logi?

Tak długo, jak wymagają przepisy szczególne lub umowa. Rozporządzenie KRI przyjmuje dwa lata, gdy brak przepisów odrębnych. Firma prywatna ustala okres w polityce na podstawie ryzyka, obowiązków branżowych i terminów dochodzenia roszczeń.

Czy mała firma musi prowadzić ścieżkę audytu?

Nie ma jednego przepisu z takim nakazem dla każdej firmy. Mała firma przetwarzająca dane osobowe musi jednak umieć wykazać zgodność z RODO (art. 5 ust. 2), a bez podstawowych logów (logowania do poczty, systemu księgowego, systemu obsługi klientów) trudno ustalić skalę naruszenia.

Co oznacza "niewystarczająca ścieżka audytu" w zamówieniach z funduszy UE?

Że z dokumentacji nie da się odtworzyć, jak wybrano wykonawcę i czy zrobiono to zgodnie z zasadami. Jeżeli wydatek okaże się nieprawidłowy, stosuje się korektę finansową, czyli anulowanie całości lub części wsparcia (art. 103 rozporządzenia 2021/1060).

Czy logi zawierają dane osobowe?

Zwykle tak (login, adres IP, czas pracy), więc same logi podlegają RODO: potrzebny jest cel, ograniczony dostęp i okres przechowywania. Monitoring poczty służbowej pracownika wymaga spełnienia warunków z art. 22³ Kodeksu pracy.

Czy ścieżkę audytu sprawdza się podczas audytu RODO i NIS2?

Tak. W audycie RODO jest częścią oceny art. 32 i procedury naruszeń, w audycie NIS2 częścią obsługi incydentów i oceny skuteczności środków, w ISO/IEC 27001 zabezpieczeń 8.15-8.17.

Źródła i podstawa prawna

Rozporządzenie Rady Ministrów z dnia 21 maja 2024 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U. 2024 poz. 773), § 2 pkt 18 i § 20: dziennikustaw.gov.pl
Rozporządzenie (UE) 2016/679 (RODO), art. 5 ust. 2, art. 32, art. 33: eur-lex.europa.eu, CELEX 32016R0679
Dyrektywa (UE) 2022/2555 (NIS2), art. 21: eur-lex.europa.eu, CELEX 32022L2555
Rozporządzenie wykonawcze Komisji (UE) 2024/2690, załącznik pkt 3.2: eur-lex.europa.eu, CELEX 32024R2690
Ustawa o krajowym systemie cyberbezpieczeństwa, art. 8b ust. 1 w brzmieniu nadanym ustawą z 23 stycznia 2026 (Dz.U. 2026 poz. 252): dziennikustaw.gov.pl
Rozporządzenie (UE) 2021/1060 (rozporządzenie ogólne dla funduszy 2021-2027), art. 69 ust. 6, art. 82 ust. 1, art. 103 ust. 1 i załącznik XIII "Elementy ścieżki audytu": eur-lex.europa.eu, CELEX 32021R1060
Kodeks pracy, art. 22³, tekst jednolity Dz.U. 2026 poz. 1245: dziennikustaw.gov.pl
ISO/IEC 27001:2022, załącznik A, zabezpieczenia 8.15, 8.16, 8.17: iso.org; opis zabezpieczeń na stronie DQS: dqsglobal.com

Ile kosztuje audyt bezpieczeństwa firmy, ceny rynkowe 2026 i co na nie wpływa

Marek Porycki — Thu, 10 Sep 2026 21:20:26 +0000

Pytanie o cenę audytu pada zwykle po jednym z trzech zdarzeń: kontrahent przysłał ankietę bezpieczeństwa, zarząd przeczytał o karach z dyrektywy NIS2, albo w firmie zdarzył się incydent. W każdym z tych przypadków decyzja jest pilna, a rynek odpowiada widełkami od tysiąca pięciuset do kilkudziesięciu tysięcy złotych za usługę nazywaną tak samo. Ta rozpiętość nie bierze się z chciwości, tylko z tego, że pod jednym słowem kryją się co najmniej trzy różne prace.

Krótka odpowiedź

Stawki publikowane otwarcie przez polskich dostawców we wrześniu 2026 układają się mniej więcej tak:

Rodzaj audytu	Typowe widełki	Co dostajesz
Audyt RODO dla małej firmy	1 500 do 5 000 zł	Przegląd dokumentacji, rejestr czynności, klauzule, raport z rekomendacjami
Audyt RODO dla średniej firmy	5 000 do 20 000 zł	To co wyżej plus wywiady z właścicielami procesów, ocena ryzyka, ocena skutków dla wybranych procesów
Audyt zgodności z NIS2 lub ustawą o krajowym systemie cyberbezpieczeństwa	5 900 do 30 000 zł	Analiza luk wobec wymagań, ocena łańcucha dostaw, plan wdrożenia z harmonogramem
Techniczny audyt bezpieczeństwa IT	3 500 do 25 000 zł	Skan podatności, przegląd konfiguracji, kontrola dostępu, kopie zapasowe, raport techniczny
Test penetracyjny aplikacji lub sieci	8 000 do 60 000 zł	Kontrolowany atak, dowód wykorzystania podatności, retest po naprawie

Dolne granice dotyczą firm do dziesięciu osób z jedną lokalizacją i prostym środowiskiem. Górne dotyczą organizacji wielooddziałowych, z produkcją, z własnym oprogramowaniem albo z obowiązkami sektorowymi.

Siedem rzeczy, które realnie windują wycenę

Liczba procesów przetwarzania, nie liczba pracowników. Firma z pięćdziesięcioma osobami i trzema procesami jest tańsza w audycie niż dziesięcioosobowa agencja marketingowa, która przetwarza dane klientów swoich klientów w dwudziestu narzędziach.

Liczba systemów i integracji. Każdy system to osobna konfiguracja uprawnień, osobne kopie zapasowe i osobna umowa powierzenia. Piętnaście narzędzi w chmurze to piętnaście osobnych sprawdzeń, nawet jeżeli każde zajmuje pół godziny.

Łańcuch dostaw. Wymagania NIS2 obejmują dostawców. Audyt, który obejmuje weryfikację dwudziestu kontrahentów, to inna praca niż audyt samej organizacji.

Czy potrzebny jest dowód, czy wystarczy opinia. Przegląd dokumentów jest tani. Weryfikacja, czy zapisany proces faktycznie działa, wymaga wywiadów, próbkowania i testów, i kosztuje wielokrotnie więcej.

Termin. Audyt na przyszły tydzień, bo klient wstrzymał umowę, kosztuje więcej niż audyt zaplanowany na kwartał.

Forma raportu. Raport dla zarządu, raport dla działu IT i dokumentacja do przedstawienia kontrahentowi to trzy różne dokumenty. Część dostawców liczy je osobno.

Retest. Sprawdzenie po wdrożeniu rekomendacji bywa doliczane, a bez niego audyt kończy się listą zadań, której nikt nie odhacza.

Trzy audyty, które ludzie mylą

Audyt RODO odpowiada na pytanie, czy przetwarzanie danych osobowych ma podstawę prawną, czy jest udokumentowane i czy zabezpieczenia są adekwatne do ryzyka. Sprawdza dokumenty, procesy i umowy. Nie sprawdza, czy serwer ma aktualne poprawki.

Audyt zgodności z NIS2 odpowiada na pytanie, czy organizacja spełnia wymagania dotyczące zarządzania ryzykiem, zgłaszania incydentów, ciągłości działania i bezpieczeństwa łańcucha dostaw. Dotyczy podmiotów kluczowych i ważnych, a odpowiedzialność spoczywa na kierownictwie osobiście.

Techniczny audyt bezpieczeństwa odpowiada na pytanie, czy da się wejść. Skanuje podatności, sprawdza konfiguracje, uprawnienia, uwierzytelnianie wieloskładnikowe i kopie zapasowe.

Firmy najczęściej kupują pierwszy, potrzebują trzeciego, a obowiązek mają z drugiego. Wycena, która nie mówi wprost, który to z tych trzech, jest niemożliwa do porównania z inną.

Audyt zerowy, czyli od czego zacząć taniej

Zanim zamówisz pełne badanie, sensowniej jest zrobić rozpoznanie: ustalić, czy firma w ogóle podlega pod NIS2, jakie ma procesy i gdzie są największe luki. Taki audyt zerowy zajmuje od jednego do trzech dni i kosztuje ułamek pełnej usługi, a jego wynikiem jest decyzja o zakresie właściwego audytu. Bez niego łatwo kupić badanie szersze albo węższe niż potrzeba.

Darmową wersję tego rozpoznania można zrobić samodzielnie: skan bezpieczeństwa firmy zadaje pytania, na które i tak odpowiesz każdemu audytorowi, i pokazuje, które obszary wymagają uwagi w pierwszej kolejności.

Czego wymagać w ofercie, żeby dało się ją porównać

Uczciwa wycena zawiera sześć elementów. Brak któregokolwiek oznacza, że porównujesz jabłka z gruszkami.

Zakres wyrażony w obiektach, nie w słowach. Ile procesów, ile systemów, ile lokalizacji, ilu dostawców.
Metoda. Czy to przegląd dokumentów, wywiady, testy techniczne, czy kombinacja. Jaka norma albo jakie przepisy stanowią punkt odniesienia.
Pracochłonność w dniach i skład zespołu. Audyt za trzy tysiące, w którym pracuje jedna osoba przez pół dnia, to nie jest audyt.
Postać wyniku. Ile raportów, dla kogo, czy jest wersja dla zarządu, czy rekomendacje mają priorytety i szacunek kosztu wdrożenia.
Co nie wchodzi w cenę. Wdrożenie rekomendacji, dokumentacja, szkolenie pracowników i retest zwykle są osobno.
Odpowiedzialność. Czy audytor podpisuje raport imiennie, czy odpowiada za wnioski, jakie ma ubezpieczenie.

Czerwone flagi w tanich ofertach

Cena poniżej dolnej granicy widełek zwykle oznacza jedną z czterech rzeczy: raport wygenerowany z szablonu bez kontaktu z firmą, sam skan automatyczny nazwany audytem, usługę wstępną, po której dopiero przychodzi właściwa wycena, albo przygotowanie do sprzedaży czegoś innego. Żadna z tych rzeczy nie jest sama w sobie oszustwem, ale żadna nie jest też audytem, na który powoła się kontrahent albo organ nadzoru.

Osobna kategoria to darmowy audyt jako wabik. Bezpłatne rozpoznanie ma sens i sam je proponuję, natomiast bezpłatny pełny audyt nie istnieje, bo to od trzech do kilkunastu dni pracy specjalisty.

Ile to trwa

Zakres	Czas kalendarzowy	Pracochłonność
Audyt zerowy, rozpoznanie	2 do 5 dni	1 do 3 dni roboczych
Audyt RODO, mała firma	2 do 3 tygodnie	3 do 6 dni roboczych
Audyt NIS2, średnia firma	4 do 8 tygodni	10 do 20 dni roboczych
Techniczny audyt IT	2 do 4 tygodnie	5 do 12 dni roboczych

Czas kalendarzowy jest dłuższy niż pracochłonność, bo audyt czeka na dostęp do systemów, na terminy wywiadów i na dokumenty od dostawców. To najczęstsza przyczyna opóźnień i zwykle leży po stronie badanej firmy, nie audytora.

Wzór zapytania ofertowego

Skopiuj, uzupełnij i wyślij do trzech dostawców. Oferty staną się porównywalne.

Zwracamy się z prośbą o wycenę audytu w zakresie: (RODO / zgodność z NIS2 i ustawą o krajowym systemie cyberbezpieczeństwa / techniczne bezpieczeństwo IT).

Dane organizacji: branża (…), liczba pracowników (…), liczba lokalizacji (…), liczba kluczowych systemów (…), liczba dostawców przetwarzających nasze dane (…), własne oprogramowanie: (tak / nie).

Powód audytu: (wymóg kontrahenta / przygotowanie do obowiązków NIS2 / incydent / przegląd cykliczny).

Prosimy o podanie w ofercie: zakresu w liczbie procesów i systemów, metody pracy i podstawy odniesienia, pracochłonności w dniach oraz składu zespołu, postaci raportu wraz z odbiorcami, pozycji wyłączonych z ceny, terminu realizacji oraz warunków retestu.

Termin nadsyłania ofert: (…). Kryteria wyboru: (cena / doświadczenie w branży / termin).

Najczęstsze pytania

Czy audyt RODO i audyt NIS2 można połączyć? Tak, i zwykle się opłaca. Obszary wspólne to zarządzanie ryzykiem, kontrola dostępu, obsługa incydentów, kopie zapasowe i umowy z dostawcami. Połączone badanie kosztuje mniej niż suma dwóch osobnych, zwykle od piętnastu do trzydziestu procent taniej.

Czy potrzebujemy audytu, jeżeli mamy inspektora ochrony danych? Inspektor monitoruje zgodność na bieżąco, ale ocenia własną organizację. Audyt zewnętrzny daje spojrzenie z zewnątrz i dokument, którym można się posłużyć wobec kontrahenta albo organu. Te dwie rzeczy się nie zastępują.

Co jeżeli audyt wykaże poważne braki? Raport jest dokumentem wewnętrznym i nie trafia do żadnego organu. Wykazanie braków przed kontrolą jest korzystne: świadczy o działaniu w dobrej wierze i daje czas na naprawę. Ukrycie problemu przed samym sobą nie usuwa problemu.

Czy mały sklep internetowy potrzebuje audytu NIS2? Prawdopodobnie nie, bo obowiązki dotyczą podmiotów kluczowych i ważnych z określonych sektorów i powyżej określonej wielkości. Prawdopodobnie natomiast podlega pod RODO i pod wymagania własnych dostawców płatności. Ustalenie tego jest dokładnie zadaniem audytu zerowego.

Ile kosztuje sam raport, bez wdrożenia? Raport jest zawsze częścią audytu i nie kupuje się go osobno. Osobno kupuje się wdrożenie rekomendacji, a jego koszt zależy od tego, ile z nich firma wykona sama.

Audyt incydentów 24/72h, procedura reagowania, RODO + NIS2 zharmonizowane

Marek Porycki — Sat, 05 Sep 2026 20:04:26 +0000

W 2026 roku polska średnia firma stała w punkcie, w którym jeden poważny incydent cyberbezpieczeństwa może aktywować trzy odrębne ścieżki obowiązkowego zgłaszania: do UODO w terminie 72 godzin (RODO art. 33), do polskiego CSIRT-u w terminach 24h/72h/1 miesiąc (NIS2 art. 23, jeśli firma jest podmiotem kluczowym lub istotnym) oraz potencjalnie do regulatorów sektorowych (KNF, URE, UKE, MZ). Trzy reżimy, trzy zakresy informacji, trzy timing’i, trzy formaty. Wszystko w sytuacji, gdy zarząd firmy próbuje jeszcze zrozumieć, co się stało.

Audyt zdolności reagowania na incydenty jest przewodnik’m w audycie holistycznym, bo łączy ze sobą obszary, które na papierze są odrębne: bezpieczeństwo (NIS2 art. 21(2)(b)), ciągłość działania (NIS2 art. 21(2)(c)), zarządzanie ryzykiem (RODO art. 32), procedury zgłaszania (RODO art. 33 + NIS2 art. 23). W rzeczywistości operacyjnej są jednym pipeline’em, którego nie da się ocenić w częściach.

Ten tekst jest pełną metodyką audytu zharmonizowanego pipeline’u incydentowego. Pokazuje, jak audytor weryfikuje gotowość firmy do obsłużenia incydentu kompleksowo, od wykrycia, przez klasyfikację (czy jest naruszeniem RODO, czy podlega NIS2, czy oba), procedury eskalacji, zgłoszenia regulatorom, komunikację z poszkodowanymi, dokumentację post-incident.

Dwa reżimy zgłaszania, co i kiedy

RODO art. 33, zgłoszenie do UODO. Termin: 72 godziny od stwierdzenia naruszenia. Próg: każde naruszenie ochrony danych, chyba że jest mało prawdopodobne, aby skutkowało ryzykiem naruszenia praw lub wolności osób fizycznych. Format: formularz UODO + opis incydentu, kategorii danych, liczby poszkodowanych, prawdopodobnych konsekwencji, środków zaradczych.

RODO art. 34, komunikacja z poszkodowanymi. Termin: bez zbędnej zwłoki, jeśli naruszenie powoduje wysokie ryzyko. Format: jasna, prosta informacja w języku zrozumiałym, z opisem konsekwencji i działań.

NIS2 art. 23, zgłoszenie do CSIRT-u. Trzy terminy kaskadowe:

24 godziny: wczesne ostrzeżenie (early warning) z podstawowymi informacjami o tym, że nastąpił poważny incydent
72 godziny: zgłoszenie incydentu z bardziej szczegółową oceną i zaktualizowaną informacją
1 miesiąc: raport końcowy z opisem przyczyn źródłowych, środków łagodzących i lessons learned

W Polsce zgłoszenia trafiają do właściwego CSIRT-u sektorowego (zwykle CSIRT NASK dla większości sektorów, CSIRT GOV.PL dla podmiotów publicznych, CSIRT MON dla sektora obronnego, sektorowe CSIRT-y dla finansów, energii, transportu).

Kluczowa pułapka. Jeden incydent może aktywować oba reżimy. Ransomware na bazę klientów to: (a) naruszenie ochrony danych osobowych, RODO art. 33, (b) poważny incydent cyberbezpieczeństwa, NIS2 art. 23. Firma musi w 24 godziny zgłosić CSIRT (NIS2 early warning), w 72 godziny zgłosić UODO i zaktualizować CSIRT, w miesiąc dosłać raport końcowy do CSIRT. Trzy odrębne dokumenty, trzy odrębne narracje, ale wszystko z tego samego zespołu pracującego pod presją.

Audyt sprawdza, czy firma to wszystko rozumie i ma procedury obsłużenia kaskady terminów.

Klasyfikacja incydentu, pierwszy test audytu

Pierwszy test, jaki wykonuje audytor: czy firma ma jasne kryteria klasyfikacji incydentu. Bez tego, każda decyzja eskalacyjna jest improwizacją.

Kryteria RODO (czy jest “naruszenie ochrony danych osobowych” w rozumieniu art. 4 pkt 12):

Naruszenie poufności: nieuprawniony dostęp lub ujawnienie
Naruszenie integralności: nieuprawniona modyfikacja
Naruszenie dostępności: utrata, zniszczenie, niedostępność

Każdy z trzech wymaga oceny: czy generuje ryzyko dla praw i wolności osób fizycznych. Skala oceny zwykle 3-poziomowa: brak ryzyka (nie zgłaszamy), ryzyko (zgłaszamy UODO), wysokie ryzyko (zgłaszamy UODO + informujemy poszkodowanych).

Kryteria NIS2 (czy jest “poważny incydent” w rozumieniu dyrektywy):

Według art. 23 ust. 3, incydent jest poważny, jeśli:

spowodował poważne zakłócenie operacyjne usług lub straty finansowe dla podmiotu, lub
wpłynął lub może wpłynąć na inne osoby fizyczne lub prawne przez powodowanie znaczących szkód materialnych lub niematerialnych

Rozporządzenie wykonawcze KE (2024/2690) doprecyzowuje progi dla różnych sektorów. Dla średniej firmy z sektora cyfrowego “poważny” zaczyna się typowo przy: utracie dostępności usługi krytycznej na ponad 1 godzinę, ekspozycji danych wrażliwych powyżej 1000 rekordów, ataku ransomware z paraliżem operacyjnym, naruszeniu integralności systemu krytycznego.

Co audytor sprawdza. Czy firma ma udokumentowaną matrycę klasyfikacji łączącą oba reżimy. Idealny format:

Scenariusz	RODO art. 33?	NIS2 art. 23?	Działania
Ransomware bez ujawnienia danych	NIE (brak naruszenia danych)	TAK (zakłócenie operacyjne)	NIS2 CSIRT 24h + dokumentacja
Phishing z eksfiltracją 5000 rekordów	TAK	TAK (jeśli podmiot kluczowy/istotny)	RODO UODO 72h + NIS2 CSIRT 24h + informacja osób
DDoS bez ujawnienia danych	NIE	TAK (jeśli utrata dostępności)	NIS2 CSIRT 24h
Błąd konfiguracji ujawnia 50 rekordów	TAK (potencjalne ryzyko)	NIE (zwykle nie spełnia progu poważnego)	RODO UODO 72h
Insider eksfiltrował 1 plik z 3 rekordami	TAK	NIE	RODO UODO 72h (zwykle bez powiadamiania osób)
Wyciek MFA tokenów administratora	TAK (potencjalne)	TAK (jeśli krytyczny dostęp)	Oba reżimy

Bez takiej matrycy zespoły improwizują pod presją czasu, i albo zgłaszają nadmiarowo (generując niepotrzebne procedury kontrolne), albo nie zgłaszają obowiązkowych incydentów.

Procedura reagowania, siedem faz

Audytor weryfikuje pełen cykl reagowania w siedmiu fazach. Dla każdej fazy: dowody (dokumenty, raporty PIR), wywiady (z osobami z zespołu reagowania), testy techniczne (tabletop exercise).

Faza 1: Wykrycie. Skąd firma wie, że jest incydent? Źródła: monitoring (SIEM, EDR, IDS/IPS), alerty użytkowników, alerty zewnętrzne (CSIRT, dostawcy, klienci), audyty post-fakto. Audyt sprawdza średni MTTD (Mean Time To Detect), dla incydentów wykrytych w 12 miesiącach. Cel: minuty, nie godziny. Branża pokazuje, że MTTD w średnich firmach polskich jest zwykle 8-96 godzin, co jest poniżej standardu 2026.

Faza 2: Triage i klasyfikacja. Co to za incydent? Jaka kategoria, jaki poziom, jakie reżimy? Audyt sprawdza: dokumentacja matrycy klasyfikacji, lista osób uprawnionych do klasyfikacji, czas od wykrycia do klasyfikacji. Cel: 1-4 godziny.

Faza 3: Powiadomienie wewnętrzne. Kto musi wiedzieć? Zarząd, IOD, prawni, IT, komunikacja, ubezpieczyciel, zewnętrzny SOC/forensik. Audyt sprawdza: lista kontaktów z aktualną kompletnością, kanały komunikacji (poza tym, który może być skompromitowany, np. e-mail firmowy w przypadku ransomware), procedury eskalacyjne dla nocy/weekendów.

Faza 4: Kontener i mitigacja. Powstrzymanie rozprzestrzeniania. Audyt sprawdza: runbooki dla typowych scenariuszy, lista decyzji odwracalnych vs. nieodwracalnych (czy zespół wie, że odpięcie serwerów może zniszczyć dowody forensykowe), procedury komunikacji z forensykami zewnętrznymi.

Faza 5: Zgłoszenia regulatorom. RODO art. 33 (UODO 72h), NIS2 art. 23 (CSIRT 24h/72h/1m), regulatorzy sektorowi. Audyt sprawdza: szablony zgłoszeń, lista kontaktów regulatorów, procedury akceptacji treści zgłoszenia (kto podpisuje), retencja dokumentacji zgłoszeń.

Faza 6: Komunikacja zewnętrzna. Poszkodowani (art. 34 RODO), klienci, partnerzy, media, akcjonariusze. Audyt sprawdza: szablony komunikatów, plan PR/IR, decyzje kto kogo informuje i w jakiej kolejności.

Faza 7: Post-incident review (PIR). Co się stało, co działało, co nie, co zmienić. Audyt sprawdza: PIR-y z ostatnich 12 miesięcy, lista action items z PIR-ów, status ich realizacji.

Symulacja stołowa, kluczowy test audytu

Audytor nie ocenia gotowości firmy tylko z dokumentów. Najlepszy test to symulacja stołowa (tabletop exercise), prowadzi scenariusz, obserwuje, jak zespół reaguje.

Typowy scenariusz dla średniej firmy:

10 maja 2026, godzina 02:14. Monitoring SOC zgłasza alert: 80 stacji w dziale księgowości oraz serwer plików F:\KSIEGOWOSC są zaszyfrowane. W każdej zaszyfrowanej lokalizacji notatka: “Twoje pliki zostały zaszyfrowane. Aby je odzyskać, skontaktuj się z [email_address] w ciągu 72 godzin. Cena: 800 000 EUR w bitcoin. Niezapłacenie skutkuje publikacją danych. Mamy 47 GB danych z systemu kadrowego, finansowego oraz bazy klientów (12 400 osób)”.

Pytania symulacyjne:

Kto jest powiadamiany w ciągu pierwszej godziny? W jakiej kolejności? Jakimi kanałami?

Kto decyduje, czy zapłacić okup?

Czy zgłaszamy do UODO? Kiedy? Kto przygotowuje treść?

Czy zgłaszamy do CSIRT? Kiedy?

Czy odpinamy zaszyfrowane stacje od sieci, czy zostawiamy dla forensyki?

Czy istnieje aktualny backup tych danych? Kiedy ostatnio testowany?

Czy zatrudniamy zewnętrznego forensyka? Mamy go zakontraktowanego prewencyjnie?

Co mówimy klientom? Kiedy? Kto pisze?

Czy informujemy media proaktywnie czy reaktywnie?

Co mówimy pracownikom? Kiedy?

Audytor obserwuje przez 2-3 godziny dyskusję zespołu (członkowie zarządu, CISO, IOD, dyrektor IT, dyrektor komunikacji, prawnik). Z dyskusji wynika ocena dojrzałości w obszarze reagowania.

Częste obserwacje z takich symulacji w polskich firmach.

Pierwsze 60 minut traci się na ustalanie, kto kogo powiadomi. Lista kontaktów jest, ale w intranecie do którego nie ma dostępu z domu.
Decyzja “czy zapłacić” wisi w powietrzu, bo nie ma jasnej linii w zarządzie.
IOD jest informowany “po sprawie”, a powinien być w godzinie 1.
Nie ma pewności, czy backup pomoże, bo nie był testowany od 18 miesięcy.
Komunikacja z klientami jest improwizowana, bo nie ma szablonu.
Forensik jest “tym, którego kiedyś znaliśmy”, nie aktualnym partnerem.

Każda z tych obserwacji jest ustaleniem audytowym z jasną rekomendacją korygującą.

Format zgłoszenia do UODO (art. 33)

UODO udostępnia formularz online. Audytor sprawdza, czy firma ma wewnętrzny szablon przygotowany, gotowy do wypełnienia w trybie awaryjnym. Szablon zawiera:

Dane administratora (nazwa, adres, NIP, kontakt do IOD)
Data i godzina stwierdzenia naruszenia
Charakter naruszenia (poufność / integralność / dostępność / kombinacja)
Kategorie i przybliżona liczba podmiotów danych
Kategorie i przybliżona liczba rekordów danych
Prawdopodobne konsekwencje naruszenia
Środki zastosowane lub proponowane w celu zminimalizowania ewentualnych negatywnych skutków
Wskazanie, czy planowane jest poinformowanie osób (art. 34)

Tip dla audytu: w prawdziwym incydencie liczba poszkodowanych może być nieznana w 72h. RODO dopuszcza zgłoszenia uzupełnione, pierwsze zgłoszenie w 72h z dostępnymi informacjami, aktualizacja w kolejnych dniach. Zespół audytowy musi to wiedzieć, żeby nie odkładać zgłoszenia czekając na “pełną informację”.

Format zgłoszenia do CSIRT (NIS2 art. 23)

CSIRT (NASK lub sektorowy) ma własny portal zgłoszeniowy. Trzy formaty kaskadowe:

Early warning (24h): typowo 1-2 strony tekstu, co się stało, kiedy, jaki potencjalny wpływ, czy podejrzewa się działanie złośliwe, czy może mieć skutki transgraniczne.

Zgłoszenie incydentu (72h): rozszerzona ocena ze wstępną analizą przyczyn, wykazem dotkniętych systemów i usług, działań podjętych, działań planowanych.

Raport końcowy (1 miesiąc): pełna analiza root cause, lista wszystkich środków podjętych, lista lessons learned, plan korygujący długoterminowy.

Audytor sprawdza, czy firma ma szablony wszystkich trzech formatów oraz czy w zespole jest osoba odpowiedzialna za zewnętrzne komunikaty (kto pisze, kto akceptuje, kto wysyła).

Jeśli przygotowujesz lub odbierasz audyt gotowości incydentowej i potrzebujesz szablonu wszystkich tych dokumentów (zgłoszenia UODO + early warning CSIRT + zgłoszenie incydentu CSIRT + raport końcowy CSIRT + szablon komunikatu do poszkodowanych z art. 34), warto dołączyć do newslettera skanujfirme.pl, przesyłamy pakiet w DOCX z polami do uzupełnienia. To narzędzie minimalizuje ryzyko, że zespół pod presją zapomni o jakimś elemencie.

Macierz dojrzałości pipeline’u incydentowego

Po przejściu wszystkich siedmiu faz audytor składa macierz oceny zharmonizowanego pipeline’u:

Element pipeline’u	Aktualna dojrzałość	Cel	Luka
Matryca klasyfikacji RODO+NIS2	1	3	2
Wykrycie (MTTD)	2	3	1
Triage i klasyfikacja	1	3	2
Powiadomienie wewnętrzne	2	3	1
Runbooki dla typowych scenariuszy	1	3	2
Szablony zgłoszeń UODO + CSIRT	1	3	2
Szablony komunikacji zewnętrznej	1	3	2
Symulacje (regularność, jakość)	0	3	3
PIR i implementacja lessons learned	1	3	2

Macierz jest natychmiast czytelna dla zarządu, pokazuje priorytety inwestycyjne. Większość polskich firm średnich jest na poziomie 1 w większości elementów, z zerem w symulacjach.

Format ustaleń w raporcie audytu pipeline’u incydentowego

Przykład typowego ustalenia:

Ustalenie INC-02 (klasyfikacja: krytyczne): Firma nie ma szablonu zgłoszenia incydentu do CSIRT zgodnego z NIS2 art. 23 oraz nie ma listy kontaktów do właściwego CSIRT-u sektorowego. Termin 24h na early warning nie jest osiągalny przy istniejącym przygotowaniu.

Dowody: (1) Wywiad z CISO i IOD, brak świadomości formatu i ścieżki CSIRT; (2) Brak szablonu w archiwum dokumentów; (3) Brak osoby wskazanej jako odpowiedzialnej za zgłoszenia NIS2.

Ryzyko prawne: Naruszenie NIS2 art. 23 ust. 4. W przypadku poważnego incydentu, kara administracyjna do 10 mln EUR lub 2% obrotu (podmiot kluczowy) lub do 7 mln EUR lub 1,4% obrotu (podmiot istotny). Plus reputacyjna ekspozycja związana z niedotrzymaniem terminu komunikacji.

Rekomendacja korygująca: (1) Identyfikacja właściwego CSIRT-u sektorowego (w 7 dni); (2) Przygotowanie szablonów early warning + zgłoszenie 72h + raport końcowy 1m (w 14 dni); (3) Wyznaczenie osoby odpowiedzialnej w organizacji (w 7 dni); (4) Tabletop exercise testujący ścieżkę w pełnym łańcuchu (w 30 dni). Odpowiedzialny: CISO + IOD wspólnie.

Trzy pytania kontrolne dla zarządu przed audytem pipeline’u incydentowego

Pierwsze. Czy wiemy, na które reżimy (RODO, NIS2, sektorowe) podlegamy zgłaszaniu incydentów? Jeśli nie ma pewności, jakiekolwiek planowanie procedur jest spekulacją.

Drugie. Kiedy ostatnio przeprowadziliśmy tabletop exercise z pełnym łańcuchem reagowania? Jeśli odpowiedź to “nigdy” lub “tak dawno, że nie pamiętamy”, pipeline jest teoretyczny, niezweryfikowany.

Trzecie. Kto budzi członka zarządu o 3:00 w nocy? Konkretne imię i nazwisko, telefon prywatny. Bez tego ścieżka eskalacyjna ma dziurę w najgorszym momencie.

Esencja

Pipeline reagowania na incydenty 2026 jest zharmonizowany między RODO art. 33 (zgłoszenie do UODO 72h + komunikacja z poszkodowanymi art. 34) a NIS2 art. 23 (zgłoszenie do CSIRT 24h/72h/1m). Jeden incydent może aktywować oba reżimy. Audyt sprawdza zdolność firmy do obsłużenia kaskady terminów pod presją.

Klasyfikacja incydentu jest punktem krytycznym. Bez matrycy łączącej oba reżimy zespoły improwizują, co skutkuje albo nadmiernymi zgłoszeniami (generującymi własne ryzyko), albo pominięciem obowiązkowego. Matryca musi być prosta, jasna, kompletna i znana zespołowi reagowania.

Siedem faz pipeline’u, wykrycie, triage, powiadomienie, kontener, zgłoszenia regulatorom, komunikacja zewnętrzna, PIR, wymaga różnych narzędzi i kompetencji. Audyt sprawdza każdą fazę osobno: dowody (dokumenty), wywiady (z zespołem), testy techniczne (tabletop exercise jako kluczowy test gotowości realnej).

Symulacja stołowa jest najlepszym testem audytu. W 2-3 godziny ujawnia luki, których dokumenty nie pokazują: kto budzi kogo o 3:00, czy lista kontaktów jest aktualna, czy IOD jest w pierwszej godzinie czy w trzeciej, czy decyzja o płatności okupu jest własnością konkretnego organu, czy backup jest faktycznie sprawny.

Szablony zgłoszeń (UODO + CSIRT trzy formaty + komunikat art. 34 RODO) muszą być gotowe przed incydentem, nie pisane pod presją. Pakiet szablonów + lista kontaktów regulatorów + matryca decyzyjna to minimum operacyjne, jakie audytor oczekuje.

Macierz dojrzałości pipeline’u, 9 elementów ocenianych w skali 0-5, pokazuje zarządowi priorytety inwestycyjne. Większość polskich firm średnich jest dziś na poziomie 1 w większości elementów, z zerem w symulacjach. To jest największa systemowa luka 2026, i prawdopodobnie najbardziej kosztowna, gdy zmieni się statystyka incydentów (statystyka, która od 2022 r. konsekwentnie idzie w górę zarówno globalnie, jak i w Polsce).

Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. (RODO), art. 33, Zgłaszanie naruszenia organowi nadzorczemu, art. 34, Zawiadamianie osoby, której dane dotyczą. https://eur-lex.europa.eu/eli/reg/2016/679/oj
Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (NIS2), art. 23, Obowiązki zgłaszania incydentów. https://eur-lex.europa.eu/eli/dir/2022/2555/oj
Rozporządzenie Wykonawcze Komisji (UE) 2024/2690 z dnia 17 października 2024 r. ustanawiające zasady stosowania dyrektywy (UE) 2022/2555 w odniesieniu do progów istotności dla incydentów. https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
EROD/EDPB (2022). Guidelines 9/2022 on personal data breach notification under GDPR. https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/
EROD/EDPB (2021). Guidelines 01/2021 on Examples regarding Personal Data Breach Notification. https://www.edpb.europa.eu/
UODO. Wytyczne w sprawie zgłaszania naruszeń ochrony danych osobowych, formularz i procedura. https://uodo.gov.pl/pl/138/
NIST SP 800-61 Rev. 2 (2012). Computer Security Incident Handling Guide. National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-61r2
ENISA (2024). Good Practices for Incident Reporting under NIS2. European Union Agency for Cybersecurity. https://www.enisa.europa.eu/publications
CSIRT NASK / CERT Polska. Procedury zgłaszania incydentów. https://csirt.gov.pl/ oraz https://www.cert.pl/
Verizon (2024). Data Breach Investigations Report (DBIR) 2024. https://www.verizon.com/business/resources/reports/dbir/
Polska Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (Dz.U. 2018 poz. 1560 ze zm.), wraz z projektem nowelizacji transponującej NIS2.

Audyt łańcucha dostaw IT, NIS2 art. 21(2)(d), klauzule i due diligence

Marek Porycki — Tue, 01 Sep 2026 16:53:00 +0000

Verizon Data Breach Investigations Report 2024 podaje liczbę, która powinna zmienić budżety bezpieczeństwa każdej średniej polskiej firmy: 62% naruszeń bezpieczeństwa rozpoczyna się od dostawcy. Atak na SolarWinds (2020) skompromitował 18 000 organizacji. Atak na Kaseya VSA (2021) zainfekował 1500 firm przez jednego dostawcę MSP. Atak na MOVEit (2023), 2700 organizacji, w tym instytucje rządowe. To nie są incydenty marginalne, to dominująca kategoria zagrożeń 2024-2026.

NIS2 art. 21 ust. 2 lit. d wprost wymaga “bezpieczeństwa łańcucha dostaw, w tym aspektów bezpieczeństwa dotyczących stosunków między podmiotem a jego bezpośrednimi dostawcami lub usługodawcami”. To nie jest opcjonalne. Dla każdego podmiotu kluczowego lub istotnego, audyt supply chain jest wymogiem regulacyjnym.

Ten tekst jest pełną metodyką audytu łańcucha dostaw IT. Obejmuje cztery obszary: mapowanie i klasyfikację dostawców, due diligence przy on-boardingu, klauzule kontraktowe, monitoring i reakcję na incydenty u dostawców.

Obszar 1: Mapowanie i klasyfikacja dostawców

Najczęstsza luka audytowa: firma nie wie, ilu ma dostawców IT.

Co audytor sprawdza.

Pełna lista dostawców IT (cloud, SaaS, hardware, software vendor, outsourcing, konsultanci, partnerzy integracyjni)
Klasyfikacja per dostawca: krytyczny / istotny / standardowy
Mapa “dostawca → systemy, do których ma dostęp / dane, które przetwarza”
Aktualność listy (data ostatniej aktualizacji)

Kryteria klasyfikacji.

Krytyczny: dostawca, którego niedostępność lub kompromitacja zatrzyma działanie kluczowego procesu biznesowego (np. dostawca cloud hostujący ERP, dostawca CRM, dostawca systemu kadrowego, dostawca usług płatniczych).

Istotny: dostawca z dostępem do danych wrażliwych lub krytycznych systemów wtórnych (np. firma marketing automation z bazą leadów, biuro księgowe z danymi pracowników, agencja PR z planami strategicznymi).

Standardowy: dostawca pomocniczy bez dostępu do danych krytycznych (np. dostawca papieru, sprzętu biurowego, kawy).

Częste obserwacje.

“Lista dostawców” pochodzi z działu zakupów i jest tylko dostawcami z formalnymi umowami. Wszystkie “shadow IT” SaaS kupione przez działy bez wiedzy IT nie są na liście.
Klasyfikacja istnieje w polityce, ale nie jest stosowana. Wszyscy są “ważni”.
Brak aktualizacji od 2 lat. Połowa dostawców już nie współpracuje, ale wciąż widnieje na liście. Część nowych nie została dodana.

Test: audytor prosi o listę 5 losowo wybranych zakupów IT z ostatnich 12 miesięcy (z systemu księgowego). Sprawdza, czy dostawcy z tych zakupów są na “oficjalnej liście dostawców IT” w zarządzaniu compliance. Dziurawa lista = ustalenie.

Obszar 2: Due diligence przy on-boardingu

Każdy nowy dostawca IT z dostępem do danych lub systemów krytycznych powinien przejść due diligence. Bez tego firma kupuje “kota w worku”.

Standardowy zakres due diligence:

Compliance. Czy dostawca jest zgodny z RODO (UE/EOG), NIS2 (jeśli applicable), regulacjami sektorowymi? Pyta o IOD, polityki, raporty audytowe.

Certyfikaty. ISO 27001, SOC 2 Type II, ISO 22301 (BCM), ISO 27701 (privacy). Dostawca podaje certyfikaty + datę ważności. Audytor sprawdza realność (czy certyfikat jest aktualny, czy zakres obejmuje konkretną usługę).

Bezpieczeństwo techniczne. Jakie środki techniczne wdrożone (szyfrowanie, MFA, monitoring)? Czy są wyniki ostatnich pentestów?

Lokalizacja danych. Gdzie geograficznie są przechowywane dane? Czy są transfery do krajów trzecich? (Patrz: audyt transferów do krajów trzecich).

Sub-procesorzy. Kto jeszcze ma dostęp do danych? Czy są umowy wiążące sub-procesorów odpowiednikami art. 28 RODO?

Historia incydentów. Czy dostawca miał incydenty bezpieczeństwa w ostatnich 3 latach? Jak je obsłużył?

Stabilność finansowa. Dla dostawców krytycznych, czy firma jest stabilna finansowo? Risk of going out of business mid-contract.

Co audytor sprawdza.

Procedura due diligence (formalny dokument)
Wypełnione kwestionariusze due diligence dla dostawców krytycznych z ostatnich 24 miesięcy
Lista dostawców, którzy NIE przeszli due diligence, z uzasadnieniem (i planem)

Typowe luki.

Due diligence istnieje “w teorii”, żaden dostawca nie przeszedł go w pełni.
Kwestionariusze są wypełniane, ale nikt nie weryfikuje odpowiedzi (dostawca może deklarować cokolwiek).
Brak procesu “gate”, dostawca zostaje podpisany bez ukończenia due diligence.

Obszar 3: Klauzule kontraktowe

Umowa z dostawcą IT z dostępem do danych musi zawierać minimum następujące klauzule. Audytor weryfikuje każdą:

Klauzula 1: Zgodność z RODO art. 28. Pełna DPA (Data Processing Agreement). Patrz: audyt umów powierzenia art. 28 RODO.

Klauzula 2: Obowiązek raportowania incydentów. Dostawca zobowiązuje się raportować incydenty bezpieczeństwa w ciągu określonego czasu (typowo 24 godziny od wykrycia). Format raportu. Lista kontaktów.

Klauzula 3: Prawo do audytu. Administrator/zleceniodawca ma prawo audytować praktyki bezpieczeństwa dostawcy (lub zamówić audyt u trzeciej strony). Warunki (częstotliwość, koszty, zakres).

Klauzula 4: Sub-procesorzy. Lista aktualnych sub-procesorów, mechanizm zgody na nowych, prawo sprzeciwu.

Klauzula 5: Bezpieczeństwo techniczne, minimum. Wymóg konkretnych środków (szyfrowanie w spoczynku i tranzycie, MFA, regularne pentesty, polityka patch managementu).

Klauzula 6: Continuity i SLA. Service Level Agreement z konkretnymi RTO i RPO. Klauzula penalty za nieprzestrzeganie. Plan continuity dostawcy.

Klauzula 7: Zwrot/destrukcja danych przy zakończeniu. Procedura, terminy (typowo 30-60 dni), certyfikat zniszczenia.

Klauzula 8: Lokalizacja geograficzna. Wymóg konkretnych regionów (np. “dane przechowywane wyłącznie w EU-Central-1 lub EU-West-1”). Procedura zgody na zmianę lokalizacji.

Klauzula 9: Ubezpieczenie cyber. Dostawca posiada polisę cyber-insurance na minimum X mln zł. Procedura w przypadku roszczeń.

Klauzula 10: Terminacja awaryjna. Prawo do natychmiastowej terminacji bez kosztów w przypadku poważnego naruszenia bezpieczeństwa przez dostawcę.

Co audytor sprawdza.

3 umowy z dostawcami krytycznymi (losowo wybrane). Każda klauzula słowo po słowie.
Aktualność umów (data ostatniego aneksu). Umowy starsze niż 3 lata zwykle nie mają nowoczesnych klauzul cyber.
Spójność między DPA a umową główną.

Częste luki.

Umowa standardowa dostawcy, niedostosowana do specyfiki klienta.
Brak klauzuli raportowania incydentów (lub “dostawca zgłasza incydenty zgodnie ze swoimi standardami”, bez konkretu).
Klauzula audytowa ograniczona do “udostępnienia certyfikatu ISO 27001”, to nie jest klauzula audytowa.
SLA bez sankcji finansowych, pozbawia ją wartości operacyjnej.

Obszar 4: Monitoring i reakcja na incydenty u dostawców

Audyt nie kończy się na on-boardingu. Dostawca, który był OK 2 lata temu, może mieć dziś poważne luki.

Co audytor sprawdza.

Procedura ciągłego monitoringu dostawców krytycznych
Lista źródeł monitoringu (raporty SOC 2 Type II coroczne, BitSight/SecurityScorecard ratings, monitoring threat intelligence pod kątem incydentów u dostawców)
Procedura reakcji na incydent u dostawcy
Historia takich incydentów w ostatnich 24 miesiącach

Standardy 2026.

Dostawcy krytyczni, przegląd minimum raz na pół roku (renewal due diligence).
Monitoring ratings (BitSight, SecurityScorecard) ciągły lub kwartalny.
Subskrypcja threat intelligence z alertami o incydentach u dostawców.
Procedura “isolation in case of compromise”, gdy dostawca jest ofiarą ataku, jak szybko firma odłącza dostawcę od systemów.

Test: “Załóżmy, że w przyszłym tygodniu Kaseya VSA (lub equivalent waszego MSP) ma incident podobny do 2021 r. Pokażcie mi procedurę reakcji. Kto powiadamia, kto decyduje o izolacji, ile to potrwa?”

Obszar 5: Mapa supply chain, output audytu

Wynikiem audytu jest mapa łańcucha dostaw IT z minimum następującymi kolumnami:

Dostawca	Klasyfikacja	Kategoria danych	Lokalizacja	DPA	Cert.	Pentest	Ostatni review	Ryzyko
AWS (EU-Central-1)	krytyczny	klienci, transakcje	UE + USA	TAK	ISO 27001, SOC 2	brak (cloud provider)	2025-08	niskie
HubSpot	istotny	leady, behawior	USA (DPF)	TAK	SOC 2 Type II	TAK (publikuje)	2025-11	średnie
Local MSP (helpdesk)	krytyczny	dostęp do laptopów	PL	TAK	brak	brak	2024-03 (stara)	wysokie, luka
Biuro księgowe	istotny	dane HR + finansowe	PL	TAK (stara, 2022)	brak	brak	nigdy	wysokie, luka
ChatGPT Enterprise	krytyczny (nowy)	dane operacyjne	USA (DPF)	TAK	SOC 2	TAK	2025-09	średnie
Print provider	standardowy	drukowanie	PL	brak (nie potrzeba)	brak	brak	n/a	niskie

Mapa pokazuje natychmiast luki: dostawcy bez aktualnego review, dostawcy bez certyfikatów istotnych dla klasyfikacji, dostawcy z DPA przestarzałymi.

Jeśli przygotowujesz lub odbierasz audyt łańcucha dostaw i potrzebujesz szablonu mapy supply chain w XLSX wraz z metodyką klasyfikacji i kwestionariuszem due diligence, przesyłamy ten pakiet w newsletterze skanujfirme.pl. Bez szablonu pierwsza iteracja zwykle zajmuje 4-6 tygodni; z szablonem, 1-2 tygodnie.

Format ustalenia

Ustalenie SC-02 (klasyfikacja: wysokie): Biuro księgowe “X” obsługuje pełen system kadrowo-płacowy z dostępem do danych osobowych 145 pracowników (w tym danych szczególnie wrażliwych, orzeczenia, zaświadczenia medyczne). Umowa z dostawcą jest z 2022 r., DPA z poprzedniej wersji RODO, brak klauzul cyber-bezpieczeństwa, brak certyfikatów ISO 27001/SOC 2, brak pentestów. Brak procesu renewal due diligence.

Dowody: (1) Umowa z dostawcą z 2022 r.; (2) Brak dokumentów due diligence; (3) Wywiad z dyrektorem HR.

Ryzyko prawne i operacyjne: Naruszenie NIS2 art. 21(2)(d) i RODO art. 28(1). Konsekwencje: w przypadku naruszenia u dostawcy, firma odpowiada za niewłaściwy wybór procesora. Kara administracyjna UODO do 4% obrotu. Ekspozycja danych 145 pracowników.

Rekomendacja korygująca: (1) Renewal due diligence biura księgowego w 30 dni; (2) Renegocjacja umowy z aktualnym DPA i klauzulami cyber; (3) Decyzja: czy dostawca pozostaje, czy zmiana. Termin: 90 dni. Odpowiedzialny: dyrektor HR + IOD + dyrektor prawny.

Trzy pytania kontrolne dla zarządu

Pierwsze. Ilu mamy dostawców IT krytycznych i kiedy ostatnio każdy przeszedł renewal due diligence? Konkretne liczby, nie “kilkudziesięciu, dawno”.

Drugie. Co się stanie, gdy nasz dostawca cloud ma 48-godzinny outage globalny? Czy mamy plan continuity bez tego dostawcy?

Trzecie. Czy wiemy, którzy z naszych dostawców mają obowiązek raportowania pod NIS2 i czy zaczęli się do tego przygotowywać? (NIS2 dotyczy także średnich dostawców usług cyfrowych.)

Esencja

Audyt łańcucha dostaw IT jest dziś najszybciej rosnącą kategorią ustaleń. 62% naruszeń bezpieczeństwa zaczyna się od dostawcy. NIS2 art. 21(2)(d) wymaga formalnej polityki supply chain dla każdego podmiotu kluczowego lub istotnego.

Mapowanie i klasyfikacja dostawców to fundament. Pełna lista wymaga współpracy zakupów, IT, HR, marketingu, finansów, bo “shadow IT” jest powszechne. Klasyfikacja (krytyczny / istotny / standardowy) musi być stosowana, nie tylko zapisana.

Due diligence przy on-boardingu jest gate’em, bez ukończonego DD nowy dostawca z dostępem do danych nie powinien zostać podpisany. Compliance, certyfikaty, bezpieczeństwo techniczne, lokalizacja danych, sub-procesorzy, historia incydentów, stabilność finansowa, sześć podstawowych obszarów weryfikacji.

Klauzule kontraktowe to 10 elementów: DPA, raportowanie incydentów, prawo do audytu, sub-procesorzy, środki techniczne minimum, SLA z penalty, zwrot danych, lokalizacja, ubezpieczenie cyber, terminacja awaryjna. Pominięcie któregokolwiek = ekspozycja.

Monitoring ciągły to standard 2026. Dostawca, który był OK 2 lata temu, może dziś mieć poważne luki. Renewal due diligence co 6 miesięcy dla krytycznych, ratings ciągłe (BitSight, SecurityScorecard), threat intelligence z alertami.

Mapa łańcucha dostaw, z klasyfikacją, lokalizacją, statusem DPA, datami review, oceną ryzyka, jest jedynym narzędziem zarządczym pozwalającym świadomie podejmować decyzje. Bez mapy zarząd nie wie, na ile firma jest narażona.

W 2026 r. atak na dostawcę (third-party breach) jest bardziej prawdopodobny niż atak bezpośredni. Inwestycja w audyt i zarządzanie supply chain ma wyższy ROI niż większość innych inwestycji w cybersecurity dla średniej polskiej firmy.

Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (NIS2), art. 21 ust. 2 lit. (d). https://eur-lex.europa.eu/eli/dir/2022/2555/oj
Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO), art. 28. https://eur-lex.europa.eu/eli/reg/2016/679/oj
NIST SP 800-161 Rev. 1 (2022). Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations. https://doi.org/10.6028/NIST.SP.800-161r1
NIST SP 800-53 Rev. 5 (2020). Security and Privacy Controls, SR family (Supply Chain Risk Management). https://doi.org/10.6028/NIST.SP.800-53r5
ENISA (2023). Good Practices for Supply Chain Cybersecurity. https://www.enisa.europa.eu/publications/good-practices-for-supply-chain-cybersecurity
ENISA (2022). Threat Landscape for Supply Chain Attacks. https://www.enisa.europa.eu/publications/threat-landscape-for-supply-chain-attacks
Verizon (2024). Data Breach Investigations Report 2024, Third-Party chapter. https://www.verizon.com/business/resources/reports/dbir/
ISO/IEC 27036 series. Information security for supplier relationships.
SANS (2024). Supply Chain Compromise Guidance. https://www.sans.org/
CISA (2024). Software Bill of Materials (SBOM) Guidelines. https://www.cisa.gov/sbom

Audyt ciągłości działania (BCP/DR), NIS2 art. 21(2)(c) + RODO art. 32

Marek Porycki — Thu, 27 Aug 2026 13:30:00 +0000

Październik 2023 r. Polska Grupa Energetyczna ofiarą ransomware. Wrzesień 2024 r. atak ransomware na MOL Polska zatrzymuje produkcję na trzy dni. Listopad 2024 r. ALAB Laboratoria, kompromitacja danych medycznych 200 000+ pacjentów, naruszenie RODO. Każdy z tych przypadków miał dwa wspólne mianowniki: po pierwsze, atak udał się, bo zabezpieczenia prewencyjne miały luki. Po drugie, czas powrotu do operacyjności okazał się znacznie dłuższy niż firmy zakładały, bo backupy albo nie istniały w pełnym zakresie, albo zostały zaszyfrowane razem z systemami produkcyjnymi, albo nie były testowane.

NIS2 art. 21 ust. 2 lit. c wymaga “ciągłości działania, takich jak zarządzanie kopiami zapasowymi, odzyskiwanie po awarii oraz zarządzanie kryzysowe”. RODO art. 32 ust. 1 lit. b wymaga “zdolności do ciągłego zapewnienia poufności, integralności, dostępności i odporności systemów i usług przetwarzania”. Lit. c dodaje “zdolności do szybkiego przywrócenia dostępności danych osobowych i dostępu do nich w razie incydentu fizycznego lub technicznego”.

Audyt ciągłości działania w 2026 r. jest audytem trzech wymiarów jednocześnie: zdolności technicznej (czy backupy faktycznie się przywracają), zdolności proceduralnej (czy zespół wie, co robić), oraz odporności specyficznej na ransomware (immutable backups, air-gapped copies). Ten tekst jest pełną metodyką dla każdego z trzech wymiarów.

Trzy poziomy odporności, BCP, DR, BIA

Business Impact Analysis (BIA). Punkt wyjścia. Identyfikuje krytyczne procesy biznesowe, ich zależności od systemów IT, dopuszczalne czasy przerwy (RTO, Recovery Time Objective) i dopuszczalne utraty danych (RPO, Recovery Point Objective). Bez BIA pozostałe dokumenty są zawieszone w próżni.

Business Continuity Plan (BCP). Plan zachowania ciągłości operacji biznesowych. Obejmuje: alternatywne lokalizacje pracy, procesy manualne fall-back, komunikację z klientami i partnerami, łańcuch decyzyjny w kryzysie.

Disaster Recovery Plan (DR). Plan techniczny przywracania systemów IT. Obejmuje: kolejność przywracania (które systemy pierwsze), procedury per system, lokalizacje backupów, role zespołu, eskalację.

Audyt zaczyna się od weryfikacji, czy te trzy dokumenty istnieją, są aktualne (minimum z ostatnich 12 miesięcy), są ze sobą spójne. Brak któregokolwiek = poważne ustalenie.

Obszar 1: Strategia backupów, fundament

Reguła 3-2-1. Standard branżowy: 3 kopie danych, 2 różne nośniki/typy storage, 1 off-site. Współczesne rozszerzenie 3-2-1-1-0: dodatkowo 1 immutable (offline lub air-gapped) i 0 błędów weryfikacji.

Co audytor sprawdza.

Polityka backupów per system krytyczny
Częstotliwość backupów (idealnie: ciągła replikacja dla bazy + dzienne pełne)
Lokalizacje (on-site, off-site geograficzne, cloud, co najmniej 2 z 3)
Szyfrowanie backupów (zawsze!)
Retencja (zgodna z BIA, zwykle 30 dni dzienne, 12 mies. miesięczne, 7 lat dla wymogów prawnych)

Standard 2026, odporność na ransomware:

Immutable backups (WORM, Write Once Read Many) jako obowiązkowe dla danych krytycznych
Air-gapped copies (offline, fizycznie odłączone) dla strategicznych danych
Cloud backups z immutable retention (np. AWS S3 Object Lock, Azure Immutable Blob Storage)

Częste luki.

Backupy w tej samej infrastrukturze co produkcja (ransomware zaszyfruje oba).
Backupy szyfrowane kluczem, który leży obok serwera produkcyjnego.
“Mamy backup” oznacza w praktyce snapshot RAID, co nie chroni przed ransomware ani błędem ludzkim.
Brak dokumentacji jakie dokładnie systemy są backupowane.
Retencja krótka (7-14 dni), niewystarczająca dla wykrycia incydentu pre-encryption.

Obszar 2: Test odtwarzania, kluczowy moment audytu

Reguła kardynalna: backup, który nie został nigdy przywrócony, nie istnieje. Audytor zawsze testuje praktycznie.

Test 1: pełne odtworzenie wybranego systemu. Audytor wybiera jeden system krytyczny (np. bazę klientów). Prosi o przywrócenie z backupu sprzed 7 dni do środowiska izolowanego (sandbox). Mierzy: czas, czy proces działa, czy dane są spójne, czy aplikacja po odtworzeniu działa.

Test 2: punkt w czasie (point-in-time recovery). Audytor wybiera konkretny moment z ostatnich 14 dni (np. “9 maja 2026 o 14:30”) i prosi o odtworzenie stanu bazy z tego momentu. Sprawdza, czy granularność backupu pozwala na PITR (Point-In-Time Recovery).

Test 3: weryfikacja integralności. Audytor prosi o raport z ostatniego testu integralności backupów. Czy automatyczna weryfikacja działa? Czy są case’y “backup zapisany, ale uszkodzony”?

Test 4: ransomware scenario. Audytor symuluje scenariusz: “Cały produkcyjny storage jest zaszyfrowany przez ransomware. Pokażcie procedurę przywrócenia z immutable backup”. Mierzy: czas decyzyjny, czas techniczny, kompletność procedury.

Częste obserwacje.

Backup się przywraca, ale dane są z poprzedniego dnia o godz. 23:00, utracone 18 godzin transakcji.
Backup się przywraca, ale aplikacja nie wstaje, bo wymaga manualnej rekonfiguracji.
“Mamy backup, ale nigdy nie testowaliśmy odtwarzania”, najczęstsze.
Test odtwarzania robi się raz w roku z fanfarami, ale nikt nie weryfikuje, czy z każdego backupu w międzyczasie da się przywrócić.

Standardy 2026.

Test odtwarzania pełnego DR minimum raz w roku (idealnie kwartalnie).
Automatyczna weryfikacja integralności każdego backupu.
Test point-in-time recovery raz na kwartał.
Test ransomware scenario raz na pół roku.

Obszar 3: RTO i RPO, kwantyfikacja oczekiwań

Recovery Time Objective (RTO), maksymalny dopuszczalny czas przerwy. Recovery Point Objective (RPO), maksymalna dopuszczalna utrata danych. Bez tych liczb BCP/DR są życzeniami.

Przykład realistycznych RTO/RPO dla średniej firmy 2026:

System	Krytyczność	RTO	RPO
System ERP (finanse)	krytyczny	4 godziny	15 minut
CRM	krytyczny	8 godzin	1 godzina
System kadrowo-płacowy	wysoki	24 godziny	4 godziny
Magazyn dokumentów	średni	48 godzin	24 godziny
Intranet	niski	5 dni	24 godziny

Co audytor sprawdza.

Czy RTO i RPO są zdefiniowane per system krytyczny (zgodne z BIA).
Czy realne testy potwierdzają osiągalność tych RTO/RPO.
Czy strategia backupów pasuje do RPO (jeśli RPO = 15 minut, dziennej kopii pełnej nie wystarczy, potrzeba ciągłej replikacji).

Częsta luka. RTO/RPO są napisane w BCP, ale nigdy nie były zweryfikowane praktycznie. Test pokazuje: prawdziwe RTO jest 4× dłuższe niż zadeklarowane.

Obszar 4: Plan komunikacji kryzysowej

Techniczny DR bez komunikacji kryzysowej = wpadnięcie w drugą katastrofę (utratę zaufania klientów i partnerów).

Co audytor sprawdza.

Plan komunikacji kryzysowej (kto, kogo, kiedy, jakim kanałem)
Lista kluczowych interesariuszy z aktualnymi kontaktami
Szablony komunikatów (do klientów, partnerów, mediów, regulatorów)
Procedury akceptacji treści w trybie awaryjnym
Alternatywne kanały komunikacji (jeśli e-mail i Slack są niedostępne)

Test: symulacja stołowa scenariusza wymagającego komunikacji zewnętrznej. Audytor obserwuje: czas reakcji, jakość treści, kompletność listy odbiorców.

Obszar 5: Łańcuch decyzyjny w kryzysie

W kryzysie nie ma czasu na “kto decyduje”. To musi być wiadome.

Co audytor sprawdza.

Lista decyzji wymagających autoryzacji (np. ogłoszenie sytuacji kryzysowej, decyzja o płaceniu okupu, decyzja o przywróceniu z backupu, decyzja o powiadomieniu mediów).
Lista osób uprawnionych do każdej decyzji + fall-back person.
Procedura eskalacji w nocy / weekendy / święta.
Realne dane kontaktowe (telefon prywatny członka zarządu, nie tylko mail służbowy).

Test: “Zadzwoń teraz do osoby, która ma autoryzować decyzję o przywróceniu systemu kadrowego o 3:00 w nocy. Pokażcie, że telefon jest aktualny.”

Macierz oceny dojrzałości BCP/DR

Element	Poziom 1	Poziom 2	Poziom 3 (min NIS2)	Poziom 4	Poziom 5
BIA	nieaktualna lub brak	częściowa	kompletna, aktualna roczna	+ kwartalna walidacja	+ ciągłe monitorowanie zależności
BCP/DR docs	minimalne	są, niepełne	kompletne, spójne, aktualne	+ automatyczne testy	+ ciągłe doskonalenie
Backupy	są, 3-2-1 nieprzestrzegane	3-2-1 wdrożone	+ immutable dla krytycznych	+ kwartalne testy	+ chaos engineering
Testy odtwarzania	nigdy	jednorazowe	roczne pełne	kwartalne	ciągłe automatyczne
RTO/RPO	nieokreślone	są w dokumencie	są i zweryfikowane	+ monitoring real-time	+ optymalizowane ciągle
Komunikacja kryzysowa	brak planu	plan jest	+ przetestowany	+ alternatywne kanały	+ automatyzowane szablony

Format ustalenia

Ustalenie BCP-03 (klasyfikacja: krytyczne): Backupy systemu kadrowo-płacowego nie były testowane od momentu wdrożenia (czerwiec 2022 r., 4 lata). RTO zadeklarowany w BCP: 24 godziny. Brak dowodów na realną osiągalność tego RTO.

Dowody: (1) Wywiad z dyrektorem IT i administratorem systemu; (2) Brak raportów z testów odtwarzania w archiwum; (3) Polityka BCP wymaga rocznych testów, niewykonywane.

Ryzyko prawne i operacyjne: Naruszenie NIS2 art. 21(2)(c) i RODO art. 32(1)(c). W przypadku katastrofy (ransomware, awaria storage) brak gwarancji odtworzenia danych pracowników. Konsekwencje finansowe i prawne (terminy wypłat, ZUS, US).

Rekomendacja korygująca: (1) Test odtwarzania pełnego do izolowanego środowiska, w 30 dni; (2) Pomiar realnego RTO i RPO; (3) Jeśli RTO/RPO niewystarczające, modyfikacja strategii backupów; (4) Kalendaryzacja kwartalnych testów. Odpowiedzialny: dyrektor IT + administrator.

Trzy pytania kontrolne dla zarządu

Pierwsze. Kiedy ostatnio testowaliśmy odtwarzanie systemów krytycznych i z jakim wynikiem? Odpowiedź “nigdy” lub “nie pamiętam” = brak BCP w praktyce.

Drugie. Co się stanie, jeśli ransomware zaszyfruje całą produkcję dziś wieczorem? Konkretna procedura z czasami, czy spekulacja?

Trzecie. Kto budzi członka zarządu o 3:00 w nocy przy krytycznym incydencie i czy ten numer jest aktualny?

Esencja

Audyt ciągłości działania weryfikuje trzy wymiary: techniczny (czy backupy się przywracają), proceduralny (czy zespół wie, co robić), ransomware-resilience (czy mamy immutable i air-gapped).

Backup, który nie został przywrócony, nie istnieje. Audytor zawsze testuje praktycznie, pełne odtworzenie wybranego systemu, point-in-time recovery, scenariusz ransomware. Rezultaty pokazują różnice między dokumentem a rzeczywistością.

RTO i RPO bez weryfikacji są życzeniami. Realne testy pokazują, że deklarowane czasy są często 4× przeoptymistyczne. Bez zweryfikowanych liczb BCP nie jest narzędziem zarządczym.

Reguła 3-2-1-1-0 (3 kopie, 2 nośniki, 1 off-site, 1 immutable, 0 błędów) to standard 2026 dla podmiotu kluczowego NIS2. Immutable backups (WORM) są mandatory dla danych krytycznych. Brak = ekspozycja na ransomware bez realnej obrony.

Plan komunikacji kryzysowej i łańcuch decyzyjny są równie ważne, co backup. Techniczny DR bez warstwy ludzkiej i komunikacyjnej powoduje, że firma “ma backup”, ale traci miesiące, by go efektywnie wykorzystać.

Większość polskich firm średnich jest dziś na poziomie 1-2 dojrzałości. NIS2 wymaga poziomu 3 dla podmiotów kluczowych. Realny test odtwarzania, to godzina, która oddziela poziom 2 od poziomu 3.

Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (NIS2), art. 21 ust. 2 lit. (c). https://eur-lex.europa.eu/eli/dir/2022/2555/oj
Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO), art. 32 ust. 1 lit. (b)(c). https://eur-lex.europa.eu/eli/reg/2016/679/oj
ISO 22301:2019. Security and resilience, Business continuity management systems, Requirements. International Organization for Standardization.
ISO 22313:2020. Security and resilience, Business continuity management systems, Guidance on the use of ISO 22301.
NIST SP 800-34 Rev. 1 (2010). Contingency Planning Guide for Federal Information Systems. https://doi.org/10.6028/NIST.SP.800-34r1
NIST SP 800-184 (2016). Guide for Cybersecurity Event Recovery. https://doi.org/10.6028/NIST.SP.800-184
ENISA (2024). Ransomware: Attacks and Mitigation Strategies. https://www.enisa.europa.eu/publications
CISA (2023). Stop Ransomware Guide. https://www.cisa.gov/stopransomware
CSIRT NASK / CERT Polska. Raporty o ransomware w Polsce (2022-2024). https://www.cert.pl/publikacje/
Veeam. Data Protection Trends Report 2024. https://www.veeam.com/wp-data-protection-trends.html

Audyt kryptografii, NIS2 art. 21(2)(h) + RODO art. 32 w praktyce

Marek Porycki — Sat, 22 Aug 2026 10:07:00 +0000

Kryptografia w firmie z 2026 r. nie jest już opcjonalnym dodatkiem, jest fundamentem wszystkich pozostałych zabezpieczeń. Hasło bez kryptografii to nic. MFA bez TLS to teatr. Backup bez szyfrowania to ekspozycja. NIS2 art. 21 ust. 2 lit. h wymaga “polityk i procedur dotyczących stosowania kryptografii oraz, w odpowiednich przypadkach, szyfrowania”. RODO art. 32 ust. 1 lit. a wprost wskazuje “szyfrowanie danych osobowych” jako jeden z czterech przykładowych środków technicznych.

Brzmi prosto: szyfrować dane. Realnie audyt kryptografii to jeden z najbardziej technicznych obszarów, w którym łatwo ulec deklaracji (“mamy szyfrowanie”) bez weryfikacji rzeczywistości (“który algorytm, jaką długość klucza, kto ma klucze, jak są rotowane, czy nie używamy słabych szyfrów w TLS”). Audytor musi mieć kompetencje techniczne, by ocenić to merytorycznie.

Ten tekst jest pełną metodyką audytu kryptografii w średniej polskiej firmie 2026. Obejmuje pięć obszarów: szyfrowanie w spoczynku, szyfrowanie w tranzycie, zarządzanie kluczami, polityki i procedury, perspektywa post-quantum.

Obszar 1: Szyfrowanie w spoczynku (data at rest)

Dane przechowywane na dysku, czy zaszyfrowane?

Co audytor szuka.

Lista baz danych z klasyfikacją (krytyczne / wrażliwe / standardowe)
Dla każdej: czy szyfrowanie storage, jakim algorytmem, jak zabezpieczone klucze
Polityka szyfrowania w spoczynku
Konfiguracja Transparent Data Encryption (TDE) w SQL Server / PostgreSQL / Oracle / MySQL
Konfiguracja szyfrowania w chmurze (AWS KMS, Azure Key Vault, Google Cloud KMS)

Standardy 2026.

AES-256 jako standard. AES-128 jako minimum dopuszczalne dla danych nieklasyfikowanych jako wrażliwe.
3DES, DES, RC4, niedopuszczalne. Wykrycie = ustalenie krytyczne.
Szyfrowanie na poziomie storage (cały dysk lub volume) plus szyfrowanie na poziomie aplikacji dla danych szczególnie wrażliwych (PESEL, dane medyczne, dane finansowe).
Klucze przechowywane oddzielnie od danych (idealnie w HSM lub cloud KMS).

Typowe luki.

Baza produkcyjna zaszyfrowana, ale środowiska dev/test/staging niezaszyfrowane (z kopią danych produkcyjnych).
Backupy w trzecim regionie chmury bez szyfrowania.
Klucze hardcoded w plikach konfiguracyjnych.
“Szyfrowanie” na poziomie pliku (.zip z hasłem) zamiast prawdziwego szyfrowania storage.

Testy techniczne.

Test 1: weryfikacja realnego szyfrowania bazy. Audytor prosi o dump pliku bazy danych. Jeśli można odczytać dane bezpośrednio z plików storage, brak szyfrowania, mimo deklaracji.

Test 2: backup encryption. Audytor prosi o pokazanie procedury przywrócenia backupu i pliki backupu. Czy są zaszyfrowane? Czy klucze są dostępne tylko uprawnionym?

Test 3: separation of keys and data. Czy klucze TDE/storage encryption są przechowywane razem z danymi (na tym samym serwerze)? Jeśli tak, brak szyfrowania w praktyce (atakujący z dostępem do serwera ma dane i klucze).

Obszar 2: Szyfrowanie w tranzycie (data in transit)

Co audytor szuka.

Wersja TLS używana w komunikacji zewnętrznej i wewnętrznej
Konfiguracja TLS na serwerach webowych, API, bazach danych
Polityka deprecation starych wersji TLS
Szyfrowanie wewnętrznej komunikacji (server-to-server)

Standardy 2026.

TLS 1.3 jako standard. TLS 1.2 jako minimum dopuszczalne (z silnymi suite szyfrów).
TLS 1.0 i 1.1, niedopuszczalne (od 2020 r. deprecated). Wykrycie = ustalenie krytyczne.
SSL v2, v3, niedopuszczalne.
Cipher suites silne: ECDHE z AES-GCM lub ChaCha20-Poly1305. Słabe: cipher z RC4, MD5, anything export grade.
HSTS (HTTP Strict Transport Security) jako standard dla portalów.
Certyfikaty z aktualnych CA, automatyczna rotacja (np. Let’s Encrypt z certbot, lub komercyjnych CA z automatic renewal).

Testy techniczne.

Test 1: skan TLS portali zewnętrznych. Audytor używa narzędzia (testssl.sh, SSL Labs, Qualys) na każdym portalu firmy. Sprawdza: wersje TLS akceptowane, cipher suites, problemy z certyfikatami, HSTS. Wynik poniżej grade B w SSL Labs = ustalenie.

Test 2: komunikacja wewnętrzna. Czy server-to-server komunikacja jest szyfrowana? Czy bazy danych dostępne tylko przez TLS? Częsta luka: aplikacja łączy się z bazą po niezaszyfrowanym połączeniu w wewnętrznej sieci (“LAN jest bezpieczna”, to jest myślenie z lat 2000).

Test 3: API. Czy wszystkie API endpointy wymagają HTTPS? Czy są jakieś legacy endpointy HTTP, które nadal działają?

Test 4: VPN. Czy VPN używa silnych protokołów (WireGuard, OpenVPN z OpenSSL, IPsec z modern crypto)? Czy słabe protokoły (PPTP, L2TP bez IPsec) są wyłączone?

Obszar 3: Zarządzanie kluczami (Key Management)

Najtrudniejszy obszar audytu kryptografii. Nawet najsilniejsze szyfrowanie jest zerem, jeśli klucze są źle zabezpieczone.

Co audytor szuka.

Polityka zarządzania kluczami (key management policy)
Lista kluczy używanych w firmie (key inventory)
Sposób generowania kluczy (cryptographically secure random)
Sposób przechowywania (HSM, cloud KMS, software-based)
Sposób rotacji (kiedy, jak często, kto)
Sposób destrukcji (przy zakończeniu retencji)
Lista osób uprawnionych do dostępu do kluczy

Standardy 2026.

Hardware Security Modules (HSM) dla najbardziej krytycznych kluczy.
Cloud KMS (AWS KMS, Azure Key Vault, GCP KMS) jako standard dla firmy chmurowej. BYOK (Bring Your Own Key) dla wzmocnionej kontroli.
Software KMS (np. HashiCorp Vault) jako alternatywa dla on-premise.
Rotacja kluczy: minimum raz w roku, częściej dla wrażliwych. Po incydencie, natychmiastowa rotacja.
Separation of duties: osoba generująca klucz, osoba używająca klucza, osoba audytująca dostęp do klucza, różne osoby.
Logi dostępu do kluczy retencjonowane minimum 12 miesięcy.

Testy techniczne.

Test 1: gdzie są klucze? Audytor prosi o pokazanie, gdzie konkretnie są przechowywane klucze do TDE bazy klientów. Jeśli odpowiedź to “w pliku na serwerze bazy”, krytyczne ustalenie.

Test 2: kto ma dostęp? Lista użytkowników z dostępem do klucza master (root key). Standard: 2-4 osoby z mechanizmem split-knowledge (m-of-n).

Test 3: rotacja. Kiedy ostatnio rotowano klucz do bazy klientów? Jeśli odpowiedź to “nigdy od wdrożenia (4 lata temu)”, ustalenie.

Obszar 4: Polityka kryptograficzna

Wszystkie powyższe obszary wymagają formalnej polityki, dokumentu, który definiuje, co firma używa, czego nie, jak.

Co audytor szuka w polityce.

Lista akceptowanych algorytmów (AES-256, RSA-2048+, ECDSA P-256+, SHA-256+)
Lista odrzuconych algorytmów (DES, 3DES, MD5, SHA-1, RC4)
Procedura wprowadzania nowych algorytmów (kto akceptuje, na podstawie czego)
Procedura usuwania słabnących algorytmów (np. plan migracji z SHA-256 do SHA-3 lub do post-quantum)
Standardy długości kluczy
Standardy generowania (cryptographically secure random, nie Math.random!)
Standardy retencji i destrukcji kluczy
Mapa systemów z konkretnymi algorytmami używanymi w każdym

Częste luki w politykach.

Polityka kryptograficzna nie istnieje formalnie (kryptografia jest w polityce bezpieczeństwa ogólnie, bez konkretów).
Polityka jest, ale nieaktualizowana od momentu napisania (3+ lata).
Polityka nie obejmuje cloud (firma używa AWS od 2 lat, polityka pochodzi z czasów on-premise).
Brak mapy “algorytm → system, w którym jest używany”.

Obszar 5: Perspektywa post-quantum (PQC)

NIST w sierpniu 2024 r. opublikował pierwsze finalne standardy post-quantum cryptography (FIPS 203, 204, 205). Komputery kwantowe zdolne do złamania RSA-2048 i ECC są oczekiwane w horyzoncie 2030-2040. Krytyczne dane wymagające ochrony 10+ lat (medyczne, prawne, strategiczne) muszą rozważyć migrację już dziś.

Co audytor sprawdza w 2026.

Czy firma ma świadomość PQC?
Czy w polityce kryptograficznej jest plan crypto-agility (zdolność do szybkiej zmiany algorytmów)?
Czy dane krytyczne z długim okresem retencji są przygotowane do migracji?
Czy dostawcy chmury i kluczowi vendor’zy mają roadmap PQC?

Dla większości średnich polskich firm w 2026 r. PQC nie jest jeszcze wymaganiem operacyjnym, ale brak świadomości i planu = ustalenie informacyjne (nie krytyczne, ale powinno być w raporcie audytu jako rekomendacja strategiczna).

Format ustaleń

Ustalenie KRYPT-02 (klasyfikacja: krytyczne): TLS 1.0 i TLS 1.1 są nadal akceptowane na portalu klienckim panel.firma.pl. SSL Labs grade: C. Cipher suites zawierają RC4 i 3DES.

Dowody: (1) Skan SSL Labs z dnia 2026-05-10 (URL raportu); (2) Skan testssl.sh, pełen log; (3) Konfiguracja nginx w /etc/nginx/sites-available/panel.conf.

Ryzyko prawne i operacyjne: Naruszenie NIS2 art. 21(2)(h). TLS 1.0/1.1 są deprecated od 2020 r. (RFC 8996). RC4 podatne na ataki Bar-Mitzvah i znane od 2013 r. Ekspozycja: man-in-the-middle, downgrade attacks. Dane osobowe 23 000 użytkowników portalu narażone.

Rekomendacja korygująca: (1) Włączenie wyłącznie TLS 1.2 i TLS 1.3 (wyłączenie TLS 1.0/1.1) w konfiguracji nginx; (2) Pozostawienie wyłącznie cipher suites z ECDHE + AES-GCM lub ChaCha20-Poly1305; (3) Włączenie HSTS z max-age=31536000; (4) Po wdrożeniu, re-test SSL Labs, target grade A lub A+. Termin: 14 dni. Odpowiedzialny: dyrektor IT + administrator nginx.

Trzy pytania kontrolne przed audytem kryptografii

Pierwsze. Czy mam mapę “system → algorytm szyfrowania → lokalizacja kluczy”? Bez tej mapy audyt jest spekulacją.

Drugie. Kiedy ostatnio wykonano skan TLS portali zewnętrznych i z jakim wynikiem? Brak skanów regularnych = brak monitoringu skuteczności środków (art. 32 ust. 1 lit. d RODO).

Trzecie. Gdzie są klucze do szyfrowania bazy klientów? Konkretna odpowiedź (np. “AWS KMS region eu-central-1, customer-managed CMK z BYOK”) = poziom 3+. “Gdzieś na serwerze” = poziom 1.

Esencja

Audyt kryptografii obejmuje pięć obszarów: szyfrowanie w spoczynku, szyfrowanie w tranzycie, zarządzanie kluczami, polityka kryptograficzna, perspektywa post-quantum. Każdy wymaga osobnej metodyki dowodów i testów technicznych.

Standardy 2026 są jasne: AES-256 dla danych, TLS 1.2/1.3 dla komunikacji, hardware lub cloud KMS dla kluczy, formalna polityka z mapą algorytmów per system. Wszystko poniżej tych standardów to ustalenia.

Najczęstsze luki w polskich średnich firmach: TLS 1.0/1.1 nadal aktywne na portalach starszych, klucze przechowywane razem z danymi (jakby ich nie było), brak rotacji kluczy, środowiska dev/test/staging niezaszyfrowane z kopią produkcji.

Zarządzanie kluczami jest najtrudniejszym obszarem. Najsilniejsze szyfrowanie z słabym key management to dziurawe sito. HSM lub cloud KMS z separation of duties to standard 2026 dla podmiotu kluczowego.

Skan SSL Labs portali zewnętrznych jest najszybszym testem audytowym. 5 minut na portal, grade B lub niżej = automatyczne ustalenie. Każdy CISO w 2026 r. powinien mieć monitoring tego w czasie rzeczywistym.

PQC nie jest jeszcze operacyjnym wymaganiem dla większości firm, ale crypto-agility (zdolność do szybkiej zmiany algorytmów) staje się strategicznym tematem. Dane z retencją 10+ lat zaszyfrowane dziś RSA-2048 są kandydatem do “harvest now, decrypt later” przez aktorów państwowych.

Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (NIS2), art. 21 ust. 2 lit. (h). https://eur-lex.europa.eu/eli/dir/2022/2555/oj
Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO), art. 32 ust. 1 lit. (a). https://eur-lex.europa.eu/eli/reg/2016/679/oj
NIST FIPS 197 (2001). Advanced Encryption Standard (AES). https://doi.org/10.6028/NIST.FIPS.197
NIST SP 800-57 Part 1 Rev. 5 (2020). Recommendation for Key Management, Part 1: General. https://doi.org/10.6028/NIST.SP.800-57pt1r5
NIST FIPS 203 (2024). Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM). Post-quantum standard. https://doi.org/10.6028/NIST.FIPS.203
NIST FIPS 204 (2024). Module-Lattice-Based Digital Signature Algorithm (ML-DSA). https://doi.org/10.6028/NIST.FIPS.204
IETF RFC 8446 (2018). The Transport Layer Security (TLS) Protocol Version 1.3. https://datatracker.ietf.org/doc/html/rfc8446
IETF RFC 8996 (2021). Deprecating TLS 1.0 and TLS 1.1. https://datatracker.ietf.org/doc/html/rfc8996
Mozilla. TLS Configuration Generator and Recommendations. https://ssl-config.mozilla.org/
ENISA (2023). Cryptographic protocols and algorithms, recommendations. https://www.enisa.europa.eu/publications
Qualys SSL Labs. SSL Server Test. https://www.ssllabs.com/ssltest/

Audyt MFA i kontroli dostępu, NIS2 art. 21(2)(j) + RODO art. 32

Marek Porycki — Mon, 17 Aug 2026 07:44:00 +0000

Microsoft w 2024 r. opublikował raport, według którego 99,9% incydentów z kompromitacją kont firmowych można było zatrzymać przez MFA. Liczba jest cytowana w setkach źródeł, i mimo to w średniej polskiej firmie MFA pokrywa typowo 20-60% kont krytycznych. Reszta to luka, której audytor szuka w pierwszej godzinie.

NIS2 art. 21 ust. 2 lit. j wymaga “stosowania uwierzytelniania wieloskładnikowego lub ciągłego uwierzytelniania, zabezpieczonych komunikacji głosowej, wideo i tekstowej oraz zabezpieczonych systemów komunikacji wewnątrz podmiotu w sytuacjach kryzysowych”. RODO art. 32 wymaga “odpowiednich środków technicznych i organizacyjnych”, MFA jest dziś standardem branżowym, a brak MFA przy danych osobowych = potencjalne naruszenie art. 32 (UODO już cytował to w decyzjach z lat 2023-2024).

Ten tekst jest pełną metodyką audytu MFA i kontroli dostępu (IAM). Obejmuje cztery obszary: pokrycie MFA, jakość metod MFA, zarządzanie tożsamością, kontrolę dostępu uprzywilejowanego.

Co dyrektywa i rozporządzenie wymagają, w detalu

NIS2 art. 21(2)(j). Standard: wszystkie wrażliwe systemy dostępne dla użytkowników wewnętrznych i zewnętrznych mają MFA. Idealnie: continuous authentication (np. ryzyko-adaptive auth, system ocenia ryzyko sesji i wymaga dodatkowych czynników gdy ryzyko rośnie).

RODO art. 32 + decyzje UODO. UODO konsekwentnie wskazuje, że dla danych osobowych dostępnych przez internet (panele administracyjne, CRM, system kadrowy, baza klientów) MFA jest minimum. Brak MFA w przypadku naruszenia (kradzież hasła, phishing skuteczny) skutkuje sankcjami.

ENISA (2024) Good Practices. Rekomenduje phishing-resistant MFA (FIDO2, WebAuthn) jako standard 2026 dla podmiotów kluczowych. SMS i hasła odzyskiwania zostają zakwalifikowane jako poniżej standardu.

Obszar 1: Pokrycie MFA, pomiar i ocena

Co audytor szuka. Lista wszystkich systemów z dostępem do danych krytycznych lub wrażliwych. Dla każdego: czy MFA wymuszone (100% kont), wymuszone dla niektórych, opcjonalne, niedostępne.

Dokumenty do zebrania.

Polityka MFA firmy
Lista systemów IT (asset inventory) z klasyfikacją krytyczności
Lista użytkowników z wyjątkami od MFA (i uzasadnieniami)
Raporty z konfiguracji MFA per system (z paneli administracyjnych)

Pytania do wywiadu z CISO/IT.

Jaki procent kont (ogółem) ma MFA?
Jaki procent kont uprzywilejowanych (administratorów) ma MFA?
Jakie systemy nie mają MFA i dlaczego?
Jak długo trwa od utworzenia nowego konta do włączenia MFA, automatycznie czy wymaga akcji?

Testy techniczne.

Test 1: weryfikacja realnego stanu w trzech systemach krytycznych. Audytor wybiera trzy systemy z danymi krytycznymi (np. system kadrowy, CRM, panel admin chmury). Dla każdego prosi o pokazanie konfiguracji MFA. Sprawdza: czy wymuszone (nie tylko dostępne), czy obejmuje wszystkie konta, jakie metody są akceptowane.

Test 2: próba zalogowania bez MFA. Audytor prosi administratora o symulację: utworzyć konto testowe, spróbować zalogować się ze stacji niezarejestrowanej. Czy MFA jest wymuszone? Jakie metody zaproponowane?

Test 3: weryfikacja wyjątków. Lista wyjątków (kont bez MFA). Audytor pyta dla każdego: dlaczego, do kiedy, jaki jest plan likwidacji wyjątku. Wyjątki bez planu = ustalenie.

Kryteria oceny dojrzałości.

Poziom 0: MFA niewdrożone lub szczątkowo (poniżej 10% kont).
Poziom 1: MFA na niektórych systemach (10-40% kont), brak polityki formalnej.
Poziom 2: Polityka MFA, wymuszone dla części systemów (40-75% kont), liczne wyjątki.
Poziom 3 (minimum NIS2): MFA wymuszone na wszystkich systemach krytycznych (95%+ kont uprzywilejowanych, 80%+ kont ogółem), wyjątki udokumentowane z planem.
Poziom 4: Poziom 3 + phishing-resistant MFA dla administratorów, conditional access (geo-fencing, anomalia behavior detection).
Poziom 5: Poziom 4 + continuous authentication, passwordless (FIDO2 wszędzie gdzie możliwe).

Obszar 2: Jakość metod MFA, nie wszystkie są równe

NIST SP 800-63B (Authentication Assurance Levels) klasyfikuje metody uwierzytelniania w trzech poziomach (AAL1, AAL2, AAL3). NIS2 wymaga AAL2 minimum, AAL3 dla systemów najbardziej krytycznych.

Metody MFA według siły (od najsłabszej):

SMS one-time password. Najsłabsza. Podatna na SIM swapping, SS7 attacks, przekierowanie wiadomości. NIST od 2017 r. odradza dla nowych wdrożeń. 2026: poniżej standardu.
E-mail one-time password. Słaba. Jeśli atakujący ma dostęp do skrzynki, ma też MFA. Akceptowalne tylko jako recovery.
TOTP (Time-Based One-Time Password), Google Authenticator, Microsoft Authenticator. Standard średni. Phishing-able (atakujący zbiera kod razem z hasłem). Akceptowalne dla większości scenariuszy.
Push notification (Microsoft Authenticator, Duo). Średnia siła. Podatna na MFA fatigue (atakujący wysyła zalewy próśb, użytkownik klika “approve” znudzony). Microsoft w 2022 r. wprowadził number matching jako mitygację.
Hardware tokens (YubiKey, Titan). Silne. FIDO2/WebAuthn = phishing-resistant. Standard dla administratorów i kont uprzywilejowanych w 2026 r.
Biometria + hardware (Windows Hello for Business, Apple Touch ID/Face ID). Silne, ale specyficzne urządzeniu. Dobre dla devices managed.
Certyfikaty + hardware (smart cards). Bardzo silne, ale wymagające infrastruktury PKI.

Co audytor sprawdza.

Test: jakie metody są dostępne dla użytkowników. W konfiguracji MFA każdego systemu, czy SMS jest dostępne jako fallback? Jeśli tak, to atakujący wybierze SMS, niezależnie od tego, że organizacja “rekomenduje” TOTP. Audytor wymaga, by SMS było wyłączone (lub akceptowane tylko jako recovery code, nie main factor).

Test: jakie metody są wymuszone dla administratorów. Cele 2026: phishing-resistant MFA (FIDO2/WebAuthn z YubiKey lub Titan) dla wszystkich kont uprzywilejowanych. Brak = ustalenie.

Test: MFA fatigue protection. Czy system push notification ma number matching (Microsoft Authenticator 2022+), location-based hints, contextual info?

Kryteria oceny dojrzałości jakości metod.

Poziom 1: SMS jako główna metoda lub bez wymuszenia metod.
Poziom 2: TOTP/push dla wszystkich, SMS jako fallback.
Poziom 3 (minimum 2026): TOTP/push wymuszone, SMS wyłączone. Hardware tokens dla administratorów.
Poziom 4: Phishing-resistant MFA (FIDO2) dla administratorów, conditional access.
Poziom 5: Passwordless wszędzie gdzie możliwe, continuous authentication.

Obszar 3: Zarządzanie tożsamością (IAM), szerszy kontekst

MFA bez IAM jest jak zamek bez framugi. Audytor sprawdza pełen pipeline:

On-boarding. Czy nowy pracownik dostaje konta automatycznie (provisioning z HR), w jakich systemach, z jakimi uprawnieniami? Zasada least privilege (najmniej uprawnień niezbędnych).

Access review. Audyt uprawnień minimum raz na 6 miesięcy. Sprawdza: kto miał dostęp do czego, czy nadal potrzebuje, czy nie ma “zombie permissions” (uprawnienia z projektów już zamkniętych).

Off-boarding. Czas od wypowiedzenia umowy do zablokowania wszystkich kont. Standard 2026: do 24 godzin od końca umowy. Najczęstsza luka: konta w systemach SaaS niezintegrowanych z SSO (poza centralną kontrolą).

Single Sign-On (SSO). Czy firma używa SSO (Okta, Azure AD/Entra ID, Google Workspace)? Centralizacja tożsamości umożliwia jeden punkt enforcement MFA, jeden punkt access review, jeden punkt off-boarding.

Audyt zewnętrznych dostawców. Czy konsultanci, freelancerzy, partnerzy mają konta w systemach? Z jakimi uprawnieniami? Z jakim okresem ważności?

Dokumenty do zebrania. Polityka IAM, polityka on/off-boardingu, raporty access review z ostatnich 12 miesięcy, integracje SSO, lista użytkowników zewnętrznych z aktualnymi uprawnieniami.

Testy.

Lista 5 osób, które odeszły w ostatnich 30 dniach. Dla każdej sprawdź: data odejścia, data zablokowania kont w głównych systemach, w SaaS niezintegrowanych z SSO. Luka czasowa = ustalenie.
Test access review: ostatni raport. Czy znalezione “zombie permissions” zostały zlikwidowane? Brak action items = poziom 1.

Obszar 4: Kontrola dostępu uprzywilejowanego (PAM)

Konta administratorów to wektory najcięższego ryzyka. Pełen incident report ataku Lapsus$ na Nvidię (2022), Microsoft (2022) i Okta (2022) pokazał: kompromitacja konta uprzywilejowanego = pełen dostęp do firmy.

Privileged Access Management (PAM) to dedykowane rozwiązania (CyberArk, BeyondTrust, Delinea, lub open-source jak Vault) do zarządzania dostępem uprzywilejowanym. Funkcje:

Vaulting haseł kont administratorów (nikt nie zna haseł “z głowy”)
Just-in-time access (administrator zgłasza prośbę, dostaje dostęp na X godzin)
Session recording (nagrywanie sesji administracyjnych)
Approval workflow (krytyczne akcje wymagają drugiej osoby)

Co audytor sprawdza.

Lista kont administratorów (root, admin, super-user w każdym systemie krytycznym).
Czy istnieje PAM? Jakie systemy są pokryte?
Czy session recording jest włączone dla działań produkcyjnych?
Czy administratorzy używają “personal admin accounts” (osobne konto dla zadań admin) zamiast osobistych?

Kryteria oceny dojrzałości PAM.

Poziom 0: Brak PAM, hasła w plikach tekstowych lub Excel’u u kilku osób.
Poziom 1: Hasła w password manager (np. KeePass, 1Password Team), ale dzielone bez audytu.
Poziom 2: Wyznaczeni administratorzy mają osobne konta. SSO wymusza MFA. Brak PAM dedykowanego.
Poziom 3 (minimum): PAM dla administratorów wszystkich systemów krytycznych. Just-in-time access. Session recording dla produkcji.
Poziom 4: PAM zintegrowany z SIEM/SOAR. Threat detection w czasie rzeczywistym.
Poziom 5: Zero standing privileges. Wszystkie dostępy administracyjne są just-in-time.

W audycie 2026 r. każdy podmiot kluczowy NIS2 powinien być minimum na poziomie 3. Mniejsze firmy istotne, minimum poziom 2.

Format ustaleń w raporcie audytu MFA i IAM

Przykład typowego ustalenia o wysokiej klasyfikacji:

Ustalenie MFA-04 (klasyfikacja: wysokie): Konta administratorów (12 kont z uprawnieniami “root” lub “global admin”) nie wymagają phishing-resistant MFA. Akceptowanymi metodami są TOTP i push notification.

Dowody: (1) Wywiad z dyrektorem IT; (2) Konfiguracja MFA w Azure AD/Entra ID (zweryfikowana przez audytora); (3) Polityka MFA z 2023 r., nieaktualizowana po publikacji ENISA Good Practices 2024.

Ryzyko prawne i operacyjne: Naruszenie NIS2 art. 21(2)(j) w wykładni ENISA. Wektory ataku: phishing kradnący TOTP, MFA fatigue na push. Ostatnie naruszenia w branży (Uber 2022, Cisco 2022) pokazują skuteczność tych wektorów. Konsekwencja kompromitacji konta admin: pełen dostęp do systemów krytycznych.

Rekomendacja korygująca: Wprowadzenie phishing-resistant MFA (FIDO2/WebAuthn), YubiKey lub Titan dla 12 administratorów (koszt ~600 zł × 24 sztuki = 14 400 zł + czas wdrożenia 3 tygodnie). Wyłączenie TOTP/push jako metod uwierzytelniania administratorów, pozostają jako fallback dla użytkowników regularnych. Aktualizacja polityki MFA. Termin: 60 dni. Odpowiedzialny: CISO + IT.

Trzy pytania kontrolne dla CISO przed audytem MFA

Pierwsze. Czy mam pełną listę systemów krytycznych z aktualnym stanem MFA? Bez mapy systemów audyt jest słaby. Lista wymaga współpracy z IT, security, biznesem (niektóre systemy są “shadow IT”, kupione przez działy bez wiedzy IT).

Drugie. Czy administratorzy mają phishing-resistant MFA? Jeśli nie, to obszar #1 do interwencji w 2026 r. Koszt sprzętu jest niski (kilka tysięcy zł), korzyść, eliminacja głównego wektora ataków targeted.

Trzecie. Czy mam process access review i czy działa? “Mamy w polityce” to nie odpowiedź. “Ostatnie review było 4 tygodnie temu, znaleziono X zombie permissions, zlikwidowano w Y dni”, to odpowiedź.

Esencja

Audyt MFA i kontroli dostępu pokrywa cztery obszary: pokrycie MFA, jakość metod MFA, zarządzanie tożsamością (IAM), kontrola dostępu uprzywilejowanego (PAM). Każdy obszar wymaga osobnej metodologii dowodów i testów technicznych.

Pokrycie MFA mierzymy ilościowo: jaki procent kont krytycznych, jaki procent kont uprzywilejowanych. Standard 2026: 95%+ administratorów, 80%+ użytkowników ogółem. Wyjątki muszą być udokumentowane z planem likwidacji.

Jakość metod MFA nie jest binarna. SMS to obecnie standard poniżej akceptowalnego, odradzany przez NIST od 2017 r. TOTP/push to średni standard, akceptowalny dla użytkowników regularnych. Phishing-resistant MFA (FIDO2/WebAuthn z hardware tokens) to standard dla administratorów w 2026 r.

IAM jest framugą dla MFA. Off-boarding w czasie poniżej 24 godzin, regularne access review, integracja z SSO, to fundamenty bez których MFA jest dziurawym sitem. Najczęstsza luka: konta w SaaS niezintegrowanych z SSO, których off-boarding wymaga akcji ręcznej, której nikt nie wykonuje.

PAM to ostatnia linia obrony przed atakiem na konto uprzywilejowane. Just-in-time access, session recording, vaulting haseł, to minimum dla podmiotu kluczowego NIS2 w 2026 r.

Phishing-resistant MFA dla administratorów to inwestycja na poziomie kilku tysięcy złotych z drastyczną redukcją ryzyka. Każdy audyt 2026 r. powinien sprawdzić ten obszar w pierwszych dwóch godzinach. Brak = ustalenie wysokie, niezależnie od pozostałych zabezpieczeń.

Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (NIS2), art. 21 ust. 2 lit. (j). https://eur-lex.europa.eu/eli/dir/2022/2555/oj
Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO), art. 32. https://eur-lex.europa.eu/eli/reg/2016/679/oj
NIST Special Publication 800-63B (2017, revision 4, draft 2024). Digital Identity Guidelines: Authentication and Lifecycle Management. https://doi.org/10.6028/NIST.SP.800-63b
NIST Special Publication 800-207 (2020). Zero Trust Architecture. https://doi.org/10.6028/NIST.SP.800-207
ENISA (2024). Good Practices for Multi-Factor Authentication. European Union Agency for Cybersecurity. https://www.enisa.europa.eu/publications
FIDO Alliance. FIDO2 / WebAuthn specifications. https://fidoalliance.org/fido2/
Microsoft Security (2024). Digital Defense Report 2024. https://www.microsoft.com/en-us/security/security-insider/microsoft-digital-defense-report-2024
CISA (2023). Implementing Phishing-Resistant MFA. Cybersecurity and Infrastructure Security Agency. https://www.cisa.gov/resources-tools/resources/implementing-phishing-resistant-mfa
UODO. Decyzje Prezesa UODO dotyczące art. 32 RODO i uwierzytelniania (2020-2024). https://uodo.gov.pl/pl/138
Verizon (2024). Data Breach Investigations Report 2024, Authentication chapter. https://www.verizon.com/business/resources/reports/dbir/

Audyt transferów do krajów trzecich, SCC, TIA, USA po Schrems II

Marek Porycki — Wed, 12 Aug 2026 14:21:00 +0000

W lipcu 2020 r. Trybunał Sprawiedliwości UE w wyroku Schrems II unieważnił Privacy Shield, ramy ułatwiające transfer danych z UE do USA. W lipcu 2023 r. Komisja Europejska wydała decyzję adekwatności dla nowych ram EU-US Data Privacy Framework (DPF). Pomiędzy tymi datami polskie firmy żyły w stanie quasi-zawieszenia: transferowały dane do USA na podstawie SCC bez pełnej pewności prawnej. W 2026 r. DPF działa, ale audyt transferów pozostaje jednym z najtrudniejszych obszarów RODO, bo łączy wymogi prawne, techniczne (czy faktycznie szyfrujesz dane przed transferem) i kontekstowe (co konkretnie robi z danymi dostawca w państwie trzecim).

Każda polska średnia firma transferuje dane do krajów trzecich, najczęściej nie wiedząc o tym. Używasz AWS, transfer. Używasz Google Workspace, transfer. Mailchimp, HubSpot, Salesforce, transfer. ChatGPT enterprise, Claude API, Microsoft Copilot, transfer. Audyt transferów to mapa rzeczywistego pomiędzy-jurysdykcyjnego krwiobiegu danych firmy oraz weryfikacja, czy każdy transfer ma legalną podstawę i adekwatne środki techniczne.

Ten tekst jest pełną metodyką audytu transferów. Strukturuje się wokół trzech narzędzi prawnych (decyzja adekwatności, SCC, art. 49 ust. 1 wyjątki) plus narzędzia weryfikacji (TIA, Transfer Impact Assessment) plus środki uzupełniające (Supplementary Measures).

Definicja transferu, co właściwie audytujemy

Art. 44 RODO: “Przekazanie danych osobowych przetwarzanych lub mających być przetwarzane po przekazaniu do państwa trzeciego lub organizacji międzynarodowej następuje tylko wtedy, gdy administrator i podmiot przetwarzający spełniają warunki określone w niniejszym rozdziale”.

Transfer obejmuje:

przesłanie danych z UE do serwera w państwie trzecim
udzielenie dostępu (zdalny) do danych z UE z państwa trzeciego (np. support engineer w Indiach loguje się do bazy w Polsce)
użycie usługi cloud, której back-end znajduje się w państwie trzecim (nawet jeśli front-end usługi jest w UE)

Transfer NIE obejmuje (kontrowersyjnie, ale przyjęta interpretacja EROD):

przejazdu danych przez kraje trzecie tranzytem (np. backbone internet)
danych w transferze szyfrowane silnie, gdzie kraj trzeci nie ma kluczy

Audyt transferów polega na zbudowaniu pełnej mapy transferów rzeczywistych w firmie. To znacznie więcej niż lista zagranicznych dostawców, to każda integracja, każdy webhook, każdy SaaS, każda chmura wykorzystywana w organizacji.

Trzy ścieżki legalizacji transferu

Ścieżka 1: Decyzja adekwatności (art. 45). Komisja Europejska wydaje decyzję uznającą państwo trzecie za zapewniające adekwatny poziom ochrony. Na maj 2026 r. decyzje istnieją dla: Andory, Argentyny, Faroe, Guernsey, Izraela, Wyspy Man, Japonii, Jersey, Nowej Zelandii, Korei Południowej, Szwajcarii, Urugwaju, Wielkiej Brytanii (post-Brexit), oraz USA (poprzez EU-US Data Privacy Framework, DPF, tylko dla podmiotów certyfikowanych).

Ścieżka 2: Odpowiednie zabezpieczenia (art. 46). Najczęściej w postaci Standardowych Klauzul Umownych (SCC) wydanych przez KE w czerwcu 2021 r. (Decyzja Wykonawcza (UE) 2021/914). Cztery moduły SCC odpowiadające relacjom: kontroler→kontroler, kontroler→processor, processor→processor, processor→kontroler. Plus inne narzędzia: BCR (Binding Corporate Rules dla grup kapitałowych), kodeksy postępowania, certyfikaty.

Ścieżka 3: Odstępstwa (art. 49). Wyjątkowe podstawy: zgoda wyraźna podmiotu, niezbędność umowy, ważne względy interesu publicznego, dochodzenie roszczeń, ochrona żywotnych interesów. Te podstawy są wyjątkami i NIE mogą być używane do transferów systematycznych, TYLKO ad hoc, ograniczone.

Audytor sprawdza, którą ścieżką dla każdego transferu legitymizowany jest transfer. Część firm transferuje dane do USA “na zgodę”, i to jest typowo nieprawidłowe, bo zgoda nie pasuje do regularnych transferów operacyjnych.

EU-US Data Privacy Framework (DPF), krytyczne uściślenia

DPF działa od lipca 2023 r. dla USA. Mechanizm: amerykański podmiot certyfikuje się dobrowolnie w Department of Commerce, deklaruje przestrzeganie zasad DPF, podlega kontroli FTC. Polska firma transferująca do tego podmiotu nie potrzebuje SCC.

Co audytor weryfikuje przy DPF:

Czy konkretny podmiot, do którego transferujemy dane, jest aktualnie certyfikowany w DPF (lista publiczna na dataprivacyframework.gov).
Czy konkretna usługa, z której korzystamy u tego podmiotu, jest objęta zakresem certyfikacji (część podmiotów certyfikuje tylko niektóre usługi).
Czy certyfikat jest aktywny (są podmioty z wygaśniętą certyfikacją, mimo że nadal pojawiają się na “starych” listach).

Niuans: DPF jest narzędziem słabszym niż wcześniejsze Privacy Shield z perspektywy zabezpieczeń przed inwigilacją USA. Schrems III (w toku przed TSUE w 2025 r.) może DPF ponownie unieważnić. Ostrożny audytor zaleca, by transfery do USA były obsługiwane przez DPF + zaplanowane fallback SCC + zaplanowane środki uzupełniające. To strategia odporności.

Standardowe klauzule umowne (SCC 2021)

SCC 2021 zastąpiły poprzednie wersje (2001, 2004, 2010). Cztery moduły. Każdy zestaw klauzul obowiązkowy ma trzy załączniki:

Załącznik I.A: opis stron i kategorii transferu
Załącznik I.B: opis transferu (kategorie danych, kategorie podmiotów, częstotliwość, charakter, cele, okresy retencji)
Załącznik II: środki techniczne i organizacyjne

Audytor sprawdza:

Czy SCC są w aktualnej wersji 2021 (firmy często mają nadal stare SCC z 2010 r., co po grudniu 2022 r. nie jest już dopuszczalne dla nowych transferów).
Czy załączniki I.A, I.B, II są kompletnie wypełnione (najczęstszy błąd: załączniki puste lub generyczne).
Czy klauzule są zharmonizowane z umową główną (DPA + SCC powinny być spójne, nie sprzeczne).
Czy klauzula odnosząca się do prawa właściwego i jurysdykcji jest poprawna (musi być prawo państwa członkowskiego UE).

Transfer Impact Assessment (TIA), najtrudniejszy element audytu

TIA to formalna ocena, czy w państwie trzecim, do którego transferujesz dane, prawo i praktyka pozwalają zachować ochronę równoważną RODO. Wymaga jej art. 46 RODO w wykładni EROD (Recommendations 01/2020). TIA jest obowiązkową częścią transferów na SCC; dla DPF nie jest formalnie wymagana, ale rekomendowana.

Etapy TIA:

Identyfikacja transferu w szczegółach: kategorie danych, kategorie podmiotów, cele, częstotliwość, sposób przesyłania.
Identyfikacja narzędzia transferu: SCC moduł, DPF, BCR, art. 49 odstępstwo.
Ocena prawa państwa trzeciego: czy istnieją regulacje umożliwiające dostęp władz publicznych do danych w sposób niezgodny ze standardami UE? Dla USA: FISA Section 702, Executive Order 12333, USA Patriot Act, CLOUD Act. Dla Chin: Cybersecurity Law, Data Security Law, Personal Information Protection Law. Dla Indii: pakiet ustaw 2023.
Ocena praktyki: czy w rzeczywistości władze państwa trzeciego korzystają z tych regulacji w stosunku do podobnych transferów? Czy istnieją skargi, wyroki, raporty?
Ocena środków uzupełniających: czy istniejące zabezpieczenia (techniczne, organizacyjne, umowne) są wystarczające, aby zniwelować ryzyko prawa państwa trzeciego?
Decyzja: transfer dozwolony / dozwolony pod warunkiem dodatkowych środków / niedozwolony.
Dokumentacja: raport TIA, akceptowany przez administratora, retencja minimum przez czas trwania transferu plus 5 lat.

Częste błędy w audycie TIA:

TIA wykonana raz przy podpisaniu umowy, nigdy nie zaktualizowana.
TIA wykonana powierzchownie (“USA = OK na podstawie DPF”), bez analizy specyficznych regulacji.
Brak dokumentacji decyzji administratora.

Środki uzupełniające (Supplementary Measures)

Gdy TIA pokazuje, że samo SCC nie wystarcza, art. 46 wymaga dodatkowych środków. EROD w Recommendations 01/2020 wymienia trzy kategorie:

Środki techniczne. Najmocniejsza kategoria. Obejmuje: szyfrowanie end-to-end (klucze pozostają w UE, dostawca w państwie trzecim nie ma kluczy), pseudonimizację, anonimizację, podział danych. Kluczowy test: czy nawet w przypadku przymusowego ujawnienia (np. nakaz amerykańskiego sądu) dostawca może rzeczywiście przekazać czytelne dane?

Środki kontraktowe. Klauzule w SCC: zobowiązanie dostawcy do natychmiastowego informowania administratora o nakazach od władz, zobowiązanie do prawnego kontestowania nakazów, zobowiązanie do publikowania transparency reports. Te środki są SŁABE, dostawca może być prawnie zmuszony do ukrycia faktu nakazu (gag order w USA).

Środki organizacyjne. Wewnętrzne polityki dostawcy, audyty bezpieczeństwa, certyfikaty, szkolenia. Najsłabsza kategoria, ma znaczenie głównie uzupełniające.

Audytor sprawdza, czy dla każdego “ryzykownego” transferu (do USA, Chin, Indii bez DPF/decyzji adekwatności) są wdrożone środki uzupełniające. Brak środków uzupełniających przy istniejącym ryzyku = ustalenie krytyczne.

Typowe scenariusze transferów w polskiej średniej firmie

Scenariusz 1: AWS / Microsoft Azure z regionem UE. Twierdzenie dostawcy: “Twoje dane są w regionie EU-Central-1”. Realnie: kontrola pozostaje w USA (administracja, support, fall-back). Audyt: SCC + TIA + ocena, czy region UE faktycznie izoluje od US persons. Środki uzupełniające: BYOK (Bring Your Own Key) lub HYOK (Hold Your Own Key) gdzie możliwe.

Scenariusz 2: SaaS marketingowy (HubSpot, Mailchimp, Salesforce Marketing Cloud). Dane w USA. Sprawdź: DPF cert + jaki konkretnie serwis jest objęty + środki techniczne (część dostawców oferuje opcję “EU region”, sprawdź realnie). Często brak środków uzupełniających przy danych behawioralnych klientów.

Scenariusz 3: AI (ChatGPT, Claude, Gemini, Copilot). Transfer treści promptów do USA. Sprawdź: czy wersja enterprise z opt-out z trenowania + DPF + ustawienia prywatności. Dla danych wrażliwych (medycznych, prawnych, klientów), częsta luka. Coraz częstszy temat audytu w 2026 r.

Scenariusz 4: Support outsourcing (Indie, Filipiny). Pracownicy zewnętrzni z dostępem do bazy klientów. Sprawdź: SCC, kontrolę dostępu, logowanie, szyfrowanie połączeń, ograniczenie zakresu danych. Często brak TIA dla Indii (zwłaszcza po ustawach 2023 r.).

Scenariusz 5: Slack, Microsoft Teams. Komunikacja wewnętrzna, w której są dane osobowe pracowników i klientów. Transfer do USA przez backend dostawcy. Sprawdź: DPF + ustawienia retencji + szyfrowanie + ewentualnie opcję “Enterprise Key Management”.

Mapa transferów, output audytu

Wynikiem audytu jest mapa transferów z minimum następującymi kolumnami:

Dostawca	Kategorie danych	Kraj transferu	Narzędzie prawne	TIA wykonana	Środki uzupełniające	Ryzyko rezydualne
AWS S3 (region us-east-1)	klienci, transakcje	USA	DPF + SCC	TAK (2025-08)	szyfrowanie BYOK, audit logs	niskie
HubSpot Marketing	leady, behawior	USA	DPF	TAK (2024-12)	brak (luka)	średnie
ChatGPT Enterprise	prompty z bazy klientów	USA	DPF	NIE	opt-out z trenowania	wysokie, luka audytowa
Support outsourcing (Indie)	tickety klientów	Indie	SCC moduł 2	NIE (luka)	brak	wysokie, luka audytowa
Slack Enterprise	komunikacja wewnętrzna	USA	DPF	TAK (2025-01)	Enterprise Key Mgmt	niskie

Taka mapa, regularnie aktualizowana (minimum kwartalnie), jest jednym z najmocniejszych dowodów świadomości zarządczej w audycie RODO. UODO przy kontrolach pyta wprost: “Pokaż mapę transferów”. Jej brak = ustalenie systemowe.

Jeśli przygotowujesz lub odbierasz pierwszy audyt transferów i potrzebujesz szablonu mapy w XLSX z metodyką wypełniania oraz checklistą TIA per kraj, przesyłamy ten pakiet w newsletterze skanujfirme.pl. Mapa transferów to dokument operacyjny, nie jednorazowy artefakt, z szablonem łatwiej utrzymać aktualność.

Trzy pytania kontrolne dla IOD przed audytem transferów

Pierwsze. Czy mam pełną listę dostawców z transferem do krajów trzecich? Bez listy audyt jest niemożliwy. Lista wymaga zaangażowania IT (kto jakich SaaS używa), zakupów (jakie umowy podpisaliśmy), security (jakie integracje techniczne istnieją).

Drugie. Dla każdego transferu, które z trzech narzędzi prawnych go legitymizuje? Brak odpowiedzi = niezgodność.

Trzecie. Dla transferów na SCC, czy mam aktualną TIA? Bez TIA SCC są niewystarczające w wykładni EROD.

Esencja

Audyt transferów do krajów trzecich łączy trzy wymiary: prawny (decyzja adekwatności / SCC / wyjątki art. 49), kontekstowy (TIA, czy prawo państwa trzeciego pozwala zachować ochronę RODO) i techniczny (środki uzupełniające, czy szyfrowanie, pseudonimizacja eliminują ryzyko realne).

EU-US Data Privacy Framework działa od lipca 2023 r. Pokrywa transfery do certyfikowanych podmiotów w USA, ale jest narzędziem słabszym niż wcześniejsze Privacy Shield. Schrems III w toku może DPF zakwestionować. Ostrożna strategia: DPF + zaplanowane fallback SCC + środki uzupełniające jako redundancja.

SCC 2021 wymagają kompletnego wypełnienia trzech załączników (I.A, I.B, II). Najczęstszy błąd: załączniki puste lub generyczne. To natychmiast widoczne w audycie.

TIA jest najtrudniejszym elementem audytu. Wymaga analizy prawa, praktyki i kontekstu konkretnego transferu. TIA wykonana powierzchownie (“USA = OK”) jest gorsza niż brak TIA, bo daje fałszywe poczucie zgodności.

Środki uzupełniające: trzy kategorie (techniczne, kontraktowe, organizacyjne). Najmocniejsze są techniczne, szyfrowanie z kluczami w UE, pseudonimizacja, podział danych. Środki kontraktowe są słabe (dostawca może być prawnie zmuszony do ukrycia faktów). Audytor szuka konkretnych środków, nie deklaracji.

Mapa transferów jako output audytu jest jednocześnie narzędziem decyzyjnym dla zarządu i dowodem zgodności dla UODO. Bez mapy nie da się ani świadomie zarządzać ryzykiem, ani efektywnie odpowiadać na kontrole.

W 2026 r. transfer do USA przez ChatGPT, Claude, Copilot jest coraz częstszym tematem audytów. Dane wrażliwe w promptach AI to obszar, gdzie wiele firm jest w stanie nieświadomej niezgodności, i gdzie pierwsze decyzje UODO są kwestią czasu.

Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. (RODO), Rozdział V (art. 44-50), Przekazywanie danych osobowych do państw trzecich. https://eur-lex.europa.eu/eli/reg/2016/679/oj
Wyrok TSUE z dnia 16 lipca 2020 r. w sprawie C-311/18 (Schrems II). https://curia.europa.eu/juris/document/document.jsf?docid=228677
Decyzja Wykonawcza Komisji (UE) 2021/914 z dnia 4 czerwca 2021 r. w sprawie standardowych klauzul umownych dotyczących przekazywania danych osobowych do państw trzecich. https://eur-lex.europa.eu/eli/dec_impl/2021/914/oj
Decyzja Wykonawcza Komisji (UE) 2023/1795 z dnia 10 lipca 2023 r. w sprawie odpowiedniego stopnia ochrony danych osobowych w ramach EU-US Data Privacy Framework. https://eur-lex.europa.eu/eli/dec_impl/2023/1795/oj
EROD (2021). Recommendations 01/2020 on measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data, version 2.0. https://www.edpb.europa.eu/our-work-tools/our-documents/recommendations/
EROD (2022). Guidelines 05/2021 on the Interplay between the application of Article 3 and the provisions on international transfers as per Chapter V of the GDPR. https://www.edpb.europa.eu/
U.S. Department of Commerce. EU-US Data Privacy Framework Program. https://www.dataprivacyframework.gov/
UODO. Wytyczne w sprawie międzynarodowego przekazywania danych osobowych. https://uodo.gov.pl/pl/138
European Commission. Adequacy decisions, list of countries. https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/adequacy-decisions_en
noyb (European Center for Digital Rights). Resources on Schrems II implementation. https://noyb.eu/en

Audyt umów powierzenia (art. 28 RODO), częste błędy, jak weryfikować

Marek Porycki — Fri, 07 Aug 2026 11:58:00 +0000

W każdym audycie RODO, który prowadziłem lub w którym uczestniczyłem, umowy powierzenia okazały się najsłabszym ogniwem. Statystyka jest brutalna: w średniej polskiej firmie 30-60% umów z procesorami danych albo nie istnieje (mimo realnego powierzenia), albo istnieje w wersji oderwanej od stanu faktycznego, albo zawiera klauzule sprzeczne z art. 28 RODO. To największy obszar systemowego ryzyka prawnego, jaki spotyka się w audytach.

Powodów jest kilka. Po pierwsze, art. 28 ma długą listę elementów obligatoryjnych (osiem podstawowych wymogów) i każde z nich jest pułapką. Po drugie, firmy podpisują DPA przygotowane przez procesorów (typowo dostawców cloud, SaaS, narzędzi marketingowych), nie negocjując i nie weryfikując zgodności. Po trzecie, lista procesorów dynamicznie rośnie (każda nowa subskrypcja SaaS to potencjalny nowy procesor), a procesy on-boardingu rzadko obejmują weryfikację DPA.

Ten tekst jest pełną metodyką audytu umów powierzenia. Strukturuje się wokół ośmiu obligatoryjnych elementów z art. 28 ust. 3, dla każdego podaje, co audytor szuka, jakie typowe błędy spotyka i jak konstruować klauzulę odporną na ustalenia kontroli.

Kiedy umowa powierzenia jest wymagana

Art. 28 ust. 1 RODO: “Jeżeli przetwarzanie ma być dokonywane w imieniu administratora, korzysta on wyłącznie z usług takich podmiotów przetwarzających, które zapewniają wystarczające gwarancje wdrożenia odpowiednich środków technicznych i organizacyjnych”.

Art. 28 ust. 3: “Przetwarzanie przez podmiot przetwarzający odbywa się na podstawie umowy lub innego instrumentu prawnego”.

Granica między procesorem (wymaga DPA) a samodzielnym administratorem (DPA nie wymagane) bywa cienka. Procesor:

przetwarza dane w celach administratora, na jego polecenie
nie decyduje samodzielnie o celach przetwarzania
nie używa danych do własnych celów

Współadministrator (art. 26) lub samodzielny administrator:

decyduje (lub współdecyduje) o celach
używa danych również do własnych celów
ma własną odpowiedzialność wobec podmiotów danych

Typowe przykłady procesorów: dostawcy hosting/cloud (AWS, Azure, OVH), narzędzia CRM (HubSpot, Pipedrive), narzędzia marketingowe (Mailchimp, Brevo, GetResponse), narzędzia HR (Asseco, Comarch ERP w SaaS), płatności (PayU, Tpay), biura księgowe, biura rachunkowe, firmy windykacyjne, firmy outsourcingu IT.

Typowe przykłady NIE-procesorów (czyli samodzielni administratorzy, bez DPA): banki (mają własną podstawę prawną przetwarzania), urzędy państwowe (działają na podstawie ustawy), agencje pracy tymczasowej w pewnych konfiguracjach, dostawcy poczty tradycyjnej w zakresie samego dostarczania (ale nie analizy).

Pierwszą ofiarą audytu jest mapa procesorów. Jeśli firma nie ma kompletnej listy aktualnych procesorów (z datą weryfikacji), audyt zaczyna się od jej tworzenia, co potrafi zająć 2-3 tygodnie pracy.

Osiem obligatoryjnych elementów art. 28 ust. 3

Każda umowa powierzenia musi zawierać osiem konkretnych elementów. Audytor weryfikuje każdy.

Element 1: Przedmiot i czas trwania przetwarzania

Co art. 28 wymaga. Określenie, co dokładnie procesor przetwarza i przez jaki okres.

Co audytor szuka. Konkretne wskazanie celu (nie ogólne “obsługa klienta”), zakresu, długości umowy, sposób przedłużenia, sposób zakończenia.

Częste błędy.

Generyczna fraza “świadczenie usług” bez konkretu, nieaudytowalne.
Brak terminu, umowa “na czas nieokreślony” jest dopuszczalna, ale powinna mieć mechanizm zakończenia i przegląd.
Brak ścisłego powiązania z umową głównej usługi (zwykle DPA jest aneksem do umowy SaaS lub umowy konsultingowej).

Klauzula odporna. “Procesor przetwarza dane osobowe w imieniu Administratora wyłącznie w celu realizacji Umowy [referencja do umowy głównej] przez okres jej obowiązywania. Po zakończeniu Umowy Procesor jest zobowiązany do zwrotu lub zniszczenia danych zgodnie z punktem [referencja do punktu o zwrocie].”

Element 2: Charakter i cel przetwarzania

Co art. 28 wymaga. Wskazanie, jakie operacje (zbieranie, przechowywanie, modyfikacja, ujawnianie, usuwanie) procesor wykonuje i w jakim celu.

Co audytor szuka. Lista konkretnych operacji, lista konkretnych celów. Idealnie tabela: cel → operacje → kategorie danych → kategorie podmiotów.

Częste błędy.

“Wszelkie operacje niezbędne do świadczenia usługi”, za szerokie, audytor odrzuca.
Brak rozróżnienia celów (np. obsługa zamówienia, marketing, profilowanie).

Element 3: Rodzaj danych osobowych i kategorie podmiotów

Co art. 28 wymaga. Wymienienie kategorii danych i kategorii podmiotów.

Co audytor szuka. Konkretna lista kategorii: dane identyfikacyjne (imię, nazwisko, e-mail), dane kontaktowe (telefon, adres), dane finansowe (numer konta, historia transakcji), dane zdrowotne (jeśli applicable), dane biometryczne (jeśli applicable). Plus kategorie podmiotów: pracownicy, klienci, kandydaci, dostawcy.

Częste błędy.

“Dane osobowe niezbędne do realizacji usługi”, niewystarczające.
Pominięcie szczególnych kategorii (art. 9), gdy są przetwarzane.

Element 4: Obowiązki i prawa administratora

Co art. 28 wymaga. Określenie, że administrator decyduje o celach i sposobach, procesor wykonuje jego polecenia.

Co audytor szuka. Klauzula określająca, że procesor nie używa danych do własnych celów (np. trenowanie modeli AI procesora na danych administratora, częsta pułapka).

Częste błędy.

Brak klauzuli o zakazie używania danych do własnych celów procesora.
Pozwolenie procesorowi na “anonimizację i wykorzystanie do analiz”, to jest własny cel procesora, nie powierzenie. Klauzula obejmująca taką operację narusza art. 28.

Element 5: Zobowiązania procesora (art. 28 ust. 3 lit. a-h)

Osiem konkretnych zobowiązań procesora, które MUSZĄ być w DPA:

(a) Przetwarzanie na udokumentowane polecenie administratora. (b) Tajemnica pracowników procesora (obowiązek poufności). (c) Stosowanie wszelkich wymaganych środków bezpieczeństwa art. 32. (d) Sub-procesory tylko za zgodą administratora. (e) Pomoc administratorowi w realizacji praw podmiotów (art. 12-22). (f) Pomoc administratorowi w wypełnianiu obowiązków art. 32-36 (bezpieczeństwo, zgłaszanie naruszeń, DPIA). (g) Po zakończeniu zwrot lub zniszczenie danych według wyboru administratora. (h) Udostępnianie wszelkich informacji niezbędnych do wykazania zgodności + audyty.

Co audytor szuka. Każda z tych ośmiu klauzul, słowo po słowie. Pominięcie którejkolwiek = ustalenie krytyczne.

Częste błędy.

Klauzule formalnie obecne, ale skróty/wycieżki: np. “procesor będzie pomagać administratorowi w zakresie ekonomicznie uzasadnionym”, to jest osłabienie obowiązku z art. 28 lit. e/f i niesie ryzyko.
“Procesor może korzystać z sub-procesorów wedle uznania, informując administratora”, narusza art. 28 lit. d, który wymaga zgody (uprzedniej lub ogólnej z prawem sprzeciwu).

Element 6: Sub-procesorzy

Co art. 28 wymaga. Procesor może powierzyć dane sub-procesorowi tylko za zgodą administratora (uprzednią konkretną LUB ogólną z prawem sprzeciwu). Sub-procesor musi być związany analogicznymi obowiązkami.

Co audytor szuka. Aktualna lista sub-procesorów (typowo dla dostawców cloud: liczne, np. AWS używa setek sub-procesorów dla różnych usług), mechanizm zgody, mechanizm aktualizacji listy z prawem sprzeciwu.

Częste błędy.

Brak listy sub-procesorów (dostawca powołuje się na ogólną dostępność listy na stronie, bez konkretnej referencji).
Brak mechanizmu sprzeciwu (administrator nie wie, że dostawca dodał nowego sub-procesora w USA).
Sub-procesorzy poza UE/EOG bez SCC lub innych zabezpieczeń.

Element 7: Zwrot lub zniszczenie danych

Co art. 28 wymaga. Po zakończeniu, zwrot lub zniszczenie, według wyboru administratora.

Co audytor szuka. Konkretna procedura, termin (typowo 30-60 dni), dowód zniszczenia (certyfikat lub raport), wyjątki tylko w zakresie zabezpieczenia przez prawo (np. archiwa księgowe).

Częste błędy.

“Procesor usunie dane wedle własnych standardów”, niewystarczające.
Brak terminu, proces “kiedyś” jest nieaudytowalny.

Element 8: Audyty (art. 28 lit. h)

Co art. 28 wymaga. Procesor udostępnia administratorowi wszelkie informacje niezbędne do wykazania zgodności + umożliwia audyty (w tym kontrole) przeprowadzane przez administratora lub audytora przez niego upoważnionego.

Co audytor szuka. Klauzula audytowa z konkretnymi warunkami: częstotliwość, koszty, zakres, ograniczenia.

Częste błędy.

Brak klauzuli audytowej.
Audyt “tylko przy uzasadnionym podejrzeniu naruszenia”, to jest osłabienie obowiązku art. 28 lit. h.
Audyt “na koszt administratora niezależnie od wyniku”, wątpliwe etycznie, choć dopuszczalne; UODO patrzy nieprzychylnie.
Ograniczenie do certyfikatów SOC 2 / ISO 27001 jako substytutu audytu, może być uzupełnieniem, ale nie zastępstwem prawa do audytu.

Test trzech umów, szybka diagnoza stanu

Jeśli musisz w ciągu jednego dnia ocenić, w jakim stanie są umowy powierzenia w firmie, przeprowadź test trzech umów:

Wybierz dostawcę krytycznego (np. dostawca cloud lub system kadrowo-płacowy).
Wybierz dostawcę średniego znaczenia (np. narzędzie marketingowe lub CRM).
Wybierz dostawcę małego znaczenia (np. drobne narzędzie SaaS).

Dla każdego sprawdź:

Czy DPA istnieje (formalnie podpisana z aktualną datą).
Czy zawiera wszystkie osiem elementów art. 28 ust. 3.
Czy lista sub-procesorów jest dostępna i aktualna.
Czy klauzula audytowa istnieje i jest sensowna.
Czy transfery do krajów trzecich są obsługiwane (SCC lub równoważne).

Test trzech umów zajmuje 2-3 godziny i daje miarodajny obraz całości. Jeśli wszystkie trzy są w porządku, system jest prawdopodobnie zdrowy. Jeśli choćby jedna kuleje (zwykle ten średniego znaczenia), reszta najpewniej również.

Dla zespołów IOD i compliance, które regularnie wykonują takie testy, przygotowujemy w newsletterze skanujfirme.pl checklist trzech umów w formie szablonu XLSX z pytaniami kontrolnymi i punktacją oraz wzorzec DPA zgodny z art. 28 (do dostosowania pod konkretną umowę usługową). Jeśli to się przydaje, można zapisać się bez zobowiązań.

Klauzule dostawców cloud, specyficzne pułapki

DPA dostawców globalnych (AWS, Google, Microsoft, Salesforce, HubSpot) to osobna kategoria. Charakterystyka:

Standardowy DPA dostarczony przez dostawcę, możliwość negocjacji minimalna lub żadna (poza klientami Enterprise).
Sub-procesorzy w listach setek pozycji, regularnie zmieniani.
Transfery do USA, od czasu Schrems II i Data Privacy Framework (DPF) z 2023 r. obsługiwane przez certyfikat DPF lub SCC plus TIA.
Klauzule audytowe ograniczone do raportów SOC 2 i ISO 27001.

Co audytor sprawdza specyficznie dla globalnych dostawców:

Czy konkretna usługa, z której firma korzysta, jest objęta DPF (nie wszystkie usługi są).
Czy administrator wyraził zgodę ogólną na sub-procesorów z mechanizmem sprzeciwu.
Czy TIA (Transfer Impact Assessment) został wykonany dla transferów do USA.
Czy dostawca informuje o zmianach sub-procesorów z odpowiednim wyprzedzeniem.

Pełna metodyka transferów: audyt transferów do krajów trzecich (SCC, TIA, USA po Schrems II).

Format ustaleń w raporcie audytu art. 28

Przykład ustalenia, którego struktura jest reprezentatywna:

Ustalenie 28-03 (klasyfikacja: krytyczne): Brak umowy powierzenia z procesorem realizującym wysyłkę newslettera (Mailchimp, USA), od listopada 2023 r. trwa przetwarzanie danych 18 400 subskrybentów bez ważnej DPA i bez weryfikacji transferu do USA.

Dowody: (1) Lista procesorów przedstawiona przez IOD (data); (2) Brak DPA w archiwum umów (zweryfikowane przez audytora); (3) Wyciąg z systemu Mailchimp pokazujący dane przetwarzane.

Ryzyko prawne: Naruszenie art. 28 ust. 3 RODO (brak DPA) oraz art. 44-49 (transfery bez podstawy). Ekspozycja: kara administracyjna UODO do 20 mln EUR lub 4% rocznego obrotu (art. 83 ust. 5). Dodatkowo: ryzyko reputacyjne i utrata zaufania subskrybentów.

Rekomendacja korygująca: (1) Natychmiast (w 24h) zawrzeć aktualne DPA Mailchimp dostępne w panelu administracyjnym; (2) Wykonać TIA dla transferu do USA z udokumentowaniem DPF lub SCC; (3) Zaktualizować klauzulę informacyjną o transferze; (4) Powiadomić IOD o nowym procesorze formalnie. Termin: 30 dni. Odpowiedzialny: dyrektor marketingu + IOD.

Taka struktura, z kwantyfikacją (18 400 subskrybentów), powołaniem na konkretną podstawę prawną i kara, propozycją z terminem, pozwala zarządowi szybko zrozumieć ryzyko i priorytetyzować.

Trzy pytania kontrolne dla IOD przed audytem art. 28

Pierwsze. Czy mamy aktualną listę procesorów? Bez kompletnej listy audyt jest niemożliwy. Lista powinna zawierać: nazwa procesora, kategoria danych, kategoria operacji, data zawarcia DPA, data ostatniej weryfikacji, status (aktywna / wygasła / wymaga aktualizacji).

Drugie. Czy każda DPA pokrywa osiem obligatoryjnych elementów art. 28 ust. 3? Audyt klauzula po klauzuli dla każdego procesora to praca, ale jednorazowa, potem aktualizacja przy każdej zmianie umowy.

Trzecie. Czy proces on-boardingu nowego dostawcy obejmuje weryfikację DPA przez IOD przed podpisaniem umowy głównej? Jeśli nie, nowe luki będą powstawać szybciej, niż stare zostaną zamknięte.

Esencja

Umowy powierzenia (art. 28 RODO) są w polskich firmach najsłabszym ogniwem zgodności. 30-60% audytów wykrywa luki w tej kategorii: brak umowy, niekompletna umowa, klauzule sprzeczne z art. 28, brak listy sub-procesorów, brak mechanizmów audytowych.

Osiem obligatoryjnych elementów art. 28 ust. 3, przedmiot i czas, charakter i cel, dane i podmioty, prawa administratora, osiem szczegółowych zobowiązań procesora (a-h), sub-procesorzy, zwrot/zniszczenie, audyty, musi być w każdej DPA. Brak jakiegokolwiek = niezgodność.

Test trzech umów (krytyczny, średni, mały dostawca) daje miarodajny obraz całości w 2-3 godziny. Jeśli wszystkie trzy są w porządku, system jest zdrowy. Jeśli choćby jedna kuleje, prawdopodobnie cały portfel jest problematyczny.

DPA dostawców globalnych (AWS, Google, Microsoft) to osobna kategoria, standardowe szablony, transfery do USA, długie listy sub-procesorów. Tutaj audyt skupia się na: DPF/SCC dla transferów, TIA, mechanizmie zgody ogólnej z prawem sprzeciwu.

Proces on-boardingu nowych procesorów jest kluczowy. Bez weryfikacji DPA przed podpisaniem umowy głównej luki będą się tworzyć szybciej, niż stare zostaną zamknięte. Najlepsze firmy mają w on-boardingu dostawcy gate’a “approval IOD”, bez tego umowa nie zostaje podpisana.

Art. 28 jest jednym z najczęściej cytowanych przepisów RODO w decyzjach UODO i sądów. Sankcje za brak DPA są wysokie, wyższy próg z art. 83 (do 20 mln EUR lub 4% obrotu), bo art. 28 zalicza się do “bardziej istotnych” obowiązków. Dla średniej firmy to znaczy, że jedno przeoczenie procesora może kosztować więcej niż dwuletni budżet IOD.

Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. (RODO), art. 28, Podmiot przetwarzający. https://eur-lex.europa.eu/eli/reg/2016/679/oj
EROD/EDPB (2021). Guidelines 07/2020 on the concepts of controller and processor in the GDPR, version 2.0. https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/
Komisja Europejska (2021). Standardowe klauzule umowne między administratorami i podmiotami przetwarzającymi, Decyzja Wykonawcza (UE) 2021/915. https://eur-lex.europa.eu/eli/dec_impl/2021/915/oj
UODO (2019, z aktualizacjami). Wytyczne w sprawie umów powierzenia danych osobowych. https://uodo.gov.pl/pl/138
UODO. Decyzje Prezesa UODO w sprawach art. 28 RODO (2019-2024). https://uodo.gov.pl/pl/138/
EDPB-EDPS Joint Opinion 2/2021 on Standard Contractual Clauses between controllers and processors. https://www.edpb.europa.eu/
Komisja Europejska. EU-US Data Privacy Framework, Decyzja Wykonawcza Komisji (UE) 2023/1795. https://eur-lex.europa.eu/eli/dec_impl/2023/1795/oj
EROD (2021). Recommendations 01/2020 on measures that supplement transfer tools, version 2.0. https://www.edpb.europa.eu/
Polska Ustawa z dnia 10 maja 2018 r. o ochronie danych osobowych (Dz.U. 2018 poz. 1000 ze zm.)
ICO (UK). Contracts and liabilities between controllers and processors. https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/contracts-and-liabilities-between-controllers-and-processors/

DPIA w praktyce, kiedy obowiązuje, jak wykonać, szablon oceny

Marek Porycki — Sun, 02 Aug 2026 08:35:00 +0000

DPIA, Data Protection Impact Assessment, po polsku “ocena skutków dla ochrony danych”, jest jednym z najczęściej źle wykonywanych elementów wdrożenia RODO w polskich firmach. Częsta sytuacja: firma wpisuje DPIA do polityki, ma jeden szablon, wypełnia formalnie raz na pół roku z myślą “żeby było”, ale nigdy nie służy on rzeczywistej decyzji o tym, czy operację przetwarzania w ogóle uruchomić, zmodyfikować, czy zaniechać. To jest DPIA-fasada.

DPIA wykonana właściwie jest narzędziem decyzyjnym. Jest analizą ryzyka skoncentrowaną na prawach i wolnościach osób fizycznych. Pokazuje zarządowi, że konkretna operacja przetwarzania (np. wdrożenie monitoringu wideo z analizą emocji, czy uruchomienie sklepu online z profilowaniem behawioralnym) ma takie a takie ryzyka, które są niwelowane przez takie a takie środki, a ryzyko rezydualne mieści się w akceptowanym progu (lub nie, i wtedy operacja nie powinna ruszyć bez konsultacji z UODO).

Ten tekst jest pełnym przewodnikiem operacyjnym po DPIA: kiedy jest obowiązkowa, jaką metodyką ją wykonać, jak wygląda raport, kiedy konsultować z UODO. Strukturę raportu DPIA podajemy w formie szablonu, którego można użyć w pracy zawodowej IOD.

Podstawa prawna i kiedy DPIA jest obowiązkowa

Art. 35 ust. 1 RODO: “Jeżeli dany rodzaj przetwarzania, w szczególności z użyciem nowych technologii, ze względu na swój charakter, zakres, kontekst i cele z dużym prawdopodobieństwem może powodować wysokie ryzyko naruszenia praw lub wolności osób fizycznych, administrator przed rozpoczęciem przetwarzania dokonuje oceny skutków planowanych operacji przetwarzania dla ochrony danych osobowych”.

Trzy elementy są kluczowe: (1) “z dużym prawdopodobieństwem”, czyli nie każde ryzyko, tylko prawdopodobne, (2) “wysokie ryzyko”, nie jakiekolwiek, tylko wysokie, (3) “przed rozpoczęciem”, DPIA jest narzędziem ex ante, nie ex post.

Art. 35 ust. 3 wymienia trzy obligatoryjne przypadki:

(a) systematyczna, kompleksowa ocena czynników osobowych, oparta na zautomatyzowanym przetwarzaniu, w tym profilowaniu, mająca skutki prawne lub w podobny sposób istotnie wpływająca na osobę
(b) przetwarzanie na dużą skalę szczególnych kategorii danych (art. 9) lub danych dotyczących wyroków skazujących (art. 10)
(c) systematyczne monitorowanie na dużą skalę miejsc publicznych

Grupa Robocza Art. 29 (poprzednik EROD) w wytycznych WP248 z 2017 r. (aktualnych dzisiaj) wskazała dziewięć kryteriów. Operacja, która spełnia dwa lub więcej z nich, powinna być traktowana jako wymagająca DPIA:

ocenianie lub punktacja (scoring)
zautomatyzowane podejmowanie decyzji o skutkach prawnych
systematyczne monitorowanie
dane wrażliwe lub o szczególnym charakterze
przetwarzanie na dużą skalę
łączenie zbiorów danych
dane osób wrażliwych (dzieci, pracowników, osób chorych)
innowacyjne wykorzystanie technologii (AI, IoT, biometria)
uniemożliwianie korzystania z prawa lub usługi

UODO opublikował w 2018 r. (z aktualizacjami) listę rodzajów operacji bezwzględnie wymagających DPIA, m.in. monitoring pracowników, profilowanie konsumentów na dużą skalę, monitoring CCTV w przestrzeni publicznej, przetwarzanie danych biometrycznych do identyfikacji, AI w decyzjach personalnych. Tę listę audytor i IOD powinni znać dokładnie.

Kiedy DPIA NIE jest obowiązkowa (i ważne uściślenia)

Częsta pułapka: zespoły wykonują DPIA dla operacji, które tego nie wymagają (marnując zasoby), lub odwrotnie, pomijają DPIA dla operacji, które wymagają (narażając firmę).

DPIA nie jest wymagana, gdy:

operacja nie generuje wysokiego ryzyka (np. typowa korespondencja e-mailowa z klientami w kontekście pre-RODO ustalonego)
operacja była już oceniona w ramach DPIA na poziomie kategorii (jeśli kontekst się nie zmienił)
art. 35 ust. 10, gdy podstawa prawna jest w prawie UE lub państwa członkowskiego i ocena skutków była przeprowadzona na poziomie legislacyjnym

Wyjątki nie zmieniają jednak ogólnej zasady, że formalna analiza ryzyka jest zawsze potrzebna (na podstawie art. 32 ust. 2 RODO). Granica jest taka: DPIA jest sformalizowaną, pogłębioną analizą ryzyka dla operacji wysokiego ryzyka. Dla pozostałych operacji wystarcza standardowa analiza ryzyka. Brak żadnej analizy = naruszenie RODO niezależnie od tego, czy DPIA była obowiązkowa.

Metodyka DPIA, siedem etapów

Etapy DPIA wynikające z art. 35 ust. 7 RODO oraz wytycznych EROD. W praktyce można rozdzielić proces na siedem etapów wykonywanych sekwencyjnie.

Etap 1: Identyfikacja potrzeby DPIA. Konsultacja z IOD, ocena, czy operacja spełnia kryteria z art. 35 ust. 3 lub WP248. Output: notatka uzasadniająca decyzję o przeprowadzeniu DPIA (lub odmowie). Notatkę zachowuje się w dokumentacji, UODO przy kontroli pyta, czy decyzja “DPIA nie była wymagana” jest udokumentowana.

Etap 2: Opis operacji przetwarzania. Szczegółowy opis: cele, kategorie danych, kategorie podmiotów, źródła, odbiorcy, okresy przechowywania, technologia. Mapa przepływu danych (data flow diagram) jest tutaj wartościowa.

Etap 3: Ocena konieczności i proporcjonalności. Czy cel można osiągnąć mniej inwazyjnie? Czy zakres danych jest minimalny? Czy okres przechowywania jest adekwatny? Czy podmioty mają realne kanały realizacji praw?

Etap 4: Identyfikacja ryzyk dla praw i wolności. Konkretne ryzyka: utrata kontroli nad danymi, dyskryminacja, kradzież tożsamości, naruszenie tajemnicy zawodowej, dyskryminacja społeczna. Każde ryzyko z prawdopodobieństwem (niskie/średnie/wysokie) i wagą wpływu (niska/średnia/wysoka). Metodyka oceny, typowo macierz 3×3 lub 5×5.

Etap 5: Środki techniczne i organizacyjne mitygujące ryzyko. Dla każdego ryzyka, konkretne środki: szyfrowanie, pseudonimizacja, ograniczenie dostępu, audyt logów, szkolenie zespołu, polityka retencji, klauzula informacyjna. Środki muszą być proporcjonalne, DPIA pokazuje, jak.

Etap 6: Ocena ryzyka rezydualnego. Po zastosowaniu środków, jakie ryzyko pozostaje? Czy jest akceptowalne? Jeśli wysokie ryzyko nie zostało zniwelowane do średniego lub niskiego, wymagana konsultacja z UODO przed rozpoczęciem przetwarzania (art. 36).

Etap 7: Dokumentacja i monitorowanie. Pełny raport DPIA, zaakceptowany przez administratora (zarząd lub jego upoważniony przedstawiciel). Plan monitorowania, kiedy DPIA zostanie zaktualizowana (typowo: przy każdej istotnej zmianie operacji lub minimum co 24 miesiące).

Struktura raportu DPIA

Raport DPIA to dokument, który audytor RODO (lub UODO w przypadku kontroli) traktuje jako dowód, że administrator wykonał obowiązek art. 35. Słaba struktura = słaba ochrona. Pełna struktura raportu, do bezpośredniego użycia jako szablon:

Sekcja 1: Metryka dokumentu.

Tytuł operacji przetwarzania
Numer i wersja DPIA
Data utworzenia, data aktualizacji
Autor (typowo IOD)
Akceptujący (administrator danych, zarząd)
Status: roboczy / zaakceptowany / wymagający konsultacji z UODO

Sekcja 2: Opis operacji.

Cel(e) przetwarzania
Kategorie danych
Kategorie podmiotów
Źródła danych
Odbiorcy (wewnętrzni, zewnętrzni procesorzy)
Transfery do krajów trzecich (jeśli dotyczy)
Okresy przechowywania
Technologia (systemy, narzędzia, dostawcy)
Mapa przepływu danych (diagram)

Sekcja 3: Analiza konieczności i proporcjonalności.

Podstawa prawna z uzasadnieniem
Minimalizacja: czy cel można osiągnąć mniejszym zakresem danych?
Klauzula informacyjna: czy podmiot ma pełną informację?
Realizacja praw podmiotów: czy procedury istnieją i są wykonalne?

Sekcja 4: Identyfikacja i ocena ryzyk. Tabela ryzyk:

Lp.	Ryzyko	Prawdopodobieństwo	Wpływ	Ocena (P×W)
1	Nieuprawniony dostęp do bazy klientów	Średnie	Wysoki	Wysokie
2	Profilowanie skutkujące dyskryminacją	Niskie	Wysoki	Średnie
3	Utrata danych (brak backupu)	Niskie	Wysoki	Średnie
…

Sekcja 5: Środki mitygujące. Dla każdego ryzyka, wykaz konkretnych środków technicznych i organizacyjnych.

Sekcja 6: Ryzyko rezydualne.

Ocena po zastosowaniu środków
Czy jest akceptowalne?
Decyzja: kontynuować / konsultować z UODO / zmodyfikować operację / zaniechać

Sekcja 7: Plan monitorowania.

Data następnej aktualizacji
Sytuacje wyzwalające ad hoc aktualizację
Osoba odpowiedzialna

Sekcja 8: Załączniki.

Wyniki konsultacji z podmiotami danych lub ich przedstawicielami (jeśli przeprowadzono)
Opinia IOD
Decyzje administratora

Tak ustrukturyzowany raport DPIA jest jednocześnie dokumentem decyzyjnym i dowodem zgodności w razie kontroli. W audycie RODO audytor szuka tego formatu, jego brak skutkuje ustaleniem o niedostatecznej dokumentacji art. 35.

Jeśli pracujesz jako IOD i chcesz mieć gotowy szablon raportu DPIA w formacie DOCX z wszystkimi sekcjami, tabelami i przykładami wypełnienia dla typowych operacji (monitoring wideo, marketing behawioralny, profilowanie HR, biometria), przygotowujemy taki pakiet jako część newslettera skanujfirme.pl. Zapis bez zobowiązań.

Konsultacja z UODO (art. 36)

Art. 36 RODO: administrator przed rozpoczęciem przetwarzania konsultuje się z organem nadzorczym, jeżeli DPIA wskazuje, że przetwarzanie powodowałoby wysokie ryzyko, gdyby administrator nie zastosował środków w celu zminimalizowania tego ryzyka.

W praktyce: konsultacja jest wymagana, gdy ryzyko rezydualne po wdrożeniu środków pozostaje wysokie. UODO ocenia operację, może zaproponować dodatkowe środki, w skrajnych przypadkach zakazać.

Termin reakcji UODO: do 8 tygodni z możliwością wydłużenia o 6 tygodni. W tym czasie nie można rozpocząć przetwarzania. To istotne dla planowania projektu, operacja wymagająca konsultacji UODO ma minimum 8-tygodniowe opóźnienie w stosunku do planu pierwotnego.

Konsultacje są w Polsce rzadkością, UODO publikuje rocznie raport z liczby konsultacji, typowo kilkadziesiąt. To oznacza, że firmy albo dobrze projektują środki mitygujące (i ryzyko rezydualne nie jest wysokie), albo nie robią DPIA wcale (i nie wiedzą, że powinny konsultować). Drugi scenariusz jest częstszy.

Częste błędy w wykonywaniu DPIA

Błąd 1: DPIA wykonywana ex post. Operacja już ruszyła, “trzeba dorobić DPIA”. To narusza ducha i literę art. 35, DPIA jest narzędziem ex ante.

Błąd 2: Generyczność. Szablon wypełniony ogólnikami (“ryzyko: utrata danych, środek: szyfrowanie”), bez konkretów. UODO odrzuca takie DPIA w kontrolach.

Błąd 3: Brak udziału biznesu. DPIA wykonana wyłącznie przez IOD bez konsultacji z właścicielem operacji. Wynik: środki nieadekwatne lub niewykonalne operacyjnie.

Błąd 4: Brak udziału podmiotów danych. Art. 35 ust. 9 wskazuje, że administrator powinien “w razie potrzeby zasięgnąć opinii osób, których dane dotyczą lub ich przedstawicieli”. To nie jest często wykonywane, ale dla operacji wysokiego ryzyka (np. monitoring pracowników), istotne.

Błąd 5: Brak monitorowania. DPIA wykonana raz, operacja się zmienia, DPIA nie jest aktualizowana. Po 12 miesiącach dokument jest oderwany od rzeczywistości.

Błąd 6: Brak akceptacji administratora. DPIA podpisana tylko przez IOD, bez akceptacji zarządu. To oznacza, że administrator danych nie wyraził formalnej decyzji o akceptacji ryzyka rezydualnego.

Trzy pytania kontrolne dla IOD przed DPIA

Pierwsze. Czy mam pełną mapę operacji przetwarzania wymagających DPIA? Bez tego nie wiem, ile DPIA muszę przygotować. Klasyczne źródło: rejestr czynności przetwarzania (RCP) + analiza ryzyka per operacja + lista UODO operacji bezwzględnie wymagających.

Drugie. Czy proces DPIA jest zintegrowany z procesem wdrażania nowych projektów IT? Jeśli DPIA “doczepia się” po zakończeniu projektu, jest fasadą. Jeśli jest częścią gate’u w project management, jest narzędziem decyzyjnym.

Trzecie. Czy zarząd wie, że DPIA jest narzędziem decyzyjnym? Jeśli administrator danych traktuje DPIA jako formalność IOD, nie podejmuje świadomych decyzji o akceptacji ryzyka. To powracający temat w decyzjach UODO, zarząd ponosi odpowiedzialność za decyzje DPIA.

Esencja

DPIA jest sformalizowaną, pogłębioną analizą ryzyka dla operacji wysokiego ryzyka przetwarzania danych osobowych. Obligatoryjna w trzech przypadkach z art. 35 ust. 3 oraz w operacjach spełniających minimum dwa z dziewięciu kryteriów WP248. Brak DPIA dla operacji wymagającej = naruszenie RODO niezależnie od pozostałych zabezpieczeń.

Metodyka siedmioetapowa: (1) identyfikacja potrzeby, (2) opis operacji, (3) konieczność i proporcjonalność, (4) identyfikacja ryzyk, (5) środki mitygujące, (6) ryzyko rezydualne, (7) monitorowanie. Każdy etap musi być udokumentowany. Output to raport DPIA w spójnej strukturze, akceptowany przez administratora.

Konsultacja z UODO (art. 36) wymagana, gdy ryzyko rezydualne po mitygacjach pozostaje wysokie. Termin reakcji UODO: do 8 tygodni, możliwość wydłużenia o 6 tygodni. Projekty wymagające konsultacji muszą uwzględnić ten bufor.

Klasyczne błędy: DPIA wykonywana ex post, generyczność szablonów, brak udziału biznesu, brak akceptacji administratora, brak aktualizacji. Każdy z tych błędów jest osobno punktowany w audycie i może skutkować ustaleniem o naruszeniu art. 35.

DPIA wykonana właściwie jest narzędziem zarządu, nie tylko IOD. Pokazuje decydentom, że konkretna operacja niesie konkretne ryzyko, które jest niwelowane lub akceptowane. Bez tej świadomości administrator nie pełni roli przewidzianej w RODO, pełni rolę formalnego sygnatariusza dokumentu, który nie rozumie.

W audycie RODO art. 35 jest jednym z najszybciej weryfikowanych obszarów, audytor patrzy na listę operacji wysokiego ryzyka i sprawdza, czy dla każdej istnieje aktualna DPIA. Luki są widoczne w 30 minut.

Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. (RODO), art. 35, Ocena skutków dla ochrony danych, art. 36, Uprzednie konsultacje. https://eur-lex.europa.eu/eli/reg/2016/679/oj
Grupa Robocza Art. 29 (2017). Wytyczne w sprawie oceny skutków dla ochrony danych (DPIA) WP248 rev.01. (Aktualne dzisiaj jako wytyczne EROD). https://ec.europa.eu/newsroom/article29/items/611236
EROD/EDPB (2020). Guidelines 05/2020 on consent under Regulation 2016/679. https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/
UODO (2018, z aktualizacjami). Komunikat Prezesa UODO w sprawie wykazu rodzajów operacji przetwarzania danych osobowych wymagających DPIA. https://uodo.gov.pl/pl/138
UODO (2024). Sprawozdanie roczne Prezesa UODO 2023, sekcja DPIA i konsultacje uprzednie. https://uodo.gov.pl/pl/sprawozdania-roczne
ENISA (2017). Handbook on Security of Personal Data Processing. https://www.enisa.europa.eu/publications/handbook-on-security-of-personal-data-processing
CNIL (2018). PIA, Privacy Impact Assessment, Methodology. Commission Nationale de l'Informatique et des Libertés. https://www.cnil.fr/en/privacy-impact-assessment-pia
ISO/IEC 29134:2017. Guidelines for privacy impact assessment. International Organization for Standardization.
ICO (UK). Data protection impact assessments (DPIAs), detailed guidance. https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/data-protection-impact-assessments-dpias/
Polska Ustawa z dnia 10 maja 2018 r. o ochronie danych osobowych (Dz.U. 2018 poz. 1000 ze zm.)

Audyt RODO art. 32, bezpieczeństwo techniczne i organizacyjne w praktyce

Marek Porycki — Tue, 28 Jul 2026 15:12:00 +0000

Artykuł 32 RODO jest najbardziej cytowanym i najtrudniej audytowalnym przepisem rozporządzenia. Wymaga, by administrator i procesor wdrożyli “odpowiednie środki techniczne i organizacyjne, aby zapewnić stopień bezpieczeństwa odpowiadający ryzyku”. W tekście rozporządzenia są tylko cztery konkretne przykłady, pseudonimizacja i szyfrowanie, zdolność do zapewnienia poufności, integralności, dostępności i odporności systemów, zdolność do szybkiego przywrócenia dostępności, regularne testowanie skuteczności środków. Resztę zostawia kontrolerom danych.

Ta otwartość art. 32 jest jednocześnie jego siłą (skalowalność do różnych firm) i słabością (niejednoznaczność audytowa). UODO w decyzjach z lat 2020-2025 sukcesywnie precyzuje, co dla średniej polskiej firmy oznacza “odpowiednie środki”. Audytor RODO musi znać te decyzje, znać standardy techniczne (ISO 27001, NIST SP 800-53), znać typową architekturę IT polskiej firmy i połączyć to w spójną metodologię.

Ten tekst jest pełną metodologią audytu zgodności z art. 32. Strukturuje się wokół czterech kategorii środków (kryptografia, ciągłość, monitoring, organizacja), dla każdej podaje pytania, dowody, testy techniczne i kryteria oceny.

Co dokładnie wymaga art. 32

Tekst art. 32 ust. 1 RODO: “Uwzględniając stan wiedzy technicznej, koszt wdrażania oraz charakter, zakres, kontekst i cele przetwarzania oraz ryzyko naruszenia praw lub wolności osób fizycznych o różnym prawdopodobieństwie wystąpienia i wadze zagrożenia, administrator i podmiot przetwarzający wdrażają odpowiednie środki techniczne i organizacyjne”.

Cztery przykłady w ust. 1 lit. a-d:

(a) pseudonimizacja i szyfrowanie danych osobowych
(b) zdolność do ciągłego zapewnienia poufności, integralności, dostępności i odporności systemów i usług przetwarzania
(c) zdolność do szybkiego przywrócenia dostępności danych osobowych i dostępu do nich w razie incydentu fizycznego lub technicznego
(d) regularne testowanie, mierzenie i ocenianie skuteczności środków technicznych i organizacyjnych mających zapewnić bezpieczeństwo przetwarzania

Art. 32 ust. 2 dodaje: “Oceniając, czy stopień bezpieczeństwa jest odpowiedni, uwzględnia się w szczególności ryzyko wiążące się z przetwarzaniem, w szczególności wynikające z przypadkowego lub niezgodnego z prawem zniszczenia, utraty, modyfikacji, nieuprawnionego ujawnienia lub nieuprawnionego dostępu”.

Audyt zgodności z art. 32 oznacza więc weryfikację: czy firma przeprowadziła analizę ryzyka, czy na jej podstawie wybrała środki, czy wdrożyła je technicznie, czy regularnie testuje skuteczność. Wszystkie cztery elementy muszą występować. Brak analizy ryzyka = automatycznie niezgodność, nawet jeśli wdrożone środki są zaawansowane.

Kategoria 1: Środki kryptograficzne (pseudonimizacja i szyfrowanie)

Dokumenty do zebrania. Polityka kryptograficzna firmy, lista systemów z włączonym szyfrowaniem (w spoczynku i w tranzycie), polityka zarządzania kluczami kryptograficznymi, dokumentacja KMS (Key Management System) jeśli używany, raporty z audytów konfiguracji TLS.

Pytania do wywiadu z IT/CISO. Które bazy danych z danymi osobowymi są szyfrowane w spoczynku (encryption at rest)? Jaką wersję TLS wymuszacie? Jak zarządzacie kluczami kryptograficznymi, gdzie są przechowywane, kto ma dostęp, jak są rotowane? Czy stosujecie pseudonimizację w środowiskach nieprodukcyjnych (test, dev, staging)?

Testy techniczne. Audytor wybiera trzy bazy danych zawierające dane osobowe. Dla każdej weryfikuje: czy faktycznie jest szyfrowanie na poziomie storage (TDE w SQL Server, encryption at rest w PostgreSQL, ATRest w MongoDB), jakim algorytmem (AES-256 jako standard, AES-128 jako minimum, wszystko poniżej = ustalenie), jak są zabezpieczone klucze (oddzielnie od bazy, idealnie w HSM lub cloud KMS). Drugi test: skan TLS portali zewnętrznych przy użyciu narzędzia takiego jak SSL Labs lub testssl.sh, sprawdza wersje TLS, suity szyfrów, problemy z certyfikatami.

Częste ustalenia.

Baza produkcyjna szyfrowana, ale środowiska dev/test z kopią produkcji bez szyfrowania i bez pseudonimizacji (klasyczny błąd, częsta przyczyna naruszeń).
Klucze szyfrowania w tym samym serwerze co dane (równoznaczne z brakiem szyfrowania w kontekście ataku z dostępem do serwera).
TLS 1.0/1.1 nadal aktywne na starszych portalach (poniżej standardu od 2020).
Brak polityki rotacji kluczy lub polityka istniejąca, ale niewykonywana.

Powiązany obszar: audyt kryptografii (NIS2 art. 21(2)(h) + RODO art. 32), szczegółowa metodologia.

Kategoria 2: Poufność, integralność, dostępność, odporność (CIA-R)

Co wchodzi w zakres. Kontrola dostępu, segregacja środowisk, monitoring zmian (integralność), zarządzanie tożsamością, MFA, monitorowanie nieautoryzowanych zmian danych, zabezpieczenia przed DDoS.

Dokumenty do zebrania. Polityka kontroli dostępu, polityka MFA, polityka segregacji obowiązków, lista użytkowników uprzywilejowanych, raporty access review, dokumentacja architektury sieci (segmentacja), polityka logowania (które systemy logują, gdzie są logi, jak długo, kto ma dostęp).

Pytania do wywiadu. Jakie systemy zawierające dane osobowe mają wymuszone MFA? Jak często robicie access review i co z tego wynika? Jak długo trwa od momentu wypowiedzenia umowy do zablokowania wszystkich kont byłego pracownika? Czy macie segregację środowisk (produkcja oddzielona od test/dev na poziomie sieciowym i tożsamości)?

Testy techniczne.

Test MFA: audytor prosi o pokazanie konfiguracji MFA w trzech systemach krytycznych z danymi osobowymi (np. CRM, system kadrowo-płacowy, baza klientów). Sprawdza realny stan, nie deklarowany.
Test off-boardingu: lista 5 osób, które odeszły w ostatnim miesiącu, czy konta są zablokowane, kiedy, w jakich systemach.
Test kont uprzywilejowanych: lista kont admin/root, weryfikacja czy są aktualnie potrzebne, czy są MFA, czy logi są audytowalne.
Test segregacji: czy konsultant developerski może wejść z produkcji do bazy produkcyjnej? Czy są mosty między dev a prod?

Kryteria oceny. Standard 2026: MFA dla wszystkich kont uprzywilejowanych (100%), MFA dla wszystkich systemów zewnętrznie dostępnych (VPN, panele cloud, e-mail), access review minimum raz na 6 miesięcy, off-boarding do 24h od końca umowy, pełna segregacja środowisk (oddzielne tożsamości, nie tylko sieciowo).

Pełna metodologia tego obszaru: audyt MFA i kontroli dostępu.

Kategoria 3: Zdolność do przywrócenia dostępności (BCP/DR dla danych osobowych)

Co wchodzi w zakres. Backupy danych osobowych, plan disaster recovery, test odtwarzania, RPO/RTO udokumentowane.

Dokumenty do zebrania. Polityka backupów (z konkretnymi RPO/RTO per system z danymi osobowymi), raporty z testów odtwarzania (DR drill) z ostatnich 24 miesięcy, mapa systemów-zależności, plan komunikacji kryzysowej dla naruszenia dostępności.

Pytania do wywiadu. Jaki RPO/RTO masz dla bazy klientów? Kiedy ostatnio testowałeś przywrócenie z backupu i z jakim wynikiem? Co się stanie z danymi osobowymi, jeśli serwer w głównej lokalizacji jest niedostępny przez 7 dni? Czy backupy mają immutable retention (odporność na ransomware)?

Testy techniczne. Audytor prosi o przywrócenie wybranej tabeli z bazą klientów z backupu z konkretnego dnia w ostatnim miesiącu. Mierzy czas, sprawdza spójność danych. To jest test krytyczny, sam fakt, że backupy istnieją, nie znaczy nic. Druga próba: czy backup jest off-site (poza główną lokalizacją), trzecia, czy jest air-gapped lub immutable.

Kryteria oceny. Minimum dla art. 32: regularne testy odtwarzania (minimum raz w roku, idealnie kwartalnie), backupy w strategii 3-2-1 (3 kopie, 2 nośniki, 1 off-site), immutable lub air-gapped dla danych krytycznych.

Powiązany obszar: audyt ciągłości działania (BCP/DR).

Kategoria 4: Regularne testowanie i ocenianie skuteczności

To kategoria, w której większość polskich firm jest słabo audytowana, bo skupia się na implementacji (“mamy MFA, mamy szyfrowanie”) zamiast na weryfikacji skuteczności (“czy MFA jest faktycznie używany, czy są obejścia, jaka jest pokrycie”).

Dokumenty do zebrania. Harmonogram testów penetracyjnych (z ostatnich 24 miesięcy), raporty pentestów, harmonogram skanów podatności, raporty z testów phishing simulations, raporty z testów DR, plan przeglądu skuteczności środków technicznych i organizacyjnych.

Pytania do wywiadu. Kiedy ostatnio robiłeś pentest systemów zawierających dane osobowe, jaki był zakres i kto wykonywał? Jak często robisz vulnerability scanning i jakim narzędziem? Czy w ramach przygotowania do art. 32 wykonano formalną ocenę skuteczności środków przez niezależną stronę?

Testy techniczne. Audytor sprawdza ostatni raport pentestu, co było w scopie, jakie podatności znaleziono, jaki jest aktualny status remediacji. Drugi test: ostatni vulnerability scan, czy są CVE krytyczne starsze niż 30 dni bez remediacji i czy są mitigants kompensujące.

Kryteria oceny. Pentesty: minimum raz w roku dla systemów zewnętrznych, raz na 2 lata dla wewnętrznych krytycznych. Skany podatności: minimum miesięczne dla infrastruktury, ciągłe dla aplikacji webowych. Phishing simulations: kwartalne. Przegląd skuteczności środków: roczny, formalny, z udziałem IOD i CISO.

Powiązanie art. 32 z analizą ryzyka

Kluczowa pułapka audytowa: art. 32 RODO wymaga, by środki bezpieczeństwa były “odpowiednie do ryzyka”. To znaczy, że bez przeprowadzonej analizy ryzyka nie da się formalnie ocenić, czy środki są wystarczające. Audytor musi sprawdzić:

Czy firma przeprowadziła analizę ryzyka dla każdej kluczowej operacji przetwarzania (typowo: kadry, marketing, klienci, dostawcy, monitoring pracowników, dane zdrowotne jeśli applicable).
Czy analiza ryzyka identyfikuje ryzyka specyficzne dla typu danych (np. ryzyko dyskryminacji przy danych zdrowotnych, ryzyko stalkingu przy danych lokalizacyjnych).
Czy wybór środków bezpieczeństwa jest uzasadniony wynikiem analizy ryzyka.
Czy istnieje udokumentowane ryzyko rezydualne, zaakceptowane formalnie.

Bez tej dokumentacji audyt art. 32 nie może zakończyć się oceną pozytywną, nawet jeśli wdrożone środki są zaawansowane. UODO w kilku decyzjach (m.in. nakaz wobec spółki energetycznej z 2023 r.) wprost wskazał brak analizy ryzyka jako podstawową przyczynę naruszenia art. 32, mimo wdrożonych konkretnych środków technicznych.

Jeśli odpowiadasz za przygotowanie firmy do takiego audytu i potrzebujesz szablonu analizy ryzyka dla typowych operacji przetwarzania (z gotową listą zagrożeń, prawdopodobieństw i wpływów), warto zapisać się do newslettera skanujfirme.pl, przesyłamy template’y formalnej analizy ryzyka RODO w XLSX/DOCX, użyteczne jako baza do dostosowania.

Format ustaleń w raporcie audytu art. 32

Każde ustalenie z audytu art. 32 powinno mieć w raporcie strukturę spójną z innymi obszarami audytu. Przykład typowego ustalenia:

Ustalenie 32-04 (klasyfikacja: wysokie): Baza klientów w systemie CRM zawierająca dane osobowe 47 000 osób nie ma włączonego szyfrowania w spoczynku.

Dowody: (1) Wywiad z administratorem CRM (data, imię); (2) Konfiguracja serwera bazy danych zweryfikowana przez audytora (data, opis weryfikacji); (3) Brak polityki szyfrowania CRM w dokumentacji RODO.

Ryzyko prawne: Naruszenie art. 32 ust. 1 lit. a RODO. W przypadku naruszenia (kradzież dysku, dostęp nieautoryzowany na poziomie systemu plików) ekspozycja danych osobowych ze skutkiem prawnym (obowiązek zgłoszenia do UODO i osób), reputacyjnym i finansowym.

Rekomendacja korygująca: Włączenie szyfrowania na poziomie storage (TDE) lub na poziomie wybranych kolumn (column-level encryption dla pól PESEL, adres, telefon). Termin docelowy: 60 dni. Odpowiedzialny: dyrektor IT. Szacunkowy koszt: 0 zł (funkcjonalność dostępna w licencji SQL Server Enterprise).

Mitigant kompensujący do czasu remediacji: Ograniczenie dostępu na poziomie sieci do serwera bazy do 3 administratorów, włączenie audytu na poziomie systemu operacyjnego, codzienna weryfikacja logów.

Taki format pozwala zarządowi podejmować decyzje świadomie, widzi ryzyko, koszt, czas, odpowiedzialnego. To jest różnica między raportem audytowym a luźną listą obserwacji.

Trzy pytania kontrolne dla IOD przed audytem art. 32

Pierwsze. Czy mamy aktualny rejestr czynności przetwarzania (RCP)? Jeśli nie, audyt art. 32 nie może się zacząć, bo nie wiadomo, jakie operacje są w zakresie. Najpierw uzupełnij RCP, potem audyt.

Drugie. Czy zrobiliśmy analizę ryzyka dla operacji wysokiego ryzyka? Jeśli przetwarzasz dane zdrowotne, dane dzieci, dane biometryczne, dane lokalizacyjne na dużą skalę, dane finansowe wrażliwe, formalna analiza ryzyka jest punktem wyjścia, nie outputem.

Trzecie. Czy mamy zewnętrzne dowody skuteczności (pentesty, certyfikaty, audyty)? UODO traktuje brak takich dowodów jako sygnał, że firma “deklaruje, ale nie weryfikuje”. W audycie art. 32 zewnętrzne dowody zwiększają wiarygodność oceny o jeden poziom dojrzałości.

Esencja

Audyt RODO art. 32 nie jest audytem checklisty. Jest oceną adekwatności środków technicznych i organizacyjnych do ryzyka przetwarzania. Cztery elementy muszą wystąpić: środki kryptograficzne (pseudonimizacja, szyfrowanie), CIA-R systemów (poufność, integralność, dostępność, odporność), zdolność do przywrócenia, regularne testowanie skuteczności. Brak któregokolwiek elementu = niezgodność.

Punkt krytyczny: art. 32 wymaga, by środki były odpowiednie do ryzyka. Bez przeprowadzonej analizy ryzyka żaden audyt nie zakończy się pozytywnie, nawet jeśli wdrożone środki techniczne są zaawansowane. UODO konsekwentnie wskazuje brak analizy ryzyka jako przyczynę pierwotną naruszeń.

Cztery kategorie metodologii, kryptografia, CIA-R, BCP/DR, testowanie skuteczności, wymagają różnych dowodów i różnych testów technicznych. Audytor nie może opierać się tylko na dokumentach. Musi weryfikować konfiguracje techniczne, robić skany TLS, prosić o przywrócenie z backupu, sprawdzać raporty pentestów, weryfikować realny stan MFA. Audyt deklaratywny (tylko dokumenty) jest niewystarczający dla art. 32.

Format ustaleń w raporcie audytowym musi wiązać ustalenie z dowodami, ryzykiem prawnym, rekomendacją i mitigantem kompensującym. Bez tej struktury raport nie jest narzędziem decyzyjnym dla zarządu. UODO oceniając poszczególne firmy patrzy na ten format, udokumentowana świadomość ryzyka i plan korygujący istotnie wpływają na łagodzenie sankcji.

W 2026 roku art. 32 RODO i art. 21 NIS2 są reżimami zharmonizowanymi w zakresie technicznym (kryptografia, MFA, ciągłość, monitoring), ale różnymi w celu (RODO chroni osoby fizyczne, NIS2 chroni infrastrukturę). Firma robi jedno wdrożenie techniczne i dwa odrębne audyty z dwoma raportami. Lub jeden audyt zharmonizowany, który omawia oba reżimy, to oszczędność znacząca, ale wymagająca audytora znającego oba systemy.

Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. (RODO/GDPR), art. 32, Bezpieczeństwo przetwarzania. https://eur-lex.europa.eu/eli/reg/2016/679/oj
UODO (2023). Decyzje Prezesa UODO 2018-2023, bezpieczeństwo przetwarzania (art. 32). https://uodo.gov.pl/pl/138
EROD/EDPB (2022). Guidelines 9/2022 on personal data breach notification under GDPR. European Data Protection Board. https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/
ENISA (2021). Handbook on Security of Personal Data Processing. European Union Agency for Cybersecurity. https://www.enisa.europa.eu/publications/handbook-on-security-of-personal-data-processing
ISO/IEC 27701:2019. Privacy Information Management, Extension to ISO/IEC 27001 and ISO/IEC 27002. International Organization for Standardization.
NIST SP 800-53 Rev. 5 (2020). Security and Privacy Controls for Information Systems and Organizations. https://doi.org/10.6028/NIST.SP.800-53r5
NIST SP 800-57 Part 1 Rev. 5 (2020). Recommendation for Key Management, Part 1: General. https://doi.org/10.6028/NIST.SP.800-57pt1r5
Mozilla TLS Configuration Recommendations. https://wiki.mozilla.org/Security/Server_Side_TLS
Polska Ustawa z dnia 10 maja 2018 r. o ochronie danych osobowych (Dz.U. 2018 poz. 1000 ze zm.)
UODO. Wytyczne w sprawie zgłaszania naruszeń ochrony danych osobowych (2019, aktualizacja 2022). https://uodo.gov.pl/

Audyt NIS2 art. 21 krok po kroku, pełna metodologia audytora dla 10 obszarów

Marek Porycki — Thu, 23 Jul 2026 12:49:00 +0000

Dyrektywa NIS2 (UE 2022/2555) w artykule 21 wymienia dziesięć obszarów, w których podmiot kluczowy lub istotny musi wdrożyć “odpowiednie i proporcjonalne środki techniczne, operacyjne i organizacyjne zarządzania ryzykiem”. Tekst dyrektywy nie podaje, jak audytor ma to zweryfikować. Polska Ustawa o krajowym systemie cyberbezpieczeństwa w wersji znowelizowanej (status: projekt na maj 2026) również nie definiuje metodologii. ENISA opublikowała wytyczne implementacyjne (Technical Implementation Guidance, 2024), ale są one ukierunkowane na podmiot, nie na audytora.

Ten tekst jest tym, czego brakuje pomiędzy literą dyrektywy a praktyką: pełną metodologią audytora dla każdego z dziesięciu obszarów art. 21. Dla każdego obszaru: jakie pytania zadać, jakie dokumenty zebrać, jakie testy techniczne wykonać, jak ocenić dojrzałość i jak sformułować ustalenie.

Założenie ogólne: audyt NIS2 art. 21 nie ocenia “czy firma jest zgodna” w sensie binarnym. Ocenia dojrzałość każdego obszaru w skali wielopunktowej, lokalizuje luki względem stanu pożądanego i formułuje rekomendacje korygujące. Wynikiem audytu jest raport z mierzalną oceną oraz plan działań naprawczych. Czas wykonania pełnego audytu dla średniej firmy (50-250 pracowników): 6-10 tygodni pracy audytora plus zaangażowanie zespołu wewnętrznego (estymacja 80-160 godzin po stronie firmy).

Struktura audytu, pięć faz przekrojowych

Niezależnie od obszaru, każdy element audytu NIS2 przechodzi przez pięć faz, których audytor nie powinien skracać.

Faza A: planowanie i scope. Definicja zakresu (czy audyt obejmuje wszystkie systemy IT, czy wybrane krytyczne; czy obejmuje wszystkie lokalizacje, czy główną siedzibę), ustalenie zespołu po stronie firmy, harmonogram, lista wymaganych dokumentów do przygotowania przed startem (typowo 30-60 pozycji).

Faza B: zebranie dowodów. Trzy źródła równolegle: dokumenty (polityki, procedury, rejestry, raporty), wywiady (z osobami pełniącymi role kluczowe, CISO, IOD, IT manager, członkowie zarządu, wybrani pracownicy operacyjni), obserwacja i testy techniczne (przegląd konfiguracji, walk-through procesów, próby symulacyjne).

Faza C: ocena dojrzałości. Dla każdego obszaru: skala 0-5 (0 = nie istnieje, 1 = ad hoc, 2 = repetytywne, 3 = zdefiniowane i udokumentowane, 4 = zarządzane z metrykami, 5 = zoptymalizowane z ciągłym doskonaleniem). Każdy poziom ma jasne kryteria, co audytor musi zobaczyć, by uznać że jest na tym poziomie.

Faza D: analiza luki. Porównanie aktualnej dojrzałości z poziomem docelowym (dla NIS2 typowo poziom 3 jako minimum dla podmiotów kluczowych, poziom 2 jako minimum dla istotnych). Identyfikacja luk, oszacowanie ryzyka rezydualnego, hierarchia priorytetów.

Faza E: raport i plan działań. Raport zawiera: ocenę w 10 obszarach (skala 0-5), listę ustaleń (findings) z klasyfikacją (krytyczne, wysokie, średnie, niskie), plan działań naprawczych (CAPA, Corrective and Preventive Actions) z odpowiedzialnymi i terminami. Format zgodny z raportem audytowym dla zarządu.

Te pięć faz powtarza się równolegle dla każdego z dziesięciu obszarów. Czas faz A i E jest stały (po około tydzień), fazy B i C zajmują 4-7 tygodni, faza D, tydzień.

Obszar 1: Polityka analizy ryzyka i bezpieczeństwa systemów IT (art. 21(2)(a))

Co dyrektywa wymaga. Firma musi mieć udokumentowaną politykę zarządzania ryzykiem cybernetycznym, opartą na metodyce (ISO/IEC 27005, NIST RMF lub równoważne), z regularnym przeglądem (minimum raz w roku) oraz integracją z ogólnym systemem zarządzania ryzykiem firmy.

Dokumenty do zebrania. Polityka zarządzania ryzykiem cybernetycznym (dokument formalny, podpisany przez zarząd), rejestr ryzyk (risk register) z aktualną datą aktualizacji, metodyka wyceny ryzyka (jak liczone są prawdopodobieństwo i wpływ), protokoły z ostatnich przeglądów ryzyka (minimum z ostatnich 24 miesięcy), raporty dla zarządu z zarządzania ryzykiem.

Pytania do wywiadu z CISO/dyrektorem IT. Kto jest odpowiedzialny za politykę? Kiedy ostatnio była aktualizowana? Jakie są pięć top ryzyk cybernetycznych firmy w tym kwartale i jakie mitigants są wdrożone? Jak ryzyko cybernetyczne jest integrowane z ogólnym risk managementem firmy (ERM)? Czy zarząd kwartalnie omawia top ryzyka cybernetyczne?

Testy do wykonania. Audytor wybiera trzy aktywa krytyczne (np. system ERP, baza klientów, system płacowy) i prosi o przedstawienie kompletnej analizy ryzyka dla każdego, od identyfikacji zagrożeń, przez wycenę prawdopodobieństwa i wpływu, po wybrane środki kontrolne i ryzyko rezydualne. Sprawdza spójność z polityką ogólną.

Kryteria oceny dojrzałości.

Poziom 0: brak polityki lub polityka istniejąca tylko formalnie, bez stosowania.
Poziom 1: polityka jest, ale stosowana ad hoc, jeden risk register, ale nieaktualizowany.
Poziom 2: polityka stosowana w niektórych obszarach (zwykle IT), nie wszędzie, aktualizowana okazjonalnie.
Poziom 3: polityka kompletnie udokumentowana, stosowana w całej firmie, aktualizowana raz w roku z udziałem zarządu, risk register aktualny.
Poziom 4: poziom 3 + metryki skuteczności (KRI, Key Risk Indicators), kwartalne przeglądy zarządu, integracja z ERM.
Poziom 5: poziom 4 + ciągłe doskonalenie metodyki, benchmarking z branżą, threat intelligence aktywnie wykorzystywane w aktualizacji rejestru.

Częste ustalenia. Większość polskich średnich firm jest na poziomie 1-2: polityka istnieje, ale w wersji ogólnikowej, risk register prowadzony jest przez jedną osobę (zwykle dyrektor IT) bez udziału biznesu, zarząd nie ma kwartalnych raportów. Aby przekroczyć poziom 3, firma potrzebuje formalnej metodyki, dedykowanego CISO lub osoby odpowiedzialnej za risk management, oraz włączenia ryzyka cybernetycznego do agendy zarządu.

Obszar 2: Obsługa incydentów cyberbezpieczeństwa (art. 21(2)(b))

Co dyrektywa wymaga. Procedury wykrywania, analizy, zawiadamiania, reagowania i analizy poincydentalnej. Powiązanie z obowiązkiem raportowania do CSIRT-u w terminach 24h / 72h / 1 miesiąc.

Dokumenty do zebrania. Incident Response Plan (IRP), formalny dokument, lista członków zespołu reagowania (CSIRT wewnętrzny lub osoby pełniące tę rolę), procedury eskalacji, runbooki dla typowych scenariuszy (ransomware, phishing, DDoS, naruszenie danych, kompromitacja konta uprzywilejowanego), rejestr incydentów z ostatnich 24 miesięcy z klasyfikacją, raporty post-incident review (PIR), umowy z zewnętrznym SOC lub forensykami (jeśli outsourcowane).

Pytania do wywiadu. Ile incydentów było w ostatnich 12 miesiącach (w podziale na poziomy)? Pokaż ostatni raport PIR, co się stało, jak długo trwało wykrycie, kontener, mitygacja? Jakie scenariusze macie w runbookach i kiedy je ostatnio ćwiczyliście? Kto budzi członka zarządu o 3:00 w nocy przy krytycznym incydencie?

Testy do wykonania. Symulacja stołowa (tabletop exercise) typowego scenariusza, np. ransomware. Audytor prowadzi scenariusz: “10 maja 2026 o 02:14 monitoring SOC zgłasza, że 80 stacji w dziale księgowości jest zaszyfrowanych, w notatce ransomware żądanie 800 000 EUR w bitcoin w ciągu 72h”. Audytor obserwuje: kto jest powiadamiany, w jakim czasie, jakie decyzje są podejmowane, jakie zewnętrzne strony są kontaktowane (CSIRT NASK, ubezpieczyciel, prawnicy, klienci, UODO jeśli RODO), kiedy zarząd otrzymuje pierwszą informację.

Kryteria oceny dojrzałości.

Poziom 0: brak formalnego IRP, “ogarniamy jak przyjdzie”.
Poziom 1: IRP istnieje, ale w wersji generycznej, nieaktualizowanej, nikt nigdy nie ćwiczył.
Poziom 2: IRP + runbooki dla 1-2 scenariuszy, jedno ćwiczenie w przeszłości, niezbyt świeże.
Poziom 3: IRP + 5+ runbooków + roczne ćwiczenia + pełen rejestr incydentów + PIR po każdym poważnym incydencie.
Poziom 4: poziom 3 + metryki MTTD (Mean Time To Detect) i MTTR (Mean Time To Respond), kwartalne ćwiczenia, integracja z SOAR.
Poziom 5: poziom 4 + threat hunting proaktywny, purple teaming, ciągłe doskonalenie runbooków.

Częste ustalenia. W połowie polskich średnich firm IRP jest “u jednego kolesia w głowie”, IT manager wie co robić, ale nikt poza nim. Brak ćwiczeń to standard. Polskie CSIRT-y (NASK, CERT.GOV.PL, sektorowe) raportują, że pierwsze 60 minut po incydencie firmy zwykle marnują na ustalanie kto kogo powiadomi.

Obszar 3: Ciągłość działania, kopie zapasowe i zarządzanie kryzysowe (art. 21(2)(c))

Co dyrektywa wymaga. Plan ciągłości działania (BCP), plan disaster recovery (DR), strategia kopii zapasowych, plan komunikacji kryzysowej, zarządzanie kryzysem. Wszystko z udokumentowanymi RTO (Recovery Time Objective) i RPO (Recovery Point Objective) dla kluczowych usług.

Dokumenty do zebrania. Business Continuity Plan z analizą BIA (Business Impact Analysis), Disaster Recovery Plan z mapą zależności systemów, polityka kopii zapasowych, raporty z testów DR z ostatnich 24 miesięcy, plan komunikacji kryzysowej, lista alternatywnych lokalizacji pracy.

Pytania do wywiadu. Jaki masz RTO dla systemu finansowego? Kiedy ostatnio testowaliście DR i z jakim wynikiem? Co się stanie z firmą jeśli serwerownia w głównej lokalizacji jest niedostępna przez 7 dni? Kto decyduje o ogłoszeniu sytuacji kryzysowej?

Testy do wykonania. Test backupu: audytor wybiera trzy systemy krytyczne, prosi o przywrócenie z backupu wybranego dnia z ostatnich 30 dni. Sprawdza czy proces działa, ile trwa, czy dane są spójne. To jest kluczowy test, sam fakt istnienia backupów nie znaczy nic bez weryfikacji odzyskiwania.

Kryteria oceny dojrzałości.

Poziom 0: backupy może są, plan BCP nie istnieje.
Poziom 1: backupy są (3-2-1 nieprzestrzegane), BCP w wersji generycznej.
Poziom 2: 3-2-1 wdrożone, BCP istnieje, jedno testowanie odzyskiwania w przeszłości.
Poziom 3: BCP + DR + BIA + RTO/RPO udokumentowane dla wszystkich systemów krytycznych, roczne testy DR, kopie immutable.
Poziom 4: poziom 3 + kwartalne testy DR, automatyczna weryfikacja integralności backupów, off-site air-gapped copies.
Poziom 5: poziom 4 + active-active multi-site, chaos engineering, ciągła weryfikacja.

Szczegóły metodologii dla tego obszaru: audyt ciągłości działania (BCP/DR).

Obszar 4: Bezpieczeństwo łańcucha dostaw (art. 21(2)(d))

Co dyrektywa wymaga. Identyfikacja dostawców krytycznych, ocena ryzyka per dostawca, klauzule bezpieczeństwa w umowach, monitorowanie zgodności dostawców, plan reakcji na incydent po stronie dostawcy.

Dokumenty do zebrania. Mapa dostawców z klasyfikacją (krytyczny / istotny / standardowy), oceny ryzyka per dostawca krytyczny, wzory klauzul bezpieczeństwa stosowane w umowach, raporty z due diligence (SOC 2, ISO 27001, audyty wewnętrzne), procedura on-boardingu nowego dostawcy.

Pytania do wywiadu. Ilu macie dostawców krytycznych i według jakich kryteriów ich klasyfikujecie? Pokaż umowę z dostawcą krytycznym, gdzie są klauzule cyberbezpieczeństwa? Co się stanie jeśli dostawca cloud (np. AWS, Azure) ma 48-godzinny incydent? Czy monitorujecie zgodność dostawców regularnie czy tylko przy podpisaniu?

Testy do wykonania. Audytor wybiera trzech dostawców krytycznych. Dla każdego prosi o: aktualną ocenę ryzyka (nie starszą niż 12 miesięcy), kompletną umowę z klauzulami, dokumenty potwierdzające zgodność (certyfikaty), historię incydentów. Sprawdza, czy klauzule umowne pokrywają minimum: prawo do audytu, obowiązek raportowania incydentów, klauzule o sub-procesorach, zwrot/zniszczenie danych po zakończeniu umowy.

Kryteria oceny dojrzałości. Większość firm średnich jest na poziomie 1-2: mają jakąś listę dostawców, ale nieformalną klasyfikację, klauzule bezpieczeństwa są w niektórych umowach (zwykle tych nowszych), regularne oceny dostawców nie istnieją.

Pełna metodologia tego obszaru: audyt łańcucha dostaw IT.

Obszar 5: Bezpieczeństwo w pozyskiwaniu, rozwoju i utrzymaniu systemów (art. 21(2)(e))

Co dyrektywa wymaga. SDLC z wbudowanym bezpieczeństwem (secure development lifecycle), zarządzanie podatnościami (vulnerability management), patch management, security testing.

Dokumenty do zebrania. Polityka SDLC (jeśli firma rozwija oprogramowanie wewnętrznie), polityka zarządzania podatnościami, polityka patch managementu, raporty ze skanów podatności z ostatnich 12 miesięcy, raporty z testów penetracyjnych, harmonogram pentestów.

Pytania do wywiadu. Jak często skanujecie infrastrukturę pod kątem podatności? Jaki jest średni czas od opublikowania CVE krytycznego do zapatchowania w produkcji? Kiedy ostatnio robiliście pentest, kto i z jakim zakresem?

Testy do wykonania. Audytor prosi o ostatni raport z vulnerability scan i wybiera trzy podatności krytyczne starsze niż 30 dni. Pyta: czemu nie zapatchowane, jaki jest plan, czy są mitigants kompensujące. To pokazuje, czy firma faktycznie zarządza ryzykiem czy tylko skanuje. Drugi test: czy są SBOM-y (Software Bill of Materials) dla aplikacji krytycznych.

Kryteria oceny dojrzałości. Poziom 3 wymaga: polityka, regularne skany (minimum miesięczne dla infrastruktury, ciągłe dla aplikacji webowych), SLA na patche (typowo 7 dni krytyczne, 30 dni wysokie, 90 dni średnie), roczne pentesty, security awareness w procesach rozwoju.

Obszar 6: Polityki oceny skuteczności środków zarządzania ryzykiem (art. 21(2)(f))

Co dyrektywa wymaga. Sposób mierzenia, czy wdrożone środki bezpieczeństwa faktycznie działają. Metryki, KPI/KRI, regularny przegląd.

Dokumenty do zebrania. Lista metryk bezpieczeństwa (KPI/KRI), dashboards/raporty z metrykami, polityki przeglądów skuteczności, protokoły z przeglądów.

Pytania do wywiadu. Jakie macie top pięć metryk bezpieczeństwa, które monitorujecie regularnie? Pokaż mi dashboard za ostatni miesiąc. Co zrobiliście, gdy metryka odchyliła się od baseline?

Testy do wykonania. Audytor wybiera trzy metryki (np. liczba incydentów high severity, średni MTTR, % stacji z aktualnym patch level) i sprawdza: czy jest baseline, czy są regularne raporty, czy odchylenia powodują action items. Brak action items przy istniejących odchyleniach = poziom 2 niezależnie od jakości dashboardu.

Kryteria oceny dojrzałości. To jest obszar, w którym polskie firmy są zwykle najsłabsze, mają wdrożone kontrole, ale nie mierzą ich skuteczności. Większość jest na poziomie 1.

Obszar 7: Cyberhigiena i szkolenia (art. 21(2)(g))

Co dyrektywa wymaga. Program szkoleń z cyberhigieny dla pracowników, regularnych ćwiczeń phishing, polityki podstawowe (hasła, MFA, urządzenia BYOD, czyste biurko), monitoring postaw.

Dokumenty do zebrania. Program szkoleń (zakres, częstotliwość, formaty), zapisy z ostatnich 24 miesięcy szkoleń (kto, kiedy, czy zaliczył test), raporty z phishing simulations, polityka cyberhigieny.

Pytania do wywiadu. Jaki procent pracowników przeszedł szkolenie w ostatnich 12 miesiącach? Jaki jest click-rate w ostatnich symulacjach phishing i czy spada w czasie? Jakie tematy są w szkoleniach poza phishing?

Testy do wykonania. Audytor przeprowadza krótki wywiad z 5-8 losowymi pracownikami operacyjnymi (nie z IT) z różnych działów. Pyta o trzy rzeczy: czy wiedzą do kogo zgłosić podejrzaną wiadomość, czy potrafią wymienić trzy zasady bezpiecznego hasła, czy wiedzą czym jest MFA. Odpowiedzi pokazują realny stan kultury, nie deklarowany.

Kryteria oceny dojrzałości. Poziom 3 wymaga: roczne szkolenie obowiązkowe dla wszystkich, kwartalne phishing simulations, dedykowane onboarding security training. Poziom 4 i wyżej: ciągły program, gamifikacja, mierzenie efektywności w czasie.

Obszar 8: Polityki kryptografii (art. 21(2)(h))

Co dyrektywa wymaga. Polityka szyfrowania danych w spoczynku i w tranzycie, zarządzanie kluczami, polityka transport layer security, ograniczenia algorytmów słabych.

Pełna metodologia: audyt kryptografii.

Obszar 9: Bezpieczeństwo zasobów ludzkich, kontrola dostępu, zarządzanie aktywami (art. 21(2)(i))

Co dyrektywa wymaga. Procesy on-boardingu i off-boardingu z perspektywy bezpieczeństwa, zarządzanie tożsamością (IAM), kontrola dostępu, klasyfikacja aktywów, inwentarz zasobów (asset inventory).

Dokumenty do zebrania. Polityka IAM, procedura on/off-boardingu, inwentarz aktywów (sprzęt + oprogramowanie + dane), polityka klasyfikacji aktywów, raporty z przeglądów uprawnień (access reviews) z ostatnich 12 miesięcy.

Pytania do wywiadu. Jak długo trwa od momentu wypowiedzenia umowy do zablokowania kont byłego pracownika? Kto przeprowadza access review i jak często? Czy macie kompletny asset inventory, także laptopy domowe pracowników, urządzenia BYOD, instancje cloud?

Testy do wykonania. Audytor prosi o listę pracowników, którzy odeszli w ostatnich 30 dniach. Dla 3 wybranych sprawdza: czy konta zostały zablokowane (data, godzina), czy odebrany sprzęt, czy hasła do współdzielonych systemów zostały zmienione. Drugi test: prośba o listę kont uprzywilejowanych (administratorzy) i sprawdzenie, czy nie ma kont “zombie” (utworzone do projektów dawno zamkniętych).

Obszar 10: Uwierzytelnianie wieloskładnikowe i kanały komunikacji (art. 21(2)(j))

Co dyrektywa wymaga. MFA dla dostępu do systemów krytycznych, bezpieczne kanały komunikacji wewnętrznej (szyfrowana poczta, komunikatory, video), zabezpieczone połączenia zdalne.

Dokumenty do zebrania. Polityka MFA, lista systemów z włączonym MFA, lista wyjątków (kto, dlaczego, do kiedy), polityka pracy zdalnej, polityka komunikatorów wewnętrznych.

Pytania do wywiadu. Jaki procent kont (ogółem i uprzywilejowanych) ma MFA? Jakie wyjątki istnieją i z jakimi uzasadnieniami? Czy MFA chroni także systemy starsze (legacy)?

Testy do wykonania. Audytor prosi o pokazanie konfiguracji MFA w trzech systemach: VPN, system finansowy, panel administracyjny chmury. Sprawdza realny stan: czy faktycznie wymagane, czy jest możliwość pominięcia, jakie metody (push, TOTP, SMS, SMS jest dziś poniżej standardu). Drugi test: czy MFA chroni także RDP/SSH dla administratorów.

Pełna metodologia: audyt MFA i kontroli dostępu.

Składanie wyników, macierz audytu i raport końcowy

Po przejściu wszystkich dziesięciu obszarów audytor składa macierz oceny: każdy obszar otrzymuje punkt 0-5, plus liczba ustaleń per klasyfikacja (krytyczne / wysokie / średnie / niskie). Macierz pokazuje obszar po obszarze, gdzie firma jest, gdzie powinna być (zwykle minimum 3 dla podmiotów kluczowych), jaka jest luka.

Format macierzy w raporcie:

Obszar art. 21	Aktualna dojrzałość	Cel	Luka	Ustalenia krytyczne/wysokie
(a) Polityka ryzyka	2	3	1	0 / 2
(b) Obsługa incydentów	1	3	2	1 / 3
(c) Ciągłość	2	4	2	0 / 4
(d) Łańcuch dostaw	1	3	2	1 / 2
(e) SDLC i podatności	3	3	0	0 / 1
(f) Ocena skuteczności	1	3	2	0 / 2
(g) Cyberhigiena	2	3	1	0 / 1
(h) Kryptografia	3	4	1	0 / 1
(i) IAM i aktywa	2	3	1	1 / 2
(j) MFA	2	4	2	1 / 2

Macierz jest wizualizowana w raporcie jako heatmapa (czerwony / żółty / zielony) i prezentowana zarządowi. Każde ustalenie krytyczne i wysokie powinno mieć w raporcie: opis, dowody, ryzyko biznesowe, rekomendację korygującą, szacunkowy koszt i czas wdrożenia, odpowiedzialnego.

Jeśli przygotowujesz lub odbierasz pierwszy taki audyt i potrzebujesz template’u macierzy oraz formatu ustaleń, możesz dołączyć do newslettera skanujfirme.pl, w którym przesyłamy szablon raportu w XLSX/DOCX wraz z listą 30+ pytań kontrolnych do każdego obszaru. To nie jest substytut audytu, ale punkt startowy, który skraca pierwszą iterację o tygodnie.

Trzy pytania kontrolne do zarządu przed zleceniem audytu

Pierwsze. Czy znamy obecną dojrzałość firmy w dziesięciu obszarach art. 21, choćby z grubsza? Jeśli nie, pierwszym krokiem powinien być self-audit (krótki, oparty na checkliście 50 pytań), nie zewnętrzny audyt za 150 000 zł.

Drugie. Jaki jest nasz cel docelowy? Dla podmiotu kluczowego minimum to poziom 3 w każdym obszarze. Dla istotnego, poziom 2. Bez celu nie da się ocenić sukcesu audytu.

Trzecie. Kto jest beneficjentem raportu? Zarząd? Zarząd plus ubezpieczyciel cyber? Zarząd plus regulator (jeśli już są pytania z UODO lub CSIRT)? Cel adresata wpływa na format raportu, zakres dowodów, język.

Esencja

Audyt NIS2 art. 21 nie jest checklistą. Jest procesem oceny dojrzałości w dziesięciu wymiarach, w którym audytor zbiera dowody (dokumenty, wywiady, testy techniczne), ocenia poziom dojrzałości w skali 0-5, identyfikuje luki względem stanu pożądanego i formułuje plan działań korygujących.

Pięć faz przekrojowych, planowanie, zebranie dowodów, ocena dojrzałości, analiza luki, raport, powtarza się dla każdego z dziesięciu obszarów. Czas pełnego audytu dla średniej firmy: 6-10 tygodni. Koszt: zwykle 80 000-250 000 zł zależnie od skali i zakresu.

Dziesięć obszarów art. 21, od polityki zarządzania ryzykiem przez obsługę incydentów, ciągłość działania, łańcuch dostaw, SDLC, ocenę skuteczności, cyberhigienę, kryptografię, IAM, po MFA, wymaga różnych metod audytowych, różnych dowodów, różnej głębokości testów technicznych. Audytor nie patrzy tylko na dokumenty. Pyta operacyjnych pracowników. Robi tabletop exercises. Sprawdza realny patch level. Weryfikuje, czy backup faktycznie się przywraca. Bez tej warstwy testów technicznych audyt jest tylko teatrem zgodności.

Macierz dojrzałości jest narzędziem komunikacji z zarządem. Pokazuje aktualny stan, cel, lukę. Zarząd nie potrzebuje wszystkich detali, potrzebuje wiedzieć, gdzie firma jest najbardziej narażona i jakie są priorytety wydatków na bezpieczeństwo w nadchodzących 12-24 miesiącach.

NIS2 w 2026 roku nie jest już regulacją odległą. Polska transponowała dyrektywę z opóźnieniem, ale obowiązki są wiążące. Audyt jest dziś nie tylko narzędziem zgodności, jest narzędziem zarządzania ryzykiem, którego zarządy używają, aby świadomie decydować, gdzie inwestować w bezpieczeństwo, a gdzie tolerować ryzyko rezydualne. To różnica między firmą reaktywną a firmą zarządzaną dorosłej.

Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 z dnia 14 grudnia 2022 r. w sprawie środków na rzecz wysokiego wspólnego poziomu cyberbezpieczeństwa na terytorium Unii (NIS2). https://eur-lex.europa.eu/eli/dir/2022/2555/oj
ENISA (2024). NIS2 Technical Implementation Guidance for Cybersecurity Risk Management Measures. European Union Agency for Cybersecurity. https://www.enisa.europa.eu/publications
ISO/IEC 27001:2022. Information security, cybersecurity and privacy protection, Information security management systems, Requirements. International Organization for Standardization.
ISO/IEC 27005:2022. Information security, cybersecurity and privacy protection, Guidance on managing information security risks. International Organization for Standardization.
NIST (2018). Framework for Improving Critical Infrastructure Cybersecurity, Version 1.1. National Institute of Standards and Technology. https://doi.org/10.6028/NIST.CSWP.04162018
NIST SP 800-53 Rev. 5 (2020). Security and Privacy Controls for Information Systems and Organizations. National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-53r5
NIST SP 800-30 Rev. 1 (2012). Guide for Conducting Risk Assessments. National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-30r1
NIST SP 800-61 Rev. 2 (2012). Computer Security Incident Handling Guide. National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-61r2
Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (Dz.U. 2018 poz. 1560 ze zm.), wraz z projektem nowelizacji transponującej NIS2 (status: maj 2026).
CSIRT NASK / CERT Polska. Krajobraz bezpieczeństwa polskiego internetu, raporty roczne 2022-2024. https://www.cert.pl/publikacje/
Verizon (2024). Data Breach Investigations Report (DBIR) 2024. https://www.verizon.com/business/resources/reports/dbir/

Self-audit firmy, checklist 50 pytań do wykonania w 60 minut

Marek Porycki — Sat, 18 Jul 2026 09:26:00 +0000

Pełen audyt firmy kosztuje 200 000-600 000 zł i trwa 3-6 miesięcy. Self-audit kosztuje godzinę Twojego czasu i daje obraz, na podstawie którego możesz podjąć decyzje strategiczne, czy zlecać pełen audyt, na które obszary skoncentrować zasoby, jak duże luki masz vs benchmark branżowy.

Ten tekst zawiera checklist 50 pytań w pięciu wymiarach (zgodność, procesy IT, łańcuch dostaw, kultura, gotowość obronna). Każde pytanie jest binarne (TAK/NIE) lub trójstopniowe (TAK/CZĘŚCIOWO/NIE), żeby uniknąć “udawania”, które jest powszechne w samoocenie. Wszystkie pytania są skonstruowane tak, by wymagać konkretnych dowodów (dokumentów, dat, osób), odpowiedź “TAK” bez dowodu = “CZĘŚCIOWO” w realnej ocenie.

Wymagany czas: 45-75 minut, zależnie od stopnia znajomości firmy. Wymagana wiedza: średnia (członek zarządu lub dyrektor compliance powinien móc wykonać sam, dyrektor IT może potrzebować wsparcia w kilku pytaniach RODO).

Sekcja 1: Zgodność regulacyjna (15 pytań, 30 punktów)

Pytanie 1. Czy mamy aktualny rejestr czynności przetwarzania (RCP) zgodnie z artykułem 30 RODO, aktualizowany w ostatnich 12 miesiącach?

TAK, kompletny i aktualny: 2 pkt
CZĘŚCIOWO (istnieje, ale nieaktualny lub niepełny): 1 pkt
NIE: 0 pkt

Pytanie 2. Czy każdy z naszych dostawców-procesorów danych osobowych ma podpisaną aktualną umowę powierzenia (artykuł 28 RODO)?

TAK, wszyscy: 2 pkt
CZĘŚCIOWO, większość: 1 pkt
NIE, większość brakuje lub nieaktualna: 0 pkt

Pytanie 3. Czy mamy procedurę obsługi praw podmiotów danych (dostęp, sprostowanie, usunięcie, ograniczenie, przenoszenie, sprzeciw) z konkretnymi terminami?

TAK, udokumentowana i przetestowana: 2 pkt
CZĘŚCIOWO, istnieje, nieprzetestowana: 1 pkt
NIE: 0 pkt

Pytanie 4. Czy wykonaliśmy DPIA (Data Protection Impact Assessment) dla wszystkich procesów wymagających zgodnie z artykułem 35 RODO?

TAK, wszystkie wymagane: 2 pkt
CZĘŚCIOWO: 1 pkt
NIE / nie zidentyfikowaliśmy: 0 pkt

Pytanie 5. Czy mamy procedurę zgłaszania naruszeń ochrony danych do PUODO w 72 godzinach, z odpowiedzialnymi osobami?

TAK, udokumentowana, przetestowana: 2 pkt
CZĘŚCIOWO: 1 pkt
NIE: 0 pkt

Pytanie 6. Jeśli podlegamy NIS2, czy zarejestrowaliśmy się w systemie CSIRT NASK?

TAK / nie podlegamy NIS2 (zweryfikowane): 2 pkt
TAK ale w opóźnieniu / nie wiemy czy podlegamy: 1 pkt
NIE: 0 pkt

Pytanie 7. Czy zarząd przyjął formalną uchwałę zatwierdzającą system zarządzania ryzykiem cyberbezpieczeństwa (NIS2 art. 20) w ostatnich 12 miesiącach?

TAK: 2 pkt
CZĘŚCIOWO (starsza niż 12 m-cy lub niepełna): 1 pkt
NIE: 0 pkt

Pytanie 8. Czy każdy członek zarządu odbył w ostatnich 12 miesiącach formalne szkolenie z cyberbezpieczeństwa (minimum 4 godziny, z dokumentacją)?

TAK, wszyscy: 2 pkt
CZĘŚCIOWO: 1 pkt
NIE: 0 pkt

Pytanie 9. Czy posiadamy formalną procedurę obsługi incydentu cyberbezpieczeństwa z trójstopniowym protokołem 24h/72h/30 dni (NIS2 art. 23)?

TAK: 2 pkt
CZĘŚCIOWO: 1 pkt
NIE: 0 pkt

Pytanie 10. Czy mamy IOD/DPO (Inspektora Ochrony Danych) wyznaczonego formalnie z odpowiednim umocowaniem?

TAK / nie jesteśmy zobowiązani do wyznaczenia (zweryfikowane): 2 pkt
TAK ale z niejasnym umocowaniem: 1 pkt
NIE: 0 pkt

Pytanie 11. Czy mamy Cybersecurity Officera lub równoważną rolę z udokumentowanym zakresem obowiązków?

TAK, pełny etat lub minimum 50%: 2 pkt
CZĘŚCIOWO, rola łączona, niejasny zakres: 1 pkt
NIE: 0 pkt

Pytanie 12. Czy wszyscy pracownicy ze stałym dostępem do systemów IT przeszli w ostatnich 12 miesiącach szkolenie cyberhigieny z dokumentacją uczestnictwa?

TAK: 2 pkt
CZĘŚCIOWO: 1 pkt
NIE: 0 pkt

Pytanie 13. Czy podlegamy regulacjom sektorowym (KNF, URE, UKE, sektorowe ochrony zdrowia, DORA, AI Act) i mamy aktualny status zgodności?

TAK / nie podlegamy specjalnym regulacjom: 2 pkt
CZĘŚCIOWO, częściowa zgodność: 1 pkt
NIE: 0 pkt

Pytanie 14. Czy nasze klauzule informacyjne dla osób, których dane przetwarzamy (klienci, pracownicy, kandydaci), są zgodne z artykułami 13-14 RODO i aktualne?

TAK: 2 pkt
CZĘŚCIOWO: 1 pkt
NIE: 0 pkt

Pytanie 15. Czy w ostatnich 24 miesiącach mieliśmy audyt zgodności (RODO i/lub NIS2) zewnętrzny lub wewnętrzny z udokumentowanym raportem?

TAK: 2 pkt
CZĘŚCIOWO, fragmentaryczny: 1 pkt
NIE: 0 pkt

Sekcja 2: Procesy IT i kontrole techniczne (12 pytań, 24 punkty)

Pytanie 16. Czy uwierzytelnianie wieloskładnikowe (MFA) jest wdrożone dla wszystkich kont administracyjnych, dostępu do systemów krytycznych i dostępu zdalnego?

TAK, wszystkie kategorie: 2 pkt
CZĘŚCIOWO: 1 pkt
NIE: 0 pkt

Pytanie 17. Czy mamy formalną procedurę zarządzania patchami z określonymi terminami reakcji na podatności (krytyczne ≤14 dni, wysokie ≤30 dni)?

TAK, z dokumentacją realnych terminów: 2 pkt
CZĘŚCIOWO: 1 pkt
NIE: 0 pkt

Pytanie 18. Czy w ostatnich 12 miesiącach przeprowadziliśmy zewnętrzny test penetracyjny lub równoważny audyt techniczny?

TAK, z udokumentowanym raportem: 2 pkt
CZĘŚCIOWO, skanowanie automatyczne: 1 pkt
NIE: 0 pkt

Pytanie 19. Czy nasze kopie zapasowe krytycznych systemów są wykonywane regularnie, przechowywane offline/immutable, z testem odtworzenia w ostatnich 12 miesiącach?

TAK, wszystkie trzy warunki: 2 pkt
CZĘŚCIOWO: 1 pkt
NIE: 0 pkt

Pytanie 20. Czy mamy aktualny plan ciągłości działania (BCP) i plan odzyskiwania po awarii (DRP) z testem w ostatnich 12 miesiącach?

TAK: 2 pkt
CZĘŚCIOWO, istnieje, nietestowany: 1 pkt
NIE: 0 pkt

Pytanie 21. Czy posiadamy politykę kryptografii określającą wymagane standardy szyfrowania w tranzycie i w spoczynku, faktycznie wdrożoną dla danych krytycznych?

TAK: 2 pkt
CZĘŚCIOWO: 1 pkt
NIE: 0 pkt

Pytanie 22. Czy mamy formalną procedurę nadawania i odbierania dostępów (onboarding/offboarding) z kwartalnymi przeglądami uprawnień?

TAK: 2 pkt
CZĘŚCIOWO: 1 pkt
NIE: 0 pkt

Pytanie 23. Czy w ostatnim audycie kont aktywnych w głównych systemach udział kont nieaktywnych był poniżej 5%?

TAK, sprawdzone w 6 m-cach: 2 pkt
NIE WIADOMO / nie sprawdzone: 0 pkt
NIE, sprawdzone, powyżej 5%: 0 pkt

Pytanie 24. Czy mamy monitoring bezpieczeństwa (SIEM lub równoważny) z analizą logów krytycznych systemów?

TAK, aktywny: 2 pkt
CZĘŚCIOWO, częściowy: 1 pkt
NIE: 0 pkt

Pytanie 25. Czy mamy segmentację sieci oddzielającą krytyczne systemy od pozostałej infrastruktury?

TAK: 2 pkt
CZĘŚCIOWO: 1 pkt
NIE: 0 pkt

Pytanie 26. Czy oceniamy poziom dojrzałości procesów IT (np. CMMI) i mamy plan rozwoju do wyższego poziomu?

TAK, minimum poziom 3 z planem dalszym: 2 pkt
CZĘŚCIOWO, poziom 2: 1 pkt
NIE, poziom 1 lub nieoceniany: 0 pkt

Pytanie 27. Czy mamy zarządzanie zmianami w infrastrukturze IT z formalnym procesem zatwierdzania?

TAK: 2 pkt
CZĘŚCIOWO: 1 pkt
NIE: 0 pkt

Sekcja 3: Łańcuch dostaw (8 pytań, 16 punktów)

Pytanie 28. Czy mamy aktualną mapę wszystkich dostawców IT i usług dotykających systemów krytycznych?

TAK, z aktualizacją w 12 m-cach: 2 pkt
CZĘŚCIOWO: 1 pkt
NIE: 0 pkt

Pytanie 29. Czy każdy dostawca jest sklasyfikowany pod względem ryzyka (krytyczny / istotny / pozostały)?

TAK: 2 pkt
CZĘŚCIOWO: 1 pkt
NIE: 0 pkt

Pytanie 30. Czy wszystkie umowy z dostawcami krytycznymi zawierają klauzule cyberbezpieczeństwa (powiadomienie o incydencie, prawo do audytu, standardy)?

TAK, wszystkie: 2 pkt
CZĘŚCIOWO: 1 pkt
NIE: 0 pkt

Pytanie 31. Czy każdy dostawca krytyczny ma aktualny raport audytu (SOC 2, ISO 27001) lub wypełnił kwestionariusz cyberbezpieczeństwa w ostatnich 18 m-cach?

TAK, wszyscy: 2 pkt
CZĘŚCIOWO: 1 pkt
NIE: 0 pkt

Pytanie 32. Czy znamy subdostawców kluczowych dostawców z dostępem do naszych systemów lub danych?

TAK, kompletna mapa: 2 pkt
CZĘŚCIOWO: 1 pkt
NIE: 0 pkt

Pytanie 33. Czy mamy plan exit (alternatywni dostawcy, procedura migracji) dla kluczowych zależności?

TAK, udokumentowany dla wszystkich krytycznych: 2 pkt
CZĘŚCIOWO: 1 pkt
NIE: 0 pkt

Pytanie 34. Czy testowaliśmy w ostatnich 12 miesiącach procedurę reakcji na incydent po stronie dostawcy?

TAK: 2 pkt
NIE: 0 pkt

Pytanie 35. Czy łańcuch dostaw jest stałym punktem agendy zarządu raz w roku?

TAK: 2 pkt
CZĘŚCIOWO, okazjonalnie: 1 pkt
NIE: 0 pkt

Sekcja 4: Kultura bezpieczeństwa (8 pytań, 16 punktów)

Pytanie 36. Czy w ostatnich 12 miesiącach przeprowadziliśmy ankietę kulturową dotyczącą cyberbezpieczeństwa wśród personelu?

TAK, z udziałem >50%: 2 pkt
CZĘŚCIOWO: 1 pkt
NIE: 0 pkt

Pytanie 37. Czy w ostatnich 12 miesiącach przeprowadziliśmy kontrolowany test phishingowy z analizą wyników?

TAK: 2 pkt
NIE: 0 pkt

Pytanie 38. Czy odsetek pracowników klikających na phishing jest poniżej 15% (benchmark branżowy)?

TAK, sprawdzone testem: 2 pkt
NIE / nie wiadomo: 0 pkt

Pytanie 39. Czy odsetek pracowników zgłaszających podejrzane wiadomości jest powyżej 30%?

TAK: 2 pkt
NIE / nie wiadomo: 0 pkt

Pytanie 40. Czy zarząd modeluje pożądane zachowania cyberbezpieczeństwa (używa MFA, managera haseł, nie obchodzi procedur)?

TAK: 2 pkt
CZĘŚCIOWO: 1 pkt
NIE: 0 pkt

Pytanie 41. Czy mamy program “champions cyber”, wyznaczone osoby w działach popularyzujące dobre praktyki?

TAK: 2 pkt
NIE: 0 pkt

Pytanie 42. Czy zgłaszanie incydentów (nawet własnych błędów) jest pozytywnie odbierane w organizacji (nie penalizowane)?

TAK, udokumentowana polityka: 2 pkt
CZĘŚCIOWO, niejasne: 1 pkt
NIE, penalizujące: 0 pkt

Pytanie 43. Czy cyberbezpieczeństwo jest stałym elementem komunikacji wewnętrznej (newslettery, briefy)?

TAK, regularnie: 2 pkt
CZĘŚCIOWO, sporadycznie: 1 pkt
NIE: 0 pkt

Sekcja 5: Gotowość obronna (7 pytań, 14 punktów)

Pytanie 44. Czy mamy aktualną listę kontaktów awaryjnych (CSIRT NASK, kancelaria prawna, firma incident response, ubezpieczyciel)?

TAK, przetestowana: 2 pkt
CZĘŚCIOWO, istnieje, nieprzetestowana: 1 pkt
NIE: 0 pkt

Pytanie 45. Czy mamy retainer/umowę o gotowości z kancelarią prawną mającą doświadczenie w postępowaniach cyber?

TAK: 2 pkt
NIE: 0 pkt

Pytanie 46. Czy nasza polisa cyber/D&O pokrywa koszty obrony w postępowaniach administracyjnych?

TAK, zweryfikowana: 2 pkt
NIE WIEMY: 0 pkt
NIE: 0 pkt

Pytanie 47. Czy mamy procedurę komunikacji kryzysowej (klienci, partnerzy, media) na różne scenariusze incydentów?

TAK: 2 pkt
CZĘŚCIOWO: 1 pkt
NIE: 0 pkt

Pytanie 48. Czy posiadamy ubezpieczenie cyber liability z odpowiednim limitem (minimum 1% rocznego obrotu)?

TAK: 2 pkt
CZĘŚCIOWO, niższy limit: 1 pkt
NIE: 0 pkt

Pytanie 49. Czy w ostatnich 12 miesiącach przeprowadziliśmy ćwiczenie tabletop (symulacja incydentu) dla zespołu kryzysowego?

TAK: 2 pkt
NIE: 0 pkt

Pytanie 50. Czy mamy wspólny rejestr incydentów obsługujący wymogi NIS2 i RODO?

TAK: 2 pkt
CZĘŚCIOWO, oddzielne: 1 pkt
NIE: 0 pkt

Punktacja i interpretacja

Maksimum: 100 punktów. Sekcje: zgodność (30), procesy IT (24), łańcuch dostaw (16), kultura (16), gotowość obronna (14).

90-100 punktów: gotowość znakomita. Twoja firma jest w czołówce branży. Pełen audyt zewnętrzny rekomendowany dla potwierdzenia stanu i benchmarku. Inwestycje w certyfikację i rozwój zaawansowanych obszarów.

75-89 punktów: gotowość wysoka. Solidne fundamenty. Drobne luki do uzupełnienia. Pełen audyt zewnętrzny co 24-36 miesięcy. Plan działań na 6 miesięcy.

60-74 punkty: gotowość umiarkowana. Działający system z istotnymi lukami. Pełen audyt zewnętrzny w ciągu 12 miesięcy. Konkretny plan inwestycji 200 000-600 000 zł na 12-18 miesięcy.

45-59 punktów: gotowość niska. Istotne luki w wielu obszarach. Pilna decyzja zarządu o priorytetowym programie. Pełen audyt zewnętrzny w ciągu 6 miesięcy z planem naprawczym 12-24 miesięcy.

Poniżej 45 punktów: gotowość minimalna lub krytyczna. Systemowe braki. Realne ryzyko maksymalnych sankcji w razie kontroli lub incydentu. Pełen audyt zewnętrzny pilnie. Plan transformacyjny 18-24 miesięcy z budżetem 500 000 zł i więcej.

Mapowanie wyników na priorytety

Sprawdź sekcje z najniższą punktacją (procentowo). To obszary priorytetowe.

Niski wynik w sekcji 1 (zgodność): problem regulacyjny. Pierwsze działania: rejestracja CSIRT NASK, formalizacja zarządcza, plan zgodności RODO+NIS2.

Niski wynik w sekcji 2 (procesy IT): problem operacyjny. Inwestycja w narzędzia (MFA, monitoring, backup), formalizacja procedur, procedura patch management.

Niski wynik w sekcji 3 (łańcuch dostaw): najczęściej zaniedbany obszar. Mapa dostawców, klasyfikacja, renegocjacje umów, plan exit.

Niski wynik w sekcji 4 (kultura): problem długoterminowy. Programy szkoleniowe, transformacja komunikacji, leadership behaviors zarządu.

Niski wynik w sekcji 5 (gotowość obronna): problem strategiczny. Kontraktowanie kancelarii, polisy cyber, ćwiczenia tabletop, plan komunikacji kryzysowej.

Co dalej po self-audit

Krok 1: walidacja wyniku. Test wykonany solo to test marketingowy. Walidacja przez drugą osobę (najlepiej z innej perspektywy) podnosi wiarygodność.

Krok 2: dyskusja w zarządzie. Wynik samoaudytu jako punkt agendy. Decyzje strategiczne na jego podstawie.

Krok 3: decyzja o pełnym audycie zewnętrznym. Jeśli wynik poniżej 75, pełen audyt zewnętrzny w ciągu 6 miesięcy. Powyżej 75, co 24-36 miesięcy.

Krok 4: plan działań na 90 dni. Konkretne kroki w obszarach najsłabszych z budżetem i odpowiedzialnymi.

Krok 5: powtórzenie self-audit za 6 miesięcy. Mierzenie postępu.

Bibliografia

Komisja Europejska. (2022). Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (NIS2). https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32022L2555
Parlament Europejski i Rada UE. (2016). Rozporządzenie (UE) 2016/679 (RODO). https://eur-lex.europa.eu/eli/reg/2016/679/oj
NIST. (2024). Cybersecurity Framework 2.0. National Institute of Standards and Technology. https://doi.org/10.6028/NIST.CSWP.29
ISO. (2022). ISO/IEC 27001:2022, Załącznik A. https://www.iso.org/standard/27001
ENISA. (2025). NIS2 technical implementation guidance. European Union Agency for Cybersecurity. https://www.enisa.europa.eu/publications/nis2-technical-implementation-guidance
Verizon. (2024). 2024 Data Breach Investigations Report. Verizon Business. https://www.verizon.com/business/resources/reports/dbir/

Self-audit to początek strategii, nie koniec. W cotygodniowym newsletterze SkanujFirme.pl publikujemy interpretacje wyników podobnych testów dla różnych typów firm, plus konkretne plany 90-dniowe i 12-miesięczne. Zapisz się, bezpłatnie i wykorzystaj ten test jako punkt wyjścia.

Raport audytowy dla zarządu, jak go napisać, by miał wpływ

Marek Porycki — Mon, 13 Jul 2026 16:03:00 +0000

W większości firm raporty audytowe spotyka ten sam los. Audytor wręcza dokument 80-150 stron, zarząd przegląda streszczenie wykonawcze, kiwa głową, zatwierdza ogólne wnioski. Raport trafia do segregatora. Po roku audytor wraca z kolejnym audytem, większość rekomendacji z poprzedniego roku jest niewdrożonych. Cykl się powtarza.

Problem nie leży w jakości audytu. Problem leży w jakości raportu jako narzędzia komunikacji. Raport, który nie prowadzi do decyzji, jest stratą. Ten tekst opisuje, jak pisać raporty audytowe, które realnie wpływają na decyzje zarządu, w strukturze, języku, priorytetyzacji, wizualizacji.

Plus zarządy, którzy chcą wiedzieć, czego oczekiwać od dobrego raportu.

Struktura raportu, siedem części

Część 1: streszczenie wykonawcze (executive summary, 2-3 strony).

Najważniejsza część raportu. 80% zarządu czyta tylko ją. Pozostałe 20% czyta dalej tylko, jeśli streszczenie ich zaintrygowało.

Treść streszczenia:

jednozdaniowa diagnoza ogólna (“Firma X znajduje się na poziomie umiarkowanej dojrzałości w obszarze RODO/NIS2, z 5 krytycznymi lukami wymagającymi działania w 30 dni”);
3-5 najważniejszych ustaleń z konkretnymi liczbami;
3-5 najważniejszych rekomendacji z priorytetami;
ramowy budżet i timeline wdrożenia;
jednozdaniowa konkluzja.

Streszczenie powinno być samowystarczalne, czytelnik nie czytający dalej wciąż ma kompletny obraz.

Część 2: metodologia.

Zakres audytu, frameworki, narzędzia, źródła danych, ograniczenia. Krótka, 1-2 strony. Cel: wiarygodność (jakimi środkami doszliśmy do wniosków).

Część 3: kontekst firmy.

Wielkość, sektor, kluczowe procesy, wcześniejsze audyty, regulacje obowiązujące. Pomaga czytelnikowi (zwłaszcza nowemu w organizacji) zrozumieć tło ustaleń.

Część 4: ustalenia per obszar.

Główne danie raportu. Każdy obszar (np. RODO, NIS2 obszar 1, NIS2 obszar 2, kultura, łańcuch dostaw) z:

statusem (dobry / średni / słaby / krytyczny);
konkretne ustalenia z dowodami;
ocena ryzyka;
benchmark branżowy (jeśli dostępny);
wstępne rekomendacje obszaru.

Ta część jest długa (30-80 stron), ale używa konsekwentnej struktury, więc czytelnik może łatwo skakać.

Część 5: mapa ryzyka.

Macierz ryzyka prawdopodobieństwo × wpływ z kluczowymi ryzykami zidentyfikowanymi. Wizualizacja graficzna jest kluczowa, zarząd lepiej rozumie macierz niż listę 50 ryzyk.

Część 6: rekomendacje priorytetyzowane.

Konsolidacja wszystkich rekomendacji z części 4 w jedną listę z priorytetami. Każda rekomendacja:

numer i tytuł;
kontekst i uzasadnienie (1-2 zdania);
konkretne działanie do podjęcia;
priorytet (krytyczny / wysoki / średni / niski);
termin realizacji;
proponowany odpowiedzialny (rola, nie nazwisko);
szacunkowy koszt (zakres);
oczekiwany efekt;
powiązanie z ustaleniami w części 4.

Liczba rekomendacji: optymalnie 15-30 w pełnym audycie. Powyżej 50, przeładowanie. Poniżej 10, prawdopodobnie zbyt powierzchowne.

Część 7: plan działań i appendices.

Plan wdrożenia rekomendacji w czasie (Gantt-like). Załączniki: szczegółowa dokumentacja, ankiety, transkrypcje, listy zauważonych dokumentów.

Język, co działa, co nie

Raport audytowy to specyficzny gatunek dokumentu. Pisany dla wymagających odbiorców (zarządy, regulatory). Konkretne zasady językowe:

Działa: konkretność liczbowa. “23 z 45 dostawców nie ma aktualnych klauzul cyber w umowach” zamiast “wiele dostawców ma luki w umowach”.

Działa: bezpośredni język decyzyjny. “Rekomendujemy” zamiast “warto rozważyć”. “Należy” zamiast “być może”.

Działa: kontekst biznesowy. “Brak MFA dla kont administracyjnych zwiększa ryzyko incydentu o ~80% (Microsoft Security Report 2024). W razie kompromitacji potencjalna kara NIS2 dla firmy Twojej skali: 2,5-5 mln zł” zamiast samego “Brak MFA dla kont administracyjnych”.

Nie działa: nadużywanie żargonu. “Brak trójstopniowej autentykacji opartej na bridach FIDO2 z hardware tokenami”, większość zarządu nie zrozumie. Lepiej: “Brak silnego uwierzytelniania (typu hasło + kod z aplikacji)”.

Nie działa: ostrożny język akademicki. “Można by argumentować, że wdrożenie pewnych dodatkowych środków mogłoby przyczynić się do…”, sygnalizuje brak pewności audytora.

Nie działa: ukrywanie złych wiadomości. Eufemizmy (“obszar wymagający uwagi” zamiast “krytyczna luka”) mylą zarząd co do priorytetów.

Wizualizacja, kiedy i jak

Dobry raport audytowy ma 15-25 wizualizacji. Złe wizualizacje są gorsze niż żadne.

Działają:

Mapa ryzyka. Macierz 5×5 z punktami reprezentującymi konkretne ryzyka. Czerwone w prawym górnym rogu, zielone w lewym dolnym. Intuicyjna. Zarząd “widzi” priorytety w 5 sekund.

Heatmap dojrzałości. Wiersze: obszary (RODO, NIS2, łańcuch dostaw, kultura). Kolumny: poziomy dojrzałości (1-5). Komórki kolorowe pokazują, gdzie firma jest w każdym obszarze.

Wykres słupkowy benchmarków. Twoja firma vs średnia branżowa w kilku kluczowych metrykach. Jeśli jesteś poniżej średniej, widać natychmiast.

Timeline rekomendacji. Plan działań w czasie z priorytetami i odpowiedzialnymi.

Diagram przepływu. Dla skomplikowanych procesów (np. obsługa incydentu), diagram pokazuje, gdzie są luki.

Nie działają:

Tabele z 30 wierszami i 8 kolumnami. Trudne do parsowania. Lepiej rozbić na mniejsze tabele.

Wykresy kołowe (pie charts) z 8+ kategoriami. Trudne do porównywania. Lepiej słupki.

Word clouds. Wyglądają nowocześnie, ale dają mało informacji.

Diagramy SSWAT z 50+ pozycjami. Przeładowanie.

Priorytetyzacja rekomendacji, system 4-poziomowy

Rekomendacje bez priorytetów są bezużyteczne. Standard 4-poziomowy:

Krytyczne (do 30 dni). Naruszenia regulacyjne, krytyczne luki techniczne, ryzyko bezpośrednie. “Niewdrożenie spowoduje wysokie ryzyko sankcji lub incydentu w najbliższych miesiącach.”

Przykłady: brak procedury obsługi naruszeń RODO, brak rejestracji w CSIRT NASK, brak MFA dla kont administracyjnych systemów krytycznych, brak udokumentowanej decyzji zarządu zatwierdzającej system NIS2.

Wysokie (do 90 dni). Istotne luki w systemie zarządzania, podstawowe wymogi regulacyjne. “Niewdrożenie spowoduje istotne ryzyko regulacyjne lub operacyjne.”

Przykłady: niekompletny rejestr czynności przetwarzania, niepełne klauzule cyber w umowach z kluczowymi dostawcami, brak rocznych szkoleń dla całego personelu.

Średnie (do 180 dni). Optymalizacje systemu, drobne luki proceduralne. “Wdrożenie poprawi system, ale nie jest pilne.”

Przykłady: aktualizacja wszystkich klauzul informacyjnych, formalizacja niektórych procedur ad hoc, optymalizacja procesu zarządzania zmianami.

Niskie (do 365 dni). Drobne ulepszenia. “Wdrożenie zalecane długoterminowo.”

Przykłady: drobne aktualizacje dokumentacji, dodatkowe metryki monitoringu, optymalizacja narzędzi.

W typowym pełnym audycie: 3-8 krytycznych, 8-15 wysokich, 8-20 średnich, 5-15 niskich. Dystrybucja powinna być zbalansowana, wszystkie krytyczne i żadne niskie wskazuje albo na firmę w katastroficznym stanie, albo na audytora dramatyzującego.

Communication strategy, jak zaprezentować zarządowi

Raport pisany to jedno. Prezentacja zarządowi to drugie.

Format prezentacji: 60-90 minut spotkania. Nie pełne czytanie raportu (zarząd przeczyta sam). Skoncentrowanie na:

5 najważniejszych ustaleniach (10 minut);
mapie ryzyka (10 minut, dyskusja);
5 priorytetowych rekomendacjach (15 minut);
planie działań (15 minut);
pytania i decyzje zarządu (15-30 minut).

Slajdy: maksymalnie 20 slajdów. Każdy z jednym kluczowym przekazem. Wizualizacje z raportu, nie tekst.

Język: bardziej rozmówny niż raport. Pierwsze osoby (“My, audytorzy, znaleźliśmy…”). Pytania do zarządu (“Jak Państwo postrzegają to ryzyko?”).

Cel spotkania: nie tylko przedstawienie wyników. Wyjście z konkretnymi decyzjami zarządu, kto bierze odpowiedzialność, jaki budżet, jaki termin.

Notatka po spotkaniu: 1-2 strony streszczające decyzje zarządu z odpowiedzialnościami i terminami. Wysłana w 48 godzin po spotkaniu. Stanowi dokumentację udokumentowanego nadzoru zarządu (artykuł 20 NIS2).

Najczęstsze błędy w raportach

Błąd 1: zbyt długi raport. 200+ stron raportu jest często sygnałem, że audytor chce pokazać, ile pracy włożył. Dla zarządu, bariera czytania. Lepiej: 80-120 stron + załączniki.

Błąd 2: brak konkluzji. Każda część kończy się bez jasnego wniosku. Zarząd zostaje z 30 stronami obserwacji bez rozumienia, co z tym zrobić.

Błąd 3: zbyt techniczny język. Raport czytelny dla CISO, niezrozumiały dla CEO/CFO. Zarząd nie podejmie decyzji o czymś, czego nie rozumie.

Błąd 4: brak benchmarku. “Wynik 73 punkty”, zarząd nie wie, czy to dużo, mało, średnio. Z benchmarkiem branżowym (“średnia firmy 100-osobowej w sektorze: 65 punktów”) nabiera znaczenia.

Błąd 5: brak konkretnego planu działań. Lista 30 rekomendacji bez timeline’u i odpowiedzialnych. Zarząd zatwierdza ogólnie, ale nikt nic nie robi konkretnie.

Błąd 6: brak follow-upu w kolejnym audycie. Następny audyt zaczyna od zera, nie sprawdza, ile poprzednich rekomendacji wdrożono. Marnotrawstwo wiedzy.

Wzór sekcji “ustalenia obszaru”

Konkretny przykład formatu dla jednego ustalenia (ze sztuczki, ale realistyczny):

Ustalenie 4.7: Brak udokumentowanego programu szkoleniowego dla zarządu (NIS2 art. 20 ust. 2)

Status: krytyczne.

Opis ustalenia: Audyt nie zidentyfikował udokumentowanych szkoleń cyberbezpieczeństwa członków zarządu w ostatnich 24 miesiącach. Wywiady z trzema członkami zarządu potwierdziły, że formalne szkolenia nie odbywały się; wiedza pochodziła z lektur indywidualnych i punktowych konsultacji z CISO.

Dowody: Protokoły posiedzeń zarządu za 2024-2025: brak punktu szkolenia. Dokumentacja HR: brak ewidencji szkoleń członków zarządu w obszarze cyber. Wywiady: 3/3 członków zarządu potwierdziło brak formalnych szkoleń.

Implikacje regulacyjne: Artykuł 20 ust. 2 dyrektywy NIS2 wymaga regularnych szkoleń członków zarządu z cyberbezpieczeństwa. Brak udokumentowanego programu jest naruszeniem obowiązku, niezależnie od tego, czy doszło do incydentu.

Implikacje finansowe: W razie kontroli i potwierdzenia naruszenia, sankcja personalna członka zarządu może wynieść do 200 000 zł oraz czasowy zakaz pełnienia funkcji (precedensy: Niemcy 2024, Holandia 2025). Sankcja dla firmy: dodatkowy czynnik obciążający przy wyliczeniu kary.

Rekomendacja R-7: wdrożyć program szkoleniowy dla zarządu, minimum 4 godziny rocznie, z formalną ewidencją uczestnictwa. Pierwsze szkolenie do 60 dni od daty raportu.

Priorytet: krytyczny (do 60 dni).

Szacunkowy koszt: 8 000-25 000 zł na pierwsze szkolenie zewnętrzne dla 5-osobowego zarządu.

Odpowiedzialny: Cybersecurity Officer we współpracy z HR.

Ten format powtarzany w każdej sekcji ustalenia, daje strukturę, konkretność, działanie.

Bibliografia

Institute of Internal Auditors. (2023). International Standards for the Professional Practice of Internal Auditing, Reporting Standards. IIA. https://www.theiia.org/
ISACA. (2024). IT Audit Framework (ITAF), Section 6: Reporting. ISACA. https://www.isaca.org/
ISO. (2018). ISO 19011:2018, Guidelines for auditing management systems. https://www.iso.org/standard/70017.html
Tufte, E. R. (2001). The Visual Display of Quantitative Information (2nd ed.). Graphics Press. ISBN: 978-0961392147.
Heath, C., & Heath, D. (2007). Made to Stick: Why Some Ideas Survive and Others Die. Random House. ISBN: 978-1400064281.
Komisja Europejska. (2022). Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (NIS2). https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32022L2555

Raport, który nie prowadzi do decyzji, jest stratą. W cotygodniowym newsletterze SkanujFirme.pl publikujemy szablony struktur raportów, przykłady executive summaries, scenariusze prezentacji wyników. Zapisz się, bezpłatnie.

Audyt kultury bezpieczeństwa, diagnoza zespołu

Marek Porycki — Wed, 08 Jul 2026 13:40:00 +0000

W badaniach Verizon DBIR 2024 wzór się powtarza: 68% naruszeń bezpieczeństwa zaczyna się od czynnika ludzkiego, phishingu, nieostrożnego użytkownika, naruszenia procedury, social engineeringu. Najlepsze technologie na świecie nie zatrzymają człowieka, który kliknie na link złośliwy. Z drugiej strony, zespół z silną kulturą bezpieczeństwa wykrywa próby ataków, ostrzega innych, raportuje anomalie, kompensuje braki technologiczne.

Kultura bezpieczeństwa jest najtrudniejszym wymiarem audytu firmy. Nie da się jej oszacować przez analizę dokumentów. Wymaga ankietowania, wywiadów, testów, obserwacji. Jest też wymiarem najtrwalej wpływającym na bezpieczeństwo, kultura zmienia się w latach, nie miesiącach. Ten tekst opisuje pełną metodologię audytu kultury bezpieczeństwa dla średniej polskiej firmy.

Cztery wymiary kultury bezpieczeństwa

Wymiar 1: świadomość. Czy pracownicy rozumieją, dlaczego procedury bezpieczeństwa istnieją? Znają główne ryzyka? Widzą sens w wymaganiach, czy traktują jako biurokrację?

Wymiar 2: postawy. Czy zespół traktuje bezpieczeństwo jako wspólną odpowiedzialność, czy jako problem działu IT? Czy zgłaszają wątpliwości? Czy tworzą obejścia procedur (workarounds)?

Wymiar 3: zachowania. Konkretne praktyki: hasła (managery vs karteczki), pendrive (szyfrowane?), praca zdalna (firmowe vs prywatne urządzenia), reakcja na phishing (zgłaszają vs klikają), reakcja na nietypowe sytuacje (raportują vs ignorują).

Wymiar 4: liderzy. Czy zarząd modeluje pożądane zachowania? Czy CISO ma realny wpływ czy tylko formalne stanowisko? Czy szkolenia są priorytetem czy obowiązkiem do odhaczenia?

Model Westruma, typologia kultur organizacyjnych

Ron Westrum (2004) wyróżnił trzy typy kultur organizacyjnych w kontekście przekazywania informacji o problemach:

Patologiczna (power-oriented): informacja blokowana, problemy ukrywane, posłańcy karani. “Nie pisz tego w mailu”, “to nie wyszło z naszego działu”, “nie będziemy się tym zajmować, dopóki nas nie złapią”. Cyberbezpieczeństwo w takiej kulturze jest reaktywne, kosmetyczne.

Biurokratyczna (rule-oriented): informacja przepływa przez formalne kanały, problemy traktowane proceduralnie, posłańcy ignorowani. “Zgodnie z procedurą…”, “nie jest to nasza odpowiedzialność”, “musisz wypełnić formularz”. Cyberbezpieczeństwo formalne, papierowe.

Generatywna (performance-oriented): informacja aktywnie poszukiwana, problemy traktowane jako okazje do uczenia, posłańcy szkoleni. “Co tu się stało?”, “co możemy z tego nauczyć?”, “jak temu zapobiec?”. Cyberbezpieczeństwo proaktywne, integralne.

W typowej polskiej średniej firmie kultura jest mieszana, różne działy mają różne kultury. Dział IT często bardziej generatywny, dział sprzedaży bardziej biurokratyczny, dział produkcji bardziej patologiczny.

Audyt kultury bezpieczeństwa identyfikuje ten typ na poziomie organizacyjnym i działowym.

Metoda 1: ankiety anonimowe

Najszerszy zasięg, najmniej głęboka analiza, ale niezbędne dla obrazu organizacyjnego.

Konstrukcja ankiety: 25-40 pytań pokrywających cztery wymiary. Każde pytanie ma skalę Likerta (1-5), niektóre pytania otwarte na komentarze.

Przykładowe pytania:

Świadomość:

“Wiem, jakie są główne zagrożenia cyberbezpieczeństwa dla naszej firmy.”
“Rozumiem, dlaczego musimy używać MFA / haseł / szyfrowania.”

Postawy:

“Cyberbezpieczeństwo to wspólna odpowiedzialność wszystkich pracowników.”
“Czuję się komfortowo zgłaszając podejrzane maile lub aktywności.”

Zachowania:

“Używam managera haseł zamiast zapisywać je w plikach.”
“Wiem, jak zgłosić podejrzany email.”

Liderzy:

“Mój przełożony aktywnie wspiera praktyki cyberbezpieczeństwa.”
“Zarząd komunikuje znaczenie cyberbezpieczeństwa.”

Anonimowość: absolutnie kluczowa. Pracownicy nie odpowiedzą szczerze, jeśli mają obawę, że wynik trafi do ich kierownika. Narzędzia: SurveyMonkey, Microsoft Forms (z anonymous), Google Forms (anonymous).

Próg uczestnictwa: minimum 50% pracowników, optymalnie 75%+. Niski udział wskazuje już na problem kulturowy (apatia, nieufność, brak czasu).

Analiza: średnie i mediany dla każdego pytania. Identyfikacja obszarów słabszych. Porównanie między działami. Kategoria pytań otwartych, analiza tekstowa, identyfikacja powtarzających się tematów.

Output: raport ankietowy z wynikami numerycznymi i analizą jakościową komentarzy.

Metoda 2: testy phishingowe

Najskuteczniejszy test rzeczywistych zachowań w wymiarze 3 (zachowania).

Procedura: kontrolowana symulacja kampanii phishingowej. Wysłanie do wszystkich pracowników wiadomości udających legalny komunikat (np. fałszywa rachunki, fałszywa prośba HR, fałszywa wiadomość od dostawcy).

Co mierzyć:

procent pracowników, którzy kliknęli na link;
procent, którzy podali dane (login, hasło) na fałszywej stronie;
procent, którzy zgłosili wiadomość do IT/security;
czas między otrzymaniem a zgłoszeniem.

Benchmark branżowy (Proofpoint, KnowBe4 raporty 2024):

typowy procent klikających: 15-25%;
po podstawowym szkoleniu: 8-15%;
po zaawansowanym programie: 3-8%;
procent zgłaszających: typowo 8-20%;
po programie świadomości: 30-50%.

Narzędzia: GoPhish (open-source), KnowBe4 (komercyjny), PhishMe.

Etyczność: test musi być wcześniej zapowiedziany ogólnie (“w najbliższych miesiącach przeprowadzimy test phishingowy”). Pracownicy, którzy klikną, powinni otrzymać szkolenie, nie karę. Cel, uczenie, nie publiczne kompromitowanie.

Output: raport z wynikami testu plus plan działań szkoleniowych.

Metoda 3: wywiady z pracownikami

Najgłębsza analiza, ale ograniczony zasięg.

Próbka: 15-30 osób z różnych szczebli i działów. Wybór losowy z elementem stratyfikacji (zarząd, kierownicy, specjaliści, juniorzy, różne działy).

Forma: wywiad indywidualny, 45-60 minut. Anonimowość zapewniona przez audytora, wyniki agregowane, nie przypisane do osób.

Pytania pogłębione:

“Opowiedz o sytuacji, gdy ktoś w firmie miał wątpliwość bezpieczeństwa. Co się stało?”
“Jak zareagowałeś, gdy ostatnio dostałeś podejrzaną wiadomość?”
“Co byłoby najtrudniejsze, gdybyś musiał zmienić swoją rutynę pracy ze względu na bezpieczeństwo?”
“Jakie procedury bezpieczeństwa wydają Ci się sensowne, jakie nie?”
“Czy masz wrażenie, że ktoś byłby ukarany za błąd cyberbezpieczeństwa, czy traktowano by to jako naukę?”
“Czy zgłosiłbyś incydent, który sam spowodowałeś?” (kluczowe pytanie kulturowe)

Analiza: transkrypcje (lub szczegółowe notatki) → kodowanie tematyczne → identyfikacja powtarzających się wzorców.

Output: raport jakościowy ze wzorcami i cytatami (anonimowymi).

Metoda 4: obserwacje w miejscu pracy

Audytor spędza czas w firmie obserwując rzeczywiste zachowania.

Co obserwować:

jak pracownicy obsługują hasła (sticky notes, managery, łatwe hasła);
czy ekrany są blokowane przy odejściu od stanowiska;
jak obsługiwane są pliki na pendrivach i wymiennych nośnikach;
jak komunikuje się o incydentach (otwarcie czy szeptem);
jak reagują kierownicy w razie problemów (pomocnie czy karnie);
czy używane są tymczasowe obejścia procedur.

Obserwacje wymagają delikatności, pracownicy świadomi obecności audytora zachowują się inaczej. Najlepsze: obecność audytora przez kilka dni, w kilku miejscach, w różnym czasie.

Output: raport obserwacji z konkretnymi przykładami zachowań.

Metoda 5: analiza incydentów wewnętrznych

Każdy zarejestrowany incydent jest oknem na kulturę.

Pytania analityczne:

Czy incydent był zgłoszony, gdy się pojawił, czy odkryty później?
Kto zgłosił, sam zaangażowany pracownik czy ktoś inny?
Jak długo trwało zgłoszenie od momentu zauważenia?
Jak zarząd zareagował, wsparciem do uczenia czy presją kary?
Co się zmieniło po incydencie, czy lessons learned wdrożone czy zignorowane?

Zdrowa kultura: szybkie zgłoszenia, otwarta komunikacja, konkretne wnioski wdrożone. Patologiczna kultura: incydenty ukrywane, odkrywane przypadkiem, posłańcy karani.

Output: analiza ostatnich 12-24 miesięcy incydentów jako wskaźnik kultury.

Realny budżet audytu kultury

Audyt kultury wewnętrzny (siłami własnymi): 40 000-100 000 zł kosztów twardych (narzędzia ankietowe, testy phishingowe), plus 200-400 godzin czasu zespołu. Wymagania: kompetencja w prowadzeniu wywiadów, narzędzia analityczne.

Audyt kultury zewnętrzny: 60 000-180 000 zł zewnętrznych usług. Korzyści: niezależność, doświadczenie, brak konfliktu interesów.

Audyt kultury hybrydowy: 30 000-80 000 zł zewnętrznych usług + zespół wewnętrzny. Najczęściej optymalny.

Czas pełnego audytu kultury: 8-14 tygodni.

Co najczęściej ujawniają audyty kultury

W 30+ audytach kultury polskich firm:

Ustalenie 1: rozdźwięk między oficjalną deklaracją a rzeczywistością. Zarząd deklaruje “cyber to nasza priorytet”, pracownicy odbierają “cyber to przeszkoda do pracy”. Klasyczne dla kultury biurokratycznej.

Ustalenie 2: jeden dział wybitnie różni się od reszty. Zwykle dział IT lub specjaliści cyber mają kulturę generatywną, reszta firmy biurokratyczną. Bezpieczeństwo zatrzymuje się na granicy IT.

Ustalenie 3: strach przed zgłoszeniem własnego błędu. 40-60% pracowników w wywiadach przyznaje, że nie zgłosiłoby incydentu, który sami spowodowali. Klasyczna patologia kultury.

Ustalenie 4: szkolenia jako biurokracja. Pracownicy odbywają e-learning, ale 80% nie pamięta treści po miesiącu. Forma: passive learning bez kontekstu.

Ustalenie 5: liderzy nie modelują zachowań. CEO używa prostego hasła, prosi sekretariat o “zalogowanie się za niego do bankowości”, e-mail służbowy na prywatnym laptopie. Sygnał dla całej firmy.

Strategie poprawy kultury

Kultura zmienia się w latach, nie tygodniach. Ale są dźwignie krótkoterminowe:

Dźwignia 1: leadership behaviors. Zarząd jako pierwszy przykład. Demonstrowanie używania managera haseł, MFA, regularnych szkoleń.

Dźwignia 2: transformacja szkoleń. Z e-learningu pasywnego na warsztatowy interaktywny. Z generycznych treści na konkretnie firmowe scenariusze.

Dźwignia 3: nagradzanie zgłoszeń. Każde zgłoszenie phishingu/anomalii, publiczne uznanie, czasem konkretna nagroda. Buduje normę “zgłaszanie jest dobre”.

Dźwignia 4: psychological safety. Komunikacja “błędy są okazjami do uczenia”. Brak punitive culture za uczciwe błędy. Zachowanie konsekwencji za zaniedbania świadome.

Dźwignia 5: regularność. Cyberbezpieczeństwo jako stały element komunikacji wewnętrznej (cotygodniowy biuletyn, miesięczne briefy zarządu, kwartalne aktualizacje).

Dźwignia 6: champions cyber. Wybór 5-15 osób w firmie (nie z IT) jako “champions cyber”, naturalni liderzy w swoich działach, którzy popularyzują dobre praktyki.

Najczęstsze błędy w audytach kultury

Błąd 1: pomijanie wymiaru kultury w audycie firmy. Audyt techniczny + compliance, kultura ignorowana. Wynik: pełna mapa techniczna, brak rozumienia, dlaczego ludzie nie przestrzegają procedur.

Błąd 2: ankieta jako jedyna metoda. Ankieta daje skalowalność, ale nie głębi. Bez wywiadów, fragmentaryczny obraz.

Błąd 3: brak anonimowości. Pracownicy nie odpowiadają szczerze. Wynik bezwartościowy.

Błąd 4: testy phishingowe jako narzędzie kary. “Kto kliknął, ten ukarany” niszczy zaufanie. Lepiej: kto kliknął, ten szkolony.

Błąd 5: jednokrotny audyt bez follow-upu. Kultura zmienia się latami. Coroczne audyty z porównaniem trendów dają realny obraz rozwoju.

Bibliografia

Westrum, R. (2004). A typology of organisational cultures. Quality and Safety in Health Care, 13(suppl 2), ii22-ii27. https://doi.org/10.1136/qshc.2003.009522
Schein, E. H. (2017). Organizational Culture and Leadership (5th ed.). Wiley. ISBN: 978-1119212041.
Edmondson, A. (2019). The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth. Wiley. ISBN: 978-1119477242.
Verizon. (2024). 2024 Data Breach Investigations Report. Verizon Business. https://www.verizon.com/business/resources/reports/dbir/
Proofpoint. (2024). State of the Phish Report 2024. Proofpoint. https://www.proofpoint.com/us/resources/threat-reports/state-of-phish
SANS Institute. (2024). Security Awareness Report. SANS. https://www.sans.org/security-awareness-training/resources/security-awareness-report
NIST. (2020). SP 800-50 Rev. 1: Building an Information Technology Security Awareness Program. National Institute of Standards and Technology. https://csrc.nist.gov/publications/detail/sp/800-50/rev-1/draft

Kultura bezpieczeństwa to wymiar najtrudniejszy do zmierzenia, ale najtrwalej wpływający. W cotygodniowym newsletterze SkanujFirme.pl publikujemy szablony ankiet kulturowych, scenariusze wywiadów, programy zmiany kultury. Zapisz się, bezpłatnie.

Audyt certyfikacyjny a zwykły audyt: czym się różnią, co wybrać

Marek Porycki — Fri, 03 Jul 2026 10:17:00 +0000

W dyskusjach zarządczych słowa “audyt” i “certyfikacja” są często używane wymiennie. To poważny błąd kategoryalny. Audyt to proces analizy, którego wynikiem jest raport. Certyfikacja to formalne potwierdzenie zgodności ze standardem, którego wynikiem jest certyfikat. Oba narzędzia mają inne cele, inne koszty, inną wartość rynkową, inną głębokość. Wybór między nimi (lub kombinacja obu) jest jedną z ważniejszych decyzji strategicznych w obszarze zarządzania jakością.

Ten artykuł rozkłada decyzję na osiem wymiarów: cel, proces, wynik, koszt, wartość dla zarządu, wartość dla klientów, wartość dla regulatorów, dynamika w czasie. Pokazuje, kiedy audyt jest właściwy, kiedy certyfikacja, kiedy oba. Konkretne scenariusze dla różnych typów firm.

Definicje pojęć

Audyt to systematyczna, niezależna i udokumentowana ocena obszaru działalności firmy w celu określenia stopnia zgodności z określonymi kryteriami. Wynikiem audytu jest raport zawierający ustalenia, wnioski i rekomendacje.

Audyt może być:

wewnętrzny (przez własny zespół) lub zewnętrzny (przez niezależną firmę);
regularnie powtarzany (co 12, 18, 24 miesiące) lub jednorazowy;
pełen (obejmujący wszystkie obszary) lub fragmentaryczny;
prowadzony pod różne kryteria (RODO, NIS2, ISO 27001, SOC 2, sektorowe).

Certyfikacja to formalny proces, w ramach którego niezależna jednostka certyfikująca (akredytowana przez krajowe centrum akredytacji) wydaje firmie certyfikat potwierdzający zgodność z określonym standardem. Certyfikat jest dokumentem o określonej dacie ważności.

Certyfikacja zawsze obejmuje audyt jako element procesu, ale audyt nie jest celem certyfikacji, celem jest wydanie (lub odmowa wydania) certyfikatu. Audyt certyfikacyjny ma sztywną metodologię narzucaną przez standard i jednostkę certyfikującą.

Wymiar 1: cele

Audyt: diagnoza stanu i identyfikacja obszarów do poprawy. Cel rozwojowy, wynik prowadzi do decyzji o inwestycjach, zmianach procesów, korektach. Audyt jest narzędziem zarządczym wewnętrznym.

Certyfikacja: formalne potwierdzenie zgodności ze standardem. Cel komunikacyjny, certyfikat służy jako dowód dla zewnętrznych interesariuszy (klientów, regulatorów, partnerów). Certyfikacja jest narzędziem komunikacji zewnętrznej.

Można mieć doskonale działający system zarządzania bez certyfikatu (i wielu firm tak ma). Można mieć certyfikat bez realnie działającego systemu (zjawisko “compliance theater”, papierowa zgodność). Te dwie sytuacje są fundamentalnie różne, choć z zewnątrz mogą wyglądać podobnie.

Wymiar 2: proces

Audyt: zwykle 4-12 tygodni. Etapy: przygotowanie → mapping → ocena → raport → ewentualne wdrożenie. Audytor ma elastyczność co do metodologii (szczególnie audyt wewnętrzny). Wynik dostosowywany do potrzeb klienta, głębsza analiza w obszarach priorytetowych, lżejsza w mniej istotnych.

Certyfikacja: typowo 6-18 miesięcy od decyzji do certyfikatu. Etapy: gap analysis → wdrożenie systemu → audyt wewnętrzny pierwszy → korekty → audyt certyfikacyjny etap 1 (dokumentacja) → audyt certyfikacyjny etap 2 (operacje) → certyfikat → audyty nadzorcze roczne → recertyfikacja co 3 lata. Sztywna metodologia narzucona przez standard.

Certyfikacja jest “pełna lub żadna”, albo firma spełnia wszystkie wymagania standardu, albo nie. Audyt może być częściowy, fragmentaryczny, dopasowany do potrzeb.

Wymiar 3: wynik

Audyt: raport (50-150 stron typowo) zawierający ustalenia, mapę ryzyka, rekomendacje priorytetyzowane. Raport to materiał wewnętrzny, może być pokazywany zewnątrz wybiórczo. Treść raportu jest zwykle szczegółowa i ujawnia luki firmy.

Certyfikacja: certyfikat (1-2 strony) plus szczegółowa dokumentacja audytu certyfikacyjnego (zwykle nie publiczna, dla wewnętrznych potrzeb). Certyfikat publicznie używany w komunikacji marketingowej, na stronach internetowych, w przetargach.

Audyt = wiedza o firmie. Certyfikat = znaczek dla świata.

Wymiar 4: koszt

Audyt dla średniej firmy:

audyt wewnętrzny: 5 000-30 000 zł plus czas zespołu;
audyt zewnętrzny: 50 000-300 000 zł zależnie od zakresu;
audyt hybrydowy: 30 000-150 000 zł.

Certyfikacja dla średniej firmy (np. ISO 27001):

pierwsza certyfikacja: 100 000-400 000 zł (gap analysis, wdrożenie systemu, audyty);
audyty nadzorcze roczne: 25 000-60 000 zł;
recertyfikacja co 3 lata: 50 000-150 000 zł;
czas wewnętrzny: 200-600 godzin pierwsze wdrożenie, 80-200 godzin rocznie utrzymanie.

Koszt całkowity certyfikacji w cyklu trzyletnim: 200 000-650 000 zł plus czas zespołu. Koszt audytu w cyklu trzyletnim (audyt co 18 miesięcy): 100 000-400 000 zł.

Certyfikacja jest droższa, ale koszt rozłożony jest w innym sposób, duża inwestycja początkowa, niski koszt utrzymania.

Wymiar 5: wartość dla zarządu

Audyt: wysoka wartość. Konkretne ustalenia, mapa luk, plan działań. Pomaga w decyzjach zarządczych. Pokazuje, gdzie inwestować.

Certyfikacja: umiarkowana wartość zarządcza. Sam certyfikat nie daje informacji rozwojowej. Wartość pochodzi z procesu wdrożenia (który de facto jest serią wewnętrznych audytów).

Dla zarządu skoncentrowanego na realnym zarządzaniu ryzykiem audyt ma większą wartość niż certyfikat. Dla zarządu skoncentrowanego na zewnętrznej komunikacji, odwrotnie.

Wymiar 6: wartość dla klientów

Audyt: niska wartość. Klienci rzadko proszą o raporty audytowe (są zwykle poufne i zbyt szczegółowe).

Certyfikacja: wysoka wartość, zwłaszcza w B2B. ISO 27001 jako warunek wielu przetargów. SOC 2 jako warunek sprzedaży do enterprise USA. Certyfikat to “skrótowy język zaufania”, klient nie musi czytać 100-stronicowego raportu audytowego, wystarcza mu wiedza, że firma ma certyfikat.

Dla firm B2B sprzedających do dojrzałych klientów certyfikacja często ma realny zwrot biznesowy. Pierwszy certyfikat ISO 27001 w średniej firmie SaaS może otworzyć kontrakty wartości 5-20 mln zł rocznie, nieosiągalne bez certyfikatu.

Wymiar 7: wartość dla regulatorów

Audyt: umiarkowana wartość. Raport audytu może być pokazany regulatorowi w razie kontroli, dowodzi, że firma aktywnie zarządza ryzykiem. Ale regulator wciąż prowadzi własną kontrolę, audyt nie zastępuje.

Certyfikacja: wysoka wartość. Certyfikat ISO 27001 lub SOC 2 znacząco skraca i ułatwia kontrolę regulacyjną. CSIRT NASK lub UODO kontrolujący firmę z aktualnym ISO 27001 stosuje uproszczoną procedurę. Firmy bez certyfikatu są kontrolowane głębiej.

Dla firm pod silną regulacją (NIS2, RODO, sektorowe) certyfikacja ma realną wartość obronną w ewentualnych postępowaniach.

Wymiar 8: dynamika w czasie

Audyt: snapshot w czasie. Audyt z 2024 roku odzwierciedla stan z 2024 roku. Po 18 miesiącach firma się zmieniła, wymagana powtórna ocena.

Certyfikacja: ciągłość przez cykle. Certyfikat ważny 3 lata z audytami nadzorczymi rocznymi. Wymusza utrzymanie systemu w czasie. Bez utrzymania, utrata certyfikatu.

Certyfikacja narzuca dyscyplinę utrzymania. Audyty pojedyncze nie, można dać sobie spokój po wykonaniu rekomendacji i nie wracać przez lata.

Decyzja: audyt, certyfikacja, czy oba

Scenariusz 1: średnia firma B2B SaaS sprzedająca do enterprise klientów USA. Rekomendacja: certyfikacja ISO 27001 + SOC 2 Type II jako warunek sprzedaży. Audyty wewnętrzne między audytami certyfikacyjnymi.

Scenariusz 2: średnia firma produkcyjna z silnym wewnętrznym IT, podlegająca NIS2. Rekomendacja: regularne audyty wewnętrzne plus zewnętrzny audyt holistyczny co 24 miesiące. Certyfikacja ISO 27001, opcjonalna, jeśli klienci jej wymagają.

Scenariusz 3: średnia firma usługowa B2C. Rekomendacja: regularne audyty RODO, ewentualnie audyt holistyczny po incydencie. Certyfikacja zwykle nieopłacalna (klienci konsumenccy nie pytają o ISO).

Scenariusz 4: szpital wojewódzki podlegający NIS2. Rekomendacja: audyty zgodności RODO+NIS2 + certyfikacja ISO 27001 (rosnące oczekiwanie regulatorów sektorowych).

Scenariusz 5: bank lub instytucja finansowa. Rekomendacja: certyfikacja obowiązkowa (sektorowo) plus regularne audyty wewnętrzne i zewnętrzne. Często kombinacja kilku certyfikacji (ISO 27001, ISO 22301, SOC 2, sektorowe).

Scenariusz 6: dostawca infrastruktury krytycznej (energia, telekomunikacja). Rekomendacja: certyfikacja sektorowa + regularne audyty proaktywne. Specyficzne wymogi sektorowe (URE, UKE) dominują nad standardami międzynarodowymi.

Scenariusz 7: firma w trakcie due diligence (sprzedaż lub inwestycja). Rekomendacja: zewnętrzny audyt holistyczny z renomowanej firmy. Certyfikacja w 6-9 miesięcy przed transakcją podnosi wycenę.

Wybór konkretnego standardu certyfikacyjnego

ISO 27001, najszerzej rozpowszechniona certyfikacja systemu zarządzania bezpieczeństwem informacji. Międzynarodowa, neutralna sektorowo. Rekomendacja domyślna.

SOC 2, amerykański standard, popularny w sektorze tech. Wymóg dla wielu kontraktów enterprise USA. Komplementarne z ISO 27001.

ISO 22301, zarządzanie ciągłością działania. Komplementarne z ISO 27001 dla sektorów wymagających odporności (energia, ochrona zdrowia, finanse).

ISO 27701, rozszerzenie ISO 27001 o RODO. Niszowe, dla firm eksponowanych na audyty RODO.

Sektorowe: w sektorze finansowym (KNF), energetycznym (URE), ochrony zdrowia (sektorowo), własne certyfikaty sektorowe.

Pełniejsze omówienie certyfikacji w artykule Certyfikacje wymagane lub rekomendowane na testnis2.pl.

Najczęstsze błędy decyzyjne

Błąd 1: certyfikat zamiast systemu. Firma kupuje certyfikat (od jednostki nieakredytowanej lub poprzez “minimum minimorum”) bez budowy realnego systemu. Wartość: papier. Ryzyko regulacyjne: wysokie.

Błąd 2: audyt zamiast certyfikatu, gdy klienci wymagają. Firma robi solidne audyty, ale klienci w przetargach wymagają ISO 27001. Bez certyfikatu nie wygrywa kontraktów. Audyty dla wewnętrznej spokojności sumienia, brak wartości rynkowej.

Błąd 3: certyfikat bez utrzymania. Firma uzyskuje certyfikat, po roku przestaje utrzymywać system. W audycie nadzorczym traci certyfikat. Odbudowa: kolejne 12+ miesięcy.

Błąd 4: zbyt szeroka certyfikacja w pierwszej iteracji. Firma próbuje certyfikować wszystkie obszary jednocześnie. Skutek: niewdrożenie w terminie, koszty rosnące. Lepiej: certyfikacja zaczyna od węższego zakresu (jeden dział lub jedna usługa), rozszerzana w kolejnych cyklach.

Błąd 5: ignorowanie audytu na rzecz tylko certyfikacji. Firma certyfikuje ISO 27001 i uznaje, że audyt jest niepotrzebny. Skutek: brak rozwoju poza minimalne wymogi standardu. Audyt holistyczny co 24 miesiące daje znacznie głębszą wartość niż sam certyfikat.

Strategia łączona: audyt + certyfikacja

Najlepsza praktyka dla większości średnich firm to kombinacja:

Cykl 3-letni:

Rok 1: audyt holistyczny zewnętrzny → identyfikacja luk → wdrożenie rekomendacji.
Rok 2: certyfikacja ISO 27001 (jeśli wybrana) → audyty nadzorcze roczne.
Rok 3: audyt holistyczny zewnętrzny → identyfikacja nowych obszarów rozwoju → drugi audyt nadzorczy → przygotowanie do recertyfikacji.

Audyt daje rozwój. Certyfikacja daje komunikację. Obie razem dają pełen system zarządzania jakością.

Bibliografia

ISO. (2018). ISO 19011:2018, Guidelines for auditing management systems. https://www.iso.org/standard/70017.html
ISO. (2022). ISO/IEC 27001:2022, Information security management systems, Requirements. https://www.iso.org/standard/27001
AICPA. (2017). SOC 2 Reports, Trust Services Criteria. American Institute of CPAs. https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2
Polskie Centrum Akredytacji. (2024). Wykaz akredytowanych jednostek certyfikujących systemy zarządzania. PCA. https://www.pca.gov.pl/
Institute of Internal Auditors. (2023). International Standards for the Professional Practice of Internal Auditing. IIA. https://www.theiia.org/
NIST. (2024). Cybersecurity Framework 2.0. National Institute of Standards and Technology. https://doi.org/10.6028/NIST.CSWP.29
Komisja Europejska. (2022). Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (NIS2). https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32022L2555

Audyt i certyfikacja to dwa różne narzędzia. W cotygodniowym newsletterze SkanujFirme.pl analizujemy konkretne strategie łączenia audytu i certyfikacji dla różnych typów firm. Zapisz się, bezpłatnie.

Audyt łańcucha dostaw, diagnoza ryzyka dostawców (2026)

Marek Porycki — Sun, 28 Jun 2026 07:54:00 +0000

W grudniu 2020 roku świat dowiedział się o ataku na SolarWinds. Atakujący wszedł nie do firm, które ostatecznie zaatakował, wszedł do dostawcy oprogramowania, którego używały te firmy. SolarWinds Orion, popularne narzędzie monitorowania infrastruktury, dostarczyło zatrutą aktualizację 18 000 organizacjom. Wśród ofiar, amerykańskie ministerstwa, korporacje technologiczne, agencje wywiadu. Atak ujawnił fundamentalną prawdę o cyberbezpieczeństwie XXI wieku: Twój łańcuch dostaw to Twoje ryzyko.

Audyt łańcucha dostaw stał się jednym z dziesięciu obowiązkowych obszarów NIS2 (artykuł 21 ust. 2 lit. d). To nie jest miły dodatek, to wymóg prawny dla wszystkich podmiotów kluczowych i ważnych. Ale wymóg prawny to dopiero powód minimalny. Realny powód to fakt, że większość poważnych incydentów cyber ostatnich pięciu lat zaczęła się w łańcuchu dostaw, nie w głównej infrastrukturze ofiary.

Ten tekst opisuje pełną metodykę audytu łańcucha dostaw dla średniej firmy, od mapowania dostawców po plan exit z kluczowych zależności.

Faza 1: pełna mapa dostawców

Krok 1: identyfikacja kategorii dostawców. Pełna mapa obejmuje sześć kategorii:

dostawcy infrastruktury (hosting, kolokacja, chmura);
dostawcy oprogramowania (ERP, CRM, BI, narzędzia biurowe);
dostawcy usług IT (outsourcing, helpdesk, monitoring);
dostawcy sprzętu (serwery, urządzenia sieciowe, end-pointy);
dostawcy usług profesjonalnych z dostępem do systemów (księgowość, audytorzy zewnętrzni z dostępem);
dostawcy specjalistyczni dla branży (np. systemy płatnicze dla handlu, systemy medyczne dla ochrony zdrowia).

Krok 2: zebranie listy. Źródła:

ewidencja kontraktów i umów (dział prawny);
ewidencja faktur (księgowość);
mapa systemów IT (dział IT);
wywiady z kierownikami działów (“z kim współpracujecie zewnętrznie?”);
ewidencja kont w systemach zewnętrznych.

W typowej firmie 100-osobowej mapa zawiera 25-60 podmiotów. Pierwszy mapping zwykle ujawnia 10-20% dostawców, którzy nie są w żadnej formalnej ewidencji.

Krok 3: subdostawcy. Dla każdego głównego dostawcy, kim są jego subdostawcy z dostępem do Twoich systemów lub danych? Wymaganie powinno być zapisane w umowie (“dostawca informuje o wszystkich subdostawcach z dostępem”). W praktyce, pierwsze pytanie często ujawnia, że dostawca sam nie wie.

Krok 4: wizualizacja. Mapa łańcucha dostaw w formie graficznej. Twoja firma jako węzeł centralny, dostawcy poziomu 1, subdostawcy poziomu 2. Dla średniej firmy wizualizacja może mieć 50-150 węzłów.

Output fazy 1: kompletna mapa dostawców (lista plus grafika), z polami: nazwa, kategoria, kontakt, kontrakt, kategoria danych/systemów dostępne, subdostawcy.

Faza 2: klasyfikacja ryzyka

Krok 5: kryteria klasyfikacji. Trzy poziomy ryzyka:

Poziom A (krytyczny): awaria/kompromitacja powoduje natychmiastowe lub poważne zakłócenie świadczenia usług kluczowych. Przykłady: główny dostawca chmurowy, główny ERP, dostawca łączności.

Poziom B (istotny): awaria powoduje znaczące, ale obsługiwalne zakłócenie. Przykłady: dostawcy SaaS dla CRM, marketing automation, BI.

Poziom C (pozostały): awaria powoduje niedogodność, ale nie zagraża ciągłości. Przykłady: drobne narzędzia, jednorazowi konsultanci.

Krok 6: klasyfikacja każdego dostawcy. Stosując kryteria, przypisz poziom każdemu z mapy. Klasyfikacja powinna być uzgodniona z osobami z różnych działów (IT, operacje, biznes), nie tylko działu compliance.

Krok 7: weryfikacja klasyfikacji. Test: jeśli ten dostawca dziś przestałby działać, jak długo trwałyby zakłócenia? Jakie skutki finansowe? Jaki wpływ na klientów?

Output fazy 2: macierz dostawców z poziomami ryzyka. Typowo dla firmy 100-osobowej: 3-8 dostawców poziomu A, 10-25 poziomu B, pozostali poziomu C.

Faza 3: ocena dostawców poziomu A

Krok 8: pełna ocena dostawców krytycznych. Każdy dostawca poziomu A wymaga:

aktualnego raportu audytu zewnętrznego (SOC 2 Type II, ISO 27001 z ostatnich 12 miesięcy);
pełnego kwestionariusza cyberbezpieczeństwa (40+ pytań);
klauzul cyberbezpieczeństwa w umowie (powiadomienie o incydencie, prawo do audytu, standardy bezpieczeństwa, ubezpieczenie cyber);
planu reakcji na incydent po stronie dostawcy z konkretnymi kontaktami;
raportu o subdostawcach;
udokumentowanej historii incydentów w ostatnich 24 miesiącach.

Krok 9: weryfikacja certyfikacji. SOC 2 lub ISO 27001, sprawdź:

czy zakres certyfikacji obejmuje usługi, które kupujesz;
czy raport jest aktualny (≤ 12 miesięcy);
czy raport wskazuje istotne ustalenia (jeśli tak, czy są naprawione);
czy jednostka certyfikująca jest akredytowana.

Krok 10: weryfikacja kwestionariusza. Kwestionariusz wypełniony przez dostawcę nie jest dowodem, jest deklaracją. Dla dostawców poziomu A weryfikuj wybrane elementy przez:

prośbę o dowody (konkretne dokumenty potwierdzające);
referencje innych klientów;
ewentualnie audyt na miejscu.

Krok 11: ocena umowy. Sprawdź czy umowa zawiera minimum 8 klauzul cyberbezpieczeństwa (omówione w artykule Łańcuch dostaw NIS2, supply chain risk na testnis2.pl).

Output fazy 3: dla każdego dostawcy A, kompletny dossier oceny.

Faza 4: ocena dostawców poziomu B

Krok 12: uproszczona ocena dostawców istotnych. Każdy dostawca B wymaga:

kwestionariusza cyberbezpieczeństwa (uproszczonego, 15-20 pytań);
klauzul cyberbezpieczeństwa w umowie (podstawowy zestaw);
oświadczenia o poziomie bezpieczeństwa (zwykle ISO 27001 wystarcza jako dowód).

Krok 13: cykl weryfikacji. Dostawcy B weryfikowani co 18-24 miesięcy.

Output fazy 4: aktualne kwestionariusze i klauzule dla wszystkich dostawców B.

Faza 5: minimalna ocena dostawców poziomu C

Krok 14: ocena dostawców pozostałych. Każdy dostawca C wymaga:

klauzul cyberbezpieczeństwa minimalnych w umowie;
oświadczenia dostawcy o przestrzeganiu standardów branżowych.

Krok 15: cykl weryfikacji. Dostawcy C weryfikowani co 24-36 miesięcy.

Faza 6: planowanie exit

Krok 16: identyfikacja kluczowych zależności. Dla dostawców poziomu A zadaj pytanie: jak długo zajęłaby migracja do alternatywnego dostawcy w razie konieczności? Jaki byłby koszt? Jaki wpływ na operacje?

Krok 17: plan exit dla dostawców krytycznych. Każdy dostawca A powinien mieć udokumentowany plan exit:

alternatywni dostawcy zidentyfikowani;
procedura migracji (etapy, terminy);
zabezpieczenie danych (zwrot/usunięcie z systemów dostawcy);
procedura komunikacji z klientami w trakcie migracji;
szacunkowy koszt i czas.

Krok 18: zabezpieczenia kontraktowe. Umowa powinna zawierać klauzule dotyczące exit:

minimalne wypowiedzenie (zwykle 6-12 miesięcy);
zwrot danych w formacie umożliwiającym migrację;
współpraca w okresie przejściowym;
zabezpieczenie finansowe (jeśli wartość kontraktu istotna).

Plan exit nie ma na celu rezygnacji z dostawcy. Ma na celu zapewnienie, że firma nie jest zakładnikiem dostawcy w sytuacji kryzysowej (np. dostawca zbankrutuje, podnosi ceny radykalnie, nie wdraża wymaganych zmian).

Faza 7: monitoring ciągły

Krok 19: news monitoring. Subskrypcja newsletterów branżowych, alertów o incydentach. Każdy poważny incydent w sektorze technologicznym sprawdzaj, czy dotyczy któregoś z Twoich dostawców?

Krok 20: roczny przegląd. Pełen przegląd ryzyka łańcucha dostaw raz w roku jako odrębny punkt agendy zarządu.

Krok 21: aktualizacja po zmianach. Każda istotna zmiana (nowy dostawca poziomu A, fuzja dostawcy, incydent) wymaga aktualizacji oceny.

Realny budżet audytu łańcucha dostaw

Dla średniej firmy 100-osobowej:

Faza 1 (mapa): 20 000-60 000 zł zewnętrznych usług plus 80-160 godzin czasu wewnętrznego. Czas: 4 tygodnie.

Fazy 2-5 (klasyfikacja, oceny): 30 000-100 000 zł zewnętrznych usług plus 200-500 godzin czasu wewnętrznego. Czas: 8-12 tygodni.

Faza 6 (planowanie exit): 15 000-40 000 zł zewnętrznych usług plus 50-120 godzin. Czas: 4-6 tygodni.

Faza 7 (monitoring): 10 000-25 000 zł rocznie plus 50-80 godzin czasu wewnętrznego.

Łączny pierwszy rok: 75 000-225 000 zł plus czas wewnętrzny.

Utrzymanie roczne: 25 000-60 000 zł plus czas wewnętrzny.

Najczęstsze ustalenia audytów łańcucha dostaw

W 50+ audytach średnich polskich firm powtarzające się wzorce:

Ustalenie 1: klauzule cyberbezpieczeństwa w umowach z dostawcami: 35% firm ma kompletne klauzule, 45% częściowe, 20% praktycznie brak.

Ustalenie 2: mapa subdostawców kluczowych dostawców: 18% firm ma kompletną mapę, 32% częściową, 50% nie ma.

Ustalenie 3: plany exit dla dostawców krytycznych: 22% firm ma udokumentowane plany, 78% nie.

Ustalenie 4: raporty SOC 2 lub ISO 27001 dostawców: 51% firm żąda i przechowuje, 49% nie.

Ustalenie 5: test komunikacji awaryjnej z dostawcą krytycznym: 28% firm testowało w ostatnich 24 miesiącach, 72% nie.

Te statystyki pokazują, że łańcuch dostaw to obszar systematycznie zaniedbywany w polskich firmach, nie z powodu trudności, lecz priorytetyzacji.

Najczęstsze błędy

Błąd 1: pominięcie subdostawców. Mapa zawiera bezpośrednich, ignoruje subdostawców z realnym dostępem. SolarWinds był subdostawcą.

Błąd 2: klasyfikacja przez compliance bez biznesu. Dział compliance klasyfikuje ryzyko, biznes wcześniej widzi prawdziwą krytyczność. Konsultacja z kierownikami operacyjnymi obowiązkowa.

Błąd 3: kwestionariusze nie weryfikowane. Wypełnione przez dostawcę raz, wpisane do segregatora. Bez weryfikacji = marketing.

Błąd 4: brak procesu exit. “Mamy świetnego dostawcę, exit nie jest potrzebny”. Realna sytuacja zmienia się, bankructwo, akwizycja, podwyżki cen, zmiana strategii dostawcy.

Błąd 5: tylko cyber, brak prywatności. Audyt cyber dostawcy bez RODO. Procesor danych musi być oceniany dwukrotnie, pod kątem cyber (NIS2) i prywatności (RODO).

Bibliografia

Komisja Europejska. (2022). Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (NIS2), art. 21 i 22. https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32022L2555
NIST. (2022). SP 800-161 Rev. 1: Cybersecurity Supply Chain Risk Management Practices. https://doi.org/10.6028/NIST.SP.800-161r1
ISO. (2022). ISO/IEC 27036-2:2022, Cybersecurity, Supplier relationships. https://www.iso.org/standard/82072.html
ENISA. (2021). Threat Landscape for Supply Chain Attacks. European Union Agency for Cybersecurity. https://www.enisa.europa.eu/publications/threat-landscape-for-supply-chain-attacks
SolarWinds Corporation. (2021). An Investigative Update of the Cyberattack. SolarWinds. https://orangematter.solarwinds.com/blog/an-investigative-update-of-the-cyberattack
CISA. (2021). Emergency Directive 21-01: Mitigate SolarWinds Orion Code Compromise. CISA. https://www.cisa.gov/news-events/directives/ed-21-01-mitigate-solarwinds-orion-code-compromise

Łańcuch dostaw to obszar, w którym najwięcej firm ma luki. W cotygodniowym newsletterze SkanujFirme.pl publikujemy szablony kwestionariuszy oceny, scenariusze audytów dostawców, analizy konkretnych incydentów supply chain. Zapisz się, bezpłatnie.

Audyt IT open source: 12 narzędzi do samodzielnego audytu w MŚP

Marek Porycki — Tue, 23 Jun 2026 14:31:00 +0000

W rozmowach z dyrektorami compliance średnich firm regularnie pojawia się pytanie typu: “konsultanci chcą 200 tys. zł za audyt cyber, a my mamy 50 tys. budżetu, co możemy zrobić sami?”. Odpowiedź jest pragmatyczna: dużo. Większość obszarów technicznych można sprawdzić samodzielnie używając narzędzi open-source lub niedrogich komercyjnych. Niektóre obszary (kultura, niezależna ocena strategiczna) wymagają zewnętrznej perspektywy, ale nawet tam istnieją narzędzia self-service redukujące koszt do ułamka pełnego audytu.

Ten tekst opisuje dwanaście konkretnych narzędzi pogrupowanych w sześć kategorii. Dla każdego: zastosowanie, dostawca, model licencji, koszt, krzywą uczenia się, ograniczenia.

Kategoria 1: skanowanie podatności

Narzędzie 1: OpenVAS / Greenbone Vulnerability Manager.

OpenVAS to flagowy open-source skaner podatności. Skanuje sieć, identyfikuje znane podatności (CVE), priorytetyzuje na podstawie CVSS score. Aktualizowana baza ~80 000 testów.

Dostawca: Greenbone Networks (GmbH).
Licencja: open-source (GPL) dla społeczności, plus komercyjne wersje z dodatkowymi funkcjami.
Koszt: 0 zł dla wersji społecznościowej. Komercyjne wersje 15 000-80 000 zł rocznie.
Krzywa uczenia: średnia. Wymaga znajomości linii poleceń i sieci.
Zastosowanie: regularne (kwartalne) skanowanie infrastruktury.

Narzędzie 2: Nessus Essentials.

Komercyjny skaner od Tenable, ale wersja Essentials darmowa do 16 adresów IP. Łatwiejszy w użyciu niż OpenVAS, profesjonalnie wsparte testy.

Dostawca: Tenable.
Licencja: Essentials darmowa (do 16 IP), Professional 14 500 zł rocznie, Expert 24 000 zł.
Koszt: 0-24 000 zł zależnie od skali.
Krzywa uczenia: niska.
Zastosowanie: dla firm do 16 serwerów, Essentials wystarcza. Większe, Professional.

Kategoria 2: zarządzanie tożsamością i dostępem

Narzędzie 3: Active Directory Audit (DSACLS, dsquery).

Wbudowane narzędzia Microsoft AD do audytu uprawnień. Skanowanie struktury OU, GPO, członkostwa w grupach, uprawnień do obiektów.

Koszt: 0 zł (część systemu Windows Server).
Krzywa uczenia: średnia (PowerShell, scripting).
Zastosowanie: audyt struktury AD, identyfikacja przeuprawniwionych kont.

Narzędzie 4: BloodHound.

Open-source narzędzie do analizy ścieżek ataków w Active Directory. Wizualizuje, kto może eskalować uprawnienia do kogo.

Dostawca: SpecterOps (open-source) plus BloodHound Enterprise (komercyjny).
Licencja: open-source MIT.
Koszt: 0 zł.
Krzywa uczenia: średnia-wysoka (wymaga zrozumienia AD).
Zastosowanie: pen-testowe podejście do AD, identyfikacja ścieżek ataku.

Kategoria 3: zarządzanie compliance i ryzykiem

Narzędzie 5: OneTrust Privacy.

Platforma GRC zorientowana na RODO. Rejestr czynności przetwarzania, zarządzanie zgodami, DPIA, obsługa praw podmiotów danych.

Dostawca: OneTrust LLC.
Licencja: SaaS, modułowa.
Koszt: 30 000-200 000 zł rocznie zależnie od skali firmy i modułów.
Krzywa uczenia: niska-średnia.
Zastosowanie: dojrzałe firmy z dużą ilością procesów RODO.

Narzędzie 6: VeraDoc / lokalne polskie alternatywy.

Polskie narzędzia do zarządzania RODO często tańsze i lepiej dostosowane do polskiego kontekstu. VeraDoc, eDoc, ProteGo One, ApplicationManager, różne profile.

Koszt: 8 000-40 000 zł rocznie.
Zastosowanie: średnie polskie firmy, gdzie OneTrust jest zbyt drogi.

Kategoria 4: monitoring i SIEM

Narzędzie 7: Wazuh.

Open-source SIEM (Security Information and Event Management). Zbiera logi, detekcja anomalii, dashboardy.

Dostawca: Wazuh Inc.
Licencja: open-source.
Koszt: 0 zł software, plus koszt infrastruktury (serwer 5 000-20 000 zł rocznie) i czasu zespołu.
Krzywa uczenia: wysoka (wymaga eksperta security).
Zastosowanie: średnie firmy bez budżetu na komercyjny SIEM.

Narzędzie 8: Splunk Free.

Komercyjny SIEM, ale wersja Free do 500 MB dziennie. Profesjonalnie wsparta, łatwiejsza w nauce niż Wazuh.

Dostawca: Splunk.
Licencja: Free do 500 MB/dzień, Enterprise od 2 000 USD/GB/rok.
Koszt: 0 zł dla małych firm. Pełna licencja: od 50 000 zł rocznie.
Krzywa uczenia: średnia.

Kategoria 5: backup i ciągłość działania

Narzędzie 9: Veeam Backup & Replication Community Edition.

Komercyjny backup, ale wersja Community do 10 instancji workload za darmo. Profesjonalne odzyskiwanie po awarii.

Dostawca: Veeam.
Licencja: Community Edition darmowa, komercyjne licencje od 5 000 zł.
Koszt: 0-60 000 zł rocznie zależnie od skali.
Krzywa uczenia: niska-średnia.
Zastosowanie: backup serwerów wirtualnych, odzyskiwanie po awarii.

Narzędzie 10: Bareos.

Open-source enterprise-grade backup. Fork Bacula z aktywnym wsparciem.

Dostawca: Bareos GmbH.
Licencja: open-source (AGPL).
Koszt: 0 zł software, plus support komercyjny opcjonalny (15 000-60 000 zł rocznie).
Krzywa uczenia: wysoka.
Zastosowanie: większe firmy z kompetencjami Linux.

Kategoria 6: testowanie phishingu i edukacja

Narzędzie 11: GoPhish.

Open-source platforma do prowadzenia symulowanych kampanii phishingowych w celu szkolenia personelu i pomiaru świadomości.

Dostawca: GoPhish (open-source).
Licencja: MIT.
Koszt: 0 zł.
Krzywa uczenia: średnia.
Zastosowanie: regularne (kwartalne) testy phishingowe wewnątrz firmy.

Narzędzie 12: KnowBe4.

Komercyjna platforma szkolenia z security awareness. Profesjonalne treści, testy phishingowe, dashboardy.

Dostawca: KnowBe4.
Licencja: SaaS.
Koszt: 30-80 zł na użytkownika rocznie. Dla 100-osobowej firmy: 3 000-8 000 zł rocznie.
Krzywa uczenia: niska.
Zastosowanie: firmy szukające gotowego programu szkoleniowego.

Strategia wdrażania narzędzi

Etap 1 (miesiące 1-2): podstawy techniczne. Nessus Essentials lub OpenVAS dla skanowania, Wazuh dla podstawowego SIEM. Koszt: do 5 000 zł.

Etap 2 (miesiące 3-6): compliance i procesy. OneTrust lub polska alternatywa dla RODO, GoPhish dla testów phishingu, BloodHound dla AD. Koszt: 20 000-60 000 zł.

Etap 3 (miesiące 7-12): zarządzanie zaawansowane. Veeam dla backupu, KnowBe4 dla szkoleń, ewentualnie pełna licencja Splunk lub komercyjna OpenVAS. Koszt: 30 000-100 000 zł.

Łącznie pierwszy rok: 50 000-165 000 zł na narzędzia. Plus czas zespołu na wdrożenie (200-500 godzin).

To znacząco mniej niż pełny zewnętrzny audyt (200 000-600 000 zł), a daje firmie ciągłą kontrolę zamiast jednorazowej diagnozy.

Czego narzędzia nie zastąpią

Mimo że narzędzia są potężne, nie zastąpią:

Niezależnej oceny strategicznej. Narzędzie pokaże, że masz 73 podatności kategorii High. Nie powie, czy Twoja strategia bezpieczeństwa jest właściwa.

Oceny kultury bezpieczeństwa. GoPhish pokaże, że 18% personelu klika na phishing. Nie powie, dlaczego, czy to brak szkoleń, presja czasowa, niejasne procedury.

Wiarygodności dla regulatorów. Self-audit nie ma ciężaru zewnętrznego audytora.

Zewnętrznej perspektywy w obszarach niszowych. Niszowe regulacje (DORA, AI Act, sektorowe) wymagają specjalistycznej wiedzy.

Audytu certyfikacyjnego. Certyfikacja (ISO 27001, SOC 2) zawsze wymaga niezależnej jednostki certyfikującej.

Dla tych obszarów, zewnętrzny audytor pozostaje konieczny, ale jego czas można dramatycznie skrócić, jeśli firma już wykonała self-audit narzędziami.

Najczęstsze błędy w wykorzystaniu narzędzi

Błąd 1: kupowanie narzędzi bez kompetencji. OpenVAS bez specjalisty dający wyniki, których nikt nie umie zinterpretować. Lepiej: prosty Nessus Essentials z osobą, która rozumie wyniki.

Błąd 2: brak follow-upu. Skanowanie wykonane, raport z 200 podatnościami otrzymany, leżący w segregatorze. Bez wdrożenia napraw narzędzie jest stratą.

Błąd 3: tylko techniczne narzędzia. Compliance kompletnie ignorowane. Cyber jest mocne, RODO papierowe.

Błąd 4: zbyt wiele narzędzi naraz. Próba wdrożenia 8 narzędzi w 6 miesięcy, żadnego nie wdrożone solidnie. Lepiej: 2-3 narzędzia, dobrze wdrożone.

Błąd 5: ignorowanie integracji. Każde narzędzie w silosie. Lepiej: narzędzia integrowane (np. Wazuh + Greenbone) dla holistycznego widoku.

Bibliografia

OWASP Foundation. (2024). OWASP Vulnerability Scanning Tools. https://owasp.org/www-community/Vulnerability_Scanning_Tools
Greenbone Networks. (2024). OpenVAS Documentation. https://greenbone.github.io/docs/
Tenable. (2024). Nessus User Guide. https://docs.tenable.com/nessus/
Wazuh Inc. (2024). Wazuh, Open Source Security Platform. https://wazuh.com/
SpecterOps. (2024). BloodHound, Six Degrees of Domain Admin. https://github.com/BloodHoundAD/BloodHound
NIST. (2023). SP 800-115: Technical Guide to Information Security Testing and Assessment. https://doi.org/10.6028/NIST.SP.800-115
Verizon. (2024). 2024 Data Breach Investigations Report. Verizon Business. https://www.verizon.com/business/resources/reports/dbir/

Self-audit narzędziami dramatycznie obniża koszt diagnostyki. W cotygodniowym newsletterze SkanujFirme.pl publikujemy konkretne tutoriale i konfiguracje narzędzi audytowych. Zapisz się, bezpłatnie.

Audyt zewnętrzny a wewnętrzny: różnice i kiedy co wybrać

Marek Porycki — Thu, 18 Jun 2026 11:08:00 +0000

Pewien zarząd średniej firmy dostawcy IT B2B zdecydował, że tegoroczny audyt RODO zrobi siłami własnymi. “Mamy IOD, mamy zespół compliance, po co płacić zewnętrznym za 80 tysięcy”. Dwanaście tygodni później audyt został zakończony. Raport, 50 stron. Sześć miesięcy później UODO wszczął kontrolę po skardze byłego pracownika. Kontrola ujawniła 14 luk, których wewnętrzny audyt nie zauważył. Wewnętrzny zespół przyjął utartym wzorem dotychczasowe praktyki za “OK”. Zewnętrzny audytor by je zakwestionował.

To częsty wzorzec. Audyt wewnętrzny jest tańszy, ale ma istotne ograniczenia poznawcze. Audyt zewnętrzny jest droższy, ale daje niezależną perspektywę. Realna decyzja zarządu zależy od kontekstu, zakresu, celów i zasobów. Ten tekst rozkłada decyzję o ścieżce audytowej na siedem pytań, podaje konkretne kryteria wyboru i pokazuje typowe scenariusze dla różnych firm.

Audyt wewnętrzny, charakterystyka

Definicja: audyt prowadzony przez własny zespół firmy (zwykle dział compliance, audytu wewnętrznego, IT lub kombinację).

Zalety:

niższy koszt bezpośredni (głównie czas pracowników);
znajomość kontekstu firmy, kultury, historii;
ciągłość po audycie, zespół, który audytował, wdraża rekomendacje;
elastyczność czasowa;
pełna kontrola nad zakresem i metodologią.

Wady:

ograniczona niezależność (audytor zaangażowany w bieżące operacje);
subiektywność (kwestionowanie istniejących praktyk jest psychologicznie trudne);
ograniczone benchmarki (brak porównania z innymi firmami);
czasem brakuje specjalistycznej kompetencji w niszowych obszarach;
mniejsza wiarygodność dla zewnętrznych interesariuszy (klientów, partnerów, regulatorów).

Typowe firmy: duże korporacje z dedykowanym działem audytu wewnętrznego (banki, energia, telekomunikacja). Średnie firmy z dojrzałym compliance.

Koszt: 5 000-30 000 zł kosztów twardych (narzędzia, szkolenia, ewentualnie konsultacje punktowe) plus 200-500 godzin czasu zespołu. Łączny koszt ekonomiczny (z uwzględnieniem kosztu alternatywnego czasu): 60 000-150 000 zł.

Audyt zewnętrzny, charakterystyka

Definicja: audyt prowadzony przez niezależną firmę audytorską lub konsultingową.

Zalety:

niezależność (kluczowe dla wiarygodności);
benchmark branżowy (audytor widział wiele firm);
specjalistyczna kompetencja (audytorzy wyspecjalizowani w obszarze);
wiarygodność dla regulatorów, klientów, partnerów;
profesjonalna metodologia oparta na frameworkach (ISO, NIST, COBIT);
dystans poznawczy, audytor widzi to, czego wewnętrzny zespół nie widzi.

Wady:

wyższy koszt bezpośredni;
brak głębokiej znajomości firmy (czas na onboarding);
zaangażowanie zasobów wewnętrznych w obsługę audytora;
wynik kończy się raportem, wdrożenie pozostaje wewnątrz;
ryzyko “standardowej” diagnozy bez specyfiki firmy (zwłaszcza u dużych konsultingów).

Typowe firmy: średnie firmy bez dedykowanego compliance. Firmy przygotowujące się do certyfikacji. Firmy po incydencie. Firmy w trakcie due diligence.

Koszt: 50 000-300 000 zł zależnie od zakresu, wielkości firmy i renomy audytora. Plus zaangażowanie wewnętrzne 100-250 godzin.

Audyt hybrydowy, charakterystyka

Definicja: kombinacja zewnętrznego eksperta z zespołem wewnętrznym.

Modele hybrydowe:

Model A, koordynator zewnętrzny + wykonawcy wewnętrzni: zewnętrzny audytor projektuje metodologię, prowadzi kluczowe wywiady i waliduje wnioski. Zespół wewnętrzny wykonuje większość pracy operacyjnej (analiza dokumentów, ankiety, gathering informacji). Koszt: 30 000-80 000 zł zewnętrzny + czas wewnętrzny.

Model B, pełen audyt zewnętrzny + buddy wewnętrzny: zewnętrzny audytor wykonuje całość, ale jest “twinning” z osobą wewnętrzną, która uczy się metodyki dla przyszłych audytów wewnętrznych. Koszt: 70 000-180 000 zł.

Model C, audyt wewnętrzny z zewnętrzną walidacją: zespół wewnętrzny wykonuje audyt, zewnętrzny ekspert waliduje wybrane obszary i wnioski. Koszt: 20 000-60 000 zł zewnętrzny.

Zalety hybrydowego:

kompromis kosztu i jakości;
transfer kompetencji do wewnętrznego zespołu;
elastyczność w głębokości obszarów;
niezależność w kluczowych obszarach.

Wady:

złożoność zarządzania;
ryzyko niespójnej metodologii (jeśli źle skoordynowana);
ryzyko luki odpowiedzialności (kto odpowiada za końcową ocenę).

Typowe firmy: średnie i większe firmy chcące zoptymalizować koszt audytu i jednocześnie budować wewnętrzną kompetencję.

Decyzja w siedmiu pytaniach

Aby wybrać optymalną ścieżkę dla konkretnej firmy, odpowiedz na siedem pytań:

Pytanie 1: czy audyt ma być wykorzystany przez zewnętrznych interesariuszy?

Jeśli wynik audytu zostanie pokazany regulatorom, klientom (w przetargach), partnerom, akcjonariuszom, niezależność ma kluczowe znaczenie. Wybierz audyt zewnętrzny lub silnie hybrydowy.

Jeśli wynik audytu jest dla wewnętrznych decyzji zarządczych, niezależność mniej istotna. Audyt wewnętrzny lub hybrydowy może być wystarczający.

Pytanie 2: jak duża jest firma i jak złożone systemy?

Mała firma (do 50 pracowników): audyt wewnętrzny często wystarczający, jeśli ma kompetentną osobę.

Średnia firma (50-250): hybrydowy zwykle optymalny.

Duża firma (>250): zewnętrzny audyt warto rozważyć dla głównych obszarów, audyt wewnętrzny dla bieżących weryfikacji.

Pytanie 3: czy mamy wystarczające kompetencje wewnętrzne?

Jeśli mamy IOD/DPO, Cybersecurity Officera, dyrektora compliance z faktyczną wiedzą, wewnętrzny audyt wykonalny.

Jeśli te role są fikcyjne lub łączone z bieżącą operacją bez specjalizacji, zewnętrzny audyt konieczny.

Pytanie 4: jaki jest cel audytu?

Diagnoza stanu: każda ścieżka możliwa.

Przygotowanie do certyfikacji: zewnętrzny audyt zalecany (treningowy, przed audytem certyfikacyjnym).

Due diligence (sprzedaż, inwestycja): zewnętrzny audyt obowiązkowy z renomowanej firmy.

Po incydencie: zewnętrzny audyt zalecany (niezależność kluczowa dla obrony przed regulatorami).

Regularna weryfikacja: hybrydowy lub wewnętrzny.

Pytanie 5: jaki budżet jest dostępny?

Do 50 000 zł: wewnętrzny lub minimalna konsultacja zewnętrzna.

50 000-150 000 zł: hybrydowy (model A lub C).

150 000-400 000 zł: hybrydowy (model B) lub pełny zewnętrzny.

400 000 zł: pełny zewnętrzny od renomowanej firmy.

Pytanie 6: jak szybko potrzebujemy wyniku?

Pilne (do 4 tygodni): zewnętrzny szybciej (mają zasoby na natychmiastową reakcję).

Średni horyzont (4-12 tygodni): każda ścieżka.

Długi horyzont (>12 tygodni): wewnętrzny może być optymalny ekonomicznie.

Pytanie 7: czy mamy wcześniejszy raport audytowy?

Pierwszy audyt firmy: zewnętrzny zalecany (ustanowienie standardu, benchmark).

Kolejne audyty: każda ścieżka, ale zewnętrzny co 2-3 lata jako weryfikacja kursu.

Praktyczne scenariusze

Scenariusz 1: średnia firma kurierska, podlega NIS2 jako podmiot ważny, pierwszy raz robi formalny audyt cyber. Rekomendacja: hybrydowy model B (zewnętrzny ekspert prowadzi, wewnętrzny twinning). Koszt: ~120 000 zł. Korzyść: pełen audyt z transferem kompetencji.

Scenariusz 2: duża firma finansowa, dojrzały dział compliance, audyt regularny RODO. Rekomendacja: audyt wewnętrzny, z zewnętrzną walidacją kluczowych obszarów co 24 miesiące. Koszt: 30 000-60 000 zł. Korzyść: optymalizacja kosztów przy zachowaniu jakości.

Scenariusz 3: średnia firma SaaS, przygotowanie do SOC 2 Type II. Rekomendacja: zewnętrzny audyt treningowy przed audytem certyfikacyjnym. Koszt: 80 000-150 000 zł. Korzyść: identyfikacja luk przed formalnym audytem.

Scenariusz 4: średnia firma produkcyjna, po incydencie ransomware, postępowanie sankcyjne w toku. Rekomendacja: zewnętrzny audyt z renomowanej firmy. Koszt: 150 000-300 000 zł. Korzyść: niezależna ocena dla obrony przed regulatorem, podstawa planu naprawczego.

Scenariusz 5: średnia firma z IT outsourcowanym, brak własnej kompetencji compliance. Rekomendacja: pełny zewnętrzny audyt. Koszt: 100 000-200 000 zł. Korzyść: kompensacja braku kompetencji wewnętrznych.

Scenariusz 6: duża firma, due diligence przed sprzedażą. Rekomendacja: pełny zewnętrzny audyt z renomowanej firmy (Big 4 lub specjalizowanej). Koszt: 300 000-800 000 zł. Korzyść: wiarygodność dla nabywcy, wyższa wycena transakcji.

Wybór konkretnego audytora

Przy wyborze zewnętrznego audytora zwróć uwagę na:

Specjalizacja branżowa. Firma audytorska doświadczona w sektorze finansowym może mieć ograniczoną wiedzę o sektorze produkcyjnym. Sprawdzaj referencje konkretnie z Twojej branży.

Kompozycja zespołu. Kto faktycznie będzie wykonywał audyt? Senior partner przy sprzedaży, junior associate przy wykonawstwie? Naciskaj na nazwiska i CV osób w zespole.

Metodologia. Czy mają udokumentowaną metodologię opartą na frameworkach (ISO, NIST, COBIT)? Czy mogą pokazać przykładowe raporty?

Cena vs zakres. Tańszy audyt z węższym zakresem może być droższy w jakości na godzinę. Porównuj nie cenę całkowitą, ale stosunek ceny do zakresu i kompetencji.

Niezależność. Czy audytor sprzedaje też usługi wdrożeniowe (konflikt interesów, może wskazywać luki, żeby je sam wdrożyć)? Niektórzy audytorzy mają polityki separacji.

Reputacja. Sprawdź opinię o audytorze w Twojej branży. Inne firmy z Twojego sektora powiedzą szczerze, czy ich doświadczenie było dobre.

Najczęstsze błędy w wyborze ścieżki

Błąd 1: wybór wyłącznie na podstawie ceny. Najtańszy audyt jest często najdroższy w skutkach (powierzchowna diagnoza, brak wartości).

Błąd 2: zatrudnienie audytora będącego konkurentem dotychczasowego dostawcy. Może wprowadzać strategiczną stronniczość (wskazywać luki, żeby sprzedać własne usługi).

Błąd 3: audyt wewnętrzny bez wsparcia zarządu. Wewnętrzni audytorzy bez backupu zarządu nie kwestionują praktyk, których kierownictwo broni. Audyt staje się fasadowy.

Błąd 4: zbyt wąski zakres dla zewnętrznego audytora. Audyt RODO osobno, NIS2 osobno, procesy osobno, koszt 3x większy niż jednego holistycznego audytu.

Błąd 5: zaniedbanie follow-upu. Niezależnie od ścieżki, bez wdrożenia rekomendacji audyt to strata pieniędzy.

Bibliografia

Institute of Internal Auditors. (2023). International Standards for the Professional Practice of Internal Auditing. IIA. https://www.theiia.org/
ISACA. (2024). IT Audit Framework (ITAF). ISACA. https://www.isaca.org/
NIST. (2024). Cybersecurity Framework 2.0. National Institute of Standards and Technology. https://doi.org/10.6028/NIST.CSWP.29
COSO. (2017). Enterprise Risk Management Framework. Committee of Sponsoring Organizations. https://www.coso.org/
ISO. (2018). ISO 19011:2018, Guidelines for auditing management systems. https://www.iso.org/standard/70017.html
AICPA. (2017). Statement on Auditing Standards. American Institute of CPAs. https://www.aicpa-cima.com/

Decyzja o ścieżce audytowej to inwestycja na lata. W cotygodniowym newsletterze SkanujFirme.pl analizujemy konkretne przypadki audytów polskich firm, co się sprawdziło, co nie. Zapisz się, bezpłatnie.

Diagnoza dojrzałości procesów IT, model 5 poziomów (CMMI)

Marek Porycki — Fri, 12 Jun 2026 08:45:00 +0000

W rozmowach o cyberbezpieczeństwie często dominuje narracja techniczna: “wdrożymy MFA, zaktualizujemy firewall, kupimy SIEM”. To podejście sprzętowe pomija fundamentalne pytanie: jak dojrzała jest organizacja, która te narzędzia obsługuje. Najlepszy SIEM w firmie z chaotycznymi procesami daje gorsze wyniki niż prosty firewall w firmie z dyscyplinowanymi procedurami. Dojrzałość procesów jest mnożnikiem skuteczności wszystkich inwestycji technicznych.

Capability Maturity Model Integration (CMMI), opracowany przez Software Engineering Institute Carnegie Mellon University, dostarcza pięciopoziomowy model oceny dojrzałości procesów. Pierwotnie zaprojektowany dla rozwoju oprogramowania, został zaadaptowany do zarządzania IT, cyberbezpieczeństwa, usług IT i wielu innych obszarów. Ten tekst opisuje pięć poziomów dojrzałości w kontekście procesów IT średniej polskiej firmy, z konkretnymi wskaźnikami, ścieżką rozwoju i kosztami przejścia.

Poziom 1: Chaotyczne (initial)

Charakterystyka: procesy ad hoc, niedokumentowane, oparte na wiedzy konkretnych osób. Sukces (gdy się zdarza) wynika z heroizmu indywidualnym, nie z systemu. Nieprzewidywalność operacyjna.

Wskaźniki w firmie IT:

brak pisanych procedur dla większości operacji;
jeden administrator znający 80% systemów (“jak Kowalski wyjedzie, nie damy rady”);
obsługa incydentów: ad hoc, zależnie od kto akurat odpowie na telefon;
backup: wykonywany czasem, nie zawsze sprawdzany;
aktualizacje: wprowadzane gdy się o nich pamięta;
zarządzanie zmianami: brak formalnego procesu, zmiany wprowadzane bezpośrednio;
monitoring: być może istnieje, ale rzadko obserwowany.

Konsekwencje operacyjne:

częstotliwość incydentów: wysoka (5-15 średnich rocznie w 100-osobowej firmie);
czas reakcji: nieprzewidywalny (od 30 minut do 8 godzin);
czas odzyskiwania: długie (dni, nie godziny);
koszty IT: trudne do prognozowania, częste niespodziewane wydatki;
ryzyko regulacyjne: krytyczne (NIS2 wymaga poziomu zarządzania, nie chaosu).

Typowe firmy: małe firmy bez dedykowanego CIO, mikrofirmy, niektóre średnie firmy bez kultury IT (np. tradycyjne firmy produkcyjne, gdzie IT było dotąd marginalne).

Poziom 2: Repetytywne (managed)

Charakterystyka: niektóre procesy ustabilizowane przez praktykę, ale często bez formalnej dokumentacji. Występuje pewna powtarzalność dla typowych zadań. Niespodziewane sytuacje wciąż wywołują chaos.

Wskaźniki:

istnieją procedury dla najczęstszych operacji (np. tworzenie kont, backup);
niektóre obszary dobrze obsłużone (np. monitorowanie krytycznych systemów), inne pozostają chaotyczne (np. zarządzanie zmianami);
helpdesk z systemem ticketów (przynajmniej podstawowym);
backup wykonywany regularnie, ale rzadko testowany;
aktualizacje zarządzane reaktywnie (po krytycznych podatnościach);
pierwsze metryki, ale nie systematycznie analizowane.

Konsekwencje:

częstotliwość incydentów: średnia (3-8 rocznie);
czas reakcji: niezawodny dla typowych incydentów, wciąż nieprzewidywalny dla nowych;
czas odzyskiwania: zwykle godziny, czasem dni;
koszty IT: bardziej przewidywalne, ale wciąż częste niespodzianki;
ryzyko regulacyjne: poważne (większość obszarów NIS2 niepokryta).

Typowe firmy: średnie polskie firmy z funkcjonującym, ale niedojrzałym działem IT. To najczęściej spotykany poziom w Polsce.

Poziom 3: Zdefiniowane (defined)

Charakterystyka: procesy formalnie udokumentowane, standardowe dla całej organizacji. Polityki kompletne i wzajemnie spójne. Procedury jasno wyznaczone z odpowiedzialnościami.

Wskaźniki:

pełna dokumentacja procesów IT (zwykle 50-100 stron);
nowy pracownik IT może z dokumentacji zrozumieć, jak procesy działają;
audyty wewnętrzne raz w roku;
regularne testowanie kopii zapasowych (kwartalnie lub miesięcznie);
formalny patch management z czasem reakcji na podatności;
zarządzanie zmianami z procesem zatwierdzania;
monitoring z definicją wskaźników (uptime, czas reakcji, MTTR);
procedury na typowe scenariusze incydentów.

Konsekwencje:

częstotliwość incydentów: niższa (1-4 rocznie);
czas reakcji: przewidywalny dla większości scenariuszy;
czas odzyskiwania: zwykle godziny;
koszty IT: przewidywalne;
ryzyko regulacyjne: kontrolowane (większość obszarów NIS2 pokryta).

Typowe firmy: dojrzałe średnie firmy z dedykowanym CIO, większe firmy tech, większość banków i instytucji finansowych.

Poziom 4: Zarządzane (quantitatively managed)

Charakterystyka: procesy mierzone, kontrolowane, zarządzane danymi. Decyzje oparte na metrykach, nie intuicji. Statystyczna kontrola jakości procesów.

Wskaźniki:

dashboard z kluczowymi wskaźnikami operacyjnymi (real-time);
regularna analiza trendów wskaźników;
prewencyjne identyfikowanie problemów (zanim staną się incydentami);
audyty kwartalne lub miesięczne;
cele wydajnościowe procesów (np. “MTTR poniżej 30 minut dla incydentów P1”);
prognozowanie pojemności i obciążenia;
automatyczne alerty oparte na anomaliach;
analiza root cause każdego istotnego incydentu.

Konsekwencje:

częstotliwość incydentów: niska (zwykle <2 rocznie);
czas reakcji: bardzo szybki (minuty);
czas odzyskiwania: zwykle minuty do godzin;
koszty IT: optymalizowane na podstawie danych;
ryzyko regulacyjne: niskie.

Typowe firmy: wielkie korporacje, banki systemowe, technologiczne giganty. W Polsce, kilkadziesiąt podmiotów.

Poziom 5: Zoptymalizowane (optimizing)

Charakterystyka: procesy ciągle doskonalone na podstawie analizy danych i feedbacku. Innowacje są częścią modelu operacyjnego. Kultura ciągłej poprawy.

Wskaźniki:

regularne eksperymenty z nowymi podejściami (A/B testing procesów);
wewnętrzne R&D w obszarze procesów IT;
automatyczna optymalizacja na podstawie machine learning;
proaktywne adaptacje do nowych zagrożeń;
kultura uczenia się, każdy incydent jako okazja;
uczestnictwo w branżowych forum dzielenia się wiedzą;
wewnętrzne publikacje (white papers, prezentacje konferencyjne).

Konsekwencje:

częstotliwość incydentów: bardzo niska;
innowacyjność: realne źródło przewagi konkurencyjnej;
ryzyko regulacyjne: poniżej średniej branżowej.

Typowe firmy: światowi liderzy technologiczni (Google, Microsoft, Amazon), rzadko spotykane poza tym. W Polsce, pojedyncze firmy w wybranych obszarach.

Diagnoza poziomu, pytania kontrolne

Aby ocenić aktualny poziom firmy, odpowiedz uczciwie na 12 pytań:

Czy mamy pisaną dokumentację 80%+ kluczowych procesów IT?
Czy nowy pracownik IT może wdrożyć się z dokumentacji?
Czy testujemy odtwarzanie kopii zapasowych przynajmniej kwartalnie?
Czy mamy formalny patch management z określonymi terminami?
Czy mamy formalne zarządzanie zmianami w infrastrukturze?
Czy mamy SLA dla incydentów (czas reakcji per priorytet)?
Czy obserwujemy metryki operacyjne na bieżąco?
Czy analizujemy root cause każdego istotnego incydentu?
Czy prognozujemy pojemność i obciążenie systemów?
Czy mamy proaktywne wykrywanie anomalii?
Czy regularnie eksperymentujemy z nowymi podejściami?
Czy mamy kulturę dzielenia się wiedzą i learnignu?

Punktacja:

0-2 TAK: poziom 1 (chaotyczne).
3-5 TAK: poziom 2 (repetytywne).
6-8 TAK: poziom 3 (zdefiniowane).
9-10 TAK: poziom 4 (zarządzane).
11-12 TAK: poziom 5 (zoptymalizowane).

Koszt przejścia między poziomami

Przejście 1 → 2: wymagane uporządkowanie podstaw. Koszt: 50 000-150 000 zł (głównie czas wewnętrzny, podstawowe narzędzia helpdeskowe). Czas: 6-12 miesięcy.

Przejście 2 → 3: największy skok. Wymaga formalizacji wszystkich procesów, dokumentacji, audytów wewnętrznych. Koszt: 150 000-400 000 zł (konsultanci, narzędzia ITSM, czas wewnętrzny). Czas: 12-18 miesięcy.

Przejście 3 → 4: wymaga inwestycji w narzędzia analityczne i kultury data-driven. Koszt: 200 000-600 000 zł (narzędzia BI, dashboardy, eksperci data analytics). Czas: 12-24 miesiące.

Przejście 4 → 5: najtrudniejsze. Wymaga zmiany kultury organizacyjnej. Koszt: trudny do wycenienia, bo to inwestycja długoterminowa w R&D. Czas: nieskończony, to ciągły proces.

Realistyczna rekomendacja dla większości polskich średnich firm: dążenie do poziomu 3 jako celu w 2-3 lata. Poziom 4, dla firm z dojrzałym IT i strategicznym znaczeniem technologii. Poziom 5, dla wybranych obszarów, nie całej organizacji.

Mapowanie do wymagań regulacyjnych

Dojrzałość procesów ma bezpośredni wpływ na zgodność regulacyjną:

RODO art. 32 (“odpowiednie środki techniczne i organizacyjne”): poziom 2 jako absolutne minimum, poziom 3 jako bezpieczne. Poziom 1 = systemowe naruszenie.

NIS2 art. 21 (10 obszarów): poziom 3 jako minimum dla podmiotów ważnych, poziom 4 zalecany dla podmiotów kluczowych. Poziom 1-2 = praktycznie niemożliwe spełnienie wszystkich obszarów.

ISO 27001: wymaga elementów odpowiadających poziomom 2-3 systemu zarządzania bezpieczeństwem informacji.

DORA (sektor finansowy): wymaga poziomu 3-4 z dodatkowym naciskiem na testowanie odporności.

Kontrola NIS2 firmy na poziomie dojrzałości 1 = praktycznie pewna kara administracyjna. Firma na poziomie 3, komfortowa pozycja w razie kontroli.

Najczęstsze błędy diagnozy

Błąd 1: samoocena zbyt wysoka. Firmy chętnie określają się jako “poziom 3” mając cechy 2. Audyt zewnętrzny zwykle obniża samoocenę o 0,5-1 poziomu.

Błąd 2: brak konsekwencji. Niektóre obszary na poziomie 4, inne na 1. Błąd: branie wyższego do prezentacji. Realnie firma jest na najniższym poziomie krytycznych obszarów.

Błąd 3: traktowanie jako etykietki. “Jesteśmy poziom 3” jako koniec dyskusji. Lepiej: jako początek pytania “co konkretnie poprawić, żeby przejść do 4 w obszarach X i Y”.

Błąd 4: zaniedbanie przejść. Firma “skacze” z 1 do 3 bez pełnego przejścia 2. Konsekwencja: pozory poziomu 3 (procedury istnieją), brak fundamentów (procedury nie są przestrzegane).

Błąd 5: ignorowanie kultury. Procesy mogą być na poziomie 3, ale bez kultury wsparcia są fasadowe. Pełna ocena uwzględnia kulturę.

Bibliografia

Software Engineering Institute. (2010). CMMI for Services, Version 1.3. Carnegie Mellon University. https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=9665
ITIL 4 Foundation. (2019). ITIL Foundation: ITIL 4 Edition. AXELOS. ISBN: 978-0113316076.
NIST. (2024). Cybersecurity Framework 2.0. National Institute of Standards and Technology. https://doi.org/10.6028/NIST.CSWP.29
ISO. (2022). ISO/IEC 27001:2022, Information security management systems. https://www.iso.org/standard/27001
Komisja Europejska. (2022). Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (NIS2). https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32022L2555
DevOps Research and Assessment (DORA). (2023). State of DevOps Report 2023. Google Cloud. https://cloud.google.com/devops/state-of-devops

Diagnoza dojrzałości jest punktem wyjścia, nie końcem. W cotygodniowym newsletterze SkanujFirme.pl publikujemy ścieżki rozwoju z poziomu N do N+1 z konkretnymi działaniami i metrykami. Zapisz się, bezpłatnie.