Laboratorium 1

• W1 Zaawansowana ochrona szczególnych kategorii danych oraz tajemnicy zawodów medycznych.
• W2W3 Wymogi ISO/IEC 27001 (klauzule 6.1, 8.1, Załącznik A), normy ISO 27799 (bezpieczeństwo w ochronie zdrowia) oraz dyrektywy NIS2.
• U1 Opracowanie zintegrowanego planu SZBI dla szpitala wielospecjalistycznego.
• U2 Klasyfikacja niezgodności (NC1 - duża, NC2 - mała, OFI - szansa na poprawę).
• U3 Przeprowadzenie analizy ryzyka w podejściu risk-based audit z użyciem matrycy ryzyka 3 × 3.
• K2K3 Zdolność do podejmowania decyzji priorytetyzujących ciągłość ratowania życia ludzkiego.

Celem zadania na ocenę 4.0 jest wykształcenie u studentów umiejętności zaprojektowania kompleksowej Polityki Bezpieczeństwa Informacji dla podmiotu leczniczego o statusie operatora usługi kluczowej w rozumieniu dyrektywy NIS2 i ustawy o KSC. Zadanie wymaga nie tylko zdefiniowania podstawowych reguł ochrony danych medycznych, ale także przeprowadzenia wstępnej analizy ryzyka dla aparatury medycznej podłączonej do sieci (IoMT), sklasyfikowania zidentyfikowanych uchybień według kategorii niezgodności (NC1/NC2/OFI) oraz opracowania formalnego Planu Działań Korygujących (CAP).

Wojewódzki Szpital Specjalistyczny im. dr. Władysława Biegańskiego dysponuje 650 łóżkami, 18 oddziałami (w tym SOR, OIOM, Blok Operacyjny) oraz przyszpitalną przychodnią specjalistyczną. Szpital zatrudnia 1 200 pracowników (lekarze, pielęgniarki, diagności, personel techniczny i administracja). Infrastruktura IT obejmuje zintegrowany Szpitalny System Informacyjny (HIS), system archiwizacji obrazów medycznych PACS/RIS, sieć laboratoryjną LIS oraz ponad 300 urządzeń medycznych z interfejsami sieciowymi (kardiomonitory, pompy infuzyjne, tomografy, rezonanse magnetyczne).

W toku audytu wstępnego zidentyfikowano następujące złożone uchybienia:

• Podatności aparatury medycznej (IoMT): Kardiomonitory na oddziale intensywnej terapii (OIOM) oraz tomograf komputerowy pracują na niemodyfikowalnym systemie Windows 7 Embedded z wyłączonymi aktualizacjami bezpieczeństwa. Urządzenia te znajdują się w tej samej podsieci co komputery biurowe ordynatorów i mają bezpośredni dostęp do Internetu w celu zdalnego serwisu przez producenta z Niemiec. Dostęp zdalny realizowany jest przez nieszyfrowane i stałe sesje AnyDesk bez wiedzy działu IT szpitala.
• Dokumentacja papierowa i elektroniczna: W archiwum zakładowym szpitala zalega 40 000 papierowych historii chorób pacjentów z lat 2005–2020. Archiwum mieści się w piwnicy zagrożonej podtopieniem, bez czujników dymu i bez ewidencji osób wchodzących. Personel oddziałowy wynosi karty pacjentów do domów w celu pisania prac doktorskich.
• Uwierzytelnianie i autoryzacja: Na bloku operacyjnym lekarze chirurdzy korzystają ze wspólnego konta „blok_operacyjny_dyzur” bez hasła, tłumacząc to koniecznością natychmiastowego dostępu do wyników badań tomograficznych w trakcie operacji (brak czasu na wpisywanie haseł).
• Incydenty i kopie zapasowe: Baza systemu PACS (zdjęcia rentgenowskie i tomograficzne) o objętości 45 TB jest kopiowana na lokalną macierz dyskową w tej samej serwerowni. Szpital nie wdrożył zasady kopii offline (WORM/air-gap), a w ciągu ostatnich 6 miesięcy odnotowano 3 próby infekcji oprogramowaniem ransomware przez pocztę elektroniczną personelu pielęgniarskiego.

Zespół 2–3 osobowy realizuje zadanie według następującego harmonogramu:

• Krok 1 (Podział ról i odpowiedzialności):

Student 1 (Kierownik Zespołu i Architekt SZBI): Tworzy strukturę nadrzędnej Polityki Bezpieczeństwa Informacji szpitala, definiuje zakres SZBI oraz reguły organizacyjne dla personelu medycznego.

Student 2 (Specjalista ds. Bezpieczeństwa Technicznego i Sieciowego): Opracowuje segmentację sieci dla aparatury medycznej (mikro-segmentacja IoMT), procedury zdalnego dostępu serwisowego oraz architekturę kopii zapasowych PACS/HIS.

Student 3 (Audytor Ryzyka i Zgodności Prawnej): Przeprowadza szacowanie ryzyka dla 3 wybranych aktywów krytycznych (aparatura medyczna, baza PACS, historia chorób), klasyfikuje niezgodności (NC1/NC2/OFI) oraz opracowuje Plan Działań Korygujących (CAP). W zespole 2-osobowym zadania te są dzielone symetrycznie.

• Krok 2 (Szacowanie ryzyka - matryca 3 × 3):

Dla zidentyfikowanych zagrożeń (np. zaszyfrowanie PACS przez ransomware, przejęcie kardiomonitora na OIOM, utrata kartotek w zalanej piwnicy) określcie Prawdopodobieństwo (1-Niskie, 2-Średnie, 3-Wysokie) oraz Skutek dla zdrowia i życia (1-Niski, 2-Poważny, 3-Krytyczny). Obliczcie poziom ryzyka inherentnego (Iloczyn P × S) i zaproponujcie kontrole mitygujące.

• Krok 3 (Kwalifikacja niezgodności wg ISO/IEC 27001):

Przypiszcie wykryte luki do konkretnych wymagań normy ISO/IEC 27001:2022 i dokonajcie ich gradacji:

• NC1 (Niezgodność Duża): Zaniechanie stwarzające bezpośrednie zagrożenie dla pacjentów lub brak wymaganego procesu.
• NC2 (Niezgodność Mała): Incydentalne uchybienie proceduralne niepowodujące załamania systemu.
• OFI (Szansa na poprawę): Możliwość wdrożenia nowoczesnego rozwiązania usprawniającego pracę.

Zaprojektujcie tabelę CAP zawierającą: Nr uchybienia, Kwalifikację, Przyczynę źródłową (Root Cause), Działanie naprawcze, Odpowiedzialnego (Właściciela) oraz Termin realizacji (od 14 do 90 dni).

• Krok 4 (Plan CAP i RTP):

Dla każdej ustalonej niezgodności przygotujcie wpis w Planie Działań Korygujących (CAP): przyczyna źródłowa, działanie naprawcze, właściciel, termin (14–90 dni od daty audytu) i kryterium skuteczności. Następnie wypełnijcie Plan Postępowania z Ryzykiem (RTP): decyzja postępowania z ryzykiem (unikanie, redukcja, transfer albo akceptacja), działanie mitygujące, właściciel, termin i szacowane ryzyko rezydualne. Uzasadnienie decyzji o akceptacji ryzyka zapiszcie w raporcie.

Skala szacowania ryzyka (matryca 3 × 3): Prawdopodobieństwo (P): 1 – niskie, 2 – średnie, 3 – wysokie. Skutek (S): 1 – niski, 2 – poważny, 3 – krytyczny. Poziom ryzyka to iloczyn P × S (1–9). Wynik 6–9 oznacza strefę wysoką / niedopuszczalną, 3–4 strefę średnią, a 1–2 ryzyko akceptowalne. Tabele poniżej zawierają przykładowe karty ryzyka dla kluczowych aktywów jednostki.

Rejestr ustaleń audytowych z formalną gradacją: NC1 – Niezgodność Duża, NC2 – Niezgodność Mała, OFI – Szansa na poprawę.

Plan Działań Korygujących zawiera numer ustalenia, kwalifikację, analizę przyczyny źródłowej (Root Cause), działanie naprawcze, właściciela oraz harmonogram realizacji (14–90 dni).

Plan Postępowania z Ryzykiem (ang. Risk Treatment Plan, RTP) uzupełnia Plan Działań Korygujących: CAP odpowiada na pytanie co i kto naprawia, a RTP – jaką decyzją zarządcy świadomie redukują, przenoszą, unikają lub akceptują ryzyko. Każde ryzyko z matrycy powyżej musi mieć w RTP jedną, jawnie zapisaną decyzję; ryzyko pozostawione bez decyzji jest ryzykiem nieakceptowanym.

Do uzupełnienia: dla każdego zagrożenia z tabeli ryzyk wpiszcie klasyfikację (P × S), kwalifikację (NC1/NC2/OFI), wybraną decyzję postępowania, działanie mitygujące z odesłaniem do pozycji CAP, właściciela z terminem oraz szacowane ryzyko rezydualne. Poniżej wzór wypełniony dla jednego scenariusza – pozostałe wiersze uzupełnijcie sami.

• Unikanie ryzyka – eliminacja aktywności lub zmiana jej zakresu, np. wyłączenie publicznego dostępu do usługi.
• Redukcja (ograniczenie) – wdrożenie kontroli obniżających prawdopodobieństwo albo skutek; to decyzja dla większości ustaleń NC1 i NC2.
• Transfer (przeniesienie) – przeniesienie ryzyka na podmiot trzeci: umowa SLA, ubezpieczenie, gwarancja dostawcy, klauzule audytowe.
• Akceptacja ryzyka – świadome pozostawienie ryzyka przez organ zarządzający, z podaniem uzasadnienia, właściciela decyzji i terminu przeglądu.

Decyzja akceptacja wymaga pisemnego uzasadnienia w raporcie; samo wpisanie decyzji bez argumentu jest niewystarczające. Terminy w RTP muszą pokrywać się z terminami w CAP dla tych samych ustaleń.

Każdy raport rozpoczyna się od Executive Summary dla zarządu (ok. 1 strona): najważniejsze ustalenia z liczbą NC1 / NC2 / OFI, najwyższe ryzyko rezydualne, kluczowe decyzje podjęte w RTP oraz wniosek o zasoby i decyzję do podjęcia. Objętość raportu to 8–12 stron A4, a obrona koncepcji przed komisją trwa 15 minut. Executive Summary jest wymagane przez kryteria formalne zaliczenia na ocenę 4.0.

Studenci przygotowują rozbudowany raport/referat audytowy (objętość 8–12 stron A4) oraz 15-minutową prezentację z obroną koncepcji przed komisją.

Struktura raportu obejmuje:

• Rozdział 1: Metryka podmiotu leczniczego, uwarunkowania prawne (RODO art. 9, NIS2, KRI, ustawa o prawach pacjenta).
• Rozdział 2: Diagnoza stanu zastanego i identyfikacja aktywów krytycznych szpitala.
• Rozdział 3: Matryca szacowania ryzyka dla zasobów teleinformatycznych i aparatury IoMT.
• Rozdział 4: Projekt Polityki Bezpieczeństwa Informacji Szpitala Wojewódzkiego wraz z procedurami szczegółowymi:
  • Procedura bezpiecznego serwisu i separacji aparatury medycznej.
  • Polityka szybkiego i bezpiecznego logowania na Bloku Operacyjnym (np. karty RFID + PIN).
  • Procedura bezpiecznego archiwizowania i cyfryzacji papierowej dokumentacji medycznej.
  • Zasady ochrony przed ransomware i polityka backupu 3-2-1 dla systemów PACS/HIS.
• Rozdział 5: Rejestr ustaleń audytowych z gradacją (NC1, NC2, OFI) oraz Plan Działań Korygujących (CAP).
• Rozdział 6: Analiza wykonalności, kosztochłonności i wskaźników dojrzałości bezpieczeństwa.

Wzorcowe rozwiązanie problemu na ocenę 4.0 zawiera:

• Segmentacja sieciowa aparatury medycznej:
  • Utworzenie odizolowanego VLAN-u Medycznego z blokadą bezpośredniego wyjścia do Internetu.
  • Całkowite wyłączenie AnyDesk/TeamViewer na korzyść szyfrowanego tunelu VPN zestawianego na żądanie (On-Demand VPN) wyłącznie na czas sesji serwisowej producenta, z rejestracją sesji (nagrywanie wideo połączenia administratora zewnętrznego).
• Uwierzytelnianie na Bloku Operacyjnym:
  • Wdrożenie bezdotykowego uwierzytelniania zbliżeniowego (karty RFID zintegrowane z fartuchem/opaską chirurga) w połączeniu z szybkim 4-cyfrowym kodem PIN, co skraca czas logowania do 2 sekund i eliminuje konta współdzielone.
• Zabezpieczenie archiwum papierowego:
  • Natychmiastowe przeniesienie archiwum do pomieszczenia powyżej poziomu gruntu, montaż czujników zalania i dymu, wdrożenie procedury kaucji i zakazu wynoszenia dokumentacji poza budynek szpitala.
• Matryca ryzyka (przykładowy wpis):
  • Zagrożenie: Infekcja ransomware bazy PACS przez otwarty pulpit AnyDesk na tomografie.
  • Prawdopodobieństwo: 3 (Wysokie), Skutek: 3 (Krytyczny - paraliż diagnostyki onkologicznej i urazowej).
  • Poziom ryzyka inherentnego: 9/9 (Strefa Czerwona - Niedopuszczalne).
  • Kontrole: Separacja VLAN, Firewall NGFW, inspekcja ruchu, backup niemodyfikowalny (WORM).
  • Ryzyko rezydualne po wdrożeniu: P=1, S=2 (Poziom 2/9 - Akceptowalne).
• Kwalifikacja ustaleń:
  • Ustalenie 1 (AnyDesk bez nadzoru na tomografie): Niezgodność Duża (NC1) – naruszenie ISO/IEC 27001 Załącznik A.8.20 oraz art. 32 RODO.
  • Ustalenie 2 (Brak blokady ekranu i wspólne hasło na Bloku): Niezgodność Mała (NC2) – naruszenie Załącznika A.8.5.
  • Ustalenie 3 (Brak automatycznej cyfryzacji archiwum papierowego): Szansa na poprawę (OFI) – Załącznik A.5.33.

Zalety rozwiązania:

• Zapewnienie ciągłości działania szpitala i ochrony życia pacjentów przed cyberatakami paraliżującymi diagnostykę.
• Spełnienie rygorystycznych wymogów dyrektywy NIS2 dla podmiotów kluczowych sektora ochrony zdrowia.
• Pogodzenie ergonomii pracy lekarzy chirurgów (szybkie logowanie RFID) z bezwzględną rozliczalnością zdarzeń w systemie medycznym.

Wady i ograniczenia wdrożeniowe:

• Znaczny koszt zakupu zapory sieciowej nowej generacji (NGFW) oraz czytników RFID na salach operacyjnych.
• Konieczność renegocjacji umów serwisowych z globalnymi producentami aparatury tomograficznej i laboratoryjnej.
• Długi czas potrzebny na zdigitalizowanie i przeniesienie 40 000 woluminów archiwalnych historii chorób.

• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (Dyrektywa NIS2) – sektor ochrony zdrowia jako podmiot kluczowy.
• Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (t.j. Dz.U. z 2024 r. poz. 1077, ze zm., w tym ustawą z dnia 23 stycznia 2026 r., Dz.U. z 2026 r. poz. 252).
• Ustawa z dnia 6 listopada 2018 r. o dokumentacji medycznej (obowiązująca, ze zm.).
• Rozporządzenie Ministra Zdrowia z dnia 6 kwietnia 2020 r. w sprawie rodzajów, zakresu i wzorów dokumentacji medycznej oraz sposobu jej przetwarzania (obowiązujące).
• Norma PN-EN ISO/IEC 27001:2022 – Załącznik A: A.8.20 (Bezpieczeństwo sieci), A.8.22 (Segregacja sieci), A.8.24 (Kryptografia).
• Norma ISO 27799:2025 – Informatyka w ochronie zdrowia: Zarządzanie bezpieczeństwem informacji w sektorze zdrowia za pomocą normy ISO/IEC 27002.
• Wytyczne CSIRT CeZ (Centrum e-Zdrowia): „Dobre praktyki cyberbezpieczeństwa dla szpitali i podmiotów leczniczych”, Warszawa 2023.

• W1 Ochrona tajemnic prawnie chronionych (tajemnica skarbowa, ochrona danych obywateli).
• W2W3 Wymogi Rozporządzenia KRI, Ustawy o KSC oraz normy ISO 22301 (ciągłość działania).
• U1 Opracowanie zintegrowanego pakietu dokumentacji bezpieczeństwa dla dużej jednostki samorządu.
• U2 Kwalifikacja niezgodności (NC1/NC2/OFI) na styku administracja-obywatel.
• U3 Identyfikacja ryzyk teleinformatycznych i wyliczenie wskaźników RTO i RPO dla krytycznych rejestrów.
• K1K3 Etyka i wysoki profesjonalizm w zabezpieczaniu danych wrażliwych społeczności lokalnej.

Celem zadania na ocenę 4.0 jest zaprojektowanie zaawansowanej Polityki Bezpieczeństwa Informacji w Urzędzie Miasta na prawach powiatu. Urząd zarządza rozproszoną architekturą teleinformatyczną, realizuje zadania z zakresu e-administracji publicznej (e-PUAP, mObywatel, EZD), przetwarza bazy ewidencji ludności, podatków oraz ewidencji gruntów i budynków, a jego działalność podlega obowiązkom wynikającym z Krajowych Ram Interoperacyjnych oraz Krajowego Systemu Cyberbezpieczeństwa. Zadanie wymaga opracowania procedury ciągłości działania (BCP), matrycy ryzyka dla usług publicznych oraz formalnego rejestru niezgodności z planem działań zapobiegawczych.

Urząd Miasta „Nadodrze” (miasto na prawach powiatu, 118 000 mieszkańców) zatrudnia 280 urzędników w 14 wydziałach zlokalizowanych w 3 odrębnych budynkach połączonych miejską siecią światłowodową. Urząd obsługuje systemy: PESEL/ŹRÓDŁO, Ewidencję Pojazdów i Kierowców (CEPiK), Centralną Ewidencję i Informację o Działalności Gospodarczej (CEIDG), system podatkowy oraz Elektroniczne Zarządzanie Dokumentacją (EZD). Rocznie urząd rejestruje 120 000 spraw urzędowych.

Audyt systemu bezpieczeństwa ujawnił następujące problemy:

• Brak procedury ciągłości działania (BCP/DRP): Serwery EZD i podatków znajdują się w jednej serwerowni w budynku głównym. Serwerownia nie posiada agregatu prądotwórczego ani automatycznego systemu gaszenia gazem (jedynie zwykła gaśnica proszkowa na ścianie). W razie pożaru lub awarii zasilania powyżej 2 godzin praca wszystkich wydziałów miasta zostaje całkowicie sparaliżowana.
• Bezpieczeństwo miejskiej sieci światłowodowej: Przełączniki światłowodowe łączące budynki urzędu umieszczone są w piwnicach innych jednostek miejskich (m.in. OSiR i MOPR) w niezamkniętych szafach RACK obok szatni sportowych, co umożliwia podpięcie analizatora sieciowego (sniffera).
• Uprawnienia użytkowników i współdzielenie ról: Pracownicy Wydziału Komunikacji rejestrujący pojazdy pracują na kontach o uprawnieniach nielimitowanych, a pracownicy stażyści posiadają dostęp do wglądu w dane majątkowe mieszkańców w systemie podatkowym. Brak jest kwartalnego przeglądu kont i uprawnień.
• Praca zdalna i telepraca: 40 urzędników pracuje zdalnie 1–2 dni w tygodniu. Korzystają z prywatnych laptopów, łącząc się z urzędowym systemem EZD przez nieszyfrowany pulpit zdalny RDP wystawiony bezpośrednio na świat bez VPN i bez uwierzytelniania wieloskładnikowego (MFA). W logach zapory sieciowej odnotowano ponad 50 000 prób siłowego złamania haseł (brute-force) na otwarty port RDP w ciągu ostatniego miesiąca.

