KSC a dostawcy: o co zapytać firmę IT, hosting i dostawcę chmury?

W skrócieFirmę IT, hosting i dostawcę chmury warto zapytać o dziewięć obszarów: zabezpieczenia, dostęp do danych, podwykonawców, zgłaszanie incydentów, kopie zapasowe, ciągłość usług, lokalizację danych, testy i audyty oraz zakończenie współpracy. Podstawą jest art. 8 ust. 1 pkt 2 lit. e ustawy o KSC. Ankietę z 27 pytaniami i oceną 0-2 pobierzesz w XLSX.

Jedno zdanie z art. 8 ustawy o KSC wyprowadza część obowiązków poza mury firmy. System zarządzania bezpieczeństwem informacji (SZBI) ma zapewniać „bezpieczeństwo i ciągłość łańcucha dostaw produktów ICT, usług ICT i procesów ICT, od których zależy świadczenie usługi” (art. 8 ust. 1 pkt 2 lit. e). ICT to technologie informacyjno-komunikacyjne, a w praktyce firma IT, która administruje serwerami, hosting, na którym działa system zamówień, i chmura z pocztą oraz danymi. Ich słabe punkty stają się Twoim ryzykiem, które trzeba ocenić i ograniczyć.

Ustawa nie podaje listy pytań do dostawców. Dlatego przygotowaliśmy ankietę: 27 pytań w 9 obszarach, każde z wyjaśnieniem, dlaczego pytać, jakiego dowodu oczekiwać i co powinno zaniepokoić. Odpowiedzi oceniasz w skali 0-2, a wynik przekładasz na decyzję i zapisy w umowie. Czy firma w ogóle podlega ustawie, sprawdzisz w naszym przewodniku po NIS2 i ustawie o KSC.

Podmioty, które spełniały przesłanki 3 kwietnia 2026 r., wdrażają obowiązki z rozdziału 3 ustawy, w tym SZBI z bezpieczeństwem łańcucha dostaw, do 3 kwietnia 2027 r. (art. 33 ust. 1 ustawy nowelizującej z 23 stycznia 2026 r.). Ocenę dostawców warto zacząć wcześnie, bo zmiana umowy zależy także od drugiej strony.

Pobierz ankietę oceny dostawcy (XLSX) W pliku: instrukcja, skala 0-2, 27 pytań w 9 obszarach z kolumnami „dlaczego pytamy”, „oczekiwany dowód” i „sygnał ostrzegawczy” oraz arkusz z sumą punktów w każdym obszarze, liczbą zer w obszarach krytycznych i wynikiem wstępnym według progów opisanych niżej.

Skąd obowiązek pytania dostawców: art. 8 ustawy i NIS2

Podstawą jest art. 8 ustawy o KSC. Ust. 1 pkt 2 lit. e wymaga środków zapewniających bezpieczeństwo i ciągłość łańcucha dostaw, „z uwzględnieniem związków pomiędzy bezpośrednim dostawcą sprzętu lub oprogramowania a podmiotem”. Ust. 2 mówi, co wziąć pod uwagę przy wdrażaniu tych środków: podatności związane z dostawcą sprzętu lub oprogramowania, ogólną jakość jego produktów, usług i procesów ICT, wyniki skoordynowanej oceny bezpieczeństwa unijnej Grupy Współpracy oraz wyniki postępowania w sprawie uznania dostawcy za dostawcę wysokiego ryzyka (art. 67b).

Odpowiednikiem w dyrektywie NIS2 jest jej art. 21. Dyrektywa wymaga bezpieczeństwa łańcucha dostaw, „w tym aspekty związane z bezpieczeństwem dotyczące stosunków między każdym podmiotem a jego bezpośrednimi dostawcami lub usługodawcami” (art. 21 ust. 2 lit. d), oraz uwzględniania podatności każdego bezpośredniego dostawcy i ogólnej jakości jego produktów i praktyk, „w tym ich procedury bezpiecznego opracowywania” (art. 21 ust. 3). Polską firmę wiąże ustawa, ale dyrektywa dobrze pokazuje, o co w tym obowiązku chodzi.

