Laboratorium 6

Głównym celem strategicznego zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie zaawansowanego, symulowanego audytu procesów zarządzania zmianami awaryjnymi (Emergency Change Management) w wielospecjalistycznym szpitalu klinicznym o statusie Podmiotu Kluczowego w rozumieniu Dyrektywy NIS2 oraz operatora infrastruktury krytycznej ochrony zdrowia. Placówka eksploatuje zintegrowany ekosystem kliniczny: Szpitalny System Informacyjny (HIS), Radiologiczny System Informacyjny (RIS), cyfrowe archiwum obrazów (PACS), systemy planowania terapii onkologicznej TPS oparte na certyfikowanych algorytmach sztucznej inteligencji (AI Act - systemy wysokiego ryzyka) oraz 5 medycznych akceleratorów liniowych LINAC. Studenci wcielają się w rolę Triady Audytorskiej badającej mechanizm nocnego wdrożenia poprawki typu hotfix bezpośrednio na środowisku produkcyjnym, która wywołała błąd integralności relacyjnej, zawieszenie kalkulacji dawek promieniowania i wstrzymanie podawania leków cytostatycznych dla 140 chorych onkologicznie. Zadanie wymaga przeprowadzenia dekompozycji uchybień w kanonicznym modelu 4C (Condition, Criteria, Cause, Consequence), wyliczenia ryzyka w 25-stopniowej matrycy 5x5 skorelowanej ze wskaźnikami BCM (RTO, RPO, MTPD), opracowania Trójfazowego Planu Działań Korygujących (CAP) ze wskaźnikami KPI i KRI, sformułowania sformalizowanego Załącznika Wykonawczego (SOP) oraz przygotowania Podsumowania Zarządczego (Executive Summary - "Pitch to Board") dla Dyrekcji Szpitala.

Powiązanie z sylabusem i efektami kształcenia na ocenę 5.0:

• W1 Zaawansowana ochrona danych szczególnej kategorii (art. 9 RODO), tajemnicy lekarskiej oraz odpowiedzialności prawnej i karnej za narażenie życia pacjentów onkologicznych (art. 160 KK).
• W2W3 Rygorystyczna korelacja wymagań Dyrektywy NIS2 (art. 21 - cyberodporność i zarządzanie incydentami), rozporządzenia AI Act (wymogi nadzoru nad modelami AI wysokiego ryzyka w medycynie), normy ISO/IEC 27001:2022 (kontrole A.8.32 Zarządzanie zmianami, A.8.29 Testowanie akceptacyjne, A.8.31 Rozdzielenie środowisk), metodyki ITIL 4 oraz standardów akredytacyjnych Centrum Monitorowania Jakości (CMJ).
• U1 Opracowanie zintegrowanej procedury Emergency Change Management łączącej rygory medyczne, automatyczne bramki sandboxa walidacyjnego i kryptograficzną autoryzację wieloosobową ECAB.
• U2 Bezbłędna identyfikacja i formalna kwalifikacja uchybień w kanonicznym modelu 4C z precyzyjnym powołaniem artykułów prawa i punktów norm.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 dla wektorów błędu radioterapii i wstrzymania chemioterapii w ujęciu ryzyka inherentnego (IR) i rezydualnego (RR) z powiązaniem ze wskaźnikami RTO=15m, RPO=0s, MTPD=1h.
• U4 Opracowanie Trójfazowego Planu Działań Korygujących (CAP) ze wskaźnikami KPI i KRI oraz 1-stronicowego briefingu zarządczego (Pitch to Board).
• K1K2K3 Niezależność osądu audytorskiego, odporność na presję autorytetu medycznego, bezkompromisowość w ochronie życia ludzkiego i wysoka etyka zawodowa.
• Powiązanie z wykładem: Wyk1 (Audyt w podmiotach kluczowych NIS2), Wyk3 (Kontrole A.8.32 i A.8.29 ISO 27001), Wyk4 (RODO art. 9 i AI Act w medycynie), Wyk5 (Matryca ryzyka 5x5 i BIA), Wyk6 (Triangulacja logów DICOM/TPS i bazy Oracle), Wyk7 (Model 4C, 5 Why i Trójfazowy CAP).

Wojewódzki Szpital Kliniczny i Centrum Onkologii w Białymstoku jest wysokospecjalistycznym kompleksem kliniczno-naukowym dysponującym 950 łóżkami, 24 klinikami stacjonarnymi, w tym Kliniką Onkologii Klinicznej, Hematologii, Radioterapii oraz Szpitalnym Oddziałem Ratunkowym. Szpital hospitalizuje rocznie ponad 70 tysięcy pacjentów, a Zakład Teleradioterapii wykonuje 45 tysięcy sesji napromieniania nowotworów za pomocą 5 medycznych akceleratorów liniowych LINAC (Varian TrueBeam).

Stan faktyczny w obszarze procesu wdrażania zmian i incydentu klinicznego:

• W ekosystemie IT szpitala kluczową rolę pełni zintegrowana platforma łącząca Szpitalny System Informacyjny (HIS), Radiologiczny System Informacyjny (RIS), archiwum obrazów PACS oraz System Planowania Terapii Onkologicznej (TPS) wyposażony w certyfikowany moduł sztucznej inteligencji AI-CONTOUR służący do automatycznej segmentacji guzów i narządów krytycznych (OAR).
• W piątek o godzinie 22:30, podczas dyżuru nocnego, w aptece cytostatycznej wystąpiło zawieszenie transakcji w bazie danych Oracle RAC, blokujące walidację recept na wlewy chemioterapeutyczne. Dyżurny administrator IT, zamiast zwołać komitet awaryjny ECAB, nawiązał kontakt telefoniczny z zewnętrznym programistą firmy wdrożeniowej.
• Programista połączył się zdalnie przez nieszyfrowany tunel administracyjny z uprawnieniami konta 'SYSDBA' i bez zarejestrowania wniosku RFC uruchomił bezpośrednio na produkcyjnym klastrze Oracle skrypt PL/SQL modyfikujący strukturę tabel zamówień leków oraz relacje kluczy obcych łączące moduł zleceń z bazą dawek promieniowania RIS/TPS. Zmiana została potraktowana jako "rutynowy hotfix na żywo".
• Nie wykonano migawki bazy (Pre-change Snapshot), nie sporządzono skryptu cofającego (Rollback Script) i nie przeprowadzono żadnych testów weryfikacyjnych na środowisku stagingowym.
• W sobotę o godzinie 06:15 personel Zakładu Radioterapii i Apteki Cytostatycznej zgłosił krytyczną awarię: moduł sztucznej inteligencji AI-CONTOUR przestał pobierać zweryfikowane dane histopatologiczne pacjentów, zgłaszając błąd spójności danych "ORA-02291: integrity constraint violated", a system TPS zablokował transfer planów wiązek do wszystkich 5 akceleratorów LINAC.
• Zablokowano przygotowanie 140 wlewów cytostatycznych dla pacjentów oddziału hematologii oraz odwołano sesje naświetlań onkologicznych dla 120 chorych. Personel medyczny nie posiadał procedur awaryjnego postępowania manualnego (Paper Fallback) ani procedury Break-Glass pozwalającej na wydanie leków w trybie ratunkowym.
• Próba odtworzenia bazy z backupu trwała 18 godzin z powodu niespójności zrzutów RMAN, co doprowadziło do utraty wpisów medycznych dla 72 pacjentów przyjętych w nocy na SOR. Sprawa trafiła do mediów ogólnopolskich, Rzecznika Praw Pacjenta oraz Prokuratury Okręgowej.

Dyrektor Szpitala, stając w obliczu groźby utraty kontraktu z NFZ o wartości 110 mln PLN oraz kar finansowych ze strony Urzędu Ochrony Danych Osobowych i Ministerstwa Zdrowia, powołuje Triadę Audytorską do przeprowadzenia strategicznego audytu w formule 90 minut na poziomie oceny 5.0.

Zadanie realizowane jest w ścisłym reżimie warsztatowym (formuła 90 minut) przez 2-3 osobową Triadę Audytorską:

• Krok 1 (Podział ról w Triadzie Audytorskiej - Minuty 00-15):

  Student A (Lead Auditor / Reprezentant CISO): Odpowiada za ład zarządczy (Change Governance), analizę regulaminu komitetu ECAB, relacje z Dyrekcją Medyczną, zgodność z Dyrektywą NIS2 i wymogami akredytacyjnymi CMJ, koordynację matrycy 5x5 oraz przygotowanie 1-stronicowego Executive Summary ("Pitch to Board").

  Student B (Technical SecOps Auditor / Architekt Bezpieczeństwa IT/AI): Bada logi transakcyjne Oracle RAC, błąd ORA-02291, procedury PL/SQL, parametry algorytmu AI-CONTOUR, komunikację DICOM-RT z akceleratorami LINAC, konfigurację tunelu zdalnego i projektuje medyczny sandbox walidacyjny z mechanizmem automatycznego rollbacku.

  Student C (Change Governance & Compliance Auditor): Przeprowadza dekompozycję ustaleń w kanonicznym modelu 4C, wylicza ryzyko w matrycy 5x5 (IR/RR) skorelowane ze wskaźnikami BCM (RTO=15m, RPO=0s, MTPD=1h), prowadzi sekwencję 5 Why oraz konstruuje Trójfazowy Plan CAP z przypisaniem ról RACI i wskaźników KPI/KRI. W zespole dwuosobowym obowiązki Roli C dzielą Studenci A i B.

• Krok 2 (Opracowanie Kanonicznej Karty Niezgodności 4C - Minuty 15-40):

  Sformułujcie kartę uchybienia krytycznego w modelu 4C:

• Krok 3 (Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM - Minuty 15-40):

  Skwantyfikujcie ryzyka w 25-stopniowej skali (P 1-5 x S 1-5):

• Krok 4 (Konstrukcja Trójfazowego Planu Działań Korygujących - CAP - Minuty 40-70):

  Opracujcie tabelę CAP w 3 horyzontach czasowych:

• Krok 5 (Sformalizowany Projekt Załącznika Wykonawczego SOP - Minuty 40-70):

  Zredagujcie sformalizowany akt normatywny: "Instrukcja Zarządzania Zmianami Awaryjnymi w Ekosystemie Medycznym HIS/RIS/LINAC WSK w Białymstoku" z numerowanymi artykułami (§ 1 Definicje i kryteria Emergency, § 2 Skład i tryb zwoływania ECAB 24/7/365, § 3 Obowiązkowy punkt kontrolny Pre-change Snapshot i Rollback Script, § 4 Procedura Break-Glass na Bloku Operacyjnym, § 5 Sankcje dyscyplinarne i karne za samowolne modyfikacje).

• Krok 6 (Opracowanie Podsumowania Zarządczego - Pitch to Board - Minuty 70-90):

  Przygotujcie 1-stronicowy dokument dla Dyrekcji Szpitala syntetyzujący ekspozycję na kary regulacyjne (do 30 mln EUR), bilans ryzyk przed i po audycie, koszt wdrożenia CAP (420 tys. PLN) oraz stopę zwrotu z inwestycji (uniknięcie kar, ochrona życia pacjentów i zachowanie kontraktu NFZ).

Plan strategicznej obrony seminaryjnej przed komisją laboratoryjną (15 minut):

• Prezentacja Podsumowania Zarządczego (Pitch to Board) dla Dyrekcji (3 min): Przedstawienie skali zagrożenia, ekspozycji finansowej i prawnej oraz bilansu ryzyk przed i po audycie (Student A - Lead Auditor).
• Dekonstrukcja incydentu technicznego i architektury HIS/TPS/LINAC (4 min): Analiza błędu ORA-02291, naruszenia relacji danych onkologicznych, analizy logów Oracle i podatności tunelu serwisowego (Student B - Technical SecOps Auditor).
• Prezentacja Kanonicznej Karty Niezgodności 4C, analizy 5 Why i matrycy ryzyka 5x5 (4 min): Uzasadnienie kwalifikacji uchybień, korelacja z NIS2, RODO art. 9 i AI Act oraz wyliczenie redukcji ryzyka z IR=20 do RR=4 (Student C - Compliance Auditor).
• Prezentacja Trójfazowego Planu CAP i Załącznika Wykonawczego SOP (3 min): Szczegółowe omówienie działań w horyzoncie 0-7, 30 i 90 dni, wskaźników KPI/KRI oraz regulaminu komitetu ECAB (Student B i Student C).
• Dyskusja z komisją i obrona rekomendacji (1 min): Merytoryczne uzasadnienie kosztów inwestycyjnych w relacji do wartości życia ludzkiego (cała Triada Audytorska).

Struktura raportu strategicznego na ocenę 5.0 (objętość 12-16 stron A4):

A. Podsumowanie Zarządcze (Executive Summary - "Pitch to Board") - 1 strona A4:

• Syntetyczny bilans ryzyk (przed audytem: 4 ryzyka krytyczne IR>=16; po CAP: ryzyka zredukowane do poziomu akceptowalnego RR<=5).
• Ekspozycja na sankcje: kary UODO (do 20 mln EUR), kary KSC/NIS2 (do 10 mln EUR), roszczenia cywilne (8,5 mln PLN).
• Budżet Planu CAP: 420 000 PLN (zakup licencji PAM, rozbudowa klastra stagingowego, szkolenia).
• Stopa zwrotu (ROI): Ochrona kontraktu NFZ o wartości 110 mln PLN rocznie, zachowanie akredytacji CMJ i wyeliminowanie ryzyka zgonów pacjentów w wyniku błędów wdrożeniowych.

B. Odpowiedzi na pytania problemowe i opis sytuacji kryzysowej:

• W jaki sposób zharmonizować rygorystyczne wymagania rozporządzenia AI Act (dla algorytmów medycznych wysokiego ryzyka) z procedurami Emergency Change Management w radioterapii onkologicznej?
• Jakie mechanizmy techniczne architektury Zero-Trust (Privileged Access Management, dynamiczne poświadczenia, kryptograficzna weryfikacja sum kontrolnych) uniemożliwiają serwisantom wprowadzanie zmian DDL z pominięciem komitetu ECAB?
• Czym charakteryzuje się medyczna procedura "Break-Glass" i jak zagwarantować jej stuprocentową audytowalność post-factum?

C. Kanoniczna Karta Ustaleń Audytowych w Modelu 4C:

• Condition: Szczegółowy opis dowodowy incydentu z analizą logów Oracle alert.log i transakcji DICOM-RT.
• Criteria: Precyzyjne zestawienie wymogów normy ISO/IEC 27001:2022 (A.8.32, A.8.29, A.8.31), art. 32 RODO, Dyrektywy NIS2 i standardów CMJ.
• Cause: Pełna dekompozycja dochodzeniowa metodą 5 Why.
• Consequence: Kwantyfikacja skutków prawnych, finansowych, operacyjnych i medycznych.

D. Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM:

• Tabela 4 obszarów podatności z wyliczeniem prawdopodobieństwa (1-5), skutku (1-5), Ryzyka Inherentnego (IR), Ryzyka Rezydualnego (RR) oraz parametrów RTO (15m), RPO (0s) i MTPD (1h).

E. Trójfazowy Plan Działań Korygujących (CAP):

• Tabela z podziałem na Fazę 1 (0-7 dni), Fazę 2 (30 dni) i Fazę 3 (90 dni) z przypisaniem macierzy RACI, mierzalnych wskaźników KPI i KRI.

F. Sformalizowany Projekt Załącznika Wykonawczego do Polityki BCP/DRP (SOP):

• Kompletny projekt aktu wewnętrznego szpitala: "Procedura Zarządzania Zmianami Awaryjnymi w Systemach Ratujących Życie HIS/TPS/LINAC" (§ 1 - § 8 z pełnymi regułami technicznymi i sankcjami).

G. Analiza zalet i ograniczeń wdrożeniowych:

• Zestawienie korzyści w zakresie cyberodporności i zgodności z kosztami organizacyjnymi i narzutem czasowym procedur ECAB.

H. Bibliografia i normy źródłowe.

• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.8.32 (Zarządzanie zmianami), A.8.29 (Testowanie bezpieczeństwa w rozwoju i akceptacji), A.8.31 (Rozdzielenie środowisk), A.8.2 (Uprzywilejowane prawa dostępu).
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (Dyrektywa NIS2) - art. 21 (Środki zarządzania ryzykiem w cyberbezpieczeństwie w sektorze ochrony zdrowia).
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/1689 z dnia 13 czerwca 2024 r. w sprawie sztucznej inteligencji (AI Act) - wymogi dla systemów wysokiego ryzyka w ochronie zdrowia.
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) - art. 9 (Przetwarzanie szczególnych kategorii danych) oraz art. 32 (Bezpieczeństwo przetwarzania).
• Ustawa z dnia 28 kwietnia 2011 r. o systemie informacji w ochronie zdrowia (Dz.U. z 2023 r. poz. 246 z późn. zm.).
• Centrum Monitorowania Jakości w Ochronie Zdrowia (CMJ): "Zestaw standardów akredytacyjnych dla szpitali - Bezpieczeństwo informacji i ciągłość opieki", Kraków 2022.
• Axelos: "ITIL 4: Change Enablement Practice Guide", PeopleCert 2020.

• U2 Bezbłędna dekompozycja uchybień w modelu 4C i przeprowadzenie analizy 5 Why w infrastrukturze medycznej.
• U1 Projekt zintegrowanej procedury Emergency Change Management z kryptograficznym komitetem ECAB i sandboxem.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 w ujęciu inherentnym i rezydualnym z powiązaniem ze wskaźnikami BCM.
• U4 Konstrukcja Trójfazowego Planu CAP oraz przygotowanie profesjonalnego Executive Summary ("Pitch to Board").
• W1W2W3 Wyczerpująca znajomość zbieżności NIS2, RODO art. 9, AI Act, normy ISO 27001 i standardów CMJ.
• K1K2K3 Profesjonalizm audytorski, zdolność do obrony ustaleń przed kadrą C-Level i bezkompromisowa ochrona życia pacjentów.

Wystąpienie rozpocznijcie od mocnego uderzenia w formule 'Pitch to Board' – przedstawcie Dyrekcji Szpitala bezpośrednie zagrożenie utraty kontraktu NFZ na 110 mln PLN i sankcji karnych, a następnie wskażcie gotowe, precyzyjne rozwiązanie w postaci Trójfazowego Planu CAP.

Głównym celem strategicznego zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie zaawansowanego audytu bezpieczeństwa fizycznej, logicznej i uprawnieniowej separacji środowisk wielochmurowych (DEV, TEST, STAGING, PROD) oraz wdrożenia automatycznych potoków zarządzania danymi testowymi (Test Data Management - TDM) opartych na syntezie i nieodwracalnej anonimizacji w regionalnej administracji publicznej. Badana jednostka zarządza krytycznymi rejestrami mieszkańców (bazy e-Urząd, system EZD RP, e-Doręczenia oraz rejestry wniosków o dofinansowanie termomodernizacji o wartości 450 mln PLN). Zadanie symuluje sytuację kryzysową powstałą po bezprawnym przekazaniu 450 tysięcy rekordów obywateli zewnętrznemu konsorcjum deweloperskiemu, braku zapór sieciowych między strefami chmury hybrydowej oraz paraliżu procesu wypłat dotacji unijnych. Studenci przeprowadzają dekompozycję uchybień w modelu 4C, szacują ryzyko w 25-stopniowej matrycy 5x5, prowadzą analizę 5 Why, konstruują Trójfazowy Plan CAP oraz przygotowują Załącznik Wykonawczy i Podsumowanie Zarządcze dla Marszałka Województwa.

Powiązanie z sylabusem i efektami kształcenia na ocenę 5.0:

• W1 Zaawansowana znajomość ochrony danych osobowych obywateli (RODO art. 5, 25, 32), tajemnicy skarbowej i informacji prawnie chronionych w projektach cyfryzacji samorządu.
• W2W3 Precyzyjna korelacja wymagań Rozporządzenia w sprawie Krajowych Ram Interoperacyjności (par. 20 KRI), Ustawy o doręczeniach elektronicznych, normy ISO/IEC 27001:2022 (A.8.31 Rozdzielenie środowisk, A.8.33 Informacje testowe, A.8.32 Zarządzanie zmianami) oraz wytycznych Europejskiej Rady Ochrony Danych (EROD).
• U1 Zaprojektowanie zaawansowanej architektury 4-strefowej Zero-Trust Network Architecture (ZTNA) z automatyczną generacją syntetycznych baz testowych TDM.
• U2 Profesjonalne udokumentowanie uchybień w kanonicznym modelu 4C z precyzyjną referencją do przepisów KRI i RODO.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 w ujęciu ryzyka inherentnego (IR=20) i rezydualnego (RR=4) skorelowana ze wskaźnikami RTO=2h, RPO=1h, MTPD=4h.
• U4 Opracowanie Trójfazowego Planu Działań Korygujących (CAP) oraz 1-stronicowego briefingu zarządczego (Pitch to Board) dla Marszałka Województwa.
• K1K2K3 Obiektywizm audytorski, wrażliwość na prawa obywatelskie, odporność na naciski polityczne i rzetelność badania dowodów sieciowych.
• Powiązanie z wykładem: Wyk1 (Audyt ładu informatycznego w samorządzie), Wyk3 (Kontrole A.8.31 i A.8.33 ISO 27001), Wyk4 (RODO i KRI w chmurze publicznej), Wyk5 (Matryca ryzyka 5x5 i BIA), Wyk6 (Analiza ruchu sieciowego NetFlow i sampling baz danych), Wyk7 (Model 4C, 5 Why i Trójfazowy CAP).