• Krok 1 (Podział zadań w zespole audytorskim):

Student 1 (Kierownik Zespołu): Projektuje Politykę Bezpieczeństwa Informacji Urzędu Miasta, regulamin nadawania i odbierania uprawnień (RBAC) oraz procedurę przeglądu kont.

Student 2 (Inżynier Bezpieczeństwa i Sieci): Opracowuje architekturę bezpiecznego dostępu zdalnego (VPN z MFA, likwidacja otwartego RDP), zabezpieczenie fizyczne punktów dystrybucyjnych światłowodu oraz plan redundancji zasilania serwerowni.

Student 3 (Audytor Ryzyka i BCP): Przeprowadza analizę wpływu na działalność (BIA - Business Impact Analysis) dla systemu podatkowego i EZD, szacuje ryzyka w matrycy 3 × 3 oraz opracowuje Plan Ciągłości Działania (BCP) i rejestr niezgodności NC1/NC2/OFI.

• Krok 2 (Analiza BIA i szacowanie ryzyka):

Dla systemów CEPiK, EZD i podatków określcie:

• Maksymalny dopuszczalny czas przestoju (MTPD).
• Docelowy czas odtworzenia (RTO - Recovery Time Objective) oraz dopuszczalną utratę danych (RPO).
• Oszacujcie ryzyko ataku ransomware przez otwarty port RDP oraz pożaru w serwerowni.

• Krok 3 (Kwalifikacja ustaleń wg KRI i ISO/IEC 27001):

Dokonajcie formalnego przypisania uchybień do § 19 i § 20 Rozporządzenia KRI, Ustawy o KSC oraz Załącznika A normy ISO/IEC 27001:2022:

• Wskażcie, które uchybienie stanowi Niezgodność Dużą (NC1) uniemożliwiającą pozytywną ocenę audytu KRI.

Zredagujcie karty zaleceń audytowych z harmonogramem naprawczym dla Prezydenta Miasta i Rady Miejskiej.

• Krok 4 (Plan CAP i RTP):

Dla każdej ustalonej niezgodności przygotujcie wpis w Planie Działań Korygujących (CAP): przyczyna źródłowa, działanie naprawcze, właściciel, termin (14–90 dni od daty audytu) i kryterium skuteczności. Następnie wypełnijcie Plan Postępowania z Ryzykiem (RTP): decyzja postępowania z ryzykiem (unikanie, redukcja, transfer albo akceptacja), działanie mitygujące, właściciel, termin i szacowane ryzyko rezydualne. Uzasadnienie decyzji o akceptacji ryzyka zapiszcie w raporcie.

Skala szacowania ryzyka (matryca 3 × 3): Prawdopodobieństwo (P): 1 – niskie, 2 – średnie, 3 – wysokie. Skutek (S): 1 – niski, 2 – poważny, 3 – krytyczny. Poziom ryzyka to iloczyn P × S (1–9). Wynik 6–9 oznacza strefę wysoką / niedopuszczalną, 3–4 strefę średnią, a 1–2 ryzyko akceptowalne. Tabele poniżej zawierają przykładowe karty ryzyka dla kluczowych aktywów jednostki.

Rejestr ustaleń audytowych z formalną gradacją: NC1 – Niezgodność Duża, NC2 – Niezgodność Mała, OFI – Szansa na poprawę.

Plan Działań Korygujących zawiera numer ustalenia, kwalifikację, analizę przyczyny źródłowej (Root Cause), działanie naprawcze, właściciela oraz harmonogram realizacji (14–90 dni).

Plan Postępowania z Ryzykiem (ang. Risk Treatment Plan, RTP) uzupełnia Plan Działań Korygujących: CAP odpowiada na pytanie co i kto naprawia, a RTP – jaką decyzją zarządcy świadomie redukują, przenoszą, unikają lub akceptują ryzyko. Każde ryzyko z matrycy powyżej musi mieć w RTP jedną, jawnie zapisaną decyzję; ryzyko pozostawione bez decyzji jest ryzykiem nieakceptowanym.

Do uzupełnienia: dla każdego zagrożenia z tabeli ryzyk wpiszcie klasyfikację (P × S), kwalifikację (NC1/NC2/OFI), wybraną decyzję postępowania, działanie mitygujące z odesłaniem do pozycji CAP, właściciela z terminem oraz szacowane ryzyko rezydualne. Poniżej wzór wypełniony dla jednego scenariusza – pozostałe wiersze uzupełnijcie sami.

• Unikanie ryzyka – eliminacja aktywności lub zmiana jej zakresu, np. wyłączenie publicznego dostępu do usługi.
• Redukcja (ograniczenie) – wdrożenie kontroli obniżających prawdopodobieństwo albo skutek; to decyzja dla większości ustaleń NC1 i NC2.
• Transfer (przeniesienie) – przeniesienie ryzyka na podmiot trzeci: umowa SLA, ubezpieczenie, gwarancja dostawcy, klauzule audytowe.
• Akceptacja ryzyka – świadome pozostawienie ryzyka przez organ zarządzający, z podaniem uzasadnienia, właściciela decyzji i terminu przeglądu.

Decyzja akceptacja wymaga pisemnego uzasadnienia w raporcie; samo wpisanie decyzji bez argumentu jest niewystarczające. Terminy w RTP muszą pokrywać się z terminami w CAP dla tych samych ustaleń.

Każdy raport rozpoczyna się od Executive Summary dla zarządu (ok. 1 strona): najważniejsze ustalenia z liczbą NC1 / NC2 / OFI, najwyższe ryzyko rezydualne, kluczowe decyzje podjęte w RTP oraz wniosek o zasoby i decyzję do podjęcia. Objętość raportu to 8–12 stron A4, a obrona koncepcji przed komisją trwa 15 minut. Executive Summary jest wymagane przez kryteria formalne zaliczenia na ocenę 4.0.

Studenci przygotowują sformalizowany raport audytowo-polityczny (8–12 stron A4):

• Wprowadzenie: Urząd Miasta jako węzeł Krajowego Systemu Cyberbezpieczeństwa i zaufany partner e-państwa.
• Diagnoza podatności infrastruktury miejskiej: Szczegółowe zestawienie luk w zasilaniu, punktach dystrybucyjnych i pracy zdalnej.
• Analiza BIA i Matryca Ryzyka dla kluczowych rejestrów publicznych.
• Projekt Nadrzędnej Polityki Bezpieczeństwa Informacji Urzędu Miasta wraz z pakietem procedur wykonawczych:
  • Procedura bezpiecznego dostępu zdalnego (Zero Trust Network Access / VPN + MFA).
  • Polityka zarządzania tożsamością i uprawnieniami (Role-Based Access Control - RBAC).
  • Plan Ciągłości Działania i Odtwarzania Awaryjnego (BCP/DRP) dla usług publicznych.
• Tabela klasyfikacji ustaleń (NC1, NC2, OFI) oraz Plan Działań Korygujących (CAP).
• Wnioski i kalkulacja budżetowa niezbędnych inwestycji technicznych.

Wzorcowa koncepcja dla Urzędu Miasta zawiera:

• Likwidację krytycznego wektora ataku RDP:
  • Natychmiastowe zamknięcie otwartego portu RDP na zaporze zewnętrznej (Firewall).
  • Wdrożenie bramy VPN z wymogiem uwierzytelniania dwuskładnikowego (MFA oparte na aplikacji tokenowej na służbowym smartfonie) oraz wycofanie prywatnych komputerów na rzecz zaszyfrowanych laptopów służbowych.
• Redundancję i ciągłość działania (BCP):
  • Zakup i instalacja automatycznego agregatu prądotwórczego z układem SZR (Samoczynne Załączanie Rezerwy) oraz systemu gaszenia gazem obojętnym w serwerowni głównej.
  • Wyznaczenie serwerowni zapasowej w budynku MOPR i uruchomienie replikacji danych krytycznych (RTO < 4 h, RPO < 1 h).
• Ochronę magistrali miejskiej:
  • Wymiana szaf RACK w piwnicach na szafy antywłamaniowe klasy IP55 z zamkiem elektronicznym monitorowanym przez centralę alarmową oraz instalacja kamer CCTV.
• Szacowanie ryzyka i matryca:
  • Zagrożenie: Przejęcie serwera EZD i zaszyfrowanie pism urzędowych przez podatność RDP. P=3 (Wysokie), S=3 (Krytyczne - paraliż decyzji administracyjnych, utrata terminów KPA). Ryzyko inherentne = 9/9 (Krytyczne).
  • Po wdrożeniu VPN+MFA i kontroli dostępu: P=1, S=2. Ryzyko rezydualne = 2/9 (Akceptowalne).
• Kwalifikacja ustaleń:
  • Otwarte porty RDP do Internetu bez MFA: Niezgodność Duża (NC1) – bezpośrednie naruszenie § 19 ust. 2 pkt 7 lit. a–c oraz § 20 ust. 1–2 KRI oraz Załącznika A.8.20 normy ISO/IEC 27001.
  • Brak zasilania awaryjnego i BCP: Niezgodność Duża (NC1) – naruszenie § 19 ust. 2 pkt 12 lit. b oraz § 15 ust. 1–2 KRI oraz Załącznik A.8.14.
  • Brak okresowego przeglądu uprawnień w CEPiK: Niezgodność Mała (NC2) – naruszenie Załącznika A.5.18.

Zalety rozwiązania:

• Zabezpieczenie ciągłości świadczenia usług publicznych dla 118 000 mieszkańców miasta w warunkach kryzysu energetycznego lub cyberataku.
• Całkowita eliminacja ryzyka kompromitacji sieci urzędowej z publicznego Internetu.
• Zapewnienie pełnej zgodności z wymogami KRI i ustawy o KSC przed planowaną kontrolą NIK.

Wady i ograniczenia wdrożeniowe:

• Wysokie koszty inwestycyjne (agregat prądotwórczy, system gaszenia gazem, serwerownia zapasowa – szacowane na ok. 250 000 – 400 000 PLN).
• Konieczność przeszkolenia 280 urzędników w posługiwaniu się aplikacją MFA przy logowaniu zdalnym.
• Wzrost obciążeń zespołu IT związany z administrowaniem rozproszoną siecią i serwerownią zapasową.

• Rozporządzenie Rady Ministrów z dnia 21 maja 2024 r. w sprawie Krajowych Ram Interoperacyjności (Dz.U. z 2024 r. poz. 773) – § 19 ust. 1 i 2 (obowiązek SZBI, w tym w administracji) oraz § 20 (rozliczalność).
• Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (t.j. Dz.U. z 2024 r. poz. 1077, ze zm., w tym ustawą z dnia 23 stycznia 2026 r., Dz.U. z 2026 r. poz. 252).
• Ustawa z dnia 18 listopada 2020 r. o doręczeniach elektronicznych (Dz.U. z 2023 r. poz. 285).
• Norma PN-EN ISO/IEC 27001:2022 – Załącznik A: A.5.15 (Kontrola dostępu), A.8.14 (Redundancja systemów informatycznych), A.8.20 (Bezpieczeństwo sieci).
• Norma ISO 22301:2019 – Bezpieczeństwo i odporność: Systemy zarządzania ciągłością działania – Wymagania.
• Rekomendacje Pełnomocnika Rządu ds. Cyberbezpieczeństwa dla JST: „Poradnik wdrożenia minimalnych środków cyberbezpieczeństwa w gminach”, Warszawa 2024.

• W1 Ochrona danych małoletnich, orzeczeń pedagogicznych oraz ewidencji egzaminów państwowych.
• W2W3 Standardy ISO/IEC 27001 w obszarze separacji środowisk oraz wymogi Prawa oświatowego.
• U1 Opracowanie polityki uwzględniającej podział na strefę administracyjną i strefę dydaktyczną.
• U2 Kwalifikacja uchybień w zarządzaniu uprawnieniami i separacją sieci (NC1/NC2/OFI).
• U3 Ocena ryzyka wewnętrznego (Insider Threat) z użyciem analizy prawdopodobieństwa i skutku.
• K2K3 Kształtowanie postaw etycznych wśród młodzieży i odpowiedzialność nauczycieli.

Celem zadania na ocenę 4.0 jest zaprojektowanie zaawansowanej Polityki Bezpieczeństwa Informacji w dużym zespole szkół technicznych i zawodowych. Placówka kształci przyszłych informatyków, mechatroników i elektroników, dysponując rozległym kampusem, specjalistycznymi laboratoriami sieciowymi oraz systemami chmurowymi. Wyzwaniem jest zbalansowanie otwartości edukacyjnej (prawo uczniów do eksperymentowania w laboratoriach) z koniecznością rygorystycznej ochrony danych osobowych uczniów i rodziców, systemów oceniania i rekrutacji oraz przeciwdziałaniem wewnętrznym próbom sabotażu sieciowego ze strony uzdolnionych technicznie uczniów.

Zespół Szkół Technicznych i Ogólnokształcących kształci 1 100 uczniów w wieku 14–19 lat i zatrudnia 95 nauczycieli oraz 20 pracowników obsługi. W skład kampusu wchodzą: 3 budynki dydaktyczne, internat na 120 miejsc, warsztaty szkolne oraz 6 pracowni komputerowych (łącznie 150 stacji PC). W szkole wdrożono dziennik elektroniczny, platformę edukacyjną Microsoft 365 / Google Workspace oraz sieć Wi-Fi pokrywającą sale lekcyjne i internat.

W trakcie audytu bezpieczeństwa ujawniono następujące incydenty i uchybienia:

• Brak separacji laboratoriów od sieci szkolnej: Pracownie komputerowe dla techników informatyków znajdują się w tej samej logicznej sieci LAN co komputery dyrekcji, sekretariatu i księgowości. Podczas lekcji z diagnostyki sieci uczniowie uruchomili narzędzia skanujące (Nmap, Wireshark) oraz podsłuchali ruch sieciowy, przechwytując hasło dyrektora do systemu finansowo-kadrowego przesyłane protokołem HTTP.
• Internat szkolny i niekontrolowany ruch: W internacie uczniowie podłączają do gniazdek ściennych własne routery, serwery gier oraz urządzenia IoT. Zarejestrowano przypadek wykorzystania szkolnego adresu IP do przeprowadzania ataków DDoS na zewnętrzne serwery komercyjne oraz pobierania nielegalnego oprogramowania.
• Dane wrażliwe w sekretariacie: Akta osobowe uczniów ze specjalnymi potrzebami edukacyjnymi (orzeczenia o niepełnosprawności, autyzmie, trudnej sytuacji materialnej) skanowane są na współdzielonym urządzeniu wielofunkcyjnym i trafiają do folderu sieciowego „Skany”, do którego dostęp bez hasła ma każdy komputer w szkole.
• Prawa administracyjne na stacjach uczniowskich: Na komputerach w pracowniach uczniowie posiadają pełne uprawnienia administratora lokalnego (Local Admin), co pozwala im na modyfikację rejestru systemowego, wyłączanie programów antywirusowych oraz instalowanie oprogramowania szpiegującego (keyloggerów) monitorującego loginy nauczycieli.

• Krok 1 (Podział ról w zespole audytorskim):

Student 1 (Koordynator): Definiuje nadrzędną Politykę Bezpieczeństwa Informacji Zespołu Szkół, kodeks etyki cyfrowej ucznia oraz procedurę postępowania z dokumentacją orzeczeniową w sekretariacie.

Student 2 (Architekt Sieci i Systemów): Projektuje kompletną separację sieciową kampusu (VLAN Administracja, VLAN Pracownie IT, VLAN Dziennik, VLAN Internat Wi-Fi) z użyciem zapory sieciowej UTM/NGFW oraz politykę ograniczenia praw użytkowników na stacjach uczniowskich.

Student 3 (Audytor Ryzyka i Kwalifikacji Niezgodności): Przeprowadza analizę ryzyka dla incydentów wewnętrznych (Insider Threat), kwalifikuje uchybienia do kategorii NC1/NC2/OFI oraz formułuje Plan Działań Korygujących (CAP).

• Krok 2 (Analiza ryzyka zagrożeń wewnętrznych):

Oceńcie w matrycy 3 × 3 prawdopodobieństwo i skutki:

• Przejęcia haseł nauczycieli do dziennika przez uczniów przy użyciu keyloggera.
• Wycieku orzeczeń o niepełnosprawności z publicznego folderu „Skany”.
• Zablokowania łącza szkoły w wyniku ataku DDoS zainicjowanego z internatu.

• Krok 3 (Kwalifikacja niezgodności wg ISO/IEC 27001):

Sformułujcie karty niezgodności wskazujące naruszone klauzule (A.8.2 - Prawa uprzywilejowane, A.8.22 - Segregacja sieci, A.8.12 - Zapobieganie wyciekom danych).

• Krok 4 (Plan CAP i RTP):

Zaprojektujcie harmonogram wdrożenia zmian z podziałem na działania natychmiastowe (0–14 dni) oraz strategiczne (wakacje szkolne).

Skala szacowania ryzyka (matryca 3 × 3): Prawdopodobieństwo (P): 1 – niskie, 2 – średnie, 3 – wysokie. Skutek (S): 1 – niski, 2 – poważny, 3 – krytyczny. Poziom ryzyka to iloczyn P × S (1–9). Wynik 6–9 oznacza strefę wysoką / niedopuszczalną, 3–4 strefę średnią, a 1–2 ryzyko akceptowalne. Tabele poniżej zawierają przykładowe karty ryzyka dla kluczowych aktywów jednostki.

Rejestr ustaleń audytowych z formalną gradacją: NC1 – Niezgodność Duża, NC2 – Niezgodność Mała, OFI – Szansa na poprawę.

Plan Działań Korygujących zawiera numer ustalenia, kwalifikację, analizę przyczyny źródłowej (Root Cause), działanie naprawcze, właściciela oraz harmonogram realizacji (14–90 dni).

Plan Postępowania z Ryzykiem (ang. Risk Treatment Plan, RTP) uzupełnia Plan Działań Korygujących: CAP odpowiada na pytanie co i kto naprawia, a RTP – jaką decyzją zarządcy świadomie redukują, przenoszą, unikają lub akceptują ryzyko. Każde ryzyko z matrycy powyżej musi mieć w RTP jedną, jawnie zapisaną decyzję; ryzyko pozostawione bez decyzji jest ryzykiem nieakceptowanym.

Do uzupełnienia: dla każdego zagrożenia z tabeli ryzyk wpiszcie klasyfikację (P × S), kwalifikację (NC1/NC2/OFI), wybraną decyzję postępowania, działanie mitygujące z odesłaniem do pozycji CAP, właściciela z terminem oraz szacowane ryzyko rezydualne. Poniżej wzór wypełniony dla jednego scenariusza – pozostałe wiersze uzupełnijcie sami.