Ministerstwo Cyfryzacji w dokumencie „Pytania i odpowiedzi” (stanowisko bez mocy prawnej, dalej MC) rozpisuje to na praktykę. W odpowiedzi 3.3 zaleca politykę łańcucha dostaw z kryteriami wyboru dostawców, postanowienia o poufności, zgłaszaniu incydentów i informowaniu o podatnościach w umowach oraz aktualny wykaz bezpośrednich dostawców z danymi kontaktowymi i listą dostarczanych produktów i usług. W odpowiedzi 3.9 dodaje, że trzeba znać swój łańcuch dostaw, a przy umowach adhezyjnych z globalnymi dostawcami wybierać tych, którzy mają certyfikację cyberbezpieczeństwa własnych produktów i usług.

Najbardziej szczegółowy wzorzec jest w rozporządzeniu wykonawczym Komisji (UE) 2024/2690, dalej RW 2024/2690: polityka bezpieczeństwa łańcucha dostaw, kryteria wyboru dostawców, elementy umów, monitorowanie dostawców i rejestr z punktami kontaktowymi (załącznik, pkt 5.1-5.2). Wprost stosują je tylko dostawcy chmury, centrów danych, usług zarządzanych i kilka innych rodzajów podmiotów (art. 8b ust. 1). Dla pozostałych to gotowa lista kontrolna, z której korzysta nasza ankieta. Organ właściwy do spraw cyberbezpieczeństwa może wystąpić o dowody realizacji wymogów z art. 8 ust. 1 (art. 53 ust. 2 pkt 6), a wypełnione ankiety, rejestr dostawców i decyzje o akceptacji ryzyka mogą być takimi dowodami w obszarze łańcucha dostaw.

Dostawca wysokiego ryzyka: stan na październik 2026 r. Minister właściwy do spraw informatyzacji może, po opinii Kolegium do Spraw Cyberbezpieczeństwa, uznać dostawcę sprzętu lub oprogramowania za dostawcę wysokiego ryzyka (art. 67b). Podmioty kluczowe i ważne nie wprowadzają wtedy do użytkowania objętych decyzją produktów, usług i procesów ICT, a używane wycofują najpóźniej w 7 lat od ogłoszenia decyzji w Monitorze Polskim (art. 67c ust. 1). Według przeglądu Monitora Polskiego do 9 października 2026 r. żadnej takiej decyzji nie ogłoszono, a Ministerstwo Cyfryzacji informowało 6 sierpnia 2026 r., że nie wszczęto żadnego postępowania. Procedurę zaskarżył do Trybunału Konstytucyjnego Prezydent RP (sprawa K 19/26, w toku). Dla ankiety wniosek jest praktyczny: lista producentów kluczowych komponentów u dostawcy pozwoli szybko sprawdzić skutki ewentualnej decyzji.

Kim w ustawie są firma IT, hosting i dostawca chmury

Ustawa definiuje kilka rodzajów dostawców, a firma zwykle korzysta z kilku naraz:

• dostawca sprzętu lub oprogramowania - producent, upoważniony przedstawiciel, importer lub dystrybutor produktu ICT, usługi ICT lub procesu ICT (art. 2 pkt 4c). Tego pojęcia używa art. 8 ust. 1 pkt 2 lit. e i ust. 2,
• dostawca usług zarządzanych - instalacja, eksploatacja i konserwacja produktów, usług i systemów przez wsparcie lub aktywną administrację u klienta albo zdalnie (art. 2 pkt 4i), czyli typowa firma IT,
• dostawca usług zarządzanych w zakresie cyberbezpieczeństwa (MSSP, od ang. managed security service provider) - realizacja lub wsparcie zarządzania ryzykiem, w tym obsługa incydentów, testy, audyty i doradztwo (art. 2 pkt 4j),
• dostawca usługi centrum przetwarzania danych - struktury do scentralizowanego hostingu i eksploatacji produktów, usług i procesów ICT wraz z zasilaniem i kontrolą środowiskową (art. 2 pkt 4h),
• dostawca chmury obliczeniowej - usługa dająca dostęp do skalowalnego i elastycznego zbioru zasobów obliczeniowych wspólnie wykorzystywanych przez wielu użytkowników (art. 2 pkt 4e).

