Laboratorium 6

Głównym celem zadania jest opanowanie przez studentów praktycznych umiejętności przeprowadzenia audytu procedury wdrażania zmian awaryjnych (Emergency Change Management) w podmiocie leczniczym ze szczególnym uwzględnieniem oceny ryzyka obchodzenia standardowych ścieżek akceptacji, badania uprawnień dostawców zewnętrznych oraz weryfikacji funkcjonowania Awaryjnego Komitetu Zarządzania Zmianami (Emergency Change Advisory Board - ECAB). Zadanie koncentruje się na identyfikacji krytycznych uchybień w nadzorze nad zmianami typu "hotfix" wdrażanymi bezpośrednio na środowisku produkcyjnym, braku planów wycofania zmian (rollback) oraz braku wstecznej autoryzacji (post-implementation review) po ustabilizowaniu sytuacji awaryjnej.

Powiązanie z sylabusem i treściami programowymi:

• U2 Identyfikacja niezgodności (NC1/NC2/NC3), braków formalnych i proceduralnych w procesie realizacji zmian awaryjnych w systemie informacji medycznej.
• U1 Opracowanie założeń znowelizowanej procedury Emergency Change Management, powołania komitetu ECAB oraz wprowadzenia obligatoryjnych punktów kontrolnych dla zewnętrznych serwisantów.
• U3 Przeprowadzenie analizy ryzyka paraliżu pracy personelu medycznego, wstrzymania wydawania leków i zagrożenia życia pacjentów na skutek nieprzetestowanych modyfikacji bazy danych.
• U4 Opracowanie pisemnego referatu oraz ustrukturyzowanego raportu z audytu procesu zarządzania zmianą dla Dyrekcji Szpitala i Pełnomocnika ds. Bezpieczeństwa Informacji.
• W1 Znajomość wymogów prawnych dotyczących zapewnienia ciągłości działania i integralności dokumentacji medycznej (art. 32 RODO, Ustawa o systemie informacji w ochronie zdrowia).
• W2W3 Zrozumienie normy PN-EN ISO/IEC 27001:2022 (kontrole Załącznika A: A.8.32 Zarządzanie zmianami, A.8.29 Testowanie bezpieczeństwa w rozwoju i akceptacji, A.8.31 Rozdzielenie środowisk), metodyki ITIL 4 oraz wytycznych Centrum e-Zdrowia (CeZ).
• K1K2K3 Kształtowanie postawy odpowiedzialności za życie ludzkie, obiektywizmu audytorskiego oraz rzetelności weryfikacji śladów rewizyjnych w rejestrach zmian.
• Powiązanie z wykładem: Wyk1 (Rola audytu w ochronie aktywów krytycznych), Wyk2 (Zasady audytowania ISO 19011), Wyk3 (Kontrola A.8.32 ISO 27001), Wyk4 (RODO i KRI w szpitalu), Wyk6 (Analiza logów transakcyjnych i triangulacja dowodów audytowych), Wyk7 (Klasyfikacja niezgodności i formułowanie zaleceń poaudytowych).

Szpital Wojewódzki w Radomiu (SPZOZ) jest wielospecjalistycznym kompleksem medycznym dysponującym 800 łóżkami, Szpitalnym Oddziałem Ratunkowym (SOR), 16 oddziałami klinicznymi, blokiem operacyjnym oraz apteką szpitalną zaopatrującą oddziały w leki ratujące życie i preparaty cytostatyczne.

Stan faktyczny w obszarze zarządzania zmianami w systemach teleinformatycznych:

• Podstawowym narzędziem pracy personelu medycznego jest Szpitalny System Informacyjny (HIS) zintegrowany z modułem e-Recepty, Apteką Szpitalną oraz systemem Elektronicznej Dokumentacji Medycznej (EDM).
• W piątek o godzinie 21:30 dyżurny informatyk szpitala otrzymał zgłoszenie z izby przyjęć o spowolnieniu generowania kart wypisowych. Zamiast wdrożyć procedurę standardową, powiadomił telefonicznie zewnętrznego programistę firmy dostarczającej system HIS (umowa serwisowa SLA).
• Zewnętrzny programista, logując się przez zdalny dostęp VPN z uprawnieniami administratora bazy danych (konto 'db_admin'), podjął decyzję o pilnym zmodyfikowaniu struktury bazy danych PostgreSQL. Wprowadził bezpośrednio na środowisku produkcyjnym skrypt modyfikujący klucze obce oraz indeksy w tabelach zleceń leków i przyjęć pacjentów (tzw. "gorąca poprawka" - hotfix na żywo).
• Zmiana ta nie została zgłoszona w systemie helpdesk jako Wniosek o Zmianę (RFC - Request for Change), nie została przetestowana na środowisku testowym ani stagingowym, a także nie uzyskała zatwierdzenia Dyrektora ds. Medycznych ani Kierownika Działu IT. Nie powołano Awaryjnego Komitetu Zmian (ECAB).
• O godzinie 06:15 w sobotę rano personel apteki szpitalnej oraz oddziałów intensywnej terapii zgłosił całkowity paraliż modułu wydawania leków: system zgłaszał błąd integralności relacyjnej "foreign key constraint violation" i blokował wydawanie zleceń. Na SOR wstrzymano rejestrację nowych pacjentów.
• Gdy podjęto próbę przywrócenia poprzedniego stanu, okazało się, że programista nie sporządził kopii zapasowej modyfikowanych tabel bezpośrednio przed uruchomieniem skryptu, nie opracował procedury wycofania zmiany (Rollback Plan), a w repozytorium kodu git brak było jakiegokolwiek śladu wprowadzonego kodu SQL.
• Przywrócenie działania systemu zajęło 14 godzin i wymagało odtworzenia bazy z nocnego backupu, co spowodowało utratę wpisów medycznych i wyników badań laboratoryjnych wprowadzonych w nocy dla 42 pacjentów.

Dyrektor Szpitala powołuje zespół audytorski z zadaniem wyjaśnienia przyczyn awarii, zbadania procedur zarządzania zmianami awaryjnymi oraz zaprojektowania szczelnego procesu Emergency Change Management.

Praca w zespole 2-3 osobowym polega na zbadaniu procedury wnioskowania, zatwierdzania i wdrażania zmian awaryjnych oraz sformułowaniu zaleceń naprawczych:

• Krok 1 (Podział ról w grupie audytowej):

  Student 1 (Audytor Wiodący / Governance i Procedury): Dokonuje przeglądu Księgi Procedur IT, analizuje formalny obieg wniosków RFC, bada regulamin komitetu CAB/ECAB, przeprowadza wywiady z Dyrektorem ds. Medycznych i Kierownikiem IT oraz koordynuje przygotowanie referatu.

  Student 2 (Audytor Techniczny ds. Baz Danych i Wdrożeń): Bada techniczny mechanizm dostępu zdalnego VPN, logi sesji administratora bazy danych, treść skryptu SQL, brak procedury rollback oraz weryfikuje brak separacji środowisk DEV/TEST/PROD.

  Student 3 (Audytor Zgodności Regulacyjnej i Bezpieczeństwa Pacjenta): Weryfikuje spełnienie wymagań art. 32 RODO (integralność i poufność), Ustawy o systemie informacji w ochronie zdrowia, kontroli A.8.32 normy ISO/IEC 27001 oraz szacuje ryzyko utraty danych pacjentów. W zespole 2-osobowym obowiązki te dzielą Studenci 1 i 2.

• Krok 2 (Triangulacja dowodów audytowych):

  Zestawcie ze sobą trzy źródła dowodów: zapisy w umowie serwisowej z dostawcą HIS (wymogi dotyczące wdrażania poprawek), logi serwera bazy danych i bramy VPN z nocy incydentu oraz brak wpisu o zmianie w szpitalnym rejestrze incydentów i zmian.

• Krok 3 (Identyfikacja i klasyfikacja niezgodności):

  Sformułujcie ustalenia audytowe i zaklasyfikujcie je według wag:

  • Niezgodność krytyczna (NC1): Brak sformalizowanej procedury wdrażania zmian awaryjnych (Emergency Change) oraz brak komitetu ECAB, co doprowadziło do bezpośredniego wprowadzenia niesprawdzonego skryptu na bazie produkcyjnej przez dostawcę zewnętrznego i wywołało paraliż leczenia pacjentów (naruszenie kontroli ISO/IEC 27001:2022 A.8.32 oraz art. 32 ust. 1 lit. b RODO).
  • Niezgodność większa (NC2): Brak wymogu sporządzania i testowania procedury wycofania zmiany (Rollback Plan) oraz brak wykonania dedykowanej migawki bazy danych (Pre-change Snapshot) przed modyfikacją schematu danych.
  • Niezgodność mniejsza (NC3): Brak rejestracji doraźnych prac serwisowych w szpitalnym systemie helpdesk i brak procedury wstecznego audytu poawaryjnego (Post-Implementation Review) w ciągu 48 godzin od zamknięcia zmiany.
• Krok 4 (Projekt procedury Emergency Change Management i powołania ECAB):

  Opracujcie procedurę awaryjną określającą:

  • Kryteria kwalifikacji zmiany jako Emergency (wyłącznie bezpośrednie zagrożenie życia pacjentów, utrata integralności danych medycznych lub krytyczny przestój szpitala).
  • Skład komitetu ECAB: Dyrektor Medyczny (lub lekarz dyżurny szpitala), Kierownik Działu IT oraz Pełnomocnik ds. Bezpieczeństwa Informacji / IOD.
  • Zasada autoryzacji "czterech oczu" przy wdrożeniach na bazie produkcyjnej (rejestracja sesji zdalnej, brak możliwości bezpośredniego wykonywania skryptów DDL bez uprzedniego zatwierdzenia sumy kontrolnej skryptu).
  • Obowiązkowy plan wycofania (Rollback Script) dołączany do każdego wniosku awaryjnego.
  • Wsteczny audyt i formalne zamknięcie wniosku (Post-Implementation Review) w pierwszym dniu roboczym po wdrożeniu.

Studenci przygotowują 10-minutowe wystąpienie seminaryjne na zajęciach laboratoryjnych:

• Wprowadzenie i opis incydentu w radomskim szpitalu (2 min): Przedstawienie profilu SPZOZ, mechanizmu nocnej modyfikacji bazy HIS na żywo i skutków dla apteki oraz oddziałów ratunkowych (Student 1).
• Wyniki audytu technicznego i formalnego (3 min): Omówienie luk w nadzorze nad serwisantami, braku komitetu ECAB, braku procedury rollback oraz dowodów z logów serwerowych (Student 2).
• Ocena ryzyka medycznego i odpowiedzialności prawnej (2 min): Analiza naruszenia art. 32 RODO, normy ISO 27001 oraz rygorów odpowiedzialności cywilnej i zawodowej szpitala za wstrzymanie podawania leków (Student 3 lub Student 1).
• Koncepcja naprawcza procesu Emergency Change (2 min): Prezentacja nowego algorytmu ścieżki awaryjnej, składu ECAB i procedury natychmiastowego wycofania błędnej łatki (Student 2).
• Podsumowanie, analiza wad i zalet (1 min): Dyskusja nad kosztami wdrożenia rygorystycznych kontroli w relacji do bezpieczeństwa pacjentów (cały zespół).

Raport składany przez zespół (objętość 4-6 stron A4) musi zawierać:

A. Odpowiedzi na pytania problemowe i opis sytuacyjny:

• Dlaczego wdrożenie "gorących poprawek" (hotfix) bezpośrednio na środowisku produkcyjnym bez udziału komitetu decyzyjnego stanowi jedno z najpoważniejszych zagrożeń dla ciągłości działania placówki medycznej?
• W jaki sposób zorganizować funkcjonowanie Awaryjnego Komitetu Zarządzania Zmianami (ECAB) w trybie dyżuru 24/7/365, aby nie opóźniać pilnych prac ratujących stabilność systemów, a jednocześnie zapobiec samowolnym działaniom informatyków?
• Jakie techniczne zabezpieczenia (np. Privilege Access Management, rejestracja sesji, blokada kont serwisowych) uniemożliwiają zewnętrznym dostawcom wprowadzanie nieautoryzowanych modyfikacji w schematach bazodanowych?

B. Wzorcowe rozwiązanie problemu (Dokumentacja poaudytowa):

• Karta ustaleń audytowych z opisem trzech niezgodności (NC1, NC2, NC3) i odniesieniem do ISO/IEC 27001:2022 (kontrola A.8.32) oraz art. 32 RODO.
• Standardowa Procedura Operacyjna (SOP): "Zarządzanie Zmianami Awaryjnymi w Szpitalnym Systemie Informacyjnym":
  • Definicja i kryteria eskalacji do trybu Emergency.
  • Schemat decyzyjny komitetu ECAB (wraz z procedurą zgody telefonicznej/SMS z tokenem autoryzacyjnym w godzinach nocnych).
  • Wymóg obowiązkowej migawki (Pre-change Snapshot) i zweryfikowanego skryptu cofającego (Rollback Script).
  • Formularz wniosku Emergency RFC (rejestrowany wstecznie w ciągu 24h w systemie zgłoszeniowym).
  • Procedura Przeglądu Po-wdrożeniowego (Post-Implementation Review - PIR) z udziałem ordynatorów.

C. Analiza zalet i wad proponowanego rozwiązania:

• Zalety: Wyeliminowanie niekontrolowanych modyfikacji baz danych szpitala; pełna rozliczalność działań zewnętrznych firm serwisowych; gwarancja natychmiastowego przywrócenia sprawności w razie błędu łatki; ochrona życia i zdrowia pacjentów; zgodność z wytycznymi CeZ i ISO 27001.
• Wady i ograniczenia: Wydłużenie czasu reakcji w sytuacjach nagłych awarii z uwagi na konieczność zwołania komitetu ECAB i przygotowania skryptu rollback; konieczność utrzymywania całodobowych dyżurów decyzyjnych kierownictwa medycznego i IT.

• Norma PN-EN ISO/IEC 27001:2022: Systemy zarządzania bezpieczeństwem informacji - Wymagania (Załącznik A: A.8.32 Zarządzanie zmianami, A.8.31 Rozdzielenie środowisk, A.8.29 Testowanie bezpieczeństwa).
• Norma PN-EN ISO/IEC 20000-1:2018: Zarządzanie usługami IT - Wymagania dotyczące systemu zarządzania usługami (punkt 8.5.1 Zarządzanie zmianami).
• Axelos: ITIL 4 Foundation: ITIL 4 Edition, TSO, London 2019 (Praktyka Change Enablement i zasady funkcjonowania Emergency CAB).
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) z dnia 27 kwietnia 2016 r. - art. 32 (Bezpieczeństwo przetwarzania i ochrona integralności).
• 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 e-Zdrowia (CeZ): "Standardy bezpieczeństwa dla systemów teleinformatycznych podmiotów wykonujących działalność leczniczą", Warszawa 2022.

• U2 Identyfikacja krytycznych luk w nadzorze nad zmianami awaryjnymi w podmiocie leczniczym.
• U1 Projekt procedury Emergency Change Management oraz regulaminu komitetu ECAB.
• U3 Szacowanie ryzyka medycznego i operacyjnego wynikającego z błędów wdrożeniowych hotfix.
• W1W2W3 Znajomość kontroli A.8.32 ISO 27001, wymogów RODO i metodyki ITIL w obszarze Change Management.
• K1K2K3 Etyka audytorska, bezstronność w ocenie błędów dostawcy i dbałość o dobro pacjenta.

Podczas wystąpienia skupcie się na wykazaniu, w jaki sposób brak procedury rollback zamienił drobną poprawkę wydajnościową w wielogodzinny paraliż ratowania zdrowia i życia pacjentów.

Celem zadania jest wykształcenie u studentów umiejętności przeprowadzania audytu fizycznej, logicznej i uprawnieniowej separacji środowisk programistycznych (DEV), testowych (TEST/STAGE) oraz produkcyjnych (PROD) w administracji samorządowej, ze szczególnym uwzględnieniem weryfikacji bezwzględnego zakazu wykorzystywania rzeczywistych danych osobowych mieszkańców do celów testowych i deweloperskich. Zadanie kładzie nacisk na ocenę zgodności z kontrolą A.8.31 i A.8.32 normy ISO/IEC 27001:2022, rygorami art. 25 (privacy by design/default) i art. 32 RODO oraz par. 20 Rozporządzenia w sprawie Krajowych Ram Interoperacyjności (KRI).

Powiązanie z sylabusem i treściami programowymi:

• U2 Identyfikacja niezgodności w architekturze sieciowej urzędu (brak separacji VLAN/firewall) oraz bezprawnym transferze produkcyjnych baz danych do środowisk deweloperskich.
• U1 Opracowanie zaleceń i projektu procedury bezpiecznej separacji środowisk oraz wdrożenia mechanizmów generowania danych syntetycznych i maskowania danych testowych.
• U3 Przeprowadzenie analizy ryzyka wycieku danych wrażliwych obywateli (PESEL, dochody, zaległości podatkowe) w wyniku prac zewnętrznych programistów na niezabezpieczonych stacjach roboczych.
• U4 Opracowanie pisemnego referatu oraz karty niezgodności audytowej dla Prezydenta Miasta i Inspektora Ochrony Danych.
• W1 Znajomość przepisów RODO dotyczących legalności przetwarzania danych i zakazu zmiany celu przetwarzania na cele testowe bez podstawy prawnej.
• W2W3 Zrozumienie normy ISO/IEC 27001:2022 (kontrole A.8.31 Rozdzielenie środowisk programistycznych, testowych i operacyjnych, A.8.33 Informacje testowe) oraz wymagań § 20 ust. 2 pkt 1-3 Rozporządzenia KRI.
• K1K2K3 Budowanie świadomości ochrony prywatności mieszkańców, rzetelności badania śladów kopiowania baz i etycznej postawy audytora publicznego.
• Powiązanie z wykładem: Wyk1 (Cele audytu w sektorze publicznym), Wyk3 (Kontrole A.8.31 i A.8.33 ISO 27001), Wyk4 (RODO i KRI w urzędzie), Wyk6 (Analiza uprawnień i badanie transferu danych), Wyk7 (Kategoryzacja niezgodności).

Urząd Miasta w Częstochowie obsługuje miasto na prawach powiatu liczące 215 tysięcy mieszkańców. W magistracie zatrudnionych jest ponad 600 urzędników przetwarzających dane osobowe obywateli w rejestrach meldunkowych, ewidencji gruntów i budynków, systemie Elektronicznego Zarządzania Dokumentacją (EZD RP) oraz dziedzinowym systemie podatków i opłat lokalnych.

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