• Unikanie ryzyka – eliminacja aktywności lub zmiana jej zakresu, np. wyłączenie publicznego dostępu do usługi.
• Redukcja (ograniczenie) – wdrożenie kontroli obniżających prawdopodobieństwo albo skutek; to decyzja dla większości ustaleń NC1 i NC2.
• Transfer (przeniesienie) – przeniesienie ryzyka na podmiot trzeci: umowa SLA, ubezpieczenie, gwarancja dostawcy, klauzule audytowe.
• Akceptacja ryzyka – świadome pozostawienie ryzyka przez organ zarządzający, z podaniem uzasadnienia, właściciela decyzji i terminu przeglądu.

Decyzja akceptacja wymaga pisemnego uzasadnienia w raporcie; samo wpisanie decyzji bez argumentu jest niewystarczające. Terminy w RTP muszą pokrywać się z terminami w CAP dla tych samych ustaleń.

Każdy raport rozpoczyna się od Executive Summary dla zarządu (ok. 1 strona): najważniejsze ustalenia z liczbą NC1 / NC2 / OFI, najwyższe ryzyko rezydualne, kluczowe decyzje podjęte w RTP oraz wniosek o zasoby i decyzję do podjęcia. Objętość raportu to 8–12 stron A4, a obrona koncepcji przed komisją trwa 15 minut. Executive Summary jest wymagane przez kryteria formalne zaliczenia na ocenę 4.0.

Studenci opracowują raport audytowy (8–12 stron A4):

• Wprowadzenie: Edukacja techniczna a wyzwania bezpieczeństwa – jak uczyć informatyki, nie narażając szkoły na kompromitację.
• Diagnoza podatności w Zespole Szkół Technicznych: Opis incydentów podsłuchiwania sieci i wycieku skanów.
• Matryca oceny ryzyka zagrożeń wewnętrznych i zewnętrznych.
• Projekt Polityki Bezpieczeństwa Informacji Kampusu Szkolnego wraz z załącznikami:
  • Architektura segmentacji sieciowej (strefy zaufane vs strefy dydaktyczne i internat).
  • Regulamin bezpiecznej pracowni komputerowej i polityka braku uprawnień administratora dla uczniów.
  • Procedura bezpiecznego skanowania dokumentacji wrażliwej (zamknięte foldery imienne).
  • Regulamin korzystania z sieci internackiej (monitoring pasma, blokada P2P i ataków sieciowych).
• Rejestr niezgodności (NC1/NC2/OFI) oraz Plan Działań Korygujących (CAP).
• Podsumowanie i plan edukacji cyfrowej dla nauczycieli i uczniów.

Wzorcowa koncepcja na ocenę 4.0 wprowadza:

• Architektoniczną segregację sieci (Strefy bezpieczeństwa):
  • Wdrożenie routera UTM/Firewall z podziałem na 5 odizolowanych stref (VLAN):

VLAN 10 (Administracja/Dyrektor): Pełne bezpieczeństwo, brak dostępu z zewnątrz.

VLAN 20 (Nauczyciele/Dziennik): Dostęp do Internetu i platformy edukacyjnej, brak wglądu w administrację.

VLAN 30 (Pracownie IT): Środowisko dydaktyczne w piaskownicy (Sandbox) – ruch izolowany, zablokowany dostęp do pozostałych sieci szkoły.

VLAN 40 (Internat Wi-Fi): Dostęp do Internetu z inspekcją ruchu, blokadą protokołów P2P (torrent), filtrem DNS i ograniczeniem pasma (QoS).

VLAN 50 (Kamery CCTV i IoT).

• Likwidację uprawnień lokalnego administratora:
  • Wdrożenie centralnej domeny Active Directory / Azure AD – uczniowie logują się na konta ze standardowymi prawami użytkownika z zablokowaną możliwością instalacji oprogramowania i edycji rejestru.
  • W pracowniach sieciowych wdrożenie maszyn wirtualnych (np. VirtualBox/Hyper-V), w których uczniowie mogą posiadać prawa administratora wyłącznie wewnątrz odizolowanego wirtualnego systemu.
• Likwidację otwartego folderu „Skany”:
  • Konfiguracja skanera sieciowego do przesyłania plików bezpośrednio na indywidualne, szyfrowane skrzynki pocztowe pracowników kadr lub do folderu chronionego hasłem imiennym.
• Kwalifikacja ustaleń:
  • Wspólna podsieć pracowni uczniowskich i sekretariatu: Niezgodność Duża (NC1) – Załącznik A.8.22 ISO/IEC 27001.
  • Otwarty folder sieciowy ze skanami orzeczeń: Niezgodność Duża (NC1) – art. 9 i art. 32 RODO (szczególne kategorie danych).
  • Brak blokady instalacji oprogramowania w pracowniach: Niezgodność Mała (NC2) – Załącznika A.8.19 i A.5.15.

Zalety rozwiązania:

• Uniemożliwienie podsłuchiwania ruchu administracyjnego i przejmowania haseł dyrekcji przez uczniów.
• Zabezpieczenie danych wrażliwych uczniów o specjalnych potrzebach przed kompromitacją rówieśniczą.
• Zachowanie pełnych możliwości dydaktycznych na lekcjach informatyki dzięki zastosowaniu bezpiecznych maszyn wirtualnych.

Wady i trudności wdrożeniowe:

• Konieczność zakupu wydajnego firewalla UTM zdolnego do filtrowania ruchu dla 1 200 użytkowników kampusu.
• Opór nauczycieli informatyki przed koniecznością zarządzania maszynami wirtualnymi zamiast fizycznymi stacjami roboczymi.
• Niezadowolenie młodzieży w internacie z powodu wprowadzenia blokad na gry sieciowe i sieci torrent.

• Ustawa z dnia 14 grudnia 2016 r. – Prawo oświatowe (t.j. Dz.U. z 2026 r. poz. 820) – art. 68 ust. 1 pkt 12 (obowiązek dyrektora zapewnienia środków ochrony danych osobowych), art. 68 ust. 2 (skreślenie z listy uczniów) oraz art. 68 ust. 3 (przeniesienie do innej szkoły przez kuratora oświaty).
• Ustawa z dnia 10 maja 2018 r. o ochronie danych osobowych (RODO): art. 5 (minimalizacja i integralność), art. 9 (dane o stanie zdrowia małoletnich) oraz art. 32 (środki techniczne i organizacyjne); uzupełniająco art. 68 ust. 1 pkt 12 Prawa oświatowego.
• Norma PN-EN ISO/IEC 27001:2022 – Załącznik A: A.8.2 (Prawa dostępu uprzywilejowanego), A.8.19 (Instalacja oprogramowania na systemach operacyjnych), A.8.22 (Segregacja sieci).
• Standard NIST SP 800-145: The NIST Definition of Cloud Computing (modele wdrożeniowe dla edukacji).
• ENISA: Cybersecurity for SMEs – Challenges and Recommendations, Publications Office of the European Union, Luxembourg 2021 (raport nr ENISA-TR-2021-040) - https://www.enisa.europa.eu/publications/enisa-report-cybersecurity-for-smes

• W1 Ochrona tajemnicy zawodowej, informacji poufnych MAR oraz tajemnic przedsiębiorstw klientów.
• W2W3 Wymogi ISO/IEC 27001, rozporządzenia MAR oraz Ustawy o biegłych rewidentach.
• U1 Opracowanie zintegrowanej polityki bezpieczeństwa dla podmiotu zaufania finansowego.
• U2 Klasyfikacja uchybień formalnych i technologicznych (NC1/NC2/OFI).
• U3 Szacowanie ryzyka wycieku informacji cenotwórczych i odpowiedzialności cywilno-prawnej.
• K1K3 Bezwzględna etyka zawodowa, dyskrecja i niezależność audytorska.

Celem zadania na ocenę 4.0 jest zaprojektowanie zaawansowanego Systemu Zarządzania Bezpieczeństwem Informacji (SZBI) w renomowanej kancelarii audytorsko-doradczej badającej sprawozdania finansowe spółek giełdowych i korporacji międzynarodowych. Zadanie wymaga opracowania procedur ochrony tajemnicy zawodowej biegłego rewidenta i doradcy podatkowego, zabezpieczenia poufnych informacji cenotwórczych (zgodnie z rozporządzeniem MAR o przeciwdziałaniu nadużyciom na rynku), wdrożenia analizy ryzyka dla operacji chmurowych oraz opracowania matrycy niezgodności i planu CAP.

Kancelaria Audytorska „Vistula Audit & Tax Partners” sp. k. zatrudnia 40 biegłych rewidentów, doradców podatkowych i asystentów audytu. Kancelaria bada roczne sprawozdania finansowe 50 dużych spółek, w tym 8 spółek notowanych na Giełdzie Papierów Wartościowych w Warszawie (GPW). Zespoły audytowe spędzają 70% czasu pracy w siedzibach badanych klientów (praca mobilna na laptopach), badając bazy ERP, wyciągi bankowe, strategie fuzji i przejęć oraz dane o rentowności.

Audyt systemu bezpieczeństwa kancelarii ujawnił krytyczne luki:

• Ryzyko wycieku informacji poufnych MAR: Biegli rewidenci posiadają dostęp do wyników finansowych spółek giełdowych na 3 tygodnie przed ich oficjalną publikacją rynkową. Kancelaria nie prowadzi listy osób mających dostęp do informacji poufnych (tzw. Insider List), a asystenci audytu wymieniają się roboczymi arkuszami kalkulacyjnymi zawierającymi dane finansowe za pośrednictwem publicznych czatów na platformie WhatsApp.
• Praca mobilna u klienta: Podczas badań terenowych audytorzy pracują w salach konferencyjnych udostępnionych przez klientów. Zostawiają laptopy na biurkach bez blokowania ekranu w czasie przerw na lunch, a dokumentacja robocza (tzw. akta badania) przechowywana jest na nieszyfrowanych dyskach USB i przesyłana przez darmowe chmury prywatne (Dropbox).
• Niszczenie dokumentacji roboczej: Kopie wydruków z ksiąg rachunkowych badanych spółek, analizy ryzyka podatkowego oraz notatki ze spotkań z zarządami klientów wyrzucane są do zwykłych koszy na śmieci w biurze kancelarii bez użycia niszczarek dokumentów o odpowiedniej klasie tajności.
• Podwykonawcy i rotacja asystentów: Kancelaria zatrudnia studentów na 3-miesięczne umowy zlecenia w szczycie sezonu audytowego (styczeń-kwiecień). Studenci po zakończeniu umowy zachowują pełne kopie akt badania na swoich prywatnych laptopach, a umowy z nimi nie zawierają precyzyjnych kar umownych za naruszenie poufności.

• Krok 1 (Podział ról w zespole audytorskim):

Student 1 (Kierownik Zespołu): Projektuje Politykę Bezpieczeństwa Informacji Kancelarii, procedurę prowadzenia Rejestru Osób Posiadających Dostęp do Informacji Poufnych (zgodnie z MAR) oraz regulamin pracy mobilnej u klienta.

Student 2 (Specjalista ds. Bezpieczeństwa Cyfrowego): Opracowuje standardy bezpiecznej stacji roboczej (szyfrowanie dysków, blokada portów USB, bezpieczna chmura firmowa ze wspólnym szyfrowaniem akt badania) oraz wdrożenie bezpiecznego komunikatora korporacyjnego.

Student 3 (Audytor Zgodności i Ryzyka): Przeprowadza szacowanie ryzyka odpowiedzialności odszkodowawczej i karnej za naruszenie tajemnicy zawodowej w matrycy 3 × 3, klasyfikuje niezgodności (NC1/NC2/OFI) oraz opracowuje Plan CAP.

• Krok 2 (Analiza ryzyka naruszenia rozporządzenia MAR):

Oceńcie prawdopodobieństwo i skutki wycieku informacji o fuzji badanej spółki giełdowej (kary Komisji Nadzoru Finansowego do 20 mln PLN, odpowiedzialność karna do 5 lat pozbawienia wolności, utrata licencji biegłego rewidenta).

• Krok 3 (Kwalifikacja niezgodności ISO/IEC 27001):

Sformułujcie karty uchybień dla: braku szyfrowania akt badania (A.8.24), wyrzucania dokumentów do zwykłych koszy (A.7.14) oraz komunikacji przez WhatsApp (A.5.14).

• Krok 4 (Zasady niszczenia i retencji dokumentacji):

Zaprojektujcie procedurę postępowania z dokumentacją papierową zgodnie z normą DIN 66399 (poziom bezpieczeństwa P-4 dla tajemnic przedsiębiorstwa).

• Krok 5 (Plan CAP i RTP):

Dla każdej ustalonej niezgodności przygotujcie wpis w Planie Działań Korygujących (CAP): przyczyna źródłowa, działanie naprawcze, właściciel, termin (14–90 dni od daty audytu) i kryterium skuteczności. Następnie wypełnijcie Plan Postępowania z Ryzykiem (RTP): decyzja postępowania z ryzykiem (unikanie, redukcja, transfer albo akceptacja), działanie mitygujące, właściciel, termin i szacowane ryzyko rezydualne. Uzasadnienie decyzji o akceptacji ryzyka zapiszcie w raporcie.

Skala szacowania ryzyka (matryca 3 × 3): Prawdopodobieństwo (P): 1 – niskie, 2 – średnie, 3 – wysokie. Skutek (S): 1 – niski, 2 – poważny, 3 – krytyczny. Poziom ryzyka to iloczyn P × S (1–9). Wynik 6–9 oznacza strefę wysoką / niedopuszczalną, 3–4 strefę średnią, a 1–2 ryzyko akceptowalne. Tabele poniżej zawierają przykładowe karty ryzyka dla kluczowych aktywów jednostki.

Rejestr ustaleń audytowych z formalną gradacją: NC1 – Niezgodność Duża, NC2 – Niezgodność Mała, OFI – Szansa na poprawę.

Plan Działań Korygujących zawiera numer ustalenia, kwalifikację, analizę przyczyny źródłowej (Root Cause), działanie naprawcze, właściciela oraz harmonogram realizacji (14–90 dni).

Plan Postępowania z Ryzykiem (ang. Risk Treatment Plan, RTP) uzupełnia Plan Działań Korygujących: CAP odpowiada na pytanie co i kto naprawia, a RTP – jaką decyzją zarządcy świadomie redukują, przenoszą, unikają lub akceptują ryzyko. Każde ryzyko z matrycy powyżej musi mieć w RTP jedną, jawnie zapisaną decyzję; ryzyko pozostawione bez decyzji jest ryzykiem nieakceptowanym.

Do uzupełnienia: dla każdego zagrożenia z tabeli ryzyk wpiszcie klasyfikację (P × S), kwalifikację (NC1/NC2/OFI), wybraną decyzję postępowania, działanie mitygujące z odesłaniem do pozycji CAP, właściciela z terminem oraz szacowane ryzyko rezydualne. Poniżej wzór wypełniony dla jednego scenariusza – pozostałe wiersze uzupełnijcie sami.

• Unikanie ryzyka – eliminacja aktywności lub zmiana jej zakresu, np. wyłączenie publicznego dostępu do usługi.
• Redukcja (ograniczenie) – wdrożenie kontroli obniżających prawdopodobieństwo albo skutek; to decyzja dla większości ustaleń NC1 i NC2.
• Transfer (przeniesienie) – przeniesienie ryzyka na podmiot trzeci: umowa SLA, ubezpieczenie, gwarancja dostawcy, klauzule audytowe.
• Akceptacja ryzyka – świadome pozostawienie ryzyka przez organ zarządzający, z podaniem uzasadnienia, właściciela decyzji i terminu przeglądu.

Decyzja akceptacja wymaga pisemnego uzasadnienia w raporcie; samo wpisanie decyzji bez argumentu jest niewystarczające. Terminy w RTP muszą pokrywać się z terminami w CAP dla tych samych ustaleń.

Każdy raport rozpoczyna się od Executive Summary dla zarządu (ok. 1 strona): najważniejsze ustalenia z liczbą NC1 / NC2 / OFI, najwyższe ryzyko rezydualne, kluczowe decyzje podjęte w RTP oraz wniosek o zasoby i decyzję do podjęcia. Objętość raportu to 8–12 stron A4, a obrona koncepcji przed komisją trwa 15 minut. Executive Summary jest wymagane przez kryteria formalne zaliczenia na ocenę 4.0.

Studenci przygotowują profesjonalny raport audytowy (8–12 stron A4):

• Wprowadzenie: Tajemnica zawodowa biegłego rewidenta i doradcy podatkowego jako podstawa zaufania rynków kapitałowych.
• Diagnoza ryzyk w „Vistula Audit & Tax Partners”: Analiza konsekwencji prawnych, dyscyplinarnych i finansowych wycieku danych MAR.
• Matryca szacowania ryzyka utraty poufności i integralności akt badania.
• Kompleksowy projekt Polityki Bezpieczeństwa Informacji Kancelarii Audytorskiej:
  • Procedura zarządzania informacjami poufnymi rynku kapitałowego (MAR Insider Compliance).
  • Standard bezpiecznej pracy audytora w terenie (Field Audit Security Policy).
  • Polityka bezpiecznego niszczenia nośników i dokumentów papierowych (DIN 66399).
  • Procedura bezpiecznego onboardingu i offboardingu personelu sezonowego.
• Tabela klasyfikacji ustaleń (NC1, NC2, OFI) oraz Plan Działań Korygujących (CAP).
• Wnioski zarządcze: Zbudowanie przewagi rynkowej kancelarii w oparciu o certyfikację ISO/IEC 27001.

Wzorcowe rozwiązanie problemu obejmuje:

• Procedurę MAR i zarządzanie tajemnicą cenotwórczą:
  • Wdrożenie elektronicznego Rejestru Listy Insiderów – każdy audytor przypisany do badania spółki giełdowej podpisuje indywidualne zobowiązanie z klauzulą świadomości odpowiedzialności karnej z art. 180 i 181 ustawy o obrocie instrumentami finansowymi.
  • Bezwzględny zakaz korzystania z publicznych komunikatorów (WhatsApp, Messenger) – wdrożenie bezpiecznego komunikatora firmowego z szyfrowaniem end-to-end zarządzanego przez kancelarię.
• Standardy pracy audytora w terenie (Field Audit):
  • Wymóg pracy wyłącznie na laptopach służbowych z wymuszonym szyfrowaniem dysków (BitLocker 256-bit z kodem PIN przed uruchomieniem systemu).
  • Akta badania przechowywane wyłącznie w dedykowanej, szyfrowanej przestrzeni chmurowej kancelarii z kontrolą wersji i zakazem pobierania plików na prywatne nośniki USB.
  • Automatyczna blokada stacji roboczej po 2 minutach bezczynności oraz wymóg stosowania filtrów prywatyzujących na ekranach.
• Bezpieczne niszczenie dokumentów (DIN 66399):
  • Zakup bezpiecznych, zamykanych pojemników aluminiowych na dokumenty przeznaczone do zniszczenia oraz podpisanie umowy z certyfikowaną firmą utylizującą w klasie niszczenia min. P-4 / DIN 66399.
• Kwalifikacja ustaleń:
  • Brak listy insiderów MAR i przesyłanie danych przez WhatsApp: Niezgodność Duża (NC1) – bezpośrednie ryzyko sankcji KNF i naruszenie Załącznika A.5.14 ISO/IEC 27001.
  • Brak procedury niszczenia dokumentacji roboczej: Niezgodność Duża (NC1) – naruszenie Załącznika A.7.14.
  • Brak procedury czyszczenia laptopów asystentów po sezonie: Niezgodność Mała (NC2) – naruszenie Załącznika A.6.5.