MC doprecyzowuje kilka granic. Usługi chmurowe obejmują infrastrukturę, platformę i oprogramowanie jako usługę (IaaS, PaaS, SaaS), ale dostawca oprogramowania w modelu SaaS bywa tylko dostawcą oprogramowania, a nie chmury (odpowiedź 1.22). Sam odsprzedawca usług chmurowych nie jest ich dostawcą (odpowiedź 1.38). Ten sam podmiot może być jednocześnie dostawcą chmury i dostawcą usługi centrum przetwarzania danych (odpowiedź 1.39), więc firma hostingowa może mieścić się w jednej albo w obu definicjach.

Dla klienta ważne jest, czy dostawca sam podlega ustawie. Dostawcy chmury i centrów przetwarzania danych są w sektorze „Infrastruktura cyfrowa”, a dostawcy usług zarządzanych i MSSP w sektorze „Zarządzanie usługami ICT” załącznika „Sektory kluczowe”. Podlegają ustawie jako średni lub duzi przedsiębiorcy (MSSP już jako mali, art. 5 ust. 1 pkt 3), ale tylko wtedy, gdy Polska jest ich głównym miejscem prowadzenia działalności, czyli tu ma siedzibę kierownik decydujący o SZBI (art. 5a ust. 3-4), albo gdy dostawca spoza UE wyznaczył przedstawiciela w Polsce (art. 5a ust. 9). Tacy dostawcy stosują środki z RW 2024/2690 (art. 8b ust. 1), więc na większość pytań z naszej ankiety powinni mieć gotowe odpowiedzi i dokumenty. Od dostawcy spoza ustawy wyegzekwujesz tylko to, co zapiszesz w umowie.

Model z zewnętrznym informatykiem lub MSSP, w tym to, kiedy umowa spełnia art. 14 ustawy i co zostaje po stronie zarządu, opisujemy w artykule o tym, czy outsourcing IT zwalnia zarząd z odpowiedzialności.

O co pytać w dziewięciu obszarach

Pytania w ankiecie dzielimy na dziewięć obszarów. Cztery z nich traktujemy jako krytyczne: dostęp do danych i systemów, zgłaszanie incydentów, kopie zapasowe i zakończenie współpracy. Luka w tych obszarach szybko zamienia się w problem po Twojej stronie: incydent zgłoszony po terminie, utracone dane albo usługę, której nie da się przenieść.

• Zabezpieczenia. Jakie środki chronią usługę, kto za nie odpowiada, czy certyfikat obejmuje właśnie Twoją usługę i jak szybko dostawca instaluje poprawki. Ustawa każe uwzględniać podatności dostawcy i jakość jego usług (art. 8 ust. 2 pkt 1-2).
• Dostęp do danych i systemów. Kto u dostawcy ma dostęp, czy konta administracyjne chroni uwierzytelnianie wieloskładnikowe (MFA) i czy działania administratorów są rejestrowane. MC w odpowiedzi 3.3 wymienia MFA przy kontach administratorów i zaleca odbieranie dostępu osobom, które go już nie potrzebują, także personelowi dostawcy.
• Podwykonawcy. Kto jeszcze ma dostęp do Twoich danych, czy obowiązują go te same wymagania i czy dowiesz się o zmianie. MC w odpowiedzi 3.48 wyjaśnia, że bezpieczeństwo personelu wykonawców i podwykonawców zapewnia się przez zarządzanie ryzykiem łańcucha dostaw i postanowienia umowne.
• Zgłaszanie incydentów. To obszar z najkrótszym zegarem. Wczesne ostrzeżenie o incydencie poważnym składasz do zespołu reagowania na incydenty bezpieczeństwa komputerowego (CSIRT) niezwłocznie, najpóźniej w 24 godziny od wykrycia, a zgłoszenie najpóźniej w 72 godziny (art. 11 ust. 1 pkt 4 i 4a). MC w odpowiedzi 6.5 wskazuje, że informacja o incydencie może przyjść od dostawcy i że umowy z dostawcami powinny przewidywać niezwłoczne informowanie. Pytaj więc o liczbę godzin, kanał całodobowy i zakres danych z art. 12. Działania zarządu w pierwszych godzinach po wykryciu ataku opisujemy w artykule o tym, co zarząd robi w pierwszych godzinach incydentu.
• Kopie zapasowe. Co dostawca kopiuje, gdzie trzyma kopie, czy są odseparowane od systemu i kiedy ostatnio odtworzył z nich dane. MC wymienia kopie zapasowe wśród mechanizmów z art. 8 ust. 1 pkt 5 lit. a (odpowiedź 3.3). Jak sprawdzić, czy z kopii da się odtworzyć działanie firmy, opisujemy w artykule o kopiach zapasowych i ciągłości działania.
• Ciągłość usług. Czas przywrócenia usługi (RTO, od ang. recovery time objective) i maksymalna dopuszczalna utrata danych liczona w czasie (RPO, od ang. recovery point objective) w umowie o gwarantowanym poziomie usług (SLA, od ang. service level agreement), plan ciągłości dostawcy i to, co się stanie, gdy zawiedzie jego centrum danych. Skróty RTO i RPO nie występują w ustawie, ale dobrze wyrażają wymóg planów ciągłości i odtworzenia (art. 8 ust. 1 pkt 2 lit. f).
• Lokalizacja danych. W jakich krajach są dane, kopie i zdalne wsparcie oraz gdzie dostawca ma główne miejsce prowadzenia działalności w rozumieniu ustawy (art. 5a ust. 3-4). Poradnik NASK-PIB „Od wymagań do działania” wśród punktów do sprawdzenia wymienia wymagania co do miejsca przechowywania i przetwarzania danych.
• Testy i audyty. Prawo do audytu albo do sprawozdań z niezależnych audytów, wyniki testów bezpieczeństwa i zobowiązanie do szybkiego przekazania dowodów, gdy zapyta organ. Organ może żądać dokumentów z terminem nie krótszym niż 7 dni (art. 53c ust. 2 pkt 5).
• Zakończenie współpracy. Plan wyjścia: w jakim formacie i terminie odzyskasz dane i konfiguracje, kto potwierdzi usunięcie danych i kont oraz jak długo dostawca pomoże przy przejściu do następcy (RW 2024/2690, załącznik, pkt 5.1.4 lit. h).

