Przejdź do treści
Załóż darmowe kontoDarmowe konto
← Wróć do listy
RozstrzygniętyPodstawowy bez negocjacji2026/BZP 00384150/01

Dostawa i wdrożenie systemu SIEM – Radom

Powiat Radomski0 aktualnych · 20 w archiwum·NIP 9482604208·mazowieckie
Składanie ofert: 19 sierpnia 2026

Rozstrzygnięcie

Kto wygrał, za ile i ilu było chętnych.

WygrałaNomios Poland Sp. z o.o.
NIP zwycięzcy1070021226
Kwota oferty218 940,00 zł
Złożonych ofert3, w tym odrzuconych: 2
Widełki ofert218 940,00 zł – 218 940,00 zł
Najtańsza oferta wygrałatak

Przedmiot zamówienia

AI
  • 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

Trudność: średnia

Zamówienie obejmuje kompleksowe wdrożenie systemu SIEM z integracją kilkuset źródeł, wymogiem wysokiej wydajności, tworzeniem parserów, agentami, długą retencją danych i 24‑m serwisem — wymaga doświadczenia wdrożeniowego i koordynacji wielu komponentów.

Terminy realizacji

Termin wykonania
maksymalnie 21 dni od dnia zawarcia umowy

Warunki udziału

AI
1Doświadczenie — Wykonawca wykonał należycie w okresie ostatnich 3 lat (lub krótszym gdy prowadzi działalność krócej) co najmniej 2 zadania polegające 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.
2Wykaz usług (referencje) — Wykonawca przedkłada wykaz wykonanych zamówień zawierający informacje o rodzaju, wartości, dacie wykonania oraz podmiotach, na rzecz których usługi zostały wykonane, wraz z dowodami potwierdzającymi należyte wykonanie (np. referencje) i w razie jednej umowy wyodrębnia rodzajowo i kwotowo zakres wykazujący spełnienie warunku.

Pozostałe 9 warunków po założeniu darmowego konta.

Kryteria wyboru oferty

AI

Wagi punktowe, według których zamawiający oceni oferty.

Cena oferty bruttocałkowita cena brutto
60%
Okres gwarancji i rękojmi na cały zakres zamówieniaokres w miesiącach
20%
Doświadczenie zawodowe osoby skierowanej do realizacji wdrożenialiczba wykonanych wdrożeń
20%

Czerwone flagi

AI

Sygnały, na które warto zwrócić uwagę przed startem.

SWZ zmodyfikowany 8 dni po udostępnieniu dokumentów
Późna modyfikacja specyfikacji może sugerować dostosowanie wymagań pod konkretnego wykonawcę lub celowe utrudnienie konkurencji, która przygotowała ofertę na pierwotną wersję SWZ.
Termin składania ofert przypada na okres wakacyjny (18 sierpnia)
Termin w okresie wakacyjnym (lipiec-sierpień) może ograniczać liczbę oferentów ze względu na urlopy.

Kary i sankcje

AI
  • Brak zapisu o karach umownych w treści SWZ ani w projekcie umowy: — s. ?

Pytania i odpowiedzi

20

Wyodrębnione z wyjaśnień treści SWZ.

1Dotyczy 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.
1W 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.
2Dotyczy 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.
2W 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.
3Dotyczy 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
3W 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.

Historia zmian

10.08.2026 — publikacja ogłoszenia
18.08.2026 — wyjaśnienia i modyfikacja dokumentacji (3 dokumenty z wyjaśnieniami · 1 modyfikacja dokumentacji)
19.08.2026 — upływ terminu składania ofert
23.09.2026 — ogłoszenie o wyniku postępowania
Janusz wypełni Twoje przetargiWgraj SWZ — dostaniesz warunki, wycenę i komplet dokumentów. 14 dni za darmo, bez karty.
Wypróbuj 14 dni