Zalety rozwiązania:

• Zabezpieczenie partnerów kancelarii przed gigantycznymi karami finansowymi nakładanymi przez KNF i utratą prawa wykonywania zawodu.
• Gwarancja poufności dla badanych spółek giełdowych, co stanowi warunek konieczny do wygrywania intratnych zleceń audytorskich.
• Pełna kontrola nad obiegiem akt badania i wyeliminowanie ryzyka kradzieży dokumentacji przez konkurencję.

Wady i ograniczenia wdrożeniowe:

• Zwiększenie rygorów biurokratycznych dla audytorów (konieczność każdorazowego logowania do bezpiecznych repozytoriów).
• Koszt zakupu niszczarek wysokiej klasy lub abonamentu na bezpieczne pojemniki utylizacyjne.
• Konieczność wyposażenia wszystkich pracowników sezonowych w drogie laptopy służbowe na okres zaledwie 3–4 miesięcy.

• Rozporządzenie Parlamentu Europejskiego i Rady (UE) nr 596/2014 (Rozporządzenie MAR) – art. 14 (zakaz wykorzystywania informacji poufnej), art. 15 (zakaz manipulowania rynkiem), art. 18 (lista osób mających dostęp do informacji poufnej) oraz art. 19 (transakcje osoby pełniącej obowiązki zarządcze); właściwym organem nadzorczym w Polsce jest Komisja Nadzoru Finansowego (KNF).
• Ustawa z dnia 11 maja 2017 r. o biegłych rewidentach, firmach audytorskich oraz nadzorze publicznym (t.j. Dz.U. z 2025 r. poz. 1891) – art. 78 (tajemnica zawodowa) oraz art. 46 ust. 1 (dopuszczalne formy firmy audytorskiej).
• Norma PN-EN ISO/IEC 27001:2022 – Załącznik A: A.5.14 (Przekazywanie informacji), A.7.14 (Bezpieczne usuwanie lub ponowne użycie sprzętu), A.8.24 (Kryptografia).
• Norma DIN 66399 – Niszczenie nośników danych – Wymagania dotyczące urządzeń i procesów niszczenia.
• Wytyczne Polskiej Izby Biegłych Rewidentów (PIBR): „Zarządzanie bezpieczeństwem informacji w firmie audytorskiej”, Warszawa 2022.

• W1 Ochrona danych osobowych, numerów kart płatniczych i historii transakcji konsumenckich na wielką skalę.
• W2W3 Standard PCI DSS v4.0.1, wymogi dyrektywy (UE) 2019/2161 w zakresie ochrony praw konsumenta oraz ISO/IEC 27001.
• U1 Zaprojektowanie kompleksowej architektury bezpieczeństwa platformy chmurowej wysokiej dostępności (High Availability).
• U2 Identyfikacja i gradacja uchybień bezpieczeństwa (NC1/NC2/OFI).
• U3 Przeprowadzenie analizy ryzyka dla ataków sieciowych i nieautoryzowanego dostępu personelu.
• K2K3 Odpowiedzialność za stabilność i bezpieczeństwo obrotu gospodarczego w sieci.

Celem zadania na ocenę 4.0 jest opracowanie zaawansowanej Polityki Bezpieczeństwa Informacji dla dużej platformy handlu elektronicznego (E-commerce Marketplace) obsługującej miliony transakcji rocznie. Zadanie skupia się na zabezpieczeniu wielomilionowej bazy danych klientów i sprzedawców, architekturze odpornej na ataki typu DDoS i przejęcia kont (Credential Stuffing), zarządzaniu dostępami opartym na rolach (RBAC) w rozproszonych centrach logistycznych oraz wdrożeniu rygorów standardu bezpieczeństwa płatności PCI DSS.

Platforma handlowa „MegaMarket24.pl” skupia 2,5 miliona zarejestrowanych kupujących oraz 15 000 niezależnych sprzedawców (sklepów partnerskich). Platforma przetwarza średnio 50 000 zamówień na dobę, generując roczny obrót rzędu 800 mln PLN. Firma zatrudnia 180 pracowników w centrali (działy: IT, DevSecOps, Marketing, Finanse, BOK, Zgodność) oraz korzysta z 3 zewnętrznych centrów logistycznych (Fulfillment Partners). Środowisko IT działa w architekturze chmury hybrydowej (AWS + własne serwery kolokowane).

W toku audytu bezpieczeństwa ujawniono następujące luki o wysokim stopniu krytyczności:

• Podatność na ataki Credential Stuffing i brak ochrony API: Hakerzy wykorzystują boty do masowego testowania loginów i haseł pochodzących z wycieków z innych portali. W ciągu miesiąca przejęto ponad 1 200 kont klientów, z których dokonano wyłudzenia towarów na kwotę 350 000 PLN. Publiczne API platformy nie posiadało mechanizmu ograniczania liczby zapytań (Rate Limiting) ani zabezpieczenia bot protection (CAPTCHA/WAF).
• Dostęp pracowników BOK do danych kartowych: Mimo że płatności realizowane są przez zewnętrznego integratora, konsultanci infolinii technicznej mają wgląd w pełne logi transakcyjne, w których w plikach tekstowych przez pomyłkę zapisywane były pierwsze 12 cyfr numeru karty (PAN) oraz nazwiska posiadaczy kart, co stanowi bezpośrednie naruszenie standardu PCI DSS.
• Integracje ze sklepami partnerskimi przez klucze API: Sprzedawcy zewnętrzni integrują swoje magazyny z platformą za pomocą stałych kluczy API generowanych w panelu sprzedawcy. Klucze te nie posiadają terminu wygaśnięcia, nie są rotowane, a w razie podejrzenia kradzieży brak jest procedury natychmiastowego ich unieważnienia.
• Dostęp podwykonawców magazynowych: Pracownicy zewnętrznych firm magazynowych mają dostęp do aplikacji wysyłkowej ze wspólnego tabletu magazynowego bez konieczności imiennego logowania, co uniemożliwia ustalenie, kto wygenerował fałszywą etykietę adresową.

• Krok 1 (Podział ról w zespole audytorskim):

Student 1 (Kierownik Zespołu i Specjalista PCI DSS): Definiuje nadrzędną Politykę Bezpieczeństwa E-commerce, procedury ochrony danych posiadaczy kart płatniczych (PCI DSS) oraz standardy zarządzania tożsamością kupujących i sprzedawców.

Student 2 (Inżynier DevSecOps i Bezpieczeństwa Chmury): Projektuje architekturę ochrony przed botami i atakami DDoS (WAF, Rate Limiting, ochrona API), mechanizmy bezpiecznej rotacji kluczy API oraz centralne logowanie zdarzeń (SIEM).

Student 3 (Audytor Ryzyka i Reagowania na Incydenty): Przeprowadza szacowanie ryzyka dla ataku Credential Stuffing i kradzieży środków w matrycy 3 × 3, klasyfikuje niezgodności (NC1/NC2/OFI) oraz opracowuje Plan Reagowania na Incydenty (Incident Response Plan) i tabelę CAP.

• Krok 2 (Analiza ryzyka i scenariusz ataku):

Wyliczcie ryzyko finansowe i reputacyjne wynikające ze zmasowanego ataku botów przejmujących konta klientów i oszustw zakupowych. Oszacujcie prawdopodobieństwo (P) i skutek (S) przed i po wdrożeniu zabezpieczeń.

• Krok 3 (Kwalifikacja niezgodności PCI DSS i ISO/IEC 27001):

Sformułujcie karty ustaleń:

• Rejestrowanie danych kartowych w logach (PCI DSS wymóg 3.2 oraz ISO Załącznik A.8.11 - maskowanie danych).
• Brak Rate Limitingu i ochrony botnetowej na API (ISO Załącznik A.8.26).
• Brak imiennego logowania w magazynach partnerskich (ISO Załącznik A.5.16).

Opracujcie ścieżkę naprawczą z terminami natychmiastowymi (24–48 h na wyłączenie logowania PAN), średnimi (30 dni na WAF) i długoterminowymi (90 dni na pełny audyt PCI DSS).

• Krok 4 (Plan CAP i RTP):

Dla każdej ustalonej niezgodności przygotujcie wpis w Planie Działań Korygujących (CAP): przyczyna źródłowa, działanie naprawcze, właściciel, termin (14–90 dni od daty audytu) i kryterium skuteczności. Następnie wypełnijcie Plan Postępowania z Ryzykiem (RTP): decyzja postępowania z ryzykiem (unikanie, redukcja, transfer albo akceptacja), działanie mitygujące, właściciel, termin i szacowane ryzyko rezydualne. Uzasadnienie decyzji o akceptacji ryzyka zapiszcie w raporcie.

Skala szacowania ryzyka (matryca 3 × 3): Prawdopodobieństwo (P): 1 – niskie, 2 – średnie, 3 – wysokie. Skutek (S): 1 – niski, 2 – poważny, 3 – krytyczny. Poziom ryzyka to iloczyn P × S (1–9). Wynik 6–9 oznacza strefę wysoką / niedopuszczalną, 3–4 strefę średnią, a 1–2 ryzyko akceptowalne. Tabele poniżej zawierają przykładowe karty ryzyka dla kluczowych aktywów jednostki.

Rejestr ustaleń audytowych z formalną gradacją: NC1 – Niezgodność Duża, NC2 – Niezgodność Mała, OFI – Szansa na poprawę.

Plan Działań Korygujących zawiera numer ustalenia, kwalifikację, analizę przyczyny źródłowej (Root Cause), działanie naprawcze, właściciela oraz harmonogram realizacji (14–90 dni).

Plan Postępowania z Ryzykiem (ang. Risk Treatment Plan, RTP) uzupełnia Plan Działań Korygujących: CAP odpowiada na pytanie co i kto naprawia, a RTP – jaką decyzją zarządcy świadomie redukują, przenoszą, unikają lub akceptują ryzyko. Każde ryzyko z matrycy powyżej musi mieć w RTP jedną, jawnie zapisaną decyzję; ryzyko pozostawione bez decyzji jest ryzykiem nieakceptowanym.

Do uzupełnienia: dla każdego zagrożenia z tabeli ryzyk wpiszcie klasyfikację (P × S), kwalifikację (NC1/NC2/OFI), wybraną decyzję postępowania, działanie mitygujące z odesłaniem do pozycji CAP, właściciela z terminem oraz szacowane ryzyko rezydualne. Poniżej wzór wypełniony dla jednego scenariusza – pozostałe wiersze uzupełnijcie sami.

• Unikanie ryzyka – eliminacja aktywności lub zmiana jej zakresu, np. wyłączenie publicznego dostępu do usługi.
• Redukcja (ograniczenie) – wdrożenie kontroli obniżających prawdopodobieństwo albo skutek; to decyzja dla większości ustaleń NC1 i NC2.
• Transfer (przeniesienie) – przeniesienie ryzyka na podmiot trzeci: umowa SLA, ubezpieczenie, gwarancja dostawcy, klauzule audytowe.
• Akceptacja ryzyka – świadome pozostawienie ryzyka przez organ zarządzający, z podaniem uzasadnienia, właściciela decyzji i terminu przeglądu.

Decyzja akceptacja wymaga pisemnego uzasadnienia w raporcie; samo wpisanie decyzji bez argumentu jest niewystarczające. Terminy w RTP muszą pokrywać się z terminami w CAP dla tych samych ustaleń.

Każdy raport rozpoczyna się od Executive Summary dla zarządu (ok. 1 strona): najważniejsze ustalenia z liczbą NC1 / NC2 / OFI, najwyższe ryzyko rezydualne, kluczowe decyzje podjęte w RTP oraz wniosek o zasoby i decyzję do podjęcia. Objętość raportu to 8–12 stron A4, a obrona koncepcji przed komisją trwa 15 minut. Executive Summary jest wymagane przez kryteria formalne zaliczenia na ocenę 4.0.

Studenci opracowują rozbudowany raport audytowy (8–12 stron A4):

• Wprowadzenie: E-commerce wielkiej skali – wyzwania cyberbezpieczeństwa na styku chmury, konsumentów i łańcucha logistycznego.
• Diagnoza podatności „MegaMarket24.pl”: Szczegółowa analiza incydentu przejęcia 1 200 kont i naruszeń PCI DSS.
• Matryca analizy ryzyka dla procesów transakcyjnych i interfejsów API.
• Zaawansowany projekt Polityki Bezpieczeństwa Informacji Platformy E-commerce:
  • Standard ochrony API i przeciwdziałania botom (WAF, CAPTCHA adaptacyjna, Rate Limiting).
  • Polityka zgodności z PCI DSS (zakaz rejestrowania danych kartowych, maskowanie PAN).
  • Procedura bezpiecznego cyklu życia kluczy API dla sprzedawców (automatyczna rotacja co 90 dni).
  • Wymogi bezpieczeństwa dla centrów logistycznych i podwykonawców magazynowych.
• Rejestr niezgodności (NC1/NC2/OFI) oraz Plan Działań Korygujących (CAP).
• Podsumowanie: Wpływ wdrożonych kontroli na redukcję wskaźnika fraudów (chargeback) i budowę zaufania kupujących.

Wzorcowe rozwiązanie problemu na ocenę 4.0 zawiera:

• Wdrożenie zaawansowanej ochrony antybotowej i API:
  • Implementacja chmurowego systemu Web Application Firewall (WAF) z modułem Bot Management, analizującym sygnatury i zachowanie użytkowników (analiza behawioralna).
  • Wdrożenie mechanizmu Rate Limiting na endpointach logowania i składania zamówień (np. max 5 prób na minutę z jednego IP/fingerprintu).
  • Wymuszenie wieloskładnikowego uwierzytelniania (2FA) dla wszystkich kont sprzedawców oraz opcjonalnego (z zachętami rabatowymi) dla kupujących.
• Oczyszczenie logów i zgodność z PCI DSS:
  • Natychmiastowe usunięcie logów zawierających numery kart oraz modyfikacja konfiguracji aplikacji w celu maskowania numerów kart (wyświetlanie wyłącznie formatu BIN + 4 ostatnie cyfry: 1234 56XX XXXX 7890).
  • Wdrożenie automatycznego skanera kodu (SAST) wykrywającego zapisywanie danych poufnych w logach w potoku CI/CD.
• Cykl życia kluczy API:
  • Wprowadzenie wymogu tworzenia kluczy API z ograniczonymi uprawnieniami (Scoping) oraz obowiązkową datą ważności (maksymalnie 180 dni) z powiadomieniem o konieczności rotacji na 14 dni przed wygaśnięciem.
• Kwalifikacja ustaleń:
  • Zapisywanie danych kartowych w logach: Niezgodność Duża (NC1) – rażące naruszenie standardu PCI DSS v4.0 pkt 3.2 oraz art. 32 RODO.
  • Podatność na Credential Stuffing z powodu braku WAF: Niezgodność Duża (NC1) – Załącznik A.8.20 i A.8.26 ISO/IEC 27001.
  • Brak rotacji kluczy API sprzedawców: Niezgodność Mała (NC2) – Załącznika A.8.24.

Zalety rozwiązania:

• Zredukowanie strat finansowych z tytułu wyłudzeń towarów i opłat chargeback o ponad 95%.
• Ochrona platformy przed karami organizacji płatniczych (Visa, Mastercard) sięgającymi 100 000 USD miesięcznie za naruszenia PCI DSS.
• Zwiększenie zaufania konsumentów dzięki skutecznej ochronie ich tożsamości i kont zakupowych.

Wady i ograniczenia wdrożeniowe:

• Koszt subskrypcji zaawansowanych reguł WAF i inspekcji botów w chmurze AWS/Cloudflare.
• Ryzyko odrzucenia części transakcji legalnych użytkowników (False Positives) przy zbyt agresywnej konfiguracji filtrów antybotowych.
• Konieczność dostosowania oprogramowania przez 15 000 sprzedawców zewnętrznych do nowej polityki rotacji kluczy API.

• Standard PCI DSS v4.0 (Payment Card Industry Data Security Standard) – wymagania 3, 6, 8 i 10.
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2019/2161 (Dyrektywa Omnibus) – ochrona praw konsumentów w handlu cyfrowym.
• Rozporządzenie RODO: art. 32 (środki techniczne i organizacyjne), art. 33 (zgłaszanie wycieków).
• Norma PN-EN ISO/IEC 27001:2022 – Załącznik A: A.8.10 (Usuwanie informacji), A.8.20 (Bezpieczeństwo sieci), A.8.26 (Wymagania bezpieczeństwa aplikacji).
• Wytyczne OWASP: OWASP Automated Threats to Web Applications (OAT-008 Credential Stuffing).

• W1 Ochrona tajemnicy bankowej, danych transakcyjnych i stabilności płynnościowej.
• W2W3 Wymogi Rozporządzenia DORA (wraz z rozporządzeniem delegowanym (UE) 2025/301) i obowiązującej Rekomendacji M KNF oraz normy ISO/IEC 27001.
• U1 Opracowanie zintegrowanej ramy zarządzania ryzykiem ICT dla instytucji finansowej.
• U2 Kwalifikacja niezgodności regulacyjnych i operacyjnych (NC1/NC2/OFI).
• U3 Przeprowadzenie analizy ryzyka łańcucha dostawców ICT i wyliczenie wskaźników odporności.
• K2K3 Świadomość odpowiedzialności za stabilność finansową lokalnej społeczności.

Celem zadania na ocenę 4.0 jest zaprojektowanie zaawansowanej Polityki Bezpieczeństwa Informacji dla Regionalnego Banku Spółdzielczego zrzeszającego centralę oraz sieć 10 oddziałów lokalnych. Zadanie uwzględnia rygorystyczne wymagania unijnego Rozporządzenia DORA (Digital Operational Resilience Act) wraz z rozporządzeniem delegowanym (UE) 2025/301 (terminy zgłaszania istotnych incydentów ICT), zasady zarządzania ryzykiem podmiotów trzecich (Third-Party Risk Management) oraz obowiązki z zakresu testowania odporności operacyjnej. Wytyczne Rekomendacji D KNF z 2013 r. zostały wycofane i nie stanowią już podstawy wymogów.

Regionalny Bank Spółdzielczy „Prosperita” posiada centralę w mieście powiatowym oraz 10 placówek filialnych na terenie dwóch województw. Bank obsługuje 60 000 klientów, prowadzi rachunki samorządów lokalnych oraz zarządza portfelem kredytowym o wartości 1,2 mld PLN. W banku pracuje 140 osób. Infrastruktura ICT opiera się na centralnym systemie bankowym (Core Banking) utrzymywanym w zewnętrznym centrum danych przez dostawcę oprogramowania, bankowości internetowej i mobilnej w chmurze oraz sieci WAN łączącej wszystkie placówki.

Audyt zgodności z Rozporządzeniem DORA wykazał następujące uchybienia:

