Wyrok KIO 2710/26 z 30 czerwca 2026

KIO 2710/26

1. Uwzględnia odwołanie w zakresie zarzutu 1 i 3, w wypadku zarzutu 4 jedynie w związku z zarzutem 2 i nakazuje

Zamawiającemu: Miasto Stołeczne Warszawa w imieniu którego postępowanie prowadzi: Biuro Informatyki Urzędu m.st. Warszawy we współpracy z Biurem Zamówień Publicznych Urzędu m.st. Warszawy, Pl. Bankowy 3/5, 00-950 Warszawa; adres do korespondencji: Aleje Jerozolimskie 44, 00-024 Warszawa unieważnienie czynności unieważnienia postępowania oraz nakazuje Zamawiającemu unieważnienie czynności odrzucenia oferty Odwołującego: Integrity Partners sp. z o.o., ul. Chłodna 51, 00-867 Warszawa (obie czynności pismo z 26 maja 2026 r.), jak i nakazuje Zamawiającemu dokonanie ponownego badania i oceny oferty Odwołującego i w jego ramach nakazuje wezwanie Odwołującego do wyjaśnień treści oferty w trybie art. 223 ust. 1 ustawy Prawa zamówień publicznych, gdzie w złożonych wraz z ofertą dokumentach technicznych znajdują się dane pozwalające na ustalenie zakresu funkcjonalności oferowanych detekcji i reakcji oraz ewentualnych ograniczeń dla systemów operacyjnych poza aktywnym wsparciem producenta oraz w jaki sposób należy odczytywać złożone dokumenty techniczne w tym zakresie celem identyfikacji tych informacji. W pozostałym zakresie oddala odwołanie.

1. Kosztami postępowania obciąża Miasto Stołeczne Warszawa w imieniu którego postępowanie prowadzi: Biuro Informatyki Urzędu m.st. Warszawy we współpracyz Biurem Zamówień Publicznych Urzędu m.st. Warszawy, Pl. Bankowy 3/5, 00-950 Warszawa; adres do korespondencji: Aleje Jerozolimskie 44, 00-024 Warszawa i:
2. 1.zalicza w poczet kosztów postępowania odwoławczego kwotę 15.000 zł 00 gr (słownie: piętnaście tysięcy złotych zero groszy) uiszczoną przez wykonawcę Integrity Partners sp. z o.o., ul. Chłodna 51, 00-867 Warszawa tytułem wpisu od odwołania oraz kwotę 3 600 zł 00 gr (słownie: trzy tysiące sześćset złotych zero groszy) poniesioną przez Integrity Partners sp. z o.o., ul. Chłodna 51, 00-867 Warszawa tytułem wynagrodzenia pełnomocnika Odwołującego; 2.2.zasądza od Miasto Stołeczne Warszawa w imieniu którego postępowanie prowadzi: Biuro Informatyki

Urzędu m.st. Warszawy we współpracy z Biurem Zamówień Publicznych Urzędu m.st. Warszawy, Pl.

Bankowy 3/5, 00-950 Warszawa; adres do korespondencji: Aleje Jerozolimskie 44, 00-024 Warszawa na rzecz wykonawcy Integrity Partners sp. z o.o., ul. Chłodna 51, 00-867 Warszawa kwotę 18.600 zł 00 gr (słownie: osiemnaście tysięcy sześćset złotych zero groszy) stanowiącą koszty postępowania odwoławczego poniesione z tytułu wpisu od odwołania oraz wydatków pełnomocnika Odwołującego.

KIO 2716/26

1. Oddala odwołanie.
2. Kosztami postępowania obciąża STINET Sp. z o.o., ul. Solec 18 lok. U 61, 00-410 Warszawa i:
3. 1. zalicza w poczet kosztów postępowania odwoławczego kwotę 15.000 zł 00 gr (słownie: piętnaście tysięcy złotych zero groszy) uiszczoną przez wykonawcę STINET Sp. z o.o., ul. Solec 18 lok. U 61, 00-410 Warszawa tytułem wpisu od odwołania oraz kwotę 3 600 zł 00 gr (słownie: trzy tysiące sześćset złotych zero groszy) poniesioną przez STINET Sp. z o.o., ul. Solec 18 lok. U 61,00-410 Warszawa tytułem wynagrodzenia pełnomocnika Odwołującego.

Na orzeczenie - w terminie 14 dni od dnia jego doręczenia - przysługuje skarga za pośrednictwem Prezesa Krajowej Izby Odwoławczej do Sądu Okręgowego w Warszawie - Sądu Zamówień Publicznych.

Przewodniczący

………………………………

Sygn. akt

KIO 2710/26

KIO 2716/26

Postępowanie o udzielenie zamówienia publicznego prowadzone trybie przetargu nieograniczonego pn. „Dostawa i wdrożenie systemów klasy XDR i NDR na okres 36 miesięcy”, Numer Postępowania: ZP/JK/271/III-193/25,zostało wszczęte ogłoszeniem opublikowanym w Dzienniku Urzędowym Unii Europejskiej w dniu 16.12.2025r. pod nr OJ S 242/2025 834700-2025 przez: Miasto Stołeczne Warszawa w imieniu którego postępowanie prowadzi: Biuro Informatyki Urzędu m.st. Warszawy we współpracy z Biurem Zamówień Publicznych Urzędu m.st. Warszawy, Pl. Bankowy 3/5, 00950 Warszawa; adres do korespondencji: Aleje Jerozolimskie 44, 00-024 Warszawa zwany dalej: „Zamawiającym”. Do ww. postępowania o udzielenie zamówienia zastosowanie znajdują przepisy ustawy z dnia 11 września 2019 r. - Prawo zamówień publicznych (t.j. Dz. U. z 2024 r. poz. 1320 z późn. zm.), zwana dalej: „Pzp” albo „PZP” albo „pzp”.

W dniu 26.05.2026 r. (za pomocą środków komunikacji elektronicznej) Zamawiający poinformował o unieważnieniu postępowania na podstawie art. 255 pkt 2 Pzp. Jednocześnie, poinformował o odrzuceniu na podstawie art. 226 ust. 1 pkt.

1. Pzp oferty INTEGRITY PARTNERS Sp. z o. o., ul. Chłodna 51, 00-867 Warszawa zwanej dalej:

„INTEGRITY PARTNERS Sp. z o. o.” albo „Odwołującym w sprawie o sygn. akt: KIO 2710/26” albo „Przystępującym po stronie Zamawiającego w sprawie o sygn. akt: KIO 2716/26” oraz na podstawie na mocy art. 226 ust 1 pkt 8 w zw. z art. 224 ust. 6 Pzp oraz art. 226 ust. 1 pkt. 5) Pzp - Stinet Sp. z o.o., Solec 18 lok. U61, 00-410 Warszawa zwanej dalej: „Stinet Sp. z o.o.” albo „Odwołującym w sprawie o sygn. akt: KIO 2716/26” albo „Przystępującym po stronie Zamawiającego w sprawie o

sygn. akt

KIO 2710/26”. Stwierdził: „(…)

I. ZAWIADOMIENIE O UNIEWAŻNIENIU CZYNNOŚCI WYBORU OFERTY NAJKORZYSTNIEJSZEJ Biuro Informatyki Urzędu m.st. Warszawy prowadzące we współpracy z Biurem Zamówień Publicznych Urzędu m.st. Warszawy wyżej wskazane postępowanie o udzielenie zamówienia publicznego, po zapoznaniu się z odwołaniem złożonym 7 maja 2026 r. przez wykonawcę Stinet sp. z o.o., ul. Solec 18 lok. U6, 100-410 Warszawa i przeprowadzeniu autokontroli czynności wyboru oferty najkorzystniejszej w przedmiotowym postępowaniu, unieważnia czynność wyboru najkorzystniejszej oferty dokonaną 27 kwietnia 2026 r. oraz powtarza czynność badania i oceny ofert.

II. INFORMACJA O UNIEWAŻANIENIU POSTĘPOWANIA Zamawiający po powtórzeniu czynności badania i oceny ofert w przedmiotowym postępowaniu zawiadamia o unieważnieniu postępowania o udzielenie zamówienia ponieważ wszystkie złożone oferty podlegają odrzuceniu.

III. INFORMACJA O ODRZUCENIU OFERTY Zamawiający informuje że: i. podtrzymuje odrzucenie oferty Wykonawcy Stinet sp. z o.o., Solec 18 lok. U61, 00-410 Warszawa, ponieważ zawiera rażąco niską cenę w zakresie usługi Asysty Wykonawcy i Wsparcia Eksperckiego.

Jednocześnie Zamawiający wskazuje, że oferta wykonawcy podlega również odrzuceniu ponieważ jej treść jest niezgodna z warunkami zamówienia. ii. odrzuca ofertę INTEGRITY PARTNERS Sp. z o. o., ul. Chłodna 51, 00-867 Warszawa, ponieważ jej treść jest niezgodna z warunkami zamówienia.

Uzasadnienie:

Ad. i)

1. Zamawiający podtrzymuje swoje uzasadnienie odrzucenia oferty Stinet Sp. z o.o. przedstawione w piśmie z 26 kwietnia 2026 r.
2. Jednocześnie Zamawiający wskazuje, że oferta Wykonawcy jest niezgodna z warunkami zamówienia. Zgodnie z pkt 1.15 OPZ, dla wykazanych (zgodnie z pkt. 1.14 OPZ) systemów operacyjnych, które są poza aktywnym wsparciem producenta (EoL ang. End of Life), Wykonawca powinien opisać zakres funkcjonalności oferowanych detekcji i reakcji oraz ewentualne ograniczenia.

Załączony przez Stinet Sp. z o.o. wykaz nie spełnia wymagań OPZ. Wykonawca podał nazwę systemu operacyjnego, wersję, datę końca wsparcia oraz zakres funkcjonalny. Dla systemów EoL wskazany jest rodzaj rozwiązania „Antywirus następnej generacji (NGAV)”, natomiast brakuje opisu funkcjonalności oferowanych detekcji i reakcji oraz ograniczeń wynikających z zastosowanego rozwiązania.

Ad. ii) Zamawiający odrzucił ofertę Wykonawcy INTEGRITY PARTNERS Sp. z o.o., ponieważ jest niezgodna z następującymi zapisami OPZ: a) pkt. 1.10 – 1.12 OPZ b) pkt. 1.15 OPZ c) pkt. 1.69 OPZ Ad. a) Zamawiający w pkt 1.10–1.12 OPZ, wymagał zaoferowania rozwiązania z pełną funkcjonalnością XDR klasy Enterprise dla wszystkich 19 000 chronionych urządzeń, bez rozróżniania na platformy.

W ofercie zaproponowano licencje dla 16 000 komputerów i serwerów — licencja Pro/Advanced (pełny XDR) oraz dla 3 000 telefonów — licencja Prevent (prewencyjna, słabsza funkcjonalnie, bez telemetrii).

Z dostępnej dokumentacji producenta oferowanego rozwiązania wynika, że, ze względy na specyfikę architektury iOS/Android, zakres ochrony telefonów jest realizowany w odmienny sposób niż dla systemów desktopowych. Oznacza to, że nie jest to ta sama funkcjonalność XDR co dla komputerów.

Ad. b) Zamawiający wskazuje, że oferta Wykonawcy jest niezgodna z warunkami zamówienia określonymi w pkt. 1.15 SW Z, zgodnie z którymi, dla wykazanych (zgodnie z pkt. 1.14 OPZ) systemów operacyjnych, które są poza aktywnym wsparciem producenta (EoL ang. End of Life), Wykonawca miał opisać zakres funkcjonalności oferowanych detekcjii reakcji oraz ewentualne ograniczenia.

Załączony przez INTEGRITY PARTNERS Sp. z o.o. wykaz nie spełnia wymagań OPZ. Wykonawca podał nazwę systemu operacyjnego, wersję, datę końca wsparcia, natomiast brakuje opisu funkcjonalności oferowanych detekcji i reakcji oraz ograniczeń wynikających z zastosowanego rozwiązania. Ponadto w załączonych do oferty dodatkowych tabelach „Cortex XDR Compatibility Matrix” oraz „Nowe funkcjonalności agenta dla systemów Windows”, Zamawiający nie znalazł potwierdzenia spełniania zapisów pkt. 1.15 OPZ.

Ad. c) Oferta nie spełnia wymagań pkt 1.69 OPZ, zgodnie z którym, Zamawiający wymagał zapewnienia 24-miesięcznej retencji danych dla wszystkich 19000 chronionych urządzeń, bez wyjątków.

Wskazana w ofercie INTEGRITY PARTNERS Sp. z o.o. licencja Prevent dla telefonów zapewnia domyślnie 186 dni retencji alertów (około 6 miesięcy). W ofercie brak jakichkolwiek licencji rozszerzających retencję dla urządzeń mobilnych. (…)”.

Na mocy zarządzenia Prezesa Krajowej Izby Odwoławczej z 11.06.2026 r. sprawy o sygn. akt: KIO 2710/26, sygn. akt: KIO 2716/26 zostały skierowane do łącznego rozpatrzenia.

Odwołanie w sprawie o sygn. akt: KIO 2710/26:

W dniu 05.06.2026 r. (przez dostawcę usługi e-Doręczenia) INTEGRITY PARTNERS Sp. z o. o. wniósł odwołanie na czynność z 26.05.2026 r.

Zarzut nr 1 - art. 226 ust. 1 pkt 5 PZP w zw. z art. 16 PZP w zw. z pkt 1.10 - 1.12 OPZ poprzez bezzasadne odrzucenie oferty Odwołującego z uwagi na niespełnienie wymagania polegającego na objęciu „pełną funkcjonalnością XDR klasy Enterprise wszystkich 19 000 chronionych urządzeń, bez rozróżniania na platformy”, ponieważ zdaniem Zamawiającego „Z dostępnej dokumentacji producenta oferowanego rozwiązania wynika, że, ze względu na specyfikę architektury iOS/Android, zakres ochrony telefonów jest realizowany w odmienny sposób niż dla systemów desktopowych.

Oznacza to, że nie jest to ta sama funkcjonalność XDR co dla komputerów”, podczas gdy wymóg taki nie wynika z żadnego postanowienia OPZ, w szczególności Zamawiający nie przewidział wymogu zapewnienia identycznego zakresu funkcjonalności dla wszystkich platform systemowych objętych ochroną, a ponadto zgodnie z oficjalnym z oświadczeniem producenta – tj. Palo Alto Networks (Poland) sp. z o.o. („Palo Alto”) rozwiązania zaoferowanego przez Odwołującego - tj.

Cortex XDR, rozwiązanie to spełnia wymagania Zamawiającego określone w pkt 1.10 - 1.12 OPZ; Zarzut nr 2 - art. 226 ust. 1 pkt 5 PZP w zw. z art. 16 PZP w zw. z pkt 1.15 OPZ poprzez bezzasadne odrzucenie oferty złożonej przez Odwołującego z uwagi na niespełnienie wymagania polegającego na tym, że „dla wykazanych (zgodnie z pkt. 1.14 OPZ) systemów operacyjnych, które są poza aktywnym wsparciem producenta (EoL ang. End of Life), Wykonawca miał opisać zakres funkcjonalności oferowanych detekcji i reakcji oraz ewentualne ograniczenia”, podczas gdy Odwołujący przedstawił wymagane informacje w dokumentach złożonych wraz z ofertą, tj. w: (i)Załączniku 6_Wykaz obsługiwanych przez system XDR systemów operacyjnych.xlsx, (ii) Załączniku 6a_Wykaz obsługiwanych przez system XDR systemów operacyjnych.pdf (iii) Załączniku 6b_Wykaz obsługiwanych przez system XDR systemów operacyjnych_nowe funkcjonalności dla Windows.pdf - w sposób odpowiadający architekturze oraz modelowi rozwoju oferowanego rozwiązania Palo Alto Cortex XDR, a tym samym spełnił wymaganie określone w pkt 1.15 OPZ; Zarzut nr 3 - art. 226 ust. 1 pkt 5 PZP w zw. z art. 16 PZP w zw. z pkt 1.69 OPZ poprzez bezzasadne odrzucenie oferty złożonej przez Odwołującego z uwagi na niespełnienie wymagania zgodnie z którym, Zamawiający oczekiwał