• Urząd podpisał umowę z lokalną firmą software'ową na modernizację i integrację modułu e-Płatności i egzekucji podatku od nieruchomości z ogólnopolską platformą ePUAP/mObywatel.
• Podczas audytu ustalono, że w celu "zapewnienia maksymalnej wierności testów nowej wersji oprogramowania", główny informatyk urzędu sporządził pełny zrzut (dump) produkcyjnej bazy danych podatkowych zawierający 180 000 rekordów mieszkańców. Rekordy te obejmowały imiona, nazwiska, numery PESEL, adresy zamieszkania, numery ksiąg wieczystych, wielkości majątku oraz historię zadłużenia podatkowego.
• Plik zrzutu bazy (o objętości 45 GB) został skopiowany na niezabezpieczony serwer testowy znajdujący się w tej samej podsieci co biurowe komputery urzędników. Ponadto zrzut bazy został udostępniony na dysku sieciowym 5 programistom zewnętrznym, którzy skopiowali go na swoje prywatne laptopy służbowe w celu pracy zdalnej z domu.
• Dane w bazie testowej nie zostały poddane żadnemu procesowi anonimizacji, pseudonimizacji ani maskowania (Data Masking/Obfuscation). Wszelkie testy nowych funkcji systemu oraz procedury symulacji błędów wykonywane były na rzeczywistych danych mieszkańców Częstochowy.
• Co więcej, serwer deweloperski posiadał bezpośrednie połączenie sieciowe z produkcyjną bazą danych urzędu, a programiści zewnętrzni posiadali aktywne konta administratora ze stałymi hasłami zapisanymi jawnym tekstem w plikach konfiguracyjnych repozytorium kodu.
• Inspektor Ochrony Danych (IOD) urzędu nie został poinformowany o przekazaniu bazy danych do testów, a w rejestrze czynności przetwarzania brak było jakiejkolwiek wzmianki o operacjach przetwarzania danych w celach testowo-deweloperskich.

Prezydent Miasta, zaniepokojony ryzykiem gigantycznego wycieku danych i kar finansowych ze strony Urzędu Ochrony Danych Osobowych (UODO), zleca zespołowi audytorów szczegółową kontrolę separacji środowisk i bezpieczeństwa procesu wdrażania zmian.

Praca w zespole 2-3 osobowym polega na wszechstronnym zbadaniu separacji środowisk, weryfikacji transferu baz danych i opracowaniu ram Test Data Management:

• Krok 1 (Podział ról w grupie audytowej):

  Student 1 (Audytor Wiodący / Governance Samorządowe): Bada umowy z wykonawcą oprogramowania, klauzule powierzenia przetwarzania danych, uprawnienia IOD, obieg dokumentacji projektowej oraz koordynuje przygotowanie referatu.

  Student 2 (Audytor Techniczny ds. Sieci i Baz Danych): Bada konfigurację sieciową (brak VLAN i reguł firewall separujących DEV/TEST od PROD), analizuje uprawnienia dostępowe do baz danych, weryfikuje zawartość serwerów testowych i bada mechanizmy maskowania danych.

  Student 3 (Audytor Zgodności z RODO i KRI): Analizuje legalność transferu danych w świetle art. 5 (integralność, poufność, ograniczenie celu), art. 25, 32 RODO oraz par. 20 KRI; sporządza zestawienie niezgodności prawnych. W grupie 2-osobowej zadania te dzielą Studenci 1 i 2.

• Krok 2 (Inspekcja topologii sieciowej i uprawnień):

  Sprawdźcie tabelę routingu i reguły zapór sieciowych między strefami DEV, TEST i PROD. Wykażcie, że brak logicznej i fizycznej separacji stwarza ryzyko, iż błąd w kodzie testowym lub atak na środowisko DEV może bezpośrednio doprowadzić do przejęcia środowiska produkcyjnego.

• Krok 3 (Identyfikacja i klasyfikacja niezgodności):

  Zaklasyfikujcie wykryte nieprawidłowości:

  • Niezgodność krytyczna (NC1): Wykorzystanie pełnej produkcyjnej bazy danych mieszkańców z numerami PESEL i danymi majątkowymi w środowisku testowym oraz wyniesienie jej na laptopy zewnętrznych programistów bez anonimizacji (rażące naruszenie art. 5 ust. 1 lit. b, art. 25 i art. 32 RODO oraz kontroli ISO/IEC 27001:2022 A.8.31 i A.8.33).
  • Niezgodność większa (NC2): Całkowity brak fizycznej i sieciowej separacji środowisk DEV/TEST od sieci produkcyjnej urzędu oraz brak kontroli uprawnień (wspólne hasła administracyjne w plikach konfiguracyjnych).
  • Niezgodność mniejsza (NC3): Brak zaopiniowania przez Inspektora Ochrony Danych procedury wdrożeniowej oraz brak wpisu w Rejestrze Czynności Przetwarzania.
• Krok 4 (Opracowanie architektury bezpiecznej separacji i zarządzania danymi testowymi):

  Zaprojektujcie:

  • Architekturę 3-warstwową z pełną separacją sieciową (osobne VLAN-y, zapory sieciowe, całkowity brak routingu ze strefy DEV do bazy PROD).
  • Procedurę Test Data Management (TDM) opartą na generowaniu syntetycznych danych testowych (fikcyjne numery PESEL z poprawną sumą kontrolną, sztucznie generowane nazwiska i adresy) lub automatycznej, nieodwracalnej anonimizacji i maskowaniu danych produkcyjnych przed ich załadowaniem do strefy TEST.
  • Obowiązkowe audyty bezpieczeństwa i skanowanie podatności środowiska TEST przed przeniesieniem kodu na produkcję.

Plan wystąpienia seminaryjnego (10 minut):

• Profil Urzędu Miasta i opis skandalu z bazą danych mieszkańców (2 min): Przedstawienie skali przetwarzania danych, charakteru modernizacji systemu i faktu skopiowania bazy podatkowej (Student 1).
• Naruszenia techniczne i brak separacji środowisk (3 min): Omówienie braku barier sieciowych, dostępu zewnętrznych programistów i obecności haseł jawnym tekstem (Student 2).
• Prawne konsekwencje naruszenia RODO i KRI (2 min): Analiza ryzyka kar finansowych od UODO (do 100 tys. zł dla jednostki publicznej), utraty zaufania obywateli i odpowiedzialności karnej urzędników (Student 3 lub Student 1).
• Wzorcowy model separacji środowisk i danych syntetycznych (2 min): Prezentacja architektury trójstrefowej i technologii maskowania danych (Student 2).
• Podsumowanie, analiza wad i zalet (1 min): Dyskusja nad kosztami narzędzi TDM w zestawieniu z ochroną danych obywateli (cały zespół).

Zawartość składanego raportu poaudytowego (4-6 stron A4):

A. Odpowiedzi na pytania problemowe i opis sytuacyjny:

• Dlaczego wykorzystywanie produkcyjnych baz danych w środowiskach testowych i programistycznych jest surowo zabronione przez normy bezpieczeństwa (ISO 27001 A.8.33) i przepisy RODO?
• W jaki sposób technicznie zorganizować logiczną i sieciową separację środowisk programistycznych, testowych i produkcyjnych, aby uniemożliwić przenikanie złośliwego kodu lub nieuprawniony dostęp?
• Jakie są różnice między pseudonimizacją, anonimizacją a generowaniem syntetycznych danych testowych i które z tych rozwiązań gwarantuje stuprocentowe bezpieczeństwo w relacjach z zewnętrznymi dostawcami IT?

B. Wzorcowe rozwiązanie problemu (Dokumentacja naprawcza):

• Karta niezgodności audytowej zawierająca opis NC1, NC2 i NC3 oraz odniesienia do RODO, KRI i ISO 27001.
• Polityka Rozdzielenia Środowisk Teleinformatycznych Urzędu Miasta:
  • Schemat podziału na strefy: Strefa Programistyczna (DEV - środowisko odizolowane, brak dostępu do internetu i LAN urzędu), Strefa Testowa (TEST - strefa weryfikacji integracji i wydajności), Strefa Produkcyjna (PROD - strefa chroniona o najwyższym reżimie).
  • Zasady transferu kodu ze strefy TEST do PROD wyłącznie w drodze formalnego wniosku RFC i audytu kodu.
• Standard Zarządzania Danymi Testowymi (Test Data Management - TDM):
  • Wymóg stosowania generatorów danych syntetycznych (np. narzędzia Faker, Mockaroo) odwzorowujących strukturę bazy bez ujawniania tożsamości osób.
  • Matryca masek dla danych wrażliwych (maskowanie numerów PESEL, haszowanie kwot, podstawianie losowych adresów).

C. Analiza zalet i wad proponowanego rozwiązania:

• Zalety: Całkowite wyeliminowanie ryzyka wycieku danych mieszkańców przez firmy trzecie; pełna zgodność z art. 25 i 32 RODO oraz normą ISO 27001; uniemożliwienie przypadkowego uszkodzenia bazy produkcyjnej przez błędy w kodzie testowym.
• Wady i ograniczenia: Konieczność zakupu dodatkowych serwerów i licencji dla odrębnych środowisk; dodatkowy nakład pracy programistów na przygotowanie i utrzymanie bazy danych syntetycznych.

• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.8.31 (Rozdzielenie środowisk programistycznych, testowych i operacyjnych), A.8.32 (Zarządzanie zmianami), A.8.33 (Informacje testowe).
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) - art. 5 ust. 1 lit. b (zasada ograniczenia celu), art. 25 (uwzględnienie ochrony danych w fazie projektowania), art. 32 (bezpieczeństwo przetwarzania).
• Rozporządzenie Rady Ministrów z dnia 21 maja 2024 r. w sprawie Krajowych Ram Interoperacyjnych, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (...) (Dz.U. z 2024 r. poz. 773) - § 20 ust. 2 pkt 1-3.
• Urząd Ochrony Danych Osobowych (UODO): "Wytyczne dotyczące bezpieczeństwa przetwarzania danych w środowiskach testowych i programistycznych", Warszawa 2021.
• European Union Agency for Cybersecurity (ENISA): "Pseudonymisation techniques and best practices", Lizbona 2020.

• U2 Zdolność do wykrywania niedozwolonego transferu danych osobowych do środowisk testowych i braku separacji sieciowej.
• U1 Opracowanie polityki separacji środowisk trójwarstwowych i zasad generowania danych syntetycznych.
• U3 Szacowanie ryzyka prawnego, finansowego i reputacyjnego w samorządzie w przypadku naruszenia RODO.
• W1W2W3 Znajomość kontroli A.8.31 i A.8.33 ISO 27001, wymogów KRI oraz wytycznych UODO.
• K1K2K3 Wrażliwość na ochronę prywatności mieszkańców i przestrzeganie tajemnicy zawodowej audytora.

Zwróćcie uwagę na kluczową różnicę prawną między anonimizacją a pseudonimizacją w kontekście dopuszczalności przekazywania danych zewnętrznym programistom.

Głównym celem zadania jest praktyczne zapoznanie studentów z metodyką audytu Komitetu Zarządzania Zmianami (Change Advisory Board - CAB) oraz procesu oceny ryzyka ICT przed wdrożeniem zmian w instytucji sektora finansowego. Zadanie skupia się na weryfikacji spełnienia rygorystycznych wymogów Rekomendacji D i M Komisji Nadzoru Finansowego (KNF), Rozporządzenia Parlamentu Europejskiego i Rady (UE) 2022/2554 (DORA - Digital Operational Resilience Act) oraz kontroli A.8.32 normy ISO/IEC 27001:2022. Studenci badają zasady kolegialnego podejmowania decyzji, kategoryzację zmian, analizę wpływu na operacje finansowe oraz egzekwowanie rozdzielenia ról projektowych i wdrożeniowych.

Powiązanie z sylabusem i treściami programowymi:

• U2 Identyfikacja luk zarządczych (jednoosobowe zatwierdzanie krytycznych zmian przez szefa IT, brak posiedzeń CAB, pomijanie ocen ryzyka bezpieczeństwa).
• U1 Opracowanie regulaminu pracy Komitetu CAB, macierzy kategoryzacji zmian (Standard, Normal, Emergency) oraz kryteriów blokad wdrożeniowych (Go/No-Go Decision).
• U3 Przeprowadzenie analizy ryzyka operacyjnego i finansowego związanego z przerwą w obsłudze transakcji płatniczych i bankowości internetowej.
• U4 Sporządzenie profesjonalnego raportu poaudytowego dla Zarządu Banku i Rady Nadzorczej oraz przygotowanie wystąpienia referatowego.
• W1 Zrozumienie wymogów prawa bankowego w zakresie ciągłości świadczenia usług finansowych i odporności cyfrowej.
• W2W3 Znajomość standardów ISO/IEC 27001:2022, ITIL 4 (Change Enablement), Rekomendacji D KNF (obszar zarządzania zmianami teleinformatycznymi) oraz art. 9 i 12 rozporządzenia DORA.
• K1K2K3 Kształtowanie postawy niezależności audytorskiej, odporności na presję biznesową dążącą do szybkiego wdrażania zmian kosztem bezpieczeństwa i etyki sektora zaufania publicznego.
• Powiązanie z wykładem: Wyk1 (Audyt jako filar governance w finansach), Wyk2 (Zasady audytowania ISO 19011), Wyk3 (Kontrola A.8.32 ISO 27001), Wyk4 (DORA i Rekomendacja D KNF), Wyk5 (Risk-based audit w ITIL), Wyk7 (Raportowanie niezgodności).

Bank Spółdzielczy w Płocku jest regionalną instytucją finansową zrzeszoną w banku aprowizacyjnym, posiadającą 18 placówek oddziałowych i obsługującą 55 tysięcy klientów detalicznych oraz małych i średnich przedsiębiorstw. Bank świadczy usługi bankowości elektronicznej, płatności mobilnych (BLIK), rozliczeń międzybankowych Elixir oraz obsługuje kredyty gospodarcze.

Stan faktyczny w obszarze procesu Change Management:

• W ramach dostosowania do nowej wersji dyrektywy PSD2 oraz rozszerzenia funkcjonalności płatności natychmiastowych Express Elixir, bank zakupił od zewnętrznego integratora nową wersję modułu autoryzacji transakcji mobilnych.
• Wniosek o zmianę (RFC/2026/044) został zarejestrowany w systemie zgłoszeniowym przez kierownika wydziału IT. W dokumentacji wniosku w rubryce "Ocena ryzyka operacyjnego i bezpieczeństwa ICT" wpisano jedynie zdawkową adnotację: "Ryzyko znikome - rutynowa aktualizacja modułu komunikacyjnego".
• Zgodnie z Księgą Procedur Banku, wdrożenie zmian krytycznych wymaga zwołania posiedzenia Komitetu CAB składającego się z: Wiceprezesa ds. Operacyjnych, Kierownika IT, Inspektora Bezpieczeństwa Teleinformatycznego (CISO), Inspektora Ochrony Danych (IOD) oraz Głównego Księgowego.
• W praktyce, z powodu pośpiechu i presji marketingowej na uruchomienie promocji nowej aplikacji mobilnej, Kierownik IT podjął jednoosobową decyzję o zatwierdzeniu zmiany w niedzielę o godzinie 23:00, nie zwołując komitetu CAB i nie konsultując terminu z CISO.
• Wdrożenie produkcyjne zakończyło się błędem konfiguracji certyfikatów kryptograficznych mTLS w bramce płatniczej. W poniedziałek od godziny 07:30 klienci banku zostali całkowicie odcięci od bankowości elektronicznej i aplikacji mobilnej, a transakcje kartowe i wypłaty z bankomatów były odrzucane z kodem błędu autoryzacji.
• Awaria trwała 11 godzin w szczycie rozliczeń początków miesiąca (wypłaty wynagrodzeń, opłaty ZUS). Bank poniósł straty prowizyjne, musiał wypłacić rekompensaty przedsiębiorcom oraz stanął w obliczu postępowania wyjaśniającego wszczętego przez Departament Cyberbezpieczeństwa Urzędu KNF.

Zarząd Banku zleca zewnętrzny, niezależny audyt procesu zarządzania zmianą mający na celu zweryfikowanie przyczyn obejścia komitetu CAB i opracowanie procedur gwarantujących bezwzględną dyscyplinę wdrożeniową.

Praca w zespole 2-3 osobowym polega na zbadaniu struktury organizacyjnej komitetu CAB, analizie procesu akceptacji zmian oraz sformułowaniu wytycznych zgodnych z DORA i KNF:

• Krok 1 (Podział ról w grupie audytowej):

  Student 1 (Audytor Wiodący / Governance Bankowy): Bada statut banku, protokoły posiedzeń Zarządu i komitetu CAB, regulamin zarządzania zmianami, analizuje proces podejmowania decyzji i koordynuje przygotowanie referatu.

  Student 2 (Audytor Techniczny ds. Systemów Bankowych i Bezpieczeństwa ICT): Bada wniosek RFC/2026/044, konfigurację bramki płatniczej, błąd certyfikatów mTLS, logi wdrożeniowe oraz mechanizmy kontroli uprawnień wdrożeniowych na serwerach produkcyjnych.

  Student 3 (Audytor Zgodności Regulacyjnej i Ryzyka DORA/KNF): Analizuje wymogi Rekomendacji D (zwłaszcza pkt 8 i 11 dotyczących zarządzania zmianami i testowania) oraz art. 9 i 12 rozporządzenia DORA; formułuje karty niezgodności. W grupie 2-osobowej zadania te dzielą Studenci 1 i 2.

• Krok 2 (Triangulacja dowodów i badanie luki w procedurze):

  Skonfrontujcie regulamin zarządzania zmianami z faktycznymi logami systemu zgłoszeniowego. Ustalcie, dlaczego system IT pozwolił na zatwierdzenie zmiany o statusie "Krytyczna" jednemu użytkownikowi bez wymogu złożenia podpisów elektronicznych przez pozostałych członków CAB.

• Krok 3 (Identyfikacja i klasyfikacja niezgodności):

  Zaklasyfikujcie ustalenia audytowe:

  • Niezgodność krytyczna (NC1): Jednoosobowe zatwierdzenie i wdrożenie krytycznej zmiany w bankowości elektronicznej z pominięciem posiedzenia Komitetu CAB i bez oceny ryzyka ICT, co doprowadziło do 11-godzinnego paraliżu usług płatniczych (rażące naruszenie Rekomendacji D KNF, art. 9 DORA oraz kontroli A.8.32 ISO/IEC 27001:2022).
  • Niezgodność większa (NC2): Brak technicznych blokad wdrożeniowych w systemie ITSM uniemożliwiających uruchomienie pakietu instalacyjnego na produkcji bez kompletu cyfrowych akceptacji komitetu CAB (brak tzw. Quality Gate / Go-NoGo Decision).
  • Niezgodność mniejsza (NC3): Nierzetelna i lakoniczna analiza ryzyka we wniosku RFC, brak testów przeciążeniowych i brak testów integracyjnych z węzłem rozliczeniowym przed wdrożeniem.