• Zależność od pojedynczego dostawcy ICT (Vendor Lock-in): Główny system transakcyjny oraz bankowość mobilna są w całości hostowane u jednego dostawcy chmurowego. Bank nie posiada alternatywnego planu wyjścia (Exit Strategy), a umowa z dostawcą nie gwarantuje audytorom banku ani KNF prawa do przeprowadzenia niezależnego audytu na miejscu w serwerowni dostawcy.
• Procedura testowania odporności na incydenty ICT: Bank nigdy nie przeprowadził testów penetracyjnych (TLPT - Threat-Led Penetration Testing) ani symulacji przełączenia na zapasowe łącza telekomunikacyjne w filiach. Podczas rutynowej awarii światłowodu u operatora telekomunikacyjnego 4 filie banku były odcięte od systemów transakcyjnych przez 14 godzin.
• Zarządzanie dostępem uprzywilejowanym (PAM): Administratorzy sieci w banku oraz serwisanci zewnętrzni logują się na serwery bazodanowe ze wspólnego konta serwisowego „root_admin” z hasłem znanym 12 osobom, bez rejestracji sesji i bez wymuszenia logowania przez dedykowany serwer pośredniczący (Bastion Host / PAM).
• Incydenty w filiach lokalnych: W dwóch małych filiach banku stwierdzono, że routery brzegowe łączące filię z centralą posiadają fabryczne hasła dostępowe, a szafy teletechniczne stoją otwarte na korytarzu obok toalety dla klientów.

• Krok 1 (Podział ról w zespole audytorskim):

Student 1 (Kierownik Zespołu i Specjalista DORA): Definiuje nadrzędną Politykę Bezpieczeństwa Informacji Banku, ramy zarządzania ryzykiem operacyjnym ICT oraz strategię wyjścia z umów outsourcingowych (Exit Strategy).

Student 2 (Inżynier ds. Bezpieczeństwa Systemów Bankowych): Opracowuje architekturę Privileged Access Management (PAM), zasady redundancji łączy WAN (SD-WAN / LTE Backup) oraz bezpieczną konfigurację urządzeń brzegowych w filiach.

Student 3 (Audytor Zgodności Regulacyjnej i Ryzyka KNF): Przeprowadza szacowanie ryzyka ciągłości działania w matrycy 3 × 3, klasyfikuje niezgodności z DORA i Rekomendacją D KNF oraz tworzy Plan Działań Korygujących (CAP).

• Krok 2 (Analiza ryzyka outsourcingu ICT):

Oceńcie w matrycy 3 × 3 prawdopodobieństwo i skutki:

• Bankructwa lub ataku ransomware na kluczowego dostawcę chmurowego systemu Core Banking.
• Przejęcia routera w filii lokalnej i podsłuchania danych klientów.

• Krok 3 (Gradacja uchybień wg DORA i Rekomendacji D KNF):

Dokonajcie gradacji uchybień:

• Brak prawa do audytu w umowie z dostawcą chmury (Rozporządzenie DORA art. 30).
• Wspólne konto root_admin bez MFA i logowania sesji (art. 9 i art. 10 DORA).
• Otwarte szafy teletechniczne w filiach (Załącznik A.7.1 ISO/IEC 27001).

Zaprojektujcie plan naprawczy z terminami renegocjacji umów dostawczych i wdrożenia systemu PAM.

• Krok 4 (Plan CAP i RTP):

Dla każdej ustalonej niezgodności przygotujcie wpis w Planie Działań Korygujących (CAP): przyczyna źródłowa, działanie naprawcze, właściciel, termin (14–90 dni od daty audytu) i kryterium skuteczności. Następnie wypełnijcie Plan Postępowania z Ryzykiem (RTP): decyzja postępowania z ryzykiem (unikanie, redukcja, transfer albo akceptacja), działanie mitygujące, właściciel, termin i szacowane ryzyko rezydualne. Uzasadnienie decyzji o akceptacji ryzyka zapiszcie w raporcie.

Skala szacowania ryzyka (matryca 3 × 3): Prawdopodobieństwo (P): 1 – niskie, 2 – średnie, 3 – wysokie. Skutek (S): 1 – niski, 2 – poważny, 3 – krytyczny. Poziom ryzyka to iloczyn P × S (1–9). Wynik 6–9 oznacza strefę wysoką / niedopuszczalną, 3–4 strefę średnią, a 1–2 ryzyko akceptowalne. Tabele poniżej zawierają przykładowe karty ryzyka dla kluczowych aktywów jednostki.

Rejestr ustaleń audytowych z formalną gradacją: NC1 – Niezgodność Duża, NC2 – Niezgodność Mała, OFI – Szansa na poprawę.

Plan Działań Korygujących zawiera numer ustalenia, kwalifikację, analizę przyczyny źródłowej (Root Cause), działanie naprawcze, właściciela oraz harmonogram realizacji (14–90 dni).

Plan Postępowania z Ryzykiem (ang. Risk Treatment Plan, RTP) uzupełnia Plan Działań Korygujących: CAP odpowiada na pytanie co i kto naprawia, a RTP – jaką decyzją zarządcy świadomie redukują, przenoszą, unikają lub akceptują ryzyko. Każde ryzyko z matrycy powyżej musi mieć w RTP jedną, jawnie zapisaną decyzję; ryzyko pozostawione bez decyzji jest ryzykiem nieakceptowanym.

Do uzupełnienia: dla każdego zagrożenia z tabeli ryzyk wpiszcie klasyfikację (P × S), kwalifikację (NC1/NC2/OFI), wybraną decyzję postępowania, działanie mitygujące z odesłaniem do pozycji CAP, właściciela z terminem oraz szacowane ryzyko rezydualne. Poniżej wzór wypełniony dla jednego scenariusza – pozostałe wiersze uzupełnijcie sami.

• Unikanie ryzyka – eliminacja aktywności lub zmiana jej zakresu, np. wyłączenie publicznego dostępu do usługi.
• Redukcja (ograniczenie) – wdrożenie kontroli obniżających prawdopodobieństwo albo skutek; to decyzja dla większości ustaleń NC1 i NC2.
• Transfer (przeniesienie) – przeniesienie ryzyka na podmiot trzeci: umowa SLA, ubezpieczenie, gwarancja dostawcy, klauzule audytowe.
• Akceptacja ryzyka – świadome pozostawienie ryzyka przez organ zarządzający, z podaniem uzasadnienia, właściciela decyzji i terminu przeglądu.

Decyzja akceptacja wymaga pisemnego uzasadnienia w raporcie; samo wpisanie decyzji bez argumentu jest niewystarczające. Terminy w RTP muszą pokrywać się z terminami w CAP dla tych samych ustaleń.

Każdy raport rozpoczyna się od Executive Summary dla zarządu (ok. 1 strona): najważniejsze ustalenia z liczbą NC1 / NC2 / OFI, najwyższe ryzyko rezydualne, kluczowe decyzje podjęte w RTP oraz wniosek o zasoby i decyzję do podjęcia. Objętość raportu to 8–12 stron A4, a obrona koncepcji przed komisją trwa 15 minut. Executive Summary jest wymagane przez kryteria formalne zaliczenia na ocenę 4.0.

Studenci przygotowują profesjonalny raport audytowy (8–12 stron A4):

• Wprowadzenie: Rewolucja Rozporządzenia DORA w europejskim sektorze bankowym – odporność operacyjna jako wymóg przetrwania.
• Diagnoza ryzyk w Regionalnym Banku Spółdzielczym „Prosperita”: Zagrożenia łańcucha dostaw ICT, braku redundancji i kont uprzywilejowanych.
• Matryca oceny ryzyka ICT dla kluczowych procesów bankowych (Core Banking, bankowość elektroniczna, rozliczenia ELIXIR).
• Zaawansowany projekt Polityki Bezpieczeństwa Informacji i Odporności Cyfrowej:
  • Procedura zarządzania ryzykiem dostawców zewnętrznych ICT (Third-Party Risk Management).
  • Polityka kontroli dostępu uprzywilejowanego (PAM / Bastion Host).
  • Standard zabezpieczenia infrastruktury teleinformatycznej w oddziałach i filiach.
  • Plan testowania ciągłości działania i awaryjnego przełączania łączy (Disaster Recovery).
• Rejestr niezgodności (NC1/NC2/OFI) oraz Plan Działań Korygujących (CAP).
• Podsumowanie: Korzyści ze spełnienia wymogów DORA w relacjach z bankiem zrzeszającym i KNF.

Wzorcowa polityka bankowa na ocenę 4.0 wprowadza:

• Zarządzanie ryzykiem podmiotów trzecich (DORA):
  • Wprowadzenie do każdej umowy z dostawcą ICT pełnego katalogu postanowień wymaganych przez art. 30 ust. 1–3 DORA: zapewnienie podmiotowi nadzorowanemu i KNF prawa do przeprowadzania audytu (także na miejscu), obowiązek niezwłocznego informowania o incydentach ICT zgodnie z art. 19–20 DORA, prawo do wypowiedzenia umowy i asygnowania danych, prawo wstępu podmiotów trzecich oraz obowiązek corocznego przedstawiania raportu SOC 2 Typ II lub certyfikatu ISO/IEC 27001. Uwaga: DORA nie przewiduje odrębnej „standardowej klauzuli umownej” - wiążące klauzule umowne dotyczące przekazywania danych osobowych wynikają z art. 46 ust. 2 lit. c RODO i decyzji Komisji (UE) 2021/914.
  • Opracowanie formalnej Strategii Wyjścia (Exit Plan) określającej możliwość migracji baz danych do alternatywnego centrum przetwarzania w uzgodnionym umownie terminie, nie dłuższym niż 90 dni.
• Wdrożenie systemu zarządzania dostępem uprzywilejowanym (PAM):
  • Całkowita likwidacja współdzielonych kont administracyjnych.
  • Wdrożenie rozwiązania PAM (Privileged Access Management) – każda sesja administracyjna wymaga logowania indywidualnego z MFA, hasła są rotowane automatycznie w sejfie haseł po każdym wylogowaniu, a cała sesja jest nagrywana w formacie wideo.
• Zabezpieczenie sieci WAN i placówek:
  • Wdrożenie technologii SD-WAN z automatycznym przełączaniem na łącze zapasowe LTE/5G w każdej z 10 filii (czas przełączenia < 5 sekund).
  • Wymiana szaf teletechnicznych w filiach na szafy zamykane z czujnikami sabotażowymi (tamper) i podpięciem pod system alarmowy.
• Kwalifikacja ustaleń:
  • Brak klauzul audytowych i planu wyjścia w umowie chmurowej: Niezgodność Duża (NC1) – bezpośrednie naruszenie art. 28 i 30 Rozporządzenia DORA.
  • Wspólne konto root_admin bez rozliczalności: Niezgodność Duża (NC1) – naruszenie Rekomendacji D KNF pkt 11.2 oraz Załącznika A.8.2 ISO/IEC 27001.
  • Brak agregacji łączy w filiach: Niezgodność Mała (NC2) – naruszenie Załącznika A.8.14.

Zalety rozwiązania:

• Pełna zgodność prawna z Rozporządzeniem DORA i Rekomendacją D KNF, co chroni Zarząd przed sankcjami administracyjnymi i odpowiedzialnością odszkodowawczą zarządu.
• Gwarancja ciągłości obsługi mieszkańców w 10 filiach nawet w przypadku zerwania głównego światłowodu.
• Pełna rozliczalność działań administratorów i dostawców zewnętrznych na krytycznych bazach bankowych.

Wady i ograniczenia wdrożeniowe:

• Bardzo wysoki koszt zakupu i wdrożenia rozwiązania klasy PAM oraz licencji SD-WAN.
• Trudne i długotrwałe negocjacje aneksów umownych z dominującymi dostawcami oprogramowania bankowego.
• Konieczność zatrudnienia dodatkowego inżyniera bezpieczeństwa w centrali banku.

• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 z dnia 14 grudnia 2022 r. w sprawie operacyjnej odporności cyfrowej sektora finansowego (Rozporządzenie DORA).
• Wytyczne KNF dotyczące zarządzania obszarami technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego w bankach (2013) - w obowiązującym stanie prawnym zastąpione Rekomendacją D KNF (styczeń 2013). DORA stosuje się wraz z rozporządzeniem delegowanym Komisji (UE) 2025/301 (treść i terminy zgłoszeń poważnych incydentów ICT, art. 6) oraz rozporządzeniem wykonawczym Komisji (UE) 2025/302 (wzory formularzy).
• Rekomendacja D KNF dotycząca zarządzania obszarami technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego w bankach (styczeń 2013) - obowiązująca.
• Rekomendacja M KNF dotycząca zarządzania ryzykiem operacyjnym w bankach (styczeń 2013) - obowiązująca.
• Norma PN-EN ISO/IEC 27001:2022 – Załącznik A: A.5.19 (Bezpieczeństwo w relacjach z dostawcami), A.8.2 (Prawa dostępu uprzywilejowanego), A.8.14 (Redundancja systemów informatycznych).
• Standard EBA Guidelines on ICT and security risk management (EBA/GL/2019/04).

• W1 Ochrona własności przemysłowej, rysunków CAD i tajemnicy prototypów.
• W2W3 Wymogi standardu TISAX (VDA ISA 6.0.3), normy IEC 62443 (bezpieczeństwo automatyki) oraz ISO/IEC 27001.
• U1 Opracowanie zintegrowanej polityki dla środowiska mieszanego IT/OT.
• U2 Kwalifikacja uchybień w sieciach przemysłowych i kontroli stref prototypowych.
• U3 Szacowanie ryzyka przestoju linii produkcyjnej i kar umownych za zerwanie łańcucha dostaw.
• K2K3 Zrozumienie wagi dyscypliny operacyjnej w międzynarodowym przemyśle produkcyjnym.

Celem zadania na ocenę 4.0 jest opracowanie zaawansowanej Polityki Bezpieczeństwa Informacji dla średniej wielkości przedsiębiorstwa produkcyjnego branży motoryzacyjnej (Tier 1 Supplier) produkującego komponenty elektroniczne dla koncernów samochodowych. Zadanie koncentruje się na specyfice zbiegu środowisk IT (biurowego) i OT (Operational Technology - automatyka przemysłowa, roboty, linie produkcyjne, sterowniki PLC), wymaganiach standardu TISAX (Trusted Information Security Assessment Exchange), ochronie tajemnicy prototypów przemysłowych oraz procedurach ciągłości dostaw w modelu Just-in-Time.

Zakład produkcyjny „AutoMech Components” sp. z o.o. zatrudnia 450 pracowników i produkuje moduły sterowania silnikiem dla trzech wiodących marek motoryzacyjnych w Niemczech i Szwecji. Fabryka pracuje w trybie ciągłym (4 brygady, 24/7), dostarczając podzespoły w reżimie Just-in-Time (opóźnienie dostawy powyżej 4 godzin oznacza karę umowną w wysokości 50 000 EUR za każdą godzinę przestoju taśmy montażowej u klienta). Środowisko techniczne składa się ze 120 komputerów biurowych (CAD, ERP, zakupy) oraz 8 w pełni zautomatyzowanych linii produkcyjnych opartych na sterownikach PLC Siemens i robotach KUKA.

W trakcie audytu certyfikacyjnego TISAX zidentyfikowano następujące uchybienia:

• Brak izolacji sieci przemysłowej (OT) od sieci biurowej (IT): Sterowniki PLC linii produkcyjnej i roboty przemysłowe pracują w tej samej przestrzeni adresowej IP co komputery działu marketingu i kadr. Z komputera biurowego można bezpośrednio połączyć się z panelem operatorskim HMI sterującym parametrami zgrzewania części samochodowych bez autoryzacji.
• Sterowniki PLC ze starym oprogramowaniem: Sterowniki linii produkcyjnych posiadają znane luki podatnościowe na ataki sieciowe (np. protokół Modbus/TCP i Profinet bez szyfrowania i uwierzytelniania). Do portów USB sterowników technicy podłączają prywatne laptopy diagnostyczne.
• Strefa ochrony prototypów: W hali fabrycznej wygrodzono strefę montażu prototypowych części do nowego modelu pojazdu elektrycznego (premiera rynkowa za 18 miesięcy). Wygrodzenie stanowi zwykła siatka druciana o wysokości 1,8 m, bez osłon optycznych, a pracownicy i goście swobodnie robią zdjęcia smartfonami z odległości 3 metrów.
• Dostęp serwisowy producentów maszyn: Dostawcy maszyn produkcyjnych posiadają stałe łącza modemowe 4G/LTE wpięte bezpośrednio w szafy sterownicze na hali, z pominięciem jakiejkolwiek kontroli zapory sieciowej przedsiębiorstwa (tzw. Shadow IT / niekontrolowane tylne furtki).

• Krok 1 (Podział ról w zespole audytorskim):

Student 1 (Kierownik Zespołu i Specjalista TISAX): Definiuje nadrzędną Politykę Bezpieczeństwa Informacji Przedsiębiorstwa, politykę ochrony prototypów i tajemnicy fabrycznej oraz procedury TISAX (poziom AL 3 - wysoka ochrona).

Student 2 (Inżynier Bezpieczeństwa IT/OT): Opracowuje architekturę stref bezpieczeństwa wg normy IEC 62443 (Model Purdue), separację sieci IT/OT za pomocą przemysłowego firewalla DMZ oraz procedurę bezpiecznego zdalnego serwisu maszyn.

Student 3 (Audytor Ciągłości Działania i Ryzyka Just-in-Time): Przeprowadza szacowanie ryzyka paraliżu linii produkcyjnej w matrycy 3 × 3, kalkuluje straty z kar umownych, klasyfikuje niezgodności (NC1/NC2/OFI) oraz opracowuje Plan CAP.

• Krok 2 (Analiza Modelu Purdue i szacowanie ryzyka):

Rozrysujcie podział na poziomy: Poziom 4/5 (Sieć korporacyjna IT), Poziom 3.5 (Przemysłowe DMZ), Poziom 3 (Zarządzanie operacjami OT/SCADA), Poziom 1/2 (Sterowniki PLC i roboty).

Oszacujcie ryzyko infekcji sieci OT złośliwym oprogramowaniem z komputera biurowego i zatrzymania fabryki na 24 godziny.

• Krok 3 (Kwalifikacja niezgodności TISAX i ISO/IEC 27001):

Przypiszcie uchybienia do wymagań katalogu VDA ISA oraz normy ISO 27001:

• Brak separacji IT/OT (Niezgodność Duża NC1).
• Brak fizycznej ochrony strefy prototypów (Niezgodność Duża NC1 - blokada poziomu AL 3 w TISAX).
• Niekontrolowane modemy 4G w szafach sterowniczych (Niezgodność Duża NC1).

Zaprojektujcie harmonogram wdrożenia prac modernizacyjnych bez konieczności zatrzymywania ciągłej produkcji fabryki (prace podczas planowanych postojów technologicznych).

• Krok 4 (Plan CAP i RTP):

Dla każdej ustalonej niezgodności przygotujcie wpis w Planie Działań Korygujących (CAP): przyczyna źródłowa, działanie naprawcze, właściciel, termin (14–90 dni od daty audytu) i kryterium skuteczności. Następnie wypełnijcie Plan Postępowania z Ryzykiem (RTP): decyzja postępowania z ryzykiem (unikanie, redukcja, transfer albo akceptacja), działanie mitygujące, właściciel, termin i szacowane ryzyko rezydualne. Uzasadnienie decyzji o akceptacji ryzyka zapiszcie w raporcie.

Skala szacowania ryzyka (matryca 3 × 3): Prawdopodobieństwo (P): 1 – niskie, 2 – średnie, 3 – wysokie. Skutek (S): 1 – niski, 2 – poważny, 3 – krytyczny. Poziom ryzyka to iloczyn P × S (1–9). Wynik 6–9 oznacza strefę wysoką / niedopuszczalną, 3–4 strefę średnią, a 1–2 ryzyko akceptowalne. Tabele poniżej zawierają przykładowe karty ryzyka dla kluczowych aktywów jednostki.