„zapewnienia 24-miesięcznej retencji danych dla wszystkich 19000 chronionych urządzeń, bez wyjątków”, ponieważ zdaniem Zamawiającego „Wskazana w ofercie INTEGRITY PARTNERS Sp. z o.o. licencja Prevent dla telefonów zapewnia domyślnie 186 dni retencji alertów (około 6 miesięcy). W ofercie brak jakichkolwiek licencji rozszerzających retencję dla urządzeń mobilnych”, podczas gdy wymaganie określone w pkt 1.69 OPZ odnosi się do systemu bezpieczeństwa jako całości, ocena dokonana przez Zamawiającego została oparta nie na analizie całej architektury oferowanego rozwiązania, lecz na analizie pojedynczego komponentu licencyjnego, a ponadto stanowisko Zamawiającego pozostaje sprzeczne z oficjalnym oświadczeniem Palo Alto, tj. producenta rozwiązania zaoferowanego przez Odwołującego - Cortex XDR.

Zarzut nr 4 (ewentualny do zarzutów nr 1-3) - art. 223 ust. 1 w zw. z art. 16 PZP poprzez zaniechanie wezwania Odwołującego do złożenia wyjaśnień w zakresie sposobu spełnienia przez niego wymagań określonych w pkt 1.10 - 1.12, 1.15 i 1.69 OPZ, podczas gdy jeśli Zamawiający miał jakiekolwiek wątpliwości w tym zakresie, to przed odrzuceniem oferty Odwołującego winien w pierwszej kolejności zwrócić się do Odwołującego o ich wyjaśnienie.

Zarzut nr 5 - art. 226 ust. 1 pkt 5 PZP w zw. z art. 16 PZP w zw. z pkt 2.5 OPZ poprzezzaniechanie odrzucenia oferty złożonej przez wykonawcę Stinet sp. z o.o. („Stinet”), ponieważ:

1. oferta Stinet nie została złożona zgodnie z wymaganiem co do formy wykazu systemów operacyjnych, ponieważ Zamawiający wymagał arkusza Excel, a Stinet złożył PDF;
2. wykaz systemów złożony przez Stinet nie potwierdza objęcia wsparciem co najmniej wszystkich wersji systemów Apple/mobile, które Zamawiający wcześniej formalnie doprecyzował jako objęte wymaganiem, tj. macOS 12 i nowszych,

iOS/iPadOS 15 i nowszych oraz Android 10 i nowszych;

1. nie można przyjąć, że wskazanie w wykazie wyłącznie wersji nowszych automatycznie potwierdza wsparcie dla wersji wcześniejszych. Gdyby taka wykładnia była dopuszczalna, wymaganie złożenia szczegółowego wykazu wersji i dat End of Support byłoby pozbawione sensu. Zamawiający żądał tego dokumentu właśnie po to, aby ustalić, jakie konkretne systemy i wersje są objęte ofertą oraz jaki jest zakres ochrony dla platform EoL.

Zarzut nr 6 - art. 255 pkt 2 w zw. z art. 16 PZP poprzez bezzasadne unieważnienie Postępowania z uwagi na odrzucenie wszystkich złożonych ofert, podczas gdy oferta Odwołującego nie podlega odrzuceniu i winna zostać uznana za najkorzystniejszą.

Wnosił o merytoryczne rozpatrzenie odwołania oraz uwzględnienie go w całości, jak również nakazanie Zamawiającemu:

1. Unieważnienie czynności unieważnienia Postępowania;
2. Unieważnienie czynności odrzucenia oferty Odwołującego;
3. Powtórzenie czynności badania i oceny ofert oraz: a.uznanie, że oferta Odwołującego spełnia wymagania określone w pkt 1.10 - 1.12, 1.15 i 1.69 OPZ oraz wybór oferty Odwołującego jako najkorzystniejszej w Postępowaniu lub - ewentualnie - wezwanie Odwołującego do złożenia wyjaśnień dot. sposobu spełnienia wymagań określonych w pkt 1.10 - 1.12, 1.15 i 1.69 OPZ; b.odrzucenie oferty Stinet dodatkowo z uwagi na niespełnienie wymagania określonego w pkt 2.5 OPZ, niezależnie od podstaw odrzucenia wskazanych w informacji Zamawiającego z dnia 26 maja 2026 r.

Ponadto wnosił o:

1. Dopuszczenie i przeprowadzenie dowodów na okoliczności wskazane w treści odwołania oraz dowodów, które zostaną złożone przez Odwołującego na rozprawie.
2. Zasądzenie od Zamawiającego na rzecz Odwołującego zwrotu kosztów postępowania odwoławczego, w tym kosztów doradztwa prawnego, według norm przepisanych i zgodnie z fakturą przedstawioną przez Odwołującego na rozprawie.

Zarys stanu faktycznego Przedmiotem Postępowania prowadzonego przez Zamawiającego jest dostawa i wdrożenie systemów klasy XDR i NDR na okres 36 miesięcy. Swoje oferty w Postępowaniu złożyło dwóch wykonawców, tj. Odwołujący oraz Stinet. Po przeprowadzeniu badania i oceny ofert, Zamawiający w dniu 24 kwietnia 2026 r. poinformował o wyborze oferty najkorzystniejszej, za którą została uznana oferta Odwołującego. W tym samym piśmie Zamawiający poinformował o odrzuceniu oferty Stinet z uwagi na zaoferowanie rażąco niskiej ceny. Co przy tym istotne, Zamawiający na tym etapie nie zdecydował się na odrzucenie oferty Odwołującego, pomimo „donosu” złożonego przez Stinet przed wyborem oferty najkorzystniejszej (tj. w dniu 26 marca 2026 r.), w którym Stinet poinformował Zamawiającego o szeregu rzekomych nieprawidłowości w ofercie Odwołującego, w tym m.in. o jej niezgodności z pkt 1.10 - 1.12, 1.15 i 1.69 OPZ, na które obecnie powołuje się Zamawiający. Od powyższej decyzji Zamawiającego w dniu 7 maja 2026 r. Stinet złożył odwołanie do KIO, w którym – z jednej strony – dążył do zakwestionowania decyzji Zamawiającego o odrzuceniu jego oferty z uwagi na rażąco niską cenę, z drugiej zaś - w znacznej mierze powielił argumentację wymierzoną w ofertę IP (dotyczącą m.in. jej rzekomej niezgodności z pkt 1.10 - 1.12, 1.15 i 1.69 OPZ), usiłując odrzucić ofertę IP z Postępowania. W odpowiedzi na odwołanie Stinet Zamawiający, w dniu 26 maja 2026 r. poinformował, że „po przeprowadzeniu autokontroli czynności wyboru oferty najkorzystniejszej w przedmiotowym postępowaniu, unieważnia czynność wyboru najkorzystniejszej oferty dokonaną 27 kwietnia 2026 r. oraz powtarza czynność badania i oceny ofert.”. W rezultacie ponownego badania i oceny ofert Zamawiający podtrzymał swoją decyzję o odrzuceniu oferty Stinet z uwagi na rażąco niską cenę, a dodatkowo odrzucił ofertę Stinet z uwagi na jej niezgodność z warunkami Zamówienia (tj. pkt 1.15 OPZ). Dla systemów operacyjnych, które są poza aktywnym wsparciem producenta (EoL ang. End of Life) Stinet nie opisał bowiem zakresu funkcjonalności oferowanych detekcji i reakcji oraz ewentualnych ograniczeń, ograniczając się do lakonicznego stwierdzenia „Antywirus następnej generacji (NGAV)”. Z kolei w odniesieniu do oferty Odwołującego Zamawiający zarzucił jej niezgodność z pkt 1.10 - 1.12, 1.15 i 1.69 OPZ i finalnie odrzucił ją z uwagi na niezgodność z warunkami Zamówienia. W konsekwencji powyższego Zamawiający unieważnił Postępowanie, ponieważ wszystkie złożone oferty zostały odrzucone. [Zarzut nr 1 – brak spełnienia wymagań określonych w pkt. 1.10 – 1.12 OPZ] Zgodnie z informacją z 26 maja 2026 r. Zamawiający odrzucił ofertę Odwołującego z uwagi na niespełnienie wymagania określonego w pkt 1.10 – 1.12 OPZ. Zamawiający uzasadnił swą decyzję w następujący sposób:

Z powyższą decyzją i uzasadnieniem Zamawiającego Odwołujący zdecydowanie się nie zgadza. W pierwszej kolejności należy przytoczyć aktualne i obowiązujące brzmienie pkt 1.10-1.12 OPZ:

1. 10Zamawiający wymaga dostarczenia rozwiązania XDR (ang. Extended Detection and Response) klasy Enterprise, pochodzącego od jednego producenta i zapewniającego pełną interoperacyjność wszystkich modułów.
2. 11System XDR musi zostać dostarczony w modelu subskrypcyjnym na okres 36 miesięcy.
3. 12Subskrypcja/licencja ma umożliwić objęcie ochroną co najmniej 2 000 serwerów, 14 000 stacji końcowych, 3 000 urządzeń mobilnych.

Jak zatem wynika z powyższych postanowień OPZ, Zamawiający nie wymagał „pełnej funkcjonalności XDR klasy Enterprise dla wszystkich 19000 chronionych urządzeń, bez rozróżnienia na platformy.”

W szczególności Zamawiający nie przewidział wymogu zapewnienia identycznego zakresu funkcjonalności dla wszystkich platform systemowych objętych ochroną. Zamawiający nie wskazał również, że urządzenia Android oraz iOS muszą zapewniać taki sam zakres danych telemetrycznych jak systemy Windows, Linux lub macOS.

Zamawiający wymagał za to, aby dostarczane rozwiązanie XDR „pochodziło od jednego producenta i zapewniało pełną interoperacyjność wszystkich modułów.” Punkt 1.10 OPZ opisuje zatem rozwiązanie jako całość.

Jest to wymóg dotyczący architektury platformy (jeden producent, współpracujące moduły), a nie wymóg jednolitej, identycznej funkcjonalności na każdym pojedynczym urządzeniu. „Pełna interoperacyjność modułów" to bowiem coś innego niż „identyczna funkcjonalność modułów".

Z kolei zgodnie z pkt 1.12 OPZ Zamawiający wymagał„objęcia ochroną" określonej liczby urządzeń, a nie „zapewnienia identycznej funkcjonalności XDR" na każdym z nich. Oferta Odwołującego obejmuje ochroną 3 000

urządzeń mobilnych dedykowaną licencją, a zatem literalnie spełnia ten wymóg.

Nadto, Zamawiający sam doskonale zdaje sobie sprawę z tego, że ze względu na specyfikę platform iOS/Android zakres ochrony telefonów jest realizowany w odmienny sposób niż dla systemów desktopowych. Świadczy o tym odpowiedź na pytanie nr 20, której Zamawiający udzielił w dniu 23 stycznia 2026 r.: „Pytanie 20 Treść:

Dotyczy: Załącznik nr 1 do wzoru umowy – OPZ, p. 7.1.

1. 1 System XDR musi posiadać wbudowany moduł analizy śledczej (Forensic), dostępny co najmniej dla hostów w liczbie określonej w punkcie 1.12 Opisu Przedmiotu Zamówienia.

W punkcie 7.1 OPZ Zamawiający określił wymagania dotyczące modułu Forensic. Zamawiający wskazał, że moduł ten powinien być dostępny dla wszystkich urządzeń końcowych wymienionych w p. 1.12, tj. dla 2000 serwerów, 14 000 stacji roboczych oraz 3000 urządzeń mobilnych.

Na podstawie naszego doświadczenia wskazujemy, że nie spotkaliśmy się dotychczas z wdrożeniem systemu XDR, w którym moduł Forensic byłby licencjonowany dla wszystkich urządzeń końcowych, w szczególności urządzeń mobilnych. W znanych nam modelach wdrożeniowych licencje Forensic obejmowały zazwyczaj 5–30% wszystkich licencji, przy czym w większości przypadków było to 10–15%, i dotyczyły one wyłącznie serwerów oraz stacji roboczych działających pod kontrolą systemów Windows/macOS/Linux.

W związku z powyższym prosimy o potwierdzenie, czy Zamawiający intencjonalnie planuje nabycie licencji Forensic dla 19 000 urządzeń (serwerów, stacji roboczych oraz urządzeń mobilnych). Jeżeli liczba ta ma być inna, prosimy o wskazanie jej w odpowiedzi na niniejsze pytanie.

Odpowiedź:

Zamawiający przychyla się do uwagi Wykonawcy w części dotyczącej urządzeń mobilnych, uznając specyfikę systemów iOS i Android.

W związku z powyższym Zamawiający modyfikuje treść wymagania pkt 7.1 OPZ, nadając mu następujące brzmienie:

„7.1. System XDR musi posiadać wbudowany moduł analizy śledczej (Forensic), dostępny dla wszystkich chronionych serwerów oraz stacji roboczych (Windows, macOS, Linux) w liczbie określonej w punkcie 1.12 Opisu Przedmiotu Zamówienia. Wymaganie nie dotyczy urządzeń mobilnych (Android, iOS/iPadOS)."

Jednocześnie Zamawiający nie wyraża zgody na ograniczenie licencjonowania modułu Forensic dla serwerów i stacji roboczych do poziomu 5-30% populacji. Zamawiający wymaga, aby funkcjonalność analizy śledczej była dostępna „na żądanie” dla każdego chronionego serwera i stacji roboczej (100% pokrycia), bez konieczności reinstalacji agenta, ręcznego przenoszenia licencji pomiędzy urządzeniami czy dokupowania rozszerzeń w momencie wystąpienia incydentu.”

Z powyższego jednoznacznie wynika zatem, że Zamawiający zaakceptował stan, w którym z uwagi na

specyfikę systemów iOS i Android zakres ochrony telefonów może być realizowany w odmienny sposób niż dla systemów desktopowych (tj. z wyłączeniem modułu Forensic).

Powyższe znajduje dodatkowe potwierdzenie także w innych punktach OPZ: a.pkt 4.37 OPZróżnicuje architekturę agenta: kernel mode lub równoważny na Windows, user space albo kernel space z auto-failover na Linux oraz wyłącznie user space na macOS, a pkt 4.38 dopuszcza dowolną architekturę, o ile zapewnia skuteczność i stabilność. b.pkt 4.41 OPZ wymaga telemetrii obejmującej m.in. „operacje na rejestrze Windows”, co z natury rzeczy nie może dotyczyć Linux, macOS, Android ani iOS, a więc sam OPZ zakłada platformowo zróżnicowany zakres telemetrii. c.pkt 7.6 OPZ odmiennie określa dane forensic dla Windows oraz dla macOS/Linux, wskazując np. Amcache, Shellbag, Shim, Prefetch i MFT dla Windows, a shell history, moduły jądra i zamontowane woluminy dla macOS/Linux oraz Apple Unified Logs tylko dla macOS.

Nadto, jak wynika z informacji, którą Odwołujący uzyskał od producenta rozwiązania Cortex XDR – tj. Palto Alto, Zamawiający w toku Postępowania zwrócił się do Palo Alto o potwierdzenie powyższej kwestii. W odpowiedzi Zamawiający uzyskał od Palo Alto następującą informację:

„Producent potwierdza, że agent Cortex XDR jest wspierany na urządzeniach mobilnychz systemami Android oraz iOS/iPadOS, a urządzenia te są zarządzane i monitorowanew ramach tej samej platformy Cortex XDR. Oficjalna dokumentacja Palo Alto Networks potwierdza możliwość instalacji agenta Cortex XDR na urządzeniach mobilnych Android i iOS/iPadOS.

Producent wskazuje jednocześnie, że zakres funkcjonalny ochrony urządzeń mobilnych należy oceniać z uwzględnieniem specyfiki architektury tych platform. Systemy mobilne wykorzystują model bezpieczeństwa oparty na izolacji aplikacji i sandboxingu, w ramach którego aplikacje działają w odseparowanych przestrzeniach oraz z ograniczonym dostępem do zasobów systemowych. Apple wskazuje, że App Sandbox ogranicza dostęp aplikacji do zasobów i danych, a Android opiera bezpieczeństwo aplikacji na Application Sandbox, izolując aplikacje od siebie i od systemu.

Z tego względu funkcjonalność ochronna dla urządzeń mobilnych jest realizowana w odmienny sposób niż dla systemów desktopowych i serwerowych. W rozumieniu Producenta pełna ochrona urządzeń mobilnych oznacza pełny zakres funkcjonalności przewidziany przez architekturę Cortex XDR dla tej klasy urządzeń, z uwzględnieniem technicznychi systemowych ograniczeń platform mobilnych.

Producent potwierdza, że w zaoferowanej konfiguracji licencja PAN-XDR-PRVT dla 3 000 urządzeń mobilnych zapewnia pełny zakres ochrony przewidziany przez producenta.” Producent jednoznacznie wskazał, że zakres funkcjonalny

