20 maja 2026 r., Wojewódzki Sąd Administracyjny w Warszawie, sygnatura II SA/Wa 458/26. Sąd oddala skargi spółek Fortum Marketing and Sales oraz Pika na decyzję Prezesa Urzędu Ochrony Danych Osobowych i tym samym utrzymuje w mocy kary, które zdążyły już obrosnąć legendą polskiego rynku ochrony danych: 4 911 732 zł dla administratora i 250 135 zł dla podmiotu przetwarzającego. Od zgłoszenia naruszenia do tego rozstrzygnięcia minęło ponad sześć lat. Po drodze była pierwsza w historii UODO kara nałożona w jednym postępowaniu jednocześnie na administratora i procesora, był wyrok WSA uchylający decyzję organu, była skuteczna skarga kasacyjna Prezesa UODO i wyrok Naczelnego Sądu Administracyjnego z początku marca 2026 r., który zawrócił sprawę do ponownego rozpoznania. A na samym początku tej historii była rzecz boleśnie banalna: dodatkowa baza danych, utworzona „na chwilę" podczas prac modernizacyjnych, wypełniona prawdziwymi danymi klientów i wystawiona do internetu bez zabezpieczeń.

Jeżeli Państwa organizacja kiedykolwiek zlecała firmie zewnętrznej modernizację systemu, migrację danych albo „drobną poprawkę wydajności" — ta sprawa jest o Państwu. Nie o energetyce, nie o wielkich korporacjach. O każdym podmiocie, który ma dane osobowe w systemie IT i wykonawcę, któremu ufa na słowo.

Sześć lat sporu: kalendarium sprawy Fortum i Pika

Wszystko zaczęło się w kwietniu 2020 r., gdy Fortum Marketing and Sales — sprzedażowa spółka koncernu energetycznego — zgłosiło Prezesowi UODO naruszenie ochrony danych osobowych. Zgłoszenie dotyczyło zmian wprowadzanych w środowisku teleinformatycznym pełniącym funkcję cyfrowego archiwum dokumentów klientów. Prace prowadziła Pika Sp. z o.o. — podmiot przetwarzający, któremu Fortum powierzyło obsługę archiwum. Sygnalizowane przez administratora problemy z wydajnością systemu skłoniły wykonawcę do utworzenia dodatkowej bazy danych, do której przeniesiono rzeczywiste dane klientów. Ta nowo utworzona baza nie została właściwie zabezpieczona — i to do tego stopnia, że osoby nieuprawnione uzyskały do niej dostęp i skopiowały jej zawartość.

W styczniu 2022 r. Prezes UODO wydał decyzję (DKN.5130.2215.2020), w której po raz pierwszy w jednym postępowaniu ukarał obie strony relacji powierzenia: administratora na blisko 5 mln zł, procesora na ponad ćwierć miliona. Spółki zaskarżyły decyzję i w pierwszym podejściu wygrały — WSA uchylił rozstrzygnięcie organu. Prezes UODO złożył jednak skargę kasacyjną, a NSA na początku marca 2026 r. przyznał mu rację, uchylił korzystny dla spółek wyrok i przekazał sprawę do ponownego rozpoznania. 20 maja 2026 r. WSA, związany oceną prawną NSA, oddalił skargi obu spółek. Kary stoją. Sześcioletnia batalia sądowa zakończyła się pełnym zwycięstwem organu nadzorczego — i to jest pierwsza lekcja tej sprawy: kalkulacja „zaskarżymy i zobaczymy" przestała być strategią. Orzecznictwo NSA konsekwentnie umacnia pozycję UODO, a czas gry na zwłokę nie unieważnia kary, tylko odsuwa ją w czasie razem z odsetkami reputacyjnymi.

Co się właściwie stało w cyfrowym archiwum

Warto zrekonstruować przebieg zdarzeń, bo jego zwyczajność jest najbardziej pouczająca. Fortum korzystało z systemu cyfrowego archiwum, w którym przechowywano dokumenty klientów — umowy, korespondencję, dane identyfikacyjne. System działał wolniej, niż oczekiwał tego administrator, więc zlecono wykonawcy prace optymalizacyjne. Pika, chcąc poprawić wydajność, utworzyła dodatkową bazę danych i zasiliła ją produkcyjnymi danymi klientów Fortum: imionami i nazwiskami, adresami zamieszkania, numerami PESEL, danymi dokumentów tożsamości, danymi kontaktowymi oraz informacjami o zawartych umowach. Według ustaleń organu naruszenie objęło około 95 tysięcy osób.