Rejestr ustaleń audytowych z formalną gradacją: NC1 – Niezgodność Duża, NC2 – Niezgodność Mała, OFI – Szansa na poprawę.

Plan Działań Korygujących zawiera numer ustalenia, kwalifikację, analizę przyczyny źródłowej (Root Cause), działanie naprawcze, właściciela oraz harmonogram realizacji (14–90 dni).

Plan Postępowania z Ryzykiem (ang. Risk Treatment Plan, RTP) uzupełnia Plan Działań Korygujących: CAP odpowiada na pytanie co i kto naprawia, a RTP – jaką decyzją zarządcy świadomie redukują, przenoszą, unikają lub akceptują ryzyko. Każde ryzyko z matrycy powyżej musi mieć w RTP jedną, jawnie zapisaną decyzję; ryzyko pozostawione bez decyzji jest ryzykiem nieakceptowanym.

Do uzupełnienia: dla każdego zagrożenia z tabeli ryzyk wpiszcie klasyfikację (P × S), kwalifikację (NC1/NC2/OFI), wybraną decyzję postępowania, działanie mitygujące z odesłaniem do pozycji CAP, właściciela z terminem oraz szacowane ryzyko rezydualne. Poniżej wzór wypełniony dla jednego scenariusza – pozostałe wiersze uzupełnijcie sami.

• Unikanie ryzyka – eliminacja aktywności lub zmiana jej zakresu, np. wyłączenie publicznego dostępu do usługi.
• Redukcja (ograniczenie) – wdrożenie kontroli obniżających prawdopodobieństwo albo skutek; to decyzja dla większości ustaleń NC1 i NC2.
• Transfer (przeniesienie) – przeniesienie ryzyka na podmiot trzeci: umowa SLA, ubezpieczenie, gwarancja dostawcy, klauzule audytowe.
• Akceptacja ryzyka – świadome pozostawienie ryzyka przez organ zarządzający, z podaniem uzasadnienia, właściciela decyzji i terminu przeglądu.

Decyzja akceptacja wymaga pisemnego uzasadnienia w raporcie; samo wpisanie decyzji bez argumentu jest niewystarczające. Terminy w RTP muszą pokrywać się z terminami w CAP dla tych samych ustaleń.

Każdy raport rozpoczyna się od Executive Summary dla zarządu (ok. 1 strona): najważniejsze ustalenia z liczbą NC1 / NC2 / OFI, najwyższe ryzyko rezydualne, kluczowe decyzje podjęte w RTP oraz wniosek o zasoby i decyzję do podjęcia. Objętość raportu to 8–12 stron A4, a obrona koncepcji przed komisją trwa 15 minut. Executive Summary jest wymagane przez kryteria formalne zaliczenia na ocenę 4.0.

Studenci przygotowują rozbudowany raport audytowy (8–12 stron A4):

• Wprowadzenie: Standard TISAX i specyfika bezpieczeństwa w erze Przemysłu 4.0 (Industry 4.0).
• Diagnoza ryzyk w „AutoMech Components”: Podatności na styku IT/OT, luki w strefie prototypów i nieautoryzowane modemy serwisowe.
• Matryca szacowania ryzyka przestoju produkcyjnego i utraty kontraktów OEM.
• Projekt Zintegrowanej Polityki Bezpieczeństwa Informacji IT/OT:
  • Architektura strefowa Purdue Model (segmentacja sieci przemysłowej i przemysłowe DMZ).
  • Polityka fizycznej ochrony prototypów i zakazu fotografowania (Clean Factory / No-Camera Policy).
  • Procedura bezpiecznego dostępu serwisowego dla dostawców maszyn (Secure Remote Maintenance).
  • Polityka zabezpieczenia nośników USB na hali produkcyjnej (kioski sanitarne).
• Rejestr niezgodności (NC1/NC2/OFI) oraz Plan Działań Korygujących (CAP).
• Wnioski i harmonogram audytu certyfikacyjnego TISAX.

Wzorcowa koncepcja na ocenę 4.0 wprowadza:

• Wdrożenie architektury bezpieczeństwa przemysłowego wg IEC 62443:
  • Wprowadzenie Przemysłowej Strefy Zdemilitaryzowanej (IDMZ) pomiędzy siecią biurową a halą produkcyjną.
  • Całkowity zakaz bezpośredniego routingu pomiędzy IT i OT – komunikacja wyłącznie za pośrednictwem serwerów proxy i serwerów skoku (Jump Host) w IDMZ z inspekcją protokołów przemysłowych.
  • Likwidacja niekontrolowanych modemów 4G dostawców maszyn – zdalny serwis realizowany wyłącznie przez centralny tunel VPN z uwierzytelnianiem MFA i autoryzacją kierownika utrzymania ruchu.
• Rygorystyczne zabezpieczenie strefy prototypów (TISAX AL 3):
  • Wzniesienie pełnych ścian nieprzeziernych o wysokości do sufitu hali wokół strefy prototypów.
  • Montaż kontroli dostępu opartej na biometrii lub kartach szyfrowanych Mifare DESFire wyłącznie dla dedykowanego zespołu inżynierów.
  • Bezwzględny zakaz wnoszenia smartfonów i aparatów fotograficznych do strefy (depozytory przy wejściu) oraz montaż detektorów obiektywów kamer.
• Bezpieczeństwo nośników USB (Stacje Kwarantanny):
  • Zablokowanie bezpośredniego wpinania pendrive do sterowników PLC – wdrożenie Stacji Sanitarnej (kiosku antywirusowego z 3 silnikami skanującymi), na której każdy nośnik przed użyciem musi zostać sprawdzony i zautoryzowany.
• Kwalifikacja ustaleń:
  • Bezpośrednie połączenie IT z OT: Niezgodność Duża (NC1) – Załącznik A.8.22 ISO/IEC 27001 oraz VDA ISA pkt 5.1.
  • Niezabezpieczona strefa prototypów: Niezgodność Duża (NC1) – VDA ISA moduł Prototype Protection.
  • Brak kontroli nad dostępem serwisowym producentów: Niezgodność Duża (NC1) – Załącznik A.5.19 i A.8.20.

Zalety rozwiązania:

• Uzyskanie certyfikatu TISAX na poziomie AL 3, co stanowi bezwzględny warunek utrzymania wielomilionowych kontraktów z koncernami samochodowymi.
• Ochrona fabryki przed sabotażem i złośliwym oprogramowaniem przemysłowym (typu Stuxnet, Industroyer) paraliżującym linie produkcyjne.
• Całkowite wyeliminowanie ryzyka wycieku zdjęć prototypowych pojazdów do prasy motoryzacyjnej.

Wady i ograniczenia wdrożeniowe:

• Bardzo wysokie koszty budowy ścian wydzielających strefę prototypów oraz wdrożenia przemysłowych zapór sieciowych (szacowane na 300 000 – 600 000 PLN).
• Skomplikowanie procedury serwisowej i wydłużenie czasu reakcji serwisantów zagranicznych w przypadku awarii nocnej.
• Drobne spowolnienie pracy technologów zmuszonych do każdorazowego skanowania pamięci USB na stacji sanitarnej.

• Standard VDA ISA w wersji 6.0.3 / TISAX (Information Security Assessment of the German Automotive Industry Association).
• Norma PN-EN IEC 62443: Bezpieczeństwo systemów automatyki przemysłowej i sterowania (Industrial Network and System Security) – części 2-1 i 3-3.
• Norma PN-EN ISO/IEC 27001:2022 – Załącznik A: A.7.1 (Obszary bezpieczne), A.8.20 (Bezpieczeństwo sieci), A.8.22 (Segregacja sieci).
• Dyrektywa NIS2 – sektor produkcji i łańcucha dostaw jako podmiot ważny/kluczowy.
• Wytyczne Agencji Unii Europejskiej ds. Cyberbezpieczeństwa (ENISA): „Good Practices for Security of IoT and Industrial Automation in Manufacturing”, 2022.

• W1 Ochrona tajemnic klientów bankowych, algorytmów scoringowych i tokenów uwierzytelniających.
• W2W3 Wymogi ISO/IEC 27001 Załącznik A.8.25, A.8.26, A.8.28, A.8.29 i A.8.31 (bezpieczny cykl rozwoju), standardy OWASP SAMM oraz wytyczne EBA.
• U1 Opracowanie polityki DevSecOps dla nowoczesnego środowiska chmurowego.
• U2 Kwalifikacja uchybień w procesie wydawania oprogramowania i zarządzania kontenerami.
• U3 Przeprowadzenie analizy ryzyka podatności łańcucha dostaw oprogramowania (biblioteki Open Source).
• K1K3 Etyka inżynierska i odpowiedzialność za bezpieczeństwo milionów transakcji finansowych.

Celem zadania na ocenę 4.0 jest zaprojektowanie zaawansowanej Polityki Bezpieczeństwa Informacji dla Software House'u tworzącego systemy płatnicze, aplikacje bankowe i rozwiązania klasy FinTech w chmurze natywnej (Cloud-Native). Zadanie skupia się na bezpieczeństwie potoku automatycznego wytwarzania oprogramowania (CI/CD), zarządzaniu podatnościami komponentów Open Source (Software Supply Chain Security - SBOM), architekturze mikroserwisowej opartej na orkiestracji kontenerów (Kubernetes) oraz wdrożeniu kultury DevSecOps i audytowalności kodu.

Firma „FinTech Logic” sp. z o.o. zatrudnia 80 inżynierów oprogramowania, inżynierów DevOps, testerów i architektów chmurowych. Firma rozwija platformę bankowości otwartej (Open Banking API) przetwarzającą transakcje dla 12 banków komercyjnych w Europie Środkowej. Aplikacje budowane są w oparciu o architekturę mikrousługową w klastrach Kubernetes w chmurze AWS i Google Cloud Platform (GCP). Wdrożenia na produkcję odbywają się automatycznie do 10 razy dziennie za pośrednictwem potoku GitLab CI/CD.

W toku audytu bezpieczeństwa ujawniono krytyczne podatności techniczne i organizacyjne:

• Brak weryfikacji bibliotek Open Source (Software Supply Chain Vulnerability): Programiści bez ograniczeń pobierają z publicznych repozytoriów (npm, Maven, PyPI) setki bibliotek zewnętrznych. W jednej z kluczowych bibliotek autoryzacyjnych wykryto podatność krytyczną (CVSS 9.8) umożliwiającą zdalne wykonanie kodu (RCE), która znajdowała się na środowisku produkcyjnym przez 5 miesięcy z powodu braku oprogramowania do skanowania zależności (SCA). Firma nie generuje wykazu komponentów oprogramowania (SBOM).
• Dostęp do klastra produkcyjnego Kubernetes: Wszyscy programiści posiadają pełne uprawnienia administratorskie (cluster-admin) do produkcyjnego klastra Kubernetes, z prawem do wglądu w sekrety, klucze szyfrujące i bazy transakcyjne. Dostęp odbywa się za pomocą jednego wspólnego pliku konfiguracyjnego kubeconfig przesyłanego na Slacku.
• Brak separacji środowisk w potoku CI/CD: Agenci wykonawczy potoku CI/CD (GitLab Runners) mają bezpośredni dostęp do bazy produkcyjnej, a błędy w skryptach wdrożeniowych spowodowały nadpisanie fragmentu tabeli bazy produkcyjnej danymi testowymi.
• Logowanie w kontenerach: Kontenery aplikacji rejestrują w logach systemowych nagłówki zapytań HTTP zawierające w jawnym tekście tokeny JWT (JSON Web Token) autoryzujące płatności klientów banków, a logi te są indeksowane w ogólnodostępnym narzędziu Kibana bez kontroli uprawnień.

• Krok 1 (Podział ról w zespole audytorskim):

Student 1 (Kierownik Zespołu i Architekt DevSecOps): Definiuje Politykę Bezpiecznego Cyklu Życia Rozwoju Oprogramowania (SSDLC), procedury generowania Software Bill of Materials (SBOM) oraz zasady zarządzania podatnościami zgodnie z OWASP SAMM.

Student 2 (Inżynier Bezpieczeństwa Chmury i Kontenerów): Opracowuje twardnienie klastra Kubernetes (Kubernetes Hardening wg CIS Benchmarks), wdrożenie kontroli dostępu RBAC, separację potoków CI/CD oraz centralne zarządzanie sekretami (HashiCorp Vault).

Student 3 (Audytor Zgodności i Analizy Ryzyka): Przeprowadza szacowanie ryzyka ataku na łańcuch dostaw oprogramowania w matrycy 3 × 3, klasyfikuje niezgodności (NC1/NC2/OFI) oraz opracowuje Plan CAP z bramkami jakościowymi (Quality Gates).

• Krok 2 (Analiza ryzyka łańcucha dostaw oprogramowania):

Wyliczcie ryzyko wprowadzenia złośliwego kodu przez przejętą bibliotekę open-source (scenariusz typu Log4j lub SolarWinds). Oszacujcie wpływ na reputację banków oraz na kary regulacyjne nakładane w tym przypadku przez Komisję Nadzoru Finansowego (EBA nie nakłada kar pieniężnych; jej decyzje indywidualne w trybie art. 8 ust. 2 lit. f rozporządzenia (UE) nr 1093/2010 są środkiem ostatniej instancji).

• Krok 3 (Kwalifikacja niezgodności ISO/IEC 27001):

Dokonajcie formalnej gradacji:

• Wspólny plik kubeconfig i cluster-admin dla każdego (Niezgodność Duża NC1 - Załącznik A.8.2).
• Brak skanowania SCA i podatność krytyczna na produkcji (Niezgodność Duża NC1 - Załącznik A.8.8 i A.8.28).
• Tokeny JWT w jawnym tekście w logach Kibana (Niezgodność Duża NC1 - Załącznik A.8.24 i A.8.28).

Zaprojektujcie 4 bramki kontrolne w potoku CI/CD: SAST (analiza statyczna kodu), SCA (analiza komponentów open-source), DAST (dynamiczne testy bezpieczeństwa API) oraz Container Scanning.

• Krok 4 (Plan CAP i RTP):

Dla każdej ustalonej niezgodności przygotujcie wpis w Planie Działań Korygujących (CAP): przyczyna źródłowa, działanie naprawcze, właściciel, termin (14–90 dni od daty audytu) i kryterium skuteczności. Następnie wypełnijcie Plan Postępowania z Ryzykiem (RTP): decyzja postępowania z ryzykiem (unikanie, redukcja, transfer albo akceptacja), działanie mitygujące, właściciel, termin i szacowane ryzyko rezydualne. Uzasadnienie decyzji o akceptacji ryzyka zapiszcie w raporcie.

Skala szacowania ryzyka (matryca 3 × 3): Prawdopodobieństwo (P): 1 – niskie, 2 – średnie, 3 – wysokie. Skutek (S): 1 – niski, 2 – poważny, 3 – krytyczny. Poziom ryzyka to iloczyn P × S (1–9). Wynik 6–9 oznacza strefę wysoką / niedopuszczalną, 3–4 strefę średnią, a 1–2 ryzyko akceptowalne. Tabele poniżej zawierają przykładowe karty ryzyka dla kluczowych aktywów jednostki.

Rejestr ustaleń audytowych z formalną gradacją: NC1 – Niezgodność Duża, NC2 – Niezgodność Mała, OFI – Szansa na poprawę.

Plan Działań Korygujących zawiera numer ustalenia, kwalifikację, analizę przyczyny źródłowej (Root Cause), działanie naprawcze, właściciela oraz harmonogram realizacji (14–90 dni).

Plan Postępowania z Ryzykiem (ang. Risk Treatment Plan, RTP) uzupełnia Plan Działań Korygujących: CAP odpowiada na pytanie co i kto naprawia, a RTP – jaką decyzją zarządcy świadomie redukują, przenoszą, unikają lub akceptują ryzyko. Każde ryzyko z matrycy powyżej musi mieć w RTP jedną, jawnie zapisaną decyzję; ryzyko pozostawione bez decyzji jest ryzykiem nieakceptowanym.

Do uzupełnienia: dla każdego zagrożenia z tabeli ryzyk wpiszcie klasyfikację (P × S), kwalifikację (NC1/NC2/OFI), wybraną decyzję postępowania, działanie mitygujące z odesłaniem do pozycji CAP, właściciela z terminem oraz szacowane ryzyko rezydualne. Poniżej wzór wypełniony dla jednego scenariusza – pozostałe wiersze uzupełnijcie sami.

• Unikanie ryzyka – eliminacja aktywności lub zmiana jej zakresu, np. wyłączenie publicznego dostępu do usługi.
• Redukcja (ograniczenie) – wdrożenie kontroli obniżających prawdopodobieństwo albo skutek; to decyzja dla większości ustaleń NC1 i NC2.
• Transfer (przeniesienie) – przeniesienie ryzyka na podmiot trzeci: umowa SLA, ubezpieczenie, gwarancja dostawcy, klauzule audytowe.
• Akceptacja ryzyka – świadome pozostawienie ryzyka przez organ zarządzający, z podaniem uzasadnienia, właściciela decyzji i terminu przeglądu.

Decyzja akceptacja wymaga pisemnego uzasadnienia w raporcie; samo wpisanie decyzji bez argumentu jest niewystarczające. Terminy w RTP muszą pokrywać się z terminami w CAP dla tych samych ustaleń.

Każdy raport rozpoczyna się od Executive Summary dla zarządu (ok. 1 strona): najważniejsze ustalenia z liczbą NC1 / NC2 / OFI, najwyższe ryzyko rezydualne, kluczowe decyzje podjęte w RTP oraz wniosek o zasoby i decyzję do podjęcia. Objętość raportu to 8–12 stron A4, a obrona koncepcji przed komisją trwa 15 minut. Executive Summary jest wymagane przez kryteria formalne zaliczenia na ocenę 4.0.

Studenci przygotowują profesjonalny raport audytowy (8–12 stron A4):

• Wprowadzenie: DevSecOps w erze Cloud-Native – jak tworzyć oprogramowanie finansowe odporne na ataki nowej generacji.
• Diagnoza ryzyk w „FinTech Logic”: Szczegółowa analiza luk w łańcuchu dostaw oprogramowania, klastrze Kubernetes i logach transakcyjnych.
• Matryca oceny ryzyka kompromitacji platformy bankowości otwartej.
• Zaawansowany projekt Polityki Bezpieczeństwa Informacji i Bezpiecznego Wytwarzania Kodu (SSDLC):
  • Architektura bramek bezpieczeństwa w potoku CI/CD (SAST, SCA, DAST, SBOM).
  • Standard twardnienia i zarządzania uprawnieniami w Kubernetes (CIS Benchmark, OPA Gatekeeper).
  • Polityka bezpiecznego zarządzania sekretami i tokenami (Vault, rotacja kluczy).
  • Standard logowania transakcyjnego i maskowania danych uwierzytelniających (JWT Masking).
• Rejestr niezgodności (NC1/NC2/OFI) oraz Plan Działań Korygujących (CAP).
• Podsumowanie: Przejście od tradycyjnego bezpieczeństwa do zautomatyzowanego Security-as-Code.

Wzorcowa koncepcja na ocenę 4.0 wprowadza:

• Automatyzację bezpieczeństwa w potoku CI/CD (DevSecOps):
  • Wdrożenie narzędzia SCA (np. Snyk, Dependabot, Trivy) z polityką automatycznego blokowania wdrożenia (Build Breaker), jeśli w bibliotece zewnętrznej wykryta zostanie luka o CVSS >= 7.0.
  • Obowiązek automatycznego generowania i podpisywania cyfrowego wykazu komponentów CycloneDX / SPDX (SBOM) dla każdego wydania produkcyjnego.
• Twardnienie środowiska kontenerowego Kubernetes:
  • Odebranie uprawnień cluster-admin – wdrożenie ścisłego modelu RBAC (Role-Based Access Control) zintegrowanego z tożsamością imienną inżyniera w Azure AD / Okta. Programiści posiadają dostęp wyłącznie do logów na środowisku deweloperskim.
  • Wdrożenie polityk bezpieczeństwa Podów (Pod Security Standards) – zakaz uruchamiania kontenerów z uprawnieniami roota (mustRunAsNonRoot) oraz zakaz montowania systemowych katalogów hosta.
• Zabezpieczenie logów transakcyjnych i tokenów:
  • Modyfikacja middleware aplikacji w celu automatycznego wycinania lub maskowania nagłówków Authorization przed wysłaniem logu do bazy Elasticsearch/Kibana.
  • Wdrożenie scentralizowanego menedżera sekretów HashiCorp Vault z dynamicznymi tokenami wygasającymi po 1 godzinie.
• Kwalifikacja ustaleń:
  • Wszystkie trzy główne uchybienia zakwalifikowano jako Niezgodności Duże (NC1), ponieważ ich zbieg stwarza bezpośrednie zagrożenie kradzieży środków klientów banków za pośrednictwem przejęcia tokenów płatniczych.

Zalety rozwiązania:

• Zabezpieczenie platformy FinTech przed atakami na łańcuch dostaw oprogramowania i kompromitacją kont bankowych.
• Spełnienie obowiązujących wytycznych Europejskiego Urzędu Nadzoru Bankowego (EBA/GL/2019/04, obowiązujących od 20 maja 2025 r.) oraz normy ISO/IEC 27001 - Załącznik A, przy realnym ryzyku sankcji administracyjnych Komisji Nadzoru Finansowego (art. 156 ust. 1 ustawy Prawo bankowe: grzywna, kara pieniężna, ograniczenie działalności, zakaz wykonywania działalności).
• Zautomatyzowanie procesu audytu kodu bez konieczności ręcznego testowania każdego wydania.

Wady i ograniczenia wdrożeniowe:

• Początkowe spowolnienie tempa wydań oprogramowania (zablokowanie wdrożeń przez wykryte podatności w starych bibliotekach).
• Konieczność gruntownego przeszkolenia 80 programistów w zakresie bezpiecznego kodowania i obsługi nowych narzędzi DevSecOps.
• Koszty subskrypcji narzędzi skanujących i platformy zarządzania sekretami w chmurze.

• Norma PN-EN ISO/IEC 27001:2022 – Załącznik A: A.8.25 (Bezpieczny cykl rozwoju), A.8.28 (Bezpieczne kodowanie), A.8.29 (Testy bezpieczeństwa), A.8.31 (Separacja środowisk rozwoju, testowych i produkcyjnych).
• Wytyczne Europejskiego Urzędu Nadzoru Bankowego (EBA/GL/2019/04) dotyczące zarządzania ryzykiem technologii informacyjno-komunikacyjnych i bezpieczeństwa - obowiązujące od 20 maja 2025 r.; wytyczne EBA/GL/2017/11 dotyczące ładu korporacyjnego; wytyczne o zgłaszaniu incydentów na podstawie dyrektywy PSD2 uchylone 17 stycznia 2025 r. w związku ze stosowaniem DORA.
• Standard OWASP Software Assurance Maturity Model (SAMM) v2.0.
• CIS Kubernetes Benchmark v2.0.1 (Center for Internet Security) – wytyczne twardnienia klastrów.
• Wytyczne NIST SP 800-204: Security Strategies for Microservices-based Application Systems.

• W1 Ochrona danych osobowych czytelników, pracowników naukowych i baz bibliograficznych.
• W2W3 Wymogi Rozporządzenia KRI, ustawy o prawie autorskim oraz standardów ISO/IEC 27001 i ISO/IEC 27005.
• U1 Opracowanie polityki dla instytucji o zbieżnym profilu publiczno-naukowym.
• U2 Kwalifikacja niezgodności w zakresie ochrony zasobów cyfrowych i publicznych punktów dostępu.
• U3 Przeprowadzenie analizy ryzyka utraty cyfrowych kopii dziedzictwa kulturowego w matrycy 3 × 3.
• K2K3 Wrażliwość na ochronę dziedzictwa kulturowego i promowanie bezpiecznego korzystania z wiedzy.

Celem zadania na ocenę 4.0 jest opracowanie zaawansowanej Polityki Bezpieczeństwa Informacji dla dużej wojewódzkiej instytucji kultury i nauki, pełniącej funkcję centralnego węzła regionalnej sieci bibliotecznej. Zadanie koncentruje się na pogodzeniu szerokiego dostępu publicznego (otwarte czytelnie, bazy naukowe, digitalizacja starodruków, sieć eduroam) z ochroną unikalnych zbiorów dziedzictwa narodowego w repozytoriach cyfrowych, przeciwdziałaniem naruszeniom praw autorskich, bezpieczeństwem serwerów bazodanowych zintegrowanego systemu bibliotecznego oraz spełnieniem wymogów Krajowych Ram Interoperacyjności.

Wojewódzka Biblioteka Publiczna i Centrum Informacji Naukowej obsługuje 120 000 zarejestrowanych użytkowników, koordynuje pracę 150 bibliotek gminnych w regionie oraz prowadzi Wojewódzką Bibliotekę Cyfrową udostępniającą 500 000 zdigitalizowanych cennych manuskryptów, map i starodruków. Instytucja zatrudnia 110 pracowników i dysponuje gmachem z 6 czytelniami specjalistycznymi, salą konferencyjną oraz 80 publicznymi terminalami komputerowymi. Przez sieć bezprzewodową eduroam i publiczną sieć Wi-Fi dziennie przewija się ponad 1 500 studentów i badaczy.

Audyt systemu bezpieczeństwa wykazał następujące uchybienia:

• Brak bezpiecznej retencji i integralności repozytorium cyfrowego: Zdigitalizowane zabytki piśmiennictwa o nieocenionej wartości historycznej (pliki TIFF o objętości 180 TB) przechowywane są na pojedynczej macierzy dyskowej NAS bez sum kontrolnych (hash SHA-256) chroniących przed cichym uszkodzeniem danych (bit rot) oraz bez zapasowej kopii georendundantnej.
• Nadużycia w otwartej sieci eduroam i Wi-Fi: Odnotowano przypadki wykorzystywania publicznych komputerów czytelni naukowej do masowego pobierania płatnych artykułów z licencjonowanych baz naukowych (Elsevier, Springer, IEEE) za pomocą zautomatyzowanych skryptów (scraperów). Doprowadziło to do zablokowania dostępu do baz naukowych dla całego województwa przez międzynarodowych wydawców z powodu naruszenia umów licencyjnych.
• Podatności systemu bibliotecznego (ILS): Zintegrowany system biblioteczny obsługujący wypożyczenia i dane osobowe czytelników (PESEL, adresy, historia lektur) posiada panel internetowy czytelnika z podatnością SQL Injection, która nie została załatana od 14 miesięcy z powodu braku umowy wsparcia technicznego (SLA) z dostawcą oprogramowania.
• Fizyczny dostęp do skanerów zabytków: Pracownia digitalizacji zbiorów cennych mieści się w pomieszczeniu z drzwiami na zwykły zamek mechaniczny. Klucze pobierają z portierni także pracownicy firmy sprzątającej i stażyści bez ewidencji, a w pracowni na biurkach leżą unikalne rękopisy z XVII wieku.

• Krok 1 (Podział ról w zespole audytorskim):

Student 1 (Kierownik Zespołu): Projektuje nadrzędną Politykę Bezpieczeństwa Informacji Biblioteki Wojewódzkiej, regulamin ochrony zbiorów cyfrowych oraz zasady korzystania z licencjonowanych zasobów naukowych.

Student 2 (Specjalista ds. Bezpieczeństwa Sieci i Repozytoriów): Opracowuje architekturę integralności repozytorium cyfrowego (sumy kontrolne, macierz WORM, georedundancja), segmentację sieci eduroam oraz wdrożenie ochrony przed scrapingiem baz danych (WAF, Rate Limiting).

Student 3 (Audytor Zgodności KRI i Ryzyka): Przeprowadza analizę ryzyka utraty dziedzictwa narodowego w matrycy 3 × 3, kwalifikuje uchybienia (NC1/NC2/OFI) oraz opracowuje Plan CAP z uwzględnieniem procedur przetargowych w sektorze publicznym.

• Krok 2 (Analiza ryzyka utraty zasobów cyfrowych):

Wyliczcie w matrycy 3 × 3 ryzyko uszkodzenia lub zaszyfrowania bazy Biblioteki Cyfrowej oraz ryzyka kar finansowych od wydawców baz naukowych.

• Krok 3 (Kwalifikacja niezgodności KRI i ISO/IEC 27001):

Przypiszcie uchybienia do norm i prawa:

• Podatność SQL Injection w panelu czytelnika (Niezgodność Duża NC1 - § 19 ust. 2 pkt 12 lit. f-g KRI i Załącznik A.8.26).
• Brak kopii georedundantnej i sum kontrolnych zbiorów (Niezgodność Duża NC1 - Załącznik A.8.13 i A.8.14).
• Brak kontroli dostępu do pracowni digitalizacji starodruków (Niezgodność Duża NC1 - Załącznik A.7.2).

Zredagujcie plan naprawczy uwzględniający natychmiastowe załatanie luki SQLi, wdrożenie reguł anty-scrapingowych oraz wniosek do Urzędu Marszałkowskiego o dotację na georedundantny backup.

• Krok 4 (Plan CAP i RTP):

Dla każdej ustalonej niezgodności przygotujcie wpis w Planie Działań Korygujących (CAP): przyczyna źródłowa, działanie naprawcze, właściciel, termin (14–90 dni od daty audytu) i kryterium skuteczności. Następnie wypełnijcie Plan Postępowania z Ryzykiem (RTP): decyzja postępowania z ryzykiem (unikanie, redukcja, transfer albo akceptacja), działanie mitygujące, właściciel, termin i szacowane ryzyko rezydualne. Uzasadnienie decyzji o akceptacji ryzyka zapiszcie w raporcie.

Skala szacowania ryzyka (matryca 3 × 3): Prawdopodobieństwo (P): 1 – niskie, 2 – średnie, 3 – wysokie. Skutek (S): 1 – niski, 2 – poważny, 3 – krytyczny. Poziom ryzyka to iloczyn P × S (1–9). Wynik 6–9 oznacza strefę wysoką / niedopuszczalną, 3–4 strefę średnią, a 1–2 ryzyko akceptowalne. Tabele poniżej zawierają przykładowe karty ryzyka dla kluczowych aktywów jednostki.

Rejestr ustaleń audytowych z formalną gradacją: NC1 – Niezgodność Duża, NC2 – Niezgodność Mała, OFI – Szansa na poprawę.

Plan Działań Korygujących zawiera numer ustalenia, kwalifikację, analizę przyczyny źródłowej (Root Cause), działanie naprawcze, właściciela oraz harmonogram realizacji (14–90 dni).

Plan Postępowania z Ryzykiem (ang. Risk Treatment Plan, RTP) uzupełnia Plan Działań Korygujących: CAP odpowiada na pytanie co i kto naprawia, a RTP – jaką decyzją zarządcy świadomie redukują, przenoszą, unikają lub akceptują ryzyko. Każde ryzyko z matrycy powyżej musi mieć w RTP jedną, jawnie zapisaną decyzję; ryzyko pozostawione bez decyzji jest ryzykiem nieakceptowanym.

Do uzupełnienia: dla każdego zagrożenia z tabeli ryzyk wpiszcie klasyfikację (P × S), kwalifikację (NC1/NC2/OFI), wybraną decyzję postępowania, działanie mitygujące z odesłaniem do pozycji CAP, właściciela z terminem oraz szacowane ryzyko rezydualne. Poniżej wzór wypełniony dla jednego scenariusza – pozostałe wiersze uzupełnijcie sami.

• Unikanie ryzyka – eliminacja aktywności lub zmiana jej zakresu, np. wyłączenie publicznego dostępu do usługi.
• Redukcja (ograniczenie) – wdrożenie kontroli obniżających prawdopodobieństwo albo skutek; to decyzja dla większości ustaleń NC1 i NC2.
• Transfer (przeniesienie) – przeniesienie ryzyka na podmiot trzeci: umowa SLA, ubezpieczenie, gwarancja dostawcy, klauzule audytowe.
• Akceptacja ryzyka – świadome pozostawienie ryzyka przez organ zarządzający, z podaniem uzasadnienia, właściciela decyzji i terminu przeglądu.

Decyzja akceptacja wymaga pisemnego uzasadnienia w raporcie; samo wpisanie decyzji bez argumentu jest niewystarczające. Terminy w RTP muszą pokrywać się z terminami w CAP dla tych samych ustaleń.

Każdy raport rozpoczyna się od Executive Summary dla zarządu (ok. 1 strona): najważniejsze ustalenia z liczbą NC1 / NC2 / OFI, najwyższe ryzyko rezydualne, kluczowe decyzje podjęte w RTP oraz wniosek o zasoby i decyzję do podjęcia. Objętość raportu to 8–12 stron A4, a obrona koncepcji przed komisją trwa 15 minut. Executive Summary jest wymagane przez kryteria formalne zaliczenia na ocenę 4.0.

Studenci przygotowują rozbudowany raport audytowy (8–12 stron A4):

• Wprowadzenie: Ochrona dziedzictwa kulturowego i wolności nauki w erze cyfrowej – wyzwania dla bibliotek naukowych.
• Diagnoza ryzyk w Wojewódzkiej Bibliotece Publicznej: Analiza luki SQL Injection, zagrożeń integralności repozytorium i naruszeń licencji naukowych.
• Matryca oceny ryzyka dla repozytoriów cyfrowych i systemów e-usług bibliotecznych.
• Zaawansowany projekt Polityki Bezpieczeństwa Informacji Instytucji Kultury i Nauki:
  • Procedura weryfikacji integralności i ochrony długoterminowej archiwaliów cyfrowych (OAIS / WORM).
  • Regulamin bezpiecznego dostępu do licencjonowanych baz naukowych i przeciwdziałania scrapingowi.
  • Standardy bezpieczeństwa publicznych terminali i sieci bezprzewodowej eduroam.
  • Procedura fizycznego i środowiskowego zabezpieczenia pracowni digitalizacji zbiorów zabytkowych.
• Rejestr niezgodności (NC1/NC2/OFI) oraz Plan Działań Korygujących (CAP).
• Wnioski i rekomendacje dotyczące pozyskania funduszy na cyberbezpieczeństwo kultury.

Wzorcowa koncepcja na ocenę 4.0 wprowadza:

• Zabezpieczenie i weryfikację integralności repozytorium cyfrowego:
  • Wdrożenie automatycznego generowania i okresowej weryfikacji sum kontrolnych SHA-256 dla wszystkich 500 000 zdigitalizowanych obiektów w celu przeciwdziałania degradacji nośników (Bit Rot).
  • Zastosowanie reguły 3-2-1: Główna macierz produkcyjna, lokalna kopia w technologii WORM (Write Once Read Many) oraz georedundantna kopia w chmurze akademickiej PIONIER.
• Załatanie luki SQL Injection i wdrożenie WAF:
  • Pilny zakup wsparcia technicznego i wdrożenie poprawki bezpieczeństwa likwidującej podatność SQL Injection w panelu czytelnika.
  • Wdrożenie zapory aplikacji webowych (WAF) blokującej próby wstrzykiwania kodu SQL oraz ograniczającej masowe pobieranie artykułów naukowych (Rate Limiting per użytkownik/IP).
• Bezpieczeństwo fizyczne pracowni zbiorów cennych:
  • Montaż drzwi z zamkiem elektromagnetycznym otwieranym kartą zbliżeniową z rejestracją czasu wejścia i wyjścia, montaż kamery CCTV skierowanej na stół digitalizacyjny oraz zakaz przebywania personelu sprzątającego bez asysty kustosza.
• Kwalifikacja ustaleń:
  • Podatność SQL Injection i brak SLA: Niezgodność Duża (NC1) – naruszenie § 19 ust. 2 pkt 12 lit. f-g KRI oraz Załącznika A.8.8 i A.8.26 ISO/IEC 27001.
  • Brak weryfikacji integralności i backupu repozytorium cyfrowego: Niezgodność Duża (NC1) – naruszenie Załącznika A.8.13.
  • Brak zabezpieczenia pobierania z baz naukowych: Niezgodność Mała (NC2) – naruszenie Załącznika A.5.15 i A.5.10.

Zalety rozwiązania:

• Trwałe zabezpieczenie dziedzictwa piśmienniczego regionu przed bezpowrotnym zniszczeniem lub skasowaniem.
• Ochrona 120 000 czytelników przed wyciekiem ich danych osobowych i historii czytelnictwa.
• Odblokowanie dostępu do międzynarodowych baz wiedzy dla całego środowiska akademickiego województwa.

Wady i ograniczenia wdrożeniowe:

• Koszt zakupu przestrzeni chmurowej PIONIER dla 180 TB danych oraz wdrożenia przemysłowych skanerów WAF.
• Drobne utrudnienia dla naukowców zmuszonych do manualnego pobierania artykułów bez użycia skryptów automatyzujących.
• Konieczność wygospodarowania środków w sztywnym budżecie publicznym instytucji kultury na stałą umowę SLA dla oprogramowania.

• Ustawa z dnia 27 czerwca 1997 r. o bibliotekach (Dz.U. z 2022 r. poz. 2393) – ochrona narodowego zasobu bibliotecznego.
• Rozporządzenie Ministra Kultury i Dziedzictwa Narodowego z dnia 4 lipca 2012 r. w sprawie narodowego zasobu bibliotecznego (Dz.U. z 2021 r. poz. 1308).
• Rozporządzenie Rady Ministrów w sprawie Krajowych Ram Interoperacyjności (Dz.U. z 2024 r. poz. 773) – § 19 (obowiązek stosowania środków ochrony) i § 20 (rozliczalność).
• Norma PN-EN ISO/IEC 27001:2022 – Załącznik A: A.8.8 (Zarządzanie podatnościami), A.8.13 (Kopie zapasowe), A.8.26 (Wymagania bezpieczeństwa aplikacji).
• Standard ISO 14721:2012 – Open Archival Information System (OAIS) – model odniesienia dla otwartych systemów archiwizacji informacji cyfrowej.

• W1 Ochrona danych konsumenckich w kampaniach Big Data, budżetów reklamowych i tajemnic premierowych.
• W2W3 Rozporządzenie RODO (profilowanie, transfer danych poza EOG), wytyczne EROD oraz ISO/IEC 27001.
• U1 Zaprojektowanie bezpiecznej architektury współpracy w ekosystemie marketingu cyfrowego.
• U2 Kwalifikacja uchybień w zarządzaniu tożsamościami federacyjnymi i prawami dostępu.
• U3 Przeprowadzenie analizy ryzyka kradzieży tożsamości menedżerów kampanii i wyłudzeń budżetowych.
• K1K3 Etyka w profilowaniu użytkowników oraz dbałość o reputację powierzonych marek globalnych.