urządzeń mobilnych powinien być oceniany z uwzględnieniem specyfiki tych platform oraz że pełna funkcjonalność dla urządzeń mobilnych oznacza pełny zakres funkcjonalności przewidziany dla tej klasy urządzeń przez architekturę Cortex XDR.

Producent wyjaśnił również, że z uwagi na architekturę systemów Android i iOS urządzenia mobilne nie generują takiego samego zakresu telemetrii jak klasyczne stacje robocze i serwery.

Pomimo uzyskania takiego stanowiska Zamawiający dokonał oceny oferty Odwołującego przyjmując założenie przeciwne, tj. że brak identycznego zakresu telemetrii dla urządzeń mobilnych oznacza niespełnienie wymagań OPZ, które to wymagania nie wynikają w żaden sposób z OPZ.

Mając na uwadze powyższe należy zatem stwierdzić, że Zamawiający nie wykazał, że zaoferowane rozwiązanie nie zapewnia ochrony urządzeń mobilnych wymaganej przez OPZ.

Zamawiający wykazał jedynie, że funkcjonalność urządzeń mobilnych różni się od funkcjonalności systemów desktopowych, co pozostaje naturalną konsekwencją architektury tych platform i nie stanowi wymagania określonego w dokumentacji postępowania. [Zarzut nr 2 – brak spełnienia wymagania określonego w pkt. 1.15 OPZ] W dalszej kolejności Zamawiający ustalił, że oferta Odwołującego nie spełnia wymagania określonego w pkt 1.15 OPZ. Zamawiający uzasadnił swoją decyzję w następujący sposób:

Na wstępie omówienia niniejszego zarzutu Odwołujący pragnie zaznaczyć, że Zamawiający na tej samej podstawie (niezgodności z pkt 1.15 OPZ) odrzucił również ofertę złożoną przez drugiego wykonawcę – tj. Stinet. Co jednak przy tym istotne, sytuacja Stinet jest w tym kontekście całkowicie odmienna od sytuacji Odwołującego. Stinet w złożonym przez siebie wykazie ograniczył się bowiem do lakonicznego stwierdzenia „Antywirus następnej generacji (NGAV)”, bez jakichkolwiek informacji dotyczących funkcjonalności oferowanych detekcji i reakcji oraz ograniczeń wynikających z zastosowanego rozwiązania.

Tymczasem jak zostanie to wykazane w dalszej części uzasadnienia niniejszego zarzutu, Odwołujący opisał

zakres funkcjonalności oferowanych detekcji i reakcji oraz ewentualnych ograniczeń dla systemów operacyjnych pozostających poza aktywnym wsparciem producenta, jednak Zamawiający tych informacji prawidłowo nie zidentyfikował.

Zgodnie z pkt 1.14 OPZ wykonawca miał dołączyć wykaz obsługiwanych przez system XDR systemów operacyjnych wraz z wersjami oraz datami końca wsparcia producenta. Zgodnie natomiast z pkt 1.15 OPZ, dla systemów

operacyjnych poza aktywnym wsparciem producenta, wykonawca miał opisać zakres funkcjonalności oferowanych detekcji i reakcji oraz ewentualne ograniczenia. OPZ nie wskazywał jednak formy tego opisu, nie określał wzoru tabeli funkcjonalnej, nie narzucał minimalnego poziomu szczegółowości ani nie wymagał, aby przy każdym systemie EoL powtarzać pełny katalog funkcjonalności detekcji, reakcji i ograniczeń.

Zamawiający w informacji o odrzuceniu oferty stwierdził, że Odwołujący podał nazwę systemu operacyjnego, wersję oraz datę końca wsparcia, lecz — zdaniem Zamawiającego — zabrakło opisu funkcjonalności detekcji i reakcji oraz ograniczeń. Jednocześnie Zamawiający przyznał, że Odwołujący złożył dodatkowe tabele: „Cortex XDR Compatibility Matrix” oraz „Nowe funkcjonalności agenta dla systemów Windows”, jednak uznał, że nie znalazł w nich potwierdzenia spełnienia pkt 1.15 OPZ.

Tym samym Zamawiający nie zakwestionował samego faktu złożenia dokumentów technicznych, lecz przyjął, że nie pozwalały one na ustalenie zakresu funkcjonalności i ograniczeń. Ocena ta jest nieprawidłowa, ponieważ Zamawiający przeanalizował dokumenty w sposób wybiórczy i w oderwaniu od siebie, zamiast odczytać je łącznie jako spójny mechanizm opisania funkcjonalności systemów EoL.

Odwołujący złożył wraz z ofertą trzy wzajemnie powiązane dokumenty: a.Wykaz obsługiwanych przez system XDR systemów operacyjnych(Załącznik 6) — wypełniony zgodnie ze wzorem Zamawiającego, wskazujący system operacyjny, wersję oraz datę zakończenia wsparcia producenta; b.Cortex XDR Compatibility Matrix(Załącznik 6a) — dokument producenta wskazujący, które systemy operacyjne są obsługiwane przez Cortex XDR i jakie wersje agentów mogą być stosowane na poszczególnych platformach. c.Nowe funkcjonalności agenta dla systemów Windows (Załącznik 6b) — dokument wskazujący, które funkcjonalności zostały dodane w nowszych wersjach agentów Windows 8.x/9.x i są nieobecne w wersji 7.9.103-CE, oraz potwierdzający, że wersja 7.9.103-CE zapewnia kompleksową ochronę przed złośliwym oprogramowaniem dla systemów, których wsparcie producenta zostało zakończone.

W przypadku produktu Cortex XDR zakres funkcjonalności dla danego systemu operacyjnego nie wynika zatem wyłącznie z samej nazwy systemu operacyjnego. Wynika on z tego, jaka wersja agenta Cortex XDR może zostać zainstalowana na danej platformie. Dlatego prawidłowy sposób oceny pkt 1.15 OPZ powinien wyglądać następująco: a.z wykazu należy ustalić, czy dany system jest systemem EoL, b.z Compatibility Matrix należy ustalić, czy system jest obsługiwany oraz jaka wersja agenta ma zastosowanie, c.z załącznika 6b należy ustalić, jakie funkcjonalności nie występują w starszej wersji agenta względem nowszych wersji, d.z tych danych należy ustalić zakres funkcjonalności oraz ograniczenia dla danego systemu EoL.

Takie podejście odpowiada rzeczywistej architekturze produktu. Ograniczenia dla systemów EoL nie wynikają bowiem abstrakcyjnie z samego faktu zakończenia wsparcia przez producenta systemu operacyjnego, lecz z wersji agenta, którą można na takim systemie zastosować.

Dla zobrazowania, że dokumenty złożone wraz z ofertą pozwalały na ustalenie zakresu funkcjonalności i ograniczeń, Odwołujący wskazuje przykład systemu Windows 7.

W wykazie obsługiwanych systemów operacyjnych, złożonym zgodnie ze wzorem Zamawiającego, wskazano system Windows w wersji 7 oraz datę zakończenia wsparcia producenta. Oznaczało to, że system ten powinien zostać oceniony jako system EoL w rozumieniu pkt 1.15 OPZ.

Następnie z dokumentu Cortex XDR Compatibility Matrixwynikało, że dla Windows 7 właściwą wersją agenta Cortex XDR jest wersja7.9.103-CE. W części dotyczącej Windows 7 dokument wskazuje, że Cortex XDR Agent 7.9 był ostatnią wersją wspierającą Windows 7, a wersja 7.9.103CE zapewnia rozszerzone wsparcie dla tych systemów do 31 grudnia 2026 r. W tym samym miejscu wskazano również, że dla tych wersji systemów operacyjnych nie będą rozwijane nowe funkcjonalności.

Z kolei dokument Nowe funkcjonalności agenta dla systemów Windows wskazywał, które funkcjonalności są funkcjonalnościami nowymi, dodanymi w liniach 8.x/9.x i nieobecnymi w wersji 7.9.103-CE. Dokument ten wymieniał m.in.

Certificate Enforcement, ulepszony Local Analysis Engine dla Office/PDF, ML-based JScript Examination, Malicious LDAP Query Protection, natywne wsparcie ARM64, obsługę Windows 11 25H2, Enhanced BTP/AntiRansomware oraz Auto ACS Detection & Fallback.

Jednocześnie dokument 6b zawierał istotne pozytywne potwierdzenie zakresu ochrony, tj. wskazywał, że wersja agenta 7.9.103-CE zapewnia kompleksową ochronę przed złośliwym oprogramowaniem dla systemów, których wsparcie przez producenta zostało zakończone.

Z powyższego przykładu wynika, że dla Windows 7 Zamawiający mógł ustalić:

Tym samym przykład Windows 7 pokazuje, że z dokumentów załączonych do oferty można było ustalić zarówno zakres funkcjonalności detekcji i reakcji, jak i ograniczenia dla systemu EoL. Nie było konieczne powtarzanie tej samej informacji przy każdym wierszu tabeli, skoro ograniczenia wynikały z wersji agenta, a wersja agenta została wskazana w Compatibility Matrix. Analogiczny mechanizm odczytania informacji był możliwy również dla systemów z rodziny Linux. Jako przykład Odwołujący wskazuje CentOS 7. W wykazie obsługiwanych systemów operacyjnych wskazano system CentOS w wersji 7 oraz datę zakończenia wsparcia producenta: 30 czerwca 2024 r.

System ten należało zatem analizować jako system pozostający poza aktywnym wsparciem producenta.

Następnie z dokumentu Cortex XDR Compatibility Matrix można było ustalić, że CentOS 7 jest obsługiwany przez agenty Cortex XDR w wersjach 9.1, 9.0, 8.9, 8.8, 8.7-CE oraz 8.3-CE. W części dotyczącej Linux dokument zawierał także opis zakresu ochrony systemów Linux, wskazując, że agent Cortex XDR chroni serwery Linux przez zapobieganie uruchomieniu znanego i nieznanego złośliwego oprogramowania oraz przez blokowanie prób wykorzystania podatności w celu kompromitacji serwera.

Co istotne, dla systemów Linux dokument 6a pozwalał także zidentyfikować ograniczenia wprost z macierzy. Przykładowo dla wariantu CentOS 7.9 aarch64 Compatibility Matrix wskazuje obsługę przez agenta Cortex XDR, ale jednocześnie zawiera ograniczenie: „User mode agent not supported”.

W przypadku CentOS 7 wynik analizy był więc następujący:

Ten przykład jest szczególnie istotny, ponieważ dla systemu Linux ograniczenie nie wynikało wyłącznie z porównania wersji agentów, ale zostało wskazane wprost w tabeli Matrix. Pokazuje to, że twierdzenie Zamawiającego, jakoby dokumenty Odwołującego nie pozwalały na ustalenie funkcjonalności i ograniczeń, jest nieprawidłowe.

Odwołujący podkreśla przy tym, że wykaz obsługiwanych systemów operacyjnych został przygotowany według wzoru Zamawiającego. Odwołujący wypełnił ten wzór zgodnie z jego strukturą, wskazując nazwę systemu operacyjnego, wersję oraz datę zakończenia wsparcia producenta.

Odwołujący nie przebudowywał samodzielnie tabeli przygotowanej przez Zamawiającego, ponieważ była ona formularzem stanowiącym element dokumentów Zamówienia i wyznaczała oczekiwany sposób złożenia informacji ofertowej. Nie chodzi przy tym o twierdzenie, że przepisy PZP zawierają abstrakcyjny zakaz każdej modyfikacji formularza. Istotne jest to, że wykonawca działający z należytą starannością ma uzasadnione podstawy, aby zachować strukturę formularza przygotowanego przez Zamawiającego, zwłaszcza gdy formularz ten stanowi część dokumentów składanych wraz z ofertą.

Samodzielne rozbudowanie wzoru o dodatkowe kolumny, zmianę układu albo dopisanie obszernych opisów funkcjonalnych w samej tabeli mogłoby rodzić ryzyko zarzutu, że wykonawca ingeruje w formularz przygotowany przez Zamawiającego albo składa oświadczenie w formie odmiennej od oczekiwanej.

Dlatego też Odwołujący zachował układ tabeli Zamawiającego, natomiast informacje techniczne potrzebne

do odczytania zakresu funkcjonalności i ograniczeń przedstawił w dokumentach uzupełniających złożonych wraz z ofertą, tj. w załącznikach nr 6, 6a i 6b.

Jeżeli natomiast Zamawiający oczekiwał, aby przy każdym systemie EoL w samej tabeli znalazły się dodatkowe kolumny obejmujące osobno funkcjonalności detekcji, funkcjonalności reakcji oraz ograniczenia, powinien był taki układ przewidzieć wprost w OPZ albo we wzorze formularza. Zamawiający tego nie zrobił. Nie może więc po terminie składania ofert wywodzić negatywnych skutków z faktu, że wykonawca zachował strukturę tabeli przygotowaną przez Zamawiającego i opisał wymagane informacje w dokumentach technicznych powiązanych z wykazem.

W tym kontekście Odwołujący zaznacza, że Stinet postąpił w odwrotny sposób, tj. w tabeli „Wykaz obsługiwanych

przez system Crowdstrike Falcon XDR systemów operacyjnych” dodał kolumnę „Zakres funkcjonalności”. Co przy tym kluczowe, Stinet w żaden sposób nie opisał funkcjonalności oferowanych detekcji i reakcji oraz ograniczeń wynikających z zastosowanego rozwiązania, ograniczając się do lakonicznych stwierdzeń „Ochrona zgodna z OPZ” lub „Antywirus Następnej Generacji (NGAV)”. Stinet nie przedstawił również wraz z ofertą żadnych dodatkowych dokumentów, z których Zamawiający mógłby te informacje uzyskać. Tym samym w odróżnieniu od Odwołującego Stinet nie przedstawił informacji wymaganych przez Zamawiającego w pkt 1.14 i 1.15 OPZ. [Zarzut nr 3 – brak spełnienia wymagania określonego w pkt. 1.69 OPZ] Trzecią z podstaw odrzucenia oferty Odwołującego jest niezgodność z pkt 1.69 OPZ. Zamawiający swoją decyzję uzasadnił w następujący sposób:

Punkt 1.69 OPZ stanowi natomiast, że:

„System bezpieczeństwa musi zapewniać retencję danych telemetrycznych, logów oraz zdarzeń bezpieczeństwa przez okres co najmniej 24 miesięcy, z zachowaniem pełnej dostępności operacyjnej dla analityków SOC, umożliwiającej prowadzenie zapytań ad hoc, automatyczną korelację zdarzeń oraz rekonstrukcję osi czasu incydentów bezpieczeństwa.

Dane te muszą być przechowywane w architekturze hot/cold storage lub innej równoważnej architekturze warstwowej, w sposób zapewniający ich integralność, niezmienność oraz przydatność dowodową na potrzeby działań Incident Response i informatyki śledczej (DFIR).”

Wymaganie określone w pkt 1.69 OPZ odnosi się zatem do systemu bezpieczeństwa jako całości. Zamawiający wymagał zapewnienia retencji danych telemetrycznych, logów i zdarzeń bezpieczeństwa - czyli tych danych, które system gromadzi - przez okres 24 miesięcy w ramach całego oferowanego systemu. Punkt 1.69 OPZ nie statuuje przy tym wymogu identycznego zakresu surowej telemetrii z każdego typu urządzenia. Dla urządzeń mobilnych retencji podlega to, co technicznie da się pozyskać (alerty, incydenty, dane bezpieczeństwa) — i to jest retencjonowane przez co najmniej 24 miesiące.

Tymczasem ocena dokonana przez Zamawiającego została oparta nie na analizie całej architektury oferowanego rozwiązania, lecz na analizie pojedynczego komponentu licencyjnego.

Nadto, jak sam stwierdził z uzasadnieniu swojej decyzji Zamawiający, opierał się on wyłącznie na „domyślnych” parametrach licencji, nie biorąc pod uwagę możliwości jej zindywidualizowanej parametryzacji.

Stanowisko takie pozostaje sprzeczne nie tylko z treścią OPZ, ale równieżz wyjaśnieniami uzyskanymi przez samego Zamawiającego od Palo Alto. W odpowiedzi na pytanie: „Czy licencje oferowane dla urządzeń mobilnych zapewniają retencję danych telemetrycznych i zdarzeń bezpieczeństwa przez 24 miesiące, zgodnie z wymaganiem pkt 1.69 OPZ? Jeśli nie – jakie licencje uzupełniające są wymagane?” Zamawiający uzyskał od Palo Alto następującą odpowiedź:

„Producent potwierdza, że wymaganie pkt 1.69 OPZ dotyczące 24-miesięcznej retencji danych i zdarzeń bezpieczeństwa jest spełnione dla zaoferowanej konfiguracji systemu Cortex XDR.