Urząd Marszałkowski Województwa Śląskiego wraz ze Śląskim Centrum Społeczeństwa Informacyjnego (ŚCSI) jest dysponentem Regionalnego Węzła Teleinformatycznego obsługującego platformę e-usług publicznych SEKAP-2, system Elektronicznego Zarządzania Dokumentacją (EZD RP), zintegrowany węzeł e-Doręczeń oraz bazę wniosków o dotacje unijne w ramach Programu Regionalnego Fundusze Europejskie dla Śląska o alokacji 450 milionów PLN. Rejestry obejmują szczegółowe dane 450 tysięcy obywateli i przedsiębiorców (numery PESEL, NIP, dochody gospodarstw domowych, stan posiadania nieruchomości, zaświadczenia o niezaleganiu w podatkach, numery prywatnych rachunków bankowych).

Stan faktyczny w obszarze rozwoju systemów i zarządzania środowiskami:

• W celu realizacji wymogów Ustawy o doręczeniach elektronicznych urząd zlecił rozbudowę portalu konsorcjum trzech zewnętrznych spółek software'owych. Prace realizowano w modelu chmury hybrydowej łączącej lokalną serwerownię ŚCSI z klastrami w chmurze Microsoft Azure.
• Audyt śledczy ujawnił, że w celu "zagwarantowania stuprocentowej realności testów wydajnościowych i uniknięcia błędów parsowania struktur XML", kierownik projektu ze strony ŚCSI wykonał pełny zrzut produkcyjnej bazy danych PostgreSQL (o objętości 180 GB) i przesłał go nieszyfrowanym protokołem FTP na serwery deweloperskie wykonawcy w Azure.
• Kopia bazy produkcyjnej zawierająca rzeczywiste dane 450 tysięcy mieszkańców została następnie pobrana na laptopy 14 programistów konsorcjum, którzy prowadzili prace deweloperskie w trybie pracy zdalnej z domów. Żadne dane nie zostały poddane anonimizacji, pseudonimizacji ani maskowaniu.
• Analiza konfiguracji sieciowej wykazała, że między środowiskiem programistycznym (DEV w Azure) a produkcyjną bazą urzędu (PROD w Katowicach) zestawiono stały tunel VPN z otwartym routingiem dla portu 5432, a na serwerach deweloperskich i produkcyjnych obowiązywały identyczne poświadczenia konta 'postgres'.
• W trakcie testów obciążeniowych skrypt deweloperski, w wyniku pomyłki w pliku konfiguracyjnym connection string, połączył się bezpośrednio z bazą produkcyjną urzędu i zablokował tabele e-Doręczeń, co doprowadziło do utraty terminów odwoławczych dla 1200 beneficjentów dotacji termomodernizacyjnych i wstrzymania wypłat na kwotę 80 milionów PLN.
• Inspektor Ochrony Danych nie został poinformowany o transferze baz, a w umowach z wykonawcami brakowało jakichkolwiek klauzul regulujących procedury zarządzania danymi testowymi.

Marszałek Województwa powołuje Triadę Audytorską do przeprowadzenia strategicznego audytu separacji środowisk, wdrożenia potoków TDM i oceny ekspozycji prawnej urzędu na poziomie oceny 5.0 w formule 90 minut.

Zadanie realizowane jest w ścisłym reżimie warsztatowym (formuła 90 minut) przez Triadę Audytorską:

• Krok 1 (Podział ról w Triadzie Audytorskiej - Minuty 00-15):

  Student A (Lead Auditor / Reprezentant Marszałka i RODO): Analizuje umowy z konsorcjum IT, klauzule powierzenia przetwarzania danych, uprawnienia IOD, zgodność z wytycznymi UODO i EROD, ramy KRI, koordynuje matrycę 5x5 oraz przygotowuje Executive Summary dla Marszałka.

  Student B (Technical SecOps Auditor / Architekt Sieci i Cloud TDM): Bada reguły zapór sieciowych Azure/NSG, tunel VPN, tabele PostgreSQL, brak separacji VLAN, brak narzędzi maskowania danych, logi połączeń deweloperskich i projektuje potok generowania danych syntetycznych TDM.

  Student C (Change Governance & Compliance Auditor): Przeprowadza dekompozycję uchybień w modelu 4C, wylicza ryzyko w matrycy 5x5 (IR/RR) skorelowane ze wskaźnikami BCM (RTO=2h, RPO=1h, MTPD=4h), prowadzi dochodzenie 5 Why oraz konstruuje Trójfazowy Plan CAP ze wskaźnikami KPI/KRI. W zespole dwuosobowym obowiązki Roli C dzielą Studenci A i B.

• Krok 2 (Opracowanie Kanonicznej Karty Niezgodności 4C - Minuty 15-40):

  Sformułujcie kartę uchybienia krytycznego w modelu 4C:

• Krok 3 (Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM - Minuty 15-40):

  Skwantyfikujcie ryzyka w skali 25-stopniowej (P 1-5 x S 1-5):

• Krok 4 (Konstrukcja Trójfazowego Planu Działań Korygujących - CAP - Minuty 40-70):

  Opracujcie tabelę CAP w 3 horyzontach czasowych:

• Krok 5 (Sformalizowany Projekt Załącznika Wykonawczego SOP - Minuty 40-70):

  Zredagujcie sformalizowany akt normatywny: "Polityka Separacji Środowisk Teleinformatycznych oraz Bezpieczeństwa Danych Testowych w Urzędzie Marszałkowskim" (§ 1 Architektura 4 stref logicznych, § 2 Bezwzględny zakaz eksportu baz produkcyjnych, § 3 Standard generowania syntetycznych numerów PESEL i danych majątkowych, § 4 Procedury weryfikacji tożsamości wykonawców, § 5 Odpowiedzialność dyscyplinarna i umowna).

• Krok 6 (Opracowanie Podsumowania Zarządczego - Pitch to Board - Minuty 70-90):

  Przygotujcie 1-stronicowy briefing dla Marszałka Województwa syntetyzujący ryzyko pozwów odszkodowawczych na 45 mln PLN, bilans ryzyk przed i po audycie, koszt wdrożenia potoku TDM (180 tys. PLN) oraz korzyści ze stabilnego odblokowania 80 mln PLN dotacji unijnych.

Plan strategicznej obrony seminaryjnej przed komisją laboratoryjną (15 minut):

• Prezentacja Podsumowania Zarządczego (Pitch to Board) dla Marszałka (3 min): Przedstawienie skali ekspozycji prawnej, ryzyka utraty dotacji unijnych i bilansu ryzyk przed i po audycie (Student A - Lead Auditor).
• Dekonstrukcja incydentu technicznego: analiza zrzutu bazy 180 GB i braku barier sieciowych (4 min): Omówienie wycieku danych 450 tys. mieszkańców, otwartego portu 5432 i zablokowania produkcji przez skrypt testowy (Student B - Technical SecOps Auditor).
• Prezentacja Kanonicznej Karty Niezgodności 4C, analizy 5 Why i matrycy ryzyka 5x5 (4 min): Uzasadnienie kwalifikacji uchybień, korelacja z KRI i RODO art. 25/32 oraz wyliczenie redukcji ryzyka z IR=20 do RR=4 (Student C - Compliance Auditor).
• Prezentacja Trójfazowego Planu CAP i Załącznika Wykonawczego SOP (3 min): Szczegółowe omówienie etapów 0-7, 30 i 90 dni, architektury 4 stref oraz generatora danych syntetycznych TDM (Student B i Student C).
• Dyskusja z komisją i obrona rekomendacji (1 min): Odpowiedź na pytania dotyczące kosztów wdrożenia danych syntetycznych w relacji do kar UODO (cała Triada Audytorska).

Struktura raportu strategicznego na ocenę 5.0 (objętość 12-16 stron A4):

A. Podsumowanie Zarządcze (Executive Summary - "Pitch to Board") - 1 strona A4:

• Bilans ryzyk: redukcja 4 ryzyk krytycznych (IR>=16) do poziomu akceptowalnego (RR<=4).
• Ekspozycja prawno-finansowa: kary UODO (100 tys. PLN), potencjalne roszczenia cywilne mieszkańców (45 mln PLN), zablokowane dotacje (80 mln PLN).
• Kosztorys Planu CAP: 180 000 PLN (oprogramowanie TDM, rekonfiguracja sieci Azure/ZTNA, audyt umów).
• Korzyści biznesowe: Bezpieczne odblokowanie wypłat 80 mln PLN funduszy unijnych, eliminacja ryzyka pozwów i pełna zgodność z KRI.

B. Odpowiedzi na pytania problemowe i opis sytuacji kryzysowej:

• W jaki sposób zorganizować architekturę wielochmurową (Hybrid Cloud), aby wykluczyć możliwość penetracji środowiska produkcyjnego z poziomu środowisk deweloperskich?
• Czym charakteryzują się zaawansowane metodyki generowania danych syntetycznych (Generative Adversarial Networks / rule-based synthesis) i dlaczego przewyższają one tradycyjne maskowanie danych?
• Jakie klauzule bezpieczeństwa w zakresie TDM i zarządzania zmianami muszą zawierać umowy publiczne IT zgodnie z wytycznymi Urzędu Zamówień Publicznych?

C. Kanoniczna Karta Ustaleń Audytowych w Modelu 4C (Condition, Criteria, Cause, Consequence).

D. Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM (RTO=2h, RPO=1h, MTPD=4h).

E. Trójfazowy Plan Działań Korygujących (CAP) z macierzą RACI, wskaźnikami KPI i KRI.

F. Sformalizowany Projekt Załącznika Wykonawczego do Polityki Bezpieczeństwa Informacji (SOP).

G. Analiza zalet i ograniczeń wdrożeniowych architektury Zero-Trust i TDM.

H. Bibliografia i normy źródłowe.

• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.8.31 (Rozdzielenie środowisk programistycznych, testowych i operacyjnych), A.8.33 (Informacje testowe), A.8.32 (Zarządzanie zmianami).
• Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności (...) (Dz.U. z 2024 r. poz. 733) - par. 20 ust. 2 pkt 3 i 7.
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) - art. 5 ust. 1 lit. b, art. 25 (Privacy by Design), art. 32 (Bezpieczeństwo przetwarzania).
• Europejska Rada Ochrony Danych (EROD): "Wytyczne 4/2019 w sprawie uwzględniania ochrony danych w fazie projektowania i domyślnej ochrony danych", Bruksela 2020.
• European Union Agency for Cybersecurity (ENISA): "Data Pseudonymisation and Synthetic Data Generation: Best Practices for Developers", 2022.
• Ustawa z dnia 18 listopada 2020 r. o doręczeniach elektronicznych (Dz.U. z 2023 r. poz. 285 z późn. zm.).

• U2 Dekompozycja uchybień w modelu 4C i analiza przyczyn 5 Why w samorządowych rejestrach publicznych.
• U1 Projekt architektury 4-strefowej Zero-Trust oraz potoków generowania danych syntetycznych TDM.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 w ujęciu inherentnym i rezydualnym z powiązaniem ze wskaźnikami BCM.
• U4 Konstrukcja Trójfazowego Planu CAP oraz przygotowanie Executive Summary ("Pitch to Board").
• W1W2W3 Dogłębna znajomość rygorów KRI, RODO, Ustawy o doręczeniach elektronicznych i normy ISO 27001.
• K1K2K3 Obiektywizm audytorski, wrażliwość na ochronę prywatności obywateli i etyka służby publicznej.

W referacie skupcie się na zjawisku 'pozornego bezpieczeństwa umowy NDA' – wykażcie, dlaczego klauzula poufności nie zwalnia administratora z technicznego obowiązku ochrony danych testowych w świetle RODO i KRI.

Głównym celem strategicznego zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie zaawansowanego audytu ładu korporacyjnego procesu zarządzania zmianami (Change Management Governance), dojrzałości Komitetu Zarządzania Zmianami (Change Advisory Board - CAB), weryfikacji automatycznych bramek decyzyjnych Go/No-Go oraz egzekwowania bezwzględnego rozdziału obowiązków (Segregation of Duties - SoD) w banku komercyjnym o znaczeniu systemowym. Zadanie koncentruje się na badaniu wieloaspektowej zbieżności regulacyjnej: Rozporządzenia Parlamentu Europejskiego i Rady (UE) 2022/2554 (DORA - art. 9 i 12), Rekomendacji D i M Komisji Nadzoru Finansowego (KNF), standardu PCI DSS v4.0 oraz kontroli normy ISO/IEC 27001:2022 A.8.32 i A.5.3. Studenci badają sytuację awaryjną wywołaną samowolnym wdrożeniem oprogramowania Core Banking przez zespół deweloperski dysponujący nadmiarowymi uprawnieniami wdrożeniowymi, co spowodowało paraliż sesji rozliczeniowych Krajowej Izby Rozliczeniowej (KIR) oraz systemu SWIFT. Zadanie wymaga dekompozycji w modelu 4C, szacowania ryzyka w matrycy 5x5, analizy 5 Why, opracowania Trójfazowego Planu CAP oraz przygotowania Załącznika Wykonawczego i Podsumowania Zarządczego dla Zarządu Banku i Rady Nadzorczej.

Powiązanie z sylabusem i efektami kształcenia na ocenę 5.0:

• W1 Zaawansowana znajomość prawa bankowego, tajemnicy bankowej, rygorów rozliczeń międzybankowych i ochrony depozytów klientów.
• W2W3 Precyzyjna korelacja wymagań Rozporządzenia DORA (art. 9 i 12 - odporność ICT i zarządzanie zmianami), Rekomendacji D KNF (obszar rozwoju i wdrożeń IT), Rekomendacji M KNF (ryzyko operacyjne), standardu PCI DSS v4.0 oraz wytycznych EBA.
• U1 Opracowanie zintegrowanego ładu CAB Charter z techniczną bramką Change Gatekeeper wymuszającą kryptograficzny podpis wieloosobowy (Multi-Party Authorization) przed wdrożeniem.
• U2 Profesjonalne sformułowanie kart ustaleń w kanonicznym modelu 4C z precyzyjnym wskazaniem naruszeń DORA, KNF i norm ISO.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 (IR=20, RR=4) skorelowana ze wskaźnikami BCM: RTO=15m, RPO=0s, MTPD=30m dla sesji KIR Elixir.
• U4 Opracowanie Trójfazowego Planu Działań Korygujących (CAP) oraz 1-stronicowego briefingu zarządczego (Pitch to Board).
• K1K2K3 Niezależność audytorska, odporność na presję biznesową dążącą do przyspieszania wdrożeń kosztem bezpieczeństwa i etyka sektora zaufania publicznego.
• Powiązanie z wykładem: Wyk1 (Ład zarządczy i cyberodporność w sektorze bankowym), Wyk3 (Kontrole A.8.32 i A.5.3 ISO 27001), Wyk4 (DORA i Rekomendacja D KNF), Wyk5 (Matryca ryzyka 5x5 i BIA), Wyk6 (Analiza logów zatwierdzeń w systemach ITSM i Active Directory), Wyk7 (Model 4C, 5 Why i Trójfazowy CAP).

Vistula Bank S.A. jest bankiem komercyjnym o znaczeniu systemowym, obsługującym ponad 2,8 miliona klientów detalicznych i korporacyjnych, uczestniczącym bezpośrednio w rozliczeniach Krajowej Izby Rozliczeniowej (sesje Elixir i Express Elixir) oraz międzynarodowym systemie rozliczeń SWIFT. Bank przetwarza dziennie ponad 6 milionów transakcji finansowych o łącznej wartości przekraczającej 15 miliardów PLN.

Stan faktyczny w obszarze procesu Change Management i komitetu CAB:

• System bankowości centralnej (Core Banking) opiera się na klastrze wysokiej dostępności baz danych Oracle Database Enterprise Edition oraz warstwie mikroserwisów autoryzacyjnych.
• W ramach wdrażania nowej funkcjonalności płatności wielowalutowych i zgodności z normą ISO 20022 przygotowano pakiet modyfikacji bazy danych oznaczony jako Release 2026.3.
• Podczas audytu ustalono, że z powodu opóźnień w pracach projektowych i presji na uniknięcie kar kontraktowych zapisanych w umowach z partnerami biznesowymi, Dyrektor Pionu Wytwarzania Oprogramowania skorzystał z procedury "obejścia komitetu" (Fast-Track Override) i jednoosobowo zatwierdził wdrożenie w niedzielę o godzinie 23:00, nie zwołując posiedzenia Komitetu CAB i nie konsultując terminu z CISO ani Głównym Oficerem Ryzyka (CRO).
• Co gorsza, audyt uprawnień ujawnił rażącą kumulację ról i całkowity brak rozdziału obowiązków (Segregation of Duties - SoD): główny programista zespołu Core Banking posiadał w Active Directory i na serwerach produkcyjnych uprawnienia z grupy 'Domain Admins' oraz 'DBA', co umożliwiło mu samodzielne zbudowanie pakietu instalacyjnego, zatwierdzenie go i wgranie bezpośrednio na produkcję z pominięciem niezależnego zespołu wdrożeniowego.
• W rubryce "Ocena ryzyka ICT" wniosku RFC wpisano zdawkowe: "Zmiana o niskim stopniu skomplikowania, brak wpływu na stabilność". Nie przeprowadzono testów obciążeniowych imitujących poranny szczyt sesji Elixir, a testy integracyjne z węzłem KIR ograniczono do sprawdzenia 5 transakcji testowych.
• W poniedziałek o godzinie 07:30, w momencie otwarcia I sesji rozliczeniowej Elixir, nowy moduł wywołał błąd blokowania tabeli rozliczeń międzybankowych (row-level lock escalation). Spowodowało to zablokowanie kolejki komunikatów i natychmiastowe zerwanie łączności z węzłem KIR oraz siecią SWIFT.
• Klienci banku zostali odcięci od środków, nie zrealizowano 120 tysięcy przelewów gospodarczych o wartości 240 milionów PLN, a system odrzucił ponad 350 tysięcy transakcji kartowych i BLIK. Awaria trwała 18 godzin, wywołując kryzys płynnościowy, spadek kursu akcji banku o 8,5% oraz wszczęcie postępowania dyscyplinarnego przez Komisję Nadzoru Finansowego w związku z naruszeniem rygorów rozporządzenia DORA.

Rada Nadzorcza Banku powołuje Triadę Audytorską do przeprowadzenia strategicznego audytu śledczego procesów CAB, kontroli SoD i bramek wdrożeniowych na poziomie oceny 5.0 w formule 90 minut.

Zadanie realizowane jest w ścisłym reżimie warsztatowym (formuła 90 minut) przez Triadę Audytorską:

• Krok 1 (Podział ról w Triadzie Audytorskiej - Minuty 00-15):

  Student A (Lead Auditor / Reprezentant Rady Nadzorczej i CISO): Analizuje ład zarządczy banku, statut CAB, ramy prawne DORA (art. 9 i 12), Rekomendację D i M KNF, wytyczne EBA, koordynuje matrycę 5x5 oraz przygotowuje 1-stronicowe Executive Summary ("Pitch to Board") dla Zarządu i Rady Nadzorczej.

  Student B (Technical SecOps Auditor / Architekt Bezpieczeństwa Core Banking i SoD): Bada logi wdrożeniowe Oracle, uprawnienia w Active Directory, uprawnienia w repozytorium kodu, błąd lock escalation, brak testów obciążeniowych KIR i projektuje techniczną bramkę Change Gatekeeper z podpisem kryptograficznym.

  Student C (Change Governance & Compliance Auditor): Przeprowadza dekompozycję uchybień w modelu 4C, wylicza ryzyko w matrycy 5x5 (IR/RR) skorelowane ze wskaźnikami BCM (RTO=15m, RPO=0s, MTPD=30m), prowadzi analizę 5 Why oraz konstruuje Trójfazowy Plan CAP ze wskaźnikami KPI/KRI. W zespole dwuosobowym obowiązki Roli C dzielą Studenci A i B.