Celem zadania na ocenę 4.0 jest opracowanie zaawansowanej Polityki Bezpieczeństwa Informacji dla dużej międzynarodowej agencji komunikacji cyfrowej i domu mediowego. Agencja zarządza wielomilionowymi budżetami reklamowymi klientów korporacyjnych, przetwarza bazy Big Data na potrzeby precyzyjnego targetowania kampanii, integruje narzędzia analityczne z globalnymi platformami reklamowymi (Meta Ads, Google Marketing Platform, TikTok For Business, Amazon Ads) oraz współpracuje z setkami rozproszonych podwykonawców (influencerzy, agencje kreatywne, domy produkcyjne w różnych strefach czasowych).

Dom Mediowy „OmniMedia Global Network” sp. z o.o. zatrudnia 220 specjalistów w biurach w Warszawie i Krakowie oraz współpracuje na stałe z 80 freelancerami w Europie, Azji i Ameryce Południowej. Agencja zarządza rocznym budżetem mediowym o wartości 350 mln PLN powierzonym przez 60 międzynarodowych korporacji (branża finansowa, telekomunikacyjna, FMCG, automotive). Agencja gromadzi i analizuje dane o zachowaniach 15 milionów internautów (profilowanie za pomocą plików cookies, pikseli śledzących i identyfikatorów mobilnych).

W trakcie audytu bezpieczeństwa ujawniono krytyczne podatności:

• Przejęcia kont menedżerów reklamowych (Ad Account Hijacking): W ciągu ostatnich 6 miesięcy odnotowano 2 udane ataki hakerskie na prywatne konta społecznościowe pracowników agencji, którzy posiadali uprawnienia administratora w Meta Business Managerze klienta. Hakerzy przejęli konta, podpięli złośliwe kampanie promujące fałszywe kryptowaluty i wydali 480 000 PLN z podpiętych kart kredytowych klienta w ciągu zaledwie 3 godzin, zanim zorientowano się o włamaniu.
• Niekontrolowany transfer baz danych poza Europejski Obszar Gospodarczy (EOG): Młodszy analityk danych przesłał bazę 400 000 adresów e-mail klientów banku do podwykonawcy w Indiach za pośrednictwem niezaszyfrowanego dysku Google Drive, bez podpisania Standardowych Klauzul Umownych UE (SCC) i bez zgody klienta, co stanowi naruszenie art. 44 i 46 ust. 1–2 RODO.
• Rotacja i brak audytu uprawnień w platformach chmurowych: W panelu Google Ads i Meta Business Manager agencji odnotowano ponad 90 aktywnych kont przypisanych do osób, które zakończyły pracę lub współpracę z agencją w latach 2021-2023. Byli pracownicy nadal posiadają możliwość generowania raportów i wglądu w wydatki konkurencji.
• Wykorzystanie generatywnej sztucznej inteligencji (Cień AI / Shadow AI): Copywriterzy i stratedzy wklejają poufne briefy kreatywne, strategie cenowe i dane o planowanych premierach produktów klientów do publicznych, darmowych modeli językowych (ChatGPT, Claude), których regulaminy przewidują trenowanie modeli na wprowadzonych danych.

• Krok 1 (Podział ról w zespole audytorskim):

Student 1 (Kierownik Zespołu i Specjalista ds. Bezpieczeństwa Mediów Cyfrowych): Definiuje Politykę Bezpieczeństwa Informacji Domu Mediowego, zasady bezpiecznego korzystania ze sztucznej inteligencji (AI Usage Policy) oraz procedury transferu danych poza EOG (Cross-Border Data Transfer).

Student 2 (Architekt Tożsamości i Bezpieczeństwa Chmury Reklamowej): Opracowuje architekturę Single Sign-On (SSO) z wymuszeniem kluczy sprzętowych FIDO2/U2F, integrację paneli reklamowych z centralnym katalogiem tożsamości oraz procedurę natychmiastowego odcinania dostępów.

Student 3 (Audytor Zgodności Prawnej i Ryzyka RODO/AdTech): Przeprowadza szacowanie ryzyka finansowego i prawnego w matrycy 3 × 3 dla incydentu przejęcia konta reklamowego, klasyfikuje niezgodności (NC1/NC2/OFI) oraz opracowuje Plan Reagowania na Incydenty AdTech i tabelę CAP.

• Krok 2 (Analiza ryzyka przejęcia budżetów reklamowych):

Wyliczcie w matrycy 3 × 3 prawdopodobieństwo i skutki przejęcia konta menedżera reklamowego (straty z kart kredytowych, odszkodowania dla marek, utrata kontraktu mediowego).

• Krok 3 (Kwalifikacja niezgodności RODO i ISO/IEC 27001):

Dokonajcie formalnego przypisania uchybień:

• Transfer bazy klientów do Indii bez standardowych klauzul umownych (Niezgodność Duża NC1 – art. 44 i 46 ust. 1–2 RODO).
• Brak MFA opartego na kluczach FIDO2 na kontach z dostępem do milionowych budżetów (Niezgodność Duża NC1 - Załącznik A.8.5).
• Pozostawienie 90 aktywnych kont byłych pracowników (Niezgodność Duża NC1 - Załącznik A.6.5).
• Wprowadzanie poufnych danych do publicznych modeli AI (Niezgodność Mała NC2 - Załącznik A.5.10 i A.5.34; OFI - brak polityki użycia AI).

Zaprojektujcie plan natychmiastowej czystki kont (48 h), wdrożenia kluczy FIDO2 (14 dni) oraz wdrożenia bezpiecznej, zamkniętej instancji AI dla pracowników (60 dni).

• Krok 4 (Plan CAP i RTP):

Dla każdej ustalonej niezgodności przygotujcie wpis w Planie Działań Korygujących (CAP): przyczyna źródłowa, działanie naprawcze, właściciel, termin (14–90 dni od daty audytu) i kryterium skuteczności. Następnie wypełnijcie Plan Postępowania z Ryzykiem (RTP): decyzja postępowania z ryzykiem (unikanie, redukcja, transfer albo akceptacja), działanie mitygujące, właściciel, termin i szacowane ryzyko rezydualne. Uzasadnienie decyzji o akceptacji ryzyka zapiszcie w raporcie.

Skala szacowania ryzyka (matryca 3 × 3): Prawdopodobieństwo (P): 1 – niskie, 2 – średnie, 3 – wysokie. Skutek (S): 1 – niski, 2 – poważny, 3 – krytyczny. Poziom ryzyka to iloczyn P × S (1–9). Wynik 6–9 oznacza strefę wysoką / niedopuszczalną, 3–4 strefę średnią, a 1–2 ryzyko akceptowalne. Tabele poniżej zawierają przykładowe karty ryzyka dla kluczowych aktywów jednostki.

Rejestr ustaleń audytowych z formalną gradacją: NC1 – Niezgodność Duża, NC2 – Niezgodność Mała, OFI – Szansa na poprawę.

Plan Działań Korygujących zawiera numer ustalenia, kwalifikację, analizę przyczyny źródłowej (Root Cause), działanie naprawcze, właściciela oraz harmonogram realizacji (14–90 dni).

Plan Postępowania z Ryzykiem (ang. Risk Treatment Plan, RTP) uzupełnia Plan Działań Korygujących: CAP odpowiada na pytanie co i kto naprawia, a RTP – jaką decyzją zarządcy świadomie redukują, przenoszą, unikają lub akceptują ryzyko. Każde ryzyko z matrycy powyżej musi mieć w RTP jedną, jawnie zapisaną decyzję; ryzyko pozostawione bez decyzji jest ryzykiem nieakceptowanym.

Do uzupełnienia: dla każdego zagrożenia z tabeli ryzyk wpiszcie klasyfikację (P × S), kwalifikację (NC1/NC2/OFI), wybraną decyzję postępowania, działanie mitygujące z odesłaniem do pozycji CAP, właściciela z terminem oraz szacowane ryzyko rezydualne. Poniżej wzór wypełniony dla jednego scenariusza – pozostałe wiersze uzupełnijcie sami.

• Unikanie ryzyka – eliminacja aktywności lub zmiana jej zakresu, np. wyłączenie publicznego dostępu do usługi.
• Redukcja (ograniczenie) – wdrożenie kontroli obniżających prawdopodobieństwo albo skutek; to decyzja dla większości ustaleń NC1 i NC2.
• Transfer (przeniesienie) – przeniesienie ryzyka na podmiot trzeci: umowa SLA, ubezpieczenie, gwarancja dostawcy, klauzule audytowe.
• Akceptacja ryzyka – świadome pozostawienie ryzyka przez organ zarządzający, z podaniem uzasadnienia, właściciela decyzji i terminu przeglądu.

Decyzja akceptacja wymaga pisemnego uzasadnienia w raporcie; samo wpisanie decyzji bez argumentu jest niewystarczające. Terminy w RTP muszą pokrywać się z terminami w CAP dla tych samych ustaleń.

Każdy raport rozpoczyna się od Executive Summary dla zarządu (ok. 1 strona): najważniejsze ustalenia z liczbą NC1 / NC2 / OFI, najwyższe ryzyko rezydualne, kluczowe decyzje podjęte w RTP oraz wniosek o zasoby i decyzję do podjęcia. Objętość raportu to 8–12 stron A4, a obrona koncepcji przed komisją trwa 15 minut. Executive Summary jest wymagane przez kryteria formalne zaliczenia na ocenę 4.0.

Studenci przygotowują rozbudowany raport audytowy (8–12 stron A4):

• Wprowadzenie: Cyberbezpieczeństwo w branży AdTech i marketingu efektywnościowego – ochrona budżetów, tożsamości i prywatności konsumentów.
• Diagnoza ryzyk w „OmniMedia Global Network”: Analiza podatności na Ad Account Hijacking, nielegalnego transferu danych i wycieków przez Shadow AI.
• Matryca oceny ryzyka dla platform reklamowych i operacji Big Data.
• Zaawansowany projekt Polityki Bezpieczeństwa Informacji Domu Mediowego:
  • Standard zarządzania dostępem do ekosystemów reklamowych (Meta Business Manager, Google MCC) w oparciu o SSO i klucze sprzętowe FIDO2.
  • Procedura transferu danych osobowych poza EOG (zgodność z wyrokiem Schrems II, Standardowe Klauzule Umowne - SCC).
  • Polityka odpowiedzialnego i bezpiecznego korzystania ze sztucznej inteligencji (Generative AI Enterprise Policy).
  • Procedura natychmiastowego Offboardingu i automatycznego przeglądu uprawnień w platformach zewnętrznych.
• Rejestr niezgodności (NC1/NC2/OFI) oraz Plan Działań Korygujących (CAP).
• Wnioski i podsumowanie: Cyberbezpieczeństwo jako warunek konieczny do obsługi międzynarodowych marek giełdowych.

Wzorcowa koncepcja na ocenę 4.0 wprowadza:

• Wdrożenie federacji tożsamości i kluczy FIDO2:
  • Wymuszenie logowania do platform reklamowych (Meta, Google, TikTok, LinkedIn) wyłącznie za pośrednictwem centralnego dostawcy tożsamości (IdP / Okta / Azure AD) ze zintegrowanym Single Sign-On (SSO).
  • Obowiązek stosowania sprzętowych kluczy bezpieczeństwa FIDO2 (np. YubiKey) dla wszystkich osób posiadających uprawnienia finansowe lub administratorskie w panelach reklamowych – całkowite wyeliminowanie podatności na phishing i przejęcia kont.
• Rygorystyczną politykę transferu danych poza EOG:
  • Natychmiastowe zablokowanie przesyłania baz klientów otwartymi kanałami chmurowymi.
  • Wdrożenie obowiązkowych audytów podwykonawców zagranicznych oraz podpisanie unijnych Standardowych Klauzul Umownych (SCC) wraz z Oceną Skutków Transferu (TIA - Transfer Impact Assessment) przed przekazaniem jakichkolwiek danych.
• Politykę i narzędzia Generative AI:
  • Zablokowanie dostępu do darmowych publicznych portali AI na poziomie zapory sieciowej – wdrożenie firmowej, zamkniętej instancji modelu AI (np. Azure OpenAI Service / Enterprise ChatGPT), w której wprowadzane zapytania nie są wykorzystywane do trenowania modeli publicznych, a dane są szyfrowane kluczem agencji.
• Kwalifikacja ustaleń:
  • Wszystkie trzy główne uchybienia (przejęcia kont reklamowych, nielegalny transfer danych, brak offboardingu 90 kont) zakwalifikowano jako Niezgodności Duże (NC1), gdyż grożą bezpośrednimi stratami finansowymi liczonymi w milionach złotych oraz karami UODO.

Zalety rozwiązania:

• Całkowite wyeliminowanie ryzyka kradzieży budżetów reklamowych klientów dzięki odpornym na phishing kluczom FIDO2.
• Bezpieczeństwo prawne agencji w relacjach międzynarodowych i zgodność z rygorystycznymi wymogami RODO dotyczącymi transferu danych.
• Możliwość bezpiecznego korzystania z innowacyjnych narzędzi AI bez obawy o utratę tajemnic handlowych klientów.

Wady i ograniczenia wdrożeniowe:

• Koszt zakupu kluczy sprzętowych FIDO2 dla ponad 200 pracowników oraz wdrożenia korporacyjnej instancji AI.
• Opór pracowników i freelancerów przyzwyczajonych do dużej swobody i korzystania z prywatnych narzędzi internetowych.
• Skomplikowany proces konfiguracji SSO w panelach biznesowych mediów społecznościowych.

• Ustawa o ochronie danych osobowych (RODO): art. 28 (powierzenie przetwarzania), art. 44 i 46 ust. 1–2 (przekazywanie do państw trzecich) oraz art. 46 ust. 2 lit. c wraz z decyzją wykonawczą Komisji (UE) 2021/914 (standardowe klauzule umowne, SCC) oraz oceną skutków transferu (TIA).
• Wytyczne EROD (Europejskiej Rady Ochrony Danych) 05/2021 w sprawie powiązania między stosowaniem art. 3 a przepisami RODO dotyczącymi międzynarodowego przekazywania danych - dotyczą wyłącznie podmiotów spoza jurysdykcji RODO (art. 3 ust. 2) i nie zastępują obowiązku zastosowania klauzul umownych z art. 46.
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/1689 z dnia 13 czerwca 2024 r. w sprawie sztucznej inteligencji (AI Act), art. 113 określa etapowe stosowanie: rozdziały I i II od 2 lutego 2025 r., rozdziały III sekcja 4, V, VII i XII oraz art. 78 od 2 sierpnia 2025 r., pozostałe obowiązki od 2 sierpnia 2026 r., a art. 6 ust. 1 wraz z powiązanymi obowiązkami dla systemów wysokiego ryzyka - do 2 sierpnia 2027 r. AI Act nie przewiduje ogólnego obowiązku zgłaszania incydentów, ale art. 26 ust. 5 zobowiązuje podmioty stosujące do niezwłocznego zgłoszenia poważnego incydentu organowi nadzoru rynku, a art. 73 nakłada na dostawców nadzór po wprowadzeniu systemu na rynek; obowiązki przejrzystości opisuje art. 50.
• Norma PN-EN ISO/IEC 27001:2022 – Załącznik A: A.5.15 (Kontrola dostępu), A.6.5 (Odpowiedzialność po ustaniu zatrudnienia), A.8.5 (Bezpieczne uwierzytelnianie).
• Wytyczne FIDO Alliance: „Enterprise Best Practices for Phishing-Resistant MFA in AdTech and Digital Marketing”, 2023.

4. Kryteria weryfikacji i zaliczenia raportów przez prowadzącego (ocena 4.0)

Zgodnie z punktem 8 sylabusa przedmiotu Audyt bezpieczeństwa informacji, ocena 4.0 (dobra) wymaga od studentów wykazania się nie tylko znajomością faktów, ale przede wszystkim zdolnością analityczną, rzetelnym warsztatem audytorskim oraz umiejętnością posługiwania się sformalizowanymi narzędziami oceny ryzyka.

Wymogi formalne zaliczenia na ocenę 4.0:

1. Złożenie pisemnego Raportu z Audytu i Projektu SZBI:

• Objętość: 8–12 stron znormalizowanego maszynopisu w formacie PDF.
• Pełna struktura raportu: Metryka, Executive Summary dla Zarządu, Diagnoza stanu faktycznego, Matryca Szacowania Ryzyka (3 × 3), Projekt Polityki Bezpieczeństwa Informacji z procedurami wykonawczymi, Rejestr Ustalonych Niezgodności (NC1/NC2/OFI), Plan Postępowania z Ryzykiem (RTP) oraz Plan Działań Korygujących (CAP).

2. Zespołowa obrona projektu na forum grupy laboratoryjnej:

• 15 minut wystąpienia z prezentacją multimedialną lub omówieniem raportu.
• Obowiązkowy i równomierny udział każdego członka zespołu (Rola 1, Rola 2, Rola 3).
• Obrona przyjętej metodyki szacowania ryzyka i kwalifikacji niezgodności w krzyżowym ogniu pytań prowadzącego i pozostałych grup studenckich.

Kryteria punktowe dla oceny 4.0:

• Poprawność i dojrzałość analizy ryzyka (waga: 25%): Trafność doboru aktywów krytycznych, uzasadnienie wartości prawdopodobieństwa i skutku, wyliczenie ryzyka inherentnego i rezydualnego po zastosowaniu kontroli mitygujących.
• Rzetelność klasyfikacji niezgodności wg ISO/IEC 27001 (waga: 25%): Prawidłowe odróżnienie Niezgodności Dużej (NC1) od Niezgodności Małej (NC2) i Szansy na poprawę (OFI) wraz z precyzyjnym powołaniem się na klauzule normy (np. A.8.20, A.8.2, A.5.15) i artykuły prawa (RODO, KRI, DORA, NIS2).
• Jakość i realność Polityki Bezpieczeństwa oraz Planu CAP (waga: 30%): Czy opracowane procedury rozwiązują zdiagnozowane problemy, czy Plan CAP posiada realne terminy (14–90 dni), przypisanych właścicieli oraz mierzalne kryteria sukcesu (KPI).
• Poziom merytoryczny obrony ustnej i dyscyplina polonistyczna (waga: 20%): Precyzja wypowiedzi, posługiwanie się terminologią normatywną, brak żargonu potocznego, wysoka kultura słowa i umiejętność odparcia obiekcji audytowanego.

Różnice pomiędzy oceną 3.0, 3.5 a 4.0:

• Ocena 3.0: Student wskazuje oczywiste uchybienia (np. hasło na karteczce), proponuje proste zasady czystego biurka, nie przeprowadza sformalizowanej analizy ryzyka, praca ma charakter odtwórczy i schematyczny.
• Ocena 3.5: Student poprawnie rozróżnia normy prawne i techniczne, jednak analiza ryzyka jest pobieżna, a plan działań naprawczych nie zawiera analizy przyczyn źródłowych (Root Cause Analysis).
• Ocena 4.0: Student bezbłędnie przeprowadza matrycową analizę ryzyka, prawidłowo klasyfikuje niezgodności dużej i małej wagi, proponuje zaawansowane procedury techniczno-organizacyjne dostosowane do specyfiki sektora oraz tworzy wiążący Plan CAP gotowy do wdrożenia w badanej jednostce.