KIO 975/22 WYROK dnia 22 kwietnia 2022 r.

Sygn. akt: KIO 975/22 

WYROK 

z dnia 22 kwietnia 2022 r. 

Krajowa Izba Odwoławcza - w składzie: 

Przewodniczący:   Agnieszka Trojanowska 

Protokolant:   

Marta Słoma 

po rozpoznaniu na rozprawie w Warszawie w dniu 22 kwietnia 

2022 r. odwołania wniesione-

go 

do Prezesa Krajowej Izby Odwoławczej w dniu 8 kwietnia 2022 r. przez wykonawcę Eu-

roCert spółka z ograniczoną odpowiedzialnością z siedzibą w Warszawie, ul. Puławska 

postępowaniu prowadzonym przez zamawiającego  –  Skarb  Państwa  -  Zakład  Ubez-

pieczeń Społecznych z siedzibą w Warszawie, ul. Szamocka 3,5 

przy udziale 

wykonawcy Enigma System Ochrony Informacji spółka z ograniczoną od-

powiedzialnością  z  siedzibą  w  Warszawie,  ul.  Jutrzenki  116  zgłaszającego swoje przy-

stąpienie w sprawie sygn. akt KIO 975/22 po stronie zamawiającego  

orzeka: 

Uwzględnia odwołanie w całości i nakazuje zamawiającemu unieważnienie czynności 

wyboru oferty najkorzystniejszej,  unieważnienie czynności  badania i  oceny oferty,  w 

tym  unieważnienie  czynności  odrzucenia  oferty  EuroCert  spółka  z  ograniczoną  od-

powiedzialnością z siedzibą w Warszawie, ul. Puławska 474, i nakazuje powtórzenie 

czynności badania i oceny ofert z uwzględnieniem oferty odwołującego,  

kosztami postępowania obciąża zamawiającego  –  Skarb  Państwa  -  Zakład  Ubez-

pieczeń Społecznych z siedzibą w Warszawie, ul. Szamocka 3,5 i:   

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ę 

EuroCert 

spółka  z  ograniczoną  odpowiedzialnością  z  siedzibą  w  War-

szawie, ul. 

Puławska 474 tytułem wpisu od odwołania, 

zasądza od zamawiającego  –  Skarb  Państwa  -  Zakład  Ubezpieczeń  Spo-

łecznych  z  siedzibą  w  Warszawie,  ul.  Szamocka  3,5  na  rzecz  EuroCert 

spółka  z  ograniczoną  odpowiedzialnością  z  siedzibą  w  Warszawie,  ul. 

Puławska 474  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 ponie-

sione z tytułu wpisu i wydatków pełnomocnika 

Stosownie  do  art.  579  ust.  1  i  580  ust.  1  i  2  ustawy  z  dnia 

11  września  2019  r.  Prawo 

zamówień  publicznych  (Dz.  U.  z  2021  r.,  poz.  1129  z  późn.  zm.)  na  niniejszy  wyrok  -  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. 

Przewodniczący:…………………………. 

 
Sygn. akt KIO 975/22 

Uzasadnienie 

Postępowanie o udzielenie zamówienia w trybie przetargu nieograniczonego na „Zakup kwa-

lifikowanych  usług  zaufania  –  zakupi  instalacja  dwóch  urządzeń  HSM,  zakup  licencji  na 

oprogram

owanie,  zakup  certyfikatów  kwalifikowanych e‐pieczęć”  zostało wszczęte  ogłosze-

niem  opublikowanym  w  Dzienniku  Urzędowym  Unii  Europejskiej  za  numerem  Dz.U./S  233 

613075 z dnia 1 grudnia 2021 r.  

W dniu 31 marca 2022 r. zamawiający poinformował o wynikach postępowania, w tym o od-

rzuceniu oferty wykonawcy EuroCert spółka z ograniczoną odpowiedzialnością z siedzibą w 

Warszawie na podstawie art. 226 ust. 1 pkt 5 ustawy. 

W dniu 8 kwietnia 2022 

r. odwołanie wniósł wykonawca EuroCert spółka z ograniczoną od-

powiedzia

lnością  z  siedzibą  w  Warszawie,  ul.  Puławska  474.  Odwołanie  zostało  wniesione 

przez prezesa 

zarządu zgodnie z zasadami reprezentacji ujawnionymi w odpisie z KRS. Od-

wołanie zostało przekazane zamawiającemu w dniu 8 kwietnia 2022 r.  

Wniósł odwołanie 

od niezgodnej z przepisami ustawy 

czynności zamawiającego, polegają-

cych na: 

1) odrzuceniu oferty 

odwołującego, pomimo iż odwołujący złożył ofertę zgodną z wymogami 

zawartymi  w  SWZ;  2)  na  wyborze  jako  najkorzystniejszej  oferty  Enigma  System  Ochrony 

Informacji Sp. z o.o. 

z siedzibą w Warszawie mimo iż wykonawca ten zaoferował cenę wyż-

szą niż zawarta w ofercie odwołującego, która jest ważna, nie podlegająca odrzuceniu i po-

winna być uznana za najkorzystniejszą.  

Odwołujący zarzucił zamawiającemu naruszenie następujących przepisów:  

1. art. 226 ust. 1 pkt 5 ustawy przez odrzucenie oferty 

odwołującego pod zarzutem, że treść 

tej oferty jest niezgodna z warunkami zamówienia, tj. a. pkt II Załącznika nr 1 ‐ Opis Przed-

miotu  Zamówienia  (dalej:  „OPZ”)  do  Projektowanych  postanowień  umowy  (stanowiących 

Załącznik  nr  2  do  SWZ).  Wedle twierdzenia  zamawiającego  zawarto  tam  wymóg  przedsta-

wienia  w 

ofercie  oprogramowania  w  zakresie  oferowanych  przez  wykonawcę  licencji.  Tym-

czasem, pkt II Załącznika nr 1 do OPZ zawiera wskazanie wymagań dotyczących oprogra-

mowania,  notabene  spełnionych  przez  odwołującego,  a  nie  wskazania  co  do  sposobu  wy-

pełnienia  formularza  ofertowego;  b.  rzekomego  obowiązku  wskazania  konkretnych  nazw 

własnych licencji na oprogramowanie wpisanych do Tabeli nr 1 w Załączniku nr 1 do SWZ – 

Formularz  ofertowy (Formularz  Ceno

wy), w poz. 2, 3 i 7 pomimo iż SWZ w żadnym posta-

nowieniu nie wymaga wskazania tych danych; 

c. rzekomego obowiązku dostarczenia więcej 

niż  jednej  licencji  na  systemy  operacyjne  i  motory  bazodanowe,  podczas  gdy  SWZ  w  żad-

nym  postanowieniu  nie  wprowadza  minim

alnych  parametrów  ilościowych  dla  tego  oprogra-

mowania;  

2. art. 239 ust. 1 i ust. 2 ustawy przez wybór oferty mniej korzystnej niż oferta odwołującego, 

pomimo tego, iż oferta odwołującego była ważna i nie podlegała odrzuceniu.

Wniósł o:  

1. uwzględnienie odwołania w całości;  

2. nakazanie 

zamawiającemu unieważnienie czynności odrzucenia oferty odwołującego;  

3. nakazanie 

zamawiającemu unieważnienie czynności wyboru oferty najkorzystniejszej;  

4. nakazanie za

mawiającemu powtórzenia czynności oceny ofert; 

5. nakazanie 

zamawiającemu dokonania wyboru oferty odwołującego jako najkorzystniejszej. 

Odwołujący  wskazał, że  posiada interes  we wniesieniu odwołania  –  w  przypadku  prawidło-

wego działania zamawiającego oferta odwołującego zostałaby uznana za ofertę najkorzyst-

niejszą.  W  wyniku  naruszenia przez zamawiającego  przepisów  ustawy  Pzp  odwołujący po-

niesie szkodę, bowiem utraci szansę na zawarcie umowy w sprawie zamówienia publiczne-

go, a tym samym nie uzyska wynagrodzen

ia z tytułu jego realizacji. Powyższe niezbicie do-

wodzi naruszenia interesu 

odwołującego w uzyskaniu niniejszego zamówienia i stanowi wy-

starczającą  przesłankę  do  skorzystania  przez  odwołującego  ze  środków  ochrony  prawnej 

przewidzianych w ustawy.  

Jak wynika z informa

cji z otwarcia ofert z dnia 12 stycznia 2022 r., wykonawca Enigma złożył 

ofertę z ceną 1.495.668,93 zł, zaś odwołujący z ceną 1.062.720,00 zł. Cena oferty Enigma 

jest  więc  o  432.948,93  zł  (41%)  wyższa  od  oferty  odwołującego.  Ponieważ  zamawiający 

ustalił

cenę jako jedyne kryterium oceny ofert, oferta odwołującego powinna zostać uznana 

za 

najkorzystniejszą.  Pismem  z  dnia  31.03.2022  r.,  zamawiający  poinformował  o  wyborze 

oferty  Enigma  z  ceną  1.495.668,93  zł.  Jednocześnie,  poinformował  o  odrzuceniu  tańszej 

oferty odw

ołującego. Jako podstawę wskazał art. 226 ust. 1 pkt 5 ustawy, przy czym wskazał 

na rzekomą niezgodność oferty odwołującego z SWZ, mającą polegać na niewskazaniu na-

zwy oprogramowania w poz. 2, 3 oraz 7 tabeli Formularza ofertowego oraz wskazanie tylko 

jednej licencji na systemy operacyjne i motory bazodanowe.  

Dodatkowo, z

amawiający stwierdził, że uważa za niemożliwe ustalenie czy oferowane przez 

odwołującego  rozwiązanie  jest  zgodne  z  tym,  które  odwołujący  planuje  wdrożyć.  Jeżeli  to 

stwierdzenie 

zamawiającego należałoby traktować jak zarzut, na co wskazywałoby zawarcie 

go  w  uzasadnieniu  czynności  odrzucenia  oferty,  to  należałoby  jednocześnie  stwierdzić,  że 

zarzut ten nie tylko jest pozbawiony oparcia w przepisach ustawy, ale 

również jest nielogicz-

ny  i  nieuzasadniony.  Brak  bowiem  jakichkolwiek 

przesłanek  dla  uznania,  że  odwołujący 

miałby zamiar wdrożyć inne rozwiązanie niż to, które wycenił i opisał w składanej zamawia-

jącemu ofercie. Co więcej, w przypadku udzielenia zamówienia odwołującemu zamawiający 

byłby w takiej sytuacji chroniony postanowieniami zawartej umowy. Ewentualne odstępstwo 

od  postanowień  umowy  stanowiłoby  jej  niewłaściwe  wykonanie,  co  skutkowałoby  powsta-

niem roszczenia po stronie 

zamawiającego. Oczywiście, są to rozważania czysto akademic-

kie,  a  sam  z

amawiający  nie  wskazał,  poza  odwołaniem  się  do  własnego  przekonania,  dla-

czego podejrzewa 

odwołującego o zamiar wdrożenia rozwiązania innego niż oferowane.  

Ewentualnie,  zarzut 

zamawiającego  można  interpretować  w  ten  sposób,  że  na  podstawie 

danych  wskazanych  w  formularzu  ofertowym  nie  potrafi  on  precyzyjnie  ustalić  szczegółów 

proponowanego  rozwiązania.  W  ocenie  odwołującego  należy  jednak  mieć  na  uwadze,  że 

oferta  zost

ała  sporządzona  w  oparciu  o  warunki  zamówienia  określone  przez  samego  za-

mawiającego. Na mocy art. 99 ust . ustawy, to zamawiający opisuje przedmiot zamówienia i 

ma obowiązek uczynić to w sposób jednoznaczny i wyczerpujący, za pomocą dostatecznie 

dokładnych  i  zrozumiałych określeń,  uwzględniając wymagania i  okoliczności mogące  mieć 

wpływ na sporządzenie oferty. Jeżeli oferta, sporządzona zgodnie z dokumentacją postępo-

wania  opracowaną  przez  samego  zamawiającego,  zawierająca  wszystkie  żądane  w  SWZ 

informacje i 

przewidująca wprowadzenie rozwiązań zgodnych z OPZ, pozostawia zamawia-

jącemu pole do wątpliwości co do ostatecznego kształtu przedmiotu zamówienia, oznacza to, 

że być może zamawiający sam niewystarczająco sprecyzował swoje potrzeby. Okoliczność 

ta nie może jednak  obciążać

wykonawców,  którzy  oferują  rozwiązanie, które  być może nie 

spełnia nie wyrażonych w warunkach postępowania oczekiwań zamawiającego.  

Dot. wpisania nazwy oprogramowania  

Zamawiający  określił  wymogi  w  zakresie  dostarczenia  licencji  dla  oprogramowania  middle-

ware oraz oprogramowania SDK w pkt II. ppkt 1 i 2 OPZ

. Nie wskazał tam na konieczność 

opisu  proponowanego  rozwiązania  za  pomocą  nazw  własnych  oprogramowania  dostarcza-

nego  wraz  z  urządzeniami  HSM.  Takiego  zapisu  brak  również  w  pozostałych  postanowie-

niach  SWZ.  Jednocześnie,  zamawiający  wprost  dopuszcza  stosowanie  oprogramowania 

typu open source, z tym zastrzeżeniem, że w przypadku jego użycia to wykonawca będzie 

świadczył  usługę  serwisu,  zastępującą  wsparcie  techniczne  producenta  komercyjnie  ofero-

wanego oprogramowania. Oprogramowanie stworzone na otwartej licen

cji może, po prostu, 

nie posiadać zastrzeżonej nazwy własnej, którą można by wprowadzić do Formularza ofer-

towego.  Ponieważ  jest  to  możliwość  dopuszczona  wprost  w  postanowieniach  SWZ,  to  jej 

wykorzystanie w ofercie nie może być przez zamawiającego uznane za niezgodne z warun-

kami postępowania.  

Również wzór umowy określony w załączniku nr 2 do SWZ nie zawiera miejsca na wpisanie 

danych takich jak nazwa własna oprogramowania middleware, oprogramowania SDK czy też 

systemów operacyjnych i motorów bazodanowych. Umowa, tak jak SWZ, opisuje obowiązek 

dostarczenia przez wykonawcę bezterminowych licencji zgodnych z OPZ.  

Jedynym miejscem, w którym pojawia się termin „nazwa oprogramowania” są umieszczone 

w nawiasach adnotacje pod tekstem w komórkach pierwszej kolumny Tabeli 1 Załącznika nr 

1 do SWZ Formularza Oferty (Formularz Cenowy). Nie można jednak uznać tej wzmianki za 

określenie wymogu użycia nazwy  własnej  pod rygorem  odrzucenia oferty,  a  za  wskazówkę 

do  użycia  jej,  jeśli  jest  dostępna,  czyli  przy  zaoferowaniu  oprogramowania  komercyjnego, 

zakupionego od producenta innego niż wykonawca. Niezależnie od powyższego, faktem jest, 

iż w poz. 2 i poz. 3 Tabeli nr 1 odwołujący wskazał, że dostarczy licencję na „oprogramowa-

nie  producenta  HSM”.  W  pozycji  1  wskazał,  że  dostarczy  urządzenia  „Luna  Network  HSM 

S700”. Jest to określenie precyzyjnie i wyczerpująco wskazujące na oprogramowanie, które 

będzie użyte w proponowanym zamawiającemu rozwiązaniu. W warunkach rynkowych Wy-

konawca  nie 

zna  przypadków,  gdzie  jest  dostarczone  inne  oprogramowanie  niż  gwaranto-

wane przez 

producentów urządzeń. Stanowi to kanon tego typu dostaw.

Odwołujący zwrócił uwagę na to, że analogicznie postąpił wykonawca Enigma, który również 

zaproponował dostarczenie urządzeń Luna Network HSM S700. W pozycji 2 Tabeli 1 wska-

zał  on  licencje  określone  jako  „Luna  Network  Client  Licenses”  co  stanowi  tłumaczenie  na 

język  angielski  określenia  „licencje  klienta  Luna  Network”.  Jeżeli  zamawiający  uważa,  że 

określenie  nazwy  dostarczanego  oprogramowania  przez  wskazanie  nazwy  producenta  ob-

sługiwanych  urządzeń  HSM  stanowi  naruszenie  postanowień  SWZ,  to  powinien  odrzucić 

również ofertę wykonawcy Enigma. Zamiast tego, uznał ją za ważną i najkorzystniejszą, po-

mimo tego, iż zawiera tę samą rzekomą niezgodność, a przy tym jest znacznie droższa.  

Reasumując, niewskazanie konkretnej nazwy własnej proponowanego oprogramowania nie 

stanowi o niezgodności oferty z warunkami zamówienia i nie mogło stanowić podstawy do jej 

odrzucenia.  

Dot. liczby licencji na systemy operacyjne i motory bazodanowe  

Wymogi dotyczące licencji na systemy operacyjne i motory bazodanowe opisano w OPZ w 

pkt.  II.  Pkt II  ppkt  7 OPZ przewiduje,  że  wykonawca ma dostarczyć  „niezbędne  licencje  na 

systemy  operacyjne  i  motory  bazodanowe  z  minimalnym  3

‐letnim  wsparciem  technicznych 

producenta.  W  przypadku  użycia  w  Rozwiązaniu  systemów  operacyjnych  lub  motorów  ba-

zowanych  z  licencją  otwartą  (open  source)  wykonawca  będzie  świadczył  usługę  serwisu 

przez okres u

mowy”.  

Zamawiający  ani  w  OPZ,  ani  w  innym  miejscu  w  SWZ  nie  zawarł  jakichkolwiek  wymogów 

ilościowych dotyczących tego rodzaju licencji. Co więcej, w Formularzu ofertowym ilość tych 

licencji jest pozostawiona do uzupełnienia przez wykonawców (również bez żadnych dodat-

kowych  informacji  o  minimalnej  liczbie).  Każdemu  wykonawcy  pozostawiono  więc  pełną 

swobodę w doborze liczby licencji właściwej dla proponowanego rozwiązania.  

Odwołujący  miał  na  uwadze,  że  w  OPZ  zamawiający  wyraźnie  wskazuje,  ilekroć  wymaga 

spełnienia minimalnych, w tym ilościowych, wymogów do zamawianych urządzeń i oprogra-

mowania. Np. w pkt I ppkt 24 w odniesieniu do zasilacza hot

‐swap urządzenia HSM wyraźnie 

zapisał, że każde z urządzeń musi być wyposażone w min. 2 zasilacze. W pkt II w ust. 4 ppkt 

1 wskazał, ile urządzeń HSM równolegle ma minimalnie obsługiwać oprogramowanie klienc-

kie.  Ponieważ  na  zamawiającym  spoczywa  obowiązek  opisania  przedmiotu  zamówienia  w 

sposób  precyzyjny i jednoznaczny,  to  jeśli  wprowadza  minimalne  wymogi  ilościowe jedynie 

dla niektórych pozycji opisanych w OPZ, to a contrario, dla pozycji opisanych bez wskazania 

takich minimalnych wymagań, należy uznać, że nie zostały one w żaden sposób określone. 

Nie można też domniemywać

istnienia takich niezastrzeżonych wprost wymagań np. na pod-

stawie  liczby  mnogiej 

użytej  przez  zamawiającego  w  opisie.  Reasumując,  zamawiający  nie 

zawarł w SWZ wymogu dostarczenia więcej niż jednej licencji na systemy operacyjne i moto-

ry bazodanowe. Oferta 

odwołującego, który wskazał na dostarczenie jednej licencji, spełnia-

jącej wymogi określone w pkt II ppkt 7 OPZ, nie może więc być w tym zakresie uznana za 

niezgodną z warunkami zamówienia. Ponadto, oferta odwołującego nie może, wbrew twier-

dzeniom  zamawia

jącego,  być  uznana  za  budzącą  wątpliwości  co  do  jej  przedmiotu.  Biorąc 

pod uwagę wpisaną w treść oferty nazwę oferowanego produktu, tj. 2 urządzenia Luna Ne-

twork  HSM  S700  oraz 

zakres tego rozwiązania, wynikający z  liczby udzielonych licencji  na 

system  operacyjny  i 

motory  bazodanowe  (pojedyncza  licencja),  nie  ma  wątpliwości  co  do 

tego,  że  przedmiotem  oferty  jest  rozwiązanie  HSM,  wraz  z  zapewniającą  możliwość  jego 

zgodnego z SWZ wykorzystania opensourcową licencją.  

Sposób opisu oferty, sporządzonej zresztą wedle wzoru narzuconego przez zamawiającego, 

wyklucza wszelkie wątpliwości co do przedmiotu tej oferty. Każde inne rozwiązanie, nie opar-

te na modelu dającym możliwość kopiowania rozwiązania w oparciu o jedną (otwartą) licen-

cję, wymagałoby opisania za pomocą innych wartości. Nie ma wiec podstaw ani nawet moż-

liwości, aby zamawiający mógł w tym zakresie nabrać uzasadnionych wątpliwości. Inne niż 

proponowane przez 

odwołującego rozwiązania zwyczajnie nie mieściłyby się w zakresie zło-

żonej  oferty.  Jak  już  wyżej  wspomniano,  ewentualne,  subiektywne  przeświadczenie  osób 

oceniających  oferty  po  stronie  zamawiającego,  że  wykonawca  mógłby  jednak  chcieć  reali-

zować  umowę  w  inny  niż  podany  w  formularzu  ofertowym  sposób,  pozostaje  pozbawione 

jakichkolwie

k logicznych podstaw i nie może mieć wpływu na wynik postępowania. Odwołu-

jący  przypomniał,  że  również  ewentualne  nieścisłości  w  opisie  przedmiotu  zamówienia  po-

pełnione przez samego zamawiającego, a zidentyfikowane przezeń dopiero na etapie oceny 

ofert,  nie 

mogą  być  interpretowane  na  niekorzyść  odwołującego.  Stanowisko  takie  zostało 

jasno  wyrażone  m.in.  w  uchwale  Krajowej  Izby  Odwoławczej  z  dnia  3  sierpnia  2017  r.  w 

sprawie o sygn. KIO/KD 38/17. 

Reguła ta wynika z prawniczej paremii »In dubio contra pro-

feren

tem«  znaczącej  w  języku  polskim  »Wątpliwości  należy  tłumaczyć  przeciw  autorowi«. 

Nie ulega wątpliwości, że Zamawiający jest autorem ogłoszenia o zamówieniu i SIWZ, które 

z

ostały zredagowane

przez 

zamawiającego”. Podobnie orzekł Sąd Okręgowy w Nowym Są-

czu w wyroku z dnia 18 marca 2015 r., III Ca 70/15. 

Z  powyższego  jasno  wynika,  że działanie  zamawiającego,  polegające  na  odrzuceniu  waż-

nej,  pra

widłowo  sporządzonej,  i  gwarantującej  realizację  przedmiotu zamówienia  zgodnie z 

SWZ oferty 

odwołującego i wyborze dużo droższej oferty wykonawcy Enigma, było niezgod-

ne z prawem i narusza wskazane w odwołaniu przepisy ustawy.  

W dniu 11 kwietnia 2022 r. z

amawiający poinformował o wniesieniu odwołania.  

W dniu 13 kwietnia 2022 r. do postępowania odwoławczego po stronie zamawiającego zgło-

sił  się  wykonawca  Enigma  System  Ochrony  Informacji  spółka  z  ograniczoną  odpowiedzial-

nością z siedzibą w Warszawie, ul. Jutrzenki 116 wnosząc o oddalenie odwołania. Przystę-

pujący wskazał, że ma interes w rozstrzygnięciu korzystnym dla zamawiającego, gdyż jego 

oferta została wybrana, a odwołujący zmierza do przywrócenia swojej oferty do postępowa-

nia,  co może  wpłynąć  na interes  przystępującego.  Zgłoszenie zostało wniesione przez peł-

nomocnika działającego na podstawie pełnomocnictwa z dnia 11 kwietnia 2022 r. udzielone-

go  przez  prezesa  i  wiceprezesa  zarządu  zgodnie  zasadami  ujawnionymi  w  KRS.  Do  zgło-

szenia dołączono dowody przekazania kopii zgłoszenia stronom.  

W  dniu  21  kwietni

a  2022 r.  zamawiający złożył odpowiedź  na  odwołanie,  w  której  wniósł  o 

oddalenie  odwołania  w  całości  i  obciążenie  kosztami  postępowania  odwołującego,  w  tym 

kosztami zastępstwa procesowego. Zamawiający wskazał, że przedmiotem zamówienia jest 

zakup kwalifiko

wanych usług zaufania – zakup instalacji dwóch urządzeń HSM, zakup licen-

cji  na  oprogramowanie,  zakup  certyfikatów  kwalifikowanych  e-pieczęć.  Z  OPZ  wynika,  że 

wykonawca jest odpowiedzialny za stworzenie i dos

tarczenie rozwiązania tj. kompleksowego 

systemu z

apewniającego obsługę opatrywania kwalifikowanymi pieczęciami elektronicznymi 

dokumentów tworzonych w systemach i oprogramowaniu ZUS zgodnie z art. 1 ust. 1 Dyrek-

tywy  wykonawczej  Komisji  (UE)  2016/650  z  dnia 

25  kwietnia  2016  r.  eIDAS.  Zamawiający 

określił  wymogi  jakie  musi  spełniać rozwiązanie w  załączniku nr  1 OPZ zer szczegółowymi 

wytycznymi co do oferowanych 

urządzeń, oprogramowania, usługi znakowania czasem, pro-

cesu  wdrożenia  i  pozostałych.  Z  SWZ  wynika,  że  zamawiający  wymagał  jednoznacznego 

wskazania  nazwy  oferowanego  oprogramowania  (formularz  ofertowy  Tabela  1  poz.  2,3,  7) 

Wbrew twierdzeniom odwołującego brak wskazania oprogramowania, które spełnia wymogi 

określone  w  pkt.  II  Szczegółowe  wymagania  dotyczące  oprogramowania  Załącznika  nr  1  – 

OPZ uniemożliwia ocenę zaproponowanego rozwiązania. Zamawiający oceniając treść ofer-

ty musi mieć jasność, co do zaoferowanych rozwiązań, nie może polegać na zapewnieniach, 

które próbuje wykazywać odwołujący w uzasadnieniu odwołania, że zamawiający jest chro-

niony postanowieniami umowy, a ewentualne 

odstępstwo od postanowień umowy stanowiło-

by jej niewłaściwe wykonanie, co skutkowałoby powstaniem roszczenia po stronie zamawia-

jącego. W dalszej części odwołujący wskazuje, że to na zamawiającym spoczywa obowiązek 

opisania prz

edmiotu zamówienia, w sposób jednoznaczny i wyczerpujący i skoro zamawiają-

cy  ma  wątpliwości,  co  do  kształtu  zamówienia,  być  może  niewystarczająco  zostały  sprecy-

zowane  jego  potrzeby.  Jak  wynika  z  przedstawion

ego  stanowiska  zamawiającego  i  doku-

mentów  przetargowych, wymogi  zostały  jasno i precyzyjnie określone.  Na wykonawcy  spo-

czywał obowiązek wskazania oprogramowania, które oferuje, odwołujący tergo wymogu nie 

spełnił. Przy tym sam odwołujący w treści odwołania przyznał w pkt. 6, że zamawiający okre-

ślił  wymóg  w  zakresie dostarczenia licencji  na  oprogramowanie middleware  oraz  SDK.  Po-

równując ofertę odwołującego z ofertą przystępującego można stwierdzić, że przystępujący 

wykonał wymagania zamawiającego i wskazał oprogramowanie, które zamierza zaoferować. 

Ponadto 

odwołując  się  wprost  do  treści  formularza  ofertowego  (tabela  1)  załącznika  nr  1 

OPZ  oraz  treści  projektowanych  postanowień  umowy,  jasno  z  nich  wynika,  że  wykonawca 

był zobowiązany do wskazania konkretnego oprogramowania.  

Każde  oprogramowanie  ma  swoją  nazwę,  w  tym  oprogramowanie  stworzone  na  otwartej 

licencji  (typu  open  source).  Kwestia  zastrzeżenia  nazwy  własnej  nie  ma  tu  zastosowania. 

Wykonawca  w  poz.  2,3,  7 formularza  ofertowego,  nie  zawarł  również  informacji  o  zastoso-

wa

niu  oprogramowania  bez  nazwy,  wskazując  choćby  nazwę  producenta  lub  własną.  Nie 

sposób się zgodzić z odwołujący, że sam wzór umowy nie zawiera miejsca na wpisanie da-

nych takich  jak  nazwa  oprogramowania middleware,  oprogramowania  SDK,.  Czy  t

eż syste-

mów operacyjnych i motorów bazodanowych. Wymóg wskazania oprogramowania wynika z 

treści załącznika nr 11 do umowy tj. formularza ofertowego, jak również na powyższe wska-

zuje treść par. 1 ust. 1 pkt 2 projektowanych postanowień umowy, gdzie pod oznaczeniem 

sprzedaż  i  dostawa  oprogramowania  dla  usługi  opatrywania  pieczęciami  kwalifikowanymi 

dokumentów elektronicznych wskazano pozycje wykropkowane, które podlegać będą wypeł-

nieniu przez wpisanie nazwy oprogramowania. Nie sposób się zgodzić z odwołującym jakoby 

termin  „nazwa  oprogramowania”  nie  stanowił  wymogu  formalnego  oferty,  a  jedynie  wska-

zówkę do  użycia,  jeśli  jest  dostępna,  czyli  przy  zaoferowaniu oprogramowania  komercyjne-

go

, zakupionego od producenta innego niż wykonawca. Treścią oferty jest zarówno opis, jaki 

i c

harakterystyka wymaganych elementów w formularzu ofertowym , jak i określenie modeli, 

ilości i cen w formularzu cenowym. W innych pozycjach formularza cenowego odwołujący nie 

miał problemu ze wskazaniem nazw urządzeń i oprogramowania. Na etapie przed złożeniem 

ofert żaden wykonawca nie miał wątpliwości, co do terminu nazwa oprogramowania” i cha-

rakteru jego użycia w formularzu ofertowym. Żadne pytanie do treści formularza nie pojawiło 

się.  Zamawiającemu  nie jest  znany kanon  wdrożenia rozwiązania dla  zaoferowanego  urzą-

dzenia  Luna  Network  HSM  S700,  albowiem  proces  wdrożenia  przeprowadza  wykonawca. 

Zamawiający wiedzę o ofercie opiera na zaproponowanym rozwiązaniu oceniając jego zgod-

ność  z  postanowieniami SWZ  oraz na  podstawie poprawnie wypełnionego  formularza  ofer-

towego.  

Według zamawiającego odwołujący był zobowiązany do wskazania nazwy licencji na syste-

my  operacyjne  i  motory  bazodanowe,  czego  nie  uczynił.  Wedle  wiedzy  zamawiającego  na 

rynku nie istnieje jedna licencja open source, która mogłaby mieć zastosowanie do tego roz-

wiązania,  a  brak  wskazania  licencji  uniemożliwia  ocenę,  czy  zaproponowane  rozwiązanie 

spełnia wymogi określone w SWZ. Co do ilości zamawiający wskazał na pkt. 5 pkt. II szcze-

gółowe  wymagania  dotyczące  oprogramowania  wyjaśniając,  że  wysoką  dostępność  należy 

rozumieć jako eliminację pojedynczych punktów awarii, co wymusza na dostawcy dostarcze-

nie  dwóch  takich  samych  urządzeń,  posiadających  stosowne  licencje  dla  każdego  z  urzą-

dzeń.  Wdrożenie  w  trybie  wysokiej  dostępności  oznacza  budowanie  nadmiarowości  w  roz-

wiązaniu (w liczbie większej niż 1), tak aby awaria komponentu (jednego systemu operacyj-

nego  lub  motoru  bazodanowego)  nie  oznaczała  awarii  całego  rozwiązania).  Zamawiający 

powołał wyrok KIO sygn. akt KIO 2159/21 i KIO 1024/21.  

Z

daniem zamawiającego uchybienia oferty odwołującego są nieusuwalnymi błędami w ofer-

cie.  

W dniu 21 kwietnia 2022 r. przystępujący przedstawił pisemne stanowisko wnosząc o odda-

lenie  odwołania.  Wskazał,  że  było  wyraźne  wymaganie  wypełnienia  Tabeli  we  wskazanych 

pozycjach - 

podkreślonych dodatkowo „wykropkowaną” linią i jednoznaczną instrukcją, iż jest 

to miejsce przeznaczone na podanie przez Wykonawców „nazwy oprogramowania”. Wymóg 

ten  nie  mógłby  być  określony  bardziej  jednoznacznie  jako  żądanie  uzupełnienia  opisu 

przedmiotu zakupu w kolumnie 1 o nazwy  konkretnie oferowanych przez  w

ykonawców pro-

duktów. W ten sposób zrozumiał zresztą tę instrukcję sam odwołujący, który wypełnił te pola 

przez podanie nazwy oprogramowania w poz. 4, 5 i 6 Tabeli nr 1. Wskazuje to 

na to, iż inter-

pretacja przedstawiana w treści odwołania została utworzona wyłącznie na poparcie zarzu-

tów odwołania, a nie stanowi faktycznego sposobu, w jaki odwołujący rozumiał treść wyma-

gań. Wykonawcy, nawet odstępując od stosowania wzoru dokumentów opracowanego przez 

z

amawiającego,  zobowiązani  są  mimo  wszystko  do  uwzględnienia  i  zawarcia  w  ofercie 

wszystkich wymaganych przez z

amawiającego w takim wzorze informacji. 

Ponad  wszelką  wątpliwość,  o  tym,  że  podanie  nazw  oferowanego  oprogramowania  we 

wskazanyc

h pozycjach stanowi wymaganie zawarte w treści warunków zamówienia, świad-

czy charakter Formularza ofertowego, który nie jest sugerowanym, ale wymaganym Załącz-

nikiem przedstawiającym treść oferty Wykonawców. Zgodnie z pkt 4.3.1 SWZ „Ofertę składa 

się na Formularzu oferty stanowiącym Załącznik nr 1 do SWZ”. Poza tym, wbrew twierdze-

niom o

dwołującego, nazwy oferowanego oprogramowania są również istotne ze względu na 

treść Umowy - zgodnie z Projektowanymi Postanowieniami Umowy, Formularz oferty złożo-

nej przez Wy

konawcę stanowi Załącznik nr 1 1 do zawieranej umowy, a tym samym stosow-

nie do S16 ust. 3 - 

integralną część tej umowy w sprawie zamówienia publicznego. 

Już  z  powyższych  względów,  wynikających  bezpośrednio  z  treści  warunków  zamówienia, 

ewidentna  jest  nieza

sadność  argumentacji  odwołania  wskazującej  na  brak  zawarcia  w  do-

kumentach zamówienia wymagania podania nazw oprogramowania wskazanego w poz. 2, 3 

i 7 Tabeli nr 1 a tym samym - 

brak niezgodności oferty odwołującego z warunkami zamówie-

nia. Nie sposób uznać za prawidłowo sporządzoną oferty, która nie zawiera elementów wy-

maganych  przez  z

amawiającego, szczególnie jeśli dotyczą one samej treści oferty wskaza-

nia oferowanego przez w

ykonawcę przedmiotu oferty. 

Polemika  z 

zasadnością  postawionego  przez  zamawiającego  wymagania  podania  nazw 

oprogramowania w treści oferty, byłaby możliwa wyłącznie na etapie kwestionowania treści 

SWZ, natomiast po upływie terminu składania ofert, wymaganie to jest wiążące zarówno dla 

wykonawców, jak i zamawiającego. 

Zasadnie  z

amawiający  podnosił  w  uzasadnieniu  odrzucenia  oferty  odwołującego,  iż  brak 

wskazania  nazwy,  oprócz  oczywistej  niezgodności  z  warunkami  zamówienia,  uniemożliwia 

również weryfikację zaoferowanego rozwiązania. Dotyczy to etapu oceny zgodności oferty z 

wymaganiami opisu p

rzedmiotu zamówienia, gdzie obowiązek zaoferowania (i wskazania w 

ofercie) konkretnego rozwiązania wykonawcy umożliwia już na tym etapie weryfikację ogól-

nych zapewnień wykonawców co do zgodności z wymaganiami SWZ, tak aby uniknąć wybo-

ru  oferty  nie  zapewnia

jącej  ich  spełnienia.  Jak  również,  jest  to  istotne  na  etapie  realizacji  i 

wdrożenia rozwiązania, gdzie zamawiający ma możliwość porównania czy produkt, który jest 

dostarczony  i  odbierany  przez  niego  jest  zgodny  z  tym  zaoferowanym  przez  w

ykonawcę  w 

składanej ofercie, którego dotyczą też deklaracje o spełnianiu wymagań OPZ. Niezgodności 

występujących w ofercie odwołującego również z tych względów nie można zatem uznać za 

nieistotne. 

Nietrafne jest także powoływanie się przez odwołującego na to, iż podanie nazwy własnej nie 

było wymagane ze względu na dopuszczenie przez zamawiającego stosowania oprogramo-

wania typu open source, które „może nie posiadać zastrzeżonej nazwy własnej, którą można 

by wprowadzić do Formularza ofertowego”. 

 Po pierwsze, postanowienie do

puszczające oprogramowanie open source, na które powołu-

je się odwołujący, to pkt Il ppkt 7 OPZ, który dopuszcza taką możliwość tylko w odniesieniu 

do licencji na systemy operacyjne i motory bazodanowe,  a zatem - nie uzasadniania to za-

niechania wskazania nazwy oprogramowania w poz. 2 i 3 Tabeli nr 

1, które dotyczyły innych 

licencji. 

Po  drugie,  z

amawiający  nie  wymagał  podania  „nazwy  zastrzeżonej  ",  ale  „nazwy  oprogra-

mowania”,  a  taką  mogą  posiadać  również  licencje  open  source,  co  potwierdza  chociażby 

oferta  Uc

zestnika  postępowania,  gdzie  w  poz.  7  (czyli  tam,  gdzie  wskazanie  licencji  open 

source zos

tało wprost dopuszczone) podano nazwy zaoferowanych „licencji otwartych” „Cent 

OS, PostgreSQL”. 

Odwołujący nie wykazał zresztą, że taka sytuacja - brak możliwości podania nazwy oferowa-

nego oprogramowania open source - 

występuje w przypadku jego oferty. Na pewno, nie mo-

że dotyczyć to oprogramowania w poz. 2 i 3, gdzie jak zdaje się wynikać z treści odwołania, 

o

dwołujący  miał  zamiar  zaoferować  oprogramowanie  „gwarantowane  przez  producenta 

urządzeń”,  czyli  firmę  Thales.  Oprogramowanie  takie  -  posługując  się  sformułowaniem  za-

wartym w pkt 8 odwołania - jest oprogramowaniem komercyjnym, zakupionym od producenta 

innego niż wykonawca. Zatem, zgodnie z linią argumentacji samego odwołującego, powinno 

być dostępne i możliwe wskazanie nazwy oprogramowania dla oprogramowania middleware 

i oprogramowania SDK, których dotyczy poz. 2 i 3 Tabeli nr 1 Formularza oferty. 

W istocie, opis podany w tych pozycjach, tj. wskazanie „oprogramowania producenta HSM” 

nie  jest  wystarczający  dla  ustalenia  co  dokładnie  stanowi  przedmiot  oferty  Odwołującego. 

Dodatkowo mając na względzie również to, iż odwołujący nie wyodrębnił także cen za ofero-

wane w tych odrębnych pozycjach produkty. 

Odniesienie do urządzenia HSM oferowanego w poz. 1 nie jest wystarczające, gdyż równie 

dobrze, pod terminem „oprogramowanie producenta HSM”, można rozumieć oprogramowa-

nie wbudowane HSM, o którym mowa w poz. 1 Tabeli nr 1 (i gdzie odwołujący ujął też wyce-

nę poz. 2 i 3), które też jest oprogramowaniem producenta urządzenia, a które w żaden spo-

sób nie jest wystarczające dla zapewnienia funkcjonalności oczekiwanych przez zamawiają-

cego od oprogramowania middleware czy oprogramowania SDK. 

Odwołujący nie udowodnił zarazem „standardu” polegającego na oferowaniu oprogramowa-

nia „gwarantowanego” przez producenta urządzeń, ani że mógł w ramach oferty zaoferować 

tylko jedno takie dostępne rozwiązanie. Na pewno, na takiej deklaracji nie mógł polegać za-

mawiający dokonując badania i oceny oferty, co wymagałoby od niego „dopowiedzenia” sa-

modzielnie  informacji  nie  zawartych  przez  odw

ołującego  w  złożonej  ofercie.  Zaznaczenia 

wymaga, że to na wykonawcy spoczywa ciężar sporządzenia oferty zgodnie z SWZ i w taki 

sposób,  aby  wykazać  jej  zgodność  z  warunkami  zamówienia.  Wypełniając  Tabelę  nr  1  w 

poz. 2 i 3, ale także w poz. 7, odwołujący nie dochował należytej staranności, jakiej należało 

oczekiwać  od  profesjonalnego  uczestnika  postepowania  o  udzielenie  zamówienia,  wobec 

czego zasadne jest obciążenie go negatywnymi konsekwencjami jego zaniechań.  

Odnosząc  się  do  twierdzenia  zawartego  w  pkt  9  odwołania,  odnoszącym  się  do  poz.  2  i  3 

Tabeli, iż „Wykonawca nie zna przypadków, gdzie jest dostarczone inne oprogramowanie niż 

gwarantowane przez producentów urządzeń”, nie można uznać go za zasadny argument dla 

poparcia  zarzutu  odwołania.  Zwłaszcza,  gdy  w  ofercie  uczestnika  postępowania  w  poz.  3 

wskazano oprogramowanie własne Enigma Pem Heart SDK, a zatem inne niż pochodzące 

od producenta HSM (również Enigma zaoferowała HSM firmy Tales). 

Nieprawidłowa jest również argumentacja odwołującego zawarta w pkt 10 odwołania, a pole-

gająca  na  zrównaniu informacji  podanych  w  poz.  2 Tabeli  nr  1 przez  odwołującego  i  przez 

u

czestnika postępowania. Wskazana w Formularzu ofertowym 

Uczestnika  postępowania  nazwa  oprogramowania  „Luna  Network  Client  Licenses”  nie  sta-

nowi tak jak u  o

dwołującego niejednoznacznego opisu przedmiotu oferty, z tym, że przetłu-

maczonego na j. angielski, ale jest nazwą oprogramowania nadaną przez producenta. Okre-

śla ona konkretny produkt, o określonych właściwościach, uwzględniany (z użyciem tej wła-

śnie  nazwy)  w  ofertach  i  cennikach  producenta.  Przedmiot  oferty  uczestnika  postępowania 

nie jest zatem nieokreślony, ale został wskazany przez użycie nazwy własnej oprogramowa-

nia  - 

jest  to  istotna  różnica  w  stosunku  do  oferty  odwołującego  i  przesądzająca  właśnie  o 

prawidłowości oferty złożonej przez Enigma w porównaniu do podlegającej odrzuceniu oferty 

o

dwołującego. 

Równie  nieprzekonująca  jest  argumentacja  przedstawiana  w  odwołaniu  w  odniesieniu  do 

licencji na systemy operacyjne i motory bazodanowe. 

Zarówno z treści Tabeli nr 1, gdzie nie podano nazwy oprogramowania, jak i z treści uzasad-

nienia odwołania, nie sposób jednoznacznie ustalić, jakie dokładnie oprogramowanie zostało 

zaoferowane przez o

dwołującego. Odwołujący powołuje się na zaoferowanie opensourcowej 

licencji,  jednakże  w  dalszym  ciągu  nie  sposób  określić,  co  to  za  licencja,  a  tym  samym  - 

określić faktycznego przedmiotu oferty i rozwiązania, które ma zapewnić zgodność z wyma-

ganiami Zamawiającego. 

Odwołujący  wymaga,  aby  zamawiający  polegał w  tym  zakresie wyłącznie na  deklaracji  wy-

konawcy,  że  proponowane  rozwiązanie  jest  prawidłowe  i  „będzie  działać”  zgodnie  z  SWZ. 

Jest to całkowite odwrócenie wymagania wynikającego z treści SWZ, którego przyjęcie pro-

wadziłoby poza tym do niedopuszczalnego naruszenia zasad uczciwej konkurencji i równego 

traktowania  w

ykonawców,  w  sytuacji,  w  której  oferta  uczestnika  postępowania  zawierająca 

wymagane  w  SWZ  informacje  podlegała  weryfikacji  pod  kątem  zgodności  z  wymaganiami, 

nie korzystając z „domniemania prawidłowości”, na które powołuje się  odwołujący. Odwołu-

jący w treści złożonej oferty nie wskazał na żadną okoliczność chociażby uprawdopodabnia-

jącą  prawidłowość  przedmiotu  oferty,  nie  zawarł  w  Formularzu  oferty  nawet  informacji,  że 

oferowana przez niego w poz. 7 licencja jest licencją open source, na czym w znacznej mie-

rze opiera się argumentacja prezentowana przez niego w tej części odwołania.  

Jedyną informacją o oferowanym w zakresie licencji na system operacyjny i motory bazoda-

nowego rozwiązaniu odwołującego, jest to, iż jest to licencja pojedyncza (Odwołujący wpisał 

samodzielnie w treść Tabeli w kolumnie 4 liczba jednostek (sztuk) cyfrę „1 ”). To z kolei budzi 

uzasadnione  zastrzeżenia,  co  do  możliwości  zaoferowania  pojedynczej  licencji  zarówno  na 

system  operacyjny,  jak  i  bazę  danych,  niezależnie  od  konieczności  zapewnienia  liczby  od-

powiedniej  dla  wymaganych  przez  z

amawiającego  środowisk,  serwerów.  Niewskazanie 

przez  z

amawiającego  w  SWZ  minimalnej  liczby  licencji,  nie  przeczy  okoliczności,  na  którą 

wskazuje sam o

dwołujący, tj., że oferowane rozwiązanie ma zapewniać zgodne z warunkami 

zamówienia  funkcjonowanie  całego  rozwiązania,  jak  również,  co  wydaje  się  oczywiste  ma 

być rozwiązaniem możliwym do zaoferowania, dostarczenia i implementacji. Niezależnie od 

tego jaki sposób spełnienia wymagań oferuje odwołujący, powinno to znaleźć wyraz we wła-

ściwym opisie zawartym w Tabeli nr 1, tak, aby zamawiający mógł ocenić prawidłowość roz-

wiązania  i  jego  wyceny  (zaoferowanej  liczby  licencji).  To  na  odwołującym  spoczywa  ciężar 

wykazania, że zaoferowany przedmiot jest zgodny z wymaganiami zamawiającego. 

Prawidłowo sporządzona w postępowaniu oferta powinna obejmować konkretne rozwiązanie 

i identyfikować je w sposób przewidziany przez zamawiającego w warunkach zamówienia (w 

tym przypadku - w Formularzu oferty), czego nie 

zapewnia oferta złożona przez odwołujące-

go.  

Izba ustaliła następujący stan faktyczny: 

Izba dopuściła dowody z dokumentacji postępowania tj. swz wraz z załącznikami, wyjaśnień 

treści swz wraz z modyfikacją nr 1, ofert odwołującego i przystępującego, pisma przystępu-

jącego z dnia 17 lutego 2022 r., informacji o wyniku postępowania z dnia 31 marca 2022 r. 

oraz dowody złożone na rozprawie przez odwołującego i przystępującego.  

Na podstawie ty

ch dowodów Izba ustaliła: 

Z SWZ wynika, że w pkt 2.1. zamawiający określił przedmiot zamówienia: 

2.1.1. Przedmiot zamówienia jest określony we Wspólnym Słowniku Zamówień (CPV) 

kodem: 

4 Urządzenia do przetwarzania danych 

‐ 48421000‐5 Pakiety opro

gramowania do zarządzania urządzeniami 

9 Usługi uwierzytelniania podpisu elektronicznego 

8 Usługi uwierzytelniania 

2.1.2. Przedmiotem zamówienia jest zakup kwalifikowanych usług zaufania  

- zakup 

i instalacja dwóch urządzeń HSM, zakup licencji na oprogramowania, zakup certyfi-

katów kwalifikowanych e‐pieczęci. 

2.1.2.1.  Szczegółowy  opis  przedmiotu  zamówienia  stanowi  Załącznik  nr  1  do  Projektowa-

nych postanowień Umowy stanowiących Załącznik nr 2 SWZ. 

2.1.4. Przedmiotowe środki dowodowe: 

2.1.4.1. Zamawiający nie wymaga wniesienia przedmiotowych środków dowodowych na po-

twierdzenie spełnienia wymagań dotyczących przedmiotu zamówienia. 

2.1.7. Szczegółowe warunki realizacji zamówienia zawarte zostały w Projektowanych posta-

nowieniach umowy stanowiących Załącznik nr 2 do SWZ. 

Załącznik nr 1 formularz oferty  

Tabela 1 

urządzenia HSM wraz z oprogramowaniem wbudowanym ‐ …………………………………

………………………………… (producent, model) 

ilość 2 

2  licencje  na  oprogramowanie  middleware  ‐  ………………………………………….  (nazwa 

oprogramowania) 

ilość 2 

3  licencje  na  oprogramowanie  SDK  ‐  ………………………………………….  (nazwa  opro-

gramowania) 

ilość 10 

7 licencje na systemy operacyjne i motory bazodanowe ‐ ………………………………………

…. (nazwa oprogramowania

) ilość …..* *Wypełnia Wykonawca. 

Załącznik nr 2 do SWZ Umowa: 

Definicje: 

Licencja  - 

Uprawnienie  do  korzystania  przez  Zamawiającego  z  Oprogramowania  udzielone 

Zamawiającemu na podstawie umowy o korzystanie z Oprogramowania, zawartej przez Za-

mawiającego (licencjobiorcę) z podmiotem, któremu przysługują majątkowe prawa autorskie 

do Oprogramowania 

(licencjodawca), określającej pola eksploatacji i inne warunki, na jakich 

Zamawiający  (licencjobiorca)  jest  uprawniony  do  korzystania  z  Oprogramowania  albo  na 

podstawie innego ni

ż umowa dokumentu. 

Odbiór - Potwierdzenie przez Zamawiającego należytego wykonania Umowy w zakresie po-

szczególnych zobowiązań Wykonawcy (dostawy elementów do obsługi opatrywania kwalifi-

kowanymi    pieczęciami  elektronicznymi,  sporządzenia  projektu  technicznego  Rozwiązania, 

Wdrożenia  Rozwiązania,  sporządzenia  koncepcji  testów,  sporządzenia  Dokumentacji, 

świadczenia Usługi serwisu). Dowodem dokonania Odbioru jest odpowiedni Protokół Odbio-

ru. 

Oprogramowanie - 

Oprogramowanie istniejące i dystrybuowane na zasadach komercyjnych 

przez dostawcę, który zachowuje prawa własności intelektualnej do oprogramowania. 

§ 1 

Przedmiot Umowy 

1. Przedmiotem Umowy jest zakup 

kwalifikowanych usług zaufania obejmujący: 

1) sprzedaż i dostawę 2 sztuk urządzeń technicznych HSM: 

‐ producent………………………………, model ……………………………*, 

spełniających wymagania Qualified Signature Creation Device (QSCD) wraz z 36 miesięczną 

gwarancją i wsparciem producenta, 

2) sprzedaż i dostawę Oprogramowania dla usługi opatrywania pieczęciami kwalifikowanymi 

dokumentów elektronicznych: 

‐ …………………………………………………………………………………….* 

‐ …………………………………………………………………………………….* 

‐ …………………………………………………………………………………….* 

* do uzupełnienia po odbiorze najkorzystniejszej oferty 

3) Wdrożenie Rozwiązania, 

4) sporządzenie i przekazanie Dokumentacji powykonawczej Rozwiązania, 

5) dostawę, w terminie wskazanym przez Zamawiającego certyfikatów pieczęci elektronicz-

nych, z okresem ważności 60 miesięcy, 

6) udostępnienie, na zlecenie Zamawiającego pakietów usługi kwalifikowanego znakowania 

czasem, 

7)  świadczenie  Usługi  serwisu  dostarczonego  Rozwiązania  przez  okres  36  miesięcy  po-

cząwszy od dnia Odbioru Wdrożenia Rozwiązania, 

2. Szczegółowy OPZ stanowi Załącznik nr 1 do Umowy. 

§ 2 

Oświadczenia/zobowiązania Wykonawcy 

4. Wykonawca oświadcza, iż w celu realizacji usługi nie jest konieczne zakupienie przez Za-

mawiającego  żadnych  dodatkowych  licencji  ani  uprawnień  poza  opisanymi  Umową,  w  tym 

szczegółowym OPZ, stanowiącym Załącznik nr 1 do Umowy i objętymi wynagrodzeniem Wy-

konawcy, o którym mowa w § 6 ust. 1. 

5. Wykonaw

ca oświadcza, że dostarczony sprzęt i oprogramowanie nie będą obciążone do-

datkowymi kosztami (z

wiązanymi np. z licencjonowaniem) zależnymi od warunków eksploat-

acji, w tym od:  

liczby połączeń do HSM, 

liczby  klientów  lub  oprogramowania  korzystającego  z  usług  opatrywania  kwalifikowanymi 

pieczęciami elektronicznymi, 

udostępnienia zdalnego administrowania HSM, 

udostępnianych algorytmów. 

§ 6 

Wynagrodzenie umowne i zasady płatności 

1.  Maksymalne  łączne  wynagrodzenie  brutto,  tj.  z  uwzględnieniem  podatku  od  towarów  i 

usług (VAT), należne Wykonawcy z tytułu realizacji przedmiotu Umowy, o którym mowa w § 

nie 

przekroczy 

kwoty 

…………………….. 

zł 

(słownie 

złotych: 

………………………………………………), zgodnie Załącznikiem nr 11 (Formularz oferty). 

2.  Wynagrodzenie  brutto  Wykonawcy 

z  tytułu  dostawy  HSM  i  Oprogramowania,  o  których 

mowa 

w  §  1  ust.  1  pkt  1  i  2,  wynosi  ……………………..  zł  (słownie  złotych: 

………………………………………………), zgodnie Załącznikiem nr 11 (Formularz oferty), w 

tym: 

1) z tytułu dostawy HSM, o której mowa w § 1 ust. 1 pkt 1, wynosi brutto …………………….. 

zł (słownie złotych: ………………………………………………), 

2)  z  tytułu  dostawy  Oprogramowania,  o  którym  mowa  w  §  1  ust.  1  pkt  2,  wynosi  brutto 

…………………….. zł (słownie złotych: ………………………………………………). 

3. Wynagrodzenie brutto Wykonawcy z tytułu Wdrożenia Rozwiązania i dostarczenia Doku-

mentacji 

powykonawczej  Rozwiązania,  o  których  mowa  w  §  1  ust.  1  pkt  3  i  4,  wynosi 

……………………..  zł  (słownie  złotych:  ………………………………………………),  zgodnie 

Załącznikiem nr 11 (Formularz oferty). 

4.  Maksymalne  wynagrodzenie  brutto  Wykonawcy  z  tytułu  dostawy  certyfikatów  pieczęci 

elektronicznej, o których mowa w § 1 ust. 1 pkt 5, wynosi ……………….. zł (słownie złotych: 

………………………).  Cena  jednostkowa  brutto  certyfikatu  pieczęci  elektronicznej  wynosi 

………………..  zł  (słownie  złotych:  ………………………),  zgodnie  Załącznikiem  nr  11  (For-

mularz oferty). 

5.  Maksymalne  wynagrodzenie  brutto  Wykonawcy  z  t

ytułu  udostępnienia  pakietów  usługi 

kwalifikowanego  znakowania  czasem,  o  których  mowa  w  §  1  ust.  1  pkt  6,  wynosi 

………………..  zł  (słownie  złotych:  ………………………).  Cena  jednostkowa  brutto  pakietu 

usług  kwalifikowanego  znakowania  czasem  wynosi  ……………………..  zł  (słownie  złotych: 

………………………………………………), zgodnie Załącznikiem nr 11 (Formularz oferty). 

6.  Maksymalne  wynagrodzenie  brutto  W

ykonawcy  z  tytułu  świadczenia  Usługi  serwisu,  o 

której  mowa  w  §  1  ust.  1  pkt  7,  wynosi  ………………..  zł  (słownie  złotych: 

………………………), w tym maksymalne wynagrodzenie brutto Wykonawcy z tytułu świad-

czenia z tytułu świadczenia Usługi serwisu HSM, o których mowa w § 1 ust 1 pkt 1, wynosi 

…………………….. zł (słownie złotych:  

………………………………………………), a maksymalne wynagrodzenie brutto Wykonawcy 

należne Wykonawcy z tytułu świadczenia Usługi serwisu Oprogramowania, o którym mowa 

w 

§ 

ust 

pkt 

wynosi 

…………………….. 

zł 

(słownie 

złotych: 

………………………………………………).  Zryczałtowane  miesięczne  wynagrodzenie  brutto 

należne Wykonawcy z tytułu świadczenia Usługi serwisu HSM, o których mowa w § 1 ust 1 

pkt 1, wynosi …………………….. zł (słownie złotych: 

………………………………………………), a zryczałtowane miesięczne wynagrodzenie brutto 

należne Wykonawcy z tytułu świadczenia Usługi serwisu Oprogramowania, o którym mowa 

w 

§ 

ust 

pkt 

wynosi 

…………………….. 

zł 

(słownie 

złotych: 

………………………………………………), zgodnie Załącznikiem nr 11 (Formularz oferty). 

7.  Maksymalne  łączne  wynagrodzenie  brutto,  o  którym  mowa  w  ust.  1,  zawiera  wszelkie 

koszty 

Wykonawcy związane z realizacją przedmiotu Umowy określonego w § 1 i wyczerpuje 

wszelkie 

roszczenia Wykonawcy wobec Zamawiającego z tytułu wykonania Umowy. Wyna-

grodzenie 

określone w § 6 nie ulegnie zmianie w okresie obowiązywania Umowy z zastrze-

żeniem§ 14 ust. 6. 

Załącznik nr 1 ‐ Opis Przedmiotu Zamówienia 

I. Szczegółowe wymagania dotyczące urządzeń. 

Każde z urządzeń HSM musi: 

1.  znajdować  się  na  liście  QSCD,  jako  wymóg  konieczny  do  przechowywania  kwalifikowa-

nych certyfikatów pieczęci elektronicznych; 

2.  posiadać  wsparcie  dla  algorytmów  symetrycznych,  dotyczy  to  przynajmniej  wsparcia  dla 

kryptografii oraz kluczy symetrycznych: AES (128 i 256 bit), Triple DES; 

3. posiadać wsparcie dla algorytmów asymetrycznych, dotyczy to przynajmniej wsparcia dla 

kryptografii oraz kluczy asymetrycznych opartych o algorytmy: RSA (2048, 4096 bit); 

4. umożliwiać generowanie par kluczy kryptograficznych (symetrycznych i asymetrycznych); 

5. umożliwiać fizyczną i logiczną ochronę kluczy kryptograficznych; 

6. mieć wbudowaną funkcjonalność kontroli dostępu do kluczy kryptograficznych; 

7. umożliwiać wykonywanie operacji z użyciem kluczy kryptograficznych; 

8. umożliwiać archiwizację kluczy oraz odtwarzanie kluczy z kopii bezpieczeństwa przecho-

wywanej poza urządzeniem, na dostarczony przez Wykonawcę bezpieczne urządzenie (de-

dykowany modułu zewnętrznego do wykonywania kopii bezpieczeństwa z takim samym po-

ziom certyfikacji jak dla głównego HSM); 

9. zapewniać przechowywanie kluczy kryptograficznych wewnątrz urządzenia; 

10.  posiadać możliwość lokalnego  i  zdalnego  (poprzez  sieć  LAN/WAN)  zarządzania  opera-

cjami na kluczach kryptograficznych; 

11. stanowić zamkniętą całość sprzętową, Zamawiający nie dopuszcza rozwiązania w posta-

ci se

rwera z wewnętrzną kartą PCIe; 

12. zapewniać minimalną wydajność odpowiednio: 

500 podpisów/s kluczem RSA o długości 2048 bitów w trybie pojedynczego podpisu; 

2 000 podpisów/s kluczem RSA o długości 2048 bitów w trybie podpisu wsadowego; 

13. obsługiwać przez sieć wiele serwerów (min. 100 active) oraz oprogramowań w wielu lo-

kalizacjach LAN; 

14. umożliwiać umieszczenie indywidulanych kwalifikowanych pieczęci rozróżnialnych kluczy 

pieczęci na urządzeniu (max. 100 pieczęci ); 

15. umożliwiać tworzenie co najmniej 100 logicznych partycji do przechowywania materiału 

kryptograficznego; 

16. zapewniać uwierzytelnienie do administrowania urządzeniem oraz każdą z partycji z uży-

ciem mechanizmu silnego uwierzytelniania (np. z użyciem kart inteligentnych lub tokenów) i 

wspierać mechanizm kworum N z M (do poprawnego uwierzytelnienia wymagane jest przed-

łożenie N poświadczeń z zestawu M poświadczeń, gdzie N=<M); 

17.  pozwalać na  całkowicie zdalną  administrację,  bez  konieczności  asysty  operatorów  przy 

urządzeniu; 

18. umożliwiać wykorzystanie interfejsów programistycznych (API) min.: PKCS#11, Microsoft 

CSP/CNG, JCE; 

19. wspierać funkcje skrótu: SHA2 (SHA‐224, SHA‐256, SHA‐384, SHA‐512); 

20.  działać w trybie pracy  wysokiej  dostępności w  klastrze  typu  active‐pasive i  active‐‐

active; 

21.  pozwalać  na  tworzenie  kopii  bezpieczeństwa  materiału  kryptograficznego,  który  jest  w 

nim przechowywany oraz na jego odtwarzanie z kopii; 

22. pozwalać na zestawienie bezpiecznego kanału komunikacyjnego pomiędzy HSM a ser-

werem uruchomionym w środowisku wirtualnym (np. VMware, Hyper‐V); 

23. posiadać obudowę o wysokości nie większej niż 1U, dostosowaną do montażu w szafie 

stelażowej 19”; 

24. posiadać wbudowane redundantne (min. 2) zasilacze hot‐swap przystosowane do zasi-

lania z sieci ~230V; 

25. posiadać możliwość zestawienia bezpiecznego kanału komunikacyjnego pomiędzy opro-

gramowaniem wykorzystującym interfejs PKCS#11 a partycją w module HSM – przy założe-

niu, że klucze do zabezpieczenia tej komunikacji muszą być przechowywane w postaci pliku 

na kliencie 

korzystającym z HSM lub w dedykowanym elemencie sprzętowym; 

26.  zapewnić  współpracę z Microsoft Windows Server  2012,  2016  i  nowsze, Windows  10  i 

nowsze; 

27. zapewnić współpracę z Linux 64 bit; 

28.  być  dostarczone  wraz  z  oprogramowaniem  zapewniającym  opatrywanie  kwalifikowaną 

pieczęcią  elektroniczną;  posiadać  oprogramowanie  oraz  dokumentację  urządzeń  w  wersji 

językowej polskiej lub angielskiej. Dokumentacja powinna być dostępna w wersji elektronicz-

nej oraz aktualna na dzień dostawy urządzeń; 

29. posiadać wsparcie producenta urządzeń, tzn. w chwili składania oferty nie może istnieć 

opublikowana  informacj

a  dotycząca  przewidywanego  bądź  postanowionego  zakończenia 

standardowego wsparcia technicznego producenta przez cały okres trwania umowy; 

30. być zgodne, wraz z dostarczonym oprogramowaniem, z QSCD oraz zarządzane w imie-

niu 

Zamawiającego przez kwalifikowanego dostawcę usług zaufania; 

31. spełniać wszystkie wymogi dotyczące bezpieczeństwa oraz zużycia energii określone w 

obowiązującym w Polsce prawie; 

32.  być  fabrycznie  nowe,  kompletne,  nieużywane  i  bez  oznak  używania,  nierefabrykowane  

nieregenerowane, nien

aprawiane, niepodlegające ponownej obróbce oraz w jednolitej konfi-

guracji; 

33.  posiadać  gwarancję  i  wsparcie  producenta  urządzeń  przez  okres  36  miesięcy  od  dnia 

dostarczenia sprzętu do Zamawiającego. 

34. zostać dostarczone wraz ze wszystkimi niezbędnymi elementami umożliwiającymi mon-

taż w szafie (kable, szyny, uchwyty, śruby, etc.). 

II. Szczegółowe wymagania dotyczące oprogramowania. 

Wykonawca dostarczy bezterminowe licencje na: 

1. oprogramowanie middleware 

– do administrowania urządzeniami oraz obsługi komunikacji 

z HSM i zarządzania danymi dla oprogramowania rozproszonego; 

2. środowisko programistyczne (SDK  ‐ Software Development Kit) dla integratorów i użyt-

kow

ników do tworzenia oprogramowania (na platformy MS Windows oraz Linux 64bit); 

oprogramowanie  realizujące  usługi  masowego  opatrywania  kwalifikowanymi  pieczęciami 

dokumentów elektronicznych, która może zostać zintegrowana z systemami IT ZUS z wyko-

rzystani

em usług sieciowych API lub współdzielonego zasobu dyskowego; 

4. oprogramowanie k

lienckie realizujące pojedyncze i masowe usługi opatrywania dokumen-

tów kwalifikowaną pieczęcią elektroniczną przez pracowników Zamawiającego: 

1)  oprogramowanie  realizujące  usługi  masowego  opatrywania  kwalifikowanymi  pieczęciami 

dokumentów elektronicznych zainstalowane na serwerze musi: 

a) obsługiwać równolegle min. 10 urządzeń HSM, 

b) obsługiwać równolegle min. 200 par kluczy na każdym urządzeniu HSM, 

c) obsługiwać równolegle min. 200 systemów IT Zamawiającego, 

d) wspierać następujące standardy podpisów elektronicznych zgodnych z przepisami wyko-

nawczymi  do  rozporządzenia  eIDAS:  PKCS#7,  PDF  &  PDF/A,  XAdES,  CAdES,  PAdES, 

LTA, 

e) obsługiwać kwalifikowaną usługę znacznika czasu, 

f) 

zapewniać obsługę następujących rodzajów podpisów elektronicznych: 

zewnętrzny, wewnętrzny, kontrasygnata, równoległe, 

g) zapewnić rozliczalność liczby użyć każdego z dostępnych certyfikatów, 

h) zapewnić rozliczalność przeprowadzonych operacji podpisu przez każdego klienta, 

i) zapewnić rozliczalność użyć kwalifikowanej usługi znacznika czasu, 

j) zapewnić obsługę opatrzenia dokumentu wybranym przez Zamawiającego scenariuszem: 

pieczęcią kwalifikowaną; 

pieczęcią kwalifikowaną z kwalifikowanym znacznikiem czasu; 

‐ kwalifikowanym znacznikiem czasu; 

k) obsługiwać oprogramowanie klienckie; 

l) poprawnie pracować w środowisku MS Windows 2012 i wyższych oraz Linux 64 bit. 

m) musi mieć możliwość wdrożenia w środowisku wirtualnym; 

2)  oprogramowanie  klienckie  realizuj

ące  usługi  pojedynczego  opatrywania  kwalifikowanymi 

pieczęciami  dokumentów  elektronicznych  przez  pracowników  ZUS  zainstalowane  na  stacji 

pracownika ZUS musi: 

a) zapewnić autoryzację pracownika do usług w oparciu o AD (Active Directory) Zamawiają-

cego i z uw

zględnieniem udostępnionych mu e‐pieczęci ze zbioru wszystkich certyfikatów, 

z których mogą korzystać pracownicy; 

b)  zapewnić  możliwość  podpisywania  dokumentu  na  stacji  klienckiej  bez  wysyłania  doku-

mentu na serwer; 

c) zapewnić realizację pojedynczej usługi w czasie krótszym niż 20 sekund; 

d) zapewnić obsługę opatrzenia dokumentu wybranym przez użytkownika scenariuszem: 

pieczęcią kwalifikowaną; 

pieczęcią kwalifikowaną z kwalifikowanym znacznikiem czasu; 

‐ kwalifikowanym znacznikiem czasu. 

e) posiadać instrukcję oraz dokumentację eksploatacyjną, w języku polskim; 

f) popr

awnie pracować w środowisku MS Windows 10 i wyższych; 

g) zapewnić wykrywanie ustawień proxy internet w systemie MS Windows 10 i wyższych w 

celu sprawdzenia listy CRL . 

5. Rozwiązania powinno zostać wdrożone w trybie wysokiej dostępności (High‐Availability) 

w obszarze oprogramowania. 

6. pozostałe niezbędne do prawidłowego działania Rozwiązania licencje dla dostarczonego 

oprogramowania oraz licencji konfiguracyjnych dla dostarczonych urządzeń HSM. 

7. niezbędne licencje na systemy operacyjne i motory bazodanowe z minimalnym 3‐letnim 

wsparciem technicznych producenta. W przypadku użycia w Rozwiązaniu systemów opera-

cyjnych  lub  motorów  bazowanych  z  licencją  otwarta  (open  source)  Wykonawca  będzie 

świadczył Usługę serwisu przez okres Umowy. 

Modyfikacja nr 1: 

Zmiani

e  ulega  pkt  I  Załącznika  1  do  Projektowanych  Postanowień  Umowy,  które  stanowią 

Załącznik nr 2 do SWZ, poprzez dodanie ust. 35 w brzmieniu: 

35.  umożliwiać  zarządzanie  urządzeniami  HSM,  generowanie  statystyk  operacji  kryptogra-

ficznych 

służących do monitorowania wydajności urządzenia, przy użyciu rozwiązań wbudo-

wanych  lub 

poprzez  dostarczenie  i  integrację  urządzenia z  posiadanym  narzędziem  Crypto 

Command  Center  lub 

dostawy  innego  narzędzia  monitorowania  wydajności  urządzenia.  W 

przypadku dostarczenia HSM 

współpracującego z narzędziem Crypto Command Center Wy-

konawca zobowiązany jest do integracji z Rozwiązaniem lub wdrożenia innego narzędzia do 

zarządzania i monitorowania wydajności urządzenia. 

W

yjaśnienia treści SWZ: 

Pytanie nr 3 

dot. pkt. 5 część II ‐ Rozwiązania powinno zostać wdrożone w trybie wysokiej dostępności 

(High‐Availability) w obszarze oprogramowania. 

Czy  Zamawiający  oczekuje  wdrożenia  oprogramowania  w  dwóch  lokalizacjach  (ośrodek 

pod

stawowy,  ośrodek  zapasowy)  połączonych  w  klastrze  HA,  czy  też  oprogramowanie  ma 

być  wdrożone  w  większej  liczbie  lokalizacji  tworząc  tryb  wysokiej  dostępność  (High ‐

Availability). Jeśli Oprogramowanie ma być wdrożone w więcej niż dwóch ośrodkach prosimy 

o po

danie liczby ośrodków w których ma zostać przeprowadzone wdrożenie. 

Odpowiedź nr 3 

Zamawiający podtrzymuje postanowienia SWZ. Jednocześnie wyjaśnia, że wymaga wdroże-

nia oprogramowania w dwóch lokalizacjach (ośrodek podstawowy, ośrodek zapasowy) połą-

czonych w klastrze HA (High‐

Availability). W każdym z ośrodków oprogramowanie powinno 

być wdrożone w trybie wysokiej dostępność HA ‐ Zgodnie z pkt. 5 część II Załącznikiem 1 

do Projektowanych Postanowień Umowy, które stanowią Załącznik nr 2 do SWZ. 

Pytanie nr 4 

P

ytania do Opisu Przedmiotu Zamówienia. 

Dot.: I Szczegółowe wymagania dotyczące urządzeń. 

Pytanie do punktu 13: 

Czy Zamawiający formułując wymaganie „Każde z urządzeń HSM musi (…) 13. obsługiwać 

przez 

sieć wiele serwerów (min. 100 active) oraz oprogramowań w wielu lokalizacjach LAN” 

ma na myśli możliwość korzystania z usługi pieczęci przez 100 zewnętrznych serwerów oraz 

oprogramowań? 

Odpowiedź nr 4 

Zamawiający podtrzymuje postanowienia SWZ. Jednocześnie wyjaśnia, że wymaga wdroże-

nia 

Rozwiązania  z  możliwością  obsługi  przez  sieć  wielu  serwerów  (min.  100  active)  oraz 

oprogramowani 

w wielu lokalizacjach LAN. W przypadku dostarczenia Rozwiązania z licen-

cjonowaniem na liczbę klientów podłączanych do urządzenia, Zamawiający wymaga dostar-

czenia  dodatkowo  liczby  licencji 

klienckich  właściwej  dla  zaoferowanego  Rozwiązania.  Za-

mawiający  wymaga  Rozwiązania  wdrożonego  z  zachowaniem  wysokiej  dostępności  oraz 

wydajności  ‐  Zgodnie  z  pkt.  15  część  I  Załącznikiem  1  do  Projektowanych  Postanowień 

Umowy, które stanowią Załącznik nr 2 do SWZ. 

Pytanie nr 5 

Dot.: II Szczegółowe wymagania dotyczące oprogramowania. Pytanie do punktu 1 

Czy w wymaganiu dot. dostarczenia bezterminowej licencji na oprogramowanie middleware 

do 

administrowania  oraz  obsługi  komunikacji  z  HSM  i  zarządzania  danymi  dla  oprogramo-

wania 

rozproszonego  Zamawiający  oczekuje  dostarczenia  licencji  na  oprogramowanie 

umożliwiające centralne zarządzanie urządzeniami HSM? 

Odpowiedź nr 5 

Zamawiający podtrzymuje postanowienia SWZ. Jednocześnie wyjaśnia, że wymaga dostar-

czenia  bezterminowej  licencji  na  oprogramowanie  middleware  w  rozumieniu  oprogramowa-

nia 

pośredniczącego ‐ Zgodnie z pkt. 1 część II Załącznikiem 1 do Projektowanych Posta-

nowień Umowy, które stanowią Załącznik nr 2 do SWZ. 

Oferta odwołującego: 

urządzenia HSM wraz z oprogramowaniem wbudowanym - LUNA NETWORK HSM S700 

(producent, model) 

ilość 2 cena łączna brutto 341940,00 

2 licencje na oprogramowanie middleware - oprogramowanie producenta HSM (nazwa opro-

gramowania) w cenie poz. 1 

ilość 2 

3 licencje na oprogramowanie SDK - oprogramowanie producenta HSM (nazwa oprogramo-

wania) w cenie poz. 1 

ilość 10 

licencje 

na 

systemy 

operacyjne 

i 

motory 

bazodanowe 

…………………………………………. 

(nazwa oprogramowania)  

ilość 1 

Oferta Enigma: 

urządzenia  HSM  wraz  z  oprogramowaniem  wbudowanym  -  Thales  Luna  Network  HSM 

S700 (producent, model) 

ilość 2 w cenie brutto 410 082,00 

2 licencje na oprogramowanie middleware - Luna Network Client Licenses (nazwa oprogra-

mowania) 

ilość 2 w cenie brutto 6 231,18 

3 licencje na oprogramowanie SDK - Enigma Pem Heart SDK (nazwa oprogramowania) 

ilość 

10 w cenie brutto 76 260,00 

7 licencje na systemy operacyjne i motory bazodanowe - Cent OS, PostgreSQL (open sour-

ce) (nazwa oprogramowania) 0,00 

ilość 6 

Pismo Enigma z dnia 17 lutego 2022 r.  

W  związku  z  toczącym się  postępowaniem  i  etapem  badania i  oceny ofert,  Enigma  zwrócił 

uwagę na nieprawidłowości w ofercie Wykonawcy Eurocert sp. z o.o. z siedzibą w Warsza-

wie (dalej: „Eurocert”). 

Udostępniona treść oferty Eurocert  – Formularz oferty, pkt 4. Formularz cenowy, Tabela 1, 

ujawnia błędy w złożonej przez Eurocert ofercie, które oznaczać mogą niezgodności stano-

wiące podstawę do odrzucenia oferty na podstawie art. 226 ust. 1 pkt 5 Pzp ze względu na 

niezgodność z warunkami zamówienia. Zastrzeżenia dotyczą m.in. poniższych, ewidentnych 

błędów w ofercie: 

Eurocert nie wskazał w poz. 2 i 3 w kolumnie 1 Tabeli nr 1 wymaganej nazwy oferowanego 

oprogramowania; 

Eurocert  nie  określił  ceny  jednostkowej  licencji  oferowanych  w  poz.  2  i  3  Tabeli  nr  1  – 

wskazanie, iż ceny te uwzględniono w cenie poz. 1 nie czyni zadość wymaganiom Zamawia-

jącego, zgodnie z którymi Zamawiający wymagał określenia i podania tych informacji w For-

mularzu cenowym; 

Eurocert  w  poz.  7  nie  wskazał  nazwy  oferowanego  oprogramowania  systemów  operacyj-

nych  i  motorów  bazodanowych  oraz  podał  dla  nich  cenę  w  wysokości  0,00  PLN  netto,  nie 

wskazując  ich  wartości,  a  mimo  to  podając  liczbę  „1”  w  kolumnie  4 (liczba  sztuk),  mimo  iż 

warunki zamówienia wskazują, iż wymagane jest dostarczenie większej ilości licencji. 

Jakkolwiek 

staranność  prowadzenia  postępowania  może  wymagać  od  Zamawiającego  wy-

czerpania procedury wezwania do wyjaśnień z art. 223 ust. 1 Pzp, w celu uzyskania od Eu-

rocert informacji o tym, czy i jakie oprogramowanie oraz w jakich cenach jednostkowych wy-

cenił w poz. 2, 3 i 7 Tabeli nr 1, to jednak, charakter popełnionych błędów wskazuje, że jeśli 

nawet stanowią one omyłki Wykonawcy, to nie będzie możliwe ich poprawienie w trybie art. 

223 ust. 2 pkt 3 Pzp. 

Zmiana treści oferty polegająca na określeniu oferowanego produktu oraz jego ceny jednost-

kowej, stanowi istotną zmianę, nie pozwalającą na poprawienie w trybie innej omyłki przewi-

dzianym  w  przepisach  Pzp.  Wyjaśnienia  treści  oferty  mogą  służyć  wyłącznie  wyjaśnieniu 

rozbieżności  lub  treści  zawartej  w  ofercie,  ale  nie  jej  uzupełnieniu  o  informacje  istotne  z 

punktu  widzenia  oferowanego  Zamawiającemu  świadczenia,  których  nie  sposób  ustalić  na 

podstawie  pozostałej  treści  oferty.  W  tym  przypadku,  brak  podania  w  szczególności  nazw 

oferowanego oprogramowania w wierszach 2, 3 i 

7 uniemożliwia Zamawiającemu weryfika-

cję oferowanego rozwiązania, jak również nie będzie możliwe ustalenie czy dostarczone mu 

rozwiązanie będzie zgodne z tym, które zostało ujęte w ofercie Wykonawcy. Szczególnie, w 

przypadku takim, z jakim mamy do czynienia w odniesieniu do oferty Eurocert, gdzie ustale-

nie  „brakującego”  zakresu  oferty  nie  jest  jednoznaczne  i  możliwe  jest  zaoferowanie  w  ra-

mach całości rozwiązania, oprogramowania, które nie będzie zgodne z SWZ. 

Niezależnie  od  powyższego,  na  niezgodność  z  warunkami  zamówienia,  wskazuje  zaofero-

wanie pojedynczej liczby sztuk licencji na oprogramowanie w poz. 7 Tabeli nr 1, gdzie zgod-

nie z wymaganiami Zamawiającego, należało ująć licencje zarówno na oprogramowanie bę-

dące systemem operacyjnym, jak i bazą danych – sztuk takich licencji powinno być więcej, 

co  najmniej  dwa razy  tyle,  co  uruchomionych  środowisk,  ze  względu  na  wymóg  wdrożenia 

rozwiązania  w  trybie  wysokiej  dostępności  (High-Availability)  w  obszarze  oprogramowania. 

Treść Formularza ofertowego Eurocert, która poprzez brak podania nazwy i ceny jednostko-

wej wskazuje, iż zakres ten w ogóle nie został objęty ofertą Wykonawcy, nie pozwala na za-

pewnienie,  że  w  ramach  oferowanego  rozwiązania  możliwe  będzie  spełnienie  wymagań 

SWZ  w  zakresie  tego  oprogramowania  i  licencji  na  nie.  U

stawa  przewiduje  tryb  wyjaśnień 

treści oferty, jednak służy on jedynie rozwianiu wątpliwości Zamawiającego, natomiast to na 

Wykonawcy spoczywa ciężar złożenia oferty potwierdzającej zgodność z warunkami zamó-

wienia. 

Dotyczy  to  również  poz.  2  i  3,  gdzie  Wykonawca  opisał  jedynie  ogólnie,  że  oferuje  „jakieś” 

oprogramowanie (podczas gdy istnieje możliwe do zaoferowania oprogramowanie nie speł-

niające wymagań SWZ) oraz wskazał, iż jego wycena została uwzględniona w poz. 1 Tabeli 

1,  wraz  z  innym  oferowanym  komponen

tem.  Jest  to,  co  potwierdza  również  orzecznictwo 

KIO, działanie niezgodne z przepisami ustawy Pzp oraz zasadami równego traktowania Wy-

konawców. W sytuacji, w której Zamawiający żąda podania w ofercie określonych informacji, 

wszyscy Wykonawc

y zobowiązani są do ich podania, niezależnie od tego, jaką konstrukcję 

ofertowania  przyjmują.  Oznacza  to,  iż  Wykonawca,  po  upływie  terminu  na  składanie  ofert, 

nie  może  powoływać  się  np.  na  wycenę  otrzymywaną  w  określonej  postaci  od  producenta 

lub własny sposób ofertowania, aby uchylić się od złożenia treści oferty zgodnej z wymaga-

niami Zamawiającego. Jedyną możliwością wpływu na zmianę takich wymagań, byłoby kwe-

stionowanie zasadności żądania ich przez Zamawiającego na etapie przed upływem terminu 

na składanie ofert, co w tym przypadku nie zostało skutecznie przeprowadzone. W przypad-

ku,  gdy  żądanie  takie  zostało  utrwalone  w  warunkach  zamówienia,  Zamawiający  nie  może 

odstąpić od jego wymagania wobec każdego z Wykonawców, zgodnie z zasadami równego 

traktowania i uczciwej konkurencji. 

Jakkolwiek zatem zasadne może być poprzedzenie decyzji Zamawiającego wezwaniem Eu-

rocert do udzielenia wyjaśnień w trybie art. 223 ust. 1 Pzp, wątpliwe wydaje się, aby udzielo-

na odpowiedź umożliwiała poprawienie oferty w sposób zgodny z przepisami lub też uznanie 

jej  za  zgodną  z  warunkami  zamówienia.  W  takim  przypadku,  zasadne  jest  podjęcie  przez 

Zamawiającego  decyzji  o  odrzuceniu  oferty  Eurocert,  szczególnie,  gdy  wskazane  niezgod-

ności  lub  dążenie  do  niedozwolonej  zmiany  treści  złożonej  oferty,  znajdą  potwierdzenie  w 

udzielanych  przez  Eurocert  wyjaśnieniach  w  zakresie  rażąco  niskiej  ceny  złożonej  oferty 

(wezwanie uzasadnione w świetle ponad 30%-owej różnicy w stosunku do wartości referen-

cyjnych). 

Informacja o wyniku postępowania z dnia 31 marca 2022 r.  

III. Informacja o Wykonawcach, których oferty zostały odrzucone: 

Wykonawca: 

EUROCERT Spółka z ograniczoną odpowiedzialnością 

Podstawa prawna: 

art. 226 ust. 1 pkt 5 ustawy Pzp. 

Uzasadnienie faktyczne: 

Treść złożonej przez firmę EUROCERT Sp. z o.o. oferty jest niezgodna z warunkami zamó-

wienia. 

Zamawiający w pkt II Załącznika nr 1 ‐ Opis Przedmiotu Zamówienia (dalej: „OPZ”) do Pro-

jektowanych 

postanowień  umowy  (stanowiących  Załącznik  nr  2  do  Specyfikacji  Warunków 

Zamówienia)  wymagał  przedstawienia  w  ofercie  oprogramowania  w  zakresie  oferowanych 

przez wykonawcę licencji. 

Ponadto stosownie do Tabeli nr 1 w Załączniku nr 1 do SWZ – Formularz ofertowy, w poz. 2 

–  7  dla  każdej  licencji  wymagano  podania  przez  wykonawcę  nazwy  oferowanego  oprogra-

mowania. Firma 

EUROCERT Sp. z o.o. składając ofertę nie podała w poz. 2, 3 oraz 7 nazwy 

oferowanego 

oprogramowania, do czego zgodnie z SWZ była zobowiązana. Z uwagi na ten 

fakt niemożliwa jest przez Zamawiającego weryfikacja oferowanego rozwiązania. Dodatkowo 

Zamawiający  uważa  za  niemożliwe  ustalenie  czy  oferowane  rozwiązanie  przez  firmę  EU-

ROCERT Sp. z o.o. jest zgodne z tym, 

które Wykonawcy planuje wdrożyć. Wskazania rów-

nież wymaga, że Wykonawca w swojej ofercie w poz. 7 kol. 4 zadeklarował ilość jednostek 

„1”, gdzie Zamawiający zgodnie z SWZ wymagał dostarczenia co najmniej 2 szt. wymaganej 

licencji na systemy operacyjne i motory bazodanowe. Wobec stwierdzonych w/w niezgodno-

ści  oferty  firmy  EUROCERT  Sp.  z  o.o.,  Zamawiający  postanawia  odrzucić  ofertę  jako  nie-

zg

odną z warunkami zamówienia. 

Z opinii OPTeam 

wynika, że jego ofercie znajdują się rozwiązania oparte o urządzenia kryp-

tograficzne (w tym HSM) oraz systemy o nie oparte. Zdaniem OPTeam oferta odwołującego 

przedstawia  system  do  kompleksowej  usługi  zapewniającej  obsługę  opatrywania  kwalifiko-

walnymi pieczęciami elektronicznych dokumentów. Zastosowanie dwóch urządzeń HSM za-

pewni redundantność elementów sprzętowych (hardware) systemu. Licencje na oprogramo-

wanie  pośredniczące  (middleware)  i  SDK  są  zwyczajowo  dostarczane  przez  producentów 

HSM i zwyczajowo stanowią jedność z dostarczanymi urządzeniami. Zaoferowane rozwiąza-

nie w części programowej (software) w postaci nielimitowanych licencji na oprogramowanie 

podpisujące dokumenty (pieczętujące), licencji klienckich dla tego oprogramowania przy jed-

noczesnym użyciu otwartego oprogramowania (open source) bazodanowego i systemu ope-

racyjnego  stanowi  o  kompletności  usługi,  którą  chce  dostarczyć  oferent.  Jednocześnie  jak 

udało  się  ustalić  z  dostępnej  dokumentacji  zamawiający  nie  przedstawił  (nie  zażądał)  kon-

kretnej architektury rozwiązania, jak i nie przedstawił informacji o aktualnym stanie architek-

tury  techniczno-

informatycznej,  używanych  urządzeniach  sieciowych,  systemach  operacyj-

nych, bazach danych, systemach aplikacyjnych itp.  

Zamawiający  nie  przedstawił  żadnych  założeń  co  do  integracji  zamawianego  systemu  z 

obecną infrastrukturą z wyjątkiem systemu HP Service Manager i (po modyfikacji zapytania) 

Crypto Command Center, tak więc zaoferowanie licencji na bazę danych oraz system opera-

cyjny  w  postaci  jednej  licencji  open source  bez podania nazwy  jest  najrozsądniejszym roz-

wiązaniem.  W  żaden  sposób  nie  ogranicza  to  zamawiającego  (nie  naraża  na  dodatkowe 

koszty) podczas włączania dostarczanego systemu do istniejących zasobów zamawiającego. 

Tego  typu  podejście  sugeruje  możliwość  dowolnego  stworzenia  architektury  co  jest  bardzo 

pomocne  przy  braku  znajomości  infrastruktury  zamawiającego.  Nie  naraża  żadnej  ze  stron 

na dodatkowe koszty i jest przyjazne dla 

użytkowników (administratorów) systemu.  

Z maila Ł. K. do T. S. z dnia 2`1 kwietnia 2022 r. godz. 17.27 wynika, że przesłał on odbiorcy 

SWZ,  informację  o  przetargu,  ofertę  odwołującego,  odwołanie  odwołującego  i  informację  o 

wyborze oferty z pytaniem , 

czy oferta odwołującego jest w stanie zrealizować oczekiwania 

zamawiającego  –  dostarczenie  systemu  do  pieczętowania  dokumentów,  urządzeń  licencji, 

certyfikatów? 

Z  maila  T.  S. z  dnia  21 kwietnia  2022  r.  godz.  21:33  w

ynika, że wstępnie przeanalizowane 

nadesłane dokumenty i wynika z nich,  że przedmiotem zamówienia jest zakup kwalifikowa-

nych  usług  zaufania  obejmujący  w  szczególności  7  usług.  Eurocert  posiada  kwalifikacje  i 

doświadczenie  niezbędne  do  należytego  wykonania  przedmiotu  zamówienia.  Zakupione 

kwalifikowane usługi zaufania mają być świadczone „on-site” w siedzibie zamawiającego, a 

poszczególne  komponenty,  takie  jak  urządzenia  HSM,  czy  oprogramowanie  systemowe, 

bazodanowe  i  aplikacyjne 

mają  tworzyć  kompletne  rozwiązanie.  Zamówienie  nie  obejmuje 

sprzętu na którym zamawiane oprogramowanie ma zostać wdrożone. Zamawiający nie okre-

ślił  szczegółowych  wymagań  technicznych  na  inne  komponenty  niż  HSM,  którego  rolą  jest 

ochrona  materiału  kryptograficznego  oraz  zapewnienie  bezpieczeństwa  realizacji  funkcji 

kryptograficznych,  na  których  opierają  się  usługi  zaufania.  Zamawiany  HSM  ma  spełniać 

wymaganie QSCD, co jest warunkiem koniecznym świadczenia kwalifikowanych usług zau-

fania.  

Szczegółowe wymagania dotyczące oprogramowania zawarto w szczególności w pkt 7 roz-

działu II Opisu przedmiotu zamówienia stanowiącego załącznik nr 2 do SWZ zawierającego 

projektowane postanowienia umowy w brzmieniu „niezbędne licencje na systemy operacyjne 

i  motory  bazodanowe  z  minimalnym  trzyletnim  wsparcie  technicznym  producenta.  W  przy-

padku użycia w rozwiązaniu systemów operacyjnych lub motorów bazodanowych z licencją 

otwartą  (open  source)  wykonawca  będzie  świadczył  usługę  serwisu  przez  okres  umowy.” 

Mając  na  względzie  powyższe  wymagania,  szczegóły  w  zakresie  systemów  operacyjnych 

oraz motorów bazodanowych opartych na oprogramowaniu otwartym (open source), można, 

a nawet należy uzgodnić na etapie projektu technicznego, a wybór tego oprogramowania nie 

ma wpływu na cenę (licencja nie wymaga wnoszenia płat). Wybór optymalnego rozwiązania 

implementacji  systemów  operacyjnych  i  baz  danych  jest  uzależniony  od  środowiska  zama-

wiającego,  w  którym ma  zostać  ono  zaimplementowane (najczęściej  będą to tzw. maszyny 

wirtualne). Należności ryczałtowe z tytułu utrzymania tego oprogramowania są ujęte w kosz-

tach serwisu (tabela nr 2).  

Z oferty nr U-

14864  wynika, że przystępujący otrzymał ofertę od Clico sp. z o.o. z siedzibą w 

Krakowie na urządzenie LUNA NETWORK HSM S700. W tym na Client Licences Luna NE-

TWORK HSM7 o kodzie 908-000402-001-001, prz

y czym jak wynika to z załączonego cen-

nika ten kod odpowiada 1 

– 10 licencji 

Reasumując uważamy, że zasadnym jest stwierdzenie, że przedstawiona oferta (wypełniony 

załącznik  nr  2)  jest  kompletna,  poprawna  technicznie  i  możliwa  do  realizacji,  a  posiadane 

ko

mpetencje i doświadczenie Eurocert dają realne podstawy do stwierdzenia, że zamówienie 

na zakup kwalifikowanych usług zaufania powinno zostać zrealizowane zgodnie z wymaga-

niami zamawiającego.  

Izba zważyła, co następuje: 

Izba stw

ierdziła, że zgłoszone przystąpienie spełnia wymogi określone w art. 525 ust. 1 – 3 

ustawy.  

Izba nie dopatrzyła się zaistnienia przesłanek odrzucenia odwołania, o których mowa w art. 

528 ustawy.  

Izba oceniła, że odwołujący wykazał przesłankę materialnoprawną dopuszczalności odwoła-

nia z art. 505 ust. 1 ustawy.  

Zarzut naruszenia przez zamawiającego art. 226 ust. 1 pkt 5 ustawy przez odrzucenie oferty 

odwołującego pod zarzutem, że treść tej oferty jest niezgodna z warunkami zamówienia, tj.  

a.  pkt  II  Załącznika  nr  1  ‐  Opis  Przedmiotu  Zamówienia  (dalej:  „OPZ”)  do  Projektowanych 

postanowień umowy (stanowiących Załącznik nr 2 do SWZ). Wedle twierdzenia zamawiają-

cego 

zawarto  tam  wymóg  przedstawienia  w  ofercie  oprogramowania  w  zakresie  oferowa-

nych 

przez wykonawcę licencji. Tymczasem, pkt II Załącznika nr 1 do OPZ zawiera wskaza-

nie  wymagań  dotyczących  oprogramowania,  notabene  spełnionych  przez  odwołującego,  a 

nie 

wskazania co do sposobu wypełnienia formularza ofertowego;  

b. rzekomego obowiązku wskazania konkretnych nazw własnych licencji na oprogramowanie 

wpisanych do Tabeli nr 1 w Załączniku nr 1 do SWZ – Formularz ofertowy (Formularz Ceno-

wy), w poz. 2, 3 i 7 pomimo iż SWZ w żadnym postanowieniu nie wymaga wskazania tych 

danych;  

c. rzekomego obowi

ązku dostarczenia więcej niż jednej licencji na systemy operacyjne i mo-

tory bazodanowe, podczas gdy SWZ w żadnym postanowieniu nie wprowadza minimalnych 

parametrów ilościowych dla tego oprogramowania 

Zarzuty zasługują na uwzględnienie. Jeżeli chodzi o pozycje 2 i 3 zamawiający wskazał, że 

w  formularzu  cenowym  oczekuje  wskazania  nazwy  oprogramowania,  a  nie  nazwy  licencji. 

Zamawiający jednocześnie w załączniku nr 2 do SWZ definiował, co rozumie pod pojęciem 

oprogramowania i licencji. N

azwa licencji nie była przez zamawiającego wymagana w żadnej 

ze spornych pozycji. Tym samym wskazanie w poz. 2 nazwy Client Licenses Luna Network 

HSM7 czy jakiejkolwiek, 

innej nie było zgodne z wymaganiem zamawiającego. Skoro tak, to 

porównanie oferty odwołującego i uczestnika postępowania, nie mogło mieć w tym zakresie 

znaczenia dla rozstrzygnięcia, gdyż treść oferty przystępującego nie mogła stanowić wzorca 

odniesienia  przy  badaniu  zgodności  oferty  z  warunkami  zamówienia.  W  tym  zakresie  nie-

przydatny  dla  r

ozstrzygnięcia  był  również  dowód  przedłożony  przez  przystępującego,  gdyż 

na  jego  podstawie  Izba  nie  była  w  stanie  ustalić  nazwy  oprogramowania,  jaką  należało 

wskazać dla licencji middleware i SDK dla urządzeń Luna Network HSM S7000. Odwołujący 

wskazał w poz. 2 i 3 oprogramowanie producenta HSM i podał, że cena jest wliczona w ce-

nie poz. 1. W żaden sposób nie zostało w postępowaniu wykazane, że istnieje nazwa opro-

gramowania  producenta  HSM,  którą  powinna  przyjąć  inne  brzmienie  niż  wskazane  przez 

odwołującego.  Zamawiający  nie  próbował  tej  okoliczności  dowodzić  twierdząc  jedynie,  że 

powinna być podana, bo tego wymagał, a przystępujący wykazał, że jest nazwa dla licencji 

na oprogramowanie middleware, ale nie wskazał jaka jest nazwa tego oprogramowania, co 

do pozy

cji 3, to przystępujący wskazał, że zaoferował oprogramowanie nie będące oprogra-

mowaniem producenta HSM, a zatem z tej okoliczności także nie można wywieść negatyw-

nych  skutków  dla  odwołującego,  który  oferuje  oprogramowanie  producenta  HSM.  Izba  od-

czytuje of

ertę odwołującego w sposób odmienny od przedstawionego przez zamawiającego i 

przystępującego, w ocenie Izby odwołujący wskazując w poz. 1 producenta HSM Luna Ne-

twork HSM S700 dla 

urządzenia HSM wraz z wbudowanym oprogramowaniem i następnie w 

poz. 2 i 3 wsk

azując, że licencje dotyczą oprogramowania producenta HSM oraz wliczone są 

w cenę urządzeń tego producenta wyraźnie sprecyzował, że chodzi o oprogramowanie pro-

ducenta  Luna  Network  HSM  S700,  bo  skoro  bowiem 

sprecyzował  producenta  urządzenia i 

samo urządzenie i dodatkowo wskazał, że koszt nabycia tak urządzeń jak i licencji zawiera 

się w koszcie zakupu urządzeń, to w ocenie Izby bez przedstawienia dowodu przeciwnego 

trudno jest uznać, że oprogramowanie middleware i SDK miałoby pochodzić od producenta 

innego n

iż producent Luna Network HSM S700. Co więcej przeciwnie niż przystępujący, od-

wołujący nie wskazał w żadnej z tych pozycji, że oferuje oprogramowanie własne, wskazał, 

że  będzie  to  oprogramowanie  producenta  urządzenia.  W  ocenie  Izby  niewskazanie  nazwy 

oprog

ramowania przy jednoczesnym określeniu producenta tego oprogramowania i wskaza-

niu urządzenia, z którym ma współpracować pozwala zamawiającemu na weryfikację złożo-

nej oferty. Za nadmiarowe i nie wynikające z treści oferty Izba uważa odczytywanie jej treści 

w oderwaniu od tego, co rzeczywiście zostało zaoferowane, tym samym Izba nie dała wiary 

twierdzeniom  zamawiającego,  że  to  może  być  oprogramowanie  dowolnego  producenta 

urządzeń HSM.  

Izba stoi na stanowisku, że przedmiot zamówienia w zakresie poz. 2 i 3 został skonkretyzo-

wany  w  sposób  umożliwiający  jego  weryfikację.  Izba  ponownie  podkreśla,  że  zamawiający 

nie  wymagał  nazw  licencji,  ale  nazwy  oprogramowania,  tym  samym  brak  podania  nazw  li-

cencji nie może świadczyć o niezgodności treści oferty z treścią SWZ.  

I

zba zauważa także, iż treść SWZ nie jest jednoznaczna co do momentu obowiązku podania 

nazw oprogramowania. Z powołanego przez zamawiającego par. 1 ust. 1 pkt 2 załącznika nr 

2 do SWZ z wyjaśnienia zawartego przy gwiazdce wynika bowiem, że pola wykropkowane w 

zakresie sprzedaży i dostawy oprogramowania dla usługi opatrywania pieczęciami kwalifiko-

wanym  dokumentów  elektronicznych  są  do  uzupełnienia  po  odbiorze  oferty  najkorzystniej-

szej. Ustawa Pzp nie zna pojęcia odbioru oferty najkorzystniejszej, zamawiający nie wskazał, 

że jest to  moment  wyboru oferty  najkorzystniejszej,  a jednocześnie  podał  definicję  odbioru, 

czyli moment potwierdzenia przez zamawiającego należytego wykonania umowy w zakresie 

poszczególnych zobowiązań wykonawcy. Tym samym w ocenie Izby, co najmniej wątpliwe, 

jest  wysnuwanie  na  podstawie  takiego  opisu  twi

erdzenia,  że  momentem  wprowadzenia  do 

umowy nazw oprogramowania jest data 

złożenia oferty. Słusznie w ocenie Izby podnosi od-

wołujący, że przedmiotem zamówienia był zakup kwalifikowanych usług zaufania w tym za-

kup i instalacja dwóch urządzeń HSM, zakup licencji do oprogramowania, zakup certyfikatów 

kwalifikowanych e-

pieczęci. Zatem zamawiający nie nabywa oprogramowania dedykowane-

go mu do świadczenia usług kwalifikowanych zaufania, ale jedynie licencje do takiego opro-

gramowania, a mimo to oczekuje w ofercie p

odania nie nazw licencji, które pozwalałyby mu 

na weryfikację bezterminowości licencji, czy braku ograniczeń, o których mowa w par. 1 ust. 

5  załącznika  nr  2  do  SWZ,  ale  nazw  samego  oprogramowania,  które  przecież  może  mieć 

przypisanych kilka modeli licencjo

nowania, otwartych, zamkniętych, z ograniczeniami teryto-

rialnymi,  przedmi

otowymi  lub  bez  takich  ograniczeń.  Co  więcej  zamawiający  nie  określa  w 

sposób  spójny, kiedy  informacje  o  nazwie oprogramowania mają mu  być  podane,  czy to w 

ofercie,  jak  wskazuje  on  i  uczestnik  na rozprawie,  czy  po  odbiorze  oferty  najkorzystniejszej 

jak  wyn

ika  z  projektowanych  postanowień  umowy.  Tym  samym  z  tych  niejednoznaczności 

SWZ, w ocenie Izby, 

nie można wyciągać negatywnych konsekwencji dla wykonawcy.  

W  konsekwencji  skoro  SWZ  je

st  niejednoznaczna, co do tego  kiedy  należało podać  nazwy 

oprogramowania 

i co jeszcze raz należy podkreślić nazwy oprogramowania nie przesądzały 

o modelu licencjonowania, nie można było uznać, że brak podania nazwy oprogramowania w 

poz.  7 formularza  cenowe

go jest istotnym brakiem skutkującym niezgodnością oferty z wa-

runkami  zam

ówienia.  Nie  bez  znaczenia jest  także  fakt,  że  zarówno  odwołujący jak  i  przy-

stępujący  wycenili  poz.  7  na  zero  złotych,  brak  wpływu  tej  pozycji  na  wartość  zamówienia 

potwierdza  także  korespondencja  elektroniczna  z  T.  S.  z  PTI.  W  ocenie  Izby  odwołujący 

uwzględnił  licencje  na  systemy  operacyjne  i  motory  bazodanowe,  gdyż  wypełnił  ilość  tych 

licencji.  Nie  można  zatem  uznać,  że  świadczenie  w  tym  zakresie  nie  zostało  zaoferowane. 

Biorąc  pod uwagę treść  art.  223 ust.  2 pkt  3 ustawy,  gdyby  nie niespójność  SWZ,  o której 

mowa  wyżej,  ewentualna  niezgodność  w  zakresie  poz.  7  jako  niepowodująca  istotnych 

zmian w treści oferty nadawałaby się do poprawienia.  

Izba  nie  podziela  również  stanowiska  zamawiającego  i  uczestnika,  że  liczba  1  licencji  na 

oprogramow

anie systemów operacyjnych i motorów bazodanowych była niezgodna z treścią 

SWZ. W ocenie Izby zamawiający jedyne swoje wymagania dotyczące tych licencji sformu-

łował w pkt 7 rozdziału II załącznika nr 1 do umowy. Z tego punktu wynika zaś jedynie to, że 

jeśli licencje są producenckie, to mają mieć 3 letnie wsparcie producenta, a jeśli open sour-

ce,  to  serwis  ma  świadczyć  wykonawca  przez  czas  umowy.  Natomiast  z  tego  punktu  nie 

można wywieść, ile licencji ma być. Zamawiający na rozprawie i w odpowiedzi na odwołanie 

podnosił, że nie ma jednej licencji na system operacyjny i systemy motorów baz danych, ale 

nie wskazał minimalnej ilości systemów operacyjnych czy baz danych, zatem nie ma wzorca 

do  którego  można  odnieść  daną  podaną  w  ofercie odwołującego  – „licencja  1 szt.”  Nie za-

sługuje także na uwzględnienie argumentacja o konieczności 2 licencji z uwagi na pkt 5 roz-

działu  II  czyli  konieczność  zapewnienia  wysokiej  dostępności  w  lokalizacji  podstawowej  i 

zastępczej. Gdyby połączyć oba stanowiska zamawiającego okazałoby się bowiem, że nie-

zbędne są co najmniej 4 licencje - po jednej na system operacyjny lokalizacji podstawowej i 

zastępczej i po jednym na system motorów baz danych w obu lokalizacjach, czyli argumen-

tacja zamawiającego pozostaje w wewnętrznej sprzeczności, bo 2 licencje w tym modelu, to 

za mało, powinny być minimum 4. Izba wzięła także pod uwagę zapytanie nr 3 w którym wy-

konawca zmierzał do ustalenia ilości wdrożeń, a nie ilości licencji, co więcej w pytaniu z góry 

założono  wdrożenie  w  dwóch  lokalizacjach,  pytanie  dotyczyło  tego,  czy  wdrożenie  dotyczy 

jeszcze  innych  ośrodków  poza  dwoma.  W  konsekwencji  tak  pytanie,  jak  i  odpowiedź,  nie 

dotyczyły ilości licencji w poz. 7. Mając to na uwadze Izba nie dała wiary w tym zakresie sta-

nowisku 

zamawiającego. Natomiast w ocenie Izby odwołujący w sposób przystępny i jedno-

znaczny na rozprawie wskazał, że zamierza zapewnić wysoką dostępność przy zachowaniu 

zaoferowanej 1 licencji przez zawarcie w jej zakresie uprawnienia do kopiowania licencji na 

ko

lejne urządzenia. Tym samym w ocenie Izby zamawiający nie wykazał, że jego stanowisko 

o  niezgodności  treści  oferty  z  warunkami  zamówienia  znajduje  odzwierciedlenie  w  treści 

SWZ

. Mając powyższe na uwadze zarzut odwołania należało uznać za zasadny, a odrzuce-

nie oferty odwołującego nie zgodne z przepisami ustawy. Z tego względu konieczne stało się 

nakazanie unieważnienia dotychczasowych czynności zamawiającego i nakazanie przywró-

cenia oferty odwołującego do postępowania.  

Zarzut  naruszenia  przez  zamawiającego  art.  239  ust.  1  i  ust.  2  ustawy  przez  wybór  oferty 

mniej korzystnej niż oferta odwołującego, pomimo tego, iż oferta odwołującego była ważna i 

nie podlegała odrzuceniu. 

Zarzut potwierdził się. Zasadność zarzutu wynika z uwzględnienia zarzutu poprzedzającego, 

skoro  bowiem  oferta  odwołującego  nie  podlegała  odrzuceniu,  to  powinna  być  przez  zama-

wiającego przywrócona do postępowania, zamawiający powinien dokonać jej badania i oce-

ny  w  świetle  przyjętych  kryteriów  oceny  ofert,  a  następnie  dopiero  dokonać  wyboru  z 

uwzględnieniem  tej  oferty.  Takich  czynności  zamawiający  w  postępowaniu  nie  dokonał,  a 

zatem czynność wyboru oferty najkorzystniejszej została dokonana niezgodnie z przepisami 

ustawy i należało nakazać jej unieważnienie.  

Mając  na  uwadze  powyższe  orzeczono  jak  w  sentencji  na  podstawie  art.  553  zdanie  1 

ustawy. 

O kosztach postępowania odwoławczego orzeczono na podstawie art. 574 i 575 ustawy, tj. 

stosownie do wyniku postępowania, z uwzględnieniem postanowień Rozporządzenia Preze-

sa Rady Ministrów w sprawie szczegółowych rodzajów kosztów postępowania odwoławcze-

go, ich rozliczania oraz wysokości i sposobu pobierania wpisu od odwołania z dnia 30 grud-

nia 2020 r. (Dz.U. z 2020 r. poz. 2437) na podstawie par. 5 ust. pkt. 1 

w związku z par. 7 ust. 

1  pkt  1 

rozporządzenia  obciążając  kosztami  zamawiającego.  Izba  na  podstawie  akt  postę-

powania

, że odwołujący poniósł koszty wpisu w kwocie 15 000 zł, oraz koszty wynagrodze-

nia pełnomocnika,  które  wykazał  rachunkiem  na  kwotę  przewyższającą kwotę maksymalną 

wydatków  pełnomocnika,  stąd  Izba  ograniczyła  uznanie  kosztów  do  kwoty  3 600zł.,  z  tego 

względu Izba nakazała zamawiającemu, aby zwrócił odwołującemu oba poniesione koszty.  

Przewodniczący: 

…………………..