WOJCIECH CHOJNACKI / CISM · EMBA
Ekspert cyberbezpieczeństwa, odporności cyfrowej oraz GRC: Governance, Risk & Compliance, czyli zarządzania, ryzyka i zgodności. Doświadczenie wyniesione z przemysłu, bankowości i energetyki, połączone z ciekawością kosmologii, astrofizyki i fizyki kwantowej.
00 / Spis treści
Strona łączy perspektywę osobistą, doświadczenie zawodowe i konkretne możliwości współpracy. Poniżej możesz przejść bezpośrednio do wybranego obszaru.
01 / Poznaj mnie
Poznaj mnie od strony, której nie da się opisać samym stanowiskiem. Cenię spokój, otwartość i partnerstwo. Kulturę bezpieczeństwa buduję przez jasne zasady, rozmowę i wzajemne zaufanie, rozumiejąc, że strach to menedżerskie załamanie funkcji falowej, które redukuje potencjał zespołu do minimum.
Doświadczenie, role i zakres praktyki opisuję osobno w sekcji „Background zawodowy”. Tutaj ważniejszy jest sposób myślenia: wpływ decyzji na ludzi, procesy, ciągłość działania i relacje w organizacji.
Perspektywa osobista
Doświadczenie zawodowe jest ważne, ale nie wyjaśnia wszystkiego. Po pracy wracam do pytań o kosmos, czas, informację i granice poznania. To one uczą mnie patrzeć szerzej, nie przywiązywać się do pierwszej odpowiedzi i szukać rozwiązań, które mają sens w większym systemie.
Otwartość. Problemy ujawnione odpowiednio wcześnie można rozwiązać, zanim staną się kryzysem.
Partnerstwo. Bezpieczeństwo jest wspólną pracą biznesu, technologii i ludzi.
Pomoc. Wiedza ma największą wartość wtedy, gdy ułatwia innym podjęcie dobrej decyzji.
02 / Background zawodowy
To część zawodowa: role, sektory i zakres praktyki w Orlen, Banku Pocztowym oraz Enei. Najcenniejsze doświadczenie powstaje na styku strategii, regulacji i sytuacji, w których trzeba podjąć decyzję bez pełnej informacji.
Orlen
Doświadczenie wyniesione ze środowiska Orlen, organizacji przemysłowej i infrastrukturalnej, w której bezpieczeństwo musi wspierać ciągłość procesów, ludzi i zasobów.
Bank Pocztowy S.A.
Dyrektor Bezpieczeństwa Systemów Teleinformatycznych i Ochrony Zasobów. Zakres pracy obejmował ochronę około 230 placówek, bezpieczeństwo ICT, wymagania KNF, SOC 24/7 oraz rozwój systemu zarządzania bezpieczeństwem informacji i ciągłością działania. Udział w zespołach roboczych Komisji Nadzoru Finansowego i Związku Banków Polskich. Obszary: DORA, NIS2, AI.
Enea / Enea Centrum
Praca w obszarze bezpieczeństwa systemów ICT dla organizacji o znaczeniu infrastrukturalnym: ryzyko ICT, dostawcy, DLP, monitoring, bezpieczeństwo IT/OT oraz wymagania UKSC, NIS2 i DORA.
Największe systemy uczą pokory. Wszechświat uczy skali. Cyberbezpieczeństwo uczy uważności.
03 / Wykształcenie i certyfikaty
Wykształcenie menedżerskie i certyfikacja bezpieczeństwa tworzą podstawę pracy, w której trzeba rozumieć zarówno decyzję zarządczą, jak i jej techniczne konsekwencje.
Dominican University Chicago
Uniwersytet Mikołaja Kopernika w Toruniu
Zarządzanie finansami
Certified Information Security Manager
ISACA
ISACA · open badge ↗
ISACA Gold Level Member
Członkostwo od 2017 r.
Praktyka obejmuje m.in. KNF, ISO 27001/27005/22301, DORA, UKSC/NIS2, NIST CSF, bezpieczeństwo Microsoft/Azure/M365, SOC, SIEM, DLP, WAF oraz ciągłość działania.
04 / Kompetencje
Łączę perspektywę zarządczą, regulacyjną i techniczną, aby rekomendacje były możliwe do wdrożenia i obrony podczas audytu.
GRC: Governance, Risk & Compliance, czyli zarządzanie, ryzyko i zgodność. Obejmuje strategię, SZBI, zarządzanie ryzykiem i raportowanie dla kierownictwa.
Obraz najważniejszych ryzyk, priorytety i decyzje inwestycyjne.
Model działania bezpieczeństwa, priorytety kontroli i mierniki skuteczności.
Katalog kontroli, rejestr ryzyka, mapowanie wymagań i dowody zgodności.
DORA, NIS2, UKSC, BCM, reagowanie na incydenty i testowanie odporności organizacji.
Ocena gotowości organizacji na zakłócenie i wpływu ryzyka na działalność.
BCM, DRP, obsługa incydentów, testy, RTO/RPO i plan doskonalenia.
Scenariusze, protokoły testów, działania korygujące i ścieżka raportowania.
Ocena ex ante, ryzyko koncentracji, klauzule, monitoring, exit plan i dowody zgodności.
Informacja, od których dostawców zależy organizacja i jakie decyzje są konieczne.
TPRM, klasyfikacja usług, monitoring ryzyka, podwykonawcy i exit plan.
Due diligence, ocena ryzyka, katalog dowodów, plan działań i klauzule.
Zależności IT/OT, infrastruktura krytyczna, segmentacja, monitoring i bezpieczeństwo usług.
Przełożenie zależności technicznych na ciągłość usług i skutki biznesowe.
Architektura, segmentacja, dostęp zdalny, monitoring i priorytety zabezpieczeń.
Rejestry aktywów i usług, ocena ryzyka, wymagania UKSC/NIS2 i dowody kontroli.
Ryzyko modeli, dane wejściowe i wyjściowe, bezpieczeństwo użycia AI oraz nadzór człowieka.
Granice akceptowalnego ryzyka AI i zasady odpowiedzialnego wykorzystania technologii.
Zatwierdzone narzędzia, tenant, tożsamość, DLP, monitoring i reagowanie na zdarzenia.
Klasyfikacja zastosowań, ocena dostawcy, rejestr modeli, dowody i przeglądy.
Rzeczowe analizy i rekomendacje możliwe do wdrożenia i obrony podczas audytu.
Krótka nota decyzyjna: problem, warianty, ryzyko, koszt i rekomendowany kierunek.
Niezależny przegląd założeń, luk, architektury lub planu działań.
Materiał audytowy: stan faktyczny, kryteria, ocena, priorytet, właściciel i dowód.
05 / Zainteresowania
To nie jest dekoracja strony. To druga część mojego sposobu myślenia: ciekawość, skala, porządek i pokora wobec tego, czego jeszcze nie rozumiemy.
01 / KOSMOLOGIA
Początek, struktura i przyszłość Wszechświata przypominają, że każdy system ma swój kontekst, granice i historię.
02 / ASTROFIZYKA
Gwiazdy, czarne dziury i fale grawitacyjne uczą cierpliwości wobec danych oraz szacunku dla tego, czego jeszcze nie widać.
03 / FIZYKA KWANTOWA
Fascynacja fizyką kwantową prowadzi do pytań o informację, pomiar i granice poznania, także w systemach tworzonych przez ludzi.
Im dalej patrzymy, tym wyraźniej widzimy, że każdy system ma swoją architekturę, granice i punkty krytyczne.
06 / Sposób pracy
Dobre doradztwo nie polega na mnożeniu dokumentów. Polega na rozpoznaniu rzeczywistego ryzyka i wskazaniu działań, które organizacja może wykonać.
Nie zastępuję zarządu, CISO ani właścicieli procesów. Pomagam uporządkować problem, pokazać warianty i przygotować wykonalny plan. Decyzje pozostają po stronie organizacji.
Co naprawdę wymaga decyzji i jaki jest kontekst biznesowy?
Oddzielamy fakty, założenia, ryzyka i wymagania.
Kończymy priorytetem, właścicielem działania i dowodem wykonania.
07 / Biblioteka wiedzy
Materiały przygotowujemy etapami: najpierw opracowanie, potem weryfikacja treści i bezpieczeństwa, a dopiero na końcu publikacja. Materiały firmowe i poufne nie są częścią tego projektu.
Treść, przykład i forma materiału.
Rzetelność, aktualność i brak danych poufnych.
Artykuł, a w razie potrzeby także materiał do pobrania.
Materiały autorskie są chronione. Wykorzystanie komercyjne wymaga uprzedniej zgody Wojciecha Chojnackiego: zobacz zasady korzystania.
Od klasyfikacji usługi i dowodów bezpieczeństwa do decyzji, klauzul, monitoringu i exit planu.
Czytaj materiałJak ograniczyć wyciek danych, zachować widoczność użycia i udostępnić pracownikom bezpieczną drogę do AI.
Czytaj materiałCzym różni się dokument, który istnieje, od kontroli, która rzeczywiście działa i daje się udowodnić.
Czytaj materiałJak zapisać w umowie wymagania, które pozwalają podmiotowi kluczowemu zarządzać ryzykiem operacyjnym ICT, incydentami, bezpieczeństwem informacji i ciągłością działania, a także jak te wymagania różnią się w reżimach DORA i UKSC.
Czytaj opracowanieJak oceniać ryzyko dostawcy ICT w praktyce
Ocena dostawcy ICT nie powinna być konkursem na najdłuższą listę pytań. Jej celem jest odpowiedź na prostsze i ważniejsze pytanie: co stanie się z organizacją, jeżeli usługa przestanie działać, zostanie zaatakowana albo nie będzie można jej szybko zastąpić?
Podmiot prawny jest dopiero początkiem analizy. Trzeba ustalić, jaki proces biznesowy wspiera usługa, jakie dane przetwarza, kto ma do niej dostęp, jakie są wymagania dostępności oraz jakie skutki powstaną po godzinie, dniu lub tygodniu przerwy.
W praktyce warto rozróżnić usługi wspierające, ważne i krytyczne. Nie po to, aby tworzyć kolejną etykietę, lecz aby dopasować głębokość oceny, wymagania umowne, monitoring i sposób testowania ciągłości.
Certyfikat lub wypełniony kwestionariusz są materiałem wejściowym, a nie końcowym dowodem bezpieczeństwa. W zależności od usługi należy oczekiwać m.in. opisu architektury, wyników niezależnych ocen, informacji o incydentach, testach ciągłości i odtworzenia, podwykonawcach, poziomach usług oraz sposobie obsługi zmian.
Uzależnienie od dostawcy powstaje nie tylko wtedy, gdy umowa jest trudna do rozwiązania. Pojawia się także wtedy, gdy migracja danych i zasobów jest bardzo trudna, nie ma przetestowanego exit planu, brakuje alternatywnej architektury, a organizacja nie wie, ile czasu i zasobów wymagałaby zmiana.
Minimalny zestaw działań obejmuje identyfikację koncentracji, opis scenariusza wyjścia, wymagania dotyczące migracji danych i zasobów, właściciela planu oraz ćwiczenie tabletop. Plan, którego nigdy nie przećwiczono, pozostaje założeniem.
Dobra ocena kończy się nie tylko ratingiem. Powinna wskazać ryzyko rezydualne, warunki akceptacji, wymagane klauzule, działania mitygujące, właściciela, termin i dowód wykonania. Dopiero wtedy analiza dostawcy staje się elementem zarządzania, a nie dokumentem odłożonym do archiwum.
Ramy odniesienia: ryzyko ICT, TPRM, DORA, NIS2, UKSC i ISO 27001. Materiał ma charakter ekspercki i informacyjny.
Shadow AI: ryzyko i zasady bezpiecznego użycia AI
Shadow AI oznacza korzystanie z narzędzi, kont, wtyczek, API lub funkcji generatywnej AI bez uzgodnienia z organizacją. Ryzyko nie wynika wyłącznie z nazwy modelu. Wynika z braku widoczności: nie wiadomo, jakie dane wysłano, gdzie trafiły, kto ma do nich dostęp i jak długo będą przechowywane.
Nie należy wprowadzać do publicznego narzędzia informacji poufnych, danych osobowych osób trzecich, danych klientów, haseł, kluczy API, kodu źródłowego ani materiałów objętych tajemnicą przedsiębiorstwa. Każdą odpowiedź trzeba traktować jako propozycję do sprawdzenia, a nie jako samodzielną decyzję.
Bezpieczna praktyka to używanie zatwierdzonego konta i tenantu, korzystanie z dozwolonych funkcji, usuwanie zbędnych danych z promptu oraz zgłaszanie pomyłkowego przesłania informacji do właściwego zespołu bezpieczeństwa.
Skuteczny model łączy politykę z technologią. Organizacja powinna wiedzieć, jakie narzędzia są zatwierdzone, kontrolować tożsamość i tenant, zapewnić widoczność użycia przez proxy lub CASB oraz objąć ochroną DLP kanały, przez które dane mogą opuścić środowisko.
Całkowity zakaz może ograniczyć widoczność, ale nie musi ograniczyć potrzeby korzystania z AI. Rozsądniejszy model polega na blokowaniu nieautoryzowanych ścieżek przy jednoczesnym udostępnieniu bezpiecznego rozwiązania organizacyjnego, na przykład zatwierdzonego narzędzia w firmowym tenancie, z określonymi zasadami danych i odpowiedzialności.
Nie należy ukrywać zdarzenia ani samodzielnie usuwać śladów. Trzeba zachować podstawowe informacje: konto, narzędzie, czas, rodzaj danych i zakres przesłania, a następnie uruchomić właściwą ścieżkę zgłoszenia. Pozwala to ocenić, czy zdarzenie jest incydentem, naruszeniem zasad lub sygnałem do zmiany kontroli.
Ramy odniesienia: AI Governance, AI Security, DLP, CASB, SOC/SIEM, zasady ochrony informacji i wymagania organizacyjne. Materiał ma charakter ekspercki i informacyjny.
Cyberbezpieczeństwo bez dekoracji
Organizacja może posiadać polityki, procedury, rejestry ryzyka i certyfikaty, a mimo to pozostawać słabo chroniona. Różnica między dokumentem a bezpieczeństwem zaczyna się tam, gdzie pojawia się pytanie: co dokładnie działa, dla kogo, w jakim zakresie, z jakim wynikiem i jak można to udowodnić?
Polityka bezpieczeństwa została zatwierdzona.
Właściciel kontroli, zakres, termin przeglądu i dowód stosowania są znane.
DLP działa w trybie monitoringu.
Reguły obejmują właściwe kanały, a organizacja potrafi przejść od obserwacji do blokowania.
MFA jest wdrożone.
Wiadomo, jaki jest rzeczywisty zakres pokrycia, wyjątki i sytuacja kont uprzywilejowanych.
SOC zbiera logi.
Logi mają właściciela, retencję, scenariusze detekcji i ścieżkę reakcji na zdarzenie.
Dostawca podpisał umowę.
Ryzyko koncentracji, exit plan, możliwość migracji danych i zasobów oraz test ciągłości są rozpoznane.
Ryzyko jest wpisane do rejestru.
Ma ocenę, właściciela, termin, działanie mitygujące i dowód zamknięcia.
Jeżeli za działanie odpowiada „wszyscy”, w praktyce często nie odpowiada nikt. Każda istotna kontrola powinna mieć właściciela, zakres, częstotliwość, kryterium skuteczności, ścieżkę eskalacji i dowód wykonania.
Reguła DLP w trybie monitoringu może dostarczyć wiedzy, ale nie zatrzyma wysyłki. Log zebrany w SIEM nie jest jeszcze detekcją, a alert bez właściciela i procedury nie jest reakcją. Warto świadomie określić, które kontrole mają obserwować, które ostrzegać, a które blokować.
Rejestr ryzyka jest użyteczny wtedy, gdy łączy ocenę z decyzją: co robimy, kto jest właścicielem, do kiedy, jak zmniejszymy ryzyko i jaki dowód zamknięcia przedstawimy. Samo przeniesienie ryzyka do tabeli nie zmienia poziomu zagrożenia.
„Proszę pokazać, że to działa” powinno prowadzić do konkretnego dowodu: konfiguracji, raportu, biletu, logu, wyniku testu, protokołu decyzji albo zapisu reakcji. Jeżeli dowodu nie ma, trzeba uczciwie określić, czy kontrola nie działa, czy tylko nie została właściwie udokumentowana.
Ramy odniesienia: GRC, DLP, SOC/SIEM, IAM, MFA, PKI, zarządzanie ryzykiem i ciągłość działania. Materiał ma charakter ekspercki i informacyjny.
Zarządzanie łańcuchem dostaw w ujęciu klauzul umownych
Podmiot kluczowy nie może skutecznie zarządzać usługą, jeżeli umowa z dostawcą ogranicza się do ogólnego obowiązku „zapewnienia bezpieczeństwa”. Potrzebne są postanowienia, które przekładają wymagania UKSC na konkretne uprawnienia, obowiązki, dowody, terminy, mechanizmy eskalacji i możliwość zakończenia współpracy bez utraty kontroli nad usługą.
Każdy panel opisuje jeden atrybut bezpieczeństwa. Zawiera cel klauzul, minimalny katalog postanowień oraz kierunkowe brzmienie, które może być podstawą do przygotowania właściwej klauzuli dla konkretnej usługi. Nie jest to gotowy wzór umowy ani porada prawna. Zakres należy dopasować do klasy usługi, architektury, modelu dostawy i wyników analizy ryzyka.
Umowa powinna pozwalać zarządzać ryzykiem przez cały cykl życia usługi, a nie tylko w dniu podpisania kontraktu.
Dostawca utrzymuje udokumentowany model zarządzania ryzykiem związanym z usługą, przekazuje podmiotowi kluczowemu informacje niezbędne do niezależnej oceny oraz nie wprowadza istotnej zmiany mogącej zwiększyć ryzyko bez uprzedniego poinformowania i uzgodnienia sposobu postępowania.
Dostawca musi być częścią procesu reagowania podmiotu kluczowego, a nie odrębnym źródłem informacji po fakcie.
Dostawca niezwłocznie informuje podmiot kluczowy o incydencie lub podejrzeniu incydentu mogącym wpłynąć na usługę, zapewnia współpracę zespołów, dostęp do niezbędnych informacji i dowodów oraz realizuje uzgodnione działania ograniczające i naprawcze aż do formalnego zakończenia obsługi.
Wymagania muszą obejmować nie tylko system, ale również ludzi, dostęp, dane, podwykonawców i sposób wykonywania zmian.
Dostawca stosuje środki techniczne i organizacyjne odpowiadające ryzyku usługi, zapewnia kontrolę dostępu i ochronę informacji, dokumentuje realizację wymagań oraz udostępnia podmiotowi kluczowemu informacje i dowody niezbędne do monitorowania bezpieczeństwa i zgodności.
Ciągłość musi być mierzalna, przetestowana i powiązana z rzeczywistym poziomem świadczenia usługi kluczowej.
Dostawca utrzymuje i testuje rozwiązania zapewniające ciągłość oraz odtworzenie usługi zgodnie z uzgodnionymi parametrami, przekazuje wyniki testów i niezwłocznie usuwa stwierdzone niezgodności. Po zakończeniu umowy zapewnia uporządkowane przejście do innego dostawcy albo rozwiązania wewnętrznego.
Punkt 5 · porównanie reżimów
To nie są dwa zamienne zestawy skrótów. DORA jest unijnym, sektorowym reżimem odporności cyfrowej dla podmiotów finansowych, natomiast UKSC jest krajowym, przekrojowym reżimem cyberbezpieczeństwa wynikającym z ustawy o krajowym systemie cyberbezpieczeństwa. W praktyce umowa z dostawcą powinna pokazywać, które obowiązki wynikają z prawa, które są wymaganiem organizacji, a które są kontrolą kontraktową pozwalającą ten obowiązek wykonać i udowodnić.
| Atrybut | DORA | UKSC | Wniosek dla klauzuli |
|---|---|---|---|
| 01 Ryzyko operacyjne ICT | Sektorowy i bardziej preskryptywny model zarządzania ryzykiem ICT. Obejmuje także zależności od zewnętrznych dostawców ICT, funkcje krytyczne lub ważne, ryzyko koncentracji, rejestr ustaleń, audyt oraz plan wyjścia. | Przekrojowe zarządzanie ryzykiem cyberbezpieczeństwa systemów i usług objętych UKSC. Bezpieczeństwo łańcucha dostaw jest jednym z wymaganych kierunków działań, a środki powinny być adekwatne do ryzyka i wpływu na usługę. | Wymagać informacji do oceny ryzyka, zgody na istotne zmiany, przejrzystości podwykonawców, kontroli koncentracji, mierników, prawa audytu i realnej ścieżki wyjścia. |
| 02 Zarządzanie incydentami | Formalny reżim obsługi i raportowania poważnych incydentów związanych z ICT w sektorze finansowym, z klasyfikacją, współpracą z organem właściwym i wymaganiem dowodów reakcji. | Obowiązek obsługi incydentów oraz realizacji ustawowych obowiązków zgłoszeniowych wobec właściwych CSIRT lub organu sektorowego. Dostawca ma dostarczyć dane, wsparcie i dowody potrzebne podmiotowi objętemu UKSC. | Zdefiniować zdarzenie i podejrzenie zdarzenia, kanał oraz czas pierwszego zgłoszenia, zakres aktualizacji, zachowanie logów, wsparcie analizy przyczyn i zakaz utrudniania skoordynowanej reakcji. |
| 03 Bezpieczeństwo informacji | Kontrole wynikają z ram zarządzania ryzykiem ICT podmiotu finansowego i są ściśle powiązane z odpornością cyfrową oraz nadzorem nad dostawcą ICT. Umowa ma wspierać dostęp, ochronę danych, logowanie, audyt i zarządzanie zmianą. | Środki bezpieczeństwa obejmują m.in. analizę ryzyka, polityki bezpieczeństwa informacji, obsługę incydentów, ciągłość działania i łańcuch dostaw. Nacisk pada na zdolność podmiotu do ochrony usługi kluczowej lub innej usługi objętej ustawą. | Ustalić minimalny poziom kontroli: IAM/MFA, uprzywilejowany dostęp, szyfrowanie, podatności i poprawki, konfigurację, monitoring, personel, podwykonawców oraz katalog dowodów bez ujawniania tajemnicy przedsiębiorstwa. |
| 04 Ciągłość działania | Odporność cyfrowa łączy prewencję, reakcję, odtworzenie, testowanie i uporządkowane wyjście. Dla dostawców ICT o znaczeniu krytycznym istnieje dodatkowy unijny wymiar nadzorczy. | Wymagane są rozwiązania ciągłości działania, kopie zapasowe, odtwarzanie po awarii i zarządzanie kryzysowe, tak aby utrzymać świadczenie usługi. Dostawca jest elementem łańcucha, ale odpowiedzialność regulacyjna pozostaje po stronie podmiotu objętego UKSC. | Wpisać RTO/RPO, dostępność, scenariusze awarii i utraty dostawcy, testy z dowodami, zależności IT/OT, wsparcie przy migracji danych i zasobów oraz okres przejściowy. |
Porównanie ma charakter syntetyczny i publiczny. Ostateczny zakres obowiązków zależy od statusu podmiotu, rodzaju usługi, jej krytyczności oraz aktualnego brzmienia przepisów i wymaga weryfikacji prawnej przed użyciem w umowie.
Materiał syntetyczny, bez danych rzeczywistych i informacji poufnych. Ramy odniesienia: UKSC, NIS2, DORA, ISO 27001/27005/22301 oraz praktyka zarządzania dostawcami ICT/OT. Przed wykorzystaniem w umowie wymagane jest dostosowanie do konkretnej usługi i weryfikacja prawna.
08 / Współpraca ekspercka
Przyjmuję ograniczoną liczbę indywidualnych zleceń B2B z obszaru cyberbezpieczeństwa, GRC, odporności cyfrowej i ryzyka ICT.
Konsultacje i opracowania realizowane są na podstawie indywidualnego zlecenia lub umowy B2B, a zasady rozliczenia ustalane są odpowiednio do zakresu prac.
Możliwe formy współpracy
09 / Potencjalne możliwości
Nie oferuję jednego, sztywnego pakietu. Zakres wsparcia zależy od problemu, poziomu decyzji i materiału, który ma powstać. Poniżej pokazuję, jak moje kompetencje mogą pracować dla poszczególnych ról.
Zarządy i komitety audytu
Przekładam złożone zagadnienia bezpieczeństwa na krótką perspektywę decyzyjną: co jest najważniejsze, jaki jest wpływ biznesowy i jakie warianty działania są realne.
CISO, CIO i dyrektorzy IT
Porządkuję model operacyjny, katalog kontroli, roadmapę i zależności między bezpieczeństwem, technologią, ciągłością działania oraz wymaganiami regulacyjnymi.
Zespoły GRC i compliance
Łączę rejestr ryzyka, wymagania, kontrole i dowody w jeden spójny obraz. Każda rekomendacja ma zakres, ocenę, działanie mitygujące i sposób zamknięcia.
Organizacje energetyczne i finansowe
Pomagam przełożyć UKSC, NIS2, DORA i wymagania KNF na rozwiązania adekwatne do usług, procesów, infrastruktury IT/OT i rzeczywistego poziomu ryzyka.
Dostawcy usług ICT
Wspieram ocenę dostawcy z perspektywy usługi, danych i zależności organizacyjnej, bez konkursu na najdłuższy kwestionariusz.
Właściciele usług IT/OT
Pomagam nazwać zależności między aktywem, usługą, procesem i skutkiem biznesowym, szczególnie tam, gdzie IT wspiera środowisko operacyjne.
Właściciele rozwiązań AI
Porządkuję zasady użycia AI, ochronę danych i odpowiedzialność człowieka, tak aby ograniczać Shadow AI, ale nie blokować uzasadnionych zastosowań.
Audyt wewnętrzny i właściciele procesów
Porządkuję ustalenia tak, aby było wiadomo, czego dotyczą, jakie ryzyko ograniczają, kto prowadzi działanie, kiedy ma ono zostać wykonane i czym zostanie potwierdzone.
Nota dla zarządu, niezależny przegląd dla CISO, rejestr ryzyka i kontroli dla GRC, warsztat dla zespołu albo konkretne opracowanie dotyczące dostawcy, AI, architektury, incydentu lub odporności.
10 / Kontakt
Proszę nie przesyłać przez formularz informacji poufnych, danych osobowych osób trzecich ani materiałów objętych tajemnicą przedsiębiorstwa. Szczegóły przekazujemy dopiero po ustaleniu bezpiecznego sposobu komunikacji.
w.j.chojnacki@gmail.com11 / Informacje prawne
Strona ma charakter osobisty, ekspercki i informacyjny. Poniższe informacje porządkują zasady korzystania z treści oraz sposób postępowania z danymi przekazywanymi w związku z kontaktem.
Ostatnia aktualizacja: 15 sierpnia 2026 r.
Treści autorskie. Autorskie analizy, opracowania, teksty, zestawienia, struktura Biblioteki wiedzy, układ materiałów oraz elementy graficzne przygotowane dla tej strony stanowią własność intelektualną Wojciecha Chojnackiego, o ile przy danym materiale nie wskazano inaczej.
Ich kopiowanie, rozpowszechnianie, modyfikowanie, tworzenie opracowań lub wykorzystywanie w działalności komercyjnej wymaga uprzedniej zgody Wojciecha Chojnackiego. Zgodę można uzyskać, kontaktując się pod adresem w.j.chojnacki@gmail.com. Dozwolony użytek i cytowanie powinny odbywać się w granicach obowiązującego prawa, z podaniem autora i źródła.
Fotografie i potwierdzenia kwalifikacji: fotografie przedstawiające Wojciecha Chojnackiego są jego własnymi materiałami. Odznaka ISACA jest wykorzystywana wyłącznie jako potwierdzenie członkostwa oraz posiadanych kwalifikacji i nie oznacza, że ISACA patronuje stronie ani rekomenduje jej treści.
Informacje o ukończonych studiach i programach wynikają z posiadanych dyplomów. Logotypy Politechniki Bydgoskiej, Uniwersytetu Mikołaja Kopernika, Wyższej Szkoły Bankowej w Toruniu i Dominican University Chicago służą wyłącznie identyfikacji instytucji, których dotyczą te kwalifikacje. Logotypy, znaki towarowe i odznaki pozostają własnością odpowiednich podmiotów, a ich umieszczenie na stronie nie oznacza przeniesienia ani udzielenia licencji do dalszego wykorzystania.
Obecny zakres: strona jest publiczną wizytówką ekspercką. Kontakt służy przedstawieniu tematu i rozpoczęciu rozmowy dotyczącej współpracy B2B. Strona nie prowadzi sprzedaży online, nie przyjmuje płatności, nie zawiera automatycznej rezerwacji usług, nie zakłada kont użytkowników i nie oferuje newslettera. Samo użycie formularza nie zawiera umowy o wykonanie usługi.
Konsultacje i opracowania są realizowane wyłącznie na podstawie indywidualnego zlecenia lub umowy B2B, w której strony ustalają zakres prac, wynagrodzenie, terminy, zasady odpowiedzialności, poufność i prawa do rezultatów. Jeżeli w przyszłości pojawi się sprzedaż online, usługi dla konsumentów, płatne materiały cyfrowe albo automatyczne zawieranie umów, przed uruchomieniem takiej funkcji zostanie opublikowany regulamin dostosowany do konkretnego modelu.
Administrator: Wojciech Chojnacki. Kontakt w sprawach dotyczących prywatności i danych osobowych: w.j.chojnacki@gmail.com.
Zakres przetwarzania: strona nie prowadzi kont użytkowników, newslettera, komentarzy, sklepu ani własnego panelu zapisywania danych. Dane mogą zostać przekazane dobrowolnie przez osobę, która skorzysta z adresu e-mail lub formularza kontaktowego.
Formularz kontaktowy: formularz nie wysyła danych do aplikacyjnej bazy strony. Po jego użyciu otwierane jest okno tworzenia wiadomości w Gmailu albo program pocztowy użytkownika, z adresem w.j.chojnacki@gmail.com jako odbiorcą. Jeżeli wiadomość zostanie wysłana, dane są przetwarzane w celu odpowiedzi na zapytanie, przygotowania współpracy lub podjęcia działań przed zawarciem umowy, zależnie od kontekstu, na podstawie art. 6 ust. 1 lit. b lub f RODO. Podanie danych jest dobrowolne, ale bez danych kontaktowych nie będzie możliwe udzielenie odpowiedzi.
Odbiorcy i przechowywanie: dane mogą być dostępne dla dostawcy poczty elektronicznej, hostingu oraz podmiotów zapewniających utrzymanie i bezpieczeństwo strony, wyłącznie w zakresie potrzebnym do obsługi kontaktu i infrastruktury. Hosting może przetwarzać dane techniczne i logi bezpieczeństwa, a treść wiadomości przetwarza dostawca poczty po jej wysłaniu. Jeżeli którykolwiek z tych dostawców korzysta z podmiotów poza Europejskim Obszarem Gospodarczym, transfer odbywa się z zastosowaniem mechanizmu przewidzianego w rozdziale V RODO, odpowiednio do aktualnej konfiguracji usługi. Wiadomości przechowuje się przez okres potrzebny do obsługi sprawy, co do zasady nie dłużej niż 12 miesięcy od jej zamknięcia, chyba że dłuższy okres wynika z umowy, obowiązku prawnego lub potrzeby obrony roszczeń.
Prawa osoby: przysługuje prawo dostępu do danych, ich sprostowania, usunięcia, ograniczenia przetwarzania, wniesienia sprzeciwu oraz, w przypadkach przewidzianych prawem, przenoszenia danych. Skargę można wnieść do Prezesa Urzędu Ochrony Danych Osobowych. Strona nie stosuje profilowania ani zautomatyzowanego podejmowania decyzji.
Zasada bezpieczeństwa: proszę nie przekazywać przez stronę informacji poufnych, danych szczególnie chronionych, haseł, kluczy API ani materiałów objętych tajemnicą przedsiębiorstwa. Szczegóły współpracy powinny być przekazane dopiero po ustaleniu bezpiecznego kanału komunikacji.
Własny kod strony nie stosuje analitycznych, reklamowych, marketingowych ani profilujących plików cookies i nie prowadzi śledzenia nawigacji użytkownika. Dlatego strona nie uruchamia opcjonalnego mechanizmu zgody dla takich narzędzi.
Warstwa hostingu, bezpieczeństwa lub dostępu może używać technicznych, niezbędnych plików cookies albo podobnych identyfikatorów. Służą one wyłącznie utrzymaniu działania, ochronie i obsłudze dostępu do strony. Ich wyłączenie może utrudnić korzystanie z serwisu. Jeżeli w przyszłości zostaną dodane narzędzia analityczne, marketingowe lub inne opcjonalne technologie, zostaną uruchomione dopiero po uzyskaniu wymaganej zgody i opisane w tej sekcji.
Strona zawiera odnośniki do serwisów zewnętrznych, w szczególności ISACA i UODO. Po przejściu do tych serwisów obowiązują ich własne zasady prywatności i cookies.