• Krok 2 (Opracowanie Kanonicznej Karty Niezgodności 4C - Minuty 15-40):

  Sformułujcie kartę uchybienia krytycznego w modelu 4C:

• Krok 3 (Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM - Minuty 15-40):

  Skwantyfikujcie ryzyka w skali 25-stopniowej (P 1-5 x S 1-5):

• Krok 4 (Konstrukcja Trójfazowego Planu Działań Korygujących - CAP - Minuty 40-70):

  Opracujcie tabelę CAP w 3 horyzontach czasowych:

• Krok 5 (Sformalizowany Projekt Załącznika Wykonawczego SOP - Minuty 40-70):

  Zredagujcie sformalizowany akt normatywny: "Regulamin Komitetu Zarządzania Zmianami oraz Zasady Rozdziału Obowiązków w Systemach Teleinformatycznych Vistula Bank S.A." (§ 1 Kworum i zasady posiedzeń CAB, § 2 Bezwzględne prawo weta CISO i CRO, § 3 Standard rozdziału ról SoD i zakaz uprawnień produkcyjnych dla deweloperów, § 4 Procedura technicznej bramki Go/No-Go, § 5 Odpowiedzialność karna i dyscyplinarna za ominięcie procedur).

• Krok 6 (Opracowanie Podsumowania Zarządczego - Pitch to Board - Minuty 70-90):

  Przygotujcie 1-stronicowy briefing dla Zarządu i Rady Nadzorczej podsumowujący ryzyko katastrofalne (IR=25), ekspozycję na kary KNF (do 10% obrotu), koszt wdrożenia CAP (650 tys. PLN) oraz korzyści z zabezpieczenia płynności i reputacji instytucji zaufania publicznego.

Plan strategicznej obrony seminaryjnej przed komisją laboratoryjną (15 minut):

• Prezentacja Podsumowania Zarządczego (Pitch to Board) dla Rady Nadzorczej (3 min): Przedstawienie skali ekspozycji regulacyjnej DORA, ryzyka utraty płynności i bilansu ryzyk przed i po audycie (Student A - Lead Auditor).
• Dekonstrukcja incydentu technicznego: analiza konfliktu SoD i blokady tabeli Oracle (4 min): Omówienie uprawnień Domain Admin programisty, błędu lock escalation, logów bazy i paraliżu węzła KIR (Student B - Technical SecOps Auditor).
• Prezentacja Kanonicznej Karty Niezgodności 4C, analizy 5 Why i matrycy ryzyka 5x5 (4 min): Uzasadnienie kwalifikacji uchybień, korelacja z rygorami DORA i Rekomendacji D KNF oraz wyliczenie redukcji ryzyka z IR=25 do RR=4 (Student C - Compliance Auditor).
• Prezentacja Trójfazowego Planu CAP i Załącznika Wykonawczego SOP (3 min): Szczegółowe omówienie etapów 0-7, 30 i 90 dni, technicznej bramki Change Gatekeeper z tokenami FIDO2 i matrycy SoD (Student B i Student C).
• Dyskusja z komisją i obrona rekomendacji (1 min): Odpowiedź na pytania dotyczące równoważenia zwinności wdrożeń fintechowych z rygorami stabilności bankowej (cała Triada Audytorska).

Struktura raportu strategicznego na ocenę 5.0 (objętość 12-16 stron A4):

A. Podsumowanie Zarządcze (Executive Summary - "Pitch to Board") - 1 strona A4:

• Bilans ryzyk: likwidacja ryzyka katastrofalnego (IR=25) i redukcja do poziomu akceptowalnego (RR<=4).
• Ekspozycja finansowo-regulacyjna: sankcje KNF (do 10% rocznego obrotu), utrata wartości giełdowej (spadek o 8,5%), zablokowane przelewy (240 mln PLN).
• Kosztorys Planu CAP: 650 000 PLN (oprogramowanie Change Gatekeeper FIDO2, audyt uprawnień IGA, symulator obciążenia KIR).
• Korzyści biznesowe: Zagwarantowanie stuprocentowej ciągłości rozliczeń KIR/SWIFT, odzyskanie zaufania akcjonariuszy i regulatora, pełna zgodność z DORA.

B. Odpowiedzi na pytania problemowe i opis sytuacji kryzysowej:

• W jaki sposób zorganizować funkcjonowanie komitetu CAB w instytucji finansowej, aby całkowicie uniemożliwić jednoosobowe zatwierdzanie ryzykownych wydań pod presją biznesową?
• Jakie bezwzględne wymagania w zakresie kontroli dostępu i separacji ról SoD nakłada na banki rozporządzenie DORA i Rekomendacja D KNF?
• Na czym polega wzorzec techniczny Multi-Party Authorization i jak integruje się go z potokami wdrożeniowymi Core Banking?

C. Kanoniczna Karta Ustaleń Audytowych w Modelu 4C (Condition, Criteria, Cause, Consequence).

D. Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM (RTO=15m, RPO=0s, MTPD=30m).

E. Trójfazowy Plan Działań Korygujących (CAP) z macierzą RACI, wskaźnikami KPI i KRI.

F. Sformalizowany Projekt Załącznika Wykonawczego do Polityki Bezpieczeństwa Informacji (SOP).

G. Analiza zalet i ograniczeń wdrożeniowych bramki Change Gatekeeper i matrycy SoD.

H. Bibliografia i normy źródłowe.

• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.8.32 (Zarządzanie zmianami), A.5.3 (Rozdzielenie obowiązków).
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 z dnia 14 grudnia 2022 r. w sprawie operacyjnej odporności cyfrowej sektora finansowego (DORA) - art. 9 i 12.
• Komisja Nadzoru Finansowego: "Rekomendacja D dotycząca zarządzania obszarami technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego w bankach", Warszawa 2013 (Obszar IV: Rozwój środowiska IT, pkt 8 i 11).
• Komisja Nadzoru Finansowego: "Rekomendacja M dotycząca zarządzania ryzykiem operacyjnym w bankach", Warszawa 2013.
• PCI Security Standards Council: "Payment Card Industry Data Security Standard (PCI DSS) Requirements and Testing Procedures v4.0", 2022 (Wymogi 6 i 8).
• European Banking Authority (EBA): "Guidelines on ICT and security risk management", EBA/GL/2019/04, Londyn 2019.

• U2 Dekompozycja uchybień w modelu 4C i dochodzenie przyczyn 5 Why w banku o znaczeniu systemowym.
• U1 Projekt statutu CAB Charter, technicznej bramki Change Gatekeeper oraz matrycy rozdziału ról SoD.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 w ujęciu inherentnym i rezydualnym z powiązaniem ze wskaźnikami BCM.
• U4 Konstrukcja Trójfazowego Planu CAP oraz przygotowanie Executive Summary ("Pitch to Board") dla Rady Nadzorczej.
• W1W2W3 Wyczerpująca znajomość rozporządzenia DORA, Rekomendacji D/M KNF, PCI DSS v4.0 i normy ISO 27001.
• K1K2K3 Niezależność audytorska, odporność na presję biznesową i najwyższa etyka zawodowa w sektorze finansowym.

Wystąpienie rozpocznijcie od briefingu 'Pitch to Board' dla Rady Nadzorczej – wskażcie, że zignorowanie komitetu CAB i kumulacja ról SoD naraziły bank na katastrofalne ryzyko utraty licencji i paraliżu rozliczeń międzybankowych.

Głównym celem strategicznego zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie zaawansowanego, symulowanego audytu procesów zarządzania zmianami konfiguracji, logiki sterowania i oprogramowania układowego (firmware) w środowiskach automatyki przemysłowej (Operational Technology - OT) oraz dyspozytorskich systemach telemetrycznych SCADA u operatora infrastruktury krytycznej o statusie Operatora Usługi Kluczowej (OUK). Zadanie koncentruje się na wieloaspektowej zbieżności regulacyjnej: Ustawy o Krajowym Systemie Cyberbezpieczeństwa (KSC), Dyrektywy NIS2, Dyrektywy CER (odporność podmiotów krytycznych), normy PN-EN IEC 62443 (części 2-4 i 3-3) oraz kontroli normy ISO/IEC 27001:2022 A.8.32. Studenci badają sytuację awaryjną wywołaną zdalną modyfikacją oprogramowania sterowników PLC na tłoczni gazu i węzłach ciepłowniczych w sezonie grzewczym, która doprowadziła do uderzenia hydraulicznego, rozszczelnienia rurociągów magistralnych i wstrzymania dostaw ciepła dla 180 tysięcy mieszkańców. Zadanie wymaga dekompozycji w modelu 4C, wyliczenia ryzyka w matrycy 5x5 w ujęciu safety/reliability, analizy 5 Why, opracowania Trójfazowego Planu CAP oraz przygotowania Załącznika Wykonawczego i Podsumowania Zarządczego dla Zarządu Przedsiębiorstwa i Wydziału Bezpieczeństwa Wojewody.

Powiązanie z sylabusem i efektami kształcenia na ocenę 5.0:

• W1 Zaawansowana znajomość rygorów bezpieczeństwa powszechnego, ochrony życia i zdrowia ludzkiego, prawa energetycznego oraz odpowiedzialności karnej i cywilnej za sprowadzenie niebezpieczeństwa katastrofy.
• W2W3 Dogłębna znajomość normy IEC 62443-2-4/3-3, Ustawy o KSC, Dyrektywy NIS2, Dyrektywy CER, modelu stref i kanałów (Purdue Model) oraz kontroli ISO/IEC 27001:2022 (A.8.32, A.8.9, A.8.14).
• U1 Zaprojektowanie zaawansowanej procedury Industrial Change Management z obligatoryjnym testowaniem zmian na stanowisku laboratoryjnym Hardware-in-the-Loop (HIL) oraz automatycznym wersjonowaniem kodów PLC.
• U2 Profesjonalne sformułowanie kart ustaleń w modelu 4C z precyzyjną referencją do standardów cyberbezpieczeństwa przemysłowego.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 (IR=20, RR=4) skorelowana ze wskaźnikami BCM: RTO=30m, RPO=0s, MTPD=2h dla infrastruktury magistralnej.
• U4 Opracowanie Trójfazowego Planu Działań Korygujących (CAP) oraz 1-stronicowego briefingu zarządczego (Pitch to Board).
• K1K2K3 Zrozumienie nadrzędności bezpieczeństwa fizycznego (safety) nad zwinnością IT, rzetelność inżynierska i etyka ochrony infrastruktury strategicznej.
• Powiązanie z wykładem: Wyk1 (Audyt w infrastrukturze krytycznej i OT), Wyk3 (Kontrola A.8.32 ISO 27001 a specyfika IEC 62443), Wyk4 (Ustawa o KSC, NIS2 i CER), Wyk5 (Matryca ryzyka 5x5 w przemyśle), Wyk6 (Analiza logów stacji inżynierskich, PLC i telemetrii SCADA), Wyk7 (Model 4C, 5 Why i Trójfazowy CAP).

Miejskie Przedsiębiorstwo Energetyki Cieplnej i Dystrybucji Gazu S.A. (MPEC-Gaz) zarządza strategiczną siecią ciepłowniczą o długości 240 km oraz siecią dystrybucji biometanu i gazu ziemnego zasilającą aglomerację liczącą 180 tysięcy mieszkańców, 4 szpitale kliniczne oraz zakłady przemysłowe. Spółka posiada status Operatora Usługi Kluczowej w rozumieniu Ustawy o KSC.

Stan faktyczny w obszarze procesu Change Management w warstwie automatyki OT:

• System nadzoru i sterowania opiera się na centralnej dyspozytorni SCADA komunikującej się za pośrednictwem redundantnych łączy światłowodowych i radiomodemów z 600 węzłami wymiennikowymi oraz 12 stacjami redukcyjno-tłocznymi gazu wyposażonymi w sterowniki logiczne PLC Siemens S7-1500 i Rockwell GuardLogix (układy bezpieczeństwa ESD).
• W środku sezonu zimowego (temperatura zewnętrzna -15°C) zewnętrzny inżynier serwisu automatyki, realizując zadanie optymalizacji zużycia gazu, połączył się zdalnie przez modem komórkowy LTE (bez MFA i bez rejestracji sesji) bezpośrednio ze stacją inżynierską tłoczni centralnej.
• Serwisant wgrał nową wersję oprogramowania układowego (firmware) do procesorów komunikacyjnych oraz zmodyfikował bloki funkcyjne regulacji ciśnienia gazu i temperatury zasilania magistrali ciepłowniczej. Modyfikację przeprowadzono w godzinach popołudniowych bez rejestracji wniosku w systemie ITSM, bez wyznaczonego okna serwisowego i bez jakiejkolwiek koordynacji z Głównym Dyspozytorem MPEC.
• Nowy algorytm regulatora PID zawierał krytyczny błąd w skalowaniu sygnałów przetworników ciśnienia, co wywołało gwałtowne, jednoczesne zamknięcie głównych zaworów dławiących. Doszło do uderzenia hydraulicznego: ciśnienie w magistrali ciepłowniczej wzrosło skokowo do 24 barów (przy ciśnieniu roboczym 16 barów), powodując rozerwanie rurociągu magistralnego DN 600 oraz zalanie komory ciepłowniczej wrzątkiem.
• W tym samym czasie w stacji gazowej błędny firmware zawiesił komunikację Modbus TCP, co uniemożliwiło dyspozytorom zdalne odcięcie dopływu paliwa. Co gorsza, serwisant nie wykonał kopii zapasowej poprzedniego kodu PLC przed aktualizacją (brak backupu logicznego), a w przedsiębiorstwie brak było systemu kontroli wersji automatyki przemysłowej (np. VersionDog).
• W rezultacie nastąpiła 36-godzinna przerwa w dostawach ciepła i gazu dla 60 tysięcy mieszkańców w warunkach silnego mrozu, konieczność ewakuacji dwóch domów pomocy społecznej, straty materialne rzędu 4,5 mln PLN oraz wszczęcie postępowania powypadkowego przez Urząd Dozoru Technicznego (UDT) i Prokuraturę.

Zarząd Spółki powołuje Triadę Audytorską do przeprowadzenia strategicznego audytu procedur Industrial Change Management na poziomie oceny 5.0 w formule 90 minut.

Zadanie realizowane jest w ścisłym reżimie warsztatowym (formuła 90 minut) przez Triadę Audytorską:

• Krok 1 (Podział ról w Triadzie Audytorskiej - Minuty 00-15):

  Student A (Lead Auditor / Reprezentant Zarządu i OUK): Analizuje procedury nadrzędne OUK, ład BCM/Safety, rygory Ustawy o KSC, Dyrektywy NIS2 i CER, umowy serwisowe, koordynuje matrycę 5x5 oraz przygotowuje Executive Summary dla Zarządu i Wojewody.

  Student B (Technical SecOps Auditor / Architekt Automatyki OT/SCADA): Bada architekturę sieci wg modelu Purdue, logi stacji inżynierskiej, błędy bloków funkcyjnych PLC, komunikację Modbus TCP, brak procedury rollback, brak blokad kluczykowych i projektuje stanowisko testowe HIL.

  Student C (Change Governance & Compliance Auditor): Przeprowadza dekompozycję uchybień w modelu 4C, wylicza ryzyko w matrycy 5x5 (IR/RR) skorelowane ze wskaźnikami BCM (RTO=30m, RPO=0s, MTPD=2h), prowadzi analizę 5 Why oraz konstruuje Trójfazowy Plan CAP ze wskaźnikami KPI/KRI. W zespole dwuosobowym obowiązki Roli C dzielą Studenci A i B.

• Krok 2 (Opracowanie Kanonicznej Karty Niezgodności 4C - Minuty 15-40):

  Sformułujcie kartę uchybienia krytycznego w modelu 4C:

• Krok 3 (Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM - Minuty 15-40):

  Skwantyfikujcie ryzyka w skali 25-stopniowej (P 1-5 x S 1-5):

• Krok 4 (Konstrukcja Trójfazowego Planu Działań Korygujących - CAP - Minuty 40-70):

  Opracujcie tabelę CAP w 3 horyzontach czasowych:

• Krok 5 (Sformalizowany Projekt Załącznika Wykonawczego SOP - Minuty 40-70):

  Zredagujcie sformalizowany akt normatywny: "Instrukcja Zarządzania Zmianami i Wdrożeniami w Układach Automatyki Przemysłowej i Telemetrii SCADA MPEC-Gaz S.A." (§ 1 Klasyfikacja zmian w warstwie OT, § 2 Obowiązkowe okna serwisowe poza sezonem grzewczym, § 3 Procedura testów na stanowisku HIL, § 4 Autoryzacja dyspozytorska i kontrola kluczyków PLC, § 5 Procedury awaryjnego sterowania manualnego Manual Fallback).

• Krok 6 (Opracowanie Podsumowania Zarządczego - Pitch to Board - Minuty 70-90):

  Przygotujcie 1-stronicowy briefing dla Zarządu i Wojewody syntetyzujący ryzyko katastrofy budowlanej i prawnej (do 15 mln PLN), bilans ryzyk przed i po audycie, koszt wdrożenia CAP (380 tys. PLN na system VersionDog i stanowisko HIL) oraz gwarancję bezpiecznych dostaw ciepła dla 180 tys. mieszkańców.

Plan strategicznej obrony seminaryjnej przed komisją laboratoryjną (15 minut):

• Prezentacja Podsumowania Zarządczego (Pitch to Board) dla Zarządu MPEC (3 min): Przedstawienie skali ekspozycji operacyjnej i prawnej OUK, bilansu ryzyk przed i po audycie oraz znaczenia infrastruktury krytycznej (Student A - Lead Auditor).
• Dekonstrukcja incydentu technicznego: analiza uderzenia hydraulicznego i logów PLC (4 min): Omówienie błędu bloku PID, skoku ciśnienia do 24 barów, awarii Modbus i podatności modemu LTE (Student B - Technical SecOps Auditor).
• Prezentacja Kanonicznej Karty Niezgodności 4C, analizy 5 Why i matrycy ryzyka 5x5 (4 min): Uzasadnienie kwalifikacji uchybień, korelacja z normą IEC 62443, Ustawą o KSC i Kodeksem Karnym oraz wyliczenie redukcji ryzyka z IR=20 do RR=4 (Student C - Compliance Auditor).
• Prezentacja Trójfazowego Planu CAP i Załącznika Wykonawczego SOP (3 min): Szczegółowe omówienie etapów 0-7, 30 i 90 dni, stanowiska HIL, systemu VersionDog i blokad kluczykowych (Student B i Student C).
• Dyskusja z komisją i obrona rekomendacji (1 min): Odpowiedź na pytania dotyczące specyfiki procedur bezpieczeństwa OT w relacji do tradycyjnego IT (cała Triada Audytorska).

Struktura raportu strategicznego na ocenę 5.0 (objętość 12-16 stron A4):

A. Podsumowanie Zarządcze (Executive Summary - "Pitch to Board") - 1 strona A4:

• Bilans ryzyk: redukcja ryzyk krytycznych i katastrofalnych (IR>=16) do poziomu akceptowalnego (RR<=4).
• Ekspozycja prawno-finansowa: straty bezpośrednie w sieci (4,5 mln PLN), kary URE i KSC (do 10 mln EUR), odpowiedzialność karna za sprowadzenie niebezpieczeństwa powszechnego (art. 163 KK).
• Kosztorys Planu CAP: 380 000 PLN (zakup systemu VersionDog, budowa stanowiska HIL, wdrożenie bramy PAM OT).
• Korzyści biznesowe: Zagwarantowanie stuprocentowego bezpieczeństwa hydraulicznego sieci, wyeliminowanie ryzyka przerw w dostawach ciepła, spełnienie rygorów NIS2/CER.

B. Odpowiedzi na pytania problemowe i opis sytuacji kryzysowej:

• Dlaczego wdrożenie zmian w systemach automatyki przemysłowej OT wymaga odmiennej filozofii niż w klasycznym IT i dlaczego paradygmat Safety przeważa nad paradygmatem Confidentiality?
• W jaki sposób stanowisko testowe Hardware-in-the-Loop (HIL) symuluje dynamikę przepływów hydraulicznych i gazowych w warunkach laboratoryjnych?
• Jakie mechanizmy obrony w głąb (Defense-in-Depth) zgodnie z normą IEC 62443 chronią sterowniki PLC przed nieautoryzowanym przeprogramowaniem?

C. Kanoniczna Karta Ustaleń Audytowych w Modelu 4C (Condition, Criteria, Cause, Consequence).

D. Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM (RTO=30m, RPO=0s, MTPD=2h).