Nowa baza została skonfigurowana z pominięciem elementarnych zabezpieczeń — w postępowaniu wykazano między innymi brak aktywnej zapory sieciowej. Skutek był łatwy do przewidzenia: zasób stał się osiągalny z zewnątrz, a osoby trzecie nie tylko mogły przeglądać dane, ale je skopiowały. Co istotne, Fortum dowiedziało się o problemie nie od swojego wykonawcy w ramach uporządkowanego procesu zarządzania zmianą, lecz post factum — gdy naruszenie już trwało. Administrator początkowo ocenił ryzyko naruszenia praw i wolności osób fizycznych jako niskie i nie zamierzał zawiadamiać klientów. Dopiero interwencja organu nadzorczego wymusiła komunikację z osobami, których dane wyciekły. Każdy z tych elementów — samowolna kopia bazy, brak zabezpieczeń, brak nadzoru, zaniżona ocena ryzyka — wróci później w uzasadnieniu kary jako odrębne naruszenie.

Grzech główny: produkcyjne dane w środowisku testowym

Sednem tej sprawy nie jest wyciek jako taki, lecz praktyka, która do niego doprowadziła: wykorzystanie rzeczywistych danych osobowych w środowisku testowym bez ich pseudonimizacji i bez objęcia tego środowiska takimi samymi zabezpieczeniami jak produkcja. To praktyka powszechna do bólu. Zespoły IT kopiują produkcyjne bazy „do testów", bo tak jest szybciej, bo dane syntetyczne trzeba by wygenerować, bo anonimizacja psuje scenariusze testowe, bo przecież to tylko na moment. Środowisko testowe z definicji traktuje się mniej poważnie: bez firewalla, bez szyfrowania, bez monitoringu dostępu, czasem na serwerze, o którym dział bezpieczeństwa w ogóle nie wie. Audytując systemy naszych klientów, regularnie znajdujemy kopie produkcyjnych baz sprzed dwóch, trzech lat — zapomniane po dawno zakończonych wdrożeniach, nieaktualizowane, dostępne dla osób, które dawno zmieniły stanowiska. Każda z nich to gotowy materiał na decyzję administracyjną.

Prezes UODO — a za nim sądy — postawił sprawę jednoznacznie: z punktu widzenia RODO nie istnieje coś takiego jak „mniej ważna" baza danych osobowych. Artykuł 32 RODO wymaga środków technicznych i organizacyjnych adekwatnych do ryzyka, a ryzyko idzie za danymi, nie za etykietą środowiska. Jeżeli w bazie testowej, deweloperskiej czy migracyjnej znajdują się prawdziwe numery PESEL, to ta baza wymaga dokładnie takiej samej ochrony jak system produkcyjny. W decyzji organ wprost odwołał się do norm ISO/IEC 27001 i ISO/IEC 27002, które nakazują stosowanie w środowiskach testowych środków ochrony równoważnych produkcyjnym, o ile przetwarza się w nich dane rzeczywiste. Współczesna redakcja normy mówi o tym wprost w zabezpieczeniach dotyczących rozdzielenia środowisk rozwojowych, testowych i produkcyjnych oraz ochrony informacji wykorzystywanych do testów. Innymi słowy: organ nadzorczy mierzy staranność przedsiębiorcy uznanymi standardami branżowymi, niezależnie od tego, czy przedsiębiorca formalnie się na nie certyfikował.

Za co dokładnie zapłacił administrator

Kara dla Fortum nie wzięła się z samego faktu, że wykonawca popełnił błąd. Administrator zapłacił za własne zaniechania nadzorcze, które organ wyliczył punkt po punkcie. Po pierwsze — Fortum nie zweryfikowało, czy Pika daje wystarczające gwarancje wdrożenia odpowiednich środków technicznych i organizacyjnych, zanim powierzyło jej dane. Artykuł 28 ust. 1 RODO formułuje ten obowiązek jednoznacznie: administrator korzysta wyłącznie z usług takich podmiotów przetwarzających, które takie gwarancje zapewniają. Weryfikacja nie może być rytualnym podpisaniem umowy powierzenia — musi być realnym sprawdzeniem kompetencji, procedur i zabezpieczeń wykonawcy.

