Sygn. akt KIO 1155/23
POSTANOWIENIE z dnia 10 maja 2023 r.
Krajowa Izba Odwoławcza - w składzie:
Przewodnicząca: Małgorzata Jodłowska
Protokolant:
Mikołaj Kraska
po rozpoznaniu w dniu 10 maja 2023 roku w Warszawie, na posiedzeniu niejawnym, odwołania wniesionego do Prezesa
Krajowej Izby Odwoławczej 24 kwietnia 2023 r. przez wykonawcę VULCAN Sp. z o.o., ul. Wołowska 6, 51- 116 Wrocław
w postępowaniu prowadzonym przez zamawiającego Centrum Usług Informatycznych we Wrocławiu, ul. Namysłowska
8, 50- 304 Wrocław
postanawia:
1. umarza postępowanie odwoławcze
2. nakazuje zwrot z rachunku bankowego Urzędu Zamówień Publicznych na rzecz wykonawcy VULCAN Sp. z
o.o. z siedzibą we Wrocławiu kwoty 15 000 zł 00 gr (słownie: piętnaście tysięcy złotych, zero groszy) uiszczonej
tytułem wpisu od odwołania.
Stosownie do art. 579 ust. 1 i art. 580 ust. 1 i 2 ustawy z dnia 11 września 2019 r. Prawo zamówień publicznych (Dz. U. z
2022 r., poz. 1710) na niniejsze postanowienie - 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ąca: ………………………
Sygn. akt KIO 1155/23
UZASADNIENIE:
Zamawiający – Centrum Usług Informatycznych we Wrocławiu prowadzi postępowanie o udzielenie zamówienia
publicznego pn: „Zakup systemu kadrowego, płacowego i finansowo – księgowego dla placówek oświatowych”, numer
referencyjny: CIU-ZZ.3201.2.2023.
Postępowanie prowadzone jest w trybie przetargu nieograniczonego, na podstawie ustawy z dnia 11 września 2019 r. –
Prawo zamówień publicznych (Dz. U. z 2022 r., poz. 1710) zwanej dalej „Pzp” lub „ustawa”. Ogłoszenie o zamówieniu
zostało opublikowane w Dzienniku Urzędowym Unii Europejskiej 12 kwietnia 2023 pod numerem 2023/S 072
220383.
W dniu 24 kwietnia 2023 roku do Prezesa Krajowej Izby Odwoławczej zostało wniesione odwołanie przez wykonawcę
VULCAN Sp. z o.o. z siedzibą we Wrocławiu (dalej jako „Odwołujący”) wobec niezgodnej z przepisami ustawy czynności
i zaniechań Zamawiającego.
Zakres czynności podlegających zaskarżeniu:
Postanowienia treści Specyfikacji Warunków Zamówienia
Odwołujący zarzucił Zamawiającemu naruszenie:
II. Wymagań w zakresie danych osobowych – załącznik do OPZ [ZARZUT#1]:
1) pkt 1.3 ppkt 1 lit a i c Specyfikacji Technicznej – Załącznika D13 do OPZ – Wymagań w zakresie danych
osobowych (dalej jako: „D13”) w zakresie ogólnych wymagań dotyczących bezpieczeństwa przetwarzania danych
osobowych w systemie informatycznym i sformułowania następujących wymogów [ZARZUT#1.1]:
„Jeżeli dane osobowe przetwarzane są bezpośrednio w systemie:
a. dane w spoczynku (z ang. data at rest) są szyfrowane zgodnie z aktualnymi standardami i zgodnie z wymogami
stawianymi w art. 32 ust. 1 RODO (min. AES-256), (…)
c. system umożliwia stosowanie metod pseudonimizację danych – szczegółowe metody pseudoanonimizacii
zostaną określone w analizie wdrożeniowej.”
2) pkt 1.4 ppkt 2 lit a-f D13 w zakresie ogólnych wymagań dotyczących bezpieczeństwa przetwarzania danych
osobowych w chmurze obliczeniowej (w części systemu działającego w środowisku chmurowym) i sformułowania
następujących wymogów
[ZARZUT#1.2]:
„2. System powinien zapewnić, że informacje przetwarzane w chmurze obliczeniowej są szyfrowane zgodnie z
poniższymi zasadami:
a) Zamawiający posiada dostęp do szczegółowych i aktualnych instrukcji konfiguracji usług chmury obliczeniowej
oraz metod weryfikacji poprawności ich konfiguracji i działania, w szczególności w zakresie szyfrowania
przetwarzanych informacji.
b) Przetwarzanie danych będzie odbywało się w poprawnej konfiguracji usług chmury obliczeniowej, zgodnie z
wytycznymi dostawcy usług chmury obliczeniowej, w tym pod kątem stosowania szyfrowania przetwarzanych
informacji;
c) informacje prawnie chronione przetwarzane w chmurze obliczeniowej są szyfrowane zarówno „data at rest”
jak i „data in transit” na zasadach co najmniej określonych w pkt 3.1.
d) Informacje są szyfrowane kluczami generowanymi przez Zamawiającego lub przez niego zarządzane, chyba
że z oszacowania ryzyka wynika, wyniknie iż dopuszczalne lub wskazane jest używanie kluczy szyfrujących
generowanych lub zarządzanych przez dostawcę usług chmury obliczeniowej.
e) W przypadku, gdy z szacowania ryzyka wynika konieczność utrzymywania i zarządzania kluczami
szyfrującymi przy wykorzystaniu sprzętowych rozwiązań (HSM9), to HSM mogą być udostępniane przez dostawcę
usług chmury obliczeniowej, przy uwzględnieniu tego elementu w szacowaniu ryzyka. HSM powinny spełniać
wymagania minimum FIPS10 1402 Level 2 lub równoważne.
f) Proces zarządzania kluczami szyfrującymi powinien uwzględniać przechowywanie w ramach własnej
infrastruktury kopii kluczy szyfrujących, które zostały wygenerowane lub są zarządzane przez dostawcę usług
chmury obliczeniowej, chyba że z oszacowania ryzyka wynika uzasadniony brak takiej potrzeby”.
3) pkt 1.5 ppkt 1 i 2 D13 w zakresie wymogów zarządzania uprawnieniami użytkowników systemu w zakresie
dostępu do danych osobowych i sformułowania następujących wymogów [ZARZUT#1.3]:
„1. System powinien wyodrębniać poszczególne kategorie danych (np. imię i nazwisko, adres, PESEL) i umożliwiać
dostosowanie do których kategorii danych ma dostęp dany użytkownik.
2. System powinien umożliwiać tworzenie grup użytkowników (np. pracownicy, kierownicy, dyrektorzy) w
stosunku do których można dostosować do których kategorii danych grupa ma dostęp”.
4) pkt 1.7 ppkt 1-7 D13 w zakresie wymagań funkcjonalnych związanych z realizacją w systemie praw osoby,
której dane dotyczą, o których mowa w art. 7 oraz art. 15 do art. 22 RODO w szczególności rejestracji zgody i
cofnięcia zgody, do usunięcia
danych, sprzeciwu, sprostowania, ograniczenia dostępu do danych, informacji o przetwarzaniu, kopii danych) i
sformułowania następujących wymogów [ZARZUT#1.4]:
„1. System generuje raporty wykonywania operacji na rekordach zawierających dane osobowe ze wskazaniem
użytkownika i czynności, która została przeprowadzona.
2. System generuje raporty rekordów danych przetwarzanych na podstawie zgody.
3. System generuje raporty rekordów danych, dla których wycofano zgodę na przetwarzanie danych.
4. System generuje raporty dla rekordów danych, których czas retencji minął.
5. System generuje raporty dotyczące żądań podmiotów danych praw art. 1615- 18 oraz 20-22, albo
ograniczenie UODO z art. 58 ust.2 lit. f RODO.
6. System generuje raporty o przekazaniu informacji, o których mowa w pkt 2 dla potrzeb rozliczalności.
7. System wykonuje kompletny wydruk lub serie wydruków zawierających komplet danych osobowych
wskazanej/wyszukanej osoby w przejrzystej jasnej postaci wraz z metadanymi dotyczącymi operacji
wykonywanych na wydrukowanych danych”.
5) pkt 1.8 ppkt 1 i 2 D13 w zakresie wymogów dot. kopii danych / backupów danych osobowych i sformułowania
następujących wymogów [ZARZUT#1.5]:
„1. System umożliwia dokonywanie backupów danych osobowych z wykorzystaniem kopii różnicowych lub
przyrostowych w oparciu o harmonogram i na żądnie”.
6) pkt 1.9 ppkt 1-3 D13 w zakresie wymogów dot. retencji danych osobowych
i sformułowania następujących wymagań [ZARZUT#1.6]:
„1 . System umożliwia ustawienie retencji danych dla danych przetwarzanych w systemie.
2. System umożliwia oznaczenie (tagowanie, oflagowanie) rekordów danych dotyczących osób, których czas
retencji minął. Oznaczanie skutkuje automatycznym (realizowanym przez system) wykluczeniem oznaczonych
danych ze „zwykłych operacji”.
3. System powiadamia użytkownika o upływie czasu retencji danych oraz umożliwia usunięcie danych, których
czas retencji minął”.
7) pkt 1.10 ppkt 1-6 i 7-10 D13 w zakresie wymagań funkcjonalnych związanych z realizacją w systemie praw
osoby, której dane dotyczą, o których mowa w art. 7 oraz art. 15 do art. 22 RODO w szczególności. rejestracji
zgody i cofnięcia zgody, do usunięcia danych, sprzeciwu, sprostowania, ograniczenia dostępu do danych,
informacji o przetwarzaniu, kopii danych) i sformułowania następujących wymogów [ZARZUT#1.7]:
as „1. System umożliwia oznaczenie (tagowanie, oflagowanie) rekordów danych
dotyczących osób, których przetwarzanie odbywa się na podstawie zgody.
2. W przypadku cofnięcia zgody na przetwarzanie danych takie oznaczanie skutkuje powiadomieniem
użytkownika, że dane można przechowywać, ale nie należy ich tymczasowo używać w „zwykłych operacjach”.
3. W przypadku cofnięcia zgody na przetwarzanie danych takie oznaczanie skutkuje automatycznym
(realizowanym przez system) wykluczeniem oznaczonych danych ze „zwykłych operacji”.
4. System umożliwia oznaczanie (tagowanie, oflagowywanie) rekordów danych dotyczących osób które zgłosiły
żądania w zakresie realizacji swoich praw art. 15- 18 RODO oraz art. 20-22 RODO albo ograniczenie UODO z art.
58.2.f. (takie oznaczanie skutkuje powiadomieniem użytkownika, że dane można przechowywać, ale nie należy ich
tymczasowo używać w „zwykłych operacjach”).
5. System umożliwia oznaczanie (tagowanie, oflagowywanie) rekordów danych dotyczących osób które zgłosiły
żądania w zakresie realizacji swoich praw art. 15- 18 RODO oraz art. 20-22 RODO albo ograniczenie UODO z art.
58 ust. 2 lit. f RODO; takie oznaczanie skutkuje automatycznym (realizowanym przez system) wykluczeniem
oznaczonych danych ze „zwykłych operacji”.
6. System przechowuje historię implementowanych w nim żądań osób (kogo dotyczyło, w jakim okresie
występowało, jakiego typu żądanie). Wymóg jest spełniony również jeżeli istnieje inny centralny system o takiej
funkcjonalności dla wielu systemów/aplikacji. (…)
8. System umożliwia wyszukanie osoby wg określonego zestawu atrybutów, w szczególności wg unikalnych
identyfikatorów jeśli występują w systemie; prezentacja wyników wyszukiwania odbywa się „po jednym rekordzie”
albo tylko w przypadku znalezienia jednego rekordu w wyniku zastosowania kryteriów wyszukiwania.
9. System umożliwia (w wyniku wywołania wbudowanej w niego funkcjonalności) eksportowanie danych
dotyczących konkretnej osoby w jednym z następujących formatów danych: txt, csv, xml, json. Dopuszczalne jest
wielokrotne wywoływanie funkcjonalności w celu otrzymania kompletu danych, oczekiwane jest jednokrotne
wywołanie skutkujące kompletem danych.
10. Lista „zwykłych operacji”, tj. tych w których nie można tymczasowo używać danych z rekordów oznaczonych
(z powodu zgłoszenia żądania w zakresie realizacji praw osób albo ograniczenia UODO z art. 58 ust. 2 lit. f
RODO) jest konfigurowalna dla systemu i występującego żądania/żądań”.
W zakresie powyższych postanowień SWZ Zamawiającemu zarzucam naruszenie:
1) art. 99 ust. 1 i ust. 4 w zw. z art. 16 pkt 1 i 3 PZP poprzez opisanie przedmiotu
zamówienia w sposób niejednoznaczny, niewyczerpujący i nieuwzględniający wszystkich okoliczności mających wpływ
na sporządzenie oferty przez wykonawców oraz w sposób uniemożliwiający uczciwą konkurencję, naruszający zasadę
równego traktowania wykonawców oraz nieproporcjonalny do przedmiotu zamówienia, poprzez sformułowanie
wskazanych powyżej wymagań, co w konsekwencji prowadzi do uniemożliwienia złożenia oferty przez wykonawców
oferujących rozwiązania w pełni zgodne z wymaganiami w zakresie ochrony danych osobowych realizowanych w
sposób odmienny niż przewiduje to w SWZ Zamawiający.
Stawiając powyższe zarzuty wnoszę o nakazanie Zamawiającemu:
1) modyfikację wymagania z pkt 1.3 ppkt 1 lit a i c D13 poprzez zmianę treści wymagań zgodnie z poniższą
propozycją:
„Jeżeli dane osobowe przetwarzane są bezpośrednio w systemie:
a. dane w spoczynku (z ang. data at rest) są szyfrowane zgodnie z aktualnymi standardami (min. AES-256) lub są
zabezpieczone w inny sposób zgodny z wymogami stawianymi w art. 32 ust. 1 RODO, (…)
c. system umożliwi stosowanie metod pseudonimizacji danych – o ile zastosowanie pseudonimizacii okaże się
konieczne stosownie do wymogów RODO i zostanie to potwierdzone i uszczegółowione co do zakresu i sposobu
w analizie wdrożeniowej.”
2) modyfikację wymagania z pkt 1.4 ppkt 2 lit a-f D13 poprzez zmianę treści wymagań zgodnie z poniższą
propozycją:
„2. System powinien zapewnić, że informacje przetwarzane w chmurze obliczeniowej są zabezpieczone zgodnie z
poniższymi zasadami:
a) Zamawiający posiada dostęp do szczegółowych i aktualnych instrukcji konfiguracji usług chmury obliczeniowej
oraz metod weryfikacji poprawności ich konfiguracji i działania, w szczególności w zakresie szyfrowania
przetwarzanych informacji.
b) Przetwarzanie danych będzie odbywało się w poprawnej konfiguracji usług chmury obliczeniowej, a jeżeli
usługi chmurowe będą świadczone przez podmiot trzeci -zgodnie z wytycznymi dostawcy usług chmury
obliczeniowej, w tym pod kątem stosowania szyfrowania przetwarzanych informacji;
c) informacje prawnie chronione przetwarzane w chmurze obliczeniowej są szyfrowane zarówno „data at rest”
jak i w „data in transit” na zasadach co najmniej określonych w pkt 3.1 1.3.
d) Jeżeli informacje są szyfrowane to jest to realizowane kluczami generowanymi przez Zamawiającego lub
przez niego zarządzane, chyba że z oszacowania ryzyka wynika, wyniknie iż dopuszczalne lub wskazane jest
używanie kluczy szyfrujących generowanych lub zarządzanych przez dostawcę usług chmury obliczeniowej.
e) W przypadku, gdy z szacowania ryzyka wynika konieczność utrzymywania i zarządzania kluczami
szyfrującymi przy wykorzystaniu sprzętowych rozwiązań (HSM9), to HSM mogą być udostępniane przez dostawcę
usług chmury obliczeniowej, przy uwzględnieniu tego elementu w szacowaniu ryzyka. HSM powinny spełniać
wymagania minimum FIPS10 1402 Level 2 lub równoważne.
f) Proces zarządzania kluczami szyfrującymi powinien uwzględniać przechowywanie w ramach własnej
infrastruktury kopii kluczy szyfrujących, które zostały wygenerowane lub są zarządzane przez dostawcę usług
chmury obliczeniowej, chyba że z oszacowania ryzyka wynika uzasadniony brak takiej potrzeby”.
3) modyfikację wymagań z pkt 1.5 ppkt 1 i 2 D13 poprzez zmianę treści wymagań zgodnie z poniższą
propozycją:
„1. System powinien wyodrębniać poszczególne kategorie predefiniowanych danych (np. imię i nazwisko, adres,
PESEL) i umożliwiać dostosowanie do których kategorii danych ma dostęp dany użytkownik.
2. System powinien umożliwiać tworzenie lub posiadać predefiniowane grupy użytkowników (np. pracownicy,
kierownicy, dyrektorzy) w stosunku do których można dostosować do których kategorii danych grupa ma dostęp;
4) modyfikację wymagań z pkt 1.7 ppkt 1-7 D13 poprzez zmianę treści wymagań zgodnie z poniższą propozycją;
„1 . System generuje raporty obrazujące jakiego zakresu zmian dokonano, wartość początkową i wartość końcową
ze wskazaniem użytkownika i czynności, która została przeprowadzona.
2. System generuje raporty rekordów danych przetwarzanych na podstawie zgody.
3. System generuje raporty rekordów danych, dla których wycofano zgodę na przetwarzanie danych.
4. System generuje raporty dla rekordów danych, których czas retencji minął.
5. System generuje raporty dotyczące żądań podmiotów danych praw art. 1615- 18 oraz 20-22, albo
ograniczenie UODO z art. 58 ust.2 lit. f RODO.
6. System generuje raporty o przekazaniu informacji, o których mowa w pkt 2 dla potrzeb rozliczalności.
7. System wykonuje kompletny wydruk lub serie wydruków zawierających komplet danych osobowych
wskazanej/wyszukanej osoby w przejrzystej jasnej postaci wraz z metadanymi dotyczącymi operacji
wykonywanych na wydrukowanych danych”.
5) usunięcie wymagania z pkt 1.8 ppkt 1 i 2 D13 poprzez zmianę treści wymagań zgodnie z poniższą
propozycją:
„1. Jeżeli wykonawca nie zapewnia możliwości backupowania danych w inny sposób, System umożliwi
dokonywanie backupów danych osobowych z wykorzystaniem kopii
różnicowych lub przyrostowych w oparciu o harmonogram i na żądnie.
6) modyfikację wymagań z pkt 1.9 ppkt 1-3 D13 poprzez zmianę treści wymań zgodnie z poniższą propozycją i
wprowadzenie pkt 4:
„1 . System umożliwia ustawienie retencji danych dla danych przetwarzanych w systemie.
2. System umożliwia oznaczenie (tagowanie, oflagowanie) rekordów danych dotyczących osób, których czas
retencji minął. Oznaczanie skutkuje automatycznym (realizowanym przez system) wykluczeniem oznaczonych
danych ze „zwykłych operacji”.
3. System powiadamia użytkownika o upływie czasu retencji danych oraz umożliwia usunięcie danych, których
czas retencji minął.
4. Sposób spełnienia wymagań w zakresie retencji danych, o których mowa w pkt 1-3 powyżej zostanie
opracowany przez wykonawcę na etapie Analizy Systemowej, przy czym Zamawiający dopuszcza w wypadku, gdy
wymagania te nie stanowią automatycznego narzędzia systemu, aby zostały zrealizowane przez Wykonawcę w
ramach Usług Utrzymania”;
7) modyfikacje wymagań z pkt 1.10 ppkt 1-6 i 7-10 D13 poprzez zmianę treści SWZ zgodnie z poniższą
propozycją:
„1 . System umożliwia oznaczenie (tagowanie, oflagowanie) rekordów danych dotyczących osób, których
przetwarzanie odbywa się na podstawie zgody.
2. W przypadku cofnięcia zgody na przetwarzanie danych takie oznaczanie skutkuje powiadomieniem
użytkownika, że dane można przechowywać, ale nie należy ich tymczasowo używać w „zwykłych operacjach”.
3. W przypadku cofnięcia zgody na przetwarzanie danych takie oznaczanie skutkuje automatycznym
(realizowanym przez system) wykluczeniem oznaczonych danych ze „zwykłych operacji”.
4. System umożliwia oznaczanie (tagowanie, oflagowywanie) rekordów danych dotyczących osób które zgłosiły
żądania w zakresie realizacji swoich praw art. 15- 18 RODO oraz art. 20-22 RODO albo ograniczenie UODO z art.
58.2.f. (takie oznaczanie skutkuje powiadomieniem użytkownika, że dane można przechowywać, ale nie należy ich
tymczasowo używać w „zwykłych operacjach”).
5. System umożliwia oznaczanie (tagowanie, oflagowywanie) rekordów danych dotyczących osób które zgłosiły
żądania w zakresie realizacji swoich praw art. 15- 18 RODO oraz art. 20-22 RODO albo ograniczenie UODO z art.
58 ust. 2 lit. f RODO; takie oznaczanie skutkuje automatycznym (realizowanym przez system) wykluczeniem
oznaczonych danych ze „zwykłych operacji”.
6. System przechowuje historię implementowanych w nim żądań osób (kogo
dotyczyło, w jakim okresie występowało, jakiego typu żądanie). Wymóg jest spełniony również jeżeli istnieje inny
centralny system o takiej funkcjonalności dla wielu systemów/aplikacji.
7. Jeżeli system przetwarza dane osobowe w różnych celach to jest tego świadomy i implementuje lub
umożliwia oznaczanie danych w oparciu o konkretne cele przetwarzania; takie oznaczenie ma swoje logiczne
konsekwencje dla możliwych czynności przetwarzania oraz realizacji praw osób.
8. System umożliwia wyszukanie osoby wg określonego zestawu atrybutów określonych przez wykonawcę, w
szczególności wg unikalnych identyfikatorów jeśli występują w systemie; prezentacja wyników wyszukiwania
odbywa się „po jednym rekordzie” albo tylko w przypadku znalezienia jednego rekordu w wyniku zastosowania
kryteriów wyszukiwania.
9. System umożliwia (w wyniku wywołania wbudowanej w niego funkcjonalności) eksportowanie danych
dotyczących konkretnej osoby w jednym z następujących formatów danych: txt, csv, xml, json, przeszukiwalny i
edytowalny pdf. Dopuszczalne jest wielokrotne wywoływanie funkcjonalności w celu otrzymania kompletu danych,
oczekiwane jest jednokrotne wywołanie skutkujące kompletem danych.
10. Lista „zwykłych operacji”, tj. tych w których nie można tymczasowo używać danych z rekordów oznaczonych
(z powodu zgłoszenia żądania w zakresie realizacji praw osób albo ograniczenia UODO z art. 58 ust. 2 lit. f
RODO) jest konfigurowalna dla systemu i występującego żądania/żądań”.
III. Harmonogram ramowy – termin wdrożenia i dostosowania Systemu do potrzeb Zamawiającego [Zarzut #2]
1) § 6 ust. 2 lit. a, b i c wzoru umowy stanowiącego Załącznik nr 9 SWZ (dalej: „Wzór
Umowy”) – w zakresie jakim Zamawiający wyznaczył na wdrożenie i dostosowanie Systemu do potrzeb Zamawiającego
termin do 31.07.2023 roku i w dalszej kolejności począwszy od dnia 1.08.2023 roku termin na udostępnienie, udzielenie
licencji oraz świadczenie Usług Utrzymania dla Modułu Płacowego do centralnego naliczania płac dla placówek
oświatowych obsługiwanych przez CUI.
W zakresie powyższego postanowienia SWZ Zamawiającemu zarzucam naruszenie następujących przepisów:
1) art. 99 ust. 1, ust. 2 i ust. 4 w zw. z art. 16 pkt 1) i pkt 3) w zw. 436 pkt 1 PZP poprzez opisanie przedmiotu
zamówienia w sposób niewyczerpujący, nieuwzgledniający okoliczności mających wpływ na sporządzenie oferty i
realizację zamówienia, nieproporcjonalny oraz w sposób uniemożliwiający uczciwą konkurencję i naruszający
zasadę równego traktowania wykonawców, poprzez postawienie
wymagania, aby wykonawca wdrożył i dostosował System do potrzeb Zamawiającego w terminie do 31.07.2023 roku, nie
zaś w terminie liczonym od dnia zawarcia umowy, podczas gdy wdrożenie i dostosowanie Systemu w tym terminie jest
niemożliwe i nierealne nawet dla wykonawców, którzy aktualnie wykonują umowę na rzecz Zamawiającego oraz w
terminie, który wbrew art. 436 pkt 1 PZP nie jest liczony od dnia zawarcia umowy, a brak jest obiektywnego uzasadnienia
dla wskazania daty wykonania umowy w tym zakresie.
Stawiając powyższe zarzuty wnoszę o nakazanie Zamawiającemu:
1) dokonania modyfikacji treści Wzoru Umowy poprzez wprowadzenie terminu na wdrożenie i dostosowanie
Systemu do potrzeb Zamawiającego wynoszącego co najmniej 180 dni od dnia zawarcia Umowy oraz odpowiednio
wydłużenia terminu na udostępnienie, udzielenie licencji oraz świadczenie Usług Utrzymania dla Modułu
Płacowego do centralnego naliczania płac dla placówek oświatowych obsługiwanych przez CUI.
IV. Załącznik nr 1 do Umowy - Opis przedmiotu zamówienia do systemu kadrowego, płacowego i finansowoksięgowego dla placówek oświatowych (dalej „OPZ”) [Zarzut#3]
1) pkt WO.12 OPZ – w zakresie jakim Zamawiający wymaga, aby System spełniał wymagania ustawy z dnia 4
kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych zgodnie z
poziomem co najmniej A [Zarzut#3.1];
2) pkt WT.21 OPZ – w zakresie jakim Zamawiający wymaga, aby System posiadał wbudowaną funkcjonalność
umożliwiającą wybiórczą lub kompletną anonimizację danych, które nie powinny być już przetwarzane w Systemie
i dotyczy to zwłaszcza pól dedykowanych, przeznaczonych do wpisywania danych osobowych [Zarzut#3.2];
W zakresie powyższych postanowień SWZ Zamawiającemu zarzucam naruszenie następujących przepisów:
1) art. 99 ust. 1, ust. 2 i ust. 4 w zw. z art. 16 pkt 1) i pkt 3)PZP poprzez opisanie przedmiotu zamówienia w
sposób niewyczerpujący, nieuwzgledniający okoliczności mających wpływ na sporządzenie oferty i realizację
zamówienia, nieproporcjonalny oraz w sposób uniemożliwiający uczciwą konkurencję i naruszający zasadę
równego traktowania wykonawców, poprzez postawienie nieuzasadnionych wymagań w postaci zgodności z
WCAG na poziomie A oraz wybiórczej lub kompletnej anonimizacji danych, podczas gdy wymogi te nie stanowią
obowiązku wykonawcy w świetle obowiązujących przepisów ustawy z dnia 4 kwietnia 2019 r. o dostępności
cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych (t.j. Dz. U. z 2023 r. poz. 82 z późn. zm.) (dalej
„UDC”) oraz RODO, a brak jest obiektywnego uzasadnienia dla stawiania takich w wymagań wobec przedmiotu
zamówienia stanowiącego rozwiązanie SaaS.
Stawiając powyższe zarzuty wnoszę o nakazanie Zamawiającemu:
1) usunięcie pkt WO.12 OPZ;
2) usunięcie pkt WT.21 OPZ.
V. Waloryzacja wynagrodzenia [Zarzut#4]
1) § 18 ust. 10 pkt 1 Wzoru Umowy – w zakresie w jakim „Waloryzacja wynagrodzenia
Wykonawcy w oparciu o ust. 9 może nastąpić, gdy wskaźnik kosztów ogłaszany w komunikacie Prezesa Głównego
Urzędu Statystycznego za ostatni miesiąc poprzedzający wniosek o waloryzację wzrośnie o co najmniej 6%
(średnioroczny wskaźnik cen towarów i usług konsumpcyjnych ogółem ogłaszany w Monitorze Polskim w komunikatach
Prezesa Głównego Urzędu Statystycznego wyniesie powyżej 106) w stosunku do wysokości tego wskaźnika w miesiącu
zawarcia Umowy”.
W zakresie powyższego postanowienia Zamawiającemu zarzucam naruszenie następujących przepisów:
1) art. 3531 ustawy z dnia 23 kwietnia 1964 r. Kodeks cywilny (t.j. Dz. U. z 2022 r. poz. 1360 z późn. zm.) (dalej
„KC”) w zw. z art. 8 ust. 1 zw. z art. 16 pkt 3 PZP poprzez ukształtowanie postanowień umowy w sposób
naruszający zasadę swobody kontraktowania wyrażoną w art. 3531 KC oraz zasadę proporcjonalności poprzez
ukształtowanie stosunku zobowiązaniowego w sposób naruszający jego naturę, równowagę stron oraz
prowadzący do nadużycia praw podmiotowych Zamawiającego (jako podmiotu przygotowującego wzór umowy)
poprzez dopuszczenie waloryzacji wynagrodzenia wyłącznie gdy wskaźnik kosztów ogłaszany w komunikacie
Prezesa Głównego Urzędu Statystycznego za ostatni miesiąc poprzedzający wniosek o waloryzację wzrośnie o co
najmniej 6% (średnioroczny wskaźnik cen towarów i usług konsumpcyjnych ogółem ogłaszany w Monitorze
Polskim w komunikatach Prezesa Głównego Urzędu Statystycznego wyniesie powyżej 106) w stosunku do
wysokości tego wskaźnika w miesiącu zawarcia Umowy,
2) art. 99 ust. 1 PZP poprzez brak dopuszczenia waloryzacji wynagrodzenia w sytuacji gdy wskaźnik kosztów za
ostatni miesiąc jest niższy niż 6%, co skutkuje brakiem możliwości rzetelnej oceny ryzyk związanych z realizacją
Zamówienia i rzetelnej
kalkulacji ceny oferty, co stanowi naruszenie art. 99 ust. 1 PZP nakazującego Zamawiającemu opisanie przedmiotu
zamówienia 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.
Stawiając powyższe zarzuty wnoszę o nakazanie Zamawiającemu:
1) modyfikację § 18 ust. 10 pkt 1 Wzoru Umowy i obniżenie progu uprawniającego do waloryzacji wynagrodzenia
z 6% do 2% i nadanie mu następującego brzmienia: „10. Waloryzacja wynagrodzenia Wykonawcy w oparciu o ust.
9:
1) może nastąpić, gdy wskaźnik kosztów ogłaszany w komunikacie Prezesa Głównego Urzędu Statystycznego
za ostatni miesiąc poprzedzający wniosek o waloryzację wzrośnie o co najmniej 2% (średnioroczny wskaźnik cen
towarów i usług konsumpcyjnych ogółem ogłaszany w Monitorze Polskim w komunikatach Prezesa Głównego
Urzędu Statystycznego wyniesie powyżej 106) w stosunku do wysokości tego wskaźnika w miesiącu zawarcia
Umowy”.
VI. Szczegółowe wymagania dotyczące dokumentacji systemu informatycznego – Załącznik nr 8 do umowy
[Zarzut#5]
1) Załącznik nr 8 do Wzoru Umowy – w zakresie jakim Zamawiający stawia następujące wymagania:
2.1.1. b b) dokumentów tekstowych w formacie DOC (lub innym ogólnie dostępnym formacie
edytowalnym).
2.1.2 2. W przypadku diagramów, schematów dostarczonych w ramach dokumentacji powinny one
być dostarczone w narzędziu zgodnym z notacjami UML, BPMN, Archimate i zapisane w formacie
umożliwiającym ich przeglądanie w dostępnych publicznie i darmowych narzędziach, wraz ze
wskazaniem źródła ich pobrania lub poprzez dostarczenie niezbędnego do przeglądania
oprogramowania w ramach projektu.
2.1.3 3. Dokumentacja powinna uwzględniać zarówno środowisko produkcyjne,
testowe/szkoleniowe, jak i deweloperskie systemu.
2.1.5. a a) szablon dokumentu z wymaganymi elementami zawiera Załącznik 6, 2.1.5.c c) czcionka o
kroju Verdana,
2.1.5. d d) wersjonowanie dokumentacji – format wersji n.xx gdzie n oznacza numer kolejnej
zatwierdzonej wersji dokumentu, xx – numer kolejnej wersji opiniowanej, roboczej.
2.1.6. a zestawienie wszystkich uzgodnień i protokołów podpisanych na etapie realizacji – Załącznik 2,
2.1.6.b globalny rejestr zmian dotyczący dokumentacji powykonawczej – Załącznik 3, 2.2 2. Opis systemu: Opis
techniczny systemu powinien uwzględnić wszelkie zmiany dokonane w systemie i obejmować:
2.2.1 1. Schemat blokowy systemu wraz z opisem jego składowych oraz
przepływu i przetwarzania danych w systemie.
2.2.2 2. Diagram wdrożenia (deployment diagram) obejmujący wszystkie
składowe systemu (w nomenklaturze UML: węzły, środowiska wykonawcze, komponenty/artefakty), wraz ze ścieżkami
komunikacji pomiędzy składowymi oraz systemami zewnętrznymi z opisem wykorzystywanych protokołów i portów
wszystkich uruchomionych w systemie usług.
2.3.2 3.2 Opis konfiguracji stacji roboczej lub urządzenia klienckiego dla
użytkownika systemu
2.3.2 Opis powinien zawierać proces przygotowania i konfiguracji stacji roboczej lub urządzenia klienckiego dla
użytkownika pracującego w systemie. Opis przygotowania i konfiguracji stacji roboczej przeznaczonej do pracy w
systemie powinien zawierać:
2.3.2.1 1. Listę oprogramowania, zawierającą nazwę oprogramowania,
producenta, wersję, źródło pakietów instalacyjnych
2.3.2.2 2. Wymagania sprzętowe.
2.3.2.3 3. Wymagania dotyczące systemu operacyjnego oraz dodatkowego
oprogramowania ze wskazaniem wersji minimalnej.
2.3.2.4 4. Instrukcję instalacji oprogramowania.
2.3.3.1 1. Opis kodowania znaków w dokumentach wysyłanych z systemów
teleinformatycznych podmiotów realizujących zadania publiczne lub odbieranych przez takie systemy, także w
odniesieniu do informacji wymienianej przez te systemy z innymi systemami na drodze teletransmisji, o ile wymiana ta
ma charakter wymiany znaków.
2.3.3.2 2. Opis formatów danych w jakim udostępniane są zasoby informacyjne zgodnie z załącznikiem nr 2 do
rozporządzenia.
2.3.3.3 3. Opis logów, dzienników systemów zawierających odnotowanie działań użytkowników lub obiektów
systemowych polegające na dostępie do:
2.3.3. 3.a a) systemu z uprawnieniami administracyjnymi;
2.3.3. 3.b b) konfiguracji systemu, w tym konfiguracji zabezpieczeń
2.3.3. 3.c c) przetwarzanych w systemach danych podlegających prawnej ochronie w zakresie wymaganym
przepisami prawa.
2.3.4 4. Opis logów, dzienników systemów zawierający działania użytkowników lub obiektów systemowych, a
także inne zdarzenia związane z eksploatacją
systemu w postaci:
2.3.4. a a) działań użytkowników nieposiadających uprawnień administracyjnych 2.3.4.b b) zdarzeń systemowych
nieposiadających krytycznego znaczenia dla funkcjonowania systemu
2.3.4. c c) zdarzeń i parametrów środowiska, w którym eksploatowany jest system teleinformatyczny.
2.4.1 W dokumentacji, wykonawca zobowiązany jest przedstawić listę wszystkich licencji na dostarczone
oprogramowanie wraz z opisem sposobu licencjonowania. Opis powinien dotyczyć wszystkich aplikacji
wymagających licencjonowania (aplikacje, systemy operacyjne, bazy danych, urządzenia i inne). Lista licencji na
oprogramowanie powinna zawierać:
2.4.1.1 1. Nazwę oprogramowania.
2.4.1.2 2. Sposób licencjonowania (np. procesor, użytkownik; informacje o
metryce, uprawnieniach, ograniczeniach).
2.4.1.3 3. Ilości, rodzaje licencji (np. enterprise, standard) oraz poziom licencji. 2.4.1.4 4. Numer licencji.
2.5.1 Procedury mające na celu zabezpieczenie, bieżące utrzymanie i zapewnienie wysokiej niezawodności
działania systemu.
2.5.1.1 1. Przekazanie inicjalnych haseł do kont administracyjnych systemu wraz z procedurą bezpiecznej
zmiany haseł (bez wpływu na funkcjonowanie systemu). 2.6.1 1. Instrukcję rozpoczęcia, zawieszania i
zakończenia pracy w systemie.
2.6.3 3. Szczegółowy opis funkcjonalności systemu.
2.6.4 4. Opis ścieżek obsługi procesów.
2.6.5 5. Dokładny opis raportów generowanych w systemie. Opis powinien zawierać informacje dotyczące
parametryzacji, filtrowania i innych elementów personalizacyjnych dostępnych dla użytkownika oraz proces
eksportowania raportów do narzędzi zewnętrznych.
2.6.6 6. Opis komunikatów błędu wraz z podaniem rozwiązań.
2.6.8 8. Instrukcja pracy awaryjnej.
2.6.9 9. Szkolenie w wersji elektronicznej, w formie pozwalającej na
przeprowadzenie szkolenia w oprogramowaniu (Moodle), wraz z prawem licencyjnym pozwalającym w szczególności
na:
2.6.9 .a a. swobodne wykorzystanie przekazanych materiałów w ramach kursu na potrzeby szkoleniowe, w
zakresie w jakim CUI uzna za stosowne,
2.6.9 .b b. swobodną ingerencję dotyczącą zawartości kursu w tym zawartości merytorycznych jak i treści,
materiałów graficznych i audiowizualnych zawartych w przekazanym kursie.
2.7.1 1. Wykaz lokalizacji tworzących obszar w których przetwarzane są dane
osobowe (wykaz budynków, pomieszczeń lokalizacji serwerów i stacji roboczych). 2.7.7 7. Opis elementów
programowych i sprzętowych zabezpieczający system informatyczny przed działaniem szkodliwego oprogramowania
oraz oprogramowania, którego celem jest uzyskanie nieuprawnionego dostępu do systemu.
2.7.8 8. Opis zabezpieczeń chroniących przed utratą danych spowodowaną awarią zasilania lub zakłóceniami w
sieci zasilającej.
2.7.9 9. Opis zawierający wyszczególnienie realizacji pozostałych wymogów odnoszących się do środków
technicznych i organizacyjnych dla poziomu bezpieczeństwa zdefiniowanym na poziomie wysokim Załącznik 5
niniejszego dokumentu.
2.7.10 10. Dokument powinien zawierać odwołania do instrukcji użytkownika oraz procedur eksploatacyjnych
zwierających informacje o:
2.7.10 .a a. Procedurze i instrukcji rozpoczęcia, zawieszania i zamykania pracy w systemie 2.7.10.b b. Procedury
tworzenia kopii zapasowych zbiorów danych oraz programów i narzędzi programowych służących do ich
przetwarzania.
2.7.10 .c c. Sposobie, miejscu i okresie przechowywania nośników informacji zawierających dane osobowe oraz
kopie zapasowe określone w podpunkcie b). 2.7.10.d d. Procedurze wykonywania przeglądów i konserwacji
systemów oraz nośników informacji służących do przetwarzania danych osobowych.
2.8.2 2. Wskazanie sposobu oraz zasad dostępu do dokumentacji dotyczącej zasad bezpieczeństwa oraz
środków technicznych przyjmowanych w poszczególnych centrach przetwarzania danych.
4.3 System powinien zapewniać poziom bezpieczeństwa: Wysoki.
4.3 W celu osiągnięcia poziomu wysokiego, niezbędne jest zapewnienie środków określonych dla poziomów
bezpieczeństwa poziomu podstawowego, podwyższonego i wysokiego (tabela 1, 2 i 3)
W zakresie powyższych postanowień SWZ Zamawiającemu zarzucam naruszenie następujących przepisów:
1) art. 99 ust. 1, ust. 2 i ust. 4 w zw. z art. 16 pkt 1) i pkt 3) PZP poprzez opisanie przedmiotu zamówienia w
sposób niewyczerpujący, nieuwzgledniający okoliczności mających wpływ na sporządzenie oferty i realizację
zamówienia, nieproporcjonalny oraz w sposób uniemożliwiający uczciwą konkurencję i naruszający zasadę
równego traktowania wykonawców, poprzez sformułowanie ww. wymagań w zakresie
dokumentacji systemu informatycznego w sposób charakterystyczny dla
oprogramowania komputerowego wdrażanego (instalowanego) na infrastrukturze Zamawiającego, nie zaś rozwiązania w
modelu SaaS, czyniąc ww. wymagania niemożliwymi do spełnienia przez wykonawców ubiegających się o udzielenie
zamówienia.
Stawiając powyższe zarzuty wnoszę o nakazanie Zamawiającemu:
1) dokonania modyfikacji treści Załącznik nr 8 do Wzoru Umowy poprzez usunięcie wskazanych w Zarzucie#5
powyżej pkt:
1) 2.1.1 2) 2.1.1.b 3) 2.1.2 4) 2.1.3 5) 2.1.5.a 6) 2.1.5.c 7) 2.1.5.d 8) 2.1.6.a 18 9) 2.1.6.b 10) 2.2 11) 2.2.1 12)
2.2.2 13) 2.3.2 14) 2.3.2 15) 2.3.2.1 16) 2.3.2.2 17) 2.3.2.3 18) 2.3.2.4 19) 2.3.3.1 20) 2.3.3.2 21) 2.3.3.3 22)
2.3.3.3.a 23) 2.3.3.3.b 24) 2.3.3.3.c 25) 2.3.4 26) 2.3.4.a 27) 2.3.4.b 28) 2.3.4.c 29) 2.4.1 30) 2.4.1.1 31) 2.4.1.2 32)
2.4.1.3 33) 2.4.1.4 34) 2.5.1 35) 2.5.1.1 36) 2.6.1 37) 2.6.3 38) 2.6.4 39) 2.6.5 40) 2.6.6 41) 2.6.8 42) 2.6.9 43)
2.6.9.a 44) 2.6.9.b 45) 2.7.1 19 46) 2.7.7 47) 2.7.8 48) 2.7.9 49) 2.7.10 50) 2.7.10.a 51) 2.7.10.b 52) 2.7.10.c 53)
2.7.10.d 54) 2.8.2 55) 4.3 56) 4.3
Ponadto, Odwołujący wniósł o:
1) zasądzenie od Zamawiającego na rzecz Odwołującego zwrotu kosztów postępowania odwoławczego, w tym
zwrotu kosztów wynagrodzenia pełnomocnika, zgodnie z fakturą, która zostanie przedłożona na rozprawie,
2) dopuszczenie i przeprowadzenie dowodów na okoliczności wskazane w treści odwołania oraz dowodów,
które zostaną złożone przez Odwołującego na rozprawie.
9 maja 2023 roku do Prezesa Krajowej Izby Odwoławczej wpłynęła odpowiedź Zamawiającego na odwołanie, w
której Zamawiający poinformował o uwzględnieniu odwołania w części.
10 maja 2023 roku do Prezesa Krajowej Izby Odwoławczej wpłynęło pismo Odwołującego, w którym Odwołujący
oświadczył, że cofa odwołanie w pozostałym zakresie, tj. w zakresie nieuwzględnionym przez Zamawiającego w
piśmie z dnia 9 maja 2023 r. Odwołujący wniósł o umorzenie postępowania w całości oraz zwrot uiszczonego
wpisu od odwołania.
Do postępowania odwoławczego po stronie Zamawiającego nie zgłosił przystąpienia żaden wykonawca.
Mając na uwadze powyższe, Krajowa Izba Odwoławcza zważyła, co następuje:
Izba zważyła, że wobec uwzględnienia przez Zamawiającego części zarzutów
podniesionych w odwołaniu i braku zgłoszenia przystąpień po stronie Zamawiającego i wycofaniu pozostałych zarzutów
przez Odwołującego, postępowanie odwoławcze należało umorzyć na podstawie art. 522 ust. 3 Pzp. Przepis ten stanowi
w zdaniu pierwszym, że w przypadku uwzględnienia przez Zamawiającego części zarzutów postawionych w odwołaniu i
wycofaniu pozostałych zarzutów przez odwołującego, Izba może umorzyć postępowanie na posiedzeniu niejawnym bez
obecności stron oraz uczestników postępowania odwoławczego, którzy przystąpili do postępowania po stronie
wykonawcy, pod warunkiem że w postępowaniu odwoławczym po stronie zamawiającego nie przystąpił w terminie
żaden wykonawca. Zgodnie z art. 522 ust. 3 in fine Pzp, w takim przypadku zamawiający wykonuje, powtarza lub
unieważnia czynności w postępowaniu o udzielenie zamówienia, zgodnie z żądaniem zawartym w odwołaniu w zakresie
uwzględnionych zarzutów.
W tym stanie rzeczy Izba na podstawie art. 522 ust. 3 Pzp umorzyła postępowanie odwoławcze, orzekając w formie
postanowienia na podstawie art. 553 zd. 2 Pzp.
O kosztach postępowania orzeczono na podstawie art. 574 i 575 ustawy Pzp oraz w oparciu o przepisy § 9 ust. 1 pkt 2 lit
b) rozporządzenia w sprawie szczegółowych rodzajów kosztów postępowania odwoławczego, ich rozliczania oraz
wysokości i sposobu pobierania wpisu od odwołania (Dz.U. z 2020 r. poz. 2437 ze zm.), z którego wynika, że jeżeli
zamawiający uwzględnił w części zarzuty przedstawione w odwołaniu i pozostałe zarzuty zostały przez odwołującego
wycofane przed otwarciem rozprawy, a do postępowania odwoławczego nie przystąpił żaden wykonawca po stronie
zamawiającego, koszty o których mowa w § 5 pkt 2 rozporządzenia znosi się wzajemnie. Izba orzeka o dokonaniu
zwrotu Odwołującemu z rachunku Urzędu kwoty uiszczonej tytułem wpisu od odwołania.
Mając powyższe na uwadze, Izba orzekła, jak w sentencji.
Przewodnicząca ...…………………..