Tryb postępowania: postępowanie prowadzone w trybie podstawowym na podstawie art. 275 pkt 1 ustawy Prawo zamówień publicznych.
Uzasadnienie trybu: Zamawiający wskazuje, że szacunkowa wartość zamówienia nie przekracza progów unijnych (informacja w SWZ) — stąd zastosowanie trybu podstawowego.
**Czy stosuje się art. (+ 3 zdania — pełna treść po zalogowaniu)
Termin wykonania przedmiotu zamówienia: maksymalnie 21 dni od dnia zawarcia umowy.
Termin składania ofert (proceduralny, do weryfikacji przez wykonawców): 19.08.2026 r. do godz. 10:00. (termin zaktualizowany przez zamawiającego — pierwotna dokumentacja podawała 18.08.2026)
Zamawiający stawia następujące warunki udziału (kwalifikacje, doświadczenie i zasoby), które Wykonawca musi spełniać, aby ubiegać się o zamówienie:
Doświadczenie: Wykonawca musi wykazać, że w okresie ostatnich 3 lat (lub krótszym, jeśli prowadzi działalność krócej) należycie wykonał co najmniej 2 zadania, z których każde polegało na dostawie i wdrożeniu (instalacji i konfiguracji) komercyjnego, własnościowego systemu zarządzania logami lub systemu klasy SIEM/XDR, niewykorzystującego jako podstawowego rozwiązania systemu Open Source lub Source Available, o wartości każdego zadania nie mniejszej niż 250000,00 zł brutto, zrealizowane na rzecz jednostek samorządu terytorialnego lub ich jednostek organizacyjnych.
Wykaz wykonanych usług (referencje): Wykonawca musi przedłożyć wykaz wykonanych zamówień zawierający informacje o rodzaju, wartości, dacie wykonania oraz podmiotach, na rzecz których zamówienia zostały wykonane, wraz z dowodami potwierdzającymi, że zamówienia te zostały wykonane należycie (np. referencje lub inne dokumenty sporządzone przez zamawiającego).
Możliwość sumowania / wyodrębnianie wartości: Jeżeli w ramach jednej umowy realizowano również inne dostawy/usługi, Wykonawca musi wyodrębnić rodzajowo i kwotowo zakres zamówienia stanowiący podstawę wykazania spełnienia warunku; wartość pojedynczego zadania rozumiana jest jako łączna wartość dostawy wraz z wdrożeniem (instalacją i konfiguracją).
Wykonawcy wspólnie ubiegający się o zamówienie: Wykonawcy ubiegający się wspólnie mogą wykazać spełnienie warunku łącznie lub wystarczy, że spełni go co najmniej jeden z wykonawców samodzielnie; w przypadku powoływania się na zdolności innych podmiotów (art.118) wymagane jest zobowiązanie tych podmiotów do oddania zasobów do dyspozycji.
Termin realizacji: (dotyczy możliwości wykonania) Wykonawca musi być w stanie zrealizować przedmiot zamówienia w terminie maksymalnie 21 dni od dnia zawarcia umowy.
Rodzaj oferowanego systemu: Oferowany system musi być komercyjnym rozwiązaniem (licencja bezterminowa na najnowszą wersję) dopuszczonym do stosowania w jednostkach sektora finansów publicznych oraz wdrożonym w środowisku Zamawiającego (środowisko zwirtualizowane); system nie może być oparty jako podstawowe rozwiązanie na Open Source/Source Available.
Zamawiający będzie oceniał oferty według trzech kryteriów: Cena brutto oferty – 60 pkt, Okres gwarancji jakości i rękojmi na cały zakres zamówienia – 20 pkt (min. 12 miesięcy, max. 48 miesięcy), Doświadczenie zawodowe osoby skierowanej do realizacji wdrożenia systemu SIEM – 20 pkt. Maksymalna liczba punktów: 100 pkt. (+ 1 zdanie — pełna treść po zalogowaniu)
Brak zapisu o karach umownych w treści SWZ ani w projekcie umowy: — s. ?
9
Inne zapisy
Widoczne 50%
Powierzenie części zamówienia podwykonawcom jest dozwolone; Wykonawca musi w ofercie wskazać części zamówienia, które zamierza powierzyć, oraz (jeżeli znane) nazwy podwykonawców. Powierzenie nie zwalnia Wykonawcy z odpowiedzialności za wykonanie zamówienia. (odn.: Rozdział IV pkt 13; Rozdział IV pkt 5; Rozdział IV pkt 5.2–5.5) — s. 6–9
Zmiana osób/zasobów podmiotów, na które Wykonawca powoływał się przy spełnianiu warunków: w przypadku zmiany lub rezygnacji z podwykonawcy, który był podstawą wykazania spełnienia warunków udziału, Wykonawca musi wykazać, że proponowany inny podwykonawca lub samodzielnie spełnia warunki w równym zakresie. (odn.: Rozdział IV pkt 5.4; Rozdział IV pkt 4.3–4.6) — s. 8–9
Audyt / weryfikacja: Zamawiający zastrzega możliwość weryfikacji referencji i innych dowodów wskazanych w ofercie (np. przez zwrócenie się do podmiotu, na rzecz którego usługi zostały wykonane). Na wezwanie Zamawiającego Wykonawca ma dostarczyć aktualne środki dowodowe w terminie nie krótszym niż 5 dni. (odn.: Rozdział VIII ust. 5–6 oraz Rozdział VIII pkt 6) — s. 10–12
Własność intelektualna: SWZ wymaga dostarczenia licencji na oprogramowanie w modelu bezterminowym, z prawem użytkowania wyłącznie w organizacji Zamawiającego; licencja powinna obejmować instalację, uruchamianie, eksploatację, administrowanie oraz prawo do aktualizacji/upgrade’ów i poprawek w okresie obowiązywania umowy serwisowej. (odn.: OPZ pkt 3 – Usługi serwisu i aktualizacji) — s. 3
RODO / ochrona danych osobowych: SWZ zawiera klauzulę informacyjną (Rozdział II) dotycząca przetwarzania danych osobowych wykonawców; Zamawiający wskazuje administratora i okresy przechowywania danych (m.in. 4 lata od zakończenia postępowania). Wszelka korespondencja i dokumenty mają być składane w języku polskim; dokumenty w języku obcym wymagają tłumaczenia. (odn.: Rozdział II; Rozdział X pkt 16; Rozdział VIII pkt 13) — s. 2, 13, 11
Z każdej z 9 sekcji pokazujemy połowę. Załóż darmowe konto, żeby odsłonić pozostałe 28 zdań — pełne warunki udziału, dokumenty i analizę ryzyka Janusza. Bez karty, 14 dni za darmo.
14 dni za darmo Bez karty płatniczej Rezygnacja w 1 klik
Opis przedmiotu zamówienia
Streszczenie AI · Janusz
Zamówienie (dostawa i wdrożenie systemu SIEM): dostawa, instalacja, konfiguracja i uruchomienie komercyjnego systemu klasy SIEM na infrastrukturze Zamawiającego (maszyna wirtualna/bare metal) wraz z licencją bezterminową, dokumentacją HLD/LLD i powdrożeniową, 24‑miesięcznym serwisem/wsparciem i aktualizacjami.
Analiza przedwdrożeniowa: wykonanie analizy środowiska, opracowanie HLD i LLD oraz architektury rozwiązania.
Wdrożenie – konfiguracja: implementacja systemu (GUI, baza danych), zabezpieczenie, optymalizacja, ujednolicenie danych, konfiguracja parserów, reguł korelacji, alertów i raportów oraz uruchomienie mechanizmów buforowania i szyfrowanej komunikacji.
Agenci zbierający logi: dostawa i wdrożenie agentów na stacjach/serwerach Windows (co najmniej 8 przykładów podczas instruktażu) z centralnym zarządzaniem, heartbeat, lokalnym buforowaniem i przesyłaniem TLS; wsparcie zbierania logów z plików tekstowych.
Źródła danych: obsługa ~300–400 źródeł logów (stacje, serwery, sieć, bazy, wirtualizacja, UPS, backup, NAS itp.), w tym min. 15 źródeł syslog UDP 514 pokazanych podczas instruktażu.
Formaty i protokoły: obsługa odbioru RAW, Syslog (RFC5424), CEF, LEEF, JSON; nasłuch na minimum 50 portach TCP/UDP; odbiór przez syslog, TCP/UDP/RELP, REST API, konektory do VMware, LDAP, MS365 integracja.
Parsowanie i przetwarzanie: możliwość tworzenia i testowania parserów z GUI, normalizacja do modelu klucz–wartość, indeksowanie pól, wzbogacanie (GeoIP, DNS), operacje matematyczne i programowanie wizualne dla logiki przetwarzania oraz filtrowanie już na agentach.
Wydajność i retencja: przetwarzanie min. 500 zdarzeń/s (EPS) przy średnim rozmiarze 700 B, buforowanie przy wzrostach obciążenia (2× obciążenia przez 5 min), przechowywanie dzienników min. 24 miesiące z możliwością konfigurowania retencji per‑kategoria.
Dostępność i HA: wdrożenie VM, mechanizmy monitorowania zapełnienia bufora, kopie zapasowe konfiguracji i danych; opcjonalne wsparcie klastra HA (min. 2 węzły) jako funkcjonalność opcjonalna.
Interfejs i użytkownicy: jednolity webowy GUI dostępny z popularnych przeglądarek, role i uprawnienia, dashboardy predefiniowane i interaktywne wizualizacje.
Dokumentacja i instruktaż: dostarczenie instrukcji obsługi, release notes (min. 2 ostatnie), dokumentacji instalacji agenta; przeprowadzenie instruktażu praktycznego dla personelu Sekcji Informatyki z uruchomieniem: min. 8 źródeł Windows i min. 15 źródeł syslog.
Licencjonowanie i wsparcie: licencja bezterminowa bez ograniczeń liczby agentów/źródeł i bez limitu wolumenu danych; 24‑miesięczny serwis/aktualizacje/wsparcie producenta z określonymi czasami reakcji i napraw dla błędów krytycznych/wysokich/średnich.
Trudnosc: wysoka
Pytania i odpowiedzi
Wyjaśnienia treści SWZ udzielone przez zamawiającego. Odpowiedzi wiążą wszystkich wykonawców — także tych, którzy nie zadali pytania.
Dotyczy wymagania w zakresie odbioru danych z zewnętrznych mechanizmów kolekcjonujących
Zamawiający w wymaganiu dotyczącym rozwiązania klasy SIEM wskazał, że: „Rozwiązanie musi wspierać odbiór danych
z zewnętrznych mechanizmów kolekcjonujących, w tym agentów z rodziny Elastic Beats.”
Zwracamy się z prośbą o dopuszczenie rozwiązania, które realizuje wskazaną funkcjonalność za pośrednictwem
dedykowanego komponentu pośredniczącego odpowiedzialnego za odbiór, przetwarzanie, normalizację oraz
przekazywanie danych do systemu SIEM, bez konieczności realizacji obsługi agentów Elastic Beats bezpośrednio przez
natywny komponent SIEM. W przypadku rozwiązania IBM QRadar SIEM możliwe jest zastosowanie komponentu
pośredniczącego, np. Logstash, który natywnie obsługuje mechanizmy zbierania danych z wykorzystaniem agentów
z rodziny Elastic Beats, a następnie umożliwia ich odpowiednie przetworzenie, parsowanie, normalizację i przekazanie
do systemu IBM QRadar w formacie oraz za pomocą mechanizmu obsługiwanego przez QRadar.
W takim modelu przepływ danych może być realizowany w następujący sposób: Elastic Beats → komponent kolekująco-
przetwarzający (np. Logstash) → IBM QRadar SIEM
Zastosowanie dodatkowego komponentu nie powoduje utraty wymaganej funkcjonalności. Przeciwnie, pozwala na
oddzielenie warstwy pozyskiwania i wstępnego przetwarzania danych od właściwej platformy SIEM, zapewniając
możliwość integracji różnych źródeł i mechanizmów kolekcjonowania danych.
Takie podejście jest również zgodne z architekturą systemów bezpieczeństwa, w których warstwa kolekcji,
przetwarzania i normalizacji danych może być realizowana przez wyspecjalizowane komponenty współpracujące z
platformą SIEM. Istotnym rezultatem jest możliwość skutecznego dostarczenia danych pochodzących z agentów Elastic
Beats do systemu SIEM, ich dalszego przetwarzania oraz wykorzystania przez mechanizmy analizy bezpieczeństwa.
Mając powyższe na uwadze, zwracamy się z pytaniem czy Zamawiający dopuści rozwiązanie SIEM, które zapewnia
odbiór danych z zewnętrznych mechanizmów kolekcjonujących, w tym agentów z rodziny Elastic Beats, za
pośrednictwem dedykowanego komponentu pośredniczącego, odpowiedzialnego za odbiór i konwersję/normalizację
Zamawiający, po przeanalizowaniu przedstawionej propozycji, podtrzymuje wymaganie określone w OPZ w jego
dotychczasowym brzmieniu. Tym samym nie przewiduje się zmiany sposobu spełnienia wskazanego wymagania poprzez
zastosowanie dodatkowego komponentu pośredniczącego w zakresie opisanym w pytaniu Wykonawcy.
W pkt. 2b. OPZ Zamawiający wymaga: Implementacja systemu która zawiera konfiguracje GUI oraz bazy danych
Czy w celu zwiększenia konkurencyjności Zamawiający zaakceptuje realizację procesu instalacyjnego Systemu w oparciu
o konsolę PowerShell? Należy pamiętać, że proces wdrożenia będzie realizowany przez Wykonawcę.
Zamawiający zaakceptuje wykorzystanie konsoli PowerShell na etapie instalacji i wdrożenia Systemu realizowanego
przez Wykonawcę. Powyższe nie zmienia wymagań OPZ dotyczących sposobu administracji, konfiguracji i aktualizacji
Systemu po jego wdrożeniu.
Dotyczy wymagania obsługi protokołu TCP RELP
Zamawiający w wymaganiach dotyczących rozwiązania klasy SIEM wskazał, że system musi zapewniać obsługę
standardowych protokołów transmisji danych, w tym co najmniej:
− UDP/TCP Syslog,
− TCP RELP w wersji szyfrowanej,
− TCP RELP w wersji nieszyfrowanej.
Zwracamy się z prośbą o ponowną analizę zasadności wymagania dotyczącego obowiązkowej obsługi protokołu TCP
RELP
RELP (Reliable Event Logging Protocol) jest protokołem wykorzystywanym w określonych rozwiązaniach do
niezawodnego transportu komunikatów logowania, jednak jego obsługa nie stanowi uniwersalnego ani obligatoryjnego
elementu funkcjonalnego systemów klasy SIEM. Podstawowym zadaniem platformy SIEM jest zapewnienie możliwości
pozyskiwania zdarzeń, ich przetwarzania, normalizacji, korelacji, analizy oraz wykrywania incydentów bezpieczeństwa,
a realizacja tych funkcji nie jest uzależniona od natywnej obsługi konkretnego protokołu transmisyjnego. Wymaganie
jednoczesnej obsługi UDP/TCP Syslog oraz TCP RELP, w tym jego wariantów szyfrowanych i nieszyfrowanych, wskazuje
na określony sposób realizacji komunikacji ze źródłami danych, zamiast określać funkcjonalność, jaką Zamawiający chce
uzyskać w ramach systemu SIEM. Warto również zwrócić uwagę, że RELP nie jest protokołem powszechnie wymaganym
dla wszystkich źródeł danych wykorzystywanych w środowiskach SIEM, a jego zastosowanie jest w znacznym stopniu
związane z konkretnymi rozwiązaniami i ekosystemami technologicznymi. Tym samym uczynienie z jego obsługi
obligatoryjnego wymagania dla platformy SIEM może prowadzić do nieuzasadnionego ograniczenia liczby rozwiązań
spełniających wymagania postępowania. Jednocześnie Zamawiający wymaga już obsługi UDP/TCP Syslog, które są
powszechnie stosowanymi mechanizmami przekazywania danych logowych i zapewniają szeroką kompatybilność z
urządzeniami oraz systemami bezpieczeństwa i infrastruktury IT. W naszej ocenie wymaganie natywnej obsługi TCP
RELP, zarówno w wariancie szyfrowanym, jak i nieszyfrowanym, nie znajduje wystarczającego uzasadnienia
funkcjonalnego dla systemu klasy SIEM i może skutkować ograniczeniem konkurencji poprzez wyeliminowanie
rozwiązań, które posiadają pełną funkcjonalność SIEM, lecz nie implementują konkretnego protokołu transmisyjnego.
Mając powyższe na uwadze, zwracamy się z pytaniem czy Zamawiający dopuści zmianę wymagania poprzez
usunięcie obowiązku obsługi protokołu TCP RELP, zarówno w wersji szyfrowanej, jak i nieszyfrowanej, pozostawiając
wymóg obsługi protokołów UDP/TCP Syslog?
Uzasadnieniem takiej zmiany jest fakt, że obsługa konkretnego protokołu transmisyjnego, jakim jest RELP, nie
determinuje zdolności systemu do realizacji kluczowych funkcji platformy SIEM, natomiast jego obligatoryjne
wymaganie może nieproporcjonalnie ograniczać konkurencję pomiędzy dostępnymi na rynku rozwiązaniami. Prosimy
zatem o usunięcie wymagania dotyczącego TCP RELP jako obligatoryjnego protokołu obsługiwanego przez oferowany
system SIEM.
Zamawiający, po ponownej analizie zakresu wymagania dotyczącego mechanizmów transmisji danych, dopuszcza
zmianę jego dotychczasowego brzmienia w części odnoszącej się do protokołu TCP RELP. W konsekwencji obsługa TCP
RELP, zarówno w wariancie szyfrowanym, jak i nieszyfrowanym, nie będzie stanowiła wymagania obligatoryjnego, przy
jednoczesnym zachowaniu wymogu obsługi protokołów UDP/TCP Syslog. Ewentualna obsługa TCP RELP przez
oferowane rozwiązanie pozostaje dopuszczalna jako funkcjonalność dodatkowa, niewarunkująca spełnienia wymagań
OPZ.
W pkt. 3. OPZ Zamawiający wymaga: System musi zapewniać przechowywanie danych w dziennikach systemowych
przez okres co najmniej 24 miesięcy od momentu ich zapisu, z możliwością konfiguracji czasu retencji dla wybranych
kategorii informacji.
Czy w celu zwiększenia konkurencyjności Zamawiający dopuszcza realizację wymaganej retencji (co najmniej 24
miesiące) oraz zróżnicowania okresów przechowywania dla poszczególnych kategorii danych w oparciu o odpowiednie
zwymiarowanie infrastruktury oraz rozdział danych na odrębne magazyny, gdzie Logi trafiające do systemu oraz
zdarzenia przechowywane są w plikach płaskich na maszynach realizujących ich składowanie, co zapewnia wydajne i
skalowalne utrzymanie danych merytorycznych przez wymagany okres retencji. Odrębnie prowadzone są dzienniki
diagnostyczne dotyczące działania poszczególnych usług LogCollectora - informacje o pracy tych usług zapisywane są do
dziennika aplikacji na danych maszynach i służą kontroli poprawności funkcjonowania komponentów systemu.
Zamawiający podtrzymuje wymaganie określone w OPZ. System musi zapewniać przechowywanie danych przez okres
co najmniej 24 miesięcy od momentu ich zapisu, z możliwością konfiguracji czasu retencji dla wybranych kategorii
informacji.
Dotyczy zakresu wdrożenia oraz kryteriów prawidłowego wykonania i odbioru wdrożenia
Zamawiający wskazuje, że oferowane rozwiązanie ma zostać dostarczone, wdrożone oraz uruchomione w
środowisku Zamawiającego na koszt Wykonawcy, jednocześnie w dokumentacji postępowania wskazano ogólny zakres
prac związanych z analizą przedwdrożeniową i wdrożeniem, obejmujący m.in.:
− analizę środowiska,
− opracowanie architektury systemu oraz dokumentacji HLD i LLD,
− implementację systemu,
− konfigurację GUI i baz danych,
− zabezpieczenie systemu,
− konfigurację niezbędnych modułów,
− konfigurację ujednolicenia danych,
− optymalizację systemu,
− konfigurację raportów i alertów,
− inne niezbędne konfiguracje do prawidłowego działania systemu,
− przygotowanie dokumentacji powdrożeniowej,
− instrukcję i wsparcie w zakresie podłączania nowych źródeł,
− szkolenie z obsługi systemu.
Ponadto Zamawiający wskazuje, że w ramach instruktażu wymagane jest zaprezentowanie działania Systemu
poprzez jego konfigurację oraz uruchomienie przykładowych źródeł danych, w tym co najmniej 8 źródeł pochodzących
z systemów Microsoft Windows oraz co najmniej 15 źródeł przekazujących logi z wykorzystaniem protokołu Syslog.
W naszej ocenie powyższe zapisy nie definiują jednak w sposób wystarczająco jednoznaczny docelowego zakresu
wdrożenia ani kryteriów, na podstawie których Zamawiający będzie mógł stwierdzić, że wdrożenie zostało wykonane
prawidłowo i zostało zakończone. W szczególności nie określono, jakie konkretne rezultaty wdrożenia mają zostać
osiągnięte, w szczególności w zakresie:
− liczby i rodzaju źródeł danych, które mają zostać docelowo podłączone do systemu, poza wskazanymi
przykładowymi źródłami uruchamianymi w ramach instruktażu;
− zakresu danych, które mają być pozyskiwane z poszczególnych źródeł;
− sposobu konfiguracji poszczególnych źródeł i zakresu prac wymaganych po stronie Wykonawcy oraz
Zamawiającego;
− zakresu normalizacji i ujednolicenia danych;
− wymaganych przypadków użycia (Use Cases) dotyczących wykrywania zagrożeń i incydentów bezpieczeństwa;
− wymaganych reguł korelacyjnych i mechanizmów detekcji;
− wymaganych alertów oraz warunków ich generowania;
− wymaganych raportów, ich liczby, zakresu oraz zawartości;
− wymaganych dashboardów, sposobu prezentacji danych, wykresów oraz innych elementów wizualizacji;
− zakresu konfiguracji systemu wynikającego ze specyfiki środowiska Zamawiającego;
− wymaganych integracji z innymi systemami Zamawiającego;
− parametrów, funkcjonalności lub scenariuszy, które będą podstawą odbioru wdrożenia.
Zamawiający podtrzymuje zakres oraz sposób realizacji wdrożenia określony w OPZ, wskazując jednocześnie, że
poszczególne wymagania należy interpretować łącznie z przewidzianym etapem analizy przedwdrożeniowej, której
rezultatem jest m.in. opracowanie architektury Systemu oraz dokumentacji HLD i LLD. Dokumenty te mają służyć
uszczegółowieniu przyjętej koncepcji wdrożenia, sposobu realizacji wymagań funkcjonalnych i integracyjnych oraz
zakresu konfiguracji wynikającego z rzeczywistej charakterystyki środowiska Zamawiającego, w tym w zakresie
dashboardów, raportów, alertów, reguł korelacyjnych i pozostałych elementów niezbędnych do prawidłowego
W pkt. 4.1 OPZ Zamawiający wymaga: Oferowany system musi zapewniać dostęp poprzez interfejs webowy,
umożliwiający administratorom oraz operatorom korzystanie ze wszystkich dostępnych funkcjonalności Systemu
Czy Zamawiający uzna wymaganie za spełnione poprzez udostępnienie funkcjonalności Systemu w ramach interfejsu
webowego w zakresie konsoli operatora oraz widoku podstawowego - obejmującym obsługę incydentów, podatności,
analizę behawioralną, przeglądanie logów, dashboardy, raportowanie oraz zarządzanie konfiguracją Systemu - przy
zapewnieniu pełnego dostępu do wszystkich funkcjonalności z poziomu aplikacji Desktop?
Zamawiający dopuszcza wykorzystanie aplikacji Desktop wyłącznie jako uzupełnienia interfejsu webowego. Aplikacja
Desktop nie może zastępować dostępu do funkcjonalności Systemu wymaganych z poziomu interfejsu webowego
zgodnie z OPZ.
Pokazujemy 6 z 20 pytań. Komplet wyjaśnień — razem z załącznikami, których dotyczą — jest w dokumentacji postępowania.