Producent wskazuje jednocześnie, że zakres danych możliwych do pozyskania z urządzeń mobilnych z systemami Android oraz iOS/iPadOS różni się od zakresu danych dostępnych dla systemów desktopowych i serwerowych, co wynika z architektury bezpieczeństwa tych platform. Zarówno Apple, jak i Android stosują model bezpieczeństwa oparty na izolacji aplikacji (sandboxing) i ograniczonym dostępie aplikacji do zasobów systemowych, co wpływa na zakres telemetrii możliwej do pozyskania z urządzeń mobilnych. Apple wskazuje, że App Sandbox ogranicza dostęp aplikacji do zasobów i danych, natomiast Android opiera bezpieczeństwo aplikacji na Application Sandbox, w ramach którego aplikacje są izolowane od siebie i od systemu.

W konsekwencji dla urządzeń mobilnych nie występuje taki sam zakres surowej telemetrii jak dla klasycznych endpointów desktopowych i serwerowych. Jednocześnie wszystkie informacje możliwe do pozyskania z urządzeń mobilnych w architekturze producenta, w tym w szczególności alerty, incydenty oraz dane bezpieczeństwa dostępne dla tej klasy urządzeń, są rejestrowane i przetwarzane w ramach platformy Cortex XDR.

Producent potwierdza, że licencja mobilna w zaoferowanej konfiguracji zapewnia retencję alertów i zdarzeń bezpieczeństwa w podstawowym okresie przewidzianym przez platformę, przy czym publiczna dokumentacja producenta wskazuje, że domyślny okres retencji alertów w Cortex XDR wynosi 186 dni.

W celu zapewnienia zachowania danych bezpieczeństwa przez okres 24 miesięcy, zgodnie z wymaganiem pkt 1.69 OPZ, alerty, incydenty oraz pozostałe dane bezpieczeństwa dostępne dla urządzeń mobilnych są utrzymywane w ramach całościowej architektury Data Lake zaoferowanego systemu, z wykorzystaniem mechanizmu rozszerzonej retencji oraz zapisu do dedykowanego datasetu przeznaczonego do przechowywania tych informacji w wymaganym okresie.

Producent podkreśla również, że pkt 1.69 OPZ odnosi się do funkcjonalności systemu bezpieczeństwa jako całości i nie różnicuje wymagań retencyjnych według poszczególnych systemów operacyjnych. Wymaganie to należy zatem oceniać na poziomie całej zaoferowanej architektury Cortex XDR / Data Lake, a nie wyłącznie na poziomie pojedynczego SKU przypisanego do urządzeń mobilnych.

Producent potwierdza tym samym, że w zaoferowanej konfiguracji wymaganie 24miesięcznej retencji dla danych bezpieczeństwa związanych z urządzeniami mobilnymi jest spełnione.”

Producent jednoznacznie potwierdził zatem, że zaoferowana konfiguracja systemu Cortex XDR spełnia wymaganie określone w pkt 1.69 OPZ dotyczące 24-miesięcznej retencji danych i zdarzeń bezpieczeństwa. Wyjaśnił przy tym, że wymaganie retencji powinno być oceniane na poziomie całej architektury Data Lake oferowanego rozwiązania, a nie w odniesieniu do pojedynczego elementu licencyjnego. Pomimo uzyskania takiego stanowiska Zamawiający ograniczył jednak swoją ocenę wyłącznie do domyślnego okresu retencji jednego z komponentów systemu, co jest metodologicznie błędnym podejściem - nie uwzględnia bowiem specyfiki oferowanego rozwiązania. Dokonanie przez Zamawiającego oceny z pominięciem ww. stanowiska Palo Alto narusza obowiązek rzetelnego i należytego badania ofert oraz zasady przejrzystości (art. 16 PZP): decyzja o odrzuceniu musi bowiem uwzględniać całość materiału dowodowego dostępnego Zamawiającemu w chwili jej podejmowania, a nie wybiórczo ten fragment, który prowadzi do z góry przyjętej tezy. W okolicznościach niniejszej sprawy to właśnie producent – Palo Alto jest podstawowym źródłem wiedzy o własnym produkcie. Zamawiający zastąpił tę wiedzę własnym, laickim odczytaniem „domyślnego" parametru z publicznej dokumentacji, choć dysponował potwierdzeniem dotyczącym faktycznie zaoferowanej konfiguracji. Tym samym należy uznać, że oferta Odwołującego spełnia wymaganie określone w 1.69 OPZ i nie podlega odrzuceniu. [Zarzut nr 4 – ewentualny – zaniechanie wezwania Odwołującego do wyjaśnień] Na wypadek nieuwzględnienia zarzutów nr 1-3, skutkujących uznaniem, że oferta Odwołującego spełnia wymagania określone w pkt 1.10 - 1.12, 1.15 i 1.69 OPZ, Odwołujący stawia również zarzut ewentualny nr 4, którego istota sprowadza się do tego, że jeżeli Zamawiający miał jakiekolwiek wątpliwości co do spełnienia tych wymagań przez Odwołującego to przed odrzuceniem jego oferty winien zwrócić się do Odwołującego o wyjaśnienie treści oferty w trybie art. 223 ust. 1 PZP. Zgodnie z art. 223 ust. 1 PZP, w toku badania i oceny ofert Zamawiający może żądać od wykonawców wyjaśnień dotyczących treści złożonych ofert oraz przedmiotowych środków dowodowych lub innych składanych dokumentów lub oświadczeń. Choć przepis ten formalnie statuuje uprawnienie Zamawiającego, w utrwalonym

orzecznictwie przyjmuje się, że uprawnienie to przeradza się w obowiązek w sytuacji, w której zamawiający zamierza odrzucić ofertę jako niezgodną z warunkami zamówienia na podstawie art. 226 ust. 1 pkt 5 PZP.

Obowiązek ten wynika z ciążącej na Zamawiającym powinności rzetelnego i należytego przeprowadzenia postępowania o udzielenie Zamówienia (tak m.in. wyrok KIO z dnia 5września 2024 r., sygn. akt KIO 2828/24; wyrok KIO z 26 lutego 2024 r., sygn. akt KIO 636/24). Przekładając powyższe na grunt niniejszej sprawy należy zauważyć, że Zamawiający stanął przed następującą alternatywą: albo treść oferty Odwołującego nie budziła wątpliwości co do spełnienia wymagań OPZ — wówczas brak było jakichkolwiek podstaw do jej odrzucenia, albo treść ta wątpliwości takie budziła — a wtedy Zamawiający, działając z należytą starannością, zobowiązany był w pierwszej kolejności zwrócić się do Odwołującego o ich wyjaśnienie. Treść uzasadnienia decyzji o odrzuceniu jednoznacznie dowodzi, że Zamawiający w istocie powziął wątpliwości co do sposobu spełnienia wymagań OPZ, lecz rozstrzygnął je samodzielnie i na niekorzyść Odwołującego,

zamiast zwrócić się o ich wyjaśnienie. Zamawiający czynił bowiem własne ustalenia techniczne — opierając się na „dostępnej dokumentacji producenta" oraz na „domyślnych" parametrach licencji (w tym domyślnym okresie retencji wynoszącym 186 dni) — i na ich podstawie wywiódł niezgodność oferty z OPZ. Tymczasem ustalenia co do tego, w jaki sposób zaoferowane rozwiązanie realizuje wymagania OPZ, powinny były zostać poczynione na podstawie wyjaśnień podmiotu związanego treścią oferty, tj. Odwołującego, a nie w oparciu o samodzielne, niekorzystne dla wykonawcy domniemania Zamawiającego. Dobitnie potwierdza to sposób działania Zamawiającego w odniesieniu do pkt 1.10 – 1.12 i 1.69 OPZ. Zamawiający dostrzegł bowiem potrzebę wyjaśnienia spornych kwestii w takim stopniu, że zwrócił się o stanowisko do producenta oferowanego rozwiązania – Palo Alto. Skoro zatem Zamawiający sam uznał, że zagadnienia te wymagają wyjaśnienia, to tym bardziej zobowiązany był umożliwić wyjaśnienie sposobu spełnienia tych wymagań podmiotowi, który ofertę złożył i jest związany jej treścią. Zaniechanie wezwania Odwołującego doprowadziło w konsekwencji do tego, że Zamawiający — dysponując nawet potwierdzającym zgodność stanowiskiem producenta — oparł rozstrzygnięcie na własnych założeniach, z pominięciem rzeczywistego sposobu działania zaoferowanej architektury. Wbrew temu, co mógłby podnosić Zamawiający, wezwanie Odwołującego do wyjaśnień nie prowadziłoby przy tym do niedopuszczalnej zmiany treści oferty ani do negocjacji jej treści w rozumieniu art. 223 ust. 1 zdanie drugie PZP. W orzecznictwie i doktrynie ugruntowany jest bowiem pogląd, że wyjaśnienia treści oferty stanowią rodzaj wykładni oświadczenia woli wykonawcy. Przedmiotem oczekiwanych wyjaśnień byłoby więc wyłącznie wskazanie sposobu, w jaki rozwiązanie już zaoferowane przez Odwołującego realizuje wymagania OPZ, a nie jakakolwiek modyfikacja lub uzupełnienie zakresu czy przedmiotu świadczenia. Wyjaśnienia takie pozostawałyby zatem w pełni dopuszczalne. [Zarzut nr 5 – zaniechanie odrzucenia oferty Stinet z uwagi na niezgodność z warunkami Zamówienia] Zgodnie z pkt 2.5 OPZ opublikowanego pierwotnie w Postępowaniu:

„System XDR musi zapewniać możliwość instalacji agenta na urządzeniach końcowych pracujących pod kontrolą co najmniej następujących systemów operacyjnych:

Microsoft: a.Windows 7, 8, 8.1, 10 i 11 (x86_64 oraz arm64). b.Windows Server 2016, 2019, 2022, 2025. c.Windows Server Core 2016, 2019, 2022, 2025.

Linux a.CentOS 6, 7 i 8. b.Debian 9, 10, 11 i 12. c.Oracle Linux 6, 7, 8 i 9. d.Red Hat Enterprise Linux 7, 8, 9 i 10. e.Rocky Linux 8 i 9. f.SUSE 12 i 15, OpenSuse. g.Ubuntu 16, 18, 20, 22 i 24.

Apple macOS.

Apple iOS/iPadOS.

Android”.

Jak już wyjaśnił Odwołujący powyżej, zgodnie z pkt 1.14 OPZ wykonawca miał dołączyć wykaz obsługiwanych przez system XDR systemów operacyjnych wraz z wersjami oraz datami końca wsparcia producenta. Zgodnie natomiast z pkt 1.15 OPZ, dla systemów operacyjnych poza aktywnym wsparciem producenta, wykonawca miał opisać zakres funkcjonalności oferowanych detekcji i reakcji oraz ewentualne ograniczenia. W toku prowadzenia Postępowania Zamawiający dokonał zmian opisu przedmiotu Zamówienia, tj.: a.w dniu 23 stycznia 2026 r. opublikował archiwum „WYJAŚNIENIA TREŚCI SWZ ZESTAW 1-11.7z”, b.w dniu 20 lutego 2026 r. opublikował archiwum „2026.02.19_WYJAŚNIENIA_ZMIANA_SWZ.7z” oraz jednolity OPZ po zmianach, c.w dniu 24 lutego 2026 r. opublikował zmianę SWZ oraz Załącznik nr 7 do SWZ.

W pierwszej serii wyjaśnień Zamawiający jednoznacznie przesądził, że wykaz systemów operacyjnych ma zostać złożony na etapie składania ofert, jako element treści oferty, oraz że dokument ten powinien być arkuszem Excel. Stanowisko to zostało przedstawione w odpowiedzi na pytanie 1 w zestawie nr 3, opublikowanym w archiwum z dnia 23 stycznia 2026 r. (fragment poniżej).

Następnie, w odpowiedzi na pytanie 3 w zestawie nr 7, dotyczącym pkt 1.14 i 1.15 OPZ, Zamawiający potwierdził, że informacje o wspieranych systemach, ich wersjach, datach końca wsparcia producenta oraz ograniczeniach funkcjonalnych dla systemów EoL stanowią merytoryczną treść oferty, a nie jedynie środek dowodowy składany później.

Archiwum obejmujące ten dokument zostało opublikowane 23 stycznia 2026 r. (fragment poniżej).

W odpowiedzi na pytanie 12 w zestawie nr 7, dotyczące pkt 2.5.1–2.5.6 OPZ(również opublikowanej w dniu 23 stycznia 2026 r.), Zamawiający wskazał ponadto, że: a.nie uzna oferty, która nie obejmuje ochroną systemów operacyjnych wyszczególnionych w pkt 2.5 OPZ, także systemów EoL, b.wymaga dostarczenia agenta instalowalnego na wskazanych systemach EoL i komunikującego się z konsolą, c.dopuszcza różnice funkcjonalne dla systemów EoL, ale wymagany jest ich rzetelny opis zgodnie z pkt 1.15 OPZ.

Szczególnie istotna jest odpowiedź na pytanie 6 w zestawie nr 9 (opublikowanym w dniu 23 stycznia 2026 r. – istotne fragmenty poniżej), w której Zamawiający: a.odmówił zawężenia listy systemów Windows i Linux, b.potwierdził konieczność objęcia ochroną systemów EoL, c.oraz doprecyzował minima dla platform Apple i mobilnych, wskazując, że oczekuje wsparcia dla: i.Apple macOS: wersja 12 i nowsze, ii. Apple iOS/iPadOS: wersja 15 i nowsze, iii.Android: wersja 10 i nowsze.

W późniejszej serii wyjaśnień, opublikowanej 20 lutego 2026 r., Zamawiający zmienił pkt 2.5 OPZ, odchodząc od enumeratywnej listy wersji na rzecz kategorii platform. Nastąpiło to m.in. w odpowiedziach na pytanie nr 3 w zestawie nr 3 oraz pytanie nr 3 w zestawie nr 5. Jednocześnie Zamawiający utrzymał obowiązek ochrony systemów niewspieranych przez producentów oraz wprost wskazał, że dla takich systemów wykonawca ma dostarczyć rozwiązania umożliwiające ich ochronę, przy dopuszczeniu ograniczonej funkcjonalności oraz obowiązku opisania tych ograniczeń w ofercie. Co

istotne, Zamawiający nigdzie nie wskazał, aby przy tej zmianie uchylał wcześniejsze doprecyzowanie minimalnych wersji dla Apple/mobile.

W ocenie Odwołującego, ostatnie odpowiedzi dotyczące pkt 2.5 OPZ miały charakter redakcyjnego uogólnienia wymagania, nie zaś ich ograniczenia. W efekcie, przywołane postanowienia OPZ-u oznaczają, że Zamawiający nie zrezygnował z wymogu kompatybilności dostarczanych przez wykonawcę systemów z konkretnymi wersjami systemów operacyjnych funkcjonujących po stronie Zamawiającego wymienionych w OPZ, w szczególności z systemami macOS, iOS/iPadOS, Android.

W ocenie Odwołującego powyższa okoliczność jest oczywista z tego powodu, że przedmiotem Postępowania jest dostawa i wdrożenie u Zamawiającego systemu bezpieczeństwa, mającego na celu zapewnienie kompleksowej ochrony zasobów teleinformatycznych Urzędu Miasta Stołecznego Warszawy. W związku z powyższym jedyną możliwą interpretacją OPZ oraz odpowiedzi udzielonych przez Zamawiającego na pytania wykonawców jest ta, w której wymóg dostarczenia systemów XDR/NDR dla ściśle określonych wersji systemów operacyjnych (wymienionych w pierwotnym brzmieniu oraz w odpowiedzi na pytanie nr 6 w zestawie nr 9) jest aktualny. Niedopuszczalna jest z kolei interpretacja, opierająca się na założeniu konieczności dostarczenia rozwiązania wspierającego jakąkolwiek wersję w ramach klasy systemu operacyjnego (np. jakiegokolwiek wydania systemu Windows), ale nie jego konkretnej, oczekiwanej przez Zamawiającego, wersji (np. Windows 10), ponieważ w takiej sytuacji istnieje ryzyko, że Zamawiający nie otrzyma rozwiązania, które zaspokoi jego realne potrzeby w tym zakresie, a w dalszej kolejności – że zasoby teleinformatyczne

Zamawiającego nie będą skutecznie chronione.