• Krok 4 (Projekt procedury komitetu CAB i bramki akceptacyjnej):

  Zaprojektujcie:

  • Sformalizowany regulamin Komitetu CAB z określeniem kworum, procedury głosowania i bezwzględnym prawem weta przysługującym Oficerowi Bezpieczeństwa (CISO).
  • Matrycę kwalifikacji ryzyka zmiany: ocena w skali 1-5 (wpływ na klientów, złożoność techniczna, konieczność restartu usług, zaangażowanie podmiotów trzecich). Zmiany o łącznym wskaźniku ryzyka powyżej 10 wymagają obowiązkowej zgody Członka Zarządu ds. Technologii.
  • Techniczną bramkę akceptacyjną (Change Gatekeeper): automatyczną blokadę wdrożenia na poziomie narzędzi CI/CD i firewalla, znoszoną wyłącznie po zarejestrowaniu kryptograficznego podpisu kompletu członków CAB.

Struktura 10-minutowego referatu zespołowego:

• Bank Spółdzielczy i charakterystyka awarii bramki płatniczej (2 min): Przedstawienie skali działalności banku, przebiegu wdrożenia w nocy z niedzieli na poniedziałek i skutków biznesowych paraliżu BLIK/Elixir (Student 1).
• Wyniki audytu: syndrom "samotnego szeryfa IT" i fikcyjny komitet CAB (3 min): Omówienie przyczyn obejścia procedur, braku rzetelnej analizy ryzyka i błędów w konfiguracji mTLS (Student 2).
• Rygory regulacyjne: Rekomendacja D KNF i DORA w praktyce bankowej (2 min): Analiza konsekwencji prawnych, ryzyka kar od KNF i utraty reputacji na lokalnym rynku finansowym (Student 3 lub Student 1).
• Nowa architektura procesu decyzyjnego CAB i automatyczne bramki akceptacji (2 min): Prezentacja regulaminu CAB, matrycy ryzyka i technicznej blokady Go/No-Go (Student 2).
• Podsumowanie, analiza wad i zalet (1 min): Dyskusja o konieczności zachowania równowagi między zwinnością biznesową a bezpieczeństwem w bankowości (cały zespół).

Raport poaudytowy składany Zarządowi Banku (objętość 4-6 stron A4):

A. Odpowiedzi na pytania problemowe i opis sytuacyjny:

• W jaki sposób zorganizować funkcjonowanie Komitetu Zarządzania Zmianami (CAB) w instytucji finansowej, aby zapobiec patologii jednoosobowego zatwierdzania ryzykownych wdrożeń przez kadrę techniczną?
• Jakie kryteria oceny ryzyka ICT nakłada na banki rozporządzenie DORA i Rekomendacja D KNF przed wydaniem zgody na instalację oprogramowania w środowisku operacyjnym?
• Czym jest formalna decyzja "Go / No-Go" i jakie testy weryfikacyjne muszą zostać pomyślnie zrealizowane, aby zmiana mogła zostać skierowana do wdrożenia produkcyjnego?

B. Wzorcowe rozwiązanie problemu (Dokumentacja governance):

• Karta ustaleń audytowych z opisem niezgodności NC1, NC2 i NC3 oraz odniesieniem do standardów DORA, KNF i ISO 27001.
• Regulamin Komitetu Zarządzania Zmianami (CAB Charter) Banku Spółdzielczego:
  • Skład osobowy, zasady zwoływania posiedzeń (cotygodniowe posiedzenia planowe, posiedzenia nadzwyczajne).
  • Kategoryzacja zmian: Zmiany Standardowe (preautoryzowane, niskie ryzyko, powtarzalne), Zmiany Zwykłe (Normal - pełna ścieżka CAB), Zmiany Awaryjne (Emergency - rygorystyczny tryb ECAB).
  • Formularz Oceny Ryzyka Zmiany (Risk Scoring Matrix): ocena kryteriów technicznych, prawnych, biznesowych i operacyjnych.
• Procedura Formalnej Decyzji Go/No-Go:
  • Lista kontrolna (Checklist): kompletność testów UAT, raport ze skanowania podatności, zweryfikowany plan rollback, potwierdzenie gotowości wsparcia drugiej linii (2nd line support).

C. Analiza zalet i wad proponowanego rozwiązania:

• Zalety: Całkowite wyeliminowanie ryzyka samowolnych, nieprzetestowanych wdrożeń; pełna rozliczalność decyzji zarządczych; ochrona reputacji banku i środków klientów; bezwzględna zgodność z audytami KNF i wymogami DORA.
• Wady i ograniczenia: Nieznaczne wydłużenie czasu wprowadzenia nowej funkcjonalności na rynek (Time-to-Market); konieczność zaangażowania kadry kierowniczej w cykliczne posiedzenia komitetu CAB.

• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrola A.8.32 (Zarządzanie zmianami).
• 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 (Ochrona i zapobieganie) oraz art. 12 (Zarządzanie zmianami ICT).
• 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 teleinformatycznego).
• Komisja Nadzoru Finansowego: "Rekomendacja M dotycząca zarządzania ryzykiem operacyjnym w bankach", Warszawa 2013.
• Axelos: "ITIL 4: Change Enablement Practice Guide", PeopleCert 2020.

• U2 Identyfikacja nieprawidłowości w funkcjonowaniu komitetu CAB i braku ocen ryzyka zmian ICT.
• U1 Projekt regulaminu CAB, procedury decyzji Go/No-Go oraz matrycy kategoryzacji zmian.
• U3 Analiza ryzyka operacyjnego i finansowego w oparciu o wytyczne KNF i rozporządzenie DORA.
• W1W2W3 Znajomość wymogów DORA, Rekomendacji D KNF, kontroli A.8.32 ISO 27001 i metodyki ITIL.
• K1K2K3 Niezależność audytorska, profesjonalizm w sektorze finansowym i ochrona zaufania publicznego.

Zwróćcie uwagę na kluczową rolę prawa weta dla CISO w komitecie CAB – wyjaśnijcie, dlaczego interes bezpieczeństwa musi przeważać nad presją marketingową.

Celem zadania jest wykształcenie u studentów specjalistycznych umiejętności audytu procesu zarządzania zmianami w środowiskach automatyki przemysłowej (Operational Technology - OT / Industrial Control Systems - ICS) oraz systemach dyspozytorskich SCADA u Podmiotu Kluczowego. Studenci uczą się identyfikować specyficzne zagrożenia wynikające z przenoszenia praktyk IT bezpośrednio do środowiska przemysłowego, audytować modyfikacje kodu w sterownikach PLC, weryfikować procedury aktualizacji oprogramowania układowego (firmware) oraz badać koordynację prac modernizacyjnych z dyspozytorami ruchu sieci ciepłowniczej zgodnie z normą PN-EN ISO/IEC 27001 (A.8.32), standardem ISA/IEC 62443 oraz przepisami Ustawy o Krajowym Systemie Cyberbezpieczeństwa (KSC) i dyrektywy NIS2.

Powiązanie z sylabusem i treściami programowymi:

• U2 Identyfikacja krytycznych nieprawidłowości w procesie modyfikacji oprogramowania sterowników PLC (zdalne wgrywanie firmware bez okna serwisowego, brak kopii zapasowej logiki sterowania, brak autoryzacji dyspozytorskiej).
• U1 Opracowanie zaleceń i projektu procedury Industrial Change Management dla warstwy automatyki i sieci SCADA, w tym wymogu testowania zmian na stanowisku laboratoryjnym (Hardware-in-the-Loop).
• U3 Przeprowadzenie analizy ryzyka awarii fizycznej infrastruktury krytycznej, rozszczelnienia rurociągów magistralnych i wstrzymania dostaw ciepła dla ludności w sezonie zimowym.
• U4 Opracowanie ustrukturyzowanego raportu poaudytowego oraz wygłoszenie referatu przed audytorium akademickim.
• W1 Znajomość obowiązków podmiotów kluczowych wynikających z Ustawy o KSC i dyrektywy NIS2.
• W2W3 Zrozumienie normy ISO/IEC 27001:2022, standardu cyberbezpieczeństwa automatyki przemysłowej PN-EN IEC 62443 oraz wytycznych CSIRT NASK/GOV dla sektora energii i ciepłownictwa.
• K1K2K3 Rozwijanie poczucia odpowiedzialności za bezpieczeństwo fizyczne obywateli, infrastrukturę krytyczną kraju oraz zachowanie rygorów technicznych audytu.
• Powiązanie z wykładem: Wyk1 (Audyt w infrastrukturze krytycznej), Wyk3 (Kontrola A.8.32 ISO 27001 a specyfika OT), Wyk4 (Ustawa o KSC i NIS2), Wyk5 (Risk-based audit zagrożeń fizyczno-cyfrowych), Wyk6 (Analiza logów sterowników i inspekcja szaf telemetrycznych), Wyk7 (Klasyfikacja niezgodności).

Miejskie Przedsiębiorstwo Energetyki Cieplnej w Olsztynie (MPEC) jest operatorem sieci ciepłowniczej o długości 190 km, zaopatrującym w ciepło systemowe i ciepłą wodę użytkową 140 tysięcy mieszkańców, szpitale oraz obiekty użyteczności publicznej. Przedsiębiorstwo posiada status Podmiotu Kluczowego w rozumieniu Ustawy o KSC.

Stan faktyczny w obszarze zarządzania zmianami w systemach OT/SCADA:

• System sterowania i nadzoru opiera się na centralnej dyspozytorni SCADA komunikującej się za pośrednictwem radiomodemów i sieci APN z 450 węzłami cieplnymi i podstacjami wyposażonymi w programowalne sterowniki logiczne (PLC) Siemens i WAGO.
• W środku sezonu grzewczego (styczeń, temperatura zewnętrzna -12°C) zewnętrzny inżynier serwisu automatyki, realizując umowę utrzymaniową, dokonał zdalnego połączenia przez modem komórkowy ze sterownikami PLC w 12 głównych komorach ciepłowniczych magistrali północnej.
• Inżynier wgrał nową wersję oprogramowania układowego (firmware) oraz zaktualizował algorytm regulatora pogodowego i zaworów różnicy ciśnień. Zmiana została przeprowadzona o godzinie 14:00, bez zarejestrowania wniosku w procesie zarządzania zmianą przedsiębiorstwa, bez wyznaczonego okna serwisowego i bez jakiejkolwiek koordynacji z Głównym Dyspozytorem Mocy MPEC.
• Nowy algorytm zawierał błąd w skalowaniu sygnału z czujników ciśnienia, co doprowadziło do gwałtownego, całkowitego zamknięcia głównych zaworów dławiących. Nastąpiło gwałtowne zjawisko uderzenia hydraulicznego (skok ciśnienia do 22 barów), które wywołało rozszczelnienie rurociągu magistralnego DN 500 i wypływ tysięcy metrów sześciennych wrzącej wody do komory ciepłowniczej.
• Gdy dyspozytorzy próbowali zdalnie przejść na sterowanie ręczne, okazało się, że sterowniki po aktualizacji zawiesiły moduł komunikacji telemetrycznej. Co więcej, serwisant nie wykonał kopii zapasowej poprzedniego kodu sterowników przed aktualizacją, co uniemożliwiło szybki powrót do nastaw stabilnych i wymusiło awaryjne odcięcie ciepła dla 35 tysięcy mieszkańców na 36 godzin.

Zarząd Przedsiębiorstwa powołuje komisję audytową w celu zbadania rażących uchybień w procesie zarządzania zmianami w infrastrukturze OT i opracowania rygorystycznych procedur bezpieczeństwa.

Praca w zespole 2-3 osobowym polega na zbadaniu procesu zarządzania zmianą w automatyce przemysłowej, analizie przyczyn uderzenia hydraulicznego i opracowaniu procedur OT Change Management:

• Krok 1 (Podział ról w grupie audytowej):

  Student 1 (Audytor Wiodący / Governance Infrastruktury Krytycznej): Analizuje procedury nadrzędne podmiotu kluczowego, rejestr ryzyka KSC, umowę z firmą serwisową automatyki, procedury powiadamiania dyspozytorów oraz koordynuje przygotowanie referatu.

  Student 2 (Audytor Techniczny ds. Systemów OT/ICS i SCADA): Bada architekturę komunikacyjną sieci przemysłowej, logi zdalnego dostępu przez APN/modem, kod sterowników PLC, brak procedury backupu nastaw fabrycznych i brak stanowiska symulacyjnego.

  Student 3 (Audytor Zgodności z Ustawą o KSC i Standardem IEC 62443): Weryfikuje spełnienie wymagań art. 8-10 Ustawy o KSC (zarządzanie incydentami, dokumentacja bezpieczeństwa), normy ISO 27001 (A.8.32) oraz wytycznych IEC 62443-2-4; przygotowuje karty niezgodności. W grupie 2-osobowej zadania te dzielą Studenci 1 i 2.

• Krok 2 (Triangulacja dowodów w warstwie automatyki):

  Zestawcie zapisy z wykresu ciśnień i temperatur w systemie SCADA, logi zdalnego logowania serwisanta z modemu komórkowego oraz brak wpisu w dzienniku dyspozytorskim i brak zatwierdzonego wniosku RFC.

• Krok 3 (Identyfikacja i klasyfikacja niezgodności):

  Zaklasyfikujcie wykryte uchybienia:

  • Niezgodność krytyczna (NC1): Niekontrolowana, zdalna modyfikacja kodu sterowników PLC w trakcie sezonu grzewczego bez zatwierdzenia dyspozytora i bez okna serwisowego, skutkująca fizyczną awarią magistrali i wstrzymaniem dostaw ciepła (naruszenie Ustawy o KSC, standardu IEC 62443 oraz ISO/IEC 27001 A.8.32).
  • Niezgodność większa (NC2): Brak wymogu testowania modyfikacji oprogramowania układowego i logiki sterowników na stanowisku testowym (symulatorze HIL) oraz brak obowiązkowego backupu nastaw przed zmianą.
  • Niezgodność mniejsza (NC3): Niewystarczająca kontrola dostępu zdalnego serwisantów zewnętrznych (brak wymogu każdorazowej autoryzacji połączenia przez dyspozytora i brak rejestracji sesji inżynierskiej).
• Krok 4 (Projekt procedury Industrial Change Management dla środowisk OT):

  Zaprojektujcie:

  • Standardową Procedurę Zarządzania Zmianą w OT: bezwzględny zakaz wgrywania zmian bezpośrednio na obiekty czynne w trakcie sezonu grzewczego (poza stanami wyższej konieczności); obowiązkowe okno serwisowe wyznaczane wyłącznie w porozumieniu z dyspozytorem.
  • Stanowisko testowe (Hardware-in-the-Loop - HIL): obowiązek przetestowania każdego skryptu i firmware na zapasowym sterowniku PLC podłączonym do symulatora parametrów hydraulicznych.
  • Procedura bezpiecznego powrotu (Rollback & Fallback): obowiązkowy zrzut pamięci sterownika (Snapshot logic) przed rozpoczęciem programowania oraz obecność lokalnego przełącznika sterowania ręcznego uniezależnionego od firmware sterownika.

Plan seminaryjnego wystąpienia studenckiego (10 minut):

• Charakterystyka MPEC jako Podmiotu Kluczowego i opis awarii magistrali (2 min): Przedstawienie skali dostaw ciepła, awarii uderzenia hydraulicznego i jej skutków dla mieszkańców (Student 1).
• Luki audytowe w nadzorze nad automatyką przemysłową OT (3 min): Wyjaśnienie, dlaczego zdalne wgranie firmware bez wiedzy dyspozytora doprowadziło do katastrofy fizycznej (Student 2).
• Ramy prawne i odpowiedzialność w świetle Ustawy o KSC i NIS2 (2 min): Analiza obowiązków podmiotu kluczowego, ryzyka kar administracyjnych (do 200 tys. zł z KSC) i odpowiedzialności karnej za sprowadzenie niebezpieczeństwa powszechnego (Student 3 lub Student 1).
• Zintegrowany model Industrial Change Management (2 min): Prezentacja procedury HIL, bramek bezpieczeństwa dla inżynierów i autoryzacji dyspozytorskiej (Student 2).
• Podsumowanie, analiza wad i zalet (1 min): Dyskusja o specyfice bezpieczeństwa OT w relacji do tradycyjnego IT (cały zespół).

Raport poaudytowy dla Zarządu MPEC (objętość 4-6 stron A4):

A. Odpowiedzi na pytania problemowe i opis sytuacyjny:

• Czym różni się zarządzanie zmianami w środowiskach automatyki przemysłowej (OT/ICS) od procesów Change Management w tradycyjnym biurowym IT i dlaczego priorytetem w OT jest dostępność i bezpieczeństwo fizyczne (safety)?
• Dlaczego bezpośrednie wgrywanie oprogramowania układowego (firmware) do działających urządzeń wykonawczych bez testów laboratoryjnych (HIL) stanowi rażące naruszenie standardów cyberbezpieczeństwa przemysłowego?
• W jaki sposób zorganizować kontrolę dostępu zdalnego dla zewnętrznych serwisantów automatyki, aby wyeliminować możliwość nieautoryzowanych modyfikacji bez wiedzy dyżurnych inżynierów ruchu?

B. Wzorcowe rozwiązanie problemu (Dokumentacja inżynierska poaudytowa):

• Karta niezgodności audytowych z opisem NC1, NC2 i NC3 oraz odniesieniem do Ustawy o KSC, normy ISO 27001 i standardu IEC 62443.
• Instrukcja Bezpieczeństwa: "Zarządzanie Zmianami i Aktualizacjami w Infrastrukturze Telemetrii i Automatyki MPEC":
  • Kategoryzacja zmian w OT: Zmiany Konfiguracyjne (nastawy parametrów), Zmiany Logiki Sterowania (kod PLC), Zmiany Oprogramowania Układowego (Firmware).
  • Procedura Autoryzacji Dwustopniowej: Zgoda Kierownika Automatyki (analiza techniczna) + Zgoda Dyspozytora Mocy (analiza ruchowa sieci).
  • Wymóg testów HIL na stanowisku symulacyjnym przed wydaniem zgody na wdrożenie obiektowe.
  • Procedura Rollback: obowiązkowy zrzut obrazu pamięci PLC przed wpięciem kabla inżynierskiego.

C. Analiza zalet i wad proponowanego rozwiązania:

• Zalety: Zabezpieczenie mieszkańców przed katastrofalnymi awariami sieci ciepłowniczej; pełna kontrola dyspozytorów nad stanem urządzeń; spełnienie rygorów Ustawy o KSC i normy IEC 62443; eliminacja ryzyka uderzeń hydraulicznych.
• Wady i ograniczenia: Konieczność poniesienia kosztów budowy stanowiska symulacyjnego HIL; wydłużenie czasu wgrywania rutynowych poprawek przez serwisantów.

• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrola A.8.32 (Zarządzanie zmianami).
• 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 integracji i utrzymania.
• Ustawa z dnia 5 lipca 2018 r. o Krajowym Systemie Cyberbezpieczeństwa (tekst jedn. Dz.U. z 2026 r. poz. 20, zm. Dz.U. z 2026 r. poz. 252) - obowiązki Podmiotów Kluczowych.
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (Dyrektywa NIS2) - sektor energii i ciepłownictwa.
• CSIRT NASK / CSIRT GOV: "Wytyczne w zakresie bezpieczeństwa systemów sterowania przemysłowego (ICS/SCADA)", Warszawa 2022.
• NIST Special Publication 800-82 Rev. 2: "Guide to Industrial Control Systems (ICS) Security", National Institute of Standards and Technology, Gaithersburg 2015.