Po drugie — administrator miał w umowie prawo do audytu i kontroli wykonawcy, z którego nigdy nie skorzystał. Organ potraktował to nie jako neutralny wybór biznesowy, lecz jako rezygnację z podstawowego narzędzia nadzoru. Po trzecie — Fortum nie sprawowało żadnej rzeczywistej kontroli nad tym, jak wykonawca wprowadza zmiany w środowisku przetwarzającym dane jego klientów. Modernizacja archiwum odbywała się bez akceptowanego przez administratora planu zmiany, bez wymogu testów bezpieczeństwa przed udostępnieniem nowej bazy, bez powiadomienia o utworzeniu kopii danych. To trzeci, najbardziej praktyczny wymiar tej decyzji: outsourcing przetwarzania nie jest outsourcingiem odpowiedzialności. Administrator może zlecić operacje na danych, ale nadzór nad nimi pozostaje jego niezbywalnym obowiązkiem — dokładnie tak samo, jak opisywaliśmy to przy okazji kary dla DPD Polska i łańcucha podwykonawców przetwarzania.

Za co zapłacił procesor — i dlaczego to ważne dla branży IT

Druga połowa tej decyzji powinna odebrać sen każdej firmie informatycznej, która świadczy usługi obejmujące dane osobowe klientów. Pika została ukarana samodzielnie, za własne naruszenia art. 32 RODO — nie jako współwinna zaniedbań administratora, lecz jako podmiot, który nie dochował własnych, bezpośrednio na nim ciążących obowiązków. Organ zarzucił procesorowi wykorzystywanie rzeczywistych danych w procesach testowych bez pseudonimizacji, brak przetestowania zabezpieczeń nowo utworzonej bazy przed jej uruchomieniem oraz błędy konfiguracyjne infrastruktury, z brakiem aktywnej zapory sieciowej na czele.

Dla rynku usług IT płynie z tego wniosek, który wciąż nie wszędzie dotarł: podpisując umowę powierzenia, wykonawca przyjmuje na siebie odpowiedzialność administracyjnoprawną wprost przed organem nadzorczym, niezależną od odpowiedzialności kontraktowej wobec klienta. Kwota 250 135 zł może nie robi wrażenia na tle prawie 5 mln zł dla Fortum, ale trzeba ją czytać w proporcji do skali działalności — a do tego dodać koszty postępowania, obsługi prawnej sześcioletniego sporu i utraty zaufania rynku. Spółka, o czym warto pamiętać, znajduje się dziś w restrukturyzacji. Dla małego i średniego software house'u, integratora czy dostawcy systemów billingowych analogiczna kara może być pytaniem o byt firmy. Jeżeli Państwa firma wdraża, utrzymuje lub modernizuje systemy klientów — środowiska testowe, procedury migracji i dyscyplina konfiguracyjna przestały być tematem inżynierskim, a stały się tematem zarządczym.

Ryzyko wystarczy: co NSA powiedział o istocie naruszenia

W warstwie czysto prawnej najdonioślejszy element tej sagi pochodzi z wyroku NSA, którym sąd kasacyjny związał WSA przy ponownym rozpoznaniu. NSA uznał, że dla stwierdzenia naruszenia ochrony danych wystarczające jest samo wystąpienie ryzyka utraty poufności — nie trzeba dowodzić, jak długo dane były wystawione na dostęp osób nieuprawnionych ani czy ktokolwiek faktycznie zdążył je wykorzystać na szkodę osób, których dotyczą. Ekspozycja danych na czynniki zewnętrzne sama w sobie przesądza o naruszeniu.

To rozstrzygnięcie zamyka furtkę, z której chętnie korzystali pełnomocnicy ukaranych podmiotów: skoro nie wykazano realnej szkody, nie ma podstaw do kary albo powinna być symboliczna. Po wyroku NSA ta linia obrony traci grunt. Praktyczna konsekwencja dla każdej organizacji jest natychmiastowa — przy ocenie wagi incydentu i obowiązków notyfikacyjnych z art. 33 i 34 RODO nie wolno czekać na dowód, że „coś się stało z danymi". Liczy się sama możliwość nieuprawnionego dostępu. Fortum zaniżyło ocenę ryzyka i zostało to wytknięte jako odrębne uchybienie; organizacje, które dziś kalkulują, czy „mały" incydent na pewno trzeba zgłaszać, powinny tę lekcję przeczytać dwa razy.