Jak wygląda ankieta oceny dostawcy: 27 pytań, dowody i sygnały ostrzegawcze

Poniżej pełna treść ankiety: 27 pytań, po trzy w każdym obszarze. Te same pytania i kolumny, a do tego pola na odpowiedź dostawcy i ocenę, są w pliku XLSX do pobrania na początku artykułu. Kolumna „Dlaczego pytamy” wskazuje przepis albo dokument, z którego wynika pytanie. Każdą odpowiedź oceniasz w skali:

• 0 - Brak odpowiedzi, odmowa albo odpowiedź, która potwierdza lukę.
• 1 - Deklaracja bez dowodu albo rozwiązanie częściowe.
• 2 - Pełna odpowiedź poparta dowodem, który sprawdziliśmy.

Dostawcy krytycznemu, bez którego nie świadczysz usługi, zadaj wszystkie pytania i żądaj dowodów. Pozostałym wystarczy wersja skrócona: obszary 2, 4, 5 i 9, czyli 12 pytań, a w niej każde 0 wymaga klauzuli w umowie albo decyzji o akceptacji ryzyka. Skróty w tabeli: MC to Ministerstwo Cyfryzacji, RW 2024/2690 to rozporządzenie wykonawcze Komisji (UE) 2024/2690 (wprost wiąże tylko podmioty z art. 8b ust. 1, dla pozostałych jest wzorcem), NIS2 to dyrektywa (UE) 2022/2555, MSSP to dostawca usług zarządzanych w zakresie cyberbezpieczeństwa.

Jak ocenić odpowiedzi: punkty, progi i przykład

Ocena ma sens tylko wtedy, gdy liczy się dowód. Deklaracja „mamy kopie” bez protokołu z testu odtworzenia to tylko 1 punkt. Certyfikat, np. ISO/IEC 27001, jest mocnym dowodem, ale tylko w swoim zakresie: sprawdź, czy obejmuje spółkę, lokalizację i usługę, z której korzystasz. Tak samo ministerstwo opisuje oczekiwania wobec Twojej firmy: MC w odpowiedzi 11.6 pisze, że wymagane jest udowodnienie stosowania przepisów, a nie przedstawienie formalnie poprawnych dokumentów.

Po zsumowaniu punktów pełnej ankiety (maksimum 54) stosujemy trzy progi. To nasze założenie, a nie wymóg ustawy, i warto je dopasować do własnej oceny ryzyka:

• Zielony - 45-54 pkt i żadnego 0 w obszarach krytycznych: akceptacja dostawcy i przegląd w zaplanowanym cyklu.
• Żółty - 30-44 pkt albo 0 w obszarze krytycznym, które dostawca usunie aneksem lub planem naprawczym z terminem: akceptacja warunkowa.
• Czerwony - poniżej 30 pkt, odmowa zawiadamiania o incydentach w ustalonym czasie albo 0 w obszarze krytycznym, którego dostawca nie usunie, niezależnie od sumy punktów: zmiana dostawcy albo udokumentowana decyzja zarządu o akceptacji ryzyka.

Wersji skróconej progi nie dotyczą: przy 12 pytaniach rozstrzygają zera, a każde z nich wymaga klauzuli w umowie albo decyzji o akceptacji ryzyka.

Przykład. Producent maszyn rolniczych zatrudniający 180 osób, podmiot ważny z sektora produkcji, utrzymuje zintegrowany system do zarządzania firmą (ERP) w centrum danych firmy hostingowej. Bez tego systemu zakład nie przyjmie zamówień i nie zaplanuje produkcji, więc hosting jest dostawcą krytycznym i dostaje pełną ankietę. Wynik to 34 z 54 punktów.

Zera pojawiły się w trzech pytaniach: hosting nie podaje czasu zawiadomienia o incydencie w godzinach (obszar 4), nie przenosi wymagań na podwykonawców (obszar 3) i nie oferuje wsparcia przy przejściu do innego dostawcy (obszar 9). Dwa z tych zer są w obszarach krytycznych. Hosting zgodził się jednak na aneks, a 34 punkty mieszczą się w przedziale 30-44, więc wynik jest żółty.

Co zrobić z wynikiem w umowie i w nadzorze

Wynik ankiety jest wart tyle, ile zmienia w umowie i w nadzorze. Każde 0 i 1 zamieniamy na jedno z trzech działań: klauzulę w umowie, plan naprawczy dostawcy z terminem albo udokumentowaną decyzję zarządu o akceptacji ryzyka. Akceptacja ryzyka należy do zarządu, bo to kierownik podmiotu podejmuje decyzje w sprawie SZBI (art. 8d pkt 1).

W przykładzie producenta maszyn działania dla czterech obszarów z najniższym wynikiem wyglądają tak:

Jedynki z pozostałych obszarów, w tym z krytycznych obszarów 2 i 5, zamieniamy tak samo: na klauzule w tym samym aneksie, plan naprawczy albo decyzję o akceptacji ryzyka.

Z globalnymi dostawcami chmury zawiera się często umowy adhezyjne, czyli na standardowych warunkach bez negocjacji. MC radzi wtedy wybierać dostawców z certyfikacją cyberbezpieczeństwa własnych produktów i usług (odpowiedź 3.9), a w odpowiedzi 3.3 zauważa, że certyfikacja dużych dostawców ułatwia zarządzanie łańcuchem dostaw, ale może utrudnić stawianie dodatkowych wymagań, zwłaszcza gdy klient jest dużo mniejszy, i odsyła do zasady proporcjonalności. W takiej sytuacji ankietę wypełniasz sam na podstawie dokumentacji dostawcy, luki zamykasz po swojej stronie, np. konfiguracją MFA i dodatkowymi kopiami danych, a decyzję o akceptacji pozostałego ryzyka zapisuje zarząd.

Wynik i decyzję zapisz w rejestrze dostawców. MC w odpowiedzi 3.3 zaleca aktualny wykaz bezpośrednich dostawców z danymi kontaktowymi i listą dostarczanych produktów, usług i procesów ICT, a RW 2024/2690 opisuje taki rejestr w pkt 5.2 załącznika. Ocenę powtarzaj w zaplanowanych odstępach oraz po istotnych zmianach albo poważnych incydentach u dostawcy, tak jak przewiduje RW 2024/2690 (pkt 5.1.6). Ustawa częstotliwości nie określa, my przyjmujemy raz w roku.

Od czego zacząć: od rejestru dostawców do przeglądu

Sześć kroków, od których zaczyna się ocena dostawców w firmie, która dotąd tego nie robiła:

1. Rejestr dostawców. Każdy bezpośredni dostawca z punktem kontaktowym i listą produktów oraz usług (odpowiedź MC 3.3, RW 2024/2690 pkt 5.2).
2. Istotność. Podziel dostawców na krytycznych, bez których nie świadczysz usługi, i pozostałych.
3. Ankieta i dowody. Pełna wersja dla krytycznych, skrócona dla pozostałych. Termin odpowiedzi i lista oczekiwanych dowodów idą razem z ankietą.
4. Ocena i decyzja. Punkty, progi i decyzja: akceptacja, aneks z planem naprawczym albo zmiana dostawcy. Akceptację ryzyka podejmuje zarząd.
5. Umowa. Klauzule za zera i jedynki, których nie zamyka plan naprawczy ani decyzja o akceptacji ryzyka, w pierwszej kolejności w obszarach krytycznych.
6. Przegląd. Termin następnej oceny w rejestrze i ponowna ocena po zmianie usługi albo incydencie u dostawcy.

Polityka łańcucha dostaw, rejestr dostawców i wyniki ocen należą do dokumentacji SZBI. Gdzie je umieścić w całej mapie dokumentów, pokazujemy w artykule o tym, jakie dokumenty przygotować do wdrożenia KSC.

Podstawa prawna i źródła

• art. 2 pkt 4c, 4e, 4h, 4i i 4j ustawy o KSC - definicje dostawców sprzętu lub oprogramowania, chmury obliczeniowej, centrum przetwarzania danych, usług zarządzanych i usług zarządzanych w zakresie cyberbezpieczeństwa
• art. 5 ust. 1 pkt 1 i 3, ust. 2 pkt 1, art. 5a ust. 3-4, 7 i 9 ustawy o KSC - kiedy dostawcy sami podlegają ustawie, główne miejsce prowadzenia działalności
• art. 8 ust. 1 pkt 1, pkt 2 lit. b, e, f, h, l, n i pkt 5 lit. a, art. 8 ust. 2 ustawy o KSC - szacowanie ryzyka i środki, w tym bezpieczeństwo łańcucha dostaw
• art. 8b ust. 1, art. 8d pkt 1 ustawy o KSC - środki z RW 2024/2690, decyzje kierownika
• art. 10 ust. 4, art. 11 ust. 1, art. 12 ust. 1 i 3 ustawy o KSC - dokumentacja operacyjna, incydenty i treść zgłoszeń
• art. 53 ust. 2 pkt 6, art. 53c ust. 2 pkt 5 ustawy o KSC - dowody i żądania organu
• art. 67b i art. 67c ust. 1 ustawy o KSC - dostawca wysokiego ryzyka
• art. 33 ust. 1 ustawy nowelizującej z 23 stycznia 2026 r. - termin wdrożenia obowiązków z rozdziału 3
• art. 21 ust. 2 lit. d i ust. 3 dyrektywy NIS2 (UE) 2022/2555
• rozporządzenie wykonawcze Komisji (UE) 2024/2690, załącznik, pkt 4.2.2, 5.1 i 5.2 - wprost dla podmiotów z art. 8b ust. 1
• Ministerstwo Cyfryzacji, Pytania i odpowiedzi (październik 2026), odpowiedzi 1.22, 1.38, 1.39, 3.3, 3.9, 3.48, 6.5 i 11.6 - stanowiska bez mocy prawnej
• NASK-PIB, „Od wymagań do działania. Praktyczny przewodnik po nowelizacji ustawy o krajowym systemie cyberbezpieczeństwa (KSC 2.0)”, 29.09.2026, tabela 13 - publikacja nie jest oficjalnym stanowiskiem Ministerstwa Cyfryzacji
• Ustawa o krajowym systemie cyberbezpieczeństwa - tekst ujednolicony, stan na 8.10.2026 (Kancelaria Sejmu)
• Ustawa nowelizująca z 23 stycznia 2026 r. - Dziennik Ustaw 2026 poz. 252
• Dyrektywa NIS2 (UE) 2022/2555 - EUR-Lex
• Rozporządzenie wykonawcze Komisji (UE) 2024/2690 - EUR-Lex
• Ministerstwo Cyfryzacji - Pytania i odpowiedzi do znowelizowanej ustawy o KSC, październik 2026 (PDF)
• NASK-PIB - poradnik „Od wymagań do działania” (PDF)
• Ministerstwo Cyfryzacji - procedura dotycząca listy dostawców wysokiego ryzyka (6.08.2026)
• Trybunał Konstytucyjny - sprawa K 19/26