• U2 Identyfikacja nieprawidłowości w modyfikacjach oprogramowania sterowników PLC i sieciach przemysłowych OT.
• U1 Projekt procedury Industrial Change Management oraz zasad testowania zmian na stanowisku HIL.
• U3 Szacowanie ryzyka fizycznego, technologicznego i społecznego wynikającego z awarii infrastruktury ciepłowniczej.
• W1W2W3 Znajomość standardu IEC 62443, Ustawy o KSC, dyrektywy NIS2 i kontroli A.8.32 ISO 27001.
• K1K2K3 Świadomość odpowiedzialności za infrastrukturę krytyczną kraju i profesjonalizm inżynierski.

Podkreślcie różnicę w priorytetach: w tradycyjnym IT liczy się poufność danych, w automatyce przemysłowej OT najważniejsze jest bezpieczeństwo ludzi (safety) i niezawodność fizyczna.

Celem zadania jest opanowanie przez studentów praktycznych umiejętności przeprowadzania audytu nowoczesnych środowisk wytwórczych i wdrożeniowych opartych na metodyce zwinnej (Agile/DevOps), potokach ciągłej integracji i ciągłego wdrażania (CI/CD) w architekturze mikrousługowej chmury publicznej AWS. Zadanie koncentruje się na audycie wdrożenia automatycznych bramek bezpieczeństwa (Quality Gates, testy SAST, DAST, SCA), weryfikacji zarządzania sekretami wdrożeniowymi (klucze API, hasła do baz danych, tokeny autoryzacyjne) oraz badaniu zgodności procesu wydań z normą ISO/IEC 27001:2022 (kontrole A.8.25, A.8.28, A.8.32) oraz standardem Payment Card Industry Data Security Standard (PCI DSS v4.0).

Powiązanie z sylabusem i treściami programowymi:

• U2 Identyfikacja krytycznych podatności w procesie CI/CD (wyłączenie skanerów kodu w GitHub Actions, umieszczanie sekretów jawnym tekstem w repozytorium, brak zasady peer review).
• U1 Opracowanie zaleceń i projektu wdrożenia architektury DevSecOps, mechanizmów Secret Scanning oraz automatycznych blokad wdrożeniowych przy wykryciu luk bezpieczeństwa.
• U3 Przeprowadzenie analizy ryzyka kradzieży danych kart płatniczych klientów, kompromitacji konta chmurowego AWS oraz strat finansowych i kar ze strony organizacji płatniczych (Visa/Mastercard).
• U4 Sporządzenie profesjonalnego raportu poaudytowego oraz obrona koncepcji w referacie seminaryjnym.
• W1 Znajomość wymogów standardu PCI DSS v4.0 dotyczących bezpiecznego cyklu wytwarzania oprogramowania (wymóg 6.3 i 6.5) oraz ochrony danych uwierzytelniających.
• W2W3 Zrozumienie normy ISO/IEC 27001:2022 (kontrole Załącznika A: A.8.25 Bezpieczny cykl życia rozwoju, A.8.28 Bezpieczne kodowanie, A.8.32 Zarządzanie zmianami), standardu OWASP SAMM oraz wytycznych NIST SP 800-204 dotyczących bezpieczeństwa mikrousług.
• K1K2K3 Kształtowanie postawy rzetelności technologicznej, etyki badania repozytoriów programistycznych i odpowiedzialności za bezpieczeństwo transakcji internetowych.
• Powiązanie z wykładem: Wyk1 (Nowoczesne modele audytu systemów chmurowych), Wyk3 (Kontrole A.8.25, A.8.28 i A.8.32 ISO 27001), Wyk5 (Risk-based approach w środowiskach CI/CD), Wyk6 (Analiza commitów git, pipeline YAML i logów wdrożeniowych), Wyk7 (Raportowanie niezgodności).

ModaPolska.pl Sp. z o.o. jest wiodącą polską platformą handlu elektronicznego w branży odzieżowej, generującą roczne obroty na poziomie 180 milionów złotych i realizującą ponad 300 tysięcy transakcji zakupowych miesięcznie. Środowisko IT działa w modelu chmury publicznej Amazon Web Services (AWS) z wykorzystaniem klastrów konteneryzacji Kubernetes (Amazon EKS), baz danych Amazon RDS oraz bramek płatności internetowych PayU i Przelewy24.

Stan faktyczny w obszarze procesu Continuous Integration / Continuous Deployment (CI/CD):

• Zespół deweloperski liczy 22 programistów pracujących w metodyce Scrum. Wdrożenia nowych funkcjonalności i poprawek do sklepu internetowego odbywają się automatycznie wielokrotnie w ciągu dnia przy użyciu potoków GitHub Actions bezpośrednio na środowisko produkcyjne EKS.
• Podczas audytu procesu zarządzania zmianą zespół audytorski przeanalizował pliki konfiguracyjne potoków (`.github/workflows/deploy.yml`) oraz historię repozytorium kodu.
• Ustalono, że 4 miesiące wcześniej, po skargach programistów na "zbyt długi czas oczekiwania na wdrożenie i fałszywe alarmy", Tech Lead wyłączył w pipeline automatyczne etapy statycznej analizy kodu (SAST - SonarQube) oraz analizy podatności w bibliotekach open-source (SCA - Snyk).
• W repozytorium wyłączono również regułę Branch Protection na głównej gałęzi `main`. W rezultacie programiści mogli wprowadzać zmiany w kodzie i wypychać je na produkcję bezpośrednio, bez konieczności tworzenia Pull Requesta i bez wymogu zatwierdzenia kodu przez drugiego programistę (brak zasady Peer Review / Four Eyes Principle).
• Skrajnym przejawem braku kontroli było zdarzenie, w którym młodszy programista, testując integrację z nowym interfejsem bramki płatniczej, wpisał bezpośrednio w pliku źródłowym produkcyjny klucz API (Secret Key) do bramki PayU oraz hasło administracyjne do bazy danych klientów Amazon RDS. Plik ten został wypchnięty do repozytorium GitHub.
• Choć repozytorium było prywatne, to w wyniku infekcji stacji roboczej jednego z deweloperów złośliwym oprogramowaniem typu infostealer, token dostępowy do GitHuba został skradziony. Cyberprzestępcy pobrali historię repozytorium, wydobyli zcommitowane sekrety produkcyjne i podjęli próbę nieautoryzowanych wypłat środków oraz modyfikacji sum transakcji zakupowych.

Prezes Zarządu spółki, zaalarmowany incydentem bezpieczeństwa, zleca audyt potoku CI/CD, kontroli kodu źródłowego i zarządzania sekretami wdrożeniowymi.

Praca w zespole 2-3 osobowym polega na zbadaniu potoku CI/CD, weryfikacji zarządzania sekretami w chmurze AWS i opracowaniu architektury DevSecOps:

• Krok 1 (Podział ról w grupie audytowej):

  Student 1 (Audytor Wiodący / Governance E-commerce i Zgodności PCI DSS): Bada procedury wytwórcze, politykę bezpieczeństwa oprogramowania, standardy PCI DSS v4.0, umowy o pracę i uprawnienia deweloperów oraz koordynuje przygotowanie referatu.

  Student 2 (Audytor Techniczny ds. Chmury AWS i Pipeline CI/CD): Analizuje pliki konfiguracyjne GitHub Actions, historię commitów, mechanizmy ochrony gałęzi, bada konfigurację AWS Secrets Manager / Parameter Store oraz projektuje automatyczne bramki SAST/DAST.

  Student 3 (Audytor Zgodności z Normą ISO 27001 i RODO): Analizuje luki pod kątem kontroli A.8.25 (bezpieczny cykl rozwoju), A.8.28 (bezpieczne kodowanie), A.8.32 (zarządzanie zmianami) oraz art. 32 RODO; sporządza karty niezgodności. W grupie 2-osobowej zadania te dzielą Studenci 1 i 2.

• Krok 2 (Inspekcja kodu źródłowego i pipeline wdrożeniowego):

  Przeanalizujcie mechanizm wycieku kluczy API. Zastosujcie narzędzia audytowe do wykrywania zcommitowanych sekretów (np. TruffleHog / GitGuardian / git-secrets) i wykażcie, że obecność sekretów w historii git jest widoczna nawet po usunięciu ich w kolejnym commicie.

• Krok 3 (Identyfikacja i klasyfikacja niezgodności):

  Zaklasyfikujcie wykryte uchybienia w procesie:

  • Niezgodność krytyczna (NC1): Umieszczanie produkcyjnych kluczy API i haseł jawnym tekstem w repozytorium kodu oraz wyłączenie automatycznych skanerów bezpieczeństwa w potoku CI/CD, co doprowadziło do kompromitacji sekretów (rażące naruszenie PCI DSS 6.3 i 8.6 oraz ISO/IEC 27001:2022 A.8.28).
  • Niezgodność większa (NC2): Wyłączenie ochrony gałęzi głównej (Branch Protection Rules) i brak wymogu obowiązkowej recenzji kodu (Peer Review / Pull Request approval) przed automatycznym wdrożeniem na środowisko produkcyjne Kubernetes (naruszenie kontroli A.8.25 i A.8.32).
  • Niezgodność mniejsza (NC3): Brak automatycznej rotacji kluczy dostępowych i sekretów w chmurze AWS po wystąpieniu incydentu bezpieczeństwa.
• Krok 4 (Projekt architektury DevSecOps i zarządzania sekretami):

  Zaprojektujcie:

  • Wdrożenie potoku DevSecOps z nieprzekraczalnymi bramkami jakościowymi (Quality Gates): automatyczne skanowanie statyczne (SAST), analiza komponentów open-source (SCA) z blokadą buildu w razie wykrycia podatności CVE o poziomie High/Critical.
  • Ochronę gałęzi `main`: wymóg minimum 2 zatwierdzeń (Peer Review) od wyznaczonych Senior Developerów przed scaleniem kodu; wymóg podpisania każdego commita kluczem GPG.
  • Dedykowane zarządzanie sekretami: całkowity zakaz przechowywania sekretów w plikach konfiguracyjnych; wstrzykiwanie zmiennych środowiskowych w locie w klastrze EKS za pośrednictwem usługi AWS Secrets Manager z włączoną automatyczną rotacją kluczy co 30 dni.

Struktura wystąpienia referatowego (10 minut):

• Prezentacja spółki ModaPolska.pl i incydentu z wyciekiem kluczy PayU (2 min): Przedstawienie skali transakcji e-commerce, specyfiki częstych wdrożeń CI/CD i ataku infostealera (Student 1).
• Wyniki audytu potoku wdrożeniowego: wyłączone skanery i brak peer review (3 min): Omówienie luk w plikach GitHub Actions, ignorowania zasad bezpiecznego kodowania i trzymania haseł w gicie (Student 2).
• Wymogi standardu PCI DSS v4.0 i rygory organizacji płatniczych (2 min): Analiza ryzyka nałożenia kar finansowych przez Visa/Mastercard, zablokowania obsługi kart i naruszenia art. 32 RODO (Student 3 lub Student 1).
• Model docelowy: architektura DevSecOps i ochrona sekretów w AWS (2 min): Prezentacja bramek Quality Gates, reguł ochrony gałęzi i integracji z AWS Secrets Manager (Student 2).
• Podsumowanie, analiza wad i zalet (1 min): Dyskusja nad relacją między szybkością wdrożeń biznesowych a rygorami bezpieczeństwa kodu (cały zespół).

Raport poaudytowy dla Zarządu spółki ModaPolska.pl (objętość 4-6 stron A4):

A. Odpowiedzi na pytania problemowe i opis sytuacyjny:

• W jaki sposób zautomatyzować proces zarządzania zmianami w zwinnych zespołach programistycznych (CI/CD), aby nie spowalniać wydań oprogramowania, a jednocześnie zagwarantować pełną kontrolę bezpieczeństwa kodu?
• Dlaczego przechowywanie haseł i kluczy API w repozytoriach kodu (nawet prywatnych) stanowi rażące naruszenie elementarnych zasad higieny cyberbezpieczeństwa i normy PCI DSS?
• Na czym polega koncepcja "Shift Left" w procesie DevSecOps i jakie narzędzia (SAST, DAST, SCA) pozwalają na wczesne wykrywanie luk przed wdrożeniem produkcyjnym?

B. Wzorcowe rozwiązanie problemu (Dokumentacja techniczno-organizacyjna):

• Karta niezgodności audytowych z opisem NC1, NC2 i NC3 oraz odniesieniem do standardu PCI DSS v4.0 i normy ISO 27001.
• Standard Bezpiecznego Cyklu Życia Rozwoju Oprogramowania (Secure SDLC & DevSecOps Policy):
  • Wymogi formalne dla gałęzi `main`: obowiązek stosowania Pull Requestów, blokada bezpośredniego pusha, minimalna liczba recenzentów (2 approvale), pomyślny wynik wszystkich testów automatycznych.
  • Konfiguracja bramek bezpieczeństwa (Quality Gates): testy SAST (SonarQube) blokujące wdrożenie przy wykryciu luk OWASP Top 10; testy SCA (Snyk/Trivy) blokujące kod przy bibliotekach z podatnościami CVSS > 7.0.
• Standard Zarządzania Sekretami w Architekturze Chmurowej:
  • Wykorzystanie AWS Secrets Manager z integracją Kubernetes External Secrets Operator.
  • Narzędzie pre-commit hook (np. git-secrets) blokujące na stacji dewelopera próbę zatwierdzenia pliku zawierającego ciągi znaków przypominające klucze kryptograficzne.

C. Analiza zalet i wad proponowanego rozwiązania:

• Zalety: Całkowita eliminacja wycieków sekretów produkcyjnych; automatyczne wykrywanie podatności kodu na wczesnym etapie; pełna zgodność z rygorami PCI DSS v4.0 i ISO 27001; wysoki poziom bezpieczeństwa płatności klientów.
• Wady i ograniczenia: Wydłużenie czasu trwania pipeline'u CI/CD o kilka minut na czas wykonania skanów; konieczność przeszkolenia zespołu programistów z zasad bezpiecznego kodowania (Secure Coding).

• 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", Wakefield 2022 (Wymóg 6: Rozwój i utrzymanie bezpiecznych systemów i oprogramowania).
• Open Web Application Security Project (OWASP): "OWASP Software Assurance Maturity Model (SAMM) v2.0", 2020.
• NIST Special Publication 800-204: "Security Strategies for Microservices-based Application Systems", National Institute of Standards and Technology, Gaithersburg 2019.
• Amazon Web Services: "AWS Security Best Practices for Secrets Management", AWS Whitepaper 2023.

• U2 Zdolność do identyfikacji luk bezpieczeństwa w potokach CI/CD, konfiguracji repozytoriów git i zarządzaniu sekretami.
• U1 Projekt architektury DevSecOps, bramek automatycznych Quality Gates i polityki Secure SDLC.
• U3 Szacowanie ryzyka biznesowego w sektorze e-commerce w świetle rygorów PCI DSS i RODO.
• W1W2W3 Znajomość standardu PCI DSS v4.0, kontroli A.8.25/A.8.28/A.8.32 ISO 27001 oraz metodyk DevSecOps.
• K1K2K3 Etyka audytu kodu programistycznego, skrupulatność techniczna i odpowiedzialność za bezpieczeństwo cyfrowe transakcji.

Zademonstrujcie na referacie, jak prosta reguła w pliku YAML potoku CI/CD oraz mechanizm pre-commit hook mogą skutecznie zapobiec kompromitacji wartych miliony złotych kluczy produkcyjnych.

Głównym celem zadania jest wykształcenie u studentów umiejętności przeprowadzania audytu procesu zarządzania poprawkami i aktualizacjami bezpieczeństwa (Patch Management), weryfikacji spójności bazy elementów konfiguracji (Configuration Management Database - CMDB) oraz oceny dojrzałości procedur wersjonowania oprogramowania w jednostce sektora finansów publicznych. Zadanie koncentruje się na zidentyfikowaniu rażących błędów wdrożeniowych polegających na masowej instalacji niesprawdzonych łatek systemowych bezpośrednio na stacjach produkcyjnych, braku podziału stacji na grupy testowo-wdrożeniowe (Deployment Rings) oraz braku aktualnej inwentaryzacji zasobów informatycznych zgodnie z kontrolami A.8.8, A.8.9 i A.8.32 normy ISO/IEC 27001:2022 oraz wymogami par. 20 ust. 2 pkt 1 i 7 Krajowych Ram Interoperacyjności (KRI).

Powiązanie z sylabusem i treściami programowymi:

• U2 Identyfikacja niezgodności (NC1/NC2/NC3), braków w ewidencji CMDB, samowolnego wdrażania poprawek bez testów regresyjnych oraz braku harmonogramu aktualizacji.
• U1 Opracowanie zaleceń i projektu procedury Patch Management, polityki zarządzania konfiguracjami oraz harmonogramu testowania łatek w środowisku odizolowanym.
• U3 Przeprowadzenie analizy ryzyka paraliżu państwowych egzaminów na prawo jazdy, utraty łączności z centralną ewidencją kierowców (CEPIK) i strat finansowych ośrodka.
• U4 Opracowanie pisemnego referatu oraz raportu z audytu procedur aktualizacyjnych dla Dyrektora WORD i Urzędu Marszałkowskiego.
• W1 Znajomość przepisów prawa o ruchu drogowym w zakresie organizacji egzaminów państwowych oraz wymogów KRI w obszarze ewidencji oprogramowania i podatności.
• W2W3 Zrozumienie normy PN-EN ISO/IEC 27001:2022 (kontrole A.8.8 Zarządzanie podatnościami technicznymi, A.8.9 Zarządzanie konfiguracją, A.8.32 Zarządzanie zmianami) oraz wytycznych NIST SP 800-40 dotyczących strategii zarządzania poprawkami.
• K1K2K3 Kształtowanie profesjonalizmu audytorskiego, rzetelności badania logów systemowych Windows Update/WSUS oraz etycznej odpowiedzialności za sprawność usług publicznych.
• Powiązanie z wykładem: Wyk1 (Audyt zgodności w jednostkach samorządowych), Wyk3 (Kontrole A.8.8 i A.8.9 ISO 27001), Wyk4 (Rozporządzenie KRI w praktyce), Wyk6 (Analiza logów aktualizacji i sampling stacji roboczych), Wyk7 (Klasyfikacja niezgodności).