Należy zwrócić uwagę, że wykonawcy nie mogą w powyższym zakresie zasłaniać się literalnym brzmieniem ostatnich odpowiedzi udzielonych przez Zamawiającego i przyjmować, że oferta jest zgodna z warunkami Zamówienia, jeżeli przewiduje dostawę i wdrożenie oprogramowania zgodnego z pewną częścią klas systemów operacyjnych wymienionych w odpowiedziach udzielonych przez Zamawiającego, ale już nie w zakresie konkretnych wersji, o których Zamawiający wspominał w trakcie Postępowania. Należy pamiętać, że w postępowaniu biorą udział podmioty profesjonalne, posiadające doświadczenie i wiedzę w zakresie przedmiotu Zamówienia. Zamawiający ma prawo domniemywać, iż wykonawcy, decydujący się wziąć udział w przetargu, będą analizować dokumentację przetargową, uwzględniać wszystkie jej zmiany i ich kontekst, posiadając odpowiednią wiedzę i doświadczenie, jakie przypisać można profesjonaliście działającemu w danej branży /Por. wyrok KIO z dnia 3 października 2019 r., sygn. KIO 1861/19/. [Treść oferty Stinet] Z formularza ofertowego wynika, że Stinet zaoferował jako system XDR rozwiązanie CrowdStrike Falcon XDR.

Z tej samej oferty wynika, że wykaz systemów operacyjnych został złożony jako załącznik nr 12 pod nazwą „Wykaz obsługiwanych przez system XDR systemów operacyjnych-sig.pdf”, a zatem w formacie PDF, nie zaś jako arkusz Excel.

W złożonym przez Stinet wykazie systemów operacyjnych wskazano dla platform Apple/mobile wyłącznie: •macOS 14, 15, 26, •iOS 17, 18, 26, •Android 11, 12, 13, 14, 15, 16.

W wykazie tym nie wskazano zatem: •macOS 12, •macOS 13, •iOS 15, •iOS 16, •Android 10, mimo że wcześniejsze doprecyzowanie Zamawiającego obejmowało właśnie te wersje jako minimalny zakres dla Apple/mobile. [Istota niezgodności oferty Stinet z warunkami Zamówienia] W ocenie Odwołującego, przedstawione powyżej okoliczności rodzą co najmniej trzy implikacje. Po pierwsze, oferta Stinet nie została złożona zgodnie z wymaganiem co do formy wykazu systemów operacyjnych, ponieważ Zamawiający wymagał arkusza Excel, a Stinet złożył PDF. Wymóg ten nie był incydentalny, lecz został wyraźnie wskazany przez Zamawiającego przy określaniu sposobu złożenia wykazu już na etapie ofertowym. Po drugie, wykaz systemów złożony przez Stinet nie potwierdza objęcia wsparciem co najmniej wszystkich wersji systemów Apple/mobile, które Zamawiający wcześniej formalnie doprecyzował jako objęte wymaganiem, tj. macOS 12 i nowszych, iOS/iPadOS 15 i nowszych oraz Android 10 i nowszych. Po trzecie, nie można przyjąć, że wskazanie w wykazie wyłącznie wersji nowszych automatycznie potwierdza wsparcie dla wersji wcześniejszych. Gdyby taka wykładnia była dopuszczalna, wymaganie złożenia szczegółowego wykazu wersji i dat End of Support byłoby pozbawione sensu. Zamawiający żądał tego dokumentu właśnie po to, aby ustalić, jakie konkretne systemy i wersje są objęte ofertą oraz jaki jest zakres ochrony dla platform EoL. Każda z tych implikacji oznacza, że oferta złożona przez Stinet jest niezgodna z warunkami Zamówienia. Zgodnie z art. 226 ust. 1 pkt 5 PZP, Zamawiający odrzuca ofertę, jeżeli jej treść jest niezgodna z warunkami zamówienia. Jak podkreśla się w orzecznictwie KIO, niezgodność z warunkami zamówienia może mieć dwojaki charakter: a.po pierwsze, jest to niezgodność o charakterze merytorycznym, która uprawnia zamawiającego do odrzucenia oferty, jeżeli możliwe jest uchwycenie określonej niezgodności pomiędzy ofertą wykonawcy lub jego określonym oświadczeniem (informacją) a warunkami zamówienia, które zostały skonkretyzowane, skwantyfikowane i jednoznacznie ustalone przez zamawiającego lub wynikają z przepisu prawa, który zgodnie z wolą zamawiającego lub z mocy praw stosuje się do wykonawcy / Np. wyrok z dnia 28 lutego 2025 r., sygn. KIO 473/25; wyrok z dnia 24 lutego 2025 r., sygn. KIO 164/25, wyrok z dnia 14 lutego 2025 r., sygn. KIO 154/25/; b.po drugie, jest to niezgodność polegająca na sporządzeniu o przedstawieniu oferty w inny sposób, niż żądał tego zamawiający /Np. wyrok z dnia 10 listopada 2017 r., sygn. KIO 2230/17/.

Oba wymienione aspekty znajdują swoje odzwierciedlenie w ofercie Stinet – z jednej strony Stinet sporządził ofertę w formie niezgodnej z SW Z, a z drugiej – nie zaoferował rozwiązania, które oferuje wsparcie dla systemów jasno określonych przez Zamawiającego. Powyższe okoliczności świadczą o niezgodności oferty Stinet z warunkami Zamówienia, które obligują Zamawiającego do odrzucenia oferty. [Zarzut nr 6 - unieważnienie Postępowania] Zarzut nr 6 jest zarzutem wynikowym w stosunku do pozostałych zarzutów niniejszego odwołania. Skoro bowiem – jak zostało to wykazane w niniejszym odwołaniu – oferta Odwołującego nie podlegała odrzuceniu to konsekwentnie Zamawiający nie miał podstaw do unieważnienia Postępowania na podstawie art. 255 pkt 2 PZP, zgodnie z którym „Zamawiający unieważnia postępowanie o udzielenie zamówienia, jeżeli wszystkie złożone wnioski o dopuszczenie do udziału w postępowaniu albo oferty podlegały odrzuceniu.” Decyzja o unieważnieniu Postępowanie w sytuacji, w której oferta Odwołującego nie podlega odrzuceniu skutkuje więc naruszeniem art. 255 pkt 2 PZP.

Zamawiający w dniu 08.06.2026 r. wezwał (za pomocą środków komunikacji elektronicznej) wraz kopią odwołania, w trybie art. 524 NPzp, uczestników postępowania przetargowego do wzięcia udziału w postępowaniu odwoławczym.

W dniu 11.06.2026 r. (wpływ do Prezesa KIO w wersji elektronicznej podpisane podpisem cyfrowym za pośrednictwem elektronicznej skrzynki podawczej - ePUAP)zgłosił Stinet Sp. z o.o. przystąpienie do postępowania odwoławczego po stronie Zamawiającego wnosząc o oddalenie odwołania w całości. Kopia zgłoszenia została przekazana Zamawiającemu oraz Odwołującemu. Izba uznała skuteczność przystąpienia do postępowania odwoławczego po stronie Zamawiającego: Stinet Sp. z o.o.

Odwołanie w sprawie o sygn. akt: KIO 2716/26:

W dniu 05.06.2026 r. (przez dostawcę usługi e-Doręczenia) Stinet Sp. z o.o. wniósł odwołanie na czynność z 26.05.2026 r. ZARZUTY:

Odwołujący zarzucił Zamawiającemu, że naruszono:

1. art. 226 ust. 1 pkt 8) Pzp w zw. z art. 224 ust. 6 Pzp w zw. z art. 239 Pzp i z art. 16 pkt 1 Pzp oraz art. 17 ust. 2 Pzp poprzez bezpodstawne odrzucenie oferty Odwołującego w wyniku uznania, że zawiera ona rażąco niską cenę w stosunku do przedmiotu zamówienia, a także, że wyjaśnienia złożone przez Odwołującego są nierzetelne i nie odpowiadają treści wezwania Zamawiającego, a w konsekwencji brak wyboru oferty, która jest najkorzystniejsza,
2. art. 226 ust. 1 pkt 5 Pzp w zw. z art. 16 pkt 1 – 3 Pzp poprzez bezpodstawne odrzucenie oferty Odwołującego w wyniku uznania, że jest ona niezgodna z warunkami zamówienia z uwagi na to, że Odwołujący rzekomo nie spełnił wymagań z pkt 1.15 OPZ tj. nie wskazał opisu funkcjonalności oferowanych detekcji i reakcji oraz ograniczeń wynikających z zastosowanego rozwiązania, w sytuacji, gdy Odwołujący w „Wykazie obsługiwanych przez system CrowdStrike Falcon XDR systemów operacyjnych” przy systemach operacyjnych, które są poza aktywnym wsparciem producenta (EoL), wskazał „Antywirus Następnej Generacji (NGAV)”, co jest powszechnie rozumianym pojęciem technologicznym w branży cyberbezpieczeństwa, opisującym zbiorczo zakres funkcjonalności oferowanych detekcji i reakcji oraz jednocześnie wskazującym ograniczenia zakresu ochrony względem pełnego XDR,
3. ewentualnie, w przypadku nieuwzględnienia zarzutu z pkt 2 - art. 223 ust. 1 Pzp poprzez zaniechanie wezwania Odwołującego do złożenia wyjaśnień dotyczących treści złożonej oferty tj. „Wykazu obsługiwanych przez system CrowdStrike Falcon XDR systemów operacyjnych”w zakresie użytego przez Odwołującego określenia „Antywirus

Następnej Generacji (NGAV)” jako zbiorczego opisu zakres funkcjonalności oferowanych detekcji i reakcji oraz wskazania ograniczeń zakresu ochrony,

1. art. 253 ust. 1 pkt 2 Pzp w zw. z art. 226 ust. 1 pkt 5 Pzp w zw. z art. 16 pkt 1 – 3 Pzp poprzez niewskazanie wszystkich okoliczności faktycznych, jakie świadczą o niezgodności oferty INTEGRITY PARTNERS sp. z o.o. z siedzibą w Warszawie (dalej jako: „Integrity” lub „Wykonawca”) z warunkami zamówienia, tj. niewskazanie w piśmie informującym o przyczynach odrzucenia oferty Integrity, że oferta tego wykonawcy jest niezgodna z warunkami zamówienia również w zakresie: a. niezapewnienia wymaganej 24-miesięcznej retencji danych telemetrycznych, logów oraz zdarzeń bezpieczeństwa w Data Lake (NGSIEM / third-party data) na skutek zaoferowania niewystarczającej liczby licencji na przechowywanie danych w Data Lake (NGSIEM / third-party data) – 48000 zamiast 48300, (ust. IX pkt 8 – 15 odwołania), b. braku zaoferowania wymaganego poziomu wsparcia producenta w zakresie czasu reakcji na zgłoszenia serwisowe zgodnie z pkt 14.1.2 (ust. IX pkt 16 – 32 odwołania), c. braku zaoferowania wymaganego dedykowanego wsparcia eksperckiego producenta (w tym opiekuna technicznego) zgodnie z pkt 14.1.3 OPZ, (ust. IX pkt 33- 35 odwołania), d. niezaoferowania wymaganej dostępności modułu analizy śledczej (Forensic) dla 100% chronionych serwerów i stacji roboczych, (ust. IX pkt 36 - 43 odwołania), e. brak zapewnienie funkcjonalności multi-tenant, (ust. IX pkt 16 - odwołania), (ust. IX pkt 44 – 49 odwołania) f. niespójności licencyjna w zakresie retencji danych endpointowych i urządzeń mobilnych – nieobjęcie 3000 urządzeń retencją danych telemetrycznych (ust. IX pkt 50 - 68 odwołania), gdy tymczasem również z ww. powodów oferta podlega odrzuceniu; a w konsekwencji
2. art. 255 pkt 2 Pzp poprzez unieważnienie postępowania w sytuacji, gdy nie zaistniały ku temu przesłanki tj. nie wszystkie oferty polegają odrzuceniu. IV. ŻĄDANIA Odwołujący wnosi o uwzględnienie odwołania i nakazanie Zamawiającemu:
3. unieważnienia czynności unieważnienia postępowania;
4. powtórzenia czynności badania i oceny ofert z uwzględnieniem zarzutów postawionych w odwołaniu, a w ramach tego unieważnienie czynności odrzucenia oferty Odwołującego oraz uzupełnienie informacji o odrzuceniu oferty Integrity o wszystkie okoliczności, jakie wskazują na spełnienie przesłanek do odrzucenia oferty Integrity, a które zostały opisane w odwołaniu,
5. wybór oferty Odwołującego jako najkorzystniejszej w Postępowaniu.

Stan faktyczny.

1. Zamawiający prowadzi postępowanie, którego przedmiotem jest dostawa i wdrożenie systemów klasy XDR i NDR na okres 36 miesięcy.
2. W Postępowaniu złożono dwie oferty: Odwołującego (Stinet sp. z o.o.) oraz INTEGRITY PARTNERS p. z o.o.
3. Pismem z dnia 27 kwietnia 2026 r. Zamawiający poinformował o odrzuceniu oferty Odwołującego na podstawie art. 226 ust. 1 pkt 8 w zw. z art. 224 ust. 6 Pzp oraz o wyborze jako najkorzystniejszej oferty złożonej przez Integrity.
4. W dniu 7 maja 2026 r. Odwołujący złożył odwołanie, którym zakwestionował czynności Zamawiającego z dnia 27 kwietnia 2026 r. zarzucając Zamawiającemu naruszenie:
5. art. 226 ust. 1 pkt 8) Pzp w związku z art. 224 ust. 6 Pzp w zw. z art. 239 Pzp i z art. 16 pkt 1 Pzp oraz art. 17 ust. 2 Pzp poprzez bezpodstawne odrzucenie oferty Odwołującego w wyniku uznania, że zawiera ona rażąco niską cenę w stosunku do przedmiotu zamówienia, a także, że wyjaśnienia złożone przez Odwołującego są nierzetelne i nie odpowiadają treści wezwania Zamawiającego, a w konsekwencji brak wyboru oferty, która jest najkorzystniejsza,
6. art. 226 ust. 1 pkt 5 Pzp w zw. z art. 16 pkt 1 – 3 Pzp w zw. z art. 239 i art. 17 ust. 2 Pzp poprzez zaniechanie odrzucenia oferty złożonej przez INTEGRITY PARTNERS sp. z o.o. z siedzibą w Warszawie (dalej jako: „Integrity” lub „Wykonawca”), pomimo że jest ona niezgodna z warunkami zamówienia w zakresie: a.niezapewnienia wymaganej 24-miesięcznej retencji danych telemetrycznych, logów oraz zdarzeń bezpieczeństwa w Data Lake (NGSIEM / third-party data) na skutek zaoferowania niewystarczającej liczby licencji na przechowywanie danych w Data Lake (NGSIEM / third-party data) – 48000 zamiast 48300, (ust. IX pkt 8 – 15 odwołania), b. braku zaoferowania wymaganego poziomu wsparcia producenta w zakresie czasu reakcji na zgłoszenia serwisowe zgodnie z pkt 14.1.2 (ust. IX pkt 16 – 32 odwołania), c. braku zaoferowania wymaganego dedykowanego wsparcia eksperckiego producenta (w tym opiekuna technicznego) zgodnie z pkt 14.1.3 OPZ, (ust. IX pkt 33- 35 odwołania), d. niezaoferowania wymaganej dostępności modułu analizy śledczej (Forensic) dla 100% chronionych serwerów i stacji roboczych, (ust. IX pkt 36 - 43 odwołania), e.niezaoferowania funkcji EDR/XDR i możliwości zbierania telemetrii dla wszystkich urządzeń końcowych, (ust. IX pkt 44 – 53 odwołania), f.zastosowania licencji Cortex XDR Prevent (PAN-XDR-PRVT) które uniemożliwiają przechowywania danych przez okres co najmniej 24 miesięcy dla wszystkich chronionych urządzeń, (ust. IX pkt 54 – 61 odwołania), g.brak zapewnienie funkcjonalności multi-tenant, (ust. IX pkt 16 - odwołania), (ust. IX pkt 61 – 67 odwołania) h.niespójności licencyjna w zakresie retencji danych endpointowych i urządzeń mobilnych – nieobjęcie 3000 urządzeń retencją danych telemetrycznych (ust. IX pkt 68 - 86 odwołania), i.w jakim Integrity nie dołączył do oferty zestawienia zawierającego opis zakresu funkcjonalności oferowanych detekcji i reakcji oraz ewentualnych ograniczeń (ust. IX pkt 87 – 89 odwołania), a w konsekwencji dokonanie wyboru jako najkorzystniejszej oferty, w stosunku do której zachodzą przesłanki odrzucenia.