E. Trójfazowy Plan Działań Korygujących (CAP) z macierzą RACI, wskaźnikami KPI i KRI.

F. Sformalizowany Projekt Załącznika Wykonawczego do Polityki Bezpieczeństwa Informacji i Automatyki (SOP).

G. Analiza zalet i ograniczeń wdrożeniowych procedur Industrial Change Management.

H. Bibliografia i normy źródłowe.

• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.8.32 (Zarządzanie zmianami), A.8.9 (Zarządzanie konfiguracją), A.8.14 (Redundancja urządzeń).
• Norma PN-EN IEC 62443-2-4:2019: Bezpieczeństwo systemów automatyki i sterowania przemysłowego - Wymagania dotyczące programu bezpieczeństwa dla dostawców usług utrzymania.
• Norma PN-EN IEC 62443-3-3:2019: Bezpieczeństwo systemów automatyki i sterowania przemysłowego - Wymagania dotyczące bezpieczeństwa systemu i poziomy bezpieczeństwa.
• Ustawa z dnia 5 lipca 2018 r. o Krajowym Systemie Cyberbezpieczeństwa (Dz.U. z 2023 r. poz. 913 z późn. zm.).
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2557 z dnia 14 grudnia 2022 r. w sprawie odporności podmiotów krytycznych (Dyrektywa CER).
• Ustawa z dnia 6 czerwca 1997 r. - Kodeks Karny (Dz.U. z 2024 r. poz. 17) - art. 163 (Sprowadzenie zdarzenia powszechnie niebezpiecznego).
• NIST Special Publication 800-82 Rev. 3: "Guide to Operational Technology (OT) Security", Gaithersburg 2023.

• U2 Dekompozycja uchybień w modelu 4C i dochodzenie przyczyn 5 Why w infrastrukturze przemysłowej OT/SCADA.
• U1 Projekt procedury Industrial Change Management, stanowiska HIL oraz architektury VersionDog.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 w ujęciu inherentnym i rezydualnym z powiązaniem ze wskaźnikami BCM.
• U4 Konstrukcja Trójfazowego Planu CAP oraz przygotowanie Executive Summary ("Pitch to Board") dla Zarządu i Wojewody.
• W1W2W3 Dogłębna znajomość normy IEC 62443, Ustawy o KSC, Dyrektywy NIS2/CER i normy ISO 27001.
• K1K2K3 Zrozumienie nadrzędności bezpieczeństwa fizycznego (safety), rzetelność inżynierska i etyka audytora infrastruktury krytycznej.

W referacie skupcie się na wykazaniu, że wdrożenie procedury fizycznej blokady kluczykowej na sterownikach PLC oraz testów HIL to jedyny sposób na wyeliminowanie ryzyka katastrof technologicznych wywoływanych przez zdalnych serwisantów.

Głównym celem strategicznego zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie zaawansowanego audytu procesów ciągłej integracji i ciągłego wdrażania (CI/CD) w metodyce DevSecOps, mechanizmów ochrony łańcucha dostaw oprogramowania (Software Supply Chain Security wg frameworku SLSA), automatycznych bramek bezpieczeństwa (Security Quality Gates) oraz architektury zarządzania sekretami w licencjonowanej instytucji płatniczej przetwarzającej dane kartowe w chmurze hybrydowej AWS-Kubernetes. Zadanie bada wieloaspektową zbieżność regulacyjną: standardu PCI DSS v4.0 (wymogi 6 i 8), Rozporządzenia DORA (art. 9 i 12), standardu SOC 2 Type II (kryteria Security i Availability), wytycznych EBA ds. outsourcingu chmurowego oraz kontroli normy ISO/IEC 27001:2022 A.8.25, A.8.28 i A.8.32. Studenci badają sytuację kryzysową wywołaną wstrzyknięciem złośliwego pakietu do repozytorium zależności w potoku CI/CD oraz wyciekiem zahardkodowanych kluczy administracyjnych AWS IAM, co doprowadziło do kompromitacji 120 tysięcy numerów kart płatniczych i zablokowania procesowania płatności przez organizacje płatnicze. Zadanie wymaga dekompozycji w modelu 4C, szacowania ryzyka w matrycy 5x5, analizy 5 Why, opracowania Trójfazowego Planu CAP oraz przygotowania Załącznika Wykonawczego i Podsumowania Zarządczego dla Zarządu Fintechu i Komitetu Bezpieczeństwa.

Powiązanie z sylabusem i efektami kształcenia na ocenę 5.0:

• W1 Zaawansowana znajomość ochrony danych uwierzytelniających posiadaczy kart (Cardholder Data / Sensitive Authentication Data), rygorów ustawy o usługach płatniczych oraz kar organizacji kartowych (Visa/Mastercard).
• W2W3 Dogłębna znajomość standardu PCI DSS v4.0, rozporządzenia DORA, standardu SOC 2 Type II, frameworku Supply-chain Levels for Software Artifacts (SLSA v1.0), normy ISO 27001:2022 (A.8.25, A.8.28, A.8.32) oraz modelu OWASP SAMM.
• U1 Zaprojektowanie bezpiecznej architektury potoku DevSecOps z nieprzekraczalnymi bramkami jakościowymi (SAST/DAST/SCA), podpisem kryptograficznym artefaktów Cosign/Sigstore oraz centralnym magazynem sekretów HashiCorp Vault.
• U2 Profesjonalne udokumentowanie uchybień w kanonicznym modelu 4C z precyzyjną referencją do wymogów PCI DSS v4.0 i DORA.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 (IR=20, RR=4) skorelowana ze wskaźnikami BCM: RTO=15m, RPO=0s, MTPD=1h dla bramek płatniczych.
• U4 Opracowanie Trójfazowego Planu Działań Korygujących (CAP) oraz 1-stronicowego briefingu zarządczego (Pitch to Board).
• K1K2K3 Niezależność audytorska, wysoka kultura inżynierii bezpieczeństwa oprogramowania, odporność na presję tempa wdrożeń i rzetelność badania kodu.
• Powiązanie z wykładem: Wyk1 (Audyt bezpieczeństwa w chmurze i fintechach), Wyk3 (Kontrole A.8.25, A.8.28 i A.8.32 ISO 27001), Wyk4 (PCI DSS v4.0 i DORA), Wyk5 (Matryca ryzyka 5x5 i BIA), Wyk6 (Analiza plików YAML potoków CI/CD, historii commitów git i logów AWS CloudTrail), Wyk7 (Model 4C, 5 Why i Trójfazowy CAP).

Krajowa Platforma Płatnicza S.A. (Pay-Platform) jest wiodącym polskim fintechem i Krajową Instytucją Płatniczą przetwarzającą transakcje e-commerce dla ponad 8000 sklepów internetowych, obsługującą bramki płatności kartowych, transakcje BLIK oraz płatności odroczone (BNPL). Spółka przetwarza miesięcznie ponad 8 milionów transakcji o wartości przekraczającej 2,5 miliarda PLN. Infrastruktura działa w chmurze publicznej AWS w oparciu o zarządzany klaster orkiestracji kontenerów Amazon EKS, bazy danych Amazon RDS PostgreSQL oraz dedykowany sprzętowy moduł bezpieczeństwa AWS CloudHSM w wydzielonym środowisku Cardholder Data Environment (CDE).

Stan faktyczny w obszarze procesu CI/CD i incydentu łańcucha dostaw:

• Wdrożenia mikrousług na środowisko produkcyjne EKS realizowane są automatycznie za pośrednictwem potoków GitLab CI/CD w modelu ciągłego wdrażania (do 25 wdrożeń na dobę).
• W trakcie audytu bezpieczeństwa procesu zarządzania zmianą zespół audytorski przeanalizował konfigurację potoków (`.gitlab-ci.yml`), polityki ochrony gałęzi oraz rejestr kontenerów Amazon ECR.
• Ustalono, że 6 miesięcy wcześniej, po skargach zespołów produktowych na opóźnienia w premierach nowych funkcji sklepu, Lead Architect wyłączył w potoku etapy analizy statycznej kodu (SAST - SonarQube) oraz analizy bezpieczeństwa komponentów open-source (SCA - Snyk/Trivy).
• Co więcej, w głównym repozytorium wyłączono ochronę gałęzi `main` (Branch Protection), zezwalając każdemu programiście na bezpośredni push do gałęzi produkcyjnej bez wymogu utworzenia Merge Requesta i bez recenzji kodu (brak zasady Peer Review).
• Skutkiem braku kontroli był atak na łańcuch dostaw oprogramowania: jeden z programistów dodał do projektu publiczny pakiet npm służący rzekomo do walidacji numerów kart, który okazał się zainfekowany złośliwym kodem (atak typu Typosquatting). Złośliwy pakiet zawierał moduł kradzieży danych (Memory Scraper), który przechwytywał numery PAN i kody CVV2 bezpośrednio z pamięci kontenera przed ich zaszyfrowaniem w CloudHSM.
• Ponadto, w celu "ułatwienia debugowania w chmurze", deweloper umieścił w pliku konfiguracyjnym w repozytorium git produkcyjne klucze AWS IAM (`AccessKeyId` i `SecretAccessKey`) z uprawnieniami administratora klastra EKS. Złośliwy kod wyeksfiltrował klucze na zewnętrzny serwer C2, co umożliwiło napastnikom pobranie bazy transakcyjnej i kradzież danych 120 tysięcy kart płatniczych.
• Wyciek został wykryty dopiero po 12 dniach przez systemy antyfraudowe organizacji Visa i Mastercard. Organizacje płatnicze nałożyły na Pay-Platform kary w łącznej wysokości 3,5 mln EUR, cofnęły certyfikację PCI DSS v4.0, a KNF wszczął procedurę zawieszenia licencji KIP.

Zarząd Spółki powołuje Triadę Audytorską do przeprowadzenia strategicznego audytu potoków DevSecOps, łańcucha dostaw oprogramowania i zarządzania sekretami na poziomie oceny 5.0 w formule 90 minut.

Zadanie realizowane jest w ścisłym reżimie warsztatowym (formuła 90 minut) przez Triadę Audytorską:

• Krok 1 (Podział ról w Triadzie Audytorskiej - Minuty 00-15):

  Student A (Lead Auditor / Reprezentant CISO i PCI QSA): Analizuje ramy regulacyjne PCI DSS v4.0 (wymóg 6 i 8), Rozporządzenie DORA (art. 9 i 12), standard SOC 2 Type II, wytyczne EBA, koordynuje matrycę 5x5 oraz przygotowuje Executive Summary dla Zarządu i audytora PCI QSA.

  Student B (Technical SecOps Auditor / Architekt Chmury AWS, Kubernetes i DevSecOps): Bada konfigurację GitLab CI/CD, historię commitów, mechanizmy ochrony gałęzi, konfigurację EKS/ECR, analizuje złośliwy pakiet npm, logi CloudTrail i projektuje architekturę potoku DevSecOps z integracją HashiCorp Vault i Cosign.

  Student C (Change Governance & Compliance Auditor): Przeprowadza dekompozycję uchybień w modelu 4C, wylicza ryzyko w matrycy 5x5 (IR/RR) skorelowane ze wskaźnikami BCM (RTO=15m, RPO=0s, MTPD=1h), prowadzi analizę 5 Why oraz konstruuje Trójfazowy Plan CAP ze wskaźnikami KPI/KRI. W zespole dwuosobowym obowiązki Roli C dzielą Studenci A i B.

• Krok 2 (Opracowanie Kanonicznej Karty Niezgodności 4C - Minuty 15-40):

  Sformułujcie kartę uchybienia krytycznego w modelu 4C:

• Krok 3 (Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM - Minuty 15-40):

  Skwantyfikujcie ryzyka w skali 25-stopniowej (P 1-5 x S 1-5):

• Krok 4 (Konstrukcja Trójfazowego Planu Działań Korygujących - CAP - Minuty 40-70):

  Opracujcie tabelę CAP w 3 horyzontach czasowych:

• Krok 5 (Sformalizowany Projekt Załącznika Wykonawczego SOP - Minuty 40-70):

  Zredagujcie sformalizowany akt normatywny: "Standard Bezpiecznego Wytwarzania i Wdrażania Oprogramowania (Secure SDLC & DevSecOps Policy) w Pay-Platform S.A." (§ 1 Zasady ochrony gałęzi i recenzji kodu Peer Review, § 2 Standardy bramek Security Quality Gates w CI/CD, § 3 Weryfikacja łańcucha dostaw i framework SLSA, § 4 Bezwzględny zakaz przechowywania sekretów w repozytoriach i obsługa HashiCorp Vault, § 5 Procedury audytu zgodności z PCI DSS v4.0).

• Krok 6 (Opracowanie Podsumowania Zarządczego - Pitch to Board - Minuty 70-90):

  Przygotujcie 1-stronicowy briefing dla Zarządu podsumowujący ryzyko katastrofalne (IR=25), ekspozycję na kary Visa/Mastercard (3,5 mln EUR) i pozwy (25 mln PLN), koszt wdrożenia CAP (450 tys. PLN) oraz odzyskanie certyfikacji PCI DSS i ochrona licencji KIP.

Plan strategicznej obrony seminaryjnej przed komisją laboratoryjną (15 minut):

• Prezentacja Podsumowania Zarządczego (Pitch to Board) dla Zarządu Fintechu (3 min): Przedstawienie skali ekspozycji regulacyjnej PCI DSS/KNF, kar finansowych i bilansu ryzyk przed i po audycie (Student A - Lead Auditor).
• Dekonstrukcja incydentu technicznego: analiza ataku na łańcuch dostaw npm i wycieku kluczy IAM (4 min): Omówienie wyłączonych skanerów w `.gitlab-ci.yml`, mechanizmu kradzieży danych z pamięci kontenera i logów CloudTrail (Student B - Technical SecOps Auditor).
• Prezentacja Kanonicznej Karty Niezgodności 4C, analizy 5 Why i matrycy ryzyka 5x5 (4 min): Uzasadnienie kwalifikacji uchybień, korelacja z PCI DSS v4.0, DORA i normą ISO 27001 oraz wyliczenie redukcji ryzyka z IR=25 do RR=4 (Student C - Compliance Auditor).
• Prezentacja Trójfazowego Planu CAP i Załącznika Wykonawczego SOP (3 min): Szczegółowe omówienie etapów 0-7, 30 i 90 dni, bramek SonarQube/Cosign, repozytorium HashiCorp Vault i prywatnego rejestru pakietów (Student B i Student C).
• Dyskusja z komisją i obrona rekomendacji (1 min): Odpowiedź na pytania dotyczące integracji bezpieczeństwa z szybkim tempem wydań w architekturze mikrousługowej (cała Triada Audytorska).

Struktura raportu strategicznego na ocenę 5.0 (objętość 12-16 stron A4):

A. Podsumowanie Zarządcze (Executive Summary - "Pitch to Board") - 1 strona A4:

• Bilans ryzyk: likwidacja ryzyka katastrofalnego (IR=25) i redukcja do poziomu akceptowalnego (RR<=4).
• Ekspozycja finansowo-regulacyjna: kary organizacji płatniczych (3,5 mln EUR), pozwy odszkodowawcze (25 mln PLN), ryzyko cofnięcia licencji KIP przez KNF.
• Kosztorys Planu CAP: 450 000 PLN (licencje HashiCorp Vault Enterprise, narzędzia Snyk/Cosign, audyt PCI QSA).
• Korzyści biznesowe: Odzyskanie certyfikacji PCI DSS v4.0, pełna ochrona danych kartowych 8000 sklepów, zgodność z DORA i SOC 2.

B. Odpowiedzi na pytania problemowe i opis sytuacji kryzysowej:

• W jaki sposób zaimplementować framework Supply-chain Levels for Software Artifacts (SLSA) w chmurze Kubernetes, aby zagwarantować niezmienność i integralność kodu od commitu do wdrożenia produkcyjnego?
• Jakie techniczne środki kontrolne uniemożliwiają wyciek sekretów chmurowych (AWS IAM, klucze API) do repozytoriów git i jak egzekwować pre-commit hooki w rozproszonym zespole deweloperskim?
• W jaki sposób standard PCI DSS v4.0 definiuje wymagania dotyczące automatycznego skanowania podatności i testów penetracyjnych w zwinnych procesach CI/CD?

C. Kanoniczna Karta Ustaleń Audytowych w Modelu 4C (Condition, Criteria, Cause, Consequence).

D. Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM (RTO=15m, RPO=0s, MTPD=1h).

E. Trójfazowy Plan Działań Korygujących (CAP) z macierzą RACI, wskaźnikami KPI i KRI.

F. Sformalizowany Projekt Załącznika Wykonawczego do Polityki Bezpieczeństwa Informacji (SOP).

G. Analiza zalet i ograniczeń wdrożeniowych architektury DevSecOps i HashiCorp Vault.

H. Bibliografia i normy źródłowe.

• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.8.25 (Bezpieczny cykl życia rozwoju), A.8.28 (Bezpieczne kodowanie), A.8.32 (Zarządzanie zmianami).
• PCI Security Standards Council: "Payment Card Industry Data Security Standard (PCI DSS) Requirements and Testing Procedures v4.0", 2022 (Wymogi 6 i 8).
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 (DORA) - art. 9 (Ochrona i zapobieganie), art. 12 (Zarządzanie zmianami ICT).
• OpenSSF (Open Source Security Foundation): "Supply-chain Levels for Software Artifacts (SLSA) Specification v1.0", 2023.
• American Institute of CPAs (AICPA): "SOC 2 - Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy", 2022.
• NIST Special Publication 800-204C: "Implementation of DevSecOps for a Microservices-based Application", Gaithersburg 2022.

• U2 Dekompozycja uchybień w modelu 4C i dochodzenie przyczyn 5 Why w chmurowym ekosystemie fintechu.
• U1 Projekt potoku DevSecOps z bramkami Quality Gates, architekturą Vault i frameworkiem SLSA.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 w ujęciu inherentnym i rezydualnym z powiązaniem ze wskaźnikami BCM.
• U4 Konstrukcja Trójfazowego Planu CAP oraz przygotowanie Executive Summary ("Pitch to Board") dla Zarządu.
• W1W2W3 Dogłębna znajomość rygorów PCI DSS v4.0, DORA, SOC 2 Type II, normy ISO 27001 i standardów SLSA.
• K1K2K3 Profesjonalizm audytorski, wysoka kultura inżynierska i etyka ochrony danych finansowych.

Podczas obrony referatu zademonstrujcie na slajdach, w jaki sposób implementacja podpisywania kontenerów Cosign oraz blokady SLSA uniemożliwia uruchomienie w klastrze produkcyjnym jakiegokolwiek kodu, który nie przeszedł zielonych testów SAST i SCA.

Głównym celem strategicznego zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie zaawansowanego, symulowanego audytu procesów zarządzania konfiguracją i zmianami (Configuration & Change Management) w węźle centralnym administracji publicznej RP - Centralnym Ośrodku Informatyki (COI) obsługującym System Rejestrów Państwowych (SRP), Rejestr PESEL, Rejestr Dowodów Osobistych oraz aplikację mObywatel. Instytucja przetwarza dane tożsamości ponad 38 milionów obywateli i obsługuje dziesiątki tysięcy zapytań na sekundę generowanych przez banki, e-administrację, policję i placówki medyczne. Studenci wcielają się w rolę Triady Audytorskiej badającej incydent wdrożenia nowej wersji mikroserwisu integracyjnego API Gateway w chmurze rządowej, która z powodu błędnej definicji zależności w federacyjnej bazie CMDB i braku testów kanarkowych (Canary Deployment) doprowadziła do rozsynchronizowania replikacji danych PESEL, zawieszenia uwierzytelniania w aplikacji mObywatel oraz uniemożliwienia załatwienia spraw urzędowych przez 2,4 miliona obywateli w całym kraju. Zadanie wymaga przeprowadzenia dekompozycji uchybień w kanonicznym modelu 4C (Condition, Criteria, Cause, Consequence), wyliczenia ryzyka w 25-stopniowej matrycy 5x5 skorelowanej ze wskaźnikami BCM (RTO=10m, RPO=0s, MTPD=30m), opracowania Trójfazowego Planu Działań Korygujących (CAP) ze wskaźnikami KPI i KRI, sformułowania sformalizowanego Załącznika Wykonawczego (SOP) oraz przygotowania Podsumowania Zarządczego (Executive Summary - "Pitch to Board") dla Kolegium Ministra Cyfryzacji.

Powiązanie z sylabusem i efektami kształcenia na ocenę 5.0:

• W1 Ochrona tajemnicy państwowej, danych tożsamości milionów obywateli (RODO), ciągłości funkcjonowania państwa w warunkach cyberkryzysu oraz odpowiedzialności kierowników jednostek sektora finansów publicznych.
• W2W3 Rygorystyczna korelacja wymagań Rozporządzenia Rady Ministrów w sprawie Krajowych Ram Interoperacyjności (KRI), Dyrektywy NIS2 (Podmiot Kluczowy Administracji Publicznej), Ustawy o informatyzacji działalności podmiotów realizujących zadania publiczne, normy ISO/IEC 20000-1 (zarządzanie konfiguracją i wydaniami) oraz wytycznych NIST SP 800-128 (Configuration Management for Information Systems).
• U1 Opracowanie zintegrowanego modelu wdrożeń kanarkowych (Canary Releases) w środowisku SRE połączonego z automatycznym wycofywaniem zmian (Automated Rollback upon Error Budget Burn Rate) oraz synchronizacją bazy CMDB.
• U2 Bezbłędna identyfikacja i formalna kwalifikacja uchybień w kanonicznym modelu 4C z precyzyjnym powołaniem artykułów prawa i punktów norm.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 dla wektorów desynchronizacji tożsamości obywateli i paraliżu e-państwa w ujęciu ryzyka inherentnego (IR) i rezydualnego (RR) z powiązaniem ze wskaźnikami RTO=10m, RPO=0s, MTPD=30m.
• U4 Opracowanie Trójfazowego Planu Działań Korygujących (CAP) ze wskaźnikami KPI i KRI oraz 1-stronicowego briefingu zarządczego (Pitch to Board).
• K1K2K3 Poczucie odpowiedzialności za bezpieczeństwo narodowe, obiektywizm audytorski w relacjach z administracją rządową i bezkompromisowa rzetelność zawodowa.
• Powiązanie z wykładem: Wyk1 (Audyt w administracji rządowej i NIS2), Wyk3 (Kontrole A.8.9 Zarządzanie konfiguracją i A.8.32 ISO 27001), Wyk4 (KRI i Ustawa o informatyzacji), Wyk5 (Matryca ryzyka 5x5 i SRE Error Budgets), Wyk6 (Analiza CMDB, CI/CD i logów API Gateway), Wyk7 (Model 4C, 5 Why i Trójfazowy CAP).

Centralny Ośrodek Informatyki (COI) jako państwowa jednostka budżetowa podległa Ministerstwu Cyfryzacji odpowiada za rozwój i utrzymanie kluczowych rejestrów państwowych Rzeczypospolitej Polskiej, w tym Systemu Rejestrów Państwowych (SRP obejmującego Rejestr PESEL, Rejestr Dowodów Osobistych, Rejestr Stanu Cywilnego) oraz Węzła Krajowego Identyfikacji Elektronicznej i ekosystemu aplikacji mObywatel. Z infrastruktury COI korzysta codziennie ponad 2500 urzędów gmin, policja, straż graniczna, sądy oraz sektor bankowy poprzez Węzeł Tożsamości.

Stan faktyczny w obszarze procesu wdrażania zmian i incydentu krajowego:

• W ramach projektu optymalizacji ruchu wprowadzono nową wersję mikroserwisu integracyjnego API Gateway (v3.4.0) obsługującego zapytania o dane PESEL i certyfikaty tożsamości mDowód. Zmiana miała charakter "Major Change" i została zatwierdzona na posiedzeniu Komitetu Zmian COI w trybie standardowym.
• Podczas planowania wdrożenia inżynierowie pominęli audyt powiązań w federacyjnej bazie CMDB. Baza CMDB nie była aktualizowana od 7 miesięcy i nie zawierała informacji o zmianie formatu nagłówków sesyjnych w klastrze bazodanowym PostgreSQL BDR (Bidirectional Replication) utrzymywanym w ośrodku zapasowym (DRC).
• Zespół wdrożeniowy, dążąc do zminimalizowania okna serwisowego, podjął decyzję o rezygnacji ze stopniowego wdrożenia kanarkowego (Canary Deployment 5% -> 25% -> 100%) i wdrożył wersję v3.4.0 od razu na 100% węzłów produkcyjnych w obu centrach danych jednocześnie o godzinie 03:00 w nocy.
• O godzinie 07:30, wraz z rozpoczęciem pracy urzędów w całej Polsce i logowaniem milionów użytkowników do mObywatela, wystąpiła masowa awaria kaskadowa: nowe API Gateway generowało błędy parsowania tokenów JWT, co doprowadziło do zakleszczenia kolejek transakcyjnych Kafka i przerwania dwukierunkowej replikacji danych między centrum podstawowym a zapasowym.
• W urzędach gmin wstrzymano wydawanie dowodów osobistych i rejestrację pojazdów dla 80 tysięcy osób. Aplikacja mObywatel wyświetlała użytkownikom błąd uwierzytelnienia "Brak połączenia z rejestrem centralnym". Banki komercyjne odrzuciły ponad 400 tysięcy prób weryfikacji tożsamości klientów przy wnioskach kredytowych.
• Próba natychmiastowego rollbacku nie powiodła się, ponieważ skrypt wycofujący nie uwzględniał migracji schematu bazy danych wykonanej przez v3.4.0 (uszkodzenie integralności więzów relacyjnych w klastrze BDR). Czas przywracania pełnej spójności rejestrów wyniósł 14 godzin.

Kolegium Ministra Cyfryzacji zleca niezależnej Triadzie Audytorskiej przeprowadzenie pilnego audytu strategicznego procesów Change & Configuration Management w formule 90 minut.

Zadanie realizowane jest w ścisłym reżimie warsztatowym (formuła 90 minut) przez 2-3 osobową Triadę Audytorską:

• Krok 1 (Podział ról w Triadzie Audytorskiej - Minuty 00-15):

  Student A (Lead Auditor / Główny Audytor Rządowy): Bada ład korporacyjny i procedury Change Advisory Board w jednostkach sektora finansów publicznych, zgodność z KRI i Dyrektywą NIS2, relacje z Ministerstwem Cyfryzacji i CSIRT GOV, koordynuje matrycę 5x5 oraz opracowuje Podsumowanie Zarządcze ("Pitch to Board").

  Student B (Technical SecOps Auditor / Architekt SRE i Chmury Rządowej): Analizuje logi klastra Kafka, błędy tokenów JWT w API Gateway, niespójność replikacji PostgreSQL BDR, brak skryptów idempotencji migracji schematów oraz projektuje architekturę wdrożeń kanarkowych Canary z metrykami Prometheus i automatycznym rollbackiem opartym na Error Budget.

  Student C (Change Governance & Compliance Auditor): Bada aktualność i integralność bazy CMDB (relacje CI), weryfikuje zgodność z normą ISO 20000-1 i NIST SP 800-128, prowadzi dochodzenie przyczyn w modelu 4C i sekwencji 5 Why oraz konstruuje Trójfazowy Plan CAP z przypisaniem ról RACI i wskaźników KPI/KRI. W zespole dwuosobowym obowiązki Roli C dzielą Studenci A i B.

• Krok 2 (Opracowanie Kanonicznej Karty Niezgodności 4C - Minuty 15-40):

  Sformułujcie kartę uchybienia krytycznego w modelu 4C:

• Krok 3 (Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM - Minuty 15-40):

  Skwantyfikujcie ryzyka w 25-stopniowej skali (P 1-5 x S 1-5):

• Krok 4 (Konstrukcja Trójfazowego Planu Działań Korygujących - CAP - Minuty 40-70):

  Opracujcie tabelę CAP w 3 horyzontach czasowych:

• Krok 5 (Sformalizowany Projekt Załącznika Wykonawczego SOP - Minuty 40-70):

  Zredagujcie sformalizowany akt normatywny: "Standard Zarządzania Zmianami i Konfiguracją w Systemach Rejestrów Państwowych RP" z numerowanymi artykułami (§ 1 Zasada ciągłości działania rejestrów centralnych, § 2 Obowiązkowa weryfikacja integralności CMDB przed akceptacją RFC, § 3 Standard wdrożeń kanarkowych Canary Releases i budżety błędów SRE, § 4 Wymóg dwukierunkowej idempotencji skryptów migracji bazodanowych i testy rollbacku, § 5 Odpowiedzialność dyscyplinarna i nadzór CSIRT GOV).

• Krok 6 (Opracowanie Podsumowania Zarządczego - Pitch to Board - Minuty 70-90):

  Przygotujcie 1-stronicowy dokument dla Kolegium Ministra Cyfryzacji syntetyzujący bilans ryzyk przed i po audycie, koszt wdrożenia CAP (1,2 mln PLN w ramach budżetu transformacji cyfrowej), uniknięcie kar KSC/NIS2 (do 10 mln EUR) oraz strategiczne zabezpieczenie suwerenności cyfrowej i zaufania obywateli do państwa.

Plan strategicznej obrony seminaryjnej przed komisją laboratoryjną (15 minut):

• Prezentacja Podsumowania Zarządczego (Pitch to Board) dla Kierownictwa Resortu (3 min): Skala incydentu krajowego, ekspozycja na ryzyka państwowe i bilans korzyści z wdrożenia Planu CAP (Student A - Lead Auditor).
• Dekonstrukcja incydentu technicznego: błędy API Gateway, mechanizm replikacji BDR i upadek CMDB (4 min): Omówienie błędu parsowania JWT, rozsynchronizowania baz danych i braku procedury rollback migracji DDL (Student B - Technical SecOps Auditor).
• Prezentacja Kanonicznej Karty Niezgodności 4C, analizy 5 Why i matrycy ryzyka 5x5 (4 min): Uzasadnienie kwalifikacji uchybień, korelacja z KRI, NIS2 i ISO 20000-1 oraz wyliczenie redukcji ryzyka z IR=20 do RR=4 (Student C - Compliance Auditor).
• Prezentacja Trójfazowego Planu CAP i Standardu Wykonawczego SOP (3 min): Szczegółowe omówienie etapów 0-7, 30 i 90 dni, architektury wdrożeń kanarkowych i automatyzacji CMDB (Student B i Student C).
• Dyskusja z komisją i obrona rekomendacji (1 min): Odpowiedź na pytania dotyczące równowagi między szybkością dostarczania e-usług a stabilnością rejestrów krytycznych (cała Triada Audytorska).

Struktura raportu strategicznego na ocenę 5.0 (objętość 12-16 stron A4):

A. Podsumowanie Zarządcze (Executive Summary - "Pitch to Board") - 1 strona A4:

• Bilans ryzyk: likwidacja ryzyk krytycznych (IR=20) i redukcja do poziomu akceptowalnego (RR<=4).
• Wymiar prawno-polityczny: ryzyko sankcji z Ustawy o KSC/NIS2, odpowiedzialność z Ustawy o finansach publicznych, utrata zaufania społecznego do e-państwa.
• Kosztorys Planu CAP: 1 200 000 PLN (automatyzacja CMDB, platforma obserwowalności OpenTelemetry/Prometheus, audyt DR klastra BDR).
• Korzyści państwowe: Gwarancja ciągłości działania Węzła Krajowego (dostępność 99.99%), eliminacja okien awaryjnych i pełna zgodność z KRI.

B. Odpowiedzi na pytania problemowe i opis sytuacji kryzysowej:

• W jaki sposób zaimplementować architekturę automatycznego wykrywania zasobów (Discovery) i powiązań w bazie CMDB, aby wyeliminować błędy wdrożeniowe wynikające z braku wiedzy o architekturze ośrodka zapasowego?
• Jakie parametry metryk SLI/SLO i budżetów błędów (Error Budget Burn Rate) w metodyce SRE powinny automatycznie inicjować procedurę awaryjnego rollbacku podczas wdrożeń kanarkowych mikroserwisów?
• W jaki sposób zapewnić niezawodność i dwukierunkowość migracji schematów baz danych (Flyway/Liquibase) w rozproszonych klastrach replikacji multi-master w administracji rządowej?

C. Kanoniczna Karta Ustaleń Audytowych w Modelu 4C (Condition, Criteria, Cause, Consequence).

D. Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM (RTO=10m, RPO=0s, MTPD=30m).

E. Trójfazowy Plan Działań Korygujących (CAP) z macierzą RACI, wskaźnikami KPI i KRI.

F. Sformalizowany Projekt Załącznika Wykonawczego do Polityki Bezpieczeństwa Informacji (SOP).

G. Analiza zalet i ograniczeń wdrożeniowych architektury SRE, modeli Canary Releases i automatycznej bazy CMDB.

H. Bibliografia i normy źródłowe.

• Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności (Dz.U. z 2017 r. poz. 2247 z późn. zm.).
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (NIS2) - podmioty kluczowe administracji publicznej.
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.8.9 (Zarządzanie konfiguracją), A.8.31 (Rozdzielenie środowisk), A.8.32 (Zarządzanie zmianami).
• Norma PN-ISO/IEC 20000-1:2018: System zarządzania usługami informatycznymi - Część 1: Wymagania (Rozdział 8.5.1 i 8.5.2).
• NIST Special Publication 800-128: "Guide for Security-Focused Configuration and Change Management in Information Systems", Gaithersburg 2019.
• Beyer B., Jones C., Petoff J., Murphy N. R.: "Site Reliability Engineering: How Google Runs Production Systems", O'Reilly Media 2016.

• U2 Dekompozycja uchybień w modelu 4C i analiza przyczyn 5 Why w architekturze rejestrów państwowych.
• U1 Projekt architektury wdrożeń kanarkowych Canary i automatycznego wycofywania zmian w oparciu o wskaźniki SRE.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 w ujęciu inherentnym i rezydualnym z powiązaniem ze wskaźnikami BCM.
• U4 Konstrukcja Trójfazowego Planu CAP oraz przygotowanie Executive Summary ("Pitch to Board") dla Kolegium Ministra.
• W1W2W3 Biegła znajomość wymogów KRI, NIS2, normy ISO 20000-1, wytycznych NIST SP 800-128 i zasad ochrony rejestrów państwowych.
• K1K2K3 Poczucie odpowiedzialności za bezpieczeństwo narodowe, wysoka etyka służby publicznej i rzetelność audytorska.

Podczas obrony referatu przedstawcie architekturę automatycznej pętli zwrotnej wdrożenia kanarkowego, demonstrując jak metryka Error Budget z systemu Prometheus automatycznie cofa ruch na API Gateway w czasie poniżej 90 sekund bez udziału człowieka.

Głównym celem strategicznego zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie zaawansowanego, symulowanego audytu procedur testowania akceptacyjnego (UAT) oraz zarządzania procedurami wycofania zmian (Rollback & Point of No Return) w Sądowym Centrum Teleinformatyki (SCT) obsługującym system CURIA/Portal Informacyjny Sądów Powszechnych dla 11 Sądów Apelacyjnych i 46 Sądów Okręgowych. System odpowiada za rejestrację spraw, przydział sędziów (SLPS - System Losowego Przydziału Spraw), zarządzanie wokandami oraz publikację orzeczeń i doręczenia pism procesowych. Studenci wcielają się w rolę Triady Audytorskiej badającej incydent nocnej migracji schematu relacyjnej bazy danych Microsoft SQL Server Enterprise, podczas której wprowadzono nieprzetestowany indeks unikalny uniemożliwiający rejestrację aktów oskarżenia i wniosków o areszt tymczasowy. Z powodu przekroczenia okna serwisowego i braku zdefiniowanego Punktu Bezpowrotu (Point of No Return) podjęto próbę awaryjnego cofnięcia transakcji, która uszkodziła dziennik logów LDF i doprowadziła do 3-dniowego paraliżu wymiaru sprawiedliwości oraz wyjścia na wolność 4 osób podejrzanych o ciężkie przestępstwa z powodu upływu konstytucyjnego terminu 48 godzin na wniesienie aresztu (art. 41 i art. 45 Konstytucji RP). Zadanie wymaga przeprowadzenia dekompozycji uchybień w kanonicznym modelu 4C, wyliczenia ryzyka w 25-stopniowej matrycy 5x5 skorelowanej ze wskaźnikami BCM (RTO=1h, RPO=0s, MTPD=4h), opracowania Trójfazowego Planu Działań Korygujących (CAP) ze wskaźnikami KPI i KRI, sformułowania sformalizowanego Załącznika Wykonawczego (SOP) oraz przygotowania Podsumowania Zarządczego (Executive Summary - "Pitch to Board") dla Kolegium Prezesów Sądów i Krajowej Rady Sądownictwa.

Powiązanie z sylabusem i efektami kształcenia na ocenę 5.0:

• W1 Znajomość konstytucyjnych praw obywateli do sprawiedliwego sądu (art. 45 Konstytucji RP), terminów aresztowych (art. 41 Konstytucji RP), przepisów Kodeksu Postępowania Karnego oraz odpowiedzialności karnej i dyscyplinarnej sędziów i urzędników.
• W2W3 Rygorystyczna korelacja wymagań KRI, normy ISO/IEC 27001:2022 (kontrole A.8.29 Testowanie akceptacyjne, A.8.32 Zarządzanie zmianami), standardów ISTQB/ISO 29119 w inżynierii testów oraz wytycznych NIST SP 800-64.
• U1 Opracowanie zintegrowanej procedury UAT obejmującej symulację pełnego obciążenia procesowego, automatyczną weryfikację integralności schematu bazy danych oraz ścisłą procedurę decyzyjną "Go/No-Go" z rygorystycznym Punktem Bezpowrotu (Point of No Return).
• U2 Bezbłędna identyfikacja i formalna kwalifikacja uchybień w kanonicznym modelu 4C z precyzyjnym powołaniem artykułów prawa procesowego i punktów norm.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 dla wektorów paraliżu konstytucyjnych terminów procesowych i uszkodzenia bazy sądowej w ujęciu inherentnym (IR) i rezydualnym (RR) z powiązaniem ze wskaźnikami RTO=1h, RPO=0s, MTPD=4h.
• U4 Opracowanie Trójfazowego Planu Działań Korygujących (CAP) ze wskaźnikami KPI i KRI oraz 1-stronicowego briefingu zarządczego (Pitch to Board).
• K1K2K3 Bezstronność i niezależność audytorska, odporność na presję hierarchiczną aparatu sędziowskiego i głębokie poszanowanie praworządności.
• Powiązanie z wykładem: Wyk1 (Audyt w wymiarze sprawiedliwości), Wyk3 (Kontrole A.8.29 i A.8.32 ISO 27001), Wyk4 (Konstytucja RP, KRI i KPK), Wyk5 (Matryca ryzyka 5x5 i BIA), Wyk6 (Analiza logów MSSQL, testów UAT i planów wdrożeń), Wyk7 (Model 4C, 5 Why i Trójfazowy CAP).

Sądowe Centrum Teleinformatyki (SCT) przy Sądzie Apelacyjnym we Wrocławiu odpowiada za infrastrukturę teleinformatyczną wspierającą orzecznictwo sądowe w całym okręgu apelacyjnym. Centralnym narzędziem pracy orzeczniczej jest zintegrowany system CURIA połączony z Portalem Informacyjnym, Krajowym Rejestrem Karnym (KRK) oraz Centralną Bazą Orzeczeń Sądów Powszechnych.

Stan faktyczny w obszarze procesu wdrażania zmian i incydentu orzeczniczego:

• W ramach dostosowania do nowelizacji Kodeksu Postępowania Cywilnego zaplanowano wdrożenie pakietu zmian CURIA v8.2, obejmującego m.in. zmianę struktury tabeli 'Orzeczenia_Postanowienia' oraz założenie unikalnego indeksu kompozytowego na numerach spraw i sygnaturach akt w bazie Microsoft SQL Server Always On.
• Testy akceptacyjne (UAT) zostały skrócone z planowanych 14 dni do 2 dni roboczych pod presją terminu wejścia w życie ustawy. W testach wzięło udział jedynie 3 pracowników sekretariatu, którzy zweryfikowali interfejs graficzny na 15 przykładowych sprawach cywilnych, całkowicie pomijając testy wydajnościowe, testy spraw karnych oraz testy mechanizmu SLPS.
• Plan wdrożenia zakładał 4-godzinne okno serwisowe w nocy z piątku na sobotę (22:00 - 02:00). W planie nie zdefiniowano krytycznego parametru "Point of No Return" (godziny granicznej, po przekroczeniu której zmiana musi zostać natychmiast cofnięta lub kontynuowana z pełną determinacją).
• O godzinie 01:45 podczas uruchamiania skryptu T-SQL na produkcji baza zgłosiła błąd naruszenia unikalności indeksu ("Violation of UNIQUE KEY constraint") z powodu obecności historycznych rekordów spraw połączonych z lat 2012-2015. Zamiast natychmiastowego przerwania procedury, inżynierowie zewnętrznego integratora kontynuowali próby manualnej edycji danych przez kolejne 5 godzin bez autoryzacji ze strony CAB.
• O godzinie 07:00, zdając sobie sprawę z niemożności ukończenia wdrożenia przed otwarciem sądów, integrator uruchomił niedopracowany skrypt rollbacku, który z powodu przerwania transakcji doprowadził do przejścia bazy danych w stan 'Recovery Pending' i uszkodzenia pliku dziennika transakcji (LDF).
• Skutki incydentu były katastrofalne: przez kolejne 72 godziny żaden sąd w okręgu nie był w stanie zarejestrować wpływu spraw ani wylosować składu orzekającego. W trzech sądach rejonowych upłynął 48-godzinny termin konstytucyjny na rozpoznanie wniosków prokuratury o zastosowanie aresztu tymczasowego wobec 4 podejrzanych o handel narkotykami i rozboje, w wyniku czego osoby te musiały zostać zwolnione z aresztu.

Prezes Sądu Apelacyjnego wraz z Krajową Radą Sądownictwa powołuje Triadę Audytorską do przeprowadzenia bezwzględnego audytu procesów UAT i Rollback Management w formule 90 minut.

Zadanie realizowane jest w ścisłym reżimie warsztatowym (formuła 90 minut) przez 2-3 osobową Triadę Audytorską:

• Krok 1 (Podział ról w Triadzie Audytorskiej - Minuty 00-15):

  Student A (Lead Auditor / Sędziowski Audytor Wiodący): Odpowiada za analizę zgodności z przepisami Kodeksu Postępowania Karnego i Cywilnego, art. 41 i 45 Konstytucji RP, regulaminem wewnętrznym urzędowania sądów, koordynację matrycy 5x5 oraz przygotowanie Executive Summary ("Pitch to Board") dla Prezesa Sądu i KRS.

  Student B (Technical SecOps Auditor / Architekt Baz Danych i Testów): Bada błędy indeksów kompozytowych MSSQL, przyczyny uszkodzenia logu transakcyjnego LDF, stan 'Recovery Pending', procedury Always On Availability Groups, analizuje skrypty T-SQL i projektuje procedury testów UAT zgodnie z normą ISO/IEC/IEEE 29119 oraz rygory technologiczne Point of No Return.

  Student C (Change Governance & Compliance Auditor): Weryfikuje dokumentację UAT, protokoły akceptacji, ład decyzyjny komitetu CAB, prowadzi dochodzenie przyczyn w modelu 4C i sekwencji 5 Why oraz konstruuje Trójfazowy Plan CAP z przypisaniem ról RACI i wskaźników KPI/KRI. W zespole dwuosobowym obowiązki Roli C dzielą Studenci A i B.

• Krok 2 (Opracowanie Kanonicznej Karty Niezgodności 4C - Minuty 15-40):

  Sformułujcie kartę uchybienia krytycznego w modelu 4C:

• Krok 3 (Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM - Minuty 15-40):

  Skwantyfikujcie ryzyka w 25-stopniowej skali (P 1-5 x S 1-5):

• Krok 4 (Konstrukcja Trójfazowego Planu Działań Korygujących - CAP - Minuty 40-70):

  Opracujcie tabelę CAP w 3 horyzontach czasowych:

• Krok 5 (Sformalizowany Projekt Załącznika Wykonawczego SOP - Minuty 40-70):

  Zredagujcie sformalizowany akt normatywny: "Procedura Zarządzania Testami Akceptacyjnymi, Oknami Serwisowymi i Punktem Bezpowrotu (Point of No Return) w Systemach Sądowych CURIA" z numerowanymi artykułami (§ 1 Bezwzględne pierwszeństwo terminów konstytucyjnych, § 2 Standard środowiska UAT i protokoły zdawczo-odbiorcze, § 3 Definicja, wyliczanie i egzekwowanie Punktu Bezpowrotu, § 4 Zgoda S-CAB na przedłużenie okna serwisowego, § 5 Kary umowne i odpowiedzialność odszkodowawcza dostawców).

• Krok 6 (Opracowanie Podsumowania Zarządczego - Pitch to Board - Minuty 70-90):

  Przygotujcie 1-stronicowy dokument dla Prezesa Sądu i Kolegium Sędziów syntetyzujący eliminację ryzyka katastrofalnego (IR=25 -> RR=4), koszt wdrożenia CAP (380 tys. PLN), uniknięcie odpowiedzialności odszkodowawczej Skarbu Państwa (szacowanej na miliony złotych) oraz gwarancję nienaruszalności konstytucyjnych praw obywateli.

Plan strategicznej obrony seminaryjnej przed komisją laboratoryjną (15 minut):

• Prezentacja Podsumowania Zarządczego (Pitch to Board) dla Prezesa Sądu (3 min): Wymiar konstytucyjny incydentu, analiza zagrożenia praworządności i bilans ryzyk (Student A - Lead Auditor).
• Dekonstrukcja incydentu technicznego: analiza błędu indeksu MSSQL i uszkodzenia pliku LDF (4 min): Omówienie błędu unikalności, braku izolacji transakcji, mechanizmu Point of No Return i stanu Recovery Pending (Student B - Technical SecOps Auditor).
• Prezentacja Kanonicznej Karty Niezgodności 4C, analizy 5 Why i matrycy ryzyka 5x5 (4 min): Uzasadnienie kwalifikacji uchybień, korelacja z art. 41/45 Konstytucji RP, ISO 27001 i ISO 29119 oraz wyliczenie redukcji ryzyka z IR=25 do RR=4 (Student C - Compliance Auditor).
• Prezentacja Trójfazowego Planu CAP i Standardu Wykonawczego SOP (3 min): Szczegółowe omówienie etapów 0-7, 30 i 90 dni, procedury awaryjnej "czerwonej teczki" i regulaminu S-CAB (Student B i Student C).
• Dyskusja z komisją i obrona rekomendacji (1 min): Odpowiedź na pytania dotyczące formalnoprawnych barier we wdrażaniu rygorów technicznych w strukturach wymiaru sprawiedliwości (cała Triada Audytorska).

Struktura raportu strategicznego na ocenę 5.0 (objętość 12-16 stron A4):

A. Podsumowanie Zarządcze (Executive Summary - "Pitch to Board") - 1 strona A4:

• Bilans ryzyk: likwidacja ryzyka katastrofalnego (IR=25) i redukcja do poziomu akceptowalnego (RR<=4).
• Wymiar konstytucyjny i prawny: naruszenie art. 41 i 45 Konstytucji RP, odpowiedzialność dyscyplinarna, ryzyko odszkodowań od Skarbu Państwa.
• Kosztorys Planu CAP: 380 000 PLN (klaster Pre-Production 1:1, narzędzia do automatycznych testów migracji baz, audyt ISTQB).
• Korzyści ustrojowe: Pełna ochrona konstytucyjnych terminów aresztowych, eliminacja awarii w sądownictwie i przywrócenie powagi wymiaru sprawiedliwości.

B. Odpowiedzi na pytania problemowe i opis sytuacji kryzysowej:

• W jaki sposób matematycznie i operacyjnie wyznaczać Punkt Bezpowrotu (Point of No Return) w oknach serwisowych wdrożeń relacyjnych baz danych o wysokim wolumenie transakcji?
• Jakie rygorystyczne kryteria wejścia (Entry Criteria) i wyjścia (Exit Criteria) zgodnie ze standardem ISO/IEC/IEEE 29119 muszą zostać spełnione przed podpisaniem protokołu odbioru testów UAT oprogramowania sądowego?
• W jaki sposób zorganizować procedurę awaryjną (Paper Fallback) dla obsługi pilnych wniosków aresztowych w prokuraturach i sądach w sytuacji całkowitej niedostępności systemów teleinformatycznych?

C. Kanoniczna Karta Ustaleń Audytowych w Modelu 4C (Condition, Criteria, Cause, Consequence).

D. Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM (RTO=1h, RPO=0s, MTPD=4h).

E. Trójfazowy Plan Działań Korygujących (CAP) z macierzą RACI, wskaźnikami KPI i KRI.

F. Sformalizowany Projekt Załącznika Wykonawczego do Polityki Bezpieczeństwa Informacji (SOP).

G. Analiza zalet i ograniczeń wdrożeniowych środowisk Pre-Production 1:1 oraz metodyki Point of No Return.

H. Bibliografia i normy źródłowe.

• Konstytucja Rzeczypospolitej Polskiej z dnia 2 kwietnia 1997 r. (Dz.U. z 1997 r. Nr 78, poz. 483 z późn. zm.) - art. 41 i 45.
• Ustawa z dnia 6 czerwca 1997 r. - Kodeks postępowania karnego (Dz.U. z 2022 r. poz. 1375 z późn. zm.).
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.8.29 (Testowanie w rozwoju i akceptacji), A.8.32 (Zarządzanie zmianami).
• Norma ISO/IEC/IEEE 29119: "Software and Systems Engineering - Software Testing" (Part 1-4).
• Rozporządzenie Ministra Sprawiedliwości - Regulamin ogólny urzędowania sądów powszechnych.
• ISTQB: "Standard Glossary of Terms used in Software Testing & Certified Tester Advanced Level Syllabus: Test Manager", 2022.

• U2 Dekompozycja uchybień w modelu 4C i analiza przyczyn 5 Why w infrastrukturze sądownictwa.
• U1 Projekt procesu testów akceptacyjnych UAT oraz procedury wyznaczania Punktu Bezpowrotu (Point of No Return).
• U3 Kwantyfikacja ryzyka w matrycy 5x5 w ujęciu inherentnym i rezydualnym z powiązaniem ze wskaźnikami BCM.
• U4 Konstrukcja Trójfazowego Planu CAP oraz przygotowanie Executive Summary ("Pitch to Board") dla Prezesa Sądu i KRS.
• W1W2W3 Dogłębna znajomość rygorów konstytucyjnych, KRI, normy ISO 27001, standardów ISO 29119 oraz zasad orzecznictwa.
• K1K2K3 Niezależność audytorska, odporność na naciski środowiskowe i wysokie poczucie etyki państwowej.

W referacie skupcie się na graficznym przedstawieniu osi czasu okna serwisowego z wyraźnie zaznaczonym Punktem Bezpowrotu, demonstrując krytyczny błąd decyzyjny integratora, który przekroczył czas graniczny o 5 godzin.

Głównym celem strategicznego zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie zaawansowanego, symulowanego audytu procesów zarządzania zmianami pochodzącymi od zewnętrznych dostawców usług ICT (Third-Party SaaS Change Management) w Towarzystwie Ubezpieczeń Cyfrowych S.A. Instytucja podlega rygorystycznemu reżimowi Rozporządzenia DORA, Wytycznym Komisji Nadzoru Finansowego (KNF) dla zakładów ubezpieczeń oraz standardom Europejskiego Urzędu Nadzoru Ubezpieczeń i Pracowniczych Programów Emerytalnych (EIOPA). Towarzystwo eksploatuje zintegrowaną platformę likwidacji szkód komunikacyjnych i majątkowych połączoną przez interfejsy API z chmurowymi serwisami zewnętrznymi: wyceny wartości pojazdów (SaaS Info-Ekspert), weryfikacji polis w Ubezpieczeniowym Funduszu Gwarancyjnym (UFG) oraz modułem szybkich wypłat odszkodowań (SaaS Payment Hub). Studenci wcielają się w rolę Triady Audytorskiej badającej incydent nagłego wycofania wsparcia dla protokołu TLS 1.2 i zmiany formatu obiektów JSON w API dostawcy SaaS Info-Ekspert, o czym dostawca powiadomił jednostronnie z 30-dniowym wyprzedzeniem w stopce biuletynu technicznego. Dział IT ubezpieczyciela nie zarejestrował wniosku RFC, co spowodowało odcięcie komunikacji z serwisem wycen, zawieszenie procesowania 18 000 wniosków o odszkodowania, awarię kaskadową wewnętrznych mikroserwisów z powodu braku wzorca Circuit Breaker oraz przekroczenie ustawowych terminów 30 dni na wypłatę świadczeń. Zadanie wymaga przeprowadzenia dekompozycji uchybień w kanonicznym modelu 4C, wyliczenia ryzyka w 25-stopniowej matrycy 5x5 skorelowanej ze wskaźnikami BCM (RTO=30m, RPO=0s, MTPD=2h), opracowania Trójfazowego Planu Działań Korygujących (CAP) ze wskaźnikami KPI i KRI, sformułowania sformalizowanego Załącznika Wykonawczego (SOP) oraz przygotowania Podsumowania Zarządczego (Executive Summary - "Pitch to Board") dla Zarządu Towarzystwa i Rady Nadzorczej.

Powiązanie z sylabusem i efektami kształcenia na ocenę 5.0:

• W1 Ochrona praw ubezpieczonych, odpowiedzialność cywilna i regulacyjna za nieterminową likwidację szkód (art. 14 Ustawy o ubezpieczeniach obowiązkowych) oraz kary KNF i Rzecznika Finansowego.
• W2W3 Rygorystyczna korelacja wymagań Rozporządzenia DORA (art. 28-44 Zarządzanie ryzykiem ze strony zewnętrznych dostawców usług ICT, art. 9 i 12 Zarządzanie zmianami ICT), Wytycznych KNF w sprawie zarządzania obszarami technologii informacyjnej w zakładach ubezpieczeń, wytycznych EIOPA oraz normy ISO/IEC 27001:2022 (kontrole A.5.19, A.5.21, A.8.32).
• U1 Opracowanie zintegrowanej procedury monitorowania zmian zewnętrznych dostawców (Vendor Change Advisory Process) powiązanej z architekturą odpornościową Circuit Breaker i automatycznym fallbackiem do tabel referencyjnych offline.
• U2 Bezbłędna identyfikacja i formalna kwalifikacja uchybień w kanonicznym modelu 4C z precyzyjnym powołaniem artykułów prawa ubezpieczeniowego i unijnego.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 dla wektorów paraliżu likwidacji szkód i sankcji nadzorczych w ujęciu inherentnym (IR) i rezydualnym (RR) z powiązaniem ze wskaźnikami RTO=30m, RPO=0s, MTPD=2h.
• U4 Opracowanie Trójfazowego Planu Działań Korygujących (CAP) ze wskaźnikami KPI i KRI oraz 1-stronicowego briefingu zarządczego (Pitch to Board).
• K1K2K3 Obiektywizm audytorski, bezkompromisowa ocena zależności od dostawców chmurowych (Vendor Lock-in) i wysoka kultura zarządzania ryzykiem operacyjnym.
• Powiązanie z wykładem: Wyk1 (Audyt w instytucjach finansowych DORA/KNF), Wyk3 (Kontrole A.5.19, A.5.21 i A.8.32 ISO 27001), Wyk4 (DORA i wytyczne KNF), Wyk5 (Matryca ryzyka 5x5 i wzorce Cloud Resiliency), Wyk6 (Analiza umów SLA/OLA, logów API i metryk Circuit Breaker), Wyk7 (Model 4C, 5 Why i Trójfazowy CAP).

Towarzystwo Ubezpieczeń Cyfrowych S.A. jest jednym z wiodących zakładów ubezpieczeń majątkowych i osobowych w Polsce, obsługującym ponad 2,5 miliona aktywnych polis. Główną przewagą rynkową towarzystwa jest w pełni zautomatyzowana likwidacja szkód komunikacyjnych za pośrednictwem platformy cyfrowej AutoSzkoda-Online.

Stan faktyczny w obszarze procesu wdrażania zmian i incydentu dostawcy:

• W procesie likwidacji szkód kluczową rolę pełni integracja API z chmurową platformą SaaS Info-Ekspert, która w czasie rzeczywistym zwraca algorytmiczną wycenę części zamiennych i robocizny blacharsko-lakierniczej.
• W dniu 15 listopada dostawca SaaS przesłał rutynowy newsletter techniczny na ogólny adres mailowy 'support@ubezpieczenia-cyfrowe.pl', informując o planowanym na 15 grudnia wyłączeniu obsługi protokołów TLS 1.0/1.1/1.2 (wymuszenie TLS 1.3) oraz wdrożeniu wersji API v4 ze zmianą formatu pól kalkulacji podatku VAT z formatu numerycznego na obiekt zagnieżdżony.
• Wiadomość została zignorowana przez pracownika helpdesku i nie została przekazana do Zespołu Zarządzania Zmianami (Change Management) ani do Architekta Integracji. W rejestrze ryzyk dostawców ICT (wymaganym przez art. 28 DORA) dostawca ten figurował jako "Standardowy dostawca danych rynkowych" bez przypisanego profilu ryzyka krytycznego.
• W nocy z 15 na 16 grudnia dostawca SaaS wdrożył zapowiedzianą zmianę. W poniedziałek o godzinie 08:00 platforma AutoSzkoda-Online zaczęła masowo rejestrować błędy połączeń SSL Handshake Failure oraz błędy parsowania odpowiedzi JSON.
• W architekturze systemowej ubezpieczyciela nie zaimplementowano wzorca odpornościowego Circuit Breaker ani bufora kolejkowego (Dead Letter Queue). Zawieszone zapytania HTTP do SaaS Info-Ekspert zablokowały wszystkie pule wątków na serwerach aplikacji, wywołując awarię kaskadową i całkowity paraliż modułów zgłaszania szkód, wypłat odszkodowań oraz infolinii telefonicznej.
• Paraliż trwał 4 dni robocze, w trakcie których zablokowano wypłatę 18 000 odszkodowań na łączną kwotę 62 mln PLN. Ponad 1200 poszkodowanych złożyło skargi do Rzecznika Finansowego z powodu niedotrzymania ustawowego terminu 30 dni na likwidację szkody.

Zarząd Towarzystwa, po otrzymaniu pisma ostrzegawczego z Departamentu Nadzoru Ubezpieczeniowego KNF, powołuje Triadę Audytorską do przeprowadzenia kompleksowego audytu procesów Third-Party Change Management w formule 90 minut.

Zadanie realizowane jest w ścisłym reżimie warsztatowym (formuła 90 minut) przez 2-3 osobową Triadę Audytorską:

• Krok 1 (Podział ról w Triadzie Audytorskiej - Minuty 00-15):

  Student A (Lead Auditor / Ubezpieczeniowy Audytor Wiodący): Odpowiada za analizę zgodności z Rozporządzeniem DORA (art. 28-44), Wytycznymi KNF, ustawowymi terminami likwidacji szkód, koordynację relacji z Radą Nadzorczą, matrycy 5x5 oraz opracowanie Executive Summary ("Pitch to Board").

  Student B (Technical SecOps Auditor / Architekt Bezpieczeństwa Chmurowego i API): Analizuje logi błędów TLS Handshake, dekonstruuje strukturę API v4 dostawcy SaaS, bada zjawisko awarii kaskadowej z powodu wyczerpania puli wątków i projektuje odporną architekturę integracji z wzorcem Circuit Breaker (Resilience4j), kolejkami DLQ i lokalnym cache offline.

  Student C (Change Governance & Compliance Auditor): Bada procedury monitorowania komunikacji od dostawców zewnętrznych, rejestr dostawców ICT wg DORA, weryfikuje klauzule SLA/OLA, prowadzi dekompozycję w modelu 4C i sekwencji 5 Why oraz konstruuje Trójfazowy Plan CAP z przypisaniem ról RACI i wskaźników KPI/KRI. W zespole dwuosobowym obowiązki Roli C dzielą Studenci A i B.

• Krok 2 (Opracowanie Kanonicznej Karty Niezgodności 4C - Minuty 15-40):

  Sformułujcie kartę uchybienia krytycznego w modelu 4C:

• Krok 3 (Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM - Minuty 15-40):

  Skwantyfikujcie ryzyka w 25-stopniowej skali (P 1-5 x S 1-5):

• Krok 4 (Konstrukcja Trójfazowego Planu Działań Korygujących - CAP - Minuty 40-70):

  Opracujcie tabelę CAP w 3 horyzontach czasowych:

• Krok 5 (Sformalizowany Projekt Załącznika Wykonawczego SOP - Minuty 40-70):

  Zredagujcie sformalizowany akt normatywny: "Instrukcja Zarządzania Zmianami Dostawców Zewnętrznych ICT i Odpornością Interfejsów API w Towarzystwie Ubezpieczeń Cyfrowych S.A." z numerowanymi artykułami (§ 1 Klasyfikacja dostawców ICT zgodnie z DORA, § 2 Obowiązkowe kanały i format powiadomień o zmianach i deprecjacji API, § 3 Standardy architektoniczne wzorców Circuit Breaker i Fallback Offline, § 4 Procedura testów kontraktowych API, § 5 Odpowiedzialność dostawców i klauzule umowne).

• Krok 6 (Opracowanie Podsumowania Zarządczego - Pitch to Board - Minuty 70-90):

  Przygotujcie 1-stronicowy dokument dla Zarządu i Rady Nadzorczej syntetyzujący eliminację ryzyka sankcji DORA (do 10% obrotu), koszt wdrożenia CAP (490 tys. PLN), ochronę przed stratami wizerunkowymi oraz gwarancję pełnej ciągłości likwidacji szkód nawet przy awarii partnerów zewnętrznych.

Plan strategicznej obrony seminaryjnej przed komisją laboratoryjną (15 minut):

• Prezentacja Podsumowania Zarządczego (Pitch to Board) dla Zarządu (3 min): Omówienie ryzyka łańcucha dostaw ICT w świetle DORA, bilans finansowy incydentu i wskaźniki zwrotu z Planu CAP (Student A - Lead Auditor).
• Dekonstrukcja incydentu technicznego: wyłączenie TLS 1.2, awaria kaskadowa i wzorzec Circuit Breaker (4 min): Analiza wyczerpania puli wątków serwerów, mechanizmu odcinania obciążeń i testów kontraktowych Pact (Student B - Technical SecOps Auditor).
• Prezentacja Kanonicznej Karty Niezgodności 4C, analizy 5 Why i matrycy ryzyka 5x5 (4 min): Uzasadnienie kwalifikacji uchybień, korelacja z art. 28 DORA, wytycznymi KNF i normą ISO 27001 oraz wyliczenie redukcji ryzyka z IR=20 do RR=4 (Student C - Compliance Auditor).
• Prezentacja Trójfazowego Planu CAP i Instrukcji Wykonawczej SOP (3 min): Szczegółowe omówienie etapów 0-7, 30 i 90 dni, automatyzacji rejestru dostawców i klauzul umownych (Student B i Student C).
• Dyskusja z komisją i obrona rekomendacji (1 min): Odpowiedź na pytania dotyczące egzekwowania reżimów zarządzania zmianami wobec globalnych dostawców chmurowych (cała Triada Audytorska).

Struktura raportu strategicznego na ocenę 5.0 (objętość 12-16 stron A4):

A. Podsumowanie Zarządcze (Executive Summary - "Pitch to Board") - 1 strona A4:

• Bilans ryzyk: likwidacja ryzyk krytycznych (IR=20) i redukcja do poziomu akceptowalnego (RR<=4).
• Ekspozycja finansowo-regulacyjna: kary KNF na podstawie DORA (do 10% obrotu), roszczenia odsetkowe poszkodowanych (850 tys. PLN), kary Rzecznika Finansowego.
• Kosztorys Planu CAP: 490 000 PLN (wdrożenie Service Mesh Istio/Circuit Breaker, platforma testów kontraktowych Pact, audyt prawny umów ICT).
• Korzyści biznesowe: Pełna cyberodporność platformy AutoSzkoda, zgodność z DORA i wytycznymi KNF, gwarancja likwidacji szkód w czasie < 24h.

B. Odpowiedzi na pytania problemowe i opis sytuacji kryzysowej:

• W jaki sposób instytucja finansowa podlegająca DORA powinna zorganizować techniczny monitoring i automatyczne procedowanie zmian wdrażanych przez zewnętrznych dostawców usług SaaS/API?
• Jakie wzorce architektoniczne (Circuit Breaker, Rate Limiting, Dead Letter Queue, Fallback Cache) są niezbędne w systemach płatniczych i ubezpieczeniowych, aby zapobiec awariom kaskadowym wywołanym niedostępnością API partnera?
• W jaki sposób testy kontraktowe API (Consumer-Driven Contract Testing - np. Pact) mogą zostać zintegrowane w potokach CI/CD w celu wczesnego wykrywania niezgodności schematów danych zewnętrznych dostawców?

C. Kanoniczna Karta Ustaleń Audytowych w Modelu 4C (Condition, Criteria, Cause, Consequence).

D. Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM (RTO=30m, RPO=0s, MTPD=2h).

E. Trójfazowy Plan Działań Korygujących (CAP) z macierzą RACI, wskaźnikami KPI i KRI.

F. Sformalizowany Projekt Załącznika Wykonawczego do Polityki Bezpieczeństwa Informacji (SOP).

G. Analiza zalet i ograniczeń wdrożeniowych architektury Circuit Breaker oraz testów kontraktowych Pact.

H. Bibliografia i normy źródłowe.

• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 z dnia 14 grudnia 2022 r. w sprawie operacyjnej odporności cyfrowej sektora finansowego (DORA) - Rozdział V: Zarządzanie ryzykiem ze strony zewnętrznych dostawców usług ICT.
• Urząd Komisji Nadzoru Finansowego: Wytyczne w sprawie zarządzania obszarami technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego w zakładach ubezpieczeń i reasekuracji, Warszawa 2020.
• European Insurance and Occupational Pensions Authority (EIOPA): "Guidelines on information and communication technology (ICT) security and governance", 2020.
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.5.19 (Bezpieczeństwo informacji w relacjach z dostawcami), A.5.21 (Zarządzanie bezpieczeństwem informacji w łańcuchu dostaw), A.8.32 (Zarządzanie zmianami).
• Nygard M. T.: "Release It! Design and Deploy Production-Ready Software", Pragmatic Bookshelf 2018 (Wzorce Circuit Breaker i Bulkhead).
• Ustawa z dnia 22 maja 2003 r. o ubezpieczeniach obowiązkowych, Ubezpieczeniowym Funduszu Gwarancyjnym i Polskim Biurze Ubezpieczycieli Komunikacyjnych (Dz.U. z 2022 r. poz. 2277 z późn. zm.).

• U2 Dekompozycja uchybień w modelu 4C i dochodzenie przyczyn 5 Why w relacjach z dostawcami zewnętrznymi ICT.
• U1 Projekt architektury cyberodporności z wzorcem Circuit Breaker oraz procedury Third-Party Change Governance.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 w ujęciu inherentnym i rezydualnym z powiązaniem ze wskaźnikami BCM.
• U4 Opracowanie Trójfazowego Planu CAP oraz przygotowanie Executive Summary ("Pitch to Board") dla Zarządu i Rady Nadzorczej.
• W1W2W3 Głęboka znajomość Rozporządzenia DORA, Wytycznych KNF/EIOPA, normy ISO 27001 i standardów architektury chmurowej.
• K1K2K3 Profesjonalizm audytorski, niezależność w ocenie dostawców chmurowych i etyka zawodowa w sektorze finansowym.

Podczas prezentacji seminaryjnej zilustrujcie działanie wzorca Circuit Breaker za pomocą schematu maszyny stanów (Closed -> Open -> Half-Open), wyjaśniając jak mechanizm ten chroni ubezpieczyciela przed wyczerpaniem zasobów serwera w sytuacji awarii API zewnętrznego partnera.

Głównym celem strategicznego zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie zaawansowanego, symulowanego audytu procesów planowania i realizacji okien serwisowych (Maintenance Windows) oraz architektury wdrożeń bezprzerwowych (Zero-Downtime Deployment / Blue-Green) w Głównym Inspektoracie Ratownictwa Medycznego i Krajowym Centrum Powiadamiania Ratunkowego 112 (MSWiA). Instytucja zarządza Systemem Wspomagania Dowodzenia Państwowego Ratownictwa Medycznego (SWD PRM), koordynującym pracę ponad 1600 zespołów ratownictwa medycznego (ZRM), 21 dyspozytorni medycznych oraz 17 centrów CPR w całej Polsce. Studenci wcielają się w rolę Triady Audytorskiej badającej katastrofalny incydent nocnego wdrożenia aktualizacji telekomunikacyjnej platformy SIP/VoIP i klastra dyspozytorskiego, zaplanowanego jako 15-minutowe okno serwisowe o godzinie 02:00. Z powodu błędnej konfiguracji przełączania ruchu w balancerze F5 BIG-IP oraz nieudanego restartu daemona Asterisk ruch głosowy z numerów 112 i 999 został zablokowany na 2 godziny i 45 minut w 6 województwach. W tym czasie nie odebrano 4 200 połączeń alarmowych, dyspozytorzy nie mogli wysyłać karetek drogą radiową, a w wyniku opóźnienia dojazdu pomocy doszło do 3 udokumentowanych zgonów pacjentów w stanie nagłego zatrzymania krążenia (art. 160 KK). Zadanie wymaga przeprowadzenia dekompozycji uchybień w kanonicznym modelu 4C, wyliczenia ryzyka w 25-stopniowej matrycy 5x5 skorelowanej ze wskaźnikami BCM (RTO=0s dla głosu, RPO=0s, MTPD=5m), opracowania Trójfazowego Planu Działań Korygujących (CAP) ze wskaźnikami KPI i KRI, sformułowania sformalizowanego Załącznika Wykonawczego (SOP) oraz przygotowania Podsumowania Zarządczego (Executive Summary - "Pitch to Board") dla Ministra Spraw Wewnętrznych i Administracji oraz Ministra Zdrowia.

Powiązanie z sylabusem i efektami kształcenia na ocenę 5.0:

• W1 Ochrona życia i zdrowia ludzkiego, odpowiedzialność karna za narażenie na bezpośrednie niebezpieczeństwo utraty życia albo ciężkiego uszczerbku na zdrowiu (art. 160 § 1 i 2 KK), rygory Ustawy o Państwowym Ratownictwie Medycznym oraz Ustawy o systemie powiadamiania ratunkowego.
• W2W3 Rygorystyczna korelacja wymagań Dyrektywy NIS2 (Podmiot Kluczowy Infrastruktury Krytycznej), Ustawy o KSC, normy ISO/IEC 27001:2022 (kontrole A.8.32 Zarządzanie zmianami, A.8.14 Redundancja systemów informacyjnych, A.8.22 Segregacja sieci), normy ISO 22301 (Zarządzanie ciągłością działania) oraz standardów EENA (European Emergency Number Association).
• U1 Opracowanie zintegrowanego modelu wdrożeń bezprzerwowych Blue-Green Deployment z redundantnym routingiem BGP/SIP i automatycznym przełączaniem awaryjnym (Failover) w czasie poniżej 1 sekundy.
• U2 Bezbłędna identyfikacja i formalna kwalifikacja uchybień w kanonicznym modelu 4C z bezwzględną precyzją dowodową dla organów śledczych i prokuratury.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 dla wektorów zgonów pacjentów i paraliżu linii 112/999 w ujęciu inherentnym (IR) i rezydualnym (RR) z powiązaniem ze wskaźnikami RTO=0s, RPO=0s, MTPD=5m.
• U4 Opracowanie Trójfazowego Planu Działań Korygujących (CAP) ze wskaźnikami KPI i KRI oraz 1-stronicowego briefingu zarządczego (Pitch to Board).
• K1K2K3 Bezwzględna etyka zawodowa, odporność na presję polityczną i resortową, bezkompromisowość w ochronie życia obywateli i rzetelność audytorska.
• Powiązanie z wykładem: Wyk1 (Audyt w służbach ratunkowych i infrastrukturze krytycznej), Wyk3 (Kontrole A.8.32 i A.8.14 ISO 27001), Wyk4 (Art. 160 KK i Ustawa o PRM), Wyk5 (Matryca ryzyka 5x5 i BCM ISO 22301), Wyk6 (Analiza logów SIP/VoIP, F5 BIG-IP i nagrań dyspozytorskich), Wyk7 (Model 4C, 5 Why i Trójfazowy CAP).

Centrum Powiadamiania Ratunkowego 112 wraz z Głównym Inspektoratem Ratownictwa Medycznego tworzą zintegrowany rdzeń teleinformatyczny bezpieczeństwa publicznego w Polsce. System przetwarza rocznie ponad 21 milionów zgłoszeń alarmowych, koordynując dyslokację karetek pogotowia, jednostek Państwowej Straży Pożarnej oraz Policji.

Stan faktyczny w obszarze procesu wdrażania zmian i incydentu ratunkowego:

• W centralnym klastrze telekomunikacyjnym SIP Trunk / VoIP zaplanowano wdrożenie poprawki bezpieczeństwa i aktualizacji kodeków audio (RFC-0892/2026). Wdrożenie zaklasyfikowano jako "Standard Maintenance Window" z 15-minutowym oknem technicznym w nocy ze środy na czwartek o godzinie 02:00.
• W procedurze wdrożeniowej zignorowano zasady architektury bezprzerwowej (Zero-Downtime Blue-Green). Zamiast utrzymania aktywnego środowiska równoległego (Blue) i stopniowego przełączania sesji SIP na zaktualizowane środowisko (Green), administratorzy wyłączyli ruch na głównym balancerze F5 BIG-IP, planując "szybki restart obu węzłów telekomunikacyjnych".
• W trakcie restartu nowy moduł Asterisk zgłosił błąd segmentacji (Segmentation Fault) wywołany konfliktem bibliotek kryptograficznych OpenSSL. Jednocześnie zapasowy kontroler sesji SBC (Session Border Controller) w drugim centrum danych nie podjął obsługi ruchu, ponieważ w skrypcie przełączającym wprowadzono błędną maskę podsieci routingu BGP.
• Przez 2 godziny i 45 minut (02:00 - 04:45) infrastruktura CPR 112 i dyspozytorni medycznych w 6 województwach była całkowicie głucha. Połączenia z numerów 112 i 999 były odrzucane sygnałem zajętości lub głuchej ciszy. Odrzucono 4 200 prób połączeń alarmowych.
• Dyspozytorzy medyczni nie otrzymali automatycznego powiadomienia o awarii centrali i nie uruchomili procedury rezerwowej łączności radiowej TETRA/EDACS ani prywatnych telefonów komórkowych.
• W trakcie trwania awarii, z powodu niemożności wezwania Zespołu Ratownictwa Medycznego, doszło do zgonu 3 pacjentów (dwóch zawałów serca i jednego udaru mózgu), których rodziny wielokrotnie bezskutecznie wybierały numer 999. Prokuratura Krajowa wszczęła śledztwo z art. 160 § 1 i 2 KK w zw. z art. 231 KK (niedopełnienie obowiązków służbowych).

Minister Spraw Wewnętrznych i Administracji oraz Minister Zdrowia powołują niezależną Triadę Audytorską do przeprowadzenia bezprecedensowego audytu procesów Maintenance Windows i Zero-Downtime w formule 90 minut.

Zadanie realizowane jest w ścisłym reżimie warsztatowym (formuła 90 minut) przez 2-3 osobową Triadę Audytorską:

• Krok 1 (Podział ról w Triadzie Audytorskiej - Minuty 00-15):

  Student A (Lead Auditor / Główny Audytor Służb Ratunkowych): Odpowiada za analizę odpowiedzialności prawnej i karnej (art. 160 KK), zgodność z Ustawą o PRM, Ustawą o KSC i Dyrektywą NIS2, koordynację relacji z Prokuraturą i MSWiA, matrycy 5x5 oraz przygotowanie Executive Summary ("Pitch to Board").

  Student B (Technical SecOps Auditor / Architekt Telekomunikacji i Systemów Krytycznych): Bada błędy routingu BGP, konfigurację balancera F5 BIG-IP, logi crashu bibliotek Asterisk/OpenSSL, brak procedury Stateful Failover dla sesji głosowych SIP i projektuje w pełni redundantną architekturę Blue-Green z zerowym czasem przełączania (Hitless Switching).

  Student C (Change Governance & Compliance Auditor): Bada regulaminy Maintenance Windows, procedury powiadamiania dyspozytorów o statusie łączy, manualne procedury awaryjne (łączność radiowa TETRA), prowadzi dochodzenie przyczyn w modelu 4C i sekwencji 5 Why oraz konstruuje Trójfazowy Plan CAP z przypisaniem ról RACI i wskaźników KPI/KRI. W zespole dwuosobowym obowiązki Roli C dzielą Studenci A i B.

• Krok 2 (Opracowanie Kanonicznej Karty Niezgodności 4C - Minuty 15-40):

  Sformułujcie kartę uchybienia krytycznego w modelu 4C:

• Krok 3 (Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM - Minuty 15-40):

  Skwantyfikujcie ryzyka w 25-stopniowej skali (P 1-5 x S 1-5):

• Krok 4 (Konstrukcja Trójfazowego Planu Działań Korygujących - CAP - Minuty 40-70):

  Opracujcie tabelę CAP w 3 horyzontach czasowych:

• Krok 5 (Sformalizowany Projekt Załącznika Wykonawczego SOP - Minuty 40-70):

  Zredagujcie sformalizowany akt normatywny: "Standard Realizacji Zmian i Wdrożeń Bezprzerwowych (Zero-Downtime Blue-Green) w Ekosystemie Teleinformatycznym Państwowego Ratownictwa Medycznego i Numeru Alarmowego 112" z numerowanymi artykułami (§ 1 Bezwzględny priorytet ochrony życia i zasada zerowego przestoju, § 2 Standard architektury Blue-Green i zakaz wspólnych okien serwisowych, § 3 Obowiązkowe procedury Heartbeat Monitor i awaryjnego fallbacku na sieć TETRA, § 4 Tryb zgłaszania i akceptacji zmian w komitecie Emergency CAB MSWiA, § 5 Odpowiedzialność karna i dyscyplinarna za naruszenie procedur).

• Krok 6 (Opracowanie Podsumowania Zarządczego - Pitch to Board - Minuty 70-90):

  Przygotujcie 1-stronicowy dokument dla Ministra Spraw Wewnętrznych i Administracji oraz Ministra Zdrowia syntetyzujący eliminację ryzyka zgonów obywateli, koszt wdrożenia CAP (1,8 mln PLN), uniezależnienie od awarii telekomunikacyjnych oraz zagwarantowanie najwyższego poziomu bezpieczeństwa narodowego.

Plan strategicznej obrony seminaryjnej przed komisją laboratoryjną (15 minut):

• Prezentacja Podsumowania Zarządczego (Pitch to Board) dla Kierownictwa MSWiA i MZ (3 min): Wstrząsający bilans incydentu, analiza odpowiedzialności z art. 160 KK i plan ratunkowy (Student A - Lead Auditor).
• Dekonstrukcja incydentu technicznego: błędy SIP, balancera F5, routing BGP i brak Blue-Green (4 min): Omówienie zjawiska Common Cause Failure, mechanizmu Hitless Failover i architektury BGP Anycast (Student B - Technical SecOps Auditor).
• Prezentacja Kanonicznej Karty Niezgodności 4C, analizy 5 Why i matrycy ryzyka 5x5 (4 min): Uzasadnienie kwalifikacji uchybień, korelacja z art. 160 KK, Ustawą o PRM, KSC i normą ISO 22301 oraz redukcja ryzyka z IR=20 do RR=4 (Student C - Compliance Auditor).
• Prezentacja Trójfazowego Planu CAP i Standardu Wykonawczego SOP (3 min): Szczegółowe omówienie etapów 0-7, 30 i 90 dni, monitoringu Heartbeat i fallbacku TETRA/Starlink (Student B i Student C).
• Dyskusja z komisją i obrona rekomendacji (1 min): Odpowiedź na pytania dotyczące etycznych i prawnych aspektów zarządzania ryzykiem w systemach podtrzymania życia i ratownictwa (cała Triada Audytorska).

Struktura raportu strategicznego na ocenę 5.0 (objętość 12-16 stron A4):

A. Podsumowanie Zarządcze (Executive Summary - "Pitch to Board") - 1 strona A4:

• Bilans ryzyk: likwidacja ryzyk krytycznych zagrażających życiu (IR=20) i redukcja do poziomu akceptowalnego (RR<=4).
• Wymiar prawny i karny: zarzuty z art. 160 KK, śledztwo prokuratorskie, odszkodowania dla rodzin zmarłych, sankcje KSC/NIS2.
• Kosztorys Planu CAP: 1 800 000 PLN (infrastruktura Blue-Green BGP Anycast, system Heartbeat GSM, redundancja TETRA/Starlink).
• Wartość nadrzędna: Bezwzględna gwarancja nieprzerwanej odbieralności połączeń ratunkowych 112/999 (dostępność 99.999%), ochrona życia obywateli.

B. Odpowiedzi na pytania problemowe i opis sytuacji kryzysowej:

• W jaki sposób zaprojektować architekturę Blue-Green Deployment dla systemów telekomunikacji krytycznej SIP Trunk/VoIP, aby wyeliminować przerwę w rejestracji połączeń (Zero-Downtime Hitless Switching)?
• Jakie mechanizmy automatycznego testowania pętli zwrotnej (Synthetic Transaction Monitoring / Out-of-Band Heartbeat) powinny monitorować dostępność linii alarmowych w dyspozytorniach medycznych?
• W jaki sposób prawnie i operacyjnie zdefiniować odpowiedzialność za błędy wdrożeniowe w systemach ratownictwa medycznego w kontekście przepisów art. 160 Kodeksu Karnego?

C. Kanoniczna Karta Ustaleń Audytowych w Modelu 4C (Condition, Criteria, Cause, Consequence).

D. Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM (RTO=0s, RPO=0s, MTPD=5m).

E. Trójfazowy Plan Działań Korygujących (CAP) z macierzą RACI, wskaźnikami KPI i KRI.

F. Sformalizowany Projekt Załącznika Wykonawczego do Polityki Bezpieczeństwa Informacji (SOP).

G. Analiza zalet i ograniczeń wdrożeniowych architektury BGP Anycast, modeli Blue-Green oraz łączności radiowej TETRA.

H. Bibliografia i normy źródłowe.

• Ustawa z dnia 6 czerwca 1997 r. - Kodeks karny (Dz.U. z 2022 r. poz. 1138 z późn. zm.) - art. 160 i art. 231.
• Ustawa z dnia 8 września 2006 r. o Państwowym Ratownictwie Medycznym (Dz.U. z 2022 r. poz. 1720 z późn. zm.).
• Ustawa z dnia 22 listopada 2013 r. o systemie powiadamiania ratunkowego (Dz.U. z 2021 r. poz. 268 z późn. zm.).
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.8.14 (Redundancja systemów), A.8.22 (Segregacja sieci), A.8.32 (Zarządzanie zmianami).
• Norma PN-EN ISO 22301:2020-04: Bezpieczeństwo i odporność - Systemy zarządzania ciągłością działania - Wymagania.
• European Emergency Number Association (EENA): "Next Generation 112 (NG112) Architecture & Resiliency Standard", Bruksela 2021.

• U2 Dekompozycja uchybień w modelu 4C i analiza przyczyn 5 Why w infrastrukturze ratownictwa medycznego.
• U1 Projekt architektury bezprzerwowej Blue-Green Zero-Downtime dla telekomunikacji alarmowej SIP/VoIP.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 w ujęciu inherentnym i rezydualnym z powiązaniem ze wskaźnikami BCM.
• U4 Konstrukcja Trójfazowego Planu CAP oraz przygotowanie Executive Summary ("Pitch to Board") dla Ministra MSWiA i MZ.
• W1W2W3 Dogłębna znajomość przepisów art. 160 KK, Ustawy o PRM, normy ISO 22301, ISO 27001 i standardów EENA.
• K1K2K3 Bezwzględna etyka zawodowa, odporność na presję hierarchiczną i bezkompromisowość w ochronie życia ludzkiego.

Podczas obrony seminaryjnej zademonstrujcie schemat przepływu ruchu SIP w architekturze Blue-Green z wykorzystaniem BGP Anycast, dowodząc, że przełączenie ruchu w trakcie aktualizacji węzła nie powoduje zerwania ani jednej trwającej rozmowy alarmowej.

Głównym celem strategicznego zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie zaawansowanego, symulowanego audytu procedur przeglądu powdrożeniowego (Post-Implementation Review - PIR), analizy przyczyn źródłowych (Root Cause Analysis - RCA w metodykach Ishikawy i 5 Why) oraz zarządzania bazą znanych błędów (Known Error Database - KEDB) w Przedsiębiorstwie Państwowym "Porty Lotnicze" (PPL S.A.) - Port Lotniczy Warszawa-Okęcie im. Fryderyka Chopina. Lotnisko jest operatorem infrastruktury krytycznej transportu lotniczego w rozumieniu Dyrektywy NIS2 i Ustawy o KSC, podlegającym rygorom Europejskiej Agencji Bezpieczeństwa Lotniczego (EASA), Organizacji Międzynarodowego Lotnictwa Cywilnego (ICAO) oraz Urzędu Lotnictwa Cywilnego (ULC). Węzeł zarządza ruchem ponad 18 milionów pasażerów rocznie, koordynując zintegrowane systemy: Zarządzania Ruchem Lotniskowym (AODB), System Informacji o Lotach (FIDS), Kontroli Odprawy Pasażerów (DCS) oraz Zautomatyzowany System Obsługi Bagażu (BHS). Studenci wcielają się w rolę Triady Audytorskiej badającej procedury formalnego zamykania incydentu krytycznego wdrożenia nowej wersji oprogramowania sterowników PLC i serwera SCADA systemu BHS, które wywołało zablokowanie sortowni bagażu na 11 godzin, odwołanie 42 rejsów międzynarodowych i zagubienie 14 000 walizek. Zamiast rzetelnej analizy PIR, kierownictwo IT sporządziło powierzchowną notatkę zrzucającą winę na "przypadkowy błąd podwykonawcy", bez analizy 5 Why, bez aktualizacji bazy KEDB i bez wdrożenia kultury Just Culture (No-Blame Culture), co stworzyło warunki do powtórzenia się tożsamej awarii 3 tygodnie później. Zadanie wymaga przeprowadzenia dekompozycji uchybień w kanonicznym modelu 4C, wyliczenia ryzyka w 25-stopniowej matrycy 5x5 skorelowanej ze wskaźnikami BCM (RTO=20m, RPO=0s, MTPD=1h), opracowania Trójfazowego Planu Działań Korygujących (CAP) ze wskaźnikami KPI i KRI, sformułowania sformalizowanego Załącznika Wykonawczego (SOP) oraz przygotowania Podsumowania Zarządczego (Executive Summary - "Pitch to Board") dla Zarządu PPL S.A. i Prezesa Urzędu Lotnictwa Cywilnego.

Powiązanie z sylabusem i efektami kształcenia na ocenę 5.0:

• W1 Ochrona bezpieczeństwa transportu lotniczego, odpowiedzialność cywilna i odszkodowawcza za opóźnienia rejsów (Rozporządzenie UE 261/2004), rygory prawa lotniczego oraz kultura sprawiedliwego traktowania (Just Culture / No-Blame Culture).
• W2W3 Rygorystyczna korelacja wymagań Dyrektywy NIS2, Rozporządzenia EASA Part-IS (Zarządzanie bezpieczeństwem informacji w lotnictwie cywilnym), załącznika 17 i 19 ICAO, normy ISO/IEC 27001:2022 (kontrole A.8.32 Zarządzanie zmianami, A.5.24 Planowanie i przygotowanie zarządzania incydentami, A.5.28 Zbieranie dowodów, A.5.27 Wyciąganie wniosków ze zdarzeń), normy ISO 20000-1 oraz metodyki ITIL 4 (Problem & Knowledge Management).
• U1 Opracowanie zintegrowanej procedury Post-Implementation Review (PIR) łączącej analizę diagramu Ishikawy, wieloaspektowe dochodzenie 5 Why oraz mechanizm zasilania bazy Known Error Database (KEDB) w systemie ITSM.
• U2 Bezbłędna identyfikacja i formalna kwalifikacja uchybień w kanonicznym modelu 4C z precyzyjnym wskazaniem naruszeń procedur lotniczych i norm międzynarodowych.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 dla wektorów paraliżu operacyjnego portu i sankcji EASA w ujęciu inherentnym (IR) i rezydualnym (RR) z powiązaniem ze wskaźnikami RTO=20m, RPO=0s, MTPD=1h.
• U4 Opracowanie Trójfazowego Planu Działań Korygujących (CAP) ze wskaźnikami KPI i KRI oraz 1-stronicowego briefingu zarządczego (Pitch to Board).
• K1K2K3 Obiektywizm audytorski, promowanie kultury organizacyjnej opartej na przejrzystości (Just Culture), odporność na próby tuszowania błędów i bezkompromisowa rzetelność.
• Powiązanie z wykładem: Wyk1 (Audyt w infrastrukturze krytycznej lotnictwa i NIS2), Wyk3 (Kontrole A.8.32, A.5.24 i A.5.27 ISO 27001), Wyk4 (EASA Part-IS i ICAO), Wyk5 (Matryca ryzyka 5x5 i BIA), Wyk6 (Analiza logów SCADA BHS, raportów PIR i bazy KEDB), Wyk7 (Model 4C, 5 Why, Diagram Ishikawy i Trójfazowy CAP).

Przedsiębiorstwo Państwowe "Porty Lotnicze" (PPL S.A.) zarządza największym portem lotniczym w Europie Środkowo-Wschodniej - Lotniskiem Chopina w Warszawie. Port obsługuje średnio 600 operacji lotniczych na dobę. Sercem operacyjnym terminala pasażerskiego jest Zautomatyzowany System Sortowania Bagażu (Baggage Handling System - BHS) oparty na 14 kilometrach taśmociągów, 28 tomografach rentgenowskich Smiths Detection oraz redundantnych sterownikach Siemens S7-1500 zintegrowanych z serwerami SCADA.

Stan faktyczny w obszarze procesu wdrażania zmian i incydentu lotniskowego:

• W nocy z niedzieli na poniedziałek przeprowadzono wdrożenie aktualizacji oprogramowania serwera SCADA BHS odpowiedzialnego za optymalizację przesyłu bagaży tranzytowych. Zmiana została zatwierdzona przez CAB jako "Minor Software Update" bez wymaganych testów obciążeniowych na symulatorze HIL (Hardware-in-the-Loop).
• O godzinie 05:30 rano, wraz z falą porannych odlotów, w module kolejkowania wystąpił błąd wycieku pamięci (Memory Leak), który doprowadził do zawieszenia komunikacji OPC UA między serwerem SCADA a sterownikami PLC taśmociągów. Taśmociągi zatrzymały się w trybie awaryjnym (Emergency E-Stop).
• Zablokowanie systemu trwało 11 godzin. Na terminalu powstał gigantyczny zator: 14 000 sztuk bagażu zalegało w halach odpraw, 42 rejsy międzynarodowe zostały odwołane przez linie lotnicze (PLL LOT, Lufthansa, Air France), a 85 samolotów odleciało z wielogodzinnym opóźnieniem bez bagaży pasażerów.
• Po przywróceniu sprawności systemu, Dyrektor Pionu IT zwołał 15-minutowe spotkanie, które nazwał "PIR", na którym stwierdzono, że przyczyną był "błąd w kodzie podwykonawcy". Sporządzono jednostronicową notatkę wewnętrzną, zamykając sprawę bez przeprowadzenia strukturyzowanej analizy RCA (brak diagramu Ishikawy, brak sekwencji 5 Why), bez zidentyfikowania przyczyn organizacyjnych i bez wpisania obejścia do bazy KEDB.
• Zespół inżynierów podwykonawcy został ukarany finansowo, co wywołało atmosferę strachu i ukrywania problemów (brak kultury No-Blame Culture).
• Zaledwie 21 dni później, podczas kolejnej rutynowej poprawki innego modułu SCADA, wystąpił bliźniaczy błąd alokacji zasobów, powodując ponowny paraliż sortowni bagażu na 6 godzin.

Zarząd PPL S.A., stojąc w obliczu roszczeń odszkodowawczych linii lotniczych na kwotę 35 mln PLN oraz kontroli doraźnej Urzędu Lotnictwa Cywilnego i EASA, powołuje Triadę Audytorską do przeprowadzenia strategicznego audytu procedur PIR, RCA i KEDB w formule 90 minut.

Zadanie realizowane jest w ścisłym reżimie warsztatowym (formuła 90 minut) przez 2-3 osobową Triadę Audytorską:

• Krok 1 (Podział ról w Triadzie Audytorskiej - Minuty 00-15):

  Student A (Lead Auditor / Lotniczy Audytor Wiodący): Odpowiada za analizę zgodności z przepisami EASA Part-IS, wytycznymi ICAO, Ustawą o KSC i Dyrektywą NIS2, badanie kultury organizacyjnej (Just Culture / No-Blame Culture), koordynację matrycy 5x5 oraz przygotowanie Executive Summary ("Pitch to Board") dla Zarządu PPL i ULC.

  Student B (Technical SecOps Auditor / Architekt Systemów SCADA i BHS): Analizuje protokół komunikacyjny OPC UA, zjawisko wycieku pamięci (Memory Leak), konfigurację sterowników PLC Siemens S7-1500, logi systemowe SCADA i projektuje środowisko testów obciążeniowych Hardware-in-the-Loop (HIL) oraz integrację bazy KEDB z monitoringiem Zabbix/Prometheus.

  Student C (Change Governance & Compliance Auditor): Przeprowadza pełną analizę przyczyn źródłowych RCA z wykorzystaniem Diagramu Ishikawy (kategorie: Ludzie, Metody, Narzędzia, Środowisko, Zarządzanie) oraz sekwencji 5 Why, projektuje kanoniczną procedurę PIR (Post-Implementation Review) i konstruuje Trójfazowy Plan CAP z przypisaniem ról RACI i wskaźników KPI/KRI. W zespole dwuosobowym obowiązki Roli C dzielą Studenci A i B.

• Krok 2 (Opracowanie Kanonicznej Karty Niezgodności 4C - Minuty 15-40):

  Sformułujcie kartę uchybienia krytycznego w modelu 4C:

• Krok 3 (Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM - Minuty 15-40):

  Skwantyfikujcie ryzyka w 25-stopniowej skali (P 1-5 x S 1-5):

• Krok 4 (Konstrukcja Trójfazowego Planu Działań Korygujących - CAP - Minuty 40-70):

  Opracujcie tabelę CAP w 3 horyzontach czasowych:

• Krok 5 (Sformalizowany Projekt Załącznika Wykonawczego SOP - Minuty 40-70):

  Zredagujcie sformalizowany akt normatywny: "Instrukcja Przeprowadzania Przeglądów Powdrożeniowych (PIR), Analizy Przyczyn Źródłowych RCA i Prowadzenia Bazy Znanych Błędów (KEDB) w Infrastrukturze Krytycznej Portu Lotniczego Warszawa-Okęcie" z numerowanymi artykułami (§ 1 Zasady lotniczej kultury sprawiedliwego traktowania Just Culture, § 2 Kryteria i harmonogram zwoływania sesji PIR, § 3 Obowiązkowe metodyki dochodzeniowe Ishikawa i 5 Why, § 4 Standard struktury artykułu w bazie KEDB i procedury obejść Workaround, § 5 Nadzór audytorski i raportowanie do Urzędu Lotnictwa Cywilnego).

• Krok 6 (Opracowanie Podsumowania Zarządczego - Pitch to Board - Minuty 70-90):

  Przygotujcie 1-stronicowy dokument dla Zarządu PPL S.A. i Prezesa ULC syntetyzujący eliminację ryzyka katastrofalnego (IR=25 -> RR=4), koszt wdrożenia CAP (650 tys. PLN), uniknięcie roszczeń odszkodowawczych (35 mln PLN) oraz transformację kultury organizacyjnej lotniska w kierunku światowych standardów bezpieczeństwa.

Plan strategicznej obrony seminaryjnej przed komisją laboratoryjną (15 minut):

• Prezentacja Podsumowania Zarządczego (Pitch to Board) dla Zarządu PPL i ULC (3 min): Skala strat operacyjnych i wizerunkowych, konieczność wdrożenia Just Culture i bilans korzyści z Planu CAP (Student A - Lead Auditor).
• Dekonstrukcja incydentu technicznego: analiza awarii SCADA BHS, wycieku pamięci i protokołu OPC UA (4 min): Omówienie błędu kolejkowania, braku testów HIL i mechanizmu powtórzenia się awarii po 21 dniach (Student B - Technical SecOps Auditor).
• Prezentacja Kanonicznej Karty Niezgodności 4C, diagramu Ishikawy i analizy 5 Why (4 min): Uzasadnienie kwalifikacji uchybień, korelacja z EASA Part-IS, ICAO Annex 19 i normą ISO 20000-1 oraz wyliczenie redukcji ryzyka z IR=25 do RR=4 (Student C - Compliance Auditor).
• Prezentacja Trójfazowego Planu CAP i Standardu Wykonawczego SOP (3 min): Szczegółowe omówienie etapów 0-7, 30 i 90 dni, architektury bazy KEDB, procedury PIR i zasad Just Culture (Student B i Student C).
• Dyskusja z komisją i obrona rekomendacji (1 min): Odpowiedź na pytania dotyczące przełamywania oporu kadry kierowniczej przed odejściem od kultury obwiniania (Blame Culture) na rzecz transparentnego raportowania błędów (cała Triada Audytorska).

Struktura raportu strategicznego na ocenę 5.0 (objętość 12-16 stron A4):

A. Podsumowanie Zarządcze (Executive Summary - "Pitch to Board") - 1 strona A4:

• Bilans ryzyk: likwidacja ryzyka katastrofalnego (IR=25) i redukcja do poziomu akceptowalnego (RR<=4).
• Ekspozycja odszkodowawcza i regulacyjna: roszczenia linii lotniczych (35 mln PLN), kary EASA/ULC, ryzyko zawieszenia certyfikatu portu lotniczego.
• Kosztorys Planu CAP: 650 000 PLN (stanowisko testowe HIL, wdrożenie modułu KEDB w ITSM, program szkoleniowy Just Culture).
• Korzyści operacyjne: Eliminacja zatorów bagażowych, stuprocentowa powtarzalność wniosków z awarii, pełna zgodność z EASA Part-IS i ICAO Annex 19.

B. Odpowiedzi na pytania problemowe i opis sytuacji kryzysowej:

• W jaki sposób zorganizować i przeprowadzić formalną sesję Przeglądu Powdrożeniowego (Post-Implementation Review - PIR) dla wdrożenia w infrastrukturze krytycznej, aby uniknąć powierzchowności i zidentyfikować rzeczywiste przyczyny systemowe?
• Jakie są kluczowe zasady budowy Diagramu Przyczynowo-Skutkowego Ishikawy w obszarze technologii przemysłowych OT/SCADA i jak integrować go z analizą 5 Why?
• W jaki sposób standardy EASA i ICAO definiują kulturę sprawiedliwego traktowania (Just Culture / No-Blame Culture) i jakie mechanizmy prawne chronią inżynierów raportujących własne pomyłki przed sankcjami dyscyplinarnymi?

C. Kanoniczna Karta Ustaleń Audytowych w Modelu 4C (Condition, Criteria, Cause, Consequence).

D. Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM (RTO=20m, RPO=0s, MTPD=1h).

E. Trójfazowy Plan Działań Korygujących (CAP) z macierzą RACI, wskaźnikami KPI i KRI.

F. Sformalizowany Projekt Załącznika Wykonawczego do Polityki Bezpieczeństwa Informacji (SOP).

G. Analiza zalet i ograniczeń wdrożeniowych bazy Known Error Database (KEDB), symulatorów HIL i kultury Just Culture.

H. Bibliografia i normy źródłowe.

• EASA (European Union Aviation Safety Agency): "Easy Access Rules for Information Security Management Systems (Part-IS)", Kolonia 2023.
• ICAO (International Civil Aviation Organization): "Annex 19 to the Convention on International Civil Aviation - Safety Management", Montreal 2020.
• Rozporządzenie Parlamentu Europejskiego i Rady (WE) nr 261/2004 z dnia 11 lutego 2004 r. ustanawiające wspólne zasady odszkodowania i pomocy dla pasażerów w przypadku odmowy przyjęcia na pokład albo odwołania lub dużego opóźnienia lotów.
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.5.24 (Planowanie incydentów), A.5.27 (Uczenie się z incydentów), A.8.32 (Zarządzanie zmianami).
• Norma PN-ISO/IEC 20000-1:2018: System zarządzania usługami informatycznymi - Część 1: Wymagania (Rozdział 8.6 Zarządzanie problemami).
• Dekker S.: "Just Culture: Restoring Trust and Accountability in Your Organization", CRC Press 2016.

• U2 Dekompozycja uchybień w modelu 4C oraz przeprowadzenie wieloaspektowej analizy RCA (Diagram Ishikawy + 5 Why).
• U1 Projekt kanonicznej procedury PIR, standardu artykułów bazy KEDB oraz implementacja zasad Just Culture.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 w ujęciu inherentnym i rezydualnym z powiązaniem ze wskaźnikami BCM.
• U4 Konstrukcja Trójfazowego Planu CAP oraz przygotowanie Executive Summary ("Pitch to Board") dla Zarządu PPL i ULC.
• W1W2W3 Dogłębna znajomość przepisów EASA Part-IS, ICAO Annex 19, normy ISO 20000-1, ISO 27001 i specyfiki portów lotniczych.
• K1K2K3 Obiektywizm, promowanie transparentności organizacyjnej, odwaga w przełamywaniu kultury obwiniania i rzetelność zawodowa.

Podczas obrony referatu zaprezentujcie przygotowany Diagram Ishikawy dla incydentu sortowni BHS, demonstrując komisji, w jaki sposób powierzchowny PIR pominął 4 kluczowe gałęzie przyczynowe (Metody, Narzędzia, Zarządzanie, Środowisko), skupiając się fałszywie wyłącznie na gałęzi Ludzie (podwykonawca).