Wojewódzki Ośrodek Ruchu Drogowego w Lublinie (WORD) jest samorządową jednostką organizacyjną prowadzącą państwowe egzaminy teoretyczne i praktyczne na prawo jazdy dla mieszkańców województwa lubelskiego. Ośrodek posiada centralę w Lublinie oraz 3 oddziały terenowe (Chełm, Zamość, Biała Podlaska), dysponując łącznie 80 stanowiskami komputerowymi w salach egzaminacyjnych, 4 serwerami lokalnymi oraz flotą 60 pojazdów egzaminacyjnych wyposażonych w cyfrowe rejestratory audio-wideo.

Stan faktyczny w obszarze procesu zarządzania konfiguracją i poprawkami:

• System egzaminacyjny opiera się na dedykowanej aplikacji klienckiej zainstalowanej na komputerach w salach egzaminacyjnych, która łączy się z lokalnym serwerem bazodanowym WORD oraz za pośrednictwem bezpiecznego łącza VPN przesyła wyniki egzaminów w czasie rzeczywistym do państwowego rejestru CEPIK 2.0 (Centralna Ewidencja Pojazdów i Kierowców).
• W ośrodku brak jest sformalizowanej bazy danych elementów konfiguracji (CMDB) oraz jednolitej ewidencji wersji oprogramowania. Część komputerów pracuje pod kontrolą systemu Windows 10 w różnych kompilacjach, a część pod kontrolą Windows 11. Na stacjach zainstalowane są różne wersje środowiska uruchomieniowego .NET Framework oraz zróżnicowane pakiety oprogramowania antywirusowego.
• W nocy z wtorku na środę samodzielny administrator IT, chcąc wykonać rutynowe zalecenia cyberbezpieczeństwa, wdrożył za pomocą centralnej usługi WSUS (Windows Server Update Services) zbiorczą comiesięczną aktualizację zabezpieczeń systemu Windows na wszystkich 80 komputerach egzaminacyjnych we wszystkich 4 miastach jednocześnie.
• Aktualizacja została przeprowadzona bez uprzedniego przetestowania łatki na maszynie testowej (Pilot Group), bez weryfikacji kompatybilności z aplikacją egzaminacyjną i bez poinformowania Egzaminatora Nadzorującego.
• W środę o godzinie 07:45, w momencie rozpoczęcia pierwszej tury egzaminów państwowych, okazało się, że zainstalowana łatka systemowa zmodyfikowała reguły zapory sieciowej Windows Defender Firewall oraz unieważniła powiązania bibliotek kryptograficznych modułu komunikacji z CEPIK. Aplikacja egzaminacyjna nie mogła pobrać pytań testowych z bazy centralnej ani autoryzować profili kandydatów (PKK).
• W rezultacie odwołano egzaminy teoretyczne dla 240 kandydatów, doszło do awantur na korytarzach ośrodków, a sprawa trafiła do lokalnych mediów i Urzędu Marszałkowskiego.
• Administrator, próbując cofnąć zmiany, zorientował się, że przed instalacją aktualizacji wyłączył na stacjach tworzenie punktów przywracania systemu (System Restore Points), co wymusiło ręczną reinstalację oprogramowania na każdym z 80 stanowisk i sparaliżowało pracę ośrodka na 2 dni robocze.

Dyrektor WORD zleca przeprowadzenie niezależnego audytu procedur zarządzania konfiguracją, wersjonowania oraz procesu instalacji poprawek bezpieczeństwa.

Praca w zespole 2-3 osobowym polega na zbadaniu cyklu życia poprawek, audycie rejestru CMDB i opracowaniu bezpiecznej procedury Patch Management:

• Krok 1 (Podział ról w grupie audytowej):

  Student 1 (Audytor Wiodący / Governance Sektora Samorządowego): Bada regulamin organizacyjny WORD, umowy licencyjne na oprogramowanie egzaminacyjne, procedury nadzoru Urzędu Marszałkowskiego oraz koordynuje przygotowanie referatu.

  Student 2 (Audytor Techniczny ds. Systemów Operacyjnych i WSUS): Bada konfigurację serwera WSUS, zasady wdrażania GPO, logi instalacji poprawek na stacjach egzaminacyjnych, brak tworzenia punktów przywracania oraz analizuje błąd integracji z CEPIK.

  Student 3 (Audytor Zgodności z KRI i ISO 27001): Analizuje spełnienie wymogów par. 20 ust. 2 pkt 1 i 7 KRI (inwentaryzacja i zarządzanie podatnościami), kontroli A.8.8, A.8.9 i A.8.32 ISO/IEC 27001; sporządza karty niezgodności. W grupie 2-osobowej zadania te dzielą Studenci 1 i 2.

• Krok 2 (Inspekcja bazy konfiguracyjnej i logów aktualizacji):

  Przeprowadźcie inwentaryzację próbki 10 stacji egzaminacyjnych. Wykażcie brak standaryzacji obrazu systemu (Golden Image), brak ewidencji zainstalowanych poprawek (KB) w CMDB oraz brak harmonogramu testów przedwdrożeniowych.

• Krok 3 (Identyfikacja i klasyfikacja niezgodności):

  Zaklasyfikujcie wykryte luki w procesie:

  • Niezgodność krytyczna (NC1): Masowe wdrożenie niesprawdzonych aktualizacji systemowych na wszystkich stacjach egzaminacyjnych bez testów na środowisku pilotowym i z wyłączonymi punktami przywracania, co doprowadziło do paraliżu egzaminów państwowych (naruszenie kontroli ISO/IEC 27001:2022 A.8.8, A.8.32 oraz par. 20 ust. 2 pkt 7 KRI).
  • Niezgodność większa (NC2): Całkowity brak sformalizowanej bazy elementów konfiguracji (CMDB) oraz brak ujednoliconego, zatwierdzonego obrazu stacji roboczej (Golden Image) wymaganego przez kontrolę A.8.9 ISO 27001.
  • Niezgodność mniejsza (NC3): Brak komunikacji z kadrą egzaminacyjną o planowanych pracach konserwacyjnych oraz brak procedury powiadamiania ministerstwa o awarii integracji z CEPIK.
• Krok 4 (Projekt procedury Patch Management i pierścieni wdrożeniowych):

  Zaprojektujcie:

  • Architekturę pierścieni wdrożeniowych (Deployment Rings):
    • Pierścień 0 (Test/Lab): 2 stacje odizolowane w dziale IT (instalacja natychmiast po wydaniu poprawki przez producenta).
    • Pierścień 1 (Pilot): po 1 stacji w każdej sali egzaminacyjnej, na których egzaminatorzy weryfikują działanie z CEPIK przez 5 dni roboczych.
    • Pierścień 2 (Produkcja): pozostałe stacje robocze, aktualizowane dopiero po pisemnej akceptacji Egzaminatora Nadzorującego.
  • Standaryzację stacji egzaminacyjnych: wdrożenie jednolitego obrazu systemu z zablokowaną możliwością samowolnej instalacji łat i obowiązkowym zachowaniem co najmniej 2 punktów przywracania systemu przed aktualizacją.
  • Wdrożenie bazy CMDB rejestrującej każdą maszynę, wersję systemu operacyjnego, sumę kontrolną oprogramowania egzaminacyjnego oraz status podatności.

Struktura 10-minutowego wystąpienia seminaryjnego:

• Profil WORD w Lublinie i paraliż egzaminów państwowych na prawo jazdy (2 min): Przedstawienie skali działalności ośrodka, roli systemu CEPIK i skutków społeczno-medialnych nagłej awarii (Student 1).
• Wyniki audytu: brak CMDB, chaotyczne łatki WSUS i brak punktów przywracania (3 min): Przedstawienie dowodów braku testów, instalacji łatki na żywym organizmie i wyłączenia funkcji System Restore (Student 2).
• Wymogi Krajowych Ram Interoperacyjności i normy ISO 27001 (2 min): Analiza prawnych obowiązków jednostek samorządowych w zakresie inwentaryzacji IT i zarządzania podatnościami (Student 3 lub Student 1).
• Nowy model: pierścienie wdrożeniowe (Deployment Rings) i standaryzacja Golden Image (2 min): Prezentacja etapowego wdrażania poprawek i architektury bazy CMDB (Student 2).
• Podsumowanie, analiza wad i zalet (1 min): Dyskusja o konieczności równoważenia bieżącego łatania podatności z zachowaniem stabilności procesów egzaminacyjnych (cały zespół).

Raport poaudytowy składany Dyrekcji WORD (objętość 4-6 stron A4):

A. Odpowiedzi na pytania problemowe i opis sytuacyjny:

• Dlaczego automatyczna, bezkrytyczna instalacja poprawek bezpieczeństwa bezpośrednio na środowiskach produkcyjnych bez wcześniejszego przetestowania niesie ze sobą ryzyko równe lub wyższe niż niezałatana podatność?
• W jaki sposób zorganizować proces zarządzania poprawkami (Patch Management) w oparciu o koncepcję pierścieni wdrożeniowych (Deployment Rings), aby uniknąć paraliżu operacyjnego placówki?
• Jakie funkcje w procesie zarządzania zmianami pełni baza danych elementów konfiguracji (CMDB) i dlaczego brak aktualnej CMDB uniemożliwia rzetelne oszacowanie wpływu planowanej aktualizacji?

B. Wzorcowe rozwiązanie problemu (Dokumentacja operacyjno-techniczna):

• Karta ustaleń audytowych z opisem niezgodności NC1, NC2 i NC3 oraz odniesieniem do KRI i normy ISO 27001 (A.8.8, A.8.9, A.8.32).
• Polityka Zarządzania Poprawkami i Konfiguracjami Teleinformatycznymi WORD:
  • Harmonogram wdrożeń łatek (Patch Tuesday -> Test Ring w ciągu 48h -> Pilot Ring po 7 dniach -> Production Ring po 14 dniach).
  • Wyjątki dla podatności krytycznych (Zero-Day Exploits): tryb awaryjny pod warunkiem pomyślnego testu modułu CEPIK na maszynie laboratoryjnej.
  • Obowiązkowa procedura wycofania (Uninstall Package / Rollback) wbudowana w skrypt wdrożeniowy WSUS.
• Karta Elementu Konfiguracji (CI) dla stacji egzaminacyjnej w systemie CMDB:
  • Specyfikacja sprzętowa, wersja systemu operacyjnego, numer kompilacji (Build), wersja klienta CEPIK, status szyfrowania dysku BitLocker, data ostatniej instalacji poprawek.

C. Analiza zalet i wad proponowanego rozwiązania:

• Zalety: Całkowite wyeliminowanie ryzyka niespodziewanego paraliżu egzaminów państwowych; pełna przejrzystość posiadanych zasobów sprzętowo-programowych w CMDB; zgodność z wymogami KRI; możliwość natychmiastowego cofnięcia wadliwej łatki.
• Wady i ograniczenia: Wydłużenie czasu instalacji łatek na stacjach produkcyjnych o 7-14 dni (konieczność monitorowania podatności w okresie kwarantanny); konieczność wygospodarowania dodatkowych stacji na laboratorium testowe.

• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.8.8 (Zarządzanie podatnościami technicznymi), A.8.9 (Zarządzanie konfiguracją), A.8.32 (Zarządzanie zmianami).
• Rozporządzenie Rady Ministrów z dnia 21 maja 2024 r. w sprawie Krajowych Ram Interoperacyjnych, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (...) (Dz.U. z 2024 r. poz. 773) - § 19 ust. 2 pkt 2 (aktualizacja inwentaryzacji) oraz § 19 ust. 2 pkt 12 lit. f-g (ograniczanie ryzyka z wykorzystania opublikowanych podatnosci).
• NIST Special Publication 800-40 Rev. 4: "Guide to Enterprise Patch Management Planning: Recommendations for Implementing an Effective Patch Management Program", National Institute of Standards and Technology, Gaithersburg 2022.
• Ustawa z dnia 5 stycznia 2011 r. o kierujących pojazdami (Dz.U. z 2023 r. poz. 622 z późn. zm.) - zasady przeprowadzania egzaminów państwowych.
• Center for Internet Security (CIS): "CIS Controls v8 - Control 07: Continuous Vulnerability Management", 2021.

• U2 Identyfikacja nieprawidłowości w procesie dystrybucji poprawek systemowych i braku bazy CMDB.
• U1 Projekt procedury Patch Management opartej na pierścieniach wdrożeniowych oraz architektury bazy konfiguracji.
• U3 Szacowanie ryzyka operacyjnego i społecznego wynikającego z awarii rejestrów egzaminacyjnych.
• W1W2W3 Znajomość kontroli A.8.8 i A.8.9 ISO 27001, wymogów KRI oraz wytycznych NIST SP 800-40.
• K1K2K3 Obiektywizm audytorski, dbałość o jakość usług publicznych i dyscyplina inżynierska.

Podczas prezentacji wyjaśnijcie ideę pierścieni wdrożeniowych (Deployment Rings) – dlaczego nawet zaufana poprawka od firmy Microsoft musi przejść okres kwarantanny na maszynach pilotowych.

Celem zadania jest praktyczne zapoznanie studentów z metodyką audytu procedur wycofania zmian (Rollback Plan / Fallback Procedure) oraz rzetelności przeprowadzania i dokumentowania testów akceptacyjnych użytkowników końcowych (User Acceptance Testing - UAT) w instytucjach wymiaru sprawiedliwości. Zadanie koncentruje się na zbadaniu przyczyn katastrofalnych awarii systemów dziedzinowych wynikających z wdrożenia nieprzetestowanych aktualizacji oprogramowania repertoryjnego, braku weryfikacji kopii zapasowych przed migracją struktur danych oraz zignorowania udziału sędziów i protokolantów w odbiorach technicznych oprogramowania zgodnie z normą ISO/IEC 27001:2022 (kontrole A.8.29, A.8.32), Ustawą - Prawo o ustroju sądów powszechnych oraz Krajowymi Ramami Interoperacyjności.

Powiązanie z sylabusem i treściami programowymi:

• U2 Identyfikacja krytycznych nieprawidłowości (brak planu rollback, brak punktu przywracania danych, fikcyjne podpisanie protokołów odbioru UAT przez osoby nieuprawnione).
• U1 Opracowanie zaleceń i projektu procedury Rollback & Fallback Management oraz sformalizowanego regulaminu prowadzenia testów UAT z udziałem kluczowych interesariuszy.
• U3 Przeprowadzenie analizy ryzyka paraliżu konstytucyjnego prawa obywateli do sądu, zablokowania publikacji wyroków i wygaśnięcia terminów procesowych w sprawach karnych i cywilnych.
• U4 Opracowanie ustrukturyzowanego raportu poaudytowego dla Prezesa Sądu i Dyrektora Sądu oraz wygłoszenie referatu akademickiego.
• W1 Znajomość wymogów prawnych dotyczących jawności rozpraw, terminowości sporządzania uzasadnień orzeczeń i ochrony integralności cyfrowych akt sądowych.
• W2W3 Zrozumienie normy PN-EN ISO/IEC 27001:2022 (kontrole A.8.29 Testowanie bezpieczeństwa w rozwoju i akceptacji, A.8.32 Zarządzanie zmianami), standardu ISTQB w obszarze UAT oraz wymogów Rozporządzenia Ministra Sprawiedliwości w sprawie prowadzenia biurowości w sądach.
• K1K2K3 Rozwijanie postawy bezstronności, odwagi w ujawnianiu pozornych kontroli w instytucjach publicznych oraz etycznej dbałości o praworządność.
• Powiązanie z wykładem: Wyk1 (Audyt w wymiarze sprawiedliwości), Wyk2 (Zasady audytowania ISO 19011), Wyk3 (Kontrole A.8.29 i A.8.32 ISO 27001), Wyk6 (Triangulacja protokołów UAT z logami bazodanowymi), Wyk7 (Ocena istotności niezgodności i formułowanie zaleceń).

Sąd Rejonowy w Kaliszu obejmuje swoją właściwością obszar zamieszkany przez 160 tysięcy osób, prowadząc 9 wydziałów orzeczniczych (Wydziały Cywilne, Karne, Rodzinne i Nieletnich, Pracy i Ubezpieczeń Społecznych oraz Ksiąg Wieczystych). W sądzie orzeka 42 sędziów i asesorów, wspieranych przez 120 pracowników sekretariatów i protokolantów.

Stan faktyczny w obszarze wdrożenia nowej wersji oprogramowania sądowego:

• Kluczowym narzędziem pracy orzeczniczej jest zintegrowany system CURIA-SĘDZIA służący do przydziału spraw, generowania elektronicznych wokand, rejestracji protokołów rozpraw oraz podpisywania uzasadnień i wyroków za pomocą kwalifikowanego podpisu elektronicznego na kartach kryptograficznych.
• W piątek o godzinie 16:30, po zakończeniu urzędowania, zewnętrzna firma wdrożeniowa rozpoczęła instalację nowej wersji oprogramowania oznaczonej jako v4.2, obejmującej modyfikację struktury relacyjnej bazy danych Microsoft SQL Server oraz wdrożenie nowego komponentu obsługi bibliotek kryptograficznych PKI.
• W dokumentacji wniosku o zmianę (RFC) widniał protokół odbioru testów UAT podpisany formalnie przez kierownika sekretariatu ogólnego. W toku audytu ustalono jednak, że testy UAT były całkowicie fikcyjne: kierownik podpisał protokół "na prośbę wykonawcy", nie uruchamiając nawet oprogramowania, a żaden sędzia ani protokolant nie został zaproszony do zweryfikowania działania nowej wersji na sprzęcie orzeczniczym.
• Wdrożenie produkcyjne w piątkowy wieczór zakończyło się zgłoszeniem błędów relacji tabelarycznych w module spraw karnych. Co gorsza, nowy komponent PKI okazał się niekompatybilny ze starszymi czytnikami kart procesorowych używanymi powszechnie w salach rozpraw.
• W poniedziałek o godzinie 08:30 sędziowie nie mogli otworzyć wokand ani podpisać wyroków w sprawach aresztowych. Gdy Prezes Sądu nakazał natychmiastowe wycofanie wdrożenia i powrót do poprzedniej, stabilnej wersji v4.1, okazało się, że wykonawca NIE przygotował planu wycofania zmiany (Rollback Plan).
• Skrypt migracji bazy danych nie posiadał procedury odwracającej (Downgrade SQL script). Co więcej, zrzut bazy danych wykonany rzekomo przed migracją zakończył się błędem braku miejsca na dysku i był uszkodzony.
• W rezultacie sędziowie musieli odroczyć 85 rozpraw, doszło do przekroczenia ustawowych terminów procesowych w sprawach tymczasowego aresztowania, a powrót do sprawności wymagał 3 dni żmudnej ręcznej naprawy uszkodzonych struktur danych przez inżynierów producenta.

Prezes Sądu powołuje zespół audytorów w celu zbadania mechanizmu fałszywego odbioru UAT, braku procedury wycofania i wdrożenia procedur uniemożliwiających powtórzenie takiego paraliżu.

Praca w zespole 2-3 osobowym polega na zbadaniu przebiegu testów akceptacyjnych, audycie wniosku RFC i opracowaniu rygorystycznej procedury Rollback Plan:

• Krok 1 (Podział ról w grupie audytowej):

  Student 1 (Audytor Wiodący / Governance Sądownictwa): Bada akta sprawy wdrożeniowej, umowę z dostawcą oprogramowania CURIA, procedury nadzoru prezesa sądu, protokoły odbioru UAT oraz koordynuje przygotowanie referatu.

  Student 2 (Audytor Techniczny ds. Baz Danych i Architektury PKI): Analizuje logi migracji bazy SQL Server, skrypty DDL, uszkodzony zrzut backupu, błąd bibliotek PKI i bada brak technicznego scenariusza rollback.

  Student 3 (Audytor Zgodności z Normą ISO 27001 i Prawem o Ustroju Sądów): Weryfikuje naruszenie kontroli A.8.29 i A.8.32 ISO/IEC 27001, przepisów regulaminu urzędowania sądów oraz prawa do rzetelnego procesu (art. 45 Konstytucji RP); sporządza karty niezgodności. W grupie 2-osobowej zadania te dzielą Studenci 1 i 2.

• Krok 2 (Triangulacja dowodów fikcyjnych odbiorów):

  Skonfrontujcie treść podpisanego protokołu testów UAT (gdzie deklarowano 100% poprawności) z logami logowania sędziów na środowisku testowym (wykażcie zero logowań) oraz logami błędów krytycznych bazy danych z nocy wdrożenia.

• Krok 3 (Identyfikacja i klasyfikacja niezgodności):

  Zaklasyfikujcie ujawnione nieprawidłowości:

  • Niezgodność krytyczna (NC1): Wdrożenie krytycznej zmiany w systemie orzeczniczym sądu bez przygotowanego i zweryfikowanego planu wycofania (Rollback Plan) oraz z uszkodzoną kopią bezpieczeństwa, co doprowadziło do 3-dniowego paraliżu wymiaru sprawiedliwości (naruszenie kontroli ISO/IEC 27001:2022 A.8.32 oraz art. 45 Konstytucji RP).
  • Niezgodność większa (NC2): Fikcyjne przeprowadzenie testów akceptacyjnych użytkowników (UAT) i poświadczenie nieprawdy w protokole odbioru bez udziału sędziów i protokolantów (naruszenie kontroli A.8.29 ISO 27001).
  • Niezgodność mniejsza (NC3): Brak wyznaczenia w harmonogramie wdrożenia tzw. "punktu bez powrotu" (Point of No Return) oraz brak obecności inżyniera wsparcia na sali rozpraw w pierwszym dniu roboczym po wdrożeniu.
• Krok 4 (Projekt procedury Rollback Management i standardu testów UAT):

  Zaprojektujcie:

  • Szablon Planu Wycofania Zmiany (Rollback Plan) stanowiący obligatoryjny załącznik do każdego wniosku RFC:
    • Kryteria decyzji o wycofaniu (np. nieuruchomienie krytycznej funkcji w ciągu 120 minut od startu prac lub wystąpienie błędów integralności bazy).
    • Gotowy, uprzednio przetestowany skrypt cofający (Reverse SQL Script).
    • Obowiązkowy punkt kontrolny: weryfikacja sumy kontrolnej i integralności backupu wykonanego tuż przed migracją (Pre-migration Verified Snapshot).
  • Regulamin Testów Akceptacyjnych Użytkowników (UAT Policy): obowiązkowe powołanie grupy testowej złożonej z min. 3 sędziów i 3 protokolantów; weryfikacja scenariuszy krytycznych (podpis wyroku, generowanie wokandy, wysyłka do portalu orzeczeń); zakaz akceptacji wdrożenia bez pisemnych podpisów użytkowników kluczowych.

Plan wystąpienia seminaryjnego (10 minut):

• Prezentacja Sądu Rejonowego w Kaliszu i paraliżu wokand sądowych (2 min): Przedstawienie skali orzecznictwa, znaczenia systemu CURIA i konstytucyjnych skutków zablokowania spraw aresztowych (Student 1).
• Wyniki audytu śledczego: fikcyjny protokół UAT i brak planu rollback (3 min): Omówienie dowodów braku testów ze strony sędziów, uszkodzonego backupu i braku skryptów cofających migrację bazy danych (Student 2).
• Aspekty prawne i odpowiedzialność dyscyplinarno-odszkodowawcza (2 min): Analiza naruszenia normy ISO 27001, prawa o ustroju sądów powszechnych i roszczeń odszkodowawczych stron procesu za bezprawne odroczenie rozpraw (Student 3 lub Student 1).
• Nowa architektura procedury Rollback i rygorystyczny proces UAT (2 min): Prezentacja szablonu Rollback Planu, punktu bez powrotu (Point of No Return) i grupy testowej sędziów (Student 2).
• Podsumowanie, analiza wad i zalet (1 min): Dyskusja o roli audytora w eliminacji zjawiska "podpisywania protokołów na wiarę" w sektorze publicznym (cały zespół).

Raport poaudytowy składany Prezesowi i Dyrektorowi Sądu (objętość 4-6 stron A4):

A. Odpowiedzi na pytania problemowe i opis sytuacyjny:

• Czym jest formalny Plan Wycofania Zmiany (Rollback / Fallback Plan) i dlaczego żaden wniosek RFC o średnim lub wysokim poziomie ryzyka nie może zostać zatwierdzony bez jego szczegółowego opracowania i przetestowania?
• W jaki sposób zorganizować rzetelne Testy Akceptacyjne Użytkowników (UAT) w organizacji o specyficznej kulturze pracy (np. w sądzie, gdzie użytkownikami są niezawiśli sędziowie), aby uniknąć formalnego, bezrefleksyjnego podpisywania odbiorów?
• Co oznacza pojęcie "Punktu bez powrotu" (Point of No Return) w harmonogramie wdrożenia i jakie kryteria decyzyjne muszą zostać zdefiniowane przez kierownika projektu przed przekroczeniem tego punktu?

B. Wzorcowe rozwiązanie problemu (Dokumentacja procedur sądowych):

• Karta ustaleń audytowych z opisem niezgodności NC1, NC2 i NC3 oraz odniesieniem do ISO/IEC 27001 (A.8.29, A.8.32) i przepisów ustroju sądów.
• Procedura Zarządzania Testami UAT w Sądzie Rejonowym:
  • Matryca Scenariuszy Testowych (Test Case Matrix): scenariusz logowania sędziego, scenariusz podpisu wyroku podpisem kwalifikowanym, scenariusz eksportu wokandy do gabloty elektronicznej, scenariusz symulacji braku łączności.
  • Wymóg uzyskania 100% pozytywnych wyników dla testów krytycznych (Blocker) przed podpisaniem protokołu odbioru.
• Standard Planu Wycofania (Rollback Management Standard):
  • Wymóg utworzenia pełnego, odtwarzalnego obrazu bazy danych przed zmianą, zweryfikowanego skryptem CHECKDB.
  • Harmonogram czasowy: wyznaczenie godziny granicznej (np. niedziela g. 18:00) jako Point of No Return. W razie niewdrożenia poprawki do tej godziny - obligatoryjne uruchomienie procedury cofania zmian bez dyskusji.

C. Analiza zalet i wad proponowanego rozwiązania:

• Zalety: Całkowita ochrona sądu przed wielodniowym paraliżem pracy orzeczniczej; wyeliminowanie fikcyjnych odbiorów oprogramowania; pełna rozliczalność dostawcy oprogramowania; zagwarantowanie konstytucyjnego prawa obywatela do sądu.
• Wady i ograniczenia: Wydłużenie czasu przygotowania wdrożenia o konieczność opracowania i testowania skryptów cofających; konieczność zaangażowania sędziów i protokolantów w testy kosztem ich bieżących obowiązków orzeczniczych.

• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.8.29 (Testowanie bezpieczeństwa w rozwoju i akceptacji), A.8.32 (Zarządzanie zmianami).
• Ustawa z dnia 27 lipca 2001 r. - Prawo o ustroju sądów powszechnych (Dz.U. z 2023 r. poz. 217 z późn. zm.).
• Rozporządzenie Ministra Sprawiedliwości z dnia 18 czerwca 2019 r. - Regulamin urzędowania sądów powszechnych (Dz.U. z 2024 r. poz. 867).
• International Software Testing Qualifications Board (ISTQB): "Certified Tester Foundation Level (CTFL) Syllabus v4.0", 2023 (Moduł Acceptance Testing).
• Axelos: "ITIL 4: Change Enablement Practice Guide", PeopleCert 2020 (Zasady planowania wycofania zmian).

• U2 Identyfikacja krytycznych braków w planach rollback oraz wykrywanie pozornych testów akceptacyjnych UAT.
• U1 Projekt procedury Rollback Plan, wyznaczania punktu bez powrotu oraz standardu testów UAT.
• U3 Szacowanie ryzyka prawnego, konstytucyjnego i operacyjnego w instytucjach wymiaru sprawiedliwości.
• W1W2W3 Znajomość kontroli A.8.29 i A.8.32 ISO 27001, metodyki ISTQB oraz prawa o ustroju sądów powszechnych.
• K1K2K3 Niezłomność audytorska, dbałość o państwo prawa i obiektywizm w badaniu procedur administracji publicznej.

Podkreślcie na referacie, że testy UAT nie mogą być traktowane jako biurokratyczna formalność – brak zaangażowania rzeczywistych użytkowników (sędziów) doprowadził w tym przypadku do naruszenia konstytucyjnych praw obywateli.

Głównym celem zadania jest opanowanie przez studentów umiejętności audytu procesów nadzoru nad zmianami technicznymi, aplikacyjnymi i architektonicznymi wprowadzanymi przez zewnętrznych dostawców usług chmurowych (Third-Party Change Governance / Cloud SaaS Change Management) w podmiocie sektora ubezpieczeniowego. Zadanie skupia się na weryfikacji zgodności z rygorystycznymi wymogami Rozporządzenia DORA (Digital Operational Resilience Act - art. 28-30 dotyczące zarządzania ryzykiem ze strony zewnętrznych dostawców usług ICT), Wytycznych KNF dotyczących zarządzania obszarami technologii informacyjnej w zakładach ubezpieczeń oraz kontroli A.5.19, A.5.21, A.5.22 i A.8.32 normy ISO/IEC 27001:2022. Studenci analizują umowy SLA-Change, procedury powiadamiania o zmianach w chmurze (Cloud Release Notifications) oraz testowanie kompatybilności interfejsów API w środowiskach piaskownicy (Sandbox).

Powiązanie z sylabusem i treściami programowymi:

• U2 Identyfikacja luk prawno-organizacyjnych w relacjach z dostawcą SaaS (brak klauzul notyfikacji o zmianach z wyprzedzeniem, jednostronne zmiany protokołów i API przez dostawcę, brak środowiska testowego Sandbox).
• U1 Opracowanie zaleceń i projektu ramowej procedury Third-Party Change Management oraz wzorcowego aneksu do umów SLA określającego obowiązki notyfikacyjne i kary umowne.
• U3 Przeprowadzenie analizy ryzyka paraliżu sieci sprzedaży agencyjnej, braku możliwości zawierania polis i zgłaszania szkód oraz naruszenia wymogów raportowych wobec UFG i KNF.
• U4 Opracowanie ustrukturyzowanego raportu poaudytowego dla Zarządu Towarzystwa Ubezpieczeń i Komitetu Ryzyka.
• W1 Znajomość przepisów Ustawy o działalności ubezpieczeniowej i reasekuracyjnej oraz zasad nadzoru KNF nad powierzaniem czynności (outsourcing ubezpieczeniowy).
• W2W3 Zrozumienie rozporządzenia DORA (zwłaszcza rozdziału V dotyczącego zarządzania ryzykiem ze strony dostawców zewnętrznych), normy ISO/IEC 27001:2022 (bezpieczeństwo w relacjach z dostawcami) oraz wytycznych EIOPA w sprawie outsourcingu do dostawców usług w chmurze.
• K1K2K3 Rozwijanie postawy asertywności audytorskiej w relacjach z globalnymi korporacjami technologicznymi, profesjonalizmu w analizie umów IT i dbałości o stabilność rynku finansowego.
• Powiązanie z wykładem: Wyk1 (Audyt w łańcuchu dostaw ICT), Wyk3 (Kontrole A.5.19-A.5.22 oraz A.8.32 ISO 27001), Wyk4 (Rozporządzenie DORA i nadzór KNF), Wyk5 (Risk-based approach do ryzyka dostawców zewnętrznych), Wyk7 (Formułowanie rekomendacji naprawczych).

Towarzystwo Ubezpieczeń na Życie Omnia Polska S.A. obsługuje ponad 850 tysięcy aktywnych polis ubezpieczeniowych, współpracując z siecią 2500 agentów wyłącznych i multiagencji w całej Polsce.

Stan faktyczny w obszarze korzystania z usług chmurowych i zarządzania zmianami zewnętrznymi:

• Głównym narzędziem operacyjnym ubezpieczyciela jest system likwidacji szkód, kalkulacji ryzyk i wystawiania polis OMNIA-CLOUD, dostarczany w modelu Software-as-a-Service (SaaS) przez globalnego dostawcę chmurowego z siedzibą w Irlandii. System integruje się za pośrednictwem interfejsów REST API z wewnętrznymi systemami finansowo-księgowymi towarzystwa oraz z bazą Ubezpieczeniowego Funduszu Gwarancyjnego (UFG).
• W umowie zawartej z dostawcą SaaS 3 lata temu nie zawarto precyzyjnych klauzul dotyczących procedury zarządzania zmianami (Change Management Agreement). Umowa przewidywała jedynie ogólnikowy zapis, że "Dostawca zastrzega sobie prawo do ciągłego doskonalenia i aktualizacji platformy w celu zapewnienia jej wysokiej wydajności".
• W nocy z czwartku na piątek dostawca chmurowy wdrożył jednostronnie na platformie produkcyjnej dużą aktualizację architektury bezpieczeństwa: wyłączył obsługę protokołu TLS 1.2, wymuszając wyłącznie TLS 1.3, oraz zmienił format nagłówków autoryzacyjnych w interfejsie API bez zachowania wstecznej kompatybilności.
• Dostawca opublikował informację o zmianie jedynie w formie wpisu na ogólnodostępnym blogu technicznym, nie przesyłając żadnego formalnego ostrzeżenia do działu IT Omnia Polska. Towarzystwo nie posiadało wykupionego dostępu do dedykowanego środowiska testowego (Sandbox), na którym mogłoby zweryfikować integrację przed wdrożeniem globalnym.
• W piątek od godziny 08:00 agenci w całej Polsce zostali odcięci od możliwości rejestracji nowych wniosków ubezpieczeniowych, a wewnętrzny system przestał komunikować się z bazą UFG (błąd negocjacji szyfrów SSL/TLS i niepoprawny nagłówek API).
• Paraliż trwał 2 dni robocze i cały weekend, uniemożliwiając wypłatę 450 świadczeń powypadkowych i wywołując lawinę skarg do Rzecznika Finansowego oraz konieczność zgłoszenia incยdentu poważnego do Urzędu KNF na mocy rozporządzenia DORA.

Zarząd Omnia Polska powołuje zespół audytorów w celu zbadania mechanizmów nadzoru nad dostawcą chmurowym i opracowania rygorystycznej polityki Third-Party Change Management.

Praca w zespole 2-3 osobowym polega na zbadaniu umowy outsourcingu chmurowego, analizie incydentu niekompatybilności API i opracowaniu procedur zgodnych z DORA:

• Krok 1 (Podział ról w grupie audytowej):

  Student 1 (Audytor Wiodący / Governance Sektora Finansowego): Bada umowę ramową i SLA z dostawcą SaaS, politykę zarządzania ryzykiem dostawców ICT, zgodność z wytycznymi KNF i koordynuje przygotowanie referatu.

  Student 2 (Audytor Techniczny ds. Usług Chmurowych i Integracji API): Bada logi błędów komunikacji TLS 1.2/1.3, zmiany w specyfikacji Swagger/OpenAPI dostawcy, mechanizmy monitorowania release notes oraz projektuje środowisko Sandbox.

  Student 3 (Audytor Zgodności z Rozporządzeniem DORA i Normą ISO 27001): Weryfikuje spełnienie wymagań art. 28-30 rozporządzenia DORA (prawa do audytu, wymogi powiadamiania o zmianach, plany wyjścia), kontroli ISO 27001 (A.5.19, A.5.21, A.5.22, A.8.32); sporządza karty niezgodności. W grupie 2-osobowej zadania te dzielą Studenci 1 i 2.

• Krok 2 (Analiza prawno-techniczna umowy i kanałów komunikacji dostawcy):

  Przeanalizujcie zapisy umowy serwisowej. Wykażcie, że brak zdefiniowanego terminu powiadamiania o zmianach (Notice Period) oraz brak gwarancji utrzymywania wstecznej kompatybilności API przez określony czas (Deprecation Policy) stanowił rażącą lukę kontraktową.

• Krok 3 (Identyfikacja i klasyfikacja niezgodności):

  Zaklasyfikujcie wykryte uchybienia:

  • Niezgodność krytyczna (NC1): Brak umownych mechanizmów kontroli nad zmianami wprowadzanymi przez dostawcę krytycznych usług chmurowych (brak wymogu formalnej notyfikacji z min. 30-dniowym wyprzedzeniem i brak środowiska Sandbox), co doprowadziło do 2-dniowego paraliżu działalności ubezpieczeniowej (rażące naruszenie art. 28 i 30 DORA, Wytycznych KNF oraz kontroli ISO/IEC 27001:2022 A.5.21 i A.8.32).
  • Niezgodność większa (NC2): Brak procedury wewnętrznego monitorowania komunikatów o aktualizacjach (Release Management) u dostawców chmurowych i brak okresowych testów kompatybilności systemów integrujących.
  • Niezgodność mniejsza (NC3): Niewystarczająca redundancja w architekturze integracyjnej (brak możliwości czasowego kolejkowania transakcji w trybie offline podczas niedostępności bramki API).
• Krok 4 (Projekt ram Third-Party Change Management i aneksu SLA-Change):

  Zaprojektujcie:

  • Standardowy Aneks do Umów Outsourcingu ICT (Change Governance Addendum):
    • Obowiązek formalnego powiadamiania o wszelkich zmianach architektury, protokołów i interfejsów API z wyprzedzeniem minimum 60 dni (dla zmian krytycznych) i 30 dni (dla zmian standardowych).
    • Obowiązek udostępnienia bezpłatnego środowiska piaskownicy (Sandbox) z nową wersją oprogramowania na minimum 30 dni przed jej wdrożeniem na produkcji globalnej.
    • Gwarancja wsparcia dla poprzedniej wersji interfejsu API przez minimum 6 miesięcy od publikacji nowej wersji (API Deprecation Policy).
    • Rygorystyczne kary umowne za jednostronne wdrożenie zmian destabilizujących operacje ubezpieczyciela.
  • Wewnętrzną Procedurę Monitorowania Dostawców ICT w Omnia Polska: powołanie Change Managera ds. Chmury odpowiedzialnego za cotygodniową analizę biuletynów technicznych i koordynację testów w środowisku Sandbox.