Anatomia kary: dlaczego akurat 4,9 mln zł i 250 tys. zł

Wysokość obu kar nie jest przypadkowa i warto rozumieć mechanikę, która za nią stoi, bo to ta sama mechanika zadziała w każdej przyszłej sprawie. Artykuł 83 RODO każe organowi ważyć między innymi charakter, wagę i czas trwania naruszenia, liczbę poszkodowanych, kategorie danych, stopień odpowiedzialności podmiotu oraz to, jak zachował się po incydencie. W sprawie Fortum niemal każdy z tych czynników działał obciążająco. Zakres danych obejmował numery PESEL i dane dokumentów tożsamości — czyli komplet wystarczający do zaciągnięcia zobowiązania na cudze nazwisko, co automatycznie windowało ocenę ryzyka dla osób poszkodowanych. Skala — około 95 tysięcy osób — przesądzała o powadze. Do tego doszła pierwotna, zaniżona ocena ryzyka i zaniechanie zawiadomienia klientów, które organ odczytał jako działanie na ich niekorzyść w momencie, gdy liczyła się każda doba na zastrzeżenie dokumentów.

Górny pułap kary z art. 83 ust. 5 RODO to 20 mln euro lub 4% całkowitego rocznego światowego obrotu — w przypadku spółki z grupy energetycznej kwota 4,9 mln zł mieściła się więc z zapasem w widełkach, a mimo to była wówczas rekordem polskiego organu. Kara dla Piki, choć nominalnie dwudziestokrotnie niższa, została wymierzona proporcjonalnie do skali działalności procesora — i właśnie ta proporcjonalność powinna dawać do myślenia mniejszym podmiotom. UODO nie karze „po równo", karze „po skali". Dla software house'u z kilkumilionowym przychodem ćwierć miliona złotych kary plus koszty sześcioletniego sporu sądowego to nie pozycja w budżecie, tylko scenariusz zagrożenia kontynuacji działalności. Restrukturyzacja, w której znajduje się dziś Pika, jest tu wymowną ilustracją.

Samorząd i spółki komunalne: ten sam scenariusz czeka u Państwa

Łatwo zbyć tę sprawę wzruszeniem ramion — wielka energetyka, korporacyjne budżety, nie nasz świat. To błąd perspektywy. Scenariusz „wykonawca modernizuje system i tworzy niezabezpieczoną kopię bazy" jest sektorowo uniwersalny, a jego najbardziej naturalnym środowiskiem jest dziś samorząd terytorialny i spółki komunalne. Urzędy migrują systemy EZD i dziedzinowe — ewidencję ludności, podatki lokalne, świadczenia. Wodociągi i ciepłownie wymieniają systemy billingowe, w których siedzą dane dziesiątek tysięcy odbiorców z numerami PESEL i historią płatności. Zakłady gospodarki odpadami wdrażają nowe moduły rozliczeń. Niemal zawsze robi to zewnętrzny wykonawca, niemal zawsze pod presją terminu, a „kopia bazy do testów" jest standardowym elementem każdego wdrożenia.

Różnica polega na tym, że samorząd i jego spółki mają dziś nad sobą dwa reżimy naraz. Po stronie ochrony danych — UODO, którego plan kontroli sektorowych na 2026 r. obejmuje między innymi monitoring wizyjny w podmiotach leczniczych i przetwarzanie danych w wielkoskalowych systemach UE, ale którego decyzje (jak ta w sprawie BIP-u gminy Myślenice) pokazują rosnącą stanowczość wobec sektora publicznego. Po stronie cyberbezpieczeństwa — znowelizowana ustawa o krajowym systemie cyberbezpieczeństwa, która od 7 maja 2026 r. otworzyła okno samoidentyfikacji podmiotów kluczowych i ważnych, obejmując nim także operatorów usług komunalnych. Incydent w rodzaju tego z archiwum Fortum oznaczałby dziś dla spółki wod-kan równoległe postępowanie przed Prezesem UODO i obowiązki zgłoszeniowe wobec właściwego CSIRT — z karami liczonymi w obu reżimach. A statystyki CERT Polska nie zostawiają złudzeń co do skali zagrożenia: 179 obsłużonych ataków ransomware w 2025 r., z czego 30 wymierzonych w instytucje publiczne.