Odwołujący wnosił o:

1. unieważnienia czynności wyboru oferty najkorzystniejszej;
2. ponowienia czynności badania i oceny ofert z uwzględnieniem zarzutów postawionych w odwołaniu, a w ramach tego unieważnienie czynności odrzucenia oferty Odwołującego oraz odrzucenie oferty Integrity,
3. ponowienia czynności wyboru oferty najkorzystniejszej w Postępowaniu.
4. W dniu 26 maja 2026 r. Zamawiający opublikował na platformie, na której prowadzi postępowanie informację o:
5. unieważnieniu czynności wyboru oferty najkorzystniejszej oraz powtórzeniu czynności badania i oceny ofert,
6. unieważnieniu postępowania – „Zamawiający po powtórzeniu czynności badania i oceny ofert w przedmiotowym postępowaniu zawiadamia o unieważnieniu postępowania o udzielenie zamówienia ponieważ wszystkie złożone oferty podlegają odrzuceniu.”
7. odrzuceniu ofert obu wykonawców.
8. Ponadto w dniu 27 maja 2026 r. Zamawiający złożył odpowiedź na odwołanie (w sprawie o sygn. akt: KIO 2189/26), w którym wskazał: „W wyniku ponownej analizy dokumentacji Postępowania Zamawiający dostrzegł potrzebę powtórzenia czynności podjętych w Postępowaniu. Kierując się względami ekonomiki postępowania Zamawiający doszedł do przekonania, że zaistniałe w sprawie okoliczności prawne oraz faktyczne przemawiają za uwzględnieniem w całości zarzutów przedstawionych w odwołaniu.”

Jednocześnie Zamawiający wniósł o umorzenie postępowania odwoławczego.

Zamawiający uwzględnił więc poprzednie odwołanie w całości. Mimo to nie wykonał czynności zgodnie z żądaniami przedstawionymi przez Odwołującego w treści tego odwołania (odwołania, ws. KIO 2189/26 które uwzględnił).

Z opisanego powyżej schematu działania Zamawiającego wynika, że: a. Zamawiający uwzględnił odwołanie ws. KIO 2189/26 w całości (zarówno w zakresie zarzutów dot. niezasadnego odrzucenia oferty Stinet, jak i zaniechania odrzucenia oferty Integrity), b. Zamawiający powtórzył czynność badania i oceny obu oferty w wyniku czego: - pomimo uwzględnienia odwołania ws. KIO 2189/26 w całości odrzucił ofertę Odwołującego ponownie z uwagi na rażąco

niską cenę oraz dodatkowo z uwagi na niezgodność z warunkami zamówienia, - odrzucił ofertę Integrity z uwagi na niezgodność z warunkami zamówienia (wyłącznie na podstawie części nieprawidłowości sygnalizowanych przez Odwołującego w pierwszym odwołaniu - sygn. akt. KIO 2189/26), - unieważnił postępowanie.

W ocenie Odwołującego Zamawiający dopuścił się naruszenia przepisów Pzp.

Odrzucenie oferty Odwołującego – rażąco niska cena.

1. Istotne jest, że zarzut ten został już przez Odwołującego sformułowany w odwołaniu z dnia 7 maja 2026 r. (sprawa o sygn. akt 2189/26) i Zamawiający dokonał jego uwzględnienia (Zamawiający uwzględnił odwołanie w całości, a więc również ten zarzut).
2. Odrzucenie oferty Stinet jako zawierającej rażąco niską cenę jest wadliwe.
3. Pismem z dnia 13 marca 2026 r. Zamawiający wezwał Odwołującego do złożenia wyjaśnień w zakresie wyliczenia istotnych części składowych ceny oferty, tj.: ceny za świadczenie Asysty Wykonawcy zgodnie z pkt 4.1.3 wzoru umowy oraz ceny za świadczenie usługi Wsparcia Eksperckiego zgodnie z pkt 4.1.4 wzoru umowy. Zamawiający wskazał w wezwaniu, że „Zaoferowane przez Państwa ceny brutto za wykonanie usług wskazanych powyżej wydają się rażąco niskie, odbiegają istotnie od poziomu szacunku Zamawiającego powiększonego o wartość VAT dla tych cen.” Pomimo wniosku Odwołującego do dnia wniesienia odwołania Zamawiający nie udostępnił jednak Odwołującemu informacji dotyczących szacowania wartości zamówienia, wobec tego nie umożliwił Odwołującemu weryfikacji czy wskazana rozbieżność faktycznie występuje.
4. Wezwanie do wyjaśnienia ceny zostało skierowane również do Integrity.
5. W dniu 20 marca 2026 r. Odwołujący złożył szczegółowe wyjaśnienia (dalej: „Wyjaśnienia RNC"), poparte kalkulacją kosztów i dowodami (fakturami, certyfikatami, referencjami, wydrukami z portalu wynagrodzeń).
6. Zamawiający uznał jednak, że „cena oferty Odwołującego w zakresie dla usług Asysty Wykonawcy i usług Wsparcia Eksperckiego jest rażąco niska, a złożone wyjaśnienia nie mogły zostać uznane za rzetelne i odpowiadające treści wezwania Zamawiającego”. Jednocześnie w uzasadnieniu odrzucenia oferty Stinet Zamawiający nie wskazał, w jakim konkretnie zakresie złożone wyjaśnienia RNC miałyby nie odpowiadać treści wezwania.
7. Zasadniczo Zamawiający ograniczył się do: a. zakwestionowania przyjętej przez Stinet pracochłonności Asysty technicznej oraz sposobu jej oszacowania, b. zarzutu niewskazania, która z osób dedykowanych do realizacji zamówienia jest osobą „mniej doświadczoną”, a która „bardziej doświadczoną”, c. zakwestionowania miesięcznego nakładu pracy poszczególnych grup osób, d. zakwestionowania dowodów dołączonych do wyjaśnień – w szczególności faktur potwierdzających przyjęte w kalkulacji stawki oraz rzekomego braku uzasadnienia „rynkowości” tych stawek.
8. Odnosząc się do argumentów przedstawionych w uzasadnieniu odrzucenia oferty Stinet Odwołujący wskazuje na następujące kwestie.
9. Charakter i zakres poprzedniej umowy z 2025 r. a. W uzasadnieniu odrzucenia Zamawiający wskazał, że Wskazane w wyjaśnieniach Stinet Sp. z o.o. „wieloletnie doświadczenie w obsłudze Zamawiającego” w rzeczywistości nie jest adekwatne do przedmiotowego zamówienia.

Poprzednie umowy realizowane przez Stinet sp. z o.o. dotyczyły wdrożenia i utrzymania jednego produktu – rozwiązania klasy EDR/AV starszej generacji (Trellix) wraz szyfrowaniem dysków. Były to produkty o ograniczonej funkcjonalności, dobrze rozpoznanej architekturze i niskim poziomie automatyzacji, wymagające głównie ręcznej obsługi, przy małych nakładach godzinowych. Tymczasem przedmiot niniejszego zamówienia jest nieporównywalnie szerszy i bardziej złożony.” (str. 2,3 z 7 Informacji o wyborze oferty najkorzystniejszej). Zamawiający zamieścił również „Porównanie zakresów umowy z 2025 (Trellix) i obecnej”. b. Taka charakterystyka poprzedniej umowy jest co najmniej niepełna, ponieważ umowa z 2025 r. obejmowała znacznie szerszy zakres, w tym w szczególności: Trellix ATD-3200 / Advanced Threat Defense (sandbox), Trellix MVISION Protect Plus (ochrona endpointów), Trellix Protect Plus EDR for Endpoint (EDR), Trellix Complete Data Protection (ochrona danych / DLP / szyfrowanie), Trellix Endpoint Security Storage Protection (ochrona storage / plików), dostęp do chmury producenta w UE, Zgłoszenia Serwisowe, Zlecenia Serwisowe, Audyt Systemu. c. Nie było to zatem proste środowisko jednego produktu antywirusowego, lecz wielokomponentowe środowisko bezpieczeństwa wymagające bieżącej obsługi, aktualizacji, konfiguracji, reakcji na podatności, obsługi problemów eksploatacyjnych, przeglądów oraz prac zleceniowych. d. Skoro Zamawiający twierdzi, że poprzednie rozwiązania miały niższy poziom automatyzacji i wymagały głównie ręcznej obsługi, to doświadczenie Stinet z ich utrzymania tym bardziej potwierdza praktyczne kompetencje i znajomość realnej pracochłonności usług wsparcia. Obsługa środowiska mniej zautomatyzowanego zasadniczo wymaga większego udziału pracy inżynierskiej niż obsługa będących przedmiotem Postępowania nowoczesnych rozwiązań z istotnym udziałem automatyzacji i wymaganego w tym postępowaniu dedykowanego wsparcia inżyniera producenta oferowanego rozwiązania. Zamawiający formułuje więc w tym zakresie nielogiczny wniosek – niski poziom automatyzacji i konieczność ręcznej obsługi systemu objętego umową z 2025 r. generują większą pracochłonność niż obsługa nowoczesnych, zautomatyzowanych i wspieranych przez producentów rozwiązań. Tym samym doświadczenie Stinet w realizacji poprzedniej umowy nie jest nieadekwatne, lecz stanowi racjonalną podstawę do oszacowania pracochłonności obecnej Asysty. e. Doświadczenie Stinet w realizacji poprzedniej umowy stanowi więc racjonalną podstawę do oszacowania pracochłonności obecnej Asysty, a nie okoliczność wyłączającą możliwość odwołania się do tej praktyki.

Zgłoszenia Serwisowe 2025 r. a obecna Asysta techniczna. a. W umowie z 2025 r. Zgłoszenia Serwisowe obejmowały w szczególności: usunięcie awarii albo problemu w działaniu Systemu niebędącego awarią, reakcję na zdiagnozowane podatności Systemu, obsługę zagadnień technicznych związanych z eksploatacją Systemu, aktualizacje oprogramowania i sprzętu Producenta Systemu wraz z konfiguracją lub rekonfiguracją, obsługę działań po aktualizacji Systemu, profilaktykę i przegląd Systemu, pomoc w zwalczaniu złośliwego oprogramowania, dostarczanie szczepionek osób trzecich na wykryte złośliwe oprogramowanie. b. Wiele z tych czynności odpowiada rdzeniowi obecnej Asysty technicznej albo jest funkcjonalnie zbliżonych do jej elementów, tj.: rozwiązywania problemów technicznych, aktualizacji i rekonfiguracji, reakcji na podatności, przeglądów i działań po aktualizacji, czynności helpdeskowych i troubleshootingu, konsultacji oraz bieżącej eksploatacji systemu bezpieczeństwa. c. Nie można zatem twierdzić, że obecna Asysta jest dla Stinet zakresem nowym, nieznanym albo nieporównywalnym z wcześniejszym doświadczeniem. Tym samym własne porównanie Zamawiającego przeczy tezie, że doświadczenie Stinet z 2025 r. nie ma istotnego znaczenia. d. Zamawiający wskazał, że obecny zakres jest o 70% większy. Nie przedstawił jednak żadnej metodologii ani kalkulacji wyliczenia tej różnicy. Nie wiadomo, czy chodzi o liczbę punktów OPZ, liczbę systemów, liczbę endpointów, wartość zamówienia, liczbę czynności czy rzeczywistą pracochłonność. Takie twierdzenie ma charakter arbitralny, nieudowodniony i nie może być podstawą odrzucenia oferty.

Wadliwość porównań i założeń przyjętych przez Zamawiającego a. Zamawiający porównuje Zgłoszenia Serwisowe wynikające z umowy z 2025 r. z pełnym katalogiem Asysty wymaganej w Postępowaniu, pomijając inne elementy poprzedniej umowy, w szczególności Zlecenia Serwisowe i Audyt Systemu. Tak skonstruowane porównanie jest metodologicznie wadliwe. b. Część obecnych obowiązków Asysty albo Wsparcia Eksperckiego odpowiada bowiem wcześniejszym Zleceniom Serwisowym lub Audytowi Systemu, które obejmowały m.in.: prace utrzymaniowe, prace rozwojowe i projektowe, prace implementacyjne, testowanie nowych funkcjonalności i oprogramowania producenta, inżynierię odwrotną, comiesięczne sprawdzenie systemu pod kątem bezpieczeństwa i wydajności oraz przygotowanie raportu z zaleceniami.

Dodatkowe elementy poprzedniej umowy, których obecnie brak. a. Zamawiający pomija, że poprzednia umowa obejmowała elementy, których obecna dokumentacja nie przewiduje w analogicznym kształcie albo które obecnie zostały przeniesione na producenta lub do Wsparcia Eksperckiego, w szczególności: - comiesięczny audyt/przegląd Systemu z pisemnym raportem – w umowie z 2025 r. Stinet realizował audyt lub przegląd co miesiąc, obejmujący weryfikację konfiguracji, bezpieczeństwa i wydajności oraz przedstawienie wniosków i zaleceń zmian lub rekonfiguracji; obecny OPZ przewiduje jedynie przegląd po wdrożeniu oraz przeglądy co pół roku, - dostarczanie szczepionek osób trzecich na wykryte złośliwe oprogramowanie – obowiązek ten występował wprost w umowie z 2025 r. jako element Zgłoszeń Serwisowych, natomiast w obecnym OPZ i wzorze umowy brak analogicznego obowiązku po stronie Wykonawcy; obecnie aktualizacje detekcji, sygnatur, reguł, reputacji i mitygacji zapewniają w istotnym zakresie producenci oferowanych systemów w ramach subskrypcji i Wsparcia Producenta, - wymogi kadrowe dotyczące certyfikowanych inżynierów – umowa z 2025 r. przewidywała, że wszystkie osoby realizujące po stronie Wykonawcy Zgłoszenia Serwisowe i Zlecenia Serwisowe muszą posiadać certyfikat Producenta Systemu uzyskany w oficjalnym ośrodku szkoleniowym producenta; dodatkowo Zlecenie Serwisowe miało być realizowane przez inżyniera Wykonawcy z certyfikatem poświadczonym przez producenta, którego wiedza została potwierdzona pisemnie przez producenta; w obecnym Postępowaniu brak analogicznego wymogu osobowego dla Asysty Wykonawcy (brak wymogu dwóch certyfikowanych inżynierów, dedykowanego etatu, stałej obsady czy minimalnej liczby roboczogodzin miesięcznie), - obowiązki administracyjno-techniczne związane z portalem producenta – cena usług w 2025 r. obejmowała także rejestrację konta Zamawiającego na portalu Producenta Systemu, udzielenie przedstawicielom Zamawiającego dostępu do serwisu webowego producenta, umożliwiającego samodzielne aktualizowanie oprogramowania, dostęp do dokumentacji oraz składanie Zleceń Serwisowych i zapytań konfiguracyjnych bezpośrednio do producenta; dokumentacja Postępowania nie przewiduje takich obowiązków po stronie Wykonawcy. b. Powyższe pokazuje, że zakres umowy z 2025 r. nie obejmował wyłącznie „obsługi zgłoszeń”, lecz znacznie szerszy pakiet czynności organizacyjno-technicznych. Różnice te zostały uwzględnione przez Wykonawcę przy ocenie pracochłonności nowego zamówienia, w którym ten zakres nie występuje.

Błędne założenia Zamawiającego co do roli Asysty i Wsparcia Producenta a. W uzasadnieniu odrzucenia oferty Stinet Zamawiający ocenia koszt Asysty tak, jakby wszystkie czynności diagnostyczne, awaryjne, eksperckie, konfiguracyjne i utrzymaniowe miały być realizowane wyłącznie przez Stinet, bez udziału producenta. Jest to błędne i sprzeczne z wymaganiami określonymi w OPZ. b. Dokumentacja Postępowania rozdziela przedmiot zamówienia na: dostawę licencji/sprzętu wraz ze Wsparciem Producenta, wdrożenie, Asystę Wykonawcy, Wsparcie Eksperckie realizowane na podstawie Zleceń. c. Model realizacji zamówienia zakłada współdziałanie: wykonawca + Wsparcie Producenta + opiekun/inżynier producenta + Wsparcie Eksperckie + automatyzacja systemów. Zamawiający nie może wymagać w OPZ dedykowanego wsparcia eksperckiego producenta i opiekuna technicznego producenta, a następnie oceniać ceny Asysty tak, jakby wsparcie producenta nie istniało. d. OPZ przewiduje bardzo rozbudowany zakres Wsparcia Producenta, obejmujący m.in.: - wsparcie techniczne świadczone bezpośrednio przez producenta, - możliwość rejestrowania zgłoszeń 24/7, - czas reakcji inżyniera producenta 1h dla zgłoszeń krytycznych i 4h dla pozostałych, - dedykowane wsparcie eksperckie producenta, - wsparcie opiekuna technicznego przy wdrażaniu, bieżącym użytkowaniu, weryfikacji konfiguracji i proaktywnym zarządzaniu zgłoszeniami. e. W obecnym wzorze umowy Wsparcie Eksperckie zostało zdefiniowane jako odrębna usługa obejmująca prace rozwojowe, projektowe, implementacyjne oraz dotyczące testowania nowych funkcjonalności Systemu Bezpieczeństwa, realizowane na podstawie Zleceń. f. Dlatego nie można całej potencjalnej pracochłonności prac zmianowych, integracyjnych, projektowych, implementacyjnych, testowych albo związanych z nowymi funkcjonalnościami przypisywać do miesięcznej, ryczałtowej Asysty technicznej. Przykładowo: - utrzymanie istniejących integracji nie jest tym samym co tworzenie nowych integracji, - bieżące testowanie zmian nie jest tym samym co szerokie testy nowych funkcjonalności, - konsultacje nie są tym samym co szkolenia, warsztaty, opracowanie procedur lub dokumentacji, - bieżące dostosowanie systemu nie jest tym samym co prace projektowe lub rozwojowe.

Złożoność zamówienia a rzeczywisty zakres Asysty. a. Zamawiający wskazuje, że obecne zamówienie obejmuje XDR SaaS, NDR on-premisesi Sandbox on-premises, ponad 19 000 endpointów, dwa CPD, integracje z AD/Entra ID, SIEM/SOAR, SMAX oraz dokumentację HLD/LLD, i na tej podstawie formułuje wniosek o konieczności zapewnienia „co najmniej jednego pełnoetatowego specjalisty” w wymiarze min. 150 rbh miesięcznie. b. Odwołujący nie kwestionuje, że obecne zamówienie jest technologicznie szersze od poprzedniej umowy, jednak elementy takie jak integracja z AD/Entra ID, integracjaz SIEM/SOAR, integracja z SMAX, instalacja NDR w dwóch CPD, przygotowanie dokumentacji HLD/LLD, konfiguracja początkowa czy testy odbiorowe są przede wszystkim elementami wdrożenia lub Wsparcia Eksperckiego, które zostały wycenione odrębnie. c. Zamawiający utożsamia złożoność całego zamówienia z pracochłonnością jednej pozycji cenowej – Asysty – nie wykazując, jakie konkretne czynności w ramach samej Asysty, z jaką częstotliwością i w jakim wymiarze godzinowym mają uzasadniać 150 rbh miesięcznie. d. Dodatkowo XDR jest w modelu SaaS, sama liczba endpointów nie przekłada się liniowo na liczbę godzin ręcznej pracy po stronie Stinet. W systemach XDR/NDR wiele czynności realizowanych jest centralnie i automatycznie, w tym: definiowanie polityk, korelacja zdarzeń, budowa baseline, alertowanie, raportowanie, analiza anomalii, reakcje automatyczne oraz eskalacje do producenta. e. NDR jest nowym komponentem względem poprzedniej umowy, czego Stinet nie kwestionuje, jednak sam fakt dodania NDR nie jest dowodem rażąco niskiej ceny. Zamawiający nie wskazał bowiem m.in.: ile zgłoszeń NDR przewiduje miesięcznie, ile zmian konfiguracji będzie wymaganych, ile incydentów będzie wymagało ręcznej analizy, ile godzin zajmie analiza anomalii, które czynności wykona system automatycznie, które czynności wykona producent, które czynności mieszczą się we Wsparciu Eksperckim, które czynności są elementem wdrożenia. f. Wniosek o „kilkukrotnym zaniżeniu” pracochłonności jest więc arbitralny i niczym niepoparty – na takiej samej zasadzie Zamawiający mógłby przyjąć dowolny inny poziom, np. 300 czy 500 roboczogodzin. g. Zamawiający wskazał w uzasadnieniu odrzucenia, że Asysta obejmuje m.in. minimum 6 przeglądów w ciągu umowy oraz dostosowanie systemu nie rzadziej niż co 3 miesiące (co najmniej 12 interwencji w ciągu 36 miesięcy) jako uzasadnienie wysokiej pracochłonności. Są to jednak czynności okresowe, a nie codzienny, stały nakład pracy pełnoetatowego specjalisty. W szczególności Zamawiający nie wykazał, ile godzin ma trwać każdy przegląd albo każda interwencja, nie wykazał również dlaczego te czynności mają uzasadniać 150 rbh miesięcznie przez cały okres umowy.

Dodatkowo przeglądy nie są nowym wymaganiem – w umowie z 2025 r. Zgłoszenia Serwisowe obejmowały już profilaktykę i comiesięczny przegląd systemu wraz z przygotowaniem raportu.

Charakter Asysty jako świadczenia ryczałtowego a. Zamawiający potraktował katalog czynności Asysty technicznej jako dowód konieczności zapewnienia pełnoetatowego specjalisty. Zamawiający wskazał, że „zakres obowiązków, realizowany przez 36 miesięcy na trzech odrębnych zaawansowanych systemach, w środowisku ponad 19 000 endpointów, wymaga w ocenie Zamawiającego regularnego zaangażowania co najmniej jednego umownego pełnoetatowego specjalisty na poziomie eksperckim (min 150 rgb),

również w trybie dyżuru, obejmującego weekendy i święta.” (str. 5 z 7 Informacji o wyborze oferty najkorzystniejszej). b. Zamawiający nie wykazał braku możliwości wykonania zamówienia za cenę zaoferowaną przez Odwołującego.

Zamawiający zakwestionował jedynie przyjęty przez Stinet model kalkulacji pracochłonności, a następnie zastąpił go własnym, nieujawnionym wcześniej założeniem, że wymagane jest zaangażowania co najmniej jednego umownego pełnoetatowego specjalisty na poziomie eksperckim min. 150 rbh, również w trybie dyżuru, obejmującego weekendy i święta. Takiego wymogu nie zawierała jednak Dokumentacja postępowania. c. Dokumentacja postępowania nie określa oczekiwanej liczby godzin Asysty technicznej miesięcznie, nie wymaga dedykowanego pełnoetatowego specjalisty po stronie wykonawcy dla celów Asysty, nie wymaga stałej obsady ani dyżuru weekendowego ze strony wykonawcy, nie wskazuje modelu 150 rbh miesięcznie ani żadnej innej wartości godzinowej.

Wymaganie te pojawiają się dopiero w uzasadnieniu odrzucenia oferty Odwołującego. d. Zamawiający ukształtował Asystę techniczną jako świadczenie ryczałtowe – cena za Asystę ma charakter ceny miesięcznej, zryczałtowanej. Cena ryczałtowa z definicji zakłada, że to wykonawca ponosi ryzyko właściwego oszacowania nakładu pracy. Zamawiający nie może po złożeniu ofert narzucać własnej (nieujawnionej w SW Z) interpretacji pracochłonności i na jej podstawie odrzucać ofertę. e. Przyjęta przez Stinet kalkulacja pracochłonności usługi Asysty Wykonawcy została oparta na rzeczywistym modelu świadczenia tego typu usług, uwzględniającym zarówno doświadczenie Odwołującego z realizacji analogicznych umów, w tym realizowanych na rzecz Zamawiającego, jak i specyfikę oferowanego rozwiązania. Przyjęta kalkulacja ceny uwzględnia rzeczywisty model wykorzystania usług, a nie maksymalny, hipotetyczny zakres ich świadczenia. Dzięki posiadanemu przez Wykonawcę doświadczeniu w realizacji tego typu zamówień, znajomości rozwiązań klasy XDR oraz NDR, kadrze, która na co dzień pracuje z tego typu rozwiązaniami, Odwołujący był w stanie realnie ocenić czasochłonność Asysty. f. Szczególnie istotna w kontekście powyższego jest udzielona przez Zamawiającego odpowiedź na pytanie nr 34 dotyczące Asysty. W odpowiedzi na pytanie nr 34 Zamawiający odmówił wprowadzenia limitu czasowego Asysty w postaci 30 godzin kwartalnie, nie dlatego że uznał ten poziom za niewystarczający i wskazał inną konkretną liczbę godzin, lecz dlatego że stwierdził, iż Asysta ma charakter ryczałtowego świadczenia rezultatu. Jednocześnie potwierdził, że wymagania pkt 14.4.6 lit. a–s mają charakter zadaniowy i celowościowy, a nie czasowy – co oznacza, że żaden z punktów tego katalogu nie definiuje konkretnej minimalnej liczby godzin, którą wykonawca ma obowiązkowo przepracować. Z odpowiedzi Zamawiającego wynikało, że wykonawca powinien samodzielnie oszacować ryzyko i pracochłonność poszczególnych zadań w ramach ryczałtowej ceny oferty. g. Zamawiający nie odrzucił więc oferty Stinet dlatego, że wykazał nierealność wykonania Asysty za cenę Stinet, lecz dlatego, że po otwarciu ofert przyjął własny, ukryty model pracochłonności Asysty, którego nie podał w dokumentacji zamówienia. Zamawiający nie może najpierw ukształtować Asysty jako świadczenia ryczałtowego bez wskazania minimalnej liczby godzin, a następnie odrzucić ofertę dlatego, że wykonawca przyjął inną pracochłonność niż oczekiwana przez Zamawiającego po otwarciu ofert.

Przyjęte do wyceny stawki. a. Zamawiający twierdzi, że Stinet nie wykazał „rynkowości” stawki Asysty i Wsparcia Eksperckiego. b. Odwołanie do stawki z 2025 r. nie przesądza o nierynkowości obecnej stawki. Niższa stawka Wsparcia Eksperckiego w obecnej ofercie nie oznacza automatycznie zaniżenia ceny, lecz wynika z odmiennego sposobu kalkulacji większego, dłuższego i technologicznie odmiennego kontraktu. Sama okoliczność, że stawka roboczogodziny Zleceń Serwisowych w 2025 r. była wyższa od stawki obecnego Wsparcia Eksperckiego, nie dowodzi nierealności obecnej kalkulacji. Ceny te dotyczą świadczeń o częściowo odmiennym zakresie, realizowanych w innych modelach technicznych i kontraktowych; w obecnym postępowaniu znaczenie ma również rozbudowane Wsparcie Producenta, model XDR SaaS, urządzenia typu appliance, automatyzacja oraz możliwość rozłożenia kosztów i marży w ramach całej 36-miesięcznej oferty. c. Zamawiający wskazał, że Stinet „unika” przytoczenia kwot zaoferowanych w poprzednim postępowaniu. Jest to argumentacja chybiona. Różnica w stawce oferowanej w 2025 r. i obecnym Postępowaniu wynika z innego profilu świadczenia: cena roboczogodziny Zleceń Serwisowych w 2025 r. była wyższa, ponieważ Zamawiający wymagał wówczas zaangażowania inżynierów posiadających certyfikację producenta i wiedzę potwierdzoną przez producenta, co generowało wyższy koszt jednostkowy zasobu. d. Dodatkowo Zlecenia Serwisowe w 2025 r. obejmowały bardzo szeroki i specjalistyczny zakres: prace utrzymaniowe (w tym instalacje i reinstalacje elementów Systemu), prace rozwojowe, projektowe, implementacyjne, testowanie nowych funkcjonalności i oprogramowania producenta, inżynierię odwrotną. Był to zakres potencjalnie bardziej pracochłonny, niestandardowy i wymagający specjalistycznej wiedzy certyfikowanych inżynierów. Dlatego stawka roboczogodziny zaoferowana w 2025 r. nie może być 1:1 porównywana z obecną stawką za Wsparcie Eksperckie – obejmowała inny profil kosztowy, kadrowy i ryzyka. e. Wyprzedzając argumentację Zamawiającego wskazujemy, że Wsparcie Eksperckie w nowej umowie również obejmuje prace specjalistyczne, ale występuje w innym modelu kontraktowym i technicznym: obecne zamówienie jest większe i 36miesięczne, co pozwala na inne rozłożenie marży i kosztów; obejmuje rozbudowane Wsparcie Producenta, w tym dedykowane wsparcie eksperckie producenta i opiekuna technicznego; XDR działa w modelu SaaS,a część ciężaru utrzymania, aktualizacji, diagnostyki i skalowania platformy pozostaje po stronie producenta; NDR i Sandbox są urządzeniami typu appliance obsługiwanymi według procedur producenta; Wsparcie Eksperckie jest tylko jednym z elementów całej oferty, a nie samodzielnym kontraktem godzinowym; oferta jako całość zawiera inne pozycje, w których Stinet mógł uwzględnić większą marżę, ryzyko i rezerwy. f. Niższa stawka Wsparcia Eksperckiego w obecnej ofercie nie oznacza automatycznie zaniżenia ceny, lecz odmienny sposób kalkulacji większego, dłuższego i technologicznie odmiennego kontraktu. Na wycenę oferty wpływa szereg okoliczności, w tym m.in. poziom marży, który w każdym postępowaniu i każdej pozycji może być kalkulowany inaczej. g. Sama okoliczność, że stawka roboczogodziny Zleceń Serwisowych w 2025 r. była wyższa od stawki obecnego Wsparcia Eksperckiego, nie dowodzi nierealności obecnej kalkulacji. Ceny te dotyczą świadczeń o częściowo odmiennym zakresie, realizowanych w innych modelach technicznych i kontraktowych; w obecnym postępowaniu znaczenie ma również rozbudowane Wsparcie Producenta, model XDR SaaS, urządzenia typu appliance, automatyzacja oraz możliwość rozłożenia kosztów i marży w ramach całej 36-miesięcznej oferty. h. Powołanie się na ofertę Integrity także nie dowodzi nierealności stawki Stinet. Oferta Integrity odzwierciedla inny model organizacyjny i cenowy.

Zamawiający nie wykazał, że model Integrity jest jedynym dopuszczalnym rynkowo modelem realizacji zamówienia. i. Stawka ok. 100 zł/rbh była stosowana przez Stinet również w kalkulacji innych projektów np. prowadzonego przez Centralny Zarząd Służby Więziennej pn. „Świadczenie usługi systemu bezpieczeństwa wraz ze wsparciem i usługami szkoleniowymi”, znak sprawy 10/24/KS. Potwierdza to, że nie jest to założenie sztuczne ani przygotowane wyłącznie na potrzeby obecnego postępowania. - W ww. postępowaniu Stinet kalkulował pełny zakres usług związanych z wdrożeniem i utrzymaniem systemu bezpieczeństwa, w tym m.in.: opracowanie dokumentacji projektowej, przygotowanie procedur obsługi systemu, dokumentację powykonawczą, szkolenia i warsztaty, konsultacje i instruktaż, bieżące utrzymanie systemu, zarządzanie systemem, administrowanie systemem, rozwiązywanie problemów związanych z obsługą, instalacją, konfiguracją, optymalizacją, utrzymaniem i administracją systemu, obsługę zgłoszeń, realizację zgłoszeń awarii, instalację poprawek, usprawnień i nowych wersji, zarządzanie projektem i nadzór. - Zamawiający wymagał konkretnych ról/personelu, m.in.: kierownika projektu, specjalistów wdrożeniowych, specjalisty ds. bezpieczeństwa, koordynatora projektu. Stinet uwzględnił w kalkulacji zaangażowanie 7 osób: kierownika projektu, 4 specjalistów wdrożeniowych, specjalisty ds. bezpieczeństwa i koordynatora projektu. - Co istotne, w Stinet kalkulował również wysokie nakłady godzinowe tam, gdzie zakres obejmował pełne bieżące utrzymanie, zarządzanie i administrowanie systemem. To pokazuje, że Stinet nie zaniża automatycznie godzin ani

stawek, ale różnicuje kalkulację według rzeczywistej konstrukcji zamówienia. - Dodatkowo w ww. projekcie Stinet konkurował z Integrity. Cena oferty Stinet wyniosła 6 911 493,00 zł, podczas gdy cena oferty Integrity wyniosła 19 099 183,40 zł. Oferta Integrity była więc ok. 2,76 razy wyższa od oferty Stinet. Mimo wszystko Zamawiający uznał, że zaoferowana stawka jest rynkowa, a cena nie jest rażąco niska. Potwierdza to, że wyższa cena Integrity nie może być traktowana jako jedyny rynkowy punkt odniesienia ani dowód nierealności ceny Stinet. Różnice cenowe między tymi wykonawcami wynikają z odmiennego modelu kosztowego i organizacyjnego.

Doświadczenie członków personelu. a. Zamawiający wskazał: „Zamawiający nie może uznać wyjaśnień Wykonawcy, ponieważ Wykonawca nie wskazał, która z osób dedykowanych do realizacji zamówienia jest osobą „mniej doświadczoną”, a która „bardziej doświadczoną”. Nie zostało wykazane także, jaki miesięczny nakład pracy będzie udziałem poszczególnych grup osób.” b. Taki wymóg nie wynikał jednak ani z SW Z, ani z OPZ, ani z wezwania do wyjaśnień ceny RNC. Zamawiający nie sformułować warunku w zakresie osób, nie wymagał również przedstawienia listy osób będą realizowały zamówienie.

Zupełnie nieadekwatne jest więc oczekiwanie wskazania poziomu doświadczenia specjalistów wykonawcy. c. Istotne jest ponadto że przy usługach IT/cybersecurity naturalna jest dynamiczna alokacja zasobów: prostsze czynności wykonują osoby o niższym poziomie seniority, a trudniejsze są eskalowane do bardziej doświadczonych inżynierów albo do producenta. Nie da się z góry wskazać miesięcznego rozkładu pracy pomiędzy grupami kompetencyjnymi, gdyż Asysta zależy od rzeczywistych zgłoszeń i potrzeb, a Wsparcie Eksperckie od przyszłych Zleceń Zamawiającego. d. Dodatkowo OPZ wymaga dedykowanego wsparcia eksperckiego producenta i opiekuna technicznego producenta. To oznacza, że nie wszystkie trudniejsze problemy muszą być rozwiązywane wyłącznie przez seniorów Stinet. Jest to kolejny argument potwierdzający, że przedstawienie godzinowego podziału pomiędzy konkretne osoby miałoby na tym etapie charakter wyłącznie sztuczny. e. Niezależnie od powyższego, jeżeli Zamawiający miał wątpliwości, to mógł skierować do Stinet ponowne wezwanie do wyjaśnień. Z całą pewnością brak ww. informacji nie uzasadniał braku uznania wyjaśnień Odwołującego. Informacje w powyższym zakresie nie wpłynęłaby bowiem na kształt wyjaśnień.

Koszt robocizny i dowody złożone przez Odwołującego. a. Istotnie jest, że Zamawiający nie zakwestionował poziomu przyjętych przez Odwołującego kosztów robocizny, a jedynie formalnie zakwestionował dowody przedstawione na ich potwierdzenie. b. Na potwierdzenie, że przyjęta stawka roboczogodziny została skalkulowana w oparciu o rzeczywiste koszty ponoszone przez Wykonawcę w zakresie świadczenia usług inżynierskich, Odwołujący złożył dokumenty księgowe (faktury) dokumentujące wynagrodzenie inżynierów na stałe współpracujących z Wykonawcą. c. W uzasadnieniu odrzucenia oferty Odwołującego Zamawiający wskazał, że „nie może z ich treści wywnioskować, jakich usług one dotyczą i w jakim stopniu są adekwatne do przedstawianej kalkulacji. Wskazane w jednej z nich „usługi informatyczne” są bardzo szerokim pojęciem, o czym doskonale zdaje sobie sprawę Wykonawca jako profesjonalny podmiot działający na rynku tychże usług.” d. Zamawiający pomija zupełnie, że faktury te zostały załączone jako dowód do wyjaśnień, a zatem należy je odczytywać łącznie. W wyjaśnieniach jasno wskazano, że są to dokumenty księgowe potwierdzające stawki przyjęte do kalkulacji ceny, a więc dotyczące usług analogicznych jak objęte przedmiotem zamówienia. e. Zupełnie niezrozumiałe i oderwane od realiów rynkowych jest wymaganie, aby opis faktury odpowiadał poszczególnych kategoriami zadań składających się na dany rodzaj usług. Zawarty na fakturze VAT opis „usługi informatyczne” jest standardowy w obrocie B2B i nie oznacza, że faktury są nierzetelne. f. Pozbawiony zasadności jest również kolejny argument Zamawiającego tj. że „żadna z załączonych faktur nie zawiera informacji co do terminu realizacji usługi”. W tym zakresie również aktualna pozostaje powyższa argumentacja – Zamawiający nie może interpretować złożonych dowodów w oderwaniu od wyjaśnień ceny. W treści wyjaśnień wskazano podane na fakturach wynagrodzenie wskazując, że jest to wynagrodzenie miesięczne. g. Adekwatności dotychczasowego doświadczenia Odwołującego wykazano we wcześniejszej części odwołania. h. Zamawiający zarzucił również, że Odwołujący „w żaden sposób nie uzasadnił „rynkowości” przyjętych stawek.” Nie sposób zgodzić się z argumentacją Zamawiającego. Odwołujący nie tylko dołączył do wyjaśnień ceny faktury przedstawiające rzeczywiste koszty jakie ponosi z tytułu świadczenia usług przez swoich współpracowników, ale również raport płacowy przedstawiający rynkowy poziom cen. Odwołujący wykazał więc, że przyjęta w kalkulacji stawka roboczogodziny znajduje również odzwierciedlenie w średnim poziomie wynagrodzeń specjalistów IT na rynku polskim.

Zamawiający zupełnie pominął ten dowód w swojej argumentacji. i. Zamawiający wskazał, że „Bazując na posiadanych dokumentach, tj. dotychczas realizowanej umowie na rzecz Zamawiającego (koszt roboczogodziny wskazany w powyższej tabeli), dokonanemu przez Zamawiającego w oparciu o rozeznanie rynku szacunkowi stawek jednostkowych oraz stawkom wskazanym w kontrofercie w przedmiotowym postępowaniu, Zamawiający uznaje, że Wykonawca w wyjaśnieniach rażąco niskiej ceny nie udowodnił rynkowej wysokości stawki zarówno świadczenia Asysty, jak i Wsparcia eksperckiego.” Istotne jest jednak, że: - Zamawiający powołuje się na wcześniejszą umowę z 2025 r., jednak pomija fundamentalną różnicę w zakresie obu zamówień. W poprzednim postępowaniu wymagano skierowania do realizacji certyfikowanych inżynierów posiadających oficjalne certyfikaty producenta Systemu, przy czym Zlecenia Serwisowe miały być realizowane przez inżyniera z certyfikatem poświadczonym przez producenta. W obecnym postępowaniu brak jest analogicznego wymogu osobowego dla Asysty Wykonawcy, co za tym idzie stawki osobowe są odpowiednio niższe. - Nie istnieją przepisy, które nakładałyby na wykonawcę obowiązek stosowania identycznych stawek we wszystkich postępowaniach. Na wycenę oferty wpływa szereg czynników – od aktualnej dostępności pracowników i ich stawek, przez liczbę realizowanych równolegle projektów, poziom marży, po atrakcyjność danego zamówienia. W wyroku KIO 2816/22 Izba wprost wskazała, że „możliwe są również sytuacje, w której sam fakt realizacji zamówienia będzie zyskiem dla wykonawcy, gdyż umożliwia mu kontynuowanie działalności gospodarczej”. Każda wycena zamówienia jest hipotetyczną analizą kosztów realizacji prac, dokonaną w oparciu o indywidualne doświadczenie i uwarunkowania wykonawcy. - Powołanie się przez Zamawiającego na ofertę i stawki oferowane przez Integrity nie dowodzi nierealności stawki Stinet.

Oferta Integrity odzwierciedla inny model organizacyjny i cenowy, właściwy dla tego konkretnego przedsiębiorcy.

Zamawiający nie wykazał, że model Integrity jest jedynym dopuszczalnym rynkowo modelem realizacji zamówienia. Jak orzekła KIO w wyroku 966/22: „każdy z wykonawców, kalkulując swoją ofertę, bierze pod uwagę jemu tylko znane czynniki, które wpływają na sposób świadczenia usługi, często wynikające z doświadczenia w realizacji takich zamówień".

Wykonawcy mają prawo do stosowania różnych modeli biznesowych, technologii i strategii zarządzania, co przekłada się na różnice w wycenie. - Zamawiający powołuje się na „dokonane w oparciu o rozeznanie rynku szacowanie stawek jednostkowych", jednak są to twierdzenia całkowicie gołosłowne. Zamawiający nie wskazał nawet, na jakiej podstawie oszacował ww. stawki, co więcej – pomimo wniosku Odwołującego, dokumenty dotyczące szacowania nie zostały udostępnione. j. Zamawiający wskazał, że Stinet unika przytoczenia kwot jakie zaoferował w poprzednim postępowaniu. Jest to jednak argumentacja zupełnie chybiona. Pomimo usilnej próby Zamawiającego Odwołujący nie czuje się „przyłapany”.

Uzasadnienie różnicy w stawce oferowanej w 2025 r. i obecnym Postępowaniu jest bowiem bardzo proste. Cena roboczogodziny Zleceń Serwisowych w 2025 r. była wyższa, ponieważ Zamawiający wymagał wówczas zaangażowania inżynierów posiadającego certyfikację producenta i wiedzę potwierdzoną przez producenta, a stawki takich osób są odpowiednio wyższe. Oznaczało to wyższy koszt jednostkowy zasobu, ponieważ Wykonawca musiał kalkulować dostępność wysoko wyspecjalizowanych, certyfikowanych inżynierów do prac przy środowisku Trellix/McAfee. k. Istotne jest, że Stinet już w ofercie złożonej Zamawiającemu w ramach rozpoznania rynku XDR na podstawie otrzymanych od Zamawiającego wytycznych przedstawił wycenę, która potwierdza konsekwentny sposób kalkulowania podstawowego wsparcia bieżącego. - W ofercie z 3.04.2025 r. Zgłoszenia Serwisowe zostały wycenione na 24 000 zł netto za 12 miesięcy, tj. 72 000 zł netto

za 36 miesięcy. Obecna Asysta Wykonawcy została skalkulowana na analogicznym poziomie netto: 2 000 zł miesięcznie, tj. 24 000 zł netto rocznie i 72 000 zł netto za 36 miesięcy. Oznacza to, że aktualna wycena Asysty nie jest wartością przypadkową ani stworzoną wyłącznie na potrzeby Wyjaśnień RNC, lecz odpowiada wcześniejszemu modelowi wyceny podstawowego wsparcia bieżącego. - Wcześniejsza oferta szacunkowa potwierdza spójność wyceny podstawowego wsparcia. l. Zgodnie z art. 224 ust. 5 ustawy Pzp obowiązek wykazania, że oferta nie zawiera rażąco niskiej ceny, spoczywa na wykonawcy. Jednakże nie oznacza to, że zamawiający może formułować arbitralne i nieudowodnione zarzuty. W wyroku KIO 2452/22 Izba wskazała: „Ciężar dowodu spoczywający na wykonawcy, który złożył ofertę z kwestionowaną ceną, nie zwalnia bowiem zamawiającego z obowiązku przedstawienia uzasadnienia wskazującego na zasadność odrzucenia oferty. Nie oznacza to przerzucania na zamawiającego obowiązku wykazania realności ceny oferty, ale wręcz przeciwnie stanowi o obowiązku wykazania nierealności ceny tej oferty lub obowiązku wykazania wadliwości wyjaśnień wykonawcy". m. Odwołujący złożył wyjaśnienia uwzględniające specyfikę przedmiotowego zamówienia, w tym brak wymogu certyfikacji dla personelu realizującego Asystę. Różnice w stawkach między obecnym a wcześniejszym zamówieniem wynikają z obiektywnych czynników, które Odwołujący ma prawo uwzględnić w kalkulacji. Zamawiający nie wykazał nierealności oferowanej ceny, opierając się jedynie na gołosłownych twierdzeniach o rozeznaniu rynku oraz nieuprawnionej porównawczości z ofertą innego wykonawcy stosującego odmienny model organizacyjny. Zgodnie z art. 224 ust. 6 ustawy Pzp oraz utrwalonym orzecznictwem KIO, brak wykazania przez Zamawiającego wadliwości złożonych wyjaśnień oznacza, że wykonawca sprostał obowiązkowi wykazania realności zaoferowanej ceny. n. W orzecznictwie Izby podkreśla się również, że „wezwanie wykonawcy do złożenia wyjaśnień w trybie art. 224 ustawy nie rodzi żadnego domniemania, ustawodawca nie wprowadził do przepisów skutku wezwania do złożenia wyjaśnień zakresie ceny w postaci domniemania rażąco niskiej ceny oferty wykonawcy wzywanego do złożenia wyjaśnień.” (tak KIO w wyroku z dnia 1 kwietnia 2025 r., sygn. KIO 836/25). Podobnie również w orzeczeniu z dnia 4 lutego 2025 r., sygn. akt KIO 4986/24, wyroku z dnia 2 stycznia 2025 r., sygn. akt KIO 4689/24, wyroku z dnia 9 maja 2024 r. sygn. akt KIO 1291/24).

IX. Ad. ust. III pkt 2 i 3 odwołania - odrzucenie oferty Odwołującego za niezgodnośćz warunkami zamówienia i zaniechanie wezwania do złożenia wyjaśnień dotyczących treści oferty.

Zamawiający dokonał odrzucenia oferty Odwołującego również z uwagi na rzekomą niezgodność z warunkami zamówienia. W uzasadnieniu swojej decyzji Zamawiający wskazał:

„Zgodnie z pkt 1.15 OPZ, dla wykazanych (zgodnie z pkt. 1.14 OPZ) systemów operacyjnych, które są poza aktywnym wsparciem producenta (EoL ang. End of Life), Wykonawca powinien opisać zakres funkcjonalności oferowanych detekcji i reakcji oraz ewentualne ograniczenia. Załączony przez Stinet Sp. z o.o. wykaz nie spełnia wymagań OPZ. Wykonawca podał nazwę systemu operacyjnego, wersję, datę końca wsparcia oraz zakres funkcjonalny. Dla systemów EoL wskazany jest rodzaj rozwiązania „Antywirus następnej generacji (NGAV)”, natomiast brakuje opisu funkcjonalności oferowanych detekcji i reakcji oraz ograniczeń wynikających z zastosowanego rozwiązania.” W ocenie Odwołującego stanowisko Zamawiającego nie zasługuje na aprobatę, zaś kontrargumentacja Odwołującego opera się na następującym: a.OPZ nie określał ani sposobu prezentacji informacji wymaganych w pkt 1.15, ani minimalnego poziomu szczegółowości takiego opisu, więc Zamawiający nie mógł stworzyć takiego wymogu dopiero na etapie oceny ofert, b.Odwołujący przedstawił wymagany opis funkcjonalności detekcyjnych i reakcyjnych oraz wskazał ograniczony względem pełnego XDR zakres ochrony dla systemów EoL poprzez użycie pojęcia „Antywirus Następnej Generacji (NGAV)”, c.„Antywirus Następnej Generacji (NGAV)” jest określeniem opisującym zbiorczo zakres funkcjonalności oferowanych detekcji i reakcji oraz jednocześnie wskazuje ograniczenie zakresu ochrony względem pełnego XDR, d.pojęcie „Antywirus Następnej Generacji (NGAV)” jest powszechnie rozumianym pojęciem technologicznym w branży cyberbezpieczeństwa, e.Zamawiający dokonał błędnej wykładni pkt 1.15 OPZ i w konsekwencji bezpodstawnie uznał ofertę Odwołującego za niezgodną z warunkami zamówienia, f.nawet przy założeniu, że Zamawiający miał wątpliwości interpretacyjne dotyczące znaczenia użytego przez Odwołującego określenia „Antywirus Następnej Generacji (NGAV)”, w pierwszej kolejności powinien był podjąć czynności zmierzające do ich usunięcia poprzez wezwanie do wyjaśnienia treści oferty. Niedopuszczalne było natomiast przyjęcie niekorzystnej dla wykonawcy interpretacji i wywiedzenie z niej najdalej idącej konsekwencji prawnej w postaci odrzucenia oferty.

1. W ocenie Odwołującego przedstawiony przez niego wykaz spełnia wymagania opisane w pkt 1.15 OPZ, a Zamawiający nie sprecyzował w dokumentacji Postępowania, w jaki sposób oczekuje opisania „funkcjonalności oferowanych detekcji i reakcji oraz ograniczeń wynikających z zastosowanego rozwiązania”, wobec tego na etapie badania i oceny ofert nie może takich wymogów wprowadzać (byłoby to wprost sprzeczne z treścią art. 137 ust. 1 Pzp oraz art. 16 pkt 1 i 2 Pzp).
2. W OPZ Zamawiający sformułował następujące wymagania:

„1.14 Oferent (Wykonawca) dołącza wykaz obsługiwanych przez system XDR systemów operacyjnych wraz z wersjami oraz datami końca wsparcia producenta.