Plan wystąpienia seminaryjnego (10 minut):

• Prezentacja Omnia Polska S.A. i paraliżu operacyjnego wywołanego zmianą w chmurze (2 min): Przedstawienie skali działalności, uzależnienia od platformy SaaS i skutków zerwania integracji z UFG (Student 1).
• Wyniki audytu: iluzoryczny nadzór nad dostawcą i brak środowiska Sandbox (3 min): Omówienie luk w umowie, jednostronnego wyłączenia TLS 1.2 i braku testów integracyjnych (Student 2).
• Rozporządzenie DORA i nadzór KNF nad łańcuchem dostaw ICT (2 min): Analiza rygorów prawnych art. 28-30 DORA, wymogu zarządzania ryzykiem koncentracji i ryzyka sankcji regulacyjnych (Student 3 lub Student 1).
• Model naprawczy: Change Governance Addendum i procedura wczesnego ostrzegania (2 min): Prezentacja klauzul umownych, polityki deprecjacji API i zasad testowania w piaskownicy (Student 2).
• Podsumowanie, analiza wad i zalet (1 min): Dyskusja o wyzwaniach w negocjacjach umownych z globalnymi gigantami chmurowymi (cały zespół).

Raport poaudytowy dla Zarządu Omnia Polska S.A. (objętość 4-6 stron A4):

A. Odpowiedzi na pytania problemowe i opis sytuacyjny:

• W jaki sposób podmiot sektora finansowego może skutecznie egzekwować kontrolę nad procesem zarządzania zmianami u zewnętrznych dostawców usług chmurowych (SaaS/PaaS) w warunkach asymetrii pozycji negocjacyjnej?
• Jakie bezwzględne wymagania w zakresie zarządzania ryzykiem ze strony dostawców zewnętrznych ICT nakłada na zakłady ubezpieczeń rozporządzenie DORA (art. 28-30)?
• Dlaczego posiadanie środowiska testowego (Sandbox) u dostawcy SaaS oraz rygorystyczna polityka wygaszania interfejsów API (API Deprecation Policy) są warunkiem koniecznym bezpiecznej integracji chmurowej?

B. Wzorcowe rozwiązanie problemu (Dokumentacja governance i prawna):

• Karta ustaleń audytowych z opisem niezgodności NC1, NC2 i NC3 oraz odniesieniem do rozporządzenia DORA, Wytycznych KNF i normy ISO 27001 (A.5.21, A.8.32).
• Wzorcowe Klauzule Umowne do Umowy Zarządzania Zmianami z Dostawcą Chmurowym (Change Management Agreement):
  • Definicje poziomów zmian: Major Release, Minor Release, Emergency Security Patch.
  • Matryca Terminów Notyfikacji: min. 60 dni dla Major Release, min. 30 dni dla zmian API/TLS, min. 48h dla Emergency Patches.
  • Wymóg udostępnienia środowiska Staging/Sandbox odzwierciedlającego architekturę produkcyjną do testów akceptacyjnych klienta.
  • Kary umowne za naruszenie procedury notyfikacyjnej skutkujące niedostępnością usług ubezpieczeniowych.
• Standard Operacyjny Nadzoru nad Zmianami Zewnętrznymi:
  • Procedura weryfikacji kompatybilności kryptograficznej (TLS, certyfikaty mTLS, algorytmy szyfrowania).
  • Testy regresyjne automatycznych zapytań API w środowisku piaskownicy przed terminem wdrożenia produkcyjnego.

C. Analiza zalet i wad proponowanego rozwiązania:

• Zalety: Odzyskanie kontroli nad stabilnością procesów biznesowych zależnych od chmury; pełna zgodność z rygorystycznymi wymogami DORA i KNF; zabezpieczenie ciągłości sprzedaży polis i likwidacji szkód; eliminacja ryzyka niespodziewanego zerwania integracji.
• Wady i ograniczenia: Wyższy koszt abonamentu SaaS z tytułu utrzymywania dedykowanego środowiska Sandbox; konieczność renegocjacji kontraktu z dostawcą zagranicznym i ryzyko oporu prawnego ze strony korporacji chmurowej.

• 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 ICT), A.5.22 (Monitorowanie, przegląd i zarządzanie zmianami w usługach dostawców), A.8.32 (Zarządzanie zmianami).
• 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 (art. 28-30).
• Komisja Nadzoru Finansowego: "Wytyczne dotyczące zarządzania obszarami technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego w zakładach ubezpieczeń i zakładach reasekuracji", Warszawa 2014.
• Europejski Urząd Nadzoru Ubezpieczeń i Pracowniczych Programów Emerytalnych (EIOPA): "Wytyczne w sprawie outsourcingu do dostawców usług w chmurze", Frankfurt 2020.
• Cloud Security Alliance (CSA): "Security Guidance for Critical Areas of Focus in Cloud Computing v4.0", 2017.

• U2 Zdolność do identyfikacji luk kontraktowych i operacyjnych w procesie zarządzania zmianami u dostawców SaaS.
• U1 Opracowanie wzorcowych klauzul Change Management Addendum oraz procedury nadzoru nad dostawcami ICT.
• U3 Szacowanie ryzyka regulacyjnego i operacyjnego wynikającego z rozporządzenia DORA i wytycznych KNF.
• W1W2W3 Znajomość przepisów DORA, kontroli A.5.21/A.5.22/A.8.32 ISO 27001 oraz wytycznych EIOPA.
• K1K2K3 Profesjonalizm audytorski w badaniu umów międzynarodowych i ochrona interesu klientów instytucji finansowych.

Zwróćcie uwagę na referacie na fakt, że w świetle rozporządzenia DORA odpowiedzialność za brak odporności cyfrowej ponosi zawsze zarząd instytucji finansowej – nie można zasłaniać się winą zagranicznego dostawcy chmury.

Celem zadania jest wykształcenie u studentów umiejętności przeprowadzania audytu planowania, harmonogramowania i zarządzania oknami serwisowymi (Maintenance Windows) w systemach teleinformatycznych działających w reżimie ciągłym (24 godziny na dobę, 7 dni w tygodniu, 365 dni w roku) ze szczególnym uwzględnieniem służb ratownictwa medycznego i powiadamiania ratunkowego. Zadanie koncentruje się na badaniu procedur wyznaczania ram czasowych prac modernizacyjnych, weryfikacji wielokanałowej komunikacji operacyjnej z dyspozytorami medycznymi, ocenie mechanizmów zapewnienia wysokiej dostępności (High Availability / Zero Downtime Deployment) oraz badaniu gotowości do wdrożenia procedur awaryjnych (Fallback to Manual Procedures) zgodnie z normą ISO/IEC 27001:2022 (kontrola A.8.32), Ustawą o Państwowym Ratownictwie Medycznym oraz Krajowymi Ramami Interoperacyjności.

Powiązanie z sylabusem i treściami programowymi:

• U2 Identyfikacja rażących błędów organizacyjnych (prowadzenie prac modernizacyjnych w godzinach szczytu operacyjnego, powiadomienie dyspozytorów mailem na 15 minut przed wyłączeniem sieci, brak weryfikacji gotowości procedury papierowej).
• U1 Opracowanie zaleceń i projektu Polityki Okien Serwisowych (Maintenance Window Policy) dla systemów ratunkowych oraz procedur przełączania bezprzerwowego.
• U3 Przeprowadzenie analizy ryzyka utraty zdrowia i życia pacjentów w wyniku zrzucenia połączeń alarmowych z numeru 112/999 oraz braku możliwości dysponowania ambulansów do wypadków.
• U4 Opracowanie raportu poaudytowego dla Dyrektora Stacji Pogotowia i Wojewody oraz przygotowanie referatu seminaryjnego.
• W1 Znajomość Ustawy o Państwowym Ratownictwie Medycznym oraz standardów funkcjonowania dyspozytorni medycznych i Systemu Wspomagania Dowodzenia (SWD PRM).
• W2W3 Zrozumienie normy PN-EN ISO/IEC 27001:2022 (kontrole A.8.32 Zarządzanie zmianami, A.8.14 Redundancja, A.5.29 Gotowość w czasie zakłóceń) oraz par. 20 KRI.
• K1K2K3 Kształtowanie postawy najwyższej odpowiedzialności za życie ludzkie, obiektywizmu audytorskiego i rygoryzmu w badaniu procedur operacyjnych.
• Powiązanie z wykładem: Wyk1 (Audyt w systemach ratujących życie), Wyk3 (Kontrole A.8.32 i A.8.14 ISO 27001), Wyk4 (KRI i regulacje ratownictwa medycznego), Wyk6 (Analiza logów centrali telefonicznej VoIP i bazy SWD), Wyk7 (Klasyfikacja niezgodności krytycznych).

Wojewódzka Stacja Pogotowia Ratunkowego w Rzeszowie (WSPR) koordynuje medyczne czynności ratunkowe na obszarze zamieszkanym przez 1,3 miliona osób, dysponując 60 Zespołami Ratownictwa Medycznego (ZRM), w tym zespołami specjalistycznymi i podstawowymi, oraz współpracując ze śmigłowcami Lotniczego Pogotowia Ratunkowego (LPR). Dyspozytornia Medyczna obsługuje średnio 650 zgłoszeń ratunkowych na dobę.

Stan faktyczny w obszarze planowania prac serwisowych i zarządzania zmianami:

• Praca dyspozytorni opiera się na Systemie Wspomagania Dowodzenia Państwowego Ratownictwa Medycznego (SWD PRM), zintegrowanym z cyfrową centralą radiową, systemem lokalizacji GPS ambulansów oraz konsolami telefonicznymi VoIP przyjmującymi formatki zgłoszeniowe z Centrów Powiadamiania Ratunkowego (numer 112).
• Dział teleinformatyki zaplanował przeprowadzenie modernizacji sieci szkieletowej serwerowni dyspozytorni (wymiana oprogramowania na przełącznikach rdzeniowych Cisco oraz restart klastra bazodanowego).
• Prace zaplanowano na poniedziałek w godzinach 11:30 - 13:00, czyli w porze największego dobowego nasilenia wypadków komunikacyjnych i nagłych zachorowań w regionie. Kierownik sekcji IT argumentował ten wybór faktem, że "w ciągu dnia wszyscy inżynierowie są na miejscu w pracy, więc w razie problemów łatwiej będzie naprawić sprzęt niż w nocy".
• O planowanych pracach poinformowano personel dyspozytorni wyłącznie za pomocą wiadomości e-mail wysłanej na ogólną skrzynkę oddziału o godzinie 11:15 (na 15 minut przed rozpoczęciem procedury). Żaden z dyżurnych dyspozytorów, zajętych obsługą zgłoszeń zawałów i urazów, nie odczytał wiadomości.
• O godzinie 11:32 inżynierowie zrestartowali przełącznik rdzeniowy. Ze względu na błąd konfiguracji protokołu redundancji VRRP/STP doszło do pętli sieciowej i całkowitego zablokowania ruchu na 45 minut.
• Konsole dyspozytorskie straciły łączność: zrzucono 12 trwających połączeń alarmowych, przestała działać telemetria GPS (dyspozytorzy nie widzieli, gdzie znajdują się karetki), a formatki z numeru 112 przestały spływać.
• Personel nie wdrożył natychmiast procedury pracy awaryjnej (papierowe karty zleceń wyjazdu i łączność radiowa VHF), ponieważ nikt nie uprzedził ich o odcięciu systemów. W efekcie karetka do potrąconego pieszego na trasie S19 została zadysponowana z 35-minutowym opóźnieniem.

Wojewoda Podkarpacki powołuje pilną komisję audytową w celu wyjaśnienia rażących błędów w procedurach planowania prac technicznych i zarządzania zmianami w dyspozytorni.

Praca w zespole 2-3 osobowym polega na zbadaniu procedury wyznaczania okien serwisowych, weryfikacji kanałów powiadamiania i opracowaniu bezpiecznej polityki wdrożeń w środowisku ratunkowym 24/7/365:

• Krok 1 (Podział ról w grupie audytowej):

  Student 1 (Audytor Wiodący / Governance Ratownictwa Medycznego): Bada regulamin dyspozytorni medycznej, procedury współpracy z Urzędem Wojewódzkim i MSWiA, analizuje proces decyzyjny kierownika IT i koordynuje przygotowanie referatu.

  Student 2 (Audytor Techniczny ds. Sieci Teleinformatycznych i VoIP): Bada logi przełączników Cisco, błąd pętli sieciowej, konfigurację protokołów wysokiej dostępności (VRRP/HSRP), mechanizmy redundancji i brak architektury Zero Downtime.

  Student 3 (Audytor Zgodności z Normą ISO 27001 i Ustawą o PRM): Weryfikuje spełnienie wymagań Ustawy o Państwowym Ratownictwie Medycznym, kontroli A.8.32 i A.8.14 ISO/IEC 27001 oraz par. 20 KRI; sporządza karty niezgodności. W grupie 2-osobowej zadania te dzielą Studenci 1 i 2.

• Krok 2 (Triangulacja dowodów incydentu operacyjnego):

  Zestawcie czas wysłania wiadomości e-mail (11:15), moment zrestartowania przełączników (11:32), logi utraty połączeń VoIP w centrali telefonicznej oraz zapisy w kartach medycznych dotyczące opóźnionego wyjazdu zespołu ZRM.

• Krok 3 (Identyfikacja i klasyfikacja niezgodności):

  Zaklasyfikujcie wykryte uchybienia w procesie:

  • Niezgodność krytyczna (NC1): Zaplanowanie i przeprowadzenie prac modernizacyjnych infrastruktury sieciowej w godzinach szczytu operacyjnego bez uzgodnienia z dyspozytorami i bez weryfikacji gotowości procedur awaryjnych, co bezpośrednio zagroziło życiu pacjentów (rażące naruszenie kontroli ISO/IEC 27001:2022 A.8.32, Ustawy o PRM oraz par. 20 KRI).
  • Niezgodność większa (NC2): Wadliwy i nieskuteczny proces komunikacji o oknach serwisowych (jednokierunkowy e-mail na 15 minut przed pracami, brak wymogu pisemnego potwierdzenia gotowości przez Głównego Dyspozytora).
  • Niezgodność mniejsza (NC3): Niewłaściwa konfiguracja urządzeń sieciowych uniemożliwiająca bezprzerwowe przełączenie ruchu (brak rzeczywistej redundancji Active-Standby).
• Krok 4 (Projekt Polityki Okien Serwisowych i Bezprzerwowych Modernizacji):

  Zaprojektujcie:

  • Politykę Okien Serwisowych (Maintenance Window Policy) dla WSPR:
    • Bezwzględny zakaz prowadzenia prac planowych w godzinach 07:00 - 22:00.
    • Dopuszczalne okno serwisowe: wyłącznie wtorek lub środa w godzinach 02:00 - 04:30 (statystycznie najmniejsza liczba zgłoszeń wypadkowych).
    • Obowiązek zgłoszenia wniosku RFC z wyprzedzeniem minimum 7 dni kalendarzowych.
  • Procedurę Komunikacji Operacyjnej i Weryfikacji Gotowości (Go/No-Go):
    • Obowiązkowa odprawa techniczna z Głównym Dyspozytorem Medycznym na 24h przed pracami.
    • Wymóg przejścia dyspozytorni na procedurę awaryjną (test łączności radiowej VHF, przygotowanie papierowych formularzy) na 15 minut PRZED rozpoczęciem prac informatycznych.
    • Pisemna zgoda dyspozytora dyżurnego na rozpoczęcie prac wydawana bezpośrednio przed fizycznym restartem urządzeń.
  • Architekturę techniczną High Availability: wdrożenie procedury Rolling Update i redundantnych ścieżek sieciowych gwarantujących przełączenie ruchu poniżej 1 sekundy (Zero Downtime).

Struktura 10-minutowego wystąpienia referatowego:

• WSPR w Rzeszowie i opis krytycznego incydentu w dyspozytorni medycznej (2 min): Przedstawienie specyfiki pracy ratownictwa 24/7/365, skali zgłoszeń i skutków zrzucenia połączeń alarmowych (Student 1).
• Wyniki audytu technicznego: restart w szczycie i e-mail na 15 minut przed faktem (3 min): Omówienie absurdalnego harmonogramu prac, błędu pętli sieciowej i braku przygotowania personelu (Student 2).
• Prawne rygory dostępności systemów ratunkowych i odpowiedzialność karna (2 min): Analiza Ustawy o PRM, normy ISO 27001 oraz odpowiedzialności z art. 160 Kodeksu Karnego za narażenie na niebezpieczeństwo utraty życia (Student 3 lub Student 1).
• Wzorcowy model: Maintenance Window Policy i procedura bezprzerwowa (2 min): Prezentacja dopuszczalnych okien nocnych, procedury odpraw dyspozytorskich i fallbacku radiowego (Student 2).
• Podsumowanie, analiza wad i zalet (1 min): Dyskusja o konieczności podporządkowania wygody informatyków bezpieczeństwu ratowania życia (cały zespół).

Raport poaudytowy dla Dyrekcji WSPR i Wydziału Bezpieczeństwa UW (objętość 4-6 stron A4):

A. Odpowiedzi na pytania problemowe i opis sytuacyjny:

• W jaki sposób należy planować i wyznaczać okna serwisowe (Maintenance Windows) w organizacjach realizujących zadania krytyczne w trybie ciągłym (24/7/365), aby wyeliminować ryzyko zakłócenia ciągłości działania?
• Dlaczego jednostronne powiadamianie personelu operacyjnego pocztą elektroniczną o pracach technicznych jest rażącym błędem i w jaki sposób zorganizować dwustronną procedurę weryfikacji gotowości operacyjnej?
• Jakie środki techniczne (np. architektura redundantna, przełączanie bezprzerwowe, testy failover) muszą zostać wdrożone, aby modernizacja sieci nie powodowała przerw w łączności ratunkowej?

B. Wzorcowe rozwiązanie problemu (Dokumentacja operacyjno-ratownicza):

• Karta ustaleń audytowych z opisem niezgodności NC1, NC2 i NC3 oraz odniesieniem do Ustawy o PRM i ISO 27001 (A.8.14, A.8.32).
• Regulamin Okien Konserwacyjnych i Modernizacyjnych Systemów Teleinformatycznych WSPR:
  • Harmonogram dozwolonych okien (okno standardowe: środa 02:00-04:30; zakaz prac w weekendy, święta i dni wzmożonego ruchu).
  • Procedura Eskalacji i Uzgodnień: wymóg zatwierdzenia wniosku RFC przez Koordynatora Ratownictwa Medycznego i Kierownika Dyspozytorni.
• Standardowa Procedura Operacyjna (SOP): "Przejście na Tryb Awaryjny podczas Planowych Prac Konserwacyjnych":
  • Krok 1 (T-60 min): Odprawa dyspozytorska, weryfikacja naładowania radiotelefonów nasobnych.
  • Krok 2 (T-15 min): Przełączenie formatki zgłoszeniowej na papierowe karty zleceń, uruchomienie równoległego nasłuchu radiowego VHF.
  • Krok 3 (T-0): Wydanie zgody radiowej na start prac przez Głównego Dyspozytora.
  • Krok 4 (T+koniec): Weryfikacja działania każdego stanowiska przed odwołaniem trybu awaryjnego.

C. Analiza zalet i wad proponowanego rozwiązania:

• Zalety: Stuprocentowe bezpieczeństwo dysponowania zespołów ratownictwa; całkowite wyeliminowanie ryzyka zaskoczenia dyspozytorów przerwą techniczną; gwarancja ciągłości przyjmowania zgłoszeń z numeru 112; zgodność z wymogami Wojewody i KRI.
• Wady i ograniczenia: Konieczność wykonywania prac modernizacyjnych przez informatyków w godzinach nocnych (koszty dodatków za pracę w nocy); konieczność cyklicznych ćwiczeń z papierowego obiegu zleceń wyjazdów.

• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.8.32 (Zarządzanie zmianami), A.8.14 (Redundancja urządzeń przetwarzania informacji), A.5.29 (Gotowość w czasie zakłóceń).
• Ustawa z dnia 8 września 2006 r. o Państwowym Ratownictwie Medycznym (Dz.U. z 2023 r. poz. 1541 z późn. zm.).
• Rozporządzenie Ministra Zdrowia z dnia 27 czerwca 2019 r. w sprawie szpitalnego oddziału ratunkowego i dyspozytorni medycznych (Dz.U. z 2023 r. poz. 1231).
• Rozporządzenie Rady Ministrów z dnia 21 maja 2024 r. w sprawie Krajowych Ram Interoperacyjnych, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (...) (Dz.U. z 2024 r. poz. 773).
• Axelos: "ITIL 4: Service Configuration and Change Enablement", TSO 2020.

• U2 Identyfikacja rażących nieprawidłowości w planowaniu okien serwisowych i komunikacji operacyjnej w systemach ratunkowych.
• U1 Projekt procedury Maintenance Window Policy oraz procedury fallbacku operacyjnego dla dyspozytorni medycznej.
• U3 Szacowanie ryzyka utraty zdrowia i życia obywateli na skutek przerw w łączności ratunkowej.
• W1W2W3 Znajomość przepisów Ustawy o PRM, kontroli A.8.32 i A.8.14 ISO 27001 oraz zasad ITIL.
• K1K2K3 Poczucie misji publicznej, rzetelność audytorska i bezkompromisowość w ochronie życia ludzkiego.

W referacie dobitnie wskażcie, dlaczego w instytucjach ratujących życie planowanie prac informatycznych w godzinach południowych 'dla wygody informatyków' stanowi naruszenie podstawowych obowiązków pracowniczych i etycznych.

Głównym celem zadania jest opanowanie przez studentów zaawansowanych umiejętności audytu końcowego etapu cyklu życia zmiany - fazy zamykania zmiany (Change Closure), w tym weryfikacji rzetelności przeprowadzania Przeglądów Po-wdrożeniowych (Post-Implementation Review - PIR), badania jakości analizy przyczyn źródłowych (Root Cause Analysis - RCA) incydentów wywołanych zmianami oraz oceny mechanizmów ciągłego doskonalenia Systemu Zarządzania Bezpieczeństwem Informacji (ISMS) w strategicznej infrastrukturze transportu lotniczego. Zadanie koncentruje się na weryfikacji spełnienia wymagań normy PN-EN ISO/IEC 27001:2022 (klauzule 10.1 Ciągłe doskonalenie, 10.2 Niezgodności i działania korygujące, kontrola Załącznika A: A.8.32 Zarządzanie zmianami), rygorów Ustawy - Prawo lotnicze oraz wytycznych Urzędu Lotnictwa Cywilnego (ULC).

Powiązanie z sylabusem i treściami programowymi:

• U2 Identyfikacja luk proceduralnych i mentalnych w procesie zamykania zmian (zamiatanie problemów pod dywan, fikcyjne oznaczanie wniosków RFC jako udane, brak analizy 5 Why / Diagramu Ishikawy, powtórzenie tego samego incydentu po 3 tygodniach).
• U1 Opracowanie zaleceń i projektu procedury sformalizowanego Przeglądu Po-wdrożeniowego (PIR), standardu analizy Root Cause Analysis oraz zasilania Bazy Znanych Błędów (Known Error Database - KEDB).
• U3 Przeprowadzenie analizy ryzyka paraliżu odpraw granicznych i kontroli bezpieczeństwa, gigantycznych odszkodowań dla linii lotniczych za opóźnione rejsy oraz sankcji nakładanych przez ULC i EASA.
• U4 Opracowanie kompleksowego raportu z audytu ciągłego doskonalenia dla Zarządu Portu Lotniczego i wygłoszenie referatu akademickiego.
• W1 Znajomość przepisów prawa lotniczego w zakresie ciągłości i bezpieczeństwa operacji naziemnych oraz standardów ICAO i EASA.
• W2W3 Zrozumienie normy PN-EN ISO/IEC 27001:2022 (klauzula 10 oraz kontrola A.8.32), metodyki ITIL 4 (Problem Management & Change Closure) oraz wytycznych zarządzania incydentami technicznymi.
• K1K2K3 Kształtowanie kultury "No-Blame Culture" sprzyjającej otwartemu badaniu przyczyn awarii, profesjonalizmu analitycznego i odpowiedzialności za bezpieczeństwo transportu publicznego.
• Powiązanie z wykładem: Wyk1 (Rola audytu w ciągłym doskonaleniu organizacji), Wyk2 (Zasady audytowania ISO 19011), Wyk3 (Klauzula 10 i kontrola A.8.32 ISO 27001), Wyk5 (Risk-based approach do powtarzalnych incydentów), Wyk7 (Ocena działań korygujących i zamykanie niezgodności).

Port Lotniczy Wrocław S.A. jest jednym z największych międzynarodowych lotnisk regionalnych w Polsce, obsługującym rocznie ponad 4 miliony pasażerów, realizującym rejsy tradycyjne, niskokosztowe, czarterowe oraz operacje cargo. Lotnisko podlega rygorystycznemu nadzorowi Urzędu Lotnictwa Cywilnego (ULC) oraz europejskiej agencji EASA.

Stan faktyczny w obszarze procesu wdrażania i zamykania zmian:

• Kluczowym systemem obsługi pasażerów w terminalu jest System Kontroli Odpraw i Wyjść do Samolotów (Departure Control System - DCS) zintegrowany z automatycznymi bramkami kontroli kart pokładowych (e-Gate) oraz systemem odczytu paszportów biometrycznych na granicy Schengen.
• W ramach planowej modernizacji oprogramowania wdrożono nową wersję modułu sterownika bramek e-Gate. Wdrożenie odbyło się w oknie nocnym w czwartek. W niedzielę rano, w szczycie porannej fali wylotów czarterowych (godz. 05:00 - 08:30), doszło do zawieszenia procesu autoryzacji kodów kreskowych na wszystkich 12 bramkach automatycznych.
• Bramki zablokowały się w pozycji zamkniętej. Powstały gigantyczne zatory pasażerskie, opóźniono 16 rejsów międzynarodowych, a część pasażerów spóźniła się na loty. Personel lotniska doraźnie rozwiązał problem poprzez restart zasilania urządzeń i przejście na manualną kontrolę biletów przez pracowników straży ochrony lotniska.
• W poniedziałek rano kierownik projektu IT, nie chcąc raportować problemów przed Dyrektorem Operacyjnym, zmienił status wniosku RFC w systemie Jira na: "Zamknięto - wdrożono pomyślnie. Wystąpiły drobne opóźnienia sprzętowe, zrestartowano urządzenia".
• W organizacji NIE przeprowadzono spotkania Przeglądu Po-wdrożeniowego (PIR), nie sporządzono analizy przyczyn źródłowych (Root Cause Analysis - RCA), nie powiadomiono Komitetu CAB o wystąpieniu incydentu wywołanego zmianą (Change-induced incident) oraz nie wprowadzono żadnych poprawek do procedur testowych ani bazy znanych błędów.
• W rezultacie po dokładnie 3 tygodniach, podczas kolejnej rutynowej aktualizacji innego modułu, identyczny konflikt bibliotek dynamicznych (DLL Hell) spowodował ponowne zablokowanie bramek e-Gate w sobotnie południe, wywołując powtórny paraliż terminala, publikacje w ogólnopolskich mediach i zapowiedź nałożenia kary finansowej przez Prezesa ULC.

Zarząd Portu Lotniczego powołuje zespół audytorów z zadaniem zbadania przyczyn zaniechania procedur PIR i RCA oraz zaprojektowania szczelnego mechanizmu ciągłego doskonalenia w procesie zarządzania zmianami.

Praca w zespole 2-3 osobowym polega na zbadaniu procedury zamykania zmian, weryfikacji incydentów powdrożeniowych i opracowaniu procesu Post-Implementation Review:

• Krok 1 (Podział ról w grupie audytowej):

  Student 1 (Audytor Wiodący / Governance Transportu Lotniczego): Bada procedury operacyjne lotniska, Księgę Jakości i ISMS, dokumentację audytową ULC, analizuje proces zamykania zgłoszeń w Jira i koordynuje przygotowanie referatu.

  Student 2 (Audytor Techniczny ds. Systemów Terminalowych i RCA): Bada logi bramek e-Gate, konflikt bibliotek dynamicznych, logi restartów systemu DCS, analizuje przyczyny techniczne incydentu oraz przeprowadza warsztat 5 Why / Diagram Ishikawy.

  Student 3 (Audytor Zgodności z Normą ISO 27001 i Prawem Lotniczym): Analizuje naruszenie klauzuli 10.1 i 10.2 oraz kontroli A.8.32 normy ISO/IEC 27001:2022, bada rygory raportowania incydentów do ULC; sporządza karty niezgodności. W grupie 2-osobowej zadania te dzielą Studenci 1 i 2.

• Krok 2 (Triangulacja dowodów i analiza powtarzalności incydentu):

  Zestawcie treść ticketa w Jira (status "wdrożono pomyślnie"), meldunki dyżurnego operacyjnego portu o opóźnieniach 16 samolotów oraz logi błędów bramek z obu niedziel (wykażcie identyczną przyczynę źródłową w postaci błędu biblioteki DLL).

• Krok 3 (Identyfikacja i klasyfikacja niezgodności):

  Zaklasyfikujcie wykryte luki w procesie:

  • Niezgodność krytyczna (NC1): Brak przeprowadzenia przeglądu po-wdrożeniowego (PIR) oraz brak analizy przyczyn źródłowych (RCA) po incydencie paraliżu bramek e-Gate, co doprowadziło do zignorowania wady systemowej i wywołało powtórną awarię lotniska (rażące naruszenie klauzul 10.1 i 10.2 oraz kontroli A.8.32 ISO/IEC 27001:2022).
  • Niezgodność większa (NC2): Fałszowanie statusu realizacji zmiany w systemie ITSM poprzez oznaczanie wdrożenia jako udanego pomimo wywołania incydentu o najwyższym priorytecie P1 (brak rzetelności audytowej i zarządczej).
  • Niezgodność mniejsza (NC3): Brak zasilania Bazy Znanych Błędów (Known Error Database) wiedzą poawaryjną i brak aktualizacji zestawu testów regresyjnych dla kolejnych wydań oprogramowania.
• Krok 4 (Projekt procedury PIR, standardu RCA i kultury No-Blame):

  Zaprojektujcie:

  • Sformalizowaną Procedurę Przeglądu Po-wdrożeniowego (Post-Implementation Review - PIR):
    • Obowiązkowe posiedzenie PIR dla każdej zmiany, która wywołała incydent o priorytecie P1 lub P2, przekroczyła okno serwisowe o ponad 30 minut lub wymagała procedury rollback.
    • Termin posiedzenia: maksymalnie 5 dni roboczych od wdrożenia, z udziałem przedstawiciela CAB, kierownika wdrożenia, testera oraz użytkownika biznesowego (Służba Ochrony Lotniska).
  • Standard Analizy Przyczyn Źródłowych (RCA):
    • Obowiązek zastosowania metody "5 Why" (5 razy dlaczego) oraz Diagramu Ishikawy (kategorie: Ludzie, Metody, Narzędzia, Środowisko, Zarządzanie).
    • Obowiązek zdefiniowania co najmniej jednego trwałego działania korygującego (Corrective Action) uniemożliwiającego powtórzenie błędu.
  • Zasady Kultury Bez Obwiniania (No-Blame Culture): promowanie zgłaszania problemów wdrożeniowych bez obawy o represje dyscyplinarne, skupienie na wadach procesu i narzędzi, a nie na szukaniu kozła ofiarnego.

Struktura wystąpienia seminaryjnego (10 minut):

• Port Lotniczy Wrocław i charakterystyka awarii bramek e-Gate (2 min): Przedstawienie skali ruchu pasażerskiego, roli bramek automatycznych i skutków paraliżu odpraw dla linii lotniczych (Student 1).
• Wyniki audytu: fałszywy sukces w Jira, brak analizy przyczyn i powtórka awarii po 3 tygodniach (3 min): Omówienie ukrywania prawdy przez kierownika projektu i technicznego mechanizmu błędu DLL (Student 2).
• Klauzula 10 normy ISO 27001 - ciągłe doskonalenie i działania korygujące w praktyce (2 min): Wyjaśnienie, dlaczego brak analizy RCA przekreśla dojrzałość systemu ISMS i sprowadza ryzyko sankcji ULC (Student 3 lub Student 1).
• Wzorcowy proces PIR, metoda 5 Why i baza KEDB (2 min): Prezentacja formularza PIR, diagramu Ishikawy i zasad kultury No-Blame (Student 2).
• Podsumowanie, analiza wad i zalet (1 min): Dyskusja o tym, że największym błędem nie jest popełnienie pomyłki przy wdrożeniu, lecz zaniechanie wyciągnięcia z niej wniosków (cały zespół).

Raport poaudytowy dla Zarządu Portu Lotniczego Wrocław S.A. (objętość 4-6 stron A4):

A. Odpowiedzi na pytania problemowe i opis sytuacyjny:

• Czym jest Przegląd Po-wdrożeniowy (Post-Implementation Review - PIR) i dlaczego zamknięcie wniosku o zmianę bez formalnego PIR stanowi złamanie kluczowych wymagań normy ISO/IEC 27001 (klauzula 10)?
• W jaki sposób wykorzystać metodykę Root Cause Analysis (RCA), w tym technikę 5 Why i diagram rybiej ości (Ishikawy), aby zidentyfikować faktyczną przyczynę źródłową incydentu wdrożeniowego?
• Na czym polega budowa kultury "No-Blame Culture" w organizacji i dlaczego ukrywanie niepowodzeń wdrożeniowych przed kierownictwem prowadzi nieuchronnie do powtórzenia katastrofy operacyjnej?

B. Wzorcowe rozwiązanie problemu (Dokumentacja ciągłego doskonalenia ISMS):

• Karta ustaleń audytowych z opisem niezgodności NC1, NC2 i NC3 oraz odniesieniem do ISO/IEC 27001 (klauzule 10.1, 10.2, kontrola A.8.32).
• Raport z Analizy Przyczyn Źródłowych (RCA Report) incydentu bramek e-Gate:
  • Zastosowanie drzewa 5 Why: 1. Dlaczego bramki się zawiesiły? (Konflikt biblioteki DLL). 2. Dlaczego wystąpił konflikt? (Nowy sterownik nadpisał współdzieloną bibliotekę). 3. Dlaczego nie wykryto tego w testach? (Testowano tylko 1 bramkę, a nie klaster). 4. Dlaczego testowano wybiórczo? (Brak czasu z powodu opóźnienia dostawcy). 5. Dlaczego wdrożono bez kompletu testów? (Presja na status wdrożenia i brak twardej bramki jakościowej w CAB).
• Procedura Przeglądu Po-wdrożeniowego (PIR Standard Operating Procedure):
  • Formularz Raportu PIR (weryfikacja metryk: faktyczny vs planowany czas przestoju, liczba incydentów po wdrożeniu, satysfakcja użytkowników).
  • Rejestr Działań Korygujących (CAPA) i aktualizacja Bazy Znanych Błędów (KEDB).

C. Analiza zalet i wad proponowanego rozwiązania:

• Zalety: Skuteczne zabezpieczenie lotniska przed powtarzaniem tych samych awarii technicznych; budowa dojrzałego, uczącego się środowiska IT; pełna zgodność z normą ISO 27001 i wymogami ULC/EASA; ochrona reputacji portu i uniknięcie kar odszkodowawczych.
• Wady i ograniczenia: Konieczność poświęcenia dodatkowego czasu zespołów technicznych i biznesowych na warsztaty PIR/RCA po każdym większym wdrożeniu; opór pracowników przed otwartym przyznawaniem się do błędów wymagający zmiany kultury organizacyjnej.

• Norma PN-EN ISO/IEC 27001:2022: Rozdział 10 (Doskonalenie: 10.1 Ciągłe doskonalenie, 10.2 Niezgodności i działania korygujące), Załącznik A - kontrola A.8.32 (Zarządzanie zmianami).
• Norma PN-EN ISO 9001:2015: Systemy zarządzania jakością - Wymagania (punkt 10 Doskonalenie).
• Ustawa z dnia 3 lipca 2002 r. - Prawo lotnicze (Dz.U. z 2023 r. poz. 2110 z późn. zm.).
• Urząd Lotnictwa Cywilnego (ULC): "Wytyczne w zakresie zarządzania bezpieczeństwem w portach lotniczych (SMS)", Warszawa 2021.
• Axelos: "ITIL 4: Problem Management Practice Guide", PeopleCert 2020 (Techniki Root Cause Analysis i PIR).
• Sidney Dekker: "The Field Guide to Understanding 'Human Error'", Ashgate Publishing, 2014 (Zasady No-Blame Culture).

• U2 Identyfikacja luk w procesie zamykania zmian, braku analizy PIR oraz tuszowania niepowodzeń wdrożeniowych.
• U1 Projekt procedury Post-Implementation Review (PIR), metodyki Root Cause Analysis (5 Why) oraz polityki No-Blame.
• U3 Szacowanie ryzyka operacyjnego, finansowego i reputacyjnego w infrastrukturze transportu lotniczego.
• W1W2W3 Znajomość klauzuli 10 i kontroli A.8.32 ISO 27001, prawa lotniczego oraz metodyk ITIL Problem Management.
• K1K2K3 Kształtowanie dojrzałej kultury organizacyjnej, odwaga w ujawnianiu błędów i etyka zawodowa audytora.

Zakończcie referat mocną puentą: sukcesu wdrożenia nie mierzy się tym, czy wdrożono kod w piątek o północy, ale tym, czy w poniedziałek rano pasażerowie odlecieli bez przeszkód do swoich domów.