Jest i dodatkowa okoliczność, o której sektor publiczny rzadko myśli w kategoriach ryzyka: asymetria kompetencji w relacji z wykonawcą. Duży operator energetyczny ma działy prawne i bezpieczeństwa zdolne wyegzekwować od dostawcy standardy — i mimo to poległ. Gmina albo spółka komunalna negocjująca z ogólnopolskim dostawcą systemu dziedzinowego najczęściej podpisuje wzorzec umowy przygotowany przez tego dostawcę, bez realnej możliwości negocjacji klauzul o środowiskach testowych czy prawie audytu. Tym większego znaczenia nabiera etap wyboru wykonawcy i opis wymagań bezpieczeństwa już w postępowaniu zakupowym — bo po podpisaniu umowy pole manewru gwałtownie się kurczy, a odpowiedzialność administratora danych pozostaje niezmiennie po stronie zamawiającego.

Jak ułożyć zmiany w IT, żeby nie skończyć przed WSA

Dobra wiadomość jest taka, że recepta na uniknięcie losu Fortum i Piki nie wymaga budżetów korporacji energetycznej. Wymaga dyscypliny w czterech obszarach, które każda organizacja — od gminy po software house — może uporządkować w kwartał.

Pierwszy obszar to weryfikacja wykonawcy przed powierzeniem. Zanim podpiszą Państwo umowę powierzenia, wykonawca powinien odpowiedzieć na konkretne pytania: jakie stosuje zabezpieczenia, jak zarządza środowiskami testowymi, czy jego personel jest upoważniony i przeszkolony, czy ma wdrożony system zarządzania bezpieczeństwem informacji — własny certyfikat ISO 27001 nie jest obowiązkiem, ale jest najprostszym dowodem gwarancji, o których mówi art. 28 RODO. Odpowiedzi należy udokumentować; w razie kontroli to one będą świadczyć o Państwa staranności.

Drugi obszar to umowa, która przewiduje zmiany w systemach. Standardowa umowa powierzenia milczy o tym, co wolno wykonawcy w trakcie modernizacji. Powinna mówić wprost: każda zmiana w środowisku przetwarzania wymaga zgłoszenia i akceptacji administratora, kopiowanie danych produkcyjnych do innych środowisk wymaga pseudonimizacji albo równoważnych zabezpieczeń, a prawo audytu nie jest ornamentem — administrator zobowiązuje się z niego korzystać według ustalonego harmonogramu, choćby w formie corocznej ankiety weryfikacyjnej i audytu na miejscu przy istotnych zmianach.

Trzeci obszar to zarządzanie zmianą po stronie technicznej. Norma ISO/IEC 27001:2022 daje gotową ramę: rozdzielenie środowisk rozwojowych, testowych i produkcyjnych, ochrona danych testowych, testy bezpieczeństwa przed wdrożeniem, przegląd konfiguracji po zmianie. Jeżeli w środowisku nieprodukcyjnym muszą znaleźć się dane rzeczywiste — co powinno być wyjątkiem uzasadnionym i udokumentowanym, nie regułą wygody — środowisko to obejmuje się pełnym zestawem zabezpieczeń produkcyjnych, z kontrolą dostępu, zaporą i monitoringiem włącznie.

Czwarty obszar to gotowość na incydent. Sprawa Fortum pokazuje, że zaniżenie oceny ryzyka naruszenia bywa karane równie surowo jak samo naruszenie. Procedura reagowania musi przewidywać rzetelną, udokumentowaną ocenę ryzyka dla osób, których dane dotyczą, decyzję o zgłoszeniu do UODO w 72 godziny i — gdy ryzyko jest wysokie — zawiadomienie samych zainteresowanych bez oglądania się na koszty wizerunkowe. Po wyroku NSA z marca 2026 r. próg uznania zdarzenia za naruszenie jest niski: wystarczy ekspozycja danych.

Jest jeszcze obszar piąty, spinający pozostałe: ludzie i ich nawyki. Baza bez zapory sieciowej nie powstała dlatego, że komuś brakowało wiedzy o firewallach — powstała dlatego, że w organizacji wykonawcy nikt nie zatrzymał decyzji „zrobimy szybciej, zabezpieczymy potem". Procedury zarządzania zmianą są skuteczne dokładnie w takim stopniu, w jakim zespoły techniczne rozumieją, po co istnieją. Dlatego program szkoleń dla administratorów systemów i deweloperów powinien obejmować nie tylko klasyczny moduł RODO dla pracowników biurowych, lecz także warsztat z bezpiecznej pracy na danych produkcyjnych: kiedy wolno je kopiować, jak je pseudonimizować, kto akceptuje wyjątki i jak wygląda ścieżka eskalacji, gdy termin wdrożenia zderza się z wymaganiami bezpieczeństwa. W sporze przed organem nadzorczym udokumentowane szkolenie zespołu technicznego jest zresztą jednym z najtańszych dowodów staranności, jakie organizacja może przedstawić.

Dlaczego z Fib.Code przy nadzorze nad wykonawcami i zmianami w IT

W Fib.Code od lat audytujemy relacje powierzenia dokładnie w tych punktach, w których wyłożyły się Fortum i Pika: weryfikacja gwarancji wykonawców, realne wykonywanie prawa audytu, bezpieczeństwo środowisk testowych i procesy zarządzania zmianą. Łączymy kompetencje prawne (RODO, UKSC, orzecznictwo NSA i WSA) z inżynierskimi (ISO/IEC 27001 i 27002, architektura systemów, konfiguracja zabezpieczeń), więc nie poprzestajemy na analizie umów — sprawdzamy, jak wdrożenia wyglądają naprawdę, od zapisów kontraktowych po reguły na zaporze sieciowej.

Pracujemy według trzech zasad. Po pierwsze: konkret zamiast checklisty — każde ustalenie audytowe ma wskazany przepis lub zabezpieczenie normy, opis ryzyka i wykonalną rekomendację z priorytetem. Po drugie: proporcjonalność — inne środki zaleca się spółce wod-kan z pięcioosobowym działem IT, inne operatorowi przetwarzającemu dane milionów klientów; wymagania RODO są wspólne, droga do ich spełnienia nie. Po trzecie: odpowiedzialność za wdrożenie — nie zostawiamy klienta z raportem, tylko prowadzimy go przez negocjacje aneksów do umów powierzenia, budowę procedur zarządzania zmianą i pierwsze audyty wykonawców.

Produktem końcowym jest udokumentowany, odporny na kontrolę UODO system nadzoru nad powierzeniem: zweryfikowani wykonawcy, umowy z klauzulami o zmianach i środowiskach testowych, harmonogram audytów, procedura oceny ryzyka naruszeń. Czyli dokładnie ten zestaw dowodów staranności, którego zabrakło w aktach sprawy II SA/Wa 458/26.

Co zrobić w ten weekend ze swoimi umowami powierzenia

Zanim w poniedziałek zacznie się operacyjny młyn, warto poświęcić godzinę na trzy pytania. Pytanie pierwsze: czy wiedzą Państwo, ilu wykonawców ma dziś dostęp do Państwa systemów z danymi osobowymi i kiedy ostatnio którykolwiek z nich został zaudytowany — nie „podpisał umowę", lecz został faktycznie sprawdzony? Pytanie drugie: czy gdyby któryś z nich jutro skopiował produkcyjną bazę „do testów", dowiedzieliby się Państwo o tym z procedury zarządzania zmianą, czy z mediów? Pytanie trzecie: czy Państwa ocena ryzyka naruszenia wytrzymałaby standard, który NSA ustawił w marcu 2026 r. — że sama ekspozycja danych przesądza o naruszeniu?

Jeżeli choć jedna odpowiedź budzi niepokój, w poniedziałek warto zwołać krótkie spotkanie z IOD, szefem IT i osobą odpowiedzialną za umowy — z jednym punktem agendy: inwentaryzacja relacji powierzenia i plan ich uszczelnienia do końca trzeciego kwartału. Sprawa Fortum i Piki dojrzewała sześć lat; Państwa organizacja może zamknąć temat w trzy miesiące.

Zapraszamy do kontaktu: l.grabowski@fibcode.com | fibcode.com/pl/kontakt. Bezpośrednio powiązane materiały: kara UODO dla DPD i łańcuch podwykonawców przetwarzania, kara UODO za BIP gminy Myślenice i kontrole sektorowe w samorządzie, samoidentyfikacja NIS-2 i wpis do wykazu cyberbezpieczeństwa — razem składają się na mapę odpowiedzialności, która zaczyna się od umowy powierzenia, a kończy na wykazie podmiotów kluczowych.