Decizie CNSC 1303/2022

În conformitate cu prevederile art. 12 alin. (1) și ale art. 27 alin. (1) din Legea nr. 101/2016 privind remediile și căile de atac în materie de atribuire a contractelor de achiziție publică, a contractelor sectoriale și a contractelor de concesiune de lucrări și concesiune de servicii, precum și pentru organizarea și funcționarea Consiliului Național de Soluționare a Contestațiilor, Consiliul adoptă următoarea: DECIZIE Nr. 1303/C6/1208 Data: 27.06.2022 Prin contestația nr. 685/20.05.2022, înregistrată la C.N.S.C. sub nr. 26041/20.05.2022, formulată de către SOBIS SOLUTIONS SRL, în calitate de lider al ASOCIERII SOBIS SOLUTIONS SRL/INDECO SOFT SRL, cu sediul în comuna Arpașu de Jos, satul Arpașu de Sus nr. 505, județul Sibiu, înmatriculată la Oficiul Registrului Comerțului sub nr. J32/348/1999, având CUI RO 12018818, reprezentată legal prin Mueller Hans Martin, în calitate de administrator, și convențional prin SOCIETATEA CIVILĂ DE AVOCAȚI „PREDOI ȘI ASOCIAȚII”, cu sediul în municipiul București, str. Cluceru Udricani nr. 1-3, bloc 106A, parter, sectorul 3, adresă indicată și pentru comunicarea actelor de procedură, împotriva comunicării rezultatului procedurii nr. 36734/13.05.2022, a raportului procedurii nr. 13/13.05.2022, precum și a oricăror „acte subsecvente”, documente emise de către autoritatea contractantă MUNICIPIUL TÂRGU-MUREȘ, cu sediul în municipiul Târgu Mureș, str. Piața Victoriei nr. 3, județul Mureș, în cadrul procedurii de licitație deschisă, derulată online, în vederea atribuirii contractului de achiziție publică având ca obiect „Achiziție active fixe necorporale și servicii aferente instalării, configurării și personalizării în vederea realizării sistemului info portal și de gestiune electronică a documentelor aferente proiectului «Planificare strategică și măsuri de simplificare pentru cetățeni la nivelul Municipiului Târgu Mureș» cod SIPOCA/MySMIS nr. 824/136243”, cod CPV 72212000-4 Servicii de programare de software de aplicație (Rev.2), anunț de participare nr. CN1037341/05.12.2021, s- a solicitat Consiliului următoarele: „1. Anularea în parte a rezultatului procedurii nr. 13/13.05.2022, cu privire la declararea ca inacceptabilă a ofertei subscrisei, respectiv declararea drept câștigătoare a ofertei depuse de BOOSTIT HUB SRL; 2. Anularea adresei de comunicare nr. 36734/13.05.2022, precum și a tuturor actelor subsecvente emiterii Raportului procedurii nr. 13/13.05.2022; 3. Obligarea autorității contractante să reevalueze oferta subscrisei; 4. Obligarea autorității contractante la plata cheltuielilor generate de soluționarea acestei contestații”. Pagina 1 din 2

CONSILIUL DECIDE: Respinge, ca nefondată, contestația formulată de către SOBIS SOLUTIONS SRL, în calitate de lider al ASOCIERII SOBIS SOLUTIONS SRL/INDECO SOFT SRL, cu sediul în comuna Arpașu de Jos, satul Arpașu de Sus nr. 505, județul Sibiu, în contradictoriu cu autoritatea contractantă MUNICIPIUL TÂRGU-MUREȘ, cu sediul în municipiul Târgu Mureș, str. Piața Victoriei nr. 3, județul Mureș. Pe cale de consecință, respinge solicitarea contestatoarei de ,,obligarea autorității contractante la plata cheltuielilor generate de soluționarea acestei contestații”. Obligatorie. Împotriva prezentei decizii, se poate formula plângere, în termen de 10 zile de la comunicare, conform dispozițiilor art. 29 din Legea nr. 101/2016. Pagina 2 din 2

În conformitate cu prevederile art. 12 alin. (1) și ale art. 27 alin. (1) din Legea nr. 101/2016 privind remediile și căile de atac în materie de atribuire a contractelor de achiziție publică, a contractelor sectoriale și a contractelor de concesiune de lucrări și concesiune de servicii, precum și pentru organizarea și funcționarea Consiliului Național de Soluționare a Contestațiilor, Consiliul adoptă următoarea: DECIZIE Nr. …/…/… Data: … Prin contestația nr. 685/20.05.2022, înregistrată la C.N.S.C. sub nr. …/…, formulată de către ..., în calitate de lider al ASOCIERII .../..., cu sediul în comuna …, satul .. nr. …, județul …, înmatriculată la Oficiul Registrului Comerțului sub nr. …/…/…, având CUI RO …, reprezentată legal prin …, în calitate de administrator, și convențional prin SOCIETATEA CIVILĂ DE AVOCAȚI „…”, cu sediul în municipiul …, str. … nr. …, bloc …, parter, sectorul …, adresă indicată și pentru comunicarea actelor de procedură, împotriva comunicării rezultatului procedurii nr. 36734/13.05.2022, a raportului procedurii nr. 13/13.05.2022, precum și a oricăror „acte subsecvente”, documente emise de către autoritatea contractantă MUNICIPIUL …, cu sediul în municipiul …, str. Piața … nr. …, județul …, în cadrul procedurii de licitație deschisă, derulată online, în vederea atribuirii contractului de achiziție publică având ca obiect „Achiziție active fixe necorporale și servicii aferente instalării, configurării și personalizării în vederea realizării sistemului info portal și de gestiune electronică a documentelor aferente proiectului «Planificare strategică și măsuri de simplificare pentru cetățeni la nivelul Municipiului …» cod SIPOCA/MySMIS nr. …/…”, cod CPV 72212000-4 Servicii de programare de software de aplicație (Rev.2), anunț de participare nr. CN…/…, s-a solicitat Consiliului următoarele: „1. Anularea în parte a rezultatului procedurii nr. 13/13.05.2022, cu privire la declararea ca inacceptabilă a ofertei subscrisei, respectiv declararea drept câștigătoare a ofertei depuse de ...; 2. Anularea adresei de comunicare nr. 36734/13.05.2022, precum și a tuturor actelor subsecvente emiterii Raportului procedurii nr. 13/13.05.2022; 3. Obligarea autorității contractante să reevalueze oferta subscrisei; 4. Obligarea autorității contractante la plata cheltuielilor generate de soluționarea acestei contestații”. În luarea deciziei asupra cauzei de față, Consiliul Național de Soluționare a Contestațiilor reține următoarele: Pagina 1 din 40

Prin contestația nr. 685/20.05.2022, înregistrată la C.N.S.C. sub nr. …/…, ... în calitate de lider al ASOCIERII .../... critică rezultatul procedurii de atribuire a contractului de achiziție publică, respectiv comunicarea rezultatului procedurii nr. 36734/13.05.2022, raportul procedurii nr. 13/13.05.2022, precum și orice „acte subsecvente” prin care oferta sa fost respinsă ca neconformă, emise de către autoritatea contractantă MUNICIPIUL ..., în cadrul procedurii de licitație deschisă, derulată online, în vederea atribuirii contractului de achiziție publică având ca obiect „Achiziție active fixe necorporale și servicii aferente instalării, configurării și personalizării în vederea realizării sistemului info portal și de gestiune electronică a documentelor aferente proiectului «Planificare strategică și măsuri de simplificare pentru cetățeni la nivelul Municipiului …» cod SIPOCA/MySMIS nr. …/…”, solicitând cele redate în partea introductivă. Cu titlu preliminar, contestatoarea prezintă, pe scurt, datele de identificare a procedurii de atribuire a contractului de achiziție publică la care a participat în calitate de lider al ASOCIERII .../.... Menționează faptul că, prin adresa nr. 36734/13.05.2022, autoritatea contractantă i-a comunicat decizia de respingere a ofertei sale, ca inacceptabilă, în temeiul dispozițiilor art. 134 alin. (5) din H.G. nr. 395/2016, și, pe cale de consecință, ca neconformă, în temeiul prevederilor art. 215 alin. (5) din Legea nr. 98/2016 coroborat cu prevederile art. 137 alin. (3) lit. a) din H.G. nr. 395/2016. Arată că decizia de mai sus a intervenit ca urmare a verificării răspunsului pe care l-a oferit la solicitarea de clarificări a autorității contractante, în faza analizei propunerii tehnice, comisia de evaluare considerând răspunsurile sale ca fiind neconcludente în ceea ce privește cerințele de la punctele 1, 2, 3, 7, 8, 10, 14, 15, 16, 17, 19, 20, 21, 23 din adresa de clarificări nr. 23352/25.03.2022. De asemenea, precizează că, potrivit raportului procedurii nr. 13/13.05.2022, oferta depusă de ... a fost declarată câștigătoare, aceasta totalizând 98 de puncte și având o valoare a propunerii financiare de 1.223.885 lei, fără TVA. Față de cele de mai sus, contestatoarea susține că respingerea ofertei sale este nelegală deoarece: 1. Cu privire la conformitatea cu prevederile GDPR, invocă prevederile de la pag. 8 din caietul de sarcini, față de care afirmă că prin răspunsul la solicitarea de clarificări nr. 23352/25.03.2022, a arătat că în fișa produsului - Product datasheet: ePortal Code:SC)B-EPORT-V402- UTE și Product datasheet: EPRIM Code:SOB-EPRIM-V420-DMS, la pag 2, se precizează că produsul satisface cerințele Regulamentului UE 679/2016 (GDPR).

Totodată, cu privire la măsurile implementate în vederea protejării accesului la datele personale, menționează că „așa cum s-a precizat și în cadrul sesiunii demonstrative”, printre măsurile implementate prin oferta Pagina 2 din 40

sa se numără și aceea că utilizatorii au acces strict la documentele cu care intră fizic în contact, deci, din punctul de vedere al securității, datele cu caracter personal afișate sunt exact cele la care funcționarul are acces ca urmare a consultării documentelor avute în lucru. Cu privire la afirmațiile autorității contractante potrivit cărora „(i) în aplicația EPRIM datele personale sunt afișate în clar, fără anonimizare, iar (ii) soluția nu capturează explicit motivul accesului la datele personale”, autoarea contestației arată că datele personale ale cetățenilor nu sunt accesibile tuturor cetățenilor, cum în mod eronat a reținut autoritatea contractantă. În acest sens precizează că datele personale pot fi vizibile funcționarilor de la registratură doar atunci când însoțesc o cerere/solicitare pe care respectivii funcționari pot să o deschidă și să o redirecționeze, niciun alt funcționar neavând acces la o solicitarea care nu se afla în lucru la el și nici nu va putea să o vadă în vreo listă, conform matricei de conformitate, pag. 123, fig. 46, pag.184, fig. 104. În altă ordine de idei, menționează că orice acces la o informație afișată pe ecran este „auditată”, astfel că se poate afla cine, de pe ce calculator, când și din ce motiv a accesat date cu caracter personal, care sunt aceste datele accesate, indiferent dacă acestea sunt afișate în liste/rapoarte, exportate, sau afișate ca înregistrări individuale. 2. Cu referire la cerințele privind interfața grafică, autoarea contestației invocă prevederile de la pag. 20 din caietul de sarcini, si susține că prin răspunsul la solicitarea de clarificări nr. 23352/ 25.03.2022, a arătat că cele două interfețe distincte la care face referire autoritatea contractantă - ePortal, destinată expunerii funcționalităților către cetățeni, și EPRIM, destinată expunerii funcționalităților către funcționari - nu sunt altceva decât implementarea a două teme responsive pentru soluția ofertată. Ambele teme sunt disponibile atât pentru zona ePortal, cât și pentru EPRIM, iar fiecare produs are configurată una dintre aceste teme ca fiind activă, putând fi schimbată de către funcționari, conform sesiunii demonstrative, minutul 2:50:51. În aceiași sesiune, la min 2.09:00, a demonstrat modul de funcționare responsive atât a interfeței ePortal, cât și a interfeței EPRIM.  3. Cu referire la cerințele privind conversia automată a fișierelor în format PDF, autoarea contestației invocă prevederile de la pag. 21 din caietul de sarcini, afirmând că a răspuns la solicitarea de clarificări nr. 23352/25.03.2022, prin indicarea faptului că "Infrastructura digitală va fi provizionată pe scenarii de încărcare astfel încât nivelul de performanță să fie unul rezonabil". Prin urmare, în opinia contestatoarei, nu există nicio altă constrângere cu privire la timpii de răspuns, iar noțiunea de "rezonabil" poate fi interpretată oricum, atâta timp cat nu este clar definită. De asemenea, arată că potrivit aceleiași cerințe, conversia fișierelor în format pdf. trebuia realizată în mod automat, aspect pe care susține Pagina 3 din 40

că l-a demonstrat, conform sesiunii demonstrative, în sensul că aceasta se realizează automat, fiind folosit un task în background care pornește „AUTOMAT”, după ce solicitarea este trimisă, și la finalizarea căruia solicitarea primește stadiul „DEPUSĂ”, rezultatul constituindu-se într-o nouă versiune a documentului depus. 7. Cu privire la îndeplinirea cerințelor privind funcționalitatea de validări format, conținut și validări de securitate a conținutului formularelor inteligente transmise on-line, prin raportare la prevederile de la pag. 21 din caietul de sarcini, menționează că prin răspunsul la solicitarea de clarificări nr. 23352/25.03.2022, a arătat că sistemul informatic propus implementează validarea în două etape a câmpurilor, și anume: „o validare front-office, în care sunt implementați algoritmi de bază pentru câmpuri (ex. dată, câmpuri text, numere, etc); o validare back-office, în care valorile introduse sunt comparate cu nomenclatoarele existente, cu restricțiile cu privire la date back-end, validare serii, validare prin interogare servicii puse la dispoziție de terți (ex. RENNS, ONRC), validare cu datele stocate deja în sistem”. Contestatoarea precizează că la sesiunea demonstrativă a dovedit atât validarea front-end, cât și faptul că datele cu conținut invalid practic fac „IMPOSIBILĂ” depunerea solicitării ca urmare a unei validări back- end. Cu privire la respectivele validări, arată că aspectele ce țin de acestea vor fi stabilite împreuna cu beneficiarul, în sensul că are capacitatea de a „pune astfel de validări pe câmpuri și ele sunt efective”. În opinia sa, „aspectele în discuție nu ar fi trebuit sa facă obiectul clarificărilor, întrucât nu au existat în caietul de sarcini cerințe exprese cu privire la ce câmpuri și ce formulare să fie implementate”, aceste facilități fiind prezentate cu titlu demonstrativ pentru a se arăta că se pot implementa validările cerute in caietul de sarcini pe unele câmpuri. 8. Referitor la îndeplinirea cerințelor privind semnarea electronică a declarațiilor/cererilor depuse de către ,,cetățean’’, autoarea contestației afirmă că a respectat prevederile de la pag. 21 din caietul de sarcini, deoarece, prin răspunsul la solicitarea de clarificări nr. 23352/ 25.03.2022, a arătat că, întrucât caietul de sarcini nu cuprinde precizări cu privire la tipul de semnături cu care să semneze cetățeanul, la sesiunea demonstrativă a ales să prezinte modul cum a implementat semnarea cu semnătură generată de portal, „care este una avansată”. Dacă cetățeanul deține „semnătură calificată (certificată pe stick usb) emisă de un furnizor acreditat”, atunci va semna offline cererea, cu instrumentele emițătorului de certificat, și o va încărca apoi în sistem. Dacă solicitantul dispune de semnătură electronică în cloud, de tip paperless, în funcție de compania aleasă, are opțiunea de semnare remote direct din interfața ePortal sau din interfețele disponibile la provideri susține aceasta. De asemenea, precizează că „pe parcursul sesiunii demo nu a fost arătată semnarea de cetățean cu certificat remote, deoarece aceasta ar Pagina 4 din 40

fi implicat, prin ipoteză, existența unui cetățean înrolat în sistem paperless la un furnizor acreditat”. Față de acest aspect, menționează că autoritatea contractantă a precizat că "Pentru a evita orice dubiu, emiterea și revocarea certificatelor calificate nu se face în sistem ci în aplicațiile furnizorilor autorizați", motiv pentru care „la momentul implementării, când se vor cunoaște furnizorii autorizați de către autoritatea contractantă, va fi activată în meniu interfața de semnare paperless aferentă care integrează serviciul furnizorului ales de beneficiar”. 10. Referitor la îndeplinirea cerințelor privind aplicația pentru dispozitivele mobile, tot în baza prevederilor de la pag. 21 din caietul de sarcini, susține că prin răspunsul la aceiași solicitare de clarificări, a arătat că în sesiunea demonstrativă aplicația era instalată pe dispozitivul mobil prezentat, cu iconiță de pe smartphone instalată, „nefiind vorba despre o redirecționare către website (web-application)”, ceea ce s-a prezentat „PE ECRAN” fiind de fapt o aplicație mobilă rulată în cadrul unui emulator pentru a putea proiecta pe ecran interfața back-office a aplicației în fața comisiei. Astfel, la momentul 02:10:00 din cadrul sesiunii demonstrative s-au arătat simultan cele 2 interfețe, desktop și mobile, tocmai pentru a se vedea operarea datelor într-o aplicație și reflectarea lor în cealaltă. „Oricum am semnalat Autorității Contractante că, dacă se vor urmări documentele DataSheet aferente celor doua aplicații, ePortal și EPRIM, se poate vedea că ele funcționează pe Android și iOS”, precizează contestatoarea. 14. Cu privire la îndeplinirea cerințelor privind implementarea unui mecanism automat și auditabil de înregistrare a lucrărilor, ce va fi integrat cu mesageria electronică, registrele instituției și cu platforma de semnare electronică, raportându-se tot la prevederile de la pag. 21 din caietul de sarcini, contestatoarea menționează că prin răspunsul la solicitarea de clarificări nr. 23352/25.03.2022, a precizat că ,,în scenariul „demo” partea de sigilare electronică nu era prevăzută, motiv pentru care aceasta nu a fost arătată, iar, pe parcursul prezentării demonstrative a adresat întrebări comisiei de evaluare în vederea clarificării eventualelor aspecte care nu erau trecute în scenariu’’. Referitor la motivul invocat de către autoritatea contractantă potrivit căruia „am constatat că sistemul prezentat de ofertant nu a demonstrat integrarea cu platforma de semnare și sigilare electronică", contestatoarea menționează că în oferta tehnică - matricea de conformitate, pag. 149, 213, 232,278, 286, 288 se indică faptul că sistemul dispune de integrare cu platforma de sigilare electronică. Mai arată că detaliile despre platforma de sigilare CertSign sunt prezentate la pag. 232 din oferta tehnică, iar procesul de semnare a documentului este întotdeauna autorizat de către utilizator, prin intermediul unui cod SMS sau a unui cod TOTP, generat de o aplicație de tip „Authenticator”. Pagina 5 din 40

Referitor la motivul autorității contractante potrivit căruia „ofertantul nu a dovedit nici: Existența la nivelul sistemului a sigiliului electronic”, contestatoarea susține că sigiliul electronic există la nivelul furnizorului calificat de sigiliu, sistemul ofertat asigurând integrarea cu acest sigiliu prin apelul securizat al serviciului de sigilare pus la dispoziție de furnizor. De asemenea, față de argumentul că „ofertantul nu a demonstrat: Integrarea între mecanismul de alocarea a numerelor de înregistrare și sigiliul electronic", arată că la pag. 22 din caietul de sarcini cerința de integrare era formulată diferit: „Sistemul va dispune de un mecanism automat și audiabil de înregistrare (acordarea numerelor de înregistrare) a lucrărilor ce va fi integrat cu mesageria electronică, registrele instituției și cu platforma de semnare electronică”, motiv pentru care, în opinia sa, „mecanismul trebuie integrat cu platforma de semnare, și nu cu sigiliul electronic”. 15. Referitor la îndeplinirea cerințelor privind înregistrarea în registrul unic și detalii care însoțesc obligatoriu un număr de înregistrare, contestatoarea susține că a respectat cerințele de la pag. 21 din caietul de sarcini, astfel cum rezultă din matricea de conformitate din oferta tehnică. În acest sens, precizează că pentru registrul unic al instituției, destinat lucrărilor, la pag. 136, figura 60, din oferta tehnică se observă, pentru fiecare lucrare, conform legislației, detaliile relevante pentru evidența documentelor, cum ar fi numărul, data, fără oră, conținutul pe scurt „etc.”. De asemenea, arată că prin răspunsul la solicitarea de clarificări a precizat că elementele ce privesc „ora exactă când a fost alocat”, „grupa de documente din care face parte” și „tipul documentului căruia i-a fost alocat” se regăsesc pe fiecare înregistrare în parte, dar nu și în lista stabilită prin lege. Referitor la elementul „Registre distincte pentru grupe distincte pentru fiecare tip de document asociate registrelor", contestatoarea susține că nu a existat o asemenea cerință în caietul de sarcini. Cu privire la elementul "Registre distincte pentru documente", susține că, la pag. 142 din oferta tehnică se observă secțiunea conținând documentele aferente lucrării și anume: numărul documentului (prima coloana); grupa de documente din care face parte (coloana Numele documentului); numărul lucrării din care face parte; emitentul (autorul); data și ora când a fost alocat; versiunea și tipul documentului căruia i-a fost alocat (coloana Tip). În ceea ce privește numărul de registru al documentelor, autoarea contestației afirmă că acesta este unic, după cum se poate observa în figura 63 de la pag. 139 din oferta tehnică - matrice de conformitate (câmpul identificatorul unic al documentului). De asemenea, referința documentului în sistem se compune dintr-o secvență ce conține numărul lucrării, anul și numărul documentului în lucrare. Pagina 6 din 40

16. Referitor la îndeplinirea cerințelor privind gestiunea separată a activităților atât după lucrări, cât și după documente, invocă cerința de la pag. 22 din caietul de sarcini prin care se solicită „Un număr de înregistrare reprezintă contextul particular în care acel document a fost manipulat în sistem (...) Documentele înregistrate în sistem trebuie să primească un număr unic de înregistrare. Este interzisă acordarea de mai multe numere unui singur document, acordarea aceluiași număr de înregistrare pentru mai multe documente sau acordarea de numere din trecut”. Așadar, conform cerinței „numărul de înregistrare poate fi orice număr, dar care să fie unic capabil să identifice un document în sistem”, conform figurii 63 de la pag. 139 din caietul de sarcini. 17. Cu privire la îndeplinirea cerințelor privind evidența numerelor de înregistrare a documentelor în cadrul unei lucrări, contestatoarea se referă la cerințele de la pag. 22 din caietul de sarcini, în opinia sa fiind eronată presupunerea autorității contractante ,,cum că toate documentele salvate în lucrare ar avea același număr de înregistrare, identic cu cel al lucrării’’. Față de cele de mai sus, contestatoarea arată că, la pag. 41 din oferta tehnică - Matrice de conformitate, a precizat că „Sistemul permite existența concomitentă a mai multor documente în cadrul aceleiași lucrări, fiecare document având număr de înregistrare unic, asigurând în permanență alocarea incrementală a numerelor de înregistrare pe fiecare document și registru", conform figurii de la pag. 142. Conform figurii 63, de la pag. 139, din oferta tehnică, se observă numărul de înregistrare al documentului în câmpul „Identificatorul unic al documentului”. Numărul este hexazecimal, de 32 de cifre, și „identifică unic documentul în registrul de documente”. 19. Referitor la îndeplinirea cerințelor privind diferențierea documentelor ciornă de cele finale, a celor principale de anexele lor și a evidentei separate a acestora, prin raportare la cerințele de la pag. 22 din caietul de sarcini, menționează că în documentul Product datasheet: EPRIM Code: SOB-EPRIM-V420-DMS se precizează, la funcționalități, secțiunea "ÎNREGISTRAREA SOLICITĂRILOR" faptul că "Documente au clase diferite: draft sau finale, principale sau anexe". De asemenea, la pag. 143 din oferta tehnică - Matrice de este menționat că: "Sistemul implementat va face diferența între documentele ciornă și documentele finale, între documentele principale și anexele lor, ținând o evidență separată a tuturor acestor tipuri de documente", în timp ce la pag. 142 din oferta tehnică se observă, pe tab-ul „Fișiere”, faptul că documentele pot fi selectate, existând butonul „dropdown”. Prin urmare, există opțiunea marcării documentelor selectate în documente principale, precum și posibilitatea marcării documentelor în ciorne (draft) sau finale, în lista de documente asociate unei lucrări, în coloana 2, aparând, în acest sens, icon-uri distincte pentru ciorne, finale, principal, anexe. Pagina 7 din 40

Contestatoarea menționează că pe tab-ul de fișiere, documentele pot fi gestionate cu ajutorul sortării după aceste atribute (keywords). Odată marcate, documentele pot fi gestionate în registrul de documente, acesta permițând filtrarea lor după coloanele principale/anexa sau ciorne/finale și chiar după emitent/autor. Aceste documente se pot identifica în mod unic în sistem prin două metode: a) numărul unic de înregistrare al documentului, sens în care exemplifică cu figura 63 de la pagina 139 din oferta tehnică; b) „referința documentului în sistem compusă dintr-o secvență ce conține numărul lucrării, registrul ei, anul și numărul documentului în lucrare”. 20. Cu referire la îndeplinirea cerințelor privind formatul predefinit al numerelor de înregistrare, având în vedere cerințele de la pag. 22 din caietul de sarcini, contestatoarea menționează că la pag. 144 din oferta tehnică a precizat că "Numerele de înregistrare urmează un format predefinit, care să ajute utilizatorul să identifice cu ușurință emitentul documentului, lucrarea din care face parte, registrul din care a fost alocat, tipul documentului". Numărul de înregistrare înseamnă „o valoare numerică care - în contextul aplicației - este un număr natural nenul scris în orice bază de numerație”, afirmă contestatoarea, cu mențiunea că sistemul nu validează numărul de înregistrare dacă nu respectă aceste criterii întrucât acesta nu poate conține caractere străine bazei de numerație. Prezentând beneficiile referinței unice a documentului, autoarea contestației arată că aceasta este compusă dintr-o secvență ce conține numărul lucrării și registrul ei, anul și numărul documentului în lucrare și menționează că acestea sunt suficiente pentru identificarea unică a documentului în sistem. În acest sens, menționează că sistemul poate „concatena oricâte keywords” cum ar fi emitentul și numărul unic. Mai afirmă că referințele la documente sunt interne sistemului, acestea ajutând la identificarea cu ușurință a documentelor, iar implementarea sistemului este definită în secțiunea de „Administrare – Regiștrii”, sens în care face trimitere la figura nr. 76 de la pag. 160 din oferta tehnică. 21. Referitor la îndeplinirea cerințelor privind funcționalitatea de semnare electronică calificată a tuturor documentelor justificative depuse de către utilizator, prin raportare la cerințele de la pag. 25 din caietul de sarcini, susține că în caietul de sarcini nu există precizări referitoare la tipul de semnături destinate a fi utilizate de către cetățean, fapt pentru care, în sesiunea demonstrativă a prezentat modul de semnare implementat, cu mențiunea că, în ipoteza în care deține semnătură calificată, emisă de un furnizor acreditat, cetățeanul va semna offline cererea și o va încărca în sistem. Dacă solicitantul dispune de semnătură electronică în cloud, de tip paperless, are opțiunea de semnare remote direct din interfața ePortal, sens în care face trimitere la „Product datasheet: ePortal Code:SOB-EPORT-V402-LITE”, sau din interfețele disponibile la provideri. Pagina 8 din 40

Autoarea contestației menționează și că, pe parcursul sesiunii „demo” nu a fost prezentată semnarea de către cetățean întrucât aceasta ar fi presupus existența unuia înrolat deja în sistemul paperless la un furnizor acreditat, ori prin răspunsul la solicitările de clarificare, autoritatea contractantă i-a precizat că: „Pentru a evita orice dubiu, emiterea și revocarea certificatelor calificate nu se face în sistem ci în aplicațiile furnizorilor autorizați”. Prin urmare, interfața de semnare paperless, care integrează serviciul furnizorului ales de beneficiar, va fi activată la momentul implementării, sens în care contestatoarea precizează că potrivit caietului de sarcini se solicită „Semnarea electronică calificată a tuturor documentelor justificative depuse de către utilizator", ceea ce în opinia contestatoarei înseamnă că aceasta aparține interfeței funcționarului, nu interfeței ePortal, dedicată cetățeanului. Or, afirmă contestatoarea, soluția pe care a propus-o permite semnarea electronică, „CU ORICE TIP DE CERTIFICAT”, a oricăror tipuri de documente, „cu atât mai mult a documentelor justificative depuse de cetățean”, sens în care face trimitere la minutele de la 2:15:28 la 2:17:13 din prezentarea demo, precum și la pag. 260 – 279 din oferta tehnică. 23. Referitor la îndeplinirea cerințelor privind accesul protejat la date și integrarea managementului identităților în soluția propusă, conform cerințelor de la pag. 35 din caietul de sarcini, contestatoarea arată că a răspuns la solicitarea de clarificări, următoarele: a) cu referire la platforma de comunicare video - la minutul 35:22 nu s-a regăsit prezentarea funcționalității de document colaborativ, fiind vorba de accesul la un link trimis pe e-mail către solicitant pentru a putea fi identificat. Link-ul respectiv are o anumită „perioadă de viață în sistem”, acesta fiind accesat pe respectiva durată de timp. Or, întrucât solicitantul care trebuia să se identifice nu era încă înregistrat în sistem, respectivul link nu putea fi integrat cu platforma de management al identităților, deoarece solicitantul nu era încă identificat în această platformă. Prin urmare, în înregistrare nu a apărut, pe ecran, niciun link către platforma de comunicare video, motiv pentru care, contestatoarea ,,nu înțelege ce link a putut accesa autoritatea contractantă ulterior prezentării’’; b) privitor la platforma „colaborativă”, arată că la minutul 2:29:54 nu a regăsit link-ul la documentul colaborativ deoarece prezentarea demo s-a făcut pe o infrastructură de test, iar ulterior datei de 17.02.2022 au fost efectuate numeroase lucrări de mentenanță, care au modificat securitatea și accesul configurat pentru prezentarea sesiunii demonstrative, motiv pentru care varianta demo nu mai îndeplinește cerințele din caietul de sarcini. Mai arată că a încercat să acceseze link- ul la care autoritatea contractanta a făcut referire, dar nu a reușit sa îl acceseze „pentru a reproduce situația semnalată”. Pagina 9 din 40

Față de cele de mai sus, contestatoarea susține că soluția sa informatică satisface cerințele caietului de sarcini, iar decizia MUNICIPIULUI ... nu are niciun temei legal întrucât, pe parcursul sesiunii demonstrative, a răspuns la toate interpelările comisiei, iar prin răspunsul formulat la solicitările de clarificări s-au eliminat îndoielile cu privire la viabilitatea soluției informatice propuse. În dovedire, au fost depuse înscrisuri. De asemenea, contestatoarea solicită și proba expertizei judiciare de specialitate IT, în scopul verificării conformității sistemului informatic propus, cu cerințele caietului de sarcini. În drept au fost invocate dispozițiile art. 8 și următoarele din Legea nr. 101/2016. Prin adresa nr. …/…/…/…, în temeiul dispozițiilor art. 611 alin. (1) lit. b) din Legea nr. 101/2016, Consiliul a solicitat contestatoarei să transmită la dosarul cauzei dovada constituirii cauțiunii în cuantum de 25.766,00 lei, iar în temeiul dispozițiilor art. 16 alin. (1) din Legea nr. 101/2016, să facă dovada comunicării contestației și către autoritatea contractantă. Prin adresa înregistrată la C.N.S.C. sub nr. …/…, ..., în calitate de lider al Asocierii .../..., a transmis la dosarul cauzei dovada comunicării contestației către autoritatea contractantă MUNICIPIUL .... Prin adresa înregistrată la C.N.S.C. sub nr. …/…, contestatoarea a transmis la dosarul cauzei dovada achitării sumei de 5.887,76 lei, plată efectuată pentru factura nr. PSA2022-124 din data de 18.05.2022, prin ordinul de plată nr. … din data de 19.05.2022, reprezentantului convențional al acesteia, cu titlu de onorariu de avocat. Prin adresa înregistrată la C.N.S.C. sub nr. …/…, contestatoarea a transmis la dosarul cauzei dovada comunicării către autoritatea contractantă a înscrisurilor depuse în dovedirea capătului de cerere privind obligarea acesteia la plata cheltuielilor ocazionate de prezenta contestație. Prin adresa înregistrată la C.N.S.C. sub nr. …/…., contestatoarea a transmis la dosarul cauzei dovada confirmării primirii contestației și înscrisurilor doveditoare de către autoritatea contractantă Prin adresa nr. 40876/30.05.2022, înregistrată la C.N.S.C. sub nr. …/…., în temeiul dispozițiilor art. 18 alin. (1) din Legea nr. 101/2016, MUNICIPIUL ... a transmis punct de vedere cu privire la contestația ..., în calitate de lider al ASOCIERII .../..., solicitând respingerea acesteia ca „neîntemeiată și nefondată”. Față de cele de mai sus, autoritatea contractantă prezintă mai întâi un istoric al procedurii de atribuire, sens în care indică faptul că, pe parcursul derulării acesteia, ofertanții interesați au depus, prin SEAP, 3 solicitări de clarificări, urmând ca ulterior să fie depuse două oferte, respectiv oferta ... și cea a contestatoarei. În urma verificării informațiilor DUAE, ambele oferte au fost declarate admisibile, ulterior Pagina 10 din 40

fiind desfășurate sesiunile demonstrative, fapt consemnat în procesele verbale încheiate cu această ocazie. Arată că, în urma analizării propunerilor tehnice și sesiunilor demonstrative, s-au solicitat, în baza principiului tratamentului egal, clarificări ambilor ofertanți, constatându-se, ulterior, faptul că răspunsurile ... sunt concludente și, pe cale de consecință, oferta acestuia a fost declarată conformă, respectivul ofertant fiind declarat câștigător, în timp ce oferta contestatoarei a fost respinsă. De asemenea, autoritatea contractantă prezintă motivele care au stat la baza respingerii ofertei contestatoarei, pe motiv că, în urma verificării răspunsului la solicitarea de clarificări, comisia de evaluare a constatat faptul că oferta în cauză este inacceptabilă, în baza prevederilor art. 134 alin. (5) din H.G. nr. 395/2016 și neconformă, prin raportare la prevederile art. 215 alin. (5) din Legea nr. 98/2016 coroborat cu art. 137 alin. (3) lit. a) din H.G. nr. 395/2016 întrucât „nu satisface

în

mod

corespunzător

cerințele

caietului

de sarcini/documentația de atribuire”. Pe cale de consecință, oferta contestatoarei fiind respinsă în temeiul art. 137 alin (1) din H.G. nr. 395/2016. Pe fondul cauzei, autoritatea contractantă prezintă argumente față de criticile contestatoarei, începând prin a preciza că la baza deciziei de respingere a ofertei contestatoarei a stat rezoluția comisiei de evaluare, potrivit căreia răspunsurile contestatoarei, la cerințele de la pct. 1, 2, 3, 7, 8, 10, 14, 15, 16, 17, 19, 20, 21 și 23 din adresa de clarificări nr. 23352/25.03.2022, sunt neconcludente. În acest sens, autoritatea contractantă menționează că în cadrul propunerii tehnice contestatoarea a depus 3 fișiere, conform celor consemnate la pag. 6 din raportul procedurii nr. 13/13.05.2022, la rubrica „principalele aspecte ale evaluării propunerilor tehnice”, „în timp ce aspectele detaliate se regăsesc în anexe la prezentul proces verbal respectiv: Grilele de evaluare tehnică - Anexe la PV nr. 3 din 20.04.2022”. De asemenea, organizatoarea procedurii precizează că, în concordanță cu prevederile art. 216 alin. (2) lit. b) și alin (3) din Legea nr. 98/2016, motivele care au stat la baza selectării ofertei câștigătoare, respectiv respingerii ofertei neconforme a contestatoarei, sunt cuprinse într-un număr de 247 pagini, în procesul verbal nr. 3/30389/20.04.2022. În ceea ce privește oferta contestatoarei, autoritatea contractantă menționează că, prin adresa SB/E/3272.322/30.03.2022, contestatoarea a răspuns, în termen, la solicitarea de clarificări nr. 23352/25.03.2022, iar, în urma evaluării răspunsurilor, comisia de evaluare le-a apreciat ca fiind neconcludente pentru pct. 1,2,3,7,8,10,14,15,16,17,19,20,21 și 23. Față de cele de mai sus, autoritatea contractantă prezintă argumentele sale pentru fiecare critică, astfel: Pagina 11 din 40

1. În combaterea criticii referitoare la îndeplinirea cerințelor privind conformitatea cu prevederile GDPR, după ce redă cerința minimă obligatorie de la pag. 8 din caietul de sarcini, precum și răspunsul contestatoarei la întrebarea aferentă din solicitarea de clarificări, precizează că sesiunea demonstrativă a arătat „fără echivoc” că declarația ofertantului conform căreia „este scris în fișa produsului că acesta satisface cerințele Regulamentului UE 679/2016 (GDPR)" nu este sustenabilă, deoarece informații precum CNP sunt afișate în clar peste tot în sistem. În ciuda clarificărilor comisiei de evaluare, contestatoarea oferă propria sa interpretare prevederilor caietului de sarcini, fapt ce-i „întărește convingerea” organizatoarei procedurii că aceasta „fie nu înțelege cerința funcțională fie, în mod deliberat, pretinde că înțelesul prevederilor caietului de sarcini este altul decât cel dat de autoritatea contractantă”. Autoritatea contractantă menționează că anonimizarea nu privește drepturile de acces ale funcționarilor la datele personale ale cetățeanului, după cum susține contestatoare, „ci imposibilitatea oricărei persoane care are acces vizual la calculatorul ce afișează datele de a putea observa în clar date asociate precum «CNP-ul + Nume Prenume»". Cerința privind „capturarea motivului accesului la datele personale” reprezintă nevoia de a avea acces la datele personale ale cetățenilor și este o operațiune care apare în activitatea zilnică a funcționarilor într-un număr foarte mare de scenarii, fapt pentru care motivul trebuie să fie întotdeauna „legitim și însoțit de detalii temeinice, clar exprimate, personalizate și contextuale”. Or, afirmă autoritatea contractantă, contrar celor susținute de contestatoare, prin soluția furnizată de aceasta, accesul la date nu se face doar în contextul unei solicitări venite de la cetățean, ci într-o varietate mult mai mare de cazuri. Față de cele de mai sus, autoritatea contractantă afirmă că „explicațiile furnizate de ofertant demonstrează că sistemul ofertat NU îndeplinește cerințele funcționale ale caietului de sarcini”, în opinia sa „autoritatea contractantă este suverană asupra înțelesului termenilor caietului de sarcini, iar contestatoarea, în cazul în care nu a înțeles sensul acestora, a avut posibilitatea de a solicita clarificări, lucru care nu s-a întâmplat”. De asemenea, autoritatea contractantă mai afirmă că societatea contestatoare „a arătat o atitudine ostilă pe durata sesiunii demonstrative, refuzând un dialog constructiv cu membrii comisiei, fapt susținut explicit în înregistrarea video (partea de început)”. 2. În combaterea criticii referitoare la îndeplinirea cerințelor privind interfața grafică, după ce redă cerința aferentă de la pag. 20 din caietul de sarcini, autoritatea contractantă precizează că sesiunea demonstrativă a arătat „fără echivoc” că declarația contestatoarei conform căreia „interfața EPRIM (back office) este una mobile responsive" nu este sustenabilă, iar contestatoarea „pe toată durata Pagina 12 din 40

sesiunii demonstrative nu a fost în măsură să dovedească caracterul INTEGRAL responsive al aplicației rezumându-se la afirmații «cum că se poate configura» (...) în ciuda clarificărilor primite în mod succesiv de la expertul tehnic și comisia de evaluare, a continuat să dea propria sa interpretare prevederilor caietului de sarcini, iar la un moment dat în cursul sesiunii demonstrative a «contestat efectiv nevoia acestei cerințe funcționale»". Cu privire la caracterul integral responsive al aplicației, organizatoarea procedurii precizează că acesta presupune ca „întreaga interfață (nu doar un singur ecran) să poată fi accesată și utilizată în aceleași condiții ca pe un calculator desktop de pe orice tip de dispozitiv mobil”. 3. În combaterea criticii referitoare la îndeplinirea cerințelor privind conversia automată a fișierelor în format PDF, prin raportare la cerințele minime obligatorii de la pag. 21 și 35 din caietul de sarcini, organizatoarea procedurii menționează că „funcționalitatea de conversie a fișierelor nu există în interfața front office ePortal; funcționalitatea de conversie a fișierelor nu este realizată automat în interfața back office, ci ca opțiune manuală «convertește la document PDF» prezentată funcționarului - fapt vizibil la min 3:10:10 al înregistrării video; performanța procesului de conversie demonstrat nu este la un nivel rezonabil (peste 42 secunde de secunde pentru un fișier-fapt vizibil la min 3:10:19-3:11:01 al înregistrării video) - procesul de conversie fiind întrerupt manual de reprezentantul ofertantului; conversia din format png (conținut original vizibil la min 3:12:13 al înregistrării video) a prezentat un conținut diferit în documentul pdf (conținut rezultat urmare a conversiei vizibil la min 3:12:21 al înregistrării video)”. Având în vedere răspunsul contestatoarei la solicitarea de clarificări, autoritatea contractantă precizează că sesiunea demonstrativă a arătat, în opinia sa, „fără echivoc”, că funcționalitățile de validare de format, conținut și de securitate nu sunt funcționale sau lipsesc cu desăvârșire. În acest sens, precizează că încă de la început a cerut ofertanților să facă dovada „validărilor prin prisma faptului că sistemul ofertat să nu fie un sistem experimental ci o «soluție deja existentă în exploatare la alte instituții»”. Totodată, susține că: „era obligația ofertantului să facă pe parcursul sesiunii demonstrative dovada existenței validărilor de nivel primar (cel mai scăzut nivel acceptat în industrie) ale sistemelor informatice precum: validarea CNP, consistența datelor cu privire la valabilitatea actelor de identitate (data de emitere și data de expirare), prezența nomenclatoarelor stradale, evitarea salvării de date incomplete cu privire la identitatea electronică a persoanelor juridice, etc.”. În acest sens autoritatea contractantă prezintă câteva exemple de erori semnalate pe parcursul sesiunii demonstrative: „Salvare în baza de date a unui CNP fals - sistemul ofertat nu a fost capabil să sesizeze structura greșită a CNP-ului introdus; Inconsistența logică a datelor Pagina 13 din 40

introduse - sistemul nu a fost capabil să identifice că actul introdus în baza de date are o dată de emitere din viitor; Salvarea în baza de date de seturi de date incomplete - identități de persoane juridice salvate în sistem fără sediu social - Sediul social este un atribut obligatoriu al identității electronice a persoanelor juridice, fiind echivalent cu domiciliul persoanei fizice”. De asemenea, susține aceasta, chiar dacă a primit clarificări de la expertul tehnic și comisia de evaluare, contestatoarea are propria sa interpretare asupra prevederilor caietului de sarcini, fapt care, în opinia autorității contractante, demonstrează lipsa de „concordanță cu intenția instituției de a implementa un sistem matur cu capabilități tehnice dovedite”. După prezentarea explicațiilor conceptuale cu privire la noțiunea de validare de format, conținut și securitate, autoritatea contractantă precizează că „nu au fost urmărite pe parcursul sesiunii demonstrative validări sofisticate sau care nu au caracter public, ceea ce face ca afirmația ofertantului de «a agrea cu instituția ce validări să implementeze» să se plaseze sub standardele minime de calitate agreate la nivelul instituției”. Referitor la contestatoare, autoritatea contractantă menționează că în măsura în care ar fi avut neclarități cu privire la ce validări vor fi verificate pe parcursul sesiunii demonstrative, ar fi putut solicita clarificări, fapt nerealizat de către aceasta. 7. În combaterea criticii referitoare la îndeplinirea cerințelor privind funcționalitatea de validări de format, conținut și validări de securitate a conținutului formularelor inteligente transmise online, autoritatea contractantă invocă cerințele minime obligatorii de la pag. 21 din caietul de sarcini și arată că, în privința propunerii tehnice a contestatoarei „validarea de conținut nu a funcționat corect la nivelul unor câmpuri din formulare inteligente transmise online”, și anume: „la min 12:45 al înregistrării video - când sistemul validează seria CI conținând litere mici; la min 58:36 al înregistrării video - când sistemul validează un CNP invalid; la min 12:52 al înregistrării video - când este introdusă și salvată de sistem o dată de emitere a actului de identitate din viitor. Cererea e preluată, validată și salvată în baza de date fără o validare a funcționarului; datele privind actul de identitate, deși preluate în solicitarea de înrolare, nu sunt prezentate spre validare funcționarului nici în interfața back-office, nici în cererea / formular de înrolare — datele pur si simplu se salvează direct în baza de date. (to do xx:xx); la min: 1:41:30 — când datele actului identitate sunt validate deși nu au fost completate; la min: 1:42:25 —adresa este validată deși numărul nu este completat; la min. XX:XX — denumirea străzii editată manual de cetățean se salvează direct în baza de date fără o verificare prealabilă a funcționarului”. Pagina 14 din 40

Prin urmare, susține autoritatea contractantă, sesiunea demonstrativă a propunerii tehnice a contestatoarei a arătat „fără echivoc” că funcționalitățile de validare de format, conținut și de securitate nu sunt funcționale sau lipsesc cu desăvârșire, cu toate că s-a cerut ofertanților să facă dovada „validărilor prin prisma faptului că sistemul ofertat să nu fie un sistem experimental ci o «soluție deja existentă în exploatare la alte instituții»”. De asemenea, precizează că „era obligația ofertantului să facă pe parcursul sesiunii demonstrative dovada existenței validărilor de nivel primar (cel mai scăzut nivel acceptat în industrie) ale sistemelor informatice precum: validarea CNP, consistența datelor cu privire la valabilitatea actelor de identitate (data de emitere și data de expirare), prezența nomenclatoarelor stradale, evitarea salvării de date incomplete cu privire la identitatea electronică a persoanelor juridice, etc.”. Față de cele de mai sus, autoritatea contractantă prezintă, tot cu titlu exemplificativ, câteva exemple de erori semnalate pe parcursul sesiunii demonstrative a contestatoarei: „Salvare în baza de date a unui CNP fals - sistemul ofertat nu a fost capabil să sesizeze structura greșită a CNP-ului introdus; Inconsistența logică a datelor introduse - sistemul nu a fost capabil să identifice că actul introdus în baza de date are o dată de emitere din viitor; Salvarea în baza de date de seturi de date incomplete - identități de persoane juridice salvate în sistem fără sediu social - Sediul social este un atribut obligatoriu al identității electronice a persoanelor juridice, fiind echivalent cu domiciliul persoanei fizice”. De asemenea, menționează că ,,nu a urmărit pe parcursul sesiunii demonstrative validări sofisticate sau care nu au caracter public, ceea ce face ca afirmația ofertantului de «a agrea cu instituția ce validări să implementeze» să se plaseze sub standardele minime de calitate agreate la nivelul instituției”. 8. În combaterea criticii referitoare la îndeplinirea cerințelor privind semnarea electronică a declarațiilor/cererilor depuse (de către cetățean), după ce redă cerințele aferente de la pag. 21 din caietul de sarcini, organizatoarea procedurii susține că, în urma analizei înregistrării sesiunii demonstrative, a constatat că nu a fost prezentat/demonstrat faptul că în interfața front office (ePortal) există opțiunea de semnare electronică calificată, de către cetățean, a declarațiilor sau cererilor depuse, în sensul că „în soluția tehnică ofertată a fost prezentată semnarea electronică cu o semnătură electronică generată de sistem care nu are puterea legală conferită de semnătura electronică calificată”. Față de cele de mai sus, autoritatea contractantă afirmă că societatea contestatoare, pe lângă faptul că „a dat dovadă pe toată durata procedurii (inclusiv în formularea contestației) de o interpretare speculativă a cerințelor funcționale din cuprinsul caietului de sarcini dovedind o conduită îndoielnică cu privire la buna credință în înțelegerea cerințelor funcționale”, se mai și contrazice în afirmații, pe de-o parte Pagina 15 din 40

susținând că „a realizat integrarea cu Certsign şi Transsped" ceea ce i-ar fi permis să demonstreze funcționalitatea pe durata sesiunii demonstrative, iar pe de altă parte își justifică imposibilitatea de a demonstra funcționalitatea prin faptul ca acest lucru „ar fi implicat existența unui cetățean înrolat în sistem paperless la un furnizor acreditat". Or, afirmă autoritatea contractantă, toți furnizorii din piață, care dețin astfel de capabilități de semnare remote (inclusiv Certsign și Transsped), pun la dispoziția companiilor de IT doritoare, „cu titlu gratuit (!)” semnături electronice calificate de test, care permit demonstrarea funcționalității atunci când este nevoie. De asemenea, autoritatea contractantă susține că, societatea contestatoarea „nu doar că nu a putut demonstra existența funcționalității de semnare electronică calificată în browser în cadrul sistemului așa cum era cerut în cerințele funcționale din caietul de sarcini însă, pe parcursul sesiunii demonstrative, a încercat în mai multe rânduri să inducă în eroare expertul tehnic și membrii Comisiei de Evaluare (fapt care este surprins pe înregistrarea video a sesiunii demonstrative) pretinzând că semnarea electronică pe care o folosește este una cu «certificat calificat»”. În acest sens, precizează că „pe înregistrare este surprins momentul în care reprezentanții … se contrazic unul pe celălalt, unul susținând că semnătura folosită este una calificată, în timp ce celălalt îi atrage atenția că nu este așa, semnătura folosită fiind una emisă de SOBIS, nu de un furnizor autorizat”. Față de cele de mai sus, autoritatea contractantă menționează că cerințele funcționale cu privire la semnarea electronică a declarațiilor și cererilor de către cetățeni privesc semnarea electronică calificată a documentelor, întrucât semnătura electronică calificată este singura care, conform legislației naționale și europene în vigoare, echivalează cu semnătura olografă a persoanei. Prin urmare, relația cetățean - instituție a presupus dintotdeauna semnarea olografă a documentelor, motiv pentru care și în mediul online, pentru a asigura semnăturii cetățeanului aceleași efecte juridice, singura semnătură viabilă era semnătura electronică calificată. Pentru argumentele mai sus enunțate, autoritatea contractantă afirmă că, în opinia sa, „interpretarea speculativă pe care ofertantul o dă prevederilor caietului de sarcini (pag. 21) este de natură să demonstreze lipsa bunei sale credințe în asigurarea unei soluții care să respecte legea și să ajute la satisfacere nevoilor instituției”. În concluzie, susține autoritatea contractantă, „explicațiile date de ofertant cu privire la motivul pentru care nu a putut demonstra funcționalitatea au fost neconcludente”. 10. În combaterea criticii referitoare la îndeplinirea cerințelor privind aplicația pentru dispozitivele mobile, raportându-se la cerințele Pagina 16 din 40

caietului de sarcini, pag. 21, organizatoarea procedurii precizează că urmare evaluării propunerii tehnice a contestatoarei a constatat faptul că aceasta „1. este o aplicație care rulează în server („web application") şi nu pe dispozitiv (aplicație mobilă) — deși susținută ca aplicație, nu „web- application", de reprezentantul ofertantului la min 1:59:26 al înregistrării video; 2. componenta back office nu s-a regăsit în aplicația prezentată”. Contestatoarea nu a reușit nici prin răspunsul la solicitarea de clarificări să demonstreze existența aplicației mobile așa cum s-a cerut în cerințele funcționale, ci doar a unui SDK de redirecționare către site-ul aplicației ePortal, care, în urma descărcării „aplicației" pe telefonul mobil al expertului, s-a constatat că nu putea accesa niciuna dintre aplicațiile ePortal şi EPRIM, deși ,,accesarea iconiței aplicației trebuia să deschidă browser-ul telefonului în care putea fi vizualizat site-ul ePortal’’, în timp ce EPRIM nu a putut fi accesat deloc. De asemenea, autoritatea contractantă explică faptul că prin cerința funcțională din caietul de sarcini s-a solicitat ca tot conținutul (front office și back office) să fie pus la dispoziție într-o aplicație de mobil, care trebuia să fie accesată în aplicație și nu apelând un website. Cu toate acestea, pe durata sesiunii demonstrative, precum și ulterior, conținutul produsului ofertat a depins de un browser de internet , motiv pentru care autoritatea contractantă susține că își menține punctul de vedere asupra neconcludenței răspunsului oferit de contestatoare. 14. În combaterea criticii referitoare la îndeplinirea cerințelor privind implementarea unui mecanism automat și auditabil de înregistrare (acordarea numerelor de înregistrare) a lucrărilor ce va fi integrat cu mesageria electronică, registrele instituției și cu platforma de semnare electronică, autoritatea contractantă redă cerințele minime obligatorii de la pag. 21 din caietul de sarcini, cu mențiunea că în timpul sesiunii demonstrative, a constatat că sistemul ofertat nu a demonstrat integrarea cu platforma de semnare și sigilare electronică, iar societatea contestatoare nu a dovedit nici existența sigiliului electronic la nivelul sistemului, respectiv integrarea între mecanismul de alocare a numerelor de înregistrare și sigiliul electronic. În același sens, afirmă că pe toată durata procedurii și a sesiunii demonstrative, contestatoarea nu a putut demonstra capabilitatea sistemului ofertat de interconectare cu platforma de semnare electronică, deși scopul interconectării, conform caietului de sarcini, este acela de a insera numărul de înregistrare în documentul semnat electronic fără alterarea semnăturilor electronice deja existente, și nici capabilitatea sistemului ofertat de interconectare cu mesageria electronică, „scopul acestei integrări fiind acela de a condiționa acordarea numărului de înregistrare de existența unui flux specific de întocmire - avizare – aprobare”. Totodată, autoritatea contractantă precizează că cerința potrivit căreia „sistemul va dispune de un mecanism automat și auditabil de Pagina 17 din 40

înregistrare (acordarea numerelor de înregistrare) a lucrărilor ce va fi integrat cu mesageria electronică, registrele instituției și cu platforma de semnare electronică" acoperă deopotrivă semnătura electronică și sigiliul electronic, motiv pentru care susține că societatea contestatoare, „fie nu deține cunoștințe temeinice în domeniu, fie în mod deliberat încearcă să inducă în eroare pe cei abilitați cu analiza prezentei contestații, întrucât înțelesul corect al termenului «semnare electronică» include deopotrivă semnătura electronică și sigiliul electronic, astfel: «semnătura electronică» când aplicatul este o persoană fizică, respectiv «sigiliu electronic» când aplicatul este o persoană juridică”. Suplimentar, autoritatea contractantă menționează că în propunerea tehnică a contestatoarei există o „inconsistență evidentă între mențiunile făcute în matricea de conformitate și cele observate de către Expertul tehnic și membrii Comisiei de evaluare pe parcursul sesiunii demonstrative”. 15. În combaterea criticii referitoare la îndeplinirea cerințelor privind înregistrarea în registrul unic și detalii care însoțesc obligatoriu un număr de înregistrare, autoritatea contractantă redă cerințele minime obligatorii din caietul de sarcini, pag. 21 și precizează că din analiza propunerii tehnice și a înregistrării sesiunii demonstrative, a rezultat că soluția tehnică ofertată de contestatoare nu dispune de registru unic al instituției, destinat lucrărilor, precum și de registre distincte pentru documente și grupe distincte pentru fiecare tip de document asociate registrelor Față de aspectele de mai sus, menționează că aceleași neconformități au fost constatate și pentru cerințele enunțare la pct. 16, 17, 19 și 20, care fac parte din aceeași secțiune, conținutul lor fiind interdependent. Pentru toate aceste motive, autoritatea contractantă precizează că va prezenta o argumentație comună în acest sens. Astfel, organizatoarea procedurii arată că sesiunea demonstrativă a arătat, fără echivoc, faptul că sistemul ofertat permite numai înregistrarea lucrărilor fără actele care o alcătuiesc, situație ce conduce, implicit, la rezervarea numerelor de înregistrare de o așa manieră încât se creează aparența ca „ele au fost înregistrate în trecut”, fapt ce demonstrează că registratura, ce deservește sistemul, încalcă cerințele funcționale din caietul de sarcini. În această ordine de idei, precizează că sistemul ofertat este mai mult un registru de numere de înregistrare (acesta ținând evidența numerelor, și nu a actelor) decât un registru de lucrări, fapt ce presupune prezența obligatorie a actelor înregistrate. Cu privire la aspectele în cauză, autoritatea contractantă menționează că actele electronice ce constituie lucrările de intrare, nu au precizate, în structura lor de date, numărul de înregistrare, motiv pentru care, în mod practic, un atare fișier nu poartă menționat nici vizibil pe document, nici în panoul de semnături, numărul de înregistrare. Pagina 18 din 40

Prin urmare, actele ce alcătuiesc o anume lucrare primesc același număr de înregistrare, fiind încălcată astfel cerința din caietul de sarcini care prevede ca actele să dețină numere de înregistrare „UNICE”. De asemenea, nici formatul numărului de înregistrare, solicitat în caietul de sarcini, nu este respectat prin soluția propusă, ofertantul acordând din nou propria sa interpretare cerințelor funcționale, fapt care, în opinia autorității contractante, a demonstrat că societatea contestatoare nu face o distincție clară între noțiunea de „lucrare" și cea de „act", fapt care se manifestă și la nivelul sistemului prin aceea că actele dintr-o lucrare sunt înregistrate toate cu numărul de înregistrare al lucrării fără a avea numere de înregistrare „individuale și unice”. În opinia sa, sistemul ofertat nu prezintă funcționalitatea „registrelor de documente electronice" ca element distinct de „registrul de unic de lucrări", așa cum era prevăzut în caietul de sarcini prin cerința „să existe o evidentă distinctă pe lucrări și pe documente". De asemenea, autoritatea contractantă subliniază faptul că modalitatea de ținere a evidenței lucrărilor și documentelor, solicitată prin caietul de sarcini, a fost menită să asigure instituției o evidență centralizată și completă a tuturor lucrărilor din instituție, respectiv să conducă la evitarea unor situații nefirești precum: rezervarea de numere de înregistrare de lucrări pentru viitor; apariția mai multor acte cu același număr de înregistrare; acordarea de numere de înregistrare din trecut; înregistrarea lucrărilor independent de introducerea în sistem a documentelor componente, precum și lipsa numărului de înregistrare din documentul electronic, respectiv din panoul de semnături. 16. În combaterea criticii referitoare la îndeplinirea cerințelor privind gestiunea separată a activităților atât după lucrări, cât și după documente, autoritatea contractantă redă cerințele de la pag. 21 din caietul de sarcini, și arată că, în accepțiunea caietului de sarcini, gestiunea separată după lucrări și documente înseamnă că lucrările și documentele sunt înregistrate în registre distincte, și, în consecință, numerele de lucrări trebuie să fie diferite de numerele de documente. Or, din analiza propunerii tehnice și din înregistrarea sesiunii demonstrative referitoare la propunerea tehnică a contestatoarei, a rezultat că lucrarea și documentele au același număr de înregistrare. Prin urmare, autoritatea contractantă arată că-și menține punctul de vedere exprimat în procesul verbal de evaluare a propunerilor tehnice, anume că răspunsul oferit la solicitarea de clarificări în cauză nu este concludent, motivele fiind deja prezentate, în formă consolidată, în cadrul analizei de la pct. 15. 17. În combaterea criticii referitoare la îndeplinirea cerințelor privind evidența numerelor de înregistrare a documentelor în cadrul unei lucrări, autoritatea contractantă redă solicitările de la pag. 22 din caietul de sarcini și arată că, din analiza propunerii tehnice și din înregistrarea sesiunii demonstrative, minutul 2:19:34 – 2:19:49 din înregistrarea Pagina 19 din 40

video, a rezultat că toate documentele salvate în lucrare au același număr de înregistrare, identic cu cel al lucrării, fapt confirmat și de reprezentantul contestatoarei. Or, în aceste condiții, autoritatea contractantă afirmă că este evident faptul că răspunsul contestatoarei a fost neconcludent, motiv pentru care își menține punctul de vedere exprimat în procesul verbal de evaluare a propunerilor tehnice. 19. În combaterea criticii referitoare la îndeplinirea cerințelor privind diferențierea documentelor ciornă de cele finale, a celor principale de anexele lor, și a evidenței separate a acestora, după ce redă cerințele de la pag. 21 din caietul de sarcini, organizatoarea procedurii arată că, din analizând propunerii tehnice a contestatoarei, precum și din înregistrarea sesiunii demonstrative, nu a identificat îndeplinirea acestei cerințe, deoarece la nivelul unei lucrări nu este evidențiat care este documentul principal, care sunt documentele anexă și nici cum se identifică acestea în mod unic, printr-un număr unic de înregistrare. Așadar și din acest punct de vedere răspunsul contestatoarei la solicitarea de clarificări a fost unul neconcludent. 20. În combaterea criticii referitoare la îndeplinirea cerințelor privind formatul predefinit al numerelor de înregistrare, autoritatea contractantă ce cerințele aferente de la pag. 21 din caietul de sarcini, și precizează că propunerea tehnică a contestatoarei conține în soluția ofertată, numere de înregistrare cu o structură simplă (numerică), fără a respecta formatul de număr solicitat prin caietul de sarcini, respectiv: „numărul unic al documentului; identificarea emitentului documentului; identificarea lucrării din care documentul face parte; registrul din care a fost alocat numărul de înregistrare”. Prin urmare, nici această cerință nu respectă caietul de sarcini, iar răspunsul contestatoarei a fost neconcludent. 21. În combaterea criticii referitoare la îndeplinirea cerințelor privind funcționalitatea de semnare electronică calificată a tuturor documentelor justificative depuse de către utilizator, astfel cum sunt redate acestea la pag. 25 din caietul de sarcini, organizatoarea procedurii susține că, din analiza propunerii tehnice, respectiv a înregistrarea sesiunii demonstrative, min. 2:49:30 – 2:50:05, astfel cum a recunoscut și „reprezentantul ofertantului”, a rezultat că interfața ePortal nu dispune de capabilitatea de semnare electronică cu certificat calificat în browser, ofertantul prezentând, în cadrul sesiunii demonstrative, semnarea cu o semnătura electronică „autoemisă” de portal. Prin urmare, interfața EPRIM nu implementează semnarea electronică calificată a documentelor justificative depuse pe fluxul de intrare al acestora în instituție. Totodată, precizează autoritatea contractantă, din răspunsul ofertantului la solicitarea de clarificări a rezultat că sesiunea demonstrativă a arătat, fără echivoc, faptul că sistemul ofertat nu Pagina 20 din 40

prezintă funcțiunea semnării electronice de către funcționar, cu semnătura electronică a funcționarului și sigiliul electronic al instituției - în termenii menționați la pct. 14, la momentul luării în evidență a lucrărilor intrate în instituție. În același sens, afirmă că din cauza acestui aspect nici numărul de înregistrare nu este vizibil pe document, acesta negăsindu-se inserat nici în panoul de semnături. Așadar, afirmă autoritatea contractantă, contestatoarea „nu a făcut dovada niciunei integrări cu furnizorii de servicii de încredere plasându- se singur astfel în imposibilitatea de a demonstra îndeplinirea cerințelor funcționale”, în condițiile în care cerința funcțională din caietul de sarcini este menită să asigure agregarea tuturor datelor ce definesc actul (respectiv: numărul de înregistrare, data înregistrării, cine l-a luat în evidență, etc.) la nivelul actului electronic și nu la nivelul sistemului informatic. În aceste condiții, autoritatea contractantă susține că modalitatea de lucru prezentată de ofertant ar face ca ,,o eventuală renunțare la relația contractuală cu furnizorul să conducă la pierderea acestor date întrucât ele sunt stocate la nivelul sistemului, acestea nefiind inserate în structura logică a documentului”. Cu privire la cele de mai sus, autoritatea contractantă menționează că inclusiv din „constatările expertului tehnic cooptat și a membrilor comisiei de evaluare rezultă că ofertantul nu a înțeles cerințele funcționale din caietul de sarcini”, în fapt, „pe durata sesiunii demonstrative, încercând să convingă expertul tehnic și membrii comisiei de evaluare că cerințele funcționale nu sunt corecte”. 23. În combaterea criticii referitoare la îndeplinirea cerințelor privind accesul protejat la date și integrarea managementului identităților în soluția propusă, astfel cum sunt acestea redate la pag. 35 din caietul de sarcini, autoritatea contractantă susține că, analizând propunerea tehnică, respectiv din înregistrarea sesiunii demonstrative, min. 2:29:54 și 35:22, rezultă că ,,documentul colaborativ a putut fi accesat de membrii comisiei și modificat (ulterior finalizării sesiunii demonstrative), folosind inclusiv amprenta identității inițiatorului, fără autentificare prealabilă, la data de 16.03.2022 (prin accesarea linkului expus în înregistrare), fapt valabil și privind platforma de comunicare video”. Față de cele de mai sus, autoritatea contractantă afirmă că sesiunea demonstrativă a arătat, fără echivoc, faptul că sistemul ofertat nu deține capabilitatea de a asigura accesul controlat la date prin token-uri de securitate asociate identității electronice a utilizatorilor, token-uri de securitate care ar fi trebuit să permită accesul utilizatorului doar cât timp acesta se află autentificat în sesiune a de browser. În același sens, precizează că expertul tehnic și comisia de evaluare au reușit, „la săptămâni distanță” față de momentul sesiunii demonstrative, să acceseze conținutul documentului, numai de pe Pagina 21 din 40

calculatorul personal, fără niciun fel de autentificare, prin simpla copiere a link-ului în browser, ceea ce denotă „vicii majore de securitate ale produsului ofertat”. Or, susține autoritatea contractantă, cerința funcțională din caietul de sarcini este menită să asigure accesul la informații doar personalului autorizat și doar pe timpul cât token-ul de securitate este valabil. Cu privire la afirmația contestatoarei, cum că „nu ar fi justificată poziția autorității contractante privind presupuse funcționalități ce nu au fost demonstrate, atâta vreme cât în cadrul sesiunii demonstrative, s-a răspuns la toate interpelările comisiei, fapt consemnat și în înregistrarea video", autoritatea contractantă menționează faptul că a adus la cunoștința tuturor ofertanților faptul că sesiunea demonstrativă va fi înregistrată și pusă la dispoziția comisiei de evaluare, conform celor precizate în secțiunea „Sesiunea demonstrativă" din caietul de sarcini. Totodată, organizatoarea procedurii învederează și următoarele aspecte: „1. Deși ofertanții aveau obligația ca ‹‹urmând fluxurile scenariului sesiunii demonstrative din documentația de atribuire, îndeplinirea cerințelor funcționale minimale din caietul de sarcini prevăzute în secțiunea «Cerințele funcționale ale infrastructurii digitale interinstituționale interconectate și interoperabile de lucru», utilizând exclusiv infrastructura digitală ofertată și urmând epica scenariilor demonstrative prevăzute în documentația de atribuire››, contestatarul a ales doar să urmeze scenariul sesiunii demonstrative, fără a urmări să demonstreze cerințele funcționale referite - faptul că «această funcționalitate nu e parte a scenariului sesiunii demonstrative» a fost reiterat pe parcursul demonstrației atunci când comisia de evaluare a formulat solicitări în acest sens. 2. Deși reiese cu claritate din cerințe obligația ofertanților de a utiliza în demonstrație infrastructura ofertată, contestatarul invocă în clarificări incapacitatea de a demonstra unele cerințe (ex. semnătură și sigilare electronică calificată) ori neconformitatea sistemului (ex. privind validări de date și securitatea sistemului) motivat de faptul că «s-a utilizat o instalație de test». 3. Deși reiese cu claritate din cerințe obligația ofertanților de a asigura infrastructura hardware și de comunicații proprie în demonstrație în vederea asigurării unui nivel de performanță adecvat, contestatarul invocă nejustificat în clarificări lipsuri privind acest subiect pentru că a ales să o utilizeze pe a Autorității contractante. 4. Deși reiese cu claritate din cerințe că «Justificat de scopul urmărit, durata procesului de analiză și volumul de informații de analizat, sesiunea demonstrativă va fi înregistrată și dispusă comisiei de evaluare în cadrul procedurii», și în plus Procesul Verbal semnat de reprezentanții contestatarului consemnează că, «în conformitate cu prevederile Caietului de Sarcini reprezentații Asocierii ... și ... au parcurs Pagina 22 din 40

toate etapele sesiunii demonstrative, oferind detalii și răspunzând întrebărilor comisiei», contestatarul asumă nejustificat că a demonstrat cerințele funcționale solicitate”. În ceea ce privește conținutul caietului de sarcini, autoritatea contractantă precizează că acesta a fost stabilit în urma unui studiu de analiză al proceselor derulate la nivelul proiectului, conform obiectivelor și priorităților comunicate de compartimentele din cadrul acesteia, relevante în acest sens fiind dispozițiile art. 2 alin. (5) din H.G. nr. 395/2016 și art. 155 alin. (1)-(6) din Legea nr. 98/2016, „nerespectarea cu strictețe a cerințelor din caietul de sarcini putând periclita desfășurarea în bune condiții a activității acesteia”. Față de cele de mai sus, MUNICIPIUL ... solicită Consiliului să respingă contestația ..., în calitate de lider al ASOCIERII .../..., ca „neîntemeiată și nefondată”. În drept au fost invocate prevederile art. 26 alin. (6) din Legea nr. 101/2016, cele ale Legii nr. 98/2016, precum și cele ale H.G. nr. 395/2016. Dovada comunicării punctului de vedere către reprezentantul convențional al contestatoarei a fost atașată. În probațiune, prin adresa nr. 40876/30.05.2022, înregistrată la C.N.S.C. sub nr. …/…, MUNICIPIUL ... a transmis la dosarul cauzei, în copie certificată, documente din dosarul achiziției publice, precum și un dispozitiv CD cuprinzând documente din dosarul achiziției publice. În completarea probațiunii, prin adresa nr. 42495/03.06.2022, înregistrată la C.N.S.C. sub nr. …/…, MUNICIPIUL ... a transmis la dosarul cauzei declarația contestatoarei privind documentele declarate confidențiale și 3 dispozitive CD, cuprinzând documente din dosarul achiziției publice, precum și înregistrările video ale sesiunilor demonstrative. Prin adresa nr. 784/08.06.2022, înregistrată la C.N.S.C. sub nr. …/ …, ... a transmis la dosarul cauzei un răspuns cu privire la punctul de vedere formulat de autoritatea contractantă MUNICIPIUL ..., solicitând îndepărtarea argumentelor invocate de către aceasta din urmă, în cuprinsul punctului de vedere nr. 40837/30.05.2022 și admiterea contestației. În acest sens, arată că, prin punctul de vedere formulat, organizatoarea procedurii a solicitat respingerea contestației, motivând, în esență, că în urma verificării răspunsurilor contestatoarei la solicitările de clarificări, comisia de evaluare a considerat că acestea sunt neconcludente cu privire la cerințele de la pct. 1, 2, 3, 7, 8, 10, 14, 15, 16, 17, 19, 20, 21 și 23 din adresa nr. 23352/25.03.2022. Față de cele de mai sus, contestatoarea precizează următoarele: 1.Referitor la criticile vizând cerința de la pct. 1, arată că nu se află în situația de a oferi o interpretare proprie cerințelor din caietul de sarcini, reafirmând că a respectat cerința cu privire la GDPR. În ceea ce privește Pagina 23 din 40

afișarea datelor în aplicația EPRIM, contrar celor susținute de organizatoarea procedurii, susține că datele personale ale cetățenilor „nu sunt accesibile tuturor cetățenilor”. 2. Referitor la criticile vizând cerința de la pct. 2, precizează că interfețele ePortal (destinată cetățenilor), și EPRIM (destinată funcționarilor), reprezintă „implementarea a două teme responsive (bazate pe Bootstrap) pentru soluția ofertată”, ambele teme fiind disponibile atât pentru zona ePortal, cât și pentru EPRIM, conform secvenței de la minutul 2:50:51 din sesiunea demonstrativă. 3. În ceea ce privește critica vizând cerința de la pct. 3, susține că prin răspunsul la solicitarea de clarificări a indicat că la pag. 20 din caietul de sarcini se solicită ca "Infrastructura digitală va fi provizionată pe scenarii de încărcare astfel încât nivelul de performanță să fie unul rezonabil", motiv pentru care, în opinia sa, nu ar exista o altă constrângere cu privire la timpii de răspuns. Privitor la conversia fișierelor, afirmă că aceasta se realizează automat, în format pdf, folosindu-se, în acest sens, un „task în backgound care pornește AUTOMAT”, rezultatul fiind reprezentat de noua versiune a documentului depus. 7. Referitor la criticile vizând cerința de la pct. 7, arată că sistemul informatic propus implementează validarea în două etape a câmpurilor, o validare front-office și una back-office, sens în care reia argumentele expuse în cuprinsul contestației. 8. Cu referire cerința de la pct. 8, susține că afirmațiile autorității contractante din cuprinsul punctului de vedere „au un caracter tendențios și sunt făcute cu rea-credință”, menționând faptul că în caietul de sarcini nu sunt cuprinse precizări referitoare la tipul de semnături cu care cetățeanul poate semna. 10. Față de criticile vizând cerința de la pct. 10, susține că aplicația ofertată era instalată pe dispozitivul mobil prezentat, nefiind vorba despre o redirecționare către website. 14. Cu privire la criticile de la pct. 14, respectiv la susținerea autorității contractante potrivit căreia „a constatat că sistemul prezentat de ofertant nu a demonstrat integrarea cu platforma de semnare și sigilare electronică", precizează că în oferta tehnică - matricea de conformitate, pag. 149, 213, 232,278, 286 și 288 sunt referințe, cu capturi, care indică faptul că „sistemul dispune de integrare cu platforma de sigilare electronică”. Referitor la susținerea autorității contractante potrivit căreia „ofertantul nu a dovedit nici: Existența la nivelul sistemului a sigiliului electronic", susține că sigiliul electronic există la nivelul furnizorului calificat drept sigiliu, iar sistemul ofertat asigură integrarea cu acest sigiliu prin apelul securizat al serviciului de sigilare pus la dispoziție de furnizor. Pagina 24 din 40

În ceea ce privește afirmația potrivit căreia „ofertantul nu a demonstrat: Integrarea între mecanismul de alocarea a numerelor de înregistrare și sigiliul electronic", redă cerința de la pag. 22 din caietul de sarcini și susține că mecanismul trebuie integrat cu platforma de semnare, si nu cu sigiliul electronic, conform figurii 58 din oferta tehnică -matrice de conformitate, pag. 134. 15. Cu referile la criticile aferente pct. 15, contestatoarea susține că „aspectele indicate de Autoritatea Contractantă nu sunt adevărate”, sens în care reia argumentația expusă, cu privire la acest aspect, în cadrul contestației. 16. În privința criticii de la pct. 16, contestatoarea precizează că „numărul de înregistrare poate fi orice număr, dar care să fie unic capabil să identifice un document în sistem”, conform figurii 63, pag. 139 din oferta tehnică – matricea de conformitate. 17. Referitor la criticile vizând cerința de la pct. 17, reafirmă că susținerea autorității contractante potrivit căreia ,,toate documentele salvate în lucrare ar avea același număr de înregistrare, identic cu cel al lucrării, este o presupunere eronată”. 19. Față de criticile vizând cerința de la pct. 19, reia argumentele din cuprinsul documentului introductiv. 20. Referitor la criticile vizând cerința de la pct. 20, susține că a respectat cerința în cauză, astfel cum reiese din propunerea sa tehnică, pag. 144 - matricea de conformitate. 21. În ceea ce privește critica referitoare la cerința de la pct. 21, reia argumentele din cadrul contestației și susține că decizia autorității contractante de respingere a ofertei sale, ca inacceptabilă, „este nelegală și, subsecvent, și decizia de anulare a procedurii de achiziție publică”. 23. Referitor la criticile vizând cerința de la ultimul punct, susține că soluția informatică pe care a propus-o satisface integral cerințele caietului de sarcini, iar, răspunsul formulat la solicitarea de clarificări a dus la eliminarea oricăror îndoieli cu privire la aptitudinea soluției informatice de a satisface toate cerințele caietului de sarcini. Prin adresa nr. 705/25.05.2022, înregistrată la C.N.S.C. sub nr. …/ …, ..., în calitate de lider al ASOCIERII .../... a transmis la dosarul cauzei, în original, recipisa de consemnare nr. …/… din …, emisă de CEC BANK, Sucursala …, a sumei de 25.766,00 lei. Din documentele depuse la dosarul cauzei și din susținerile părților, Consiliul reține următoarele: MUNICIPIUL ..., în calitate de autoritate contractantă, a inițiat procedura de atribuire, prin licitație deschisă, derulată online, în vederea atribuirii contractului de achiziție publică având ca obiect „Achiziție active fixe necorporale și servicii aferente instalării, configurării și personalizării în vederea realizării sistemului info portal și de gestiune electronică a documentelor aferente proiectului «Planificare strategică și măsuri de Pagina 25 din 40

simplificare pentru cetățeni la nivelul Municipiului …» cod SIPOCA/MySMIS nr. …/…”, cod CPV 72212000-4 Servicii de programare de software de aplicație (Rev.2), publicând, în S.E.A.P., anunțul de participare nr. CN…/…. Potrivit mențiunii de la pct. II.1.5) - Valoarea totală estimată, din cadrul anunțului de participare mai sus precizat, cuantumul acesteia este de 1.288.300 lei fără T.V.A. De asemenea, conform celor precizate la pct. II.2.5) din același anunț criteriul de atribuire ales a fost „cel mai bun raport calitate-preț”, factori de evaluare și ponderea acestora fiind: „Prețul ofertei” - 40% și „Abordarea propusă pentru implementarea contractului” – 5%; „Resursele (umane și materiale) și realizările corespunzătoare fiecărei activități” – 5 %; „Atribuțiile membrilor echipei în implementarea activităților contractului și, dacă este cazul, contribuția fiecărui membru al grupului de operatori economici, precum și distribuirea și interacțiunea sarcinilor și responsabilitățile dintre ei” – 5%; „Încadrarea în timp, succesiunea și durata activităților propuse și corelarea cu efortul prevăzut pentru experți” – 5%; „Identificarea și încadrarea în timp a punctelor de reper semnificative în execuția contractului, inclusiv descrierea modului în care acestea vor fi reflectate în raportări, în special cele prevăzute în caietul de sarcini” – 5%; „Abordarea propusă pentru managementul schimbării în organizație” – 5%; „Manager de proiect” – 5%; „Expert analist de business” – 5%; „Expert infrastructură hardware și software” – 5%; „Expert platforme de semnare electronică în browser” – 5%; „Expert în managementul identității electronice” – 5%; „Expert UX/UI –user experience și user interface” - 5%. Potrivit celor menționate în cadrul procesului – verbal nr. 2/18.01.2022, pag. 1 – 9, au fost depuse 2 (două) oferte, aparținând ... și ASOCIERII …/.... Ulterior evaluării ofertelor de mai sus, conform raportului procedurii nr. 13/13.05.2022, pag. 36 – 50, oferta aparținând ASOCIERII .../... a fost respinsă ,,ca inacceptabilă în baza art. 134 alin. 5) din HG nr. 395/2016 deoarece în urma verificării răspunsului la solicitarea de clarificări nr. 23352/25.03.2022 prezentat de ASOCIEREA .../... la clarificările privind propunerea tehnică, comisia de evaluare consideră că ofertantul prezintă răspunsuri neconcludente referitoare la cerințele de la pct. 1, 2, 3, 7, 8, 10, 14, 15, 16, 17, 19, 20, 21, 23 din solicitarea de clarificare nr. 23352/25.03.2022 și neconformă în temeiul art. 215 alin. 5) din legea nr. 98/2016 coroborat cu art. 137 alin. 3) lit. a) din HG nr. 395/2016 deoarece nu satisface în mod corespunzător cerințele caietului de sarcini/ documentația de atribuire (...)’’. Oferta aparținând ... a fost declarată câștigătoare cu o valoare a propunerii financiare de 1.223.885 lei fără T.V.A. și 98 de puncte. Decizia de mai sus a fost transmisă ASOCIERII .../... prin adresa nr. 36734/13.05.2022, pag. 52 – 56, care, nemulțumită fiind, în Pagina 26 din 40

termenul legal, a formulat contestația din prezenta cauză, solicitând cele menționate în partea introductivă. Examinând susținerile părților, probatoriul aflat la dosarul cauzei și dispozițiile legale aplicabile, Consiliul constată: Preliminar analizării aspectelor sesizate de contestatoare, este de remarcat că documentația de atribuire, alcătuită din fișa de date, caietul de sarcini, formularele necesare și modelul contractului, și-a consolidat forța obligatorie atât pentru autoritatea contractantă, cât și pentru operatorii economici participanți la procedura de atribuire, inclusiv ofertantul desemnat câștigător. La acest moment nu pot fi emise pretenții sau critici vizavi de prevederile documentației de atribuire, întrucât ar fi vădit tardive, raportat la termenul prescris de Legea nr. 101/2016. Având în vedere cele de mai sus, Consiliul reține că în cursul procesului de evaluare a propunerii tehnice a contestatoarei, aplicând dispozițiile art. 209 alin. 1) din Legea nr. 98/2016 privind achizițiile publice [,,În cazul în care informaţiile sau documentele prezentate de către operatorii economici sunt incomplete sau eronate sau în cazul în care lipsesc anumite documente, autoritatea contractantă are dreptul de a solicita într-un anumit termen ofertanţilor/candidaţilor clarificări şi, după caz, completări ale documentelor prezentate de aceştia în cadrul ofertelor sau solicitărilor de participare, cu respectarea principiilor tratamentului egal şi transparenţei’’], prin adresa nr. 23352/25.03.2022, pag. 1 – 8, autoritatea contractantă a solicitat ASOCIERII .../... clarificări referitoare la ,,oferta tehnică’’ a acesteia. Clarificările au vizat modul în care contestatoarea a respectat 14 (paisprezece) cerințe din cadrul caietului de sarcini, după cum urmează: ,,1. Îndeplinirea cerințelor privind conformitatea cu prevederile GDPR; 2. Îndeplinirea cerințelor privind interfața grafică; 3. Îndeplinirea cerințelor privind conversia automată a filierelor în format PDF. Performanța soluției propuse; 4. Îndeplinirea cerinței privind salvarea în ciorne a formularelor (ce vor fi accesate de cetățeni) pentru care utilizatorul nu a terminat editarea; 5. Îndeplinirea cerinței privind urmărirea (de către cetățeni a) stadiului prelucrării/procesării lucrării de către instituție; 6. Îndeplinirea cerințelor privind revizuirea declarației/ cererii la nevoie; 7. Îndeplinirea cerințelor privind funcționalitatea de validări de format, conținut și validări de securitate a conținutului formularelor inteligente transmise online; 8. Îndeplinirea cerințelor privind semnarea electronică a declarațiilor/cererilor depuse (de către cetățeni); 9. Îndeplinirea cerințelor privind (integrarea cu) arhiva electronică a cetățeanului; 10. Îndeplinirea cerințelor privind aplicația pentru dispozitivele mobile; 11. Îndeplinirea cerințelor privind implementarea principiilor de securitate progresivă bazate pe niveluri de încredere succesive; 12. Îndeplinirea cerințelor privind procedura de on- boarding cetățeni și funcționari; 13. Îndeplinirea cerințelor privind Pagina 27 din 40

versionarea/ actualizarea datelor de identitate; 14. Îndeplinirea cerințelor privind implementarea unui mecanism automat și auditabil de înregistrare (acordarea numerelor de înregistrare) a lucrărilor ce va fi integrat cu mesageria electronică, registrele instituției și cu platforma de semnare electronică; 15. Îndeplinirea cerințelor privind înregistrarea în registrul unic și detalii care însoțesc obligatoriu un număr de înregistrare; 16. Îndeplinirea cerințelor privind gestiunea separată a activităților atât după lucrări, cât și după documente; 17. Îndeplinirea cerințelor privind evidența numerelor de înregistrare al documentelor în cadrul unei lucrări; 18. Îndeplinirea cerințelor privind restricționarea duplicării numerelor de înregistrare, a acordării de numere retroactiv sau de rezervare a lor pentru viitor prin alocarea numerelor de înregistrare odată cu trimiterea pe flux; 19. Îndeplinirea cerințelor privind diferențierea documentelor ciornă de cele finale, a celor principale de anexele lor, și a evidenței separate a acestora; 20. Îndeplinirea cerințelor privind formatul predefinit al numerelor de înregistrare; 21. Îndeplinirea cerințelor privind funcționalitatea de semnare electronică calificată a tuturor documentelor justificative depuse de către utilizator; 22. Îndeplinirea cerințelor privind consistența datelor; 23. Îndeplinirea cerințelor privind accesul protejat la date și integrarea managementului identităților în soluția propusă’’. La solicitarea de mai sus, contestatoarea a răspuns prin adresa FN aflată la pag. 1 – 24, iar ulterior, informațiile prezentate în acest document pentru 14 (paisprezece) cerințe au fost considerate neconcludente de către autoritatea contractantă, aspect care a condus la respingerea ofertei contestatoarei. În ceea ce privește stabilirea neconcludenței informațiilor în cauză, pe lângă argumentele părților, Consiliul va reține că, în aplicarea dispozițiilor art. 126 alin. 3) din H.G. nr. 395/2016 pentru aprobarea Normelor metodologice de aplicare a prevederilor referitoare la atribuirea contractului de achiziţie publică/acordului-cadru din Legea nr. 98/2016 privind achiziţiile publice [,,În cazul în care evaluarea solicitărilor de participare/ofertelor necesită o expertiză aprofundată în domeniul achiziţiilor publice ori de natură tehnică, financiară, juridică şi/sau privind aspectele contractuale specifice, autoritatea contractantă poate desemna, pe lângă comisia de evaluare, specialişti externi numiţi experţi cooptaţi’’], autoritatea contractantă MUNICIPIUL ..., prin dispoziția nr. 2458/22.12.2021, l-a desemnat expert tehnic cooptat pe dl. … – …. Conform prevederilor art. 128 alin. 3) din H.G. nr. 395/2016, ,,Experții cooptaţi nu au drept de vot în cadrul comisiei de evaluare, însă în îndeplinirea atribuţiilor ce le revin potrivit legii şi a mandatului primit în baza deciziei de desemnare, precum şi a competenţelor personale, aceştia procedează la întocmirea unor rapoarte de specialitate asupra cărora îşi exprimă punctul de vedere, pe baza propriei expertize pe care o deţin’’. Pagina 28 din 40

Din verificarea documentelor anexate dosarului cauzei, Consiliul reține că, în aplicarea normei juridice mai sus invocate, expertul tehnic cooptat/senior solutions architect a elaborat raportul de specialitate nr. 8/1/6/19.04.2022, de evaluare tehnică a ofertei ASOCIERII …/..., pag. 1 – 106, care ,,se referă la evaluarea conformității propunerilor tehnice cu prevederile caietului de sarcini și, după caz, cu factorii de evaluare. Procesul de evaluare a fost realizat pe baza informațiilor preliminare prezentate de Ofertant(ți) în ofertă și a documentelor suplimentare depuse de aceștia în anexele ofertei, urmărind să ofere comisiei de evaluare un punct de vedere tehnic privind îndeplinirea sau neîndeplinirea cerințelor minime prevăzute în Caietul de sarcini’’. Față de cele de mai sus, Consiliul va respinge cererea contestatoarei ,,de administrare a probei expertizei judiciare de specialitate IT, în scopul verificării conformității sistemului informatic propus, cu cerințele caietului de sarcini’’, considerând că informațiile cuprinse în cadrul raportului de specialitate elaborate de către expertul tehnic cooptat, de profesie – senior solutions architect, precum și cele furnizate de către părți, sunt suficiente pentru formarea convingerii cu privire la speța dedusă soluționării. Referitor la fondul cauzei, Consiliul va lua în considerare că la pct. 15.5 ,,Sesiunea demonstrativă’’ din caietul de sarcini, pag. 66, se precizează următoarele: ,,Prin depunerea ofertei, ofertantul asumă obligația de a susține prezentarea în cadrul sesiunii demonstrative în sarcina sa cu caracter de conformitate al ofertei depuse (...)’’. În acest sens, Consiliul reține că, în procesul verbal al sesiunii demonstrative nr. 13086/17.02.2022, pag. 1 -2, autoritatea contractantă a precizat că ,,în acord cu cerințele documentației de atribuire, comisia de evaluare consemnează (…) conform cerințelor caietului de sarcini, reprezentanții Asocierii ... și … au parcurs toate etapele sesiunii demonstrative, oferind detalii și răspunzând intrebărilor comisiei’’. Totodată, Consiliul va lua în considerare că primul motiv de respingere a propunerii tehnice a contestatoarei privește modul de îndeplinirea a cerinței de la pct. 3.1.1 Proiectul din caietul de sarcini, pag. 8, conform căreia ,,soluția urmărește implementarea unei infrastructuri digitale capabilă să asigure nevoile de front-office, respectiv transport și interoperabilitate al informațiilor la nivel interinstituțional back-office cu respectarea prevederilor regulamentelor și directivelor europene în vigoare (GDPR, EIDAS, NIS)’’. De asemenea, la pct. 15.5 din caietul de sarcini, pag. 66, s-a specificat faptul că ,,soluția ofertată asigură respectarea cel puțin a prevederilor relevante în contextul proiectului, în ce privește: Legea nr. 455/2001 privind semnătura electronică; Legea nr. 451/2004 privind marca temporală; Regulamentul (UE) nr. 679/2016 cu privire la protecția datelor cu caracter personal (GDPR); Regulamentul (UE) nr. 910/2014 privind serviciile de încredere și identitatea Pagina 29 din 40

electronică (eIDAS); Directiva (UE) nr. 1148/2016 privind nivelul comun ridicat de securitate al rețelelor și sistemelor informatice (NIS)’’. Cu privire la cerințele de mai sus, din analiza propunerii tehnice – matricea de conformitate a contestatoarei, pag. 15, a rezultat că aceasta a menționat următoarele: ,,Am luat la cunoștință. Ne conformăm cerinței enunțate. Din punct de vedere conceptual soluția urmărește implementarea unei infrastructuri digitale capabile să asigure nevoile de front-office, respectiv transport și interoperabilitate al informațiilor la nivel interinstituțional back-office cu respectarea prevederilor regulamentelor și directivelor europene în vigoare (GDPR, EIDAS, NIS)’’. Prin raportare la cele de mai sus, Consiliul reține că, ulterior derulării sesiunii demonstrative, prin adresa nr. 23352/25.03.2022, autoritatea contractantă a solicitat contestatoarei următoarele clarificări: ,,(…) analizând propunerea tehnică prezentată, am constatat că informațiile prezentate în anexa – Oferta tehnică – matrice de conformitate, nu fac trimitere la măsuri implementate în soluția propusă privind protejarea accesului la datele personale. Analizând înregistrarea sesiunii demonstrative prezentate, spre exemplu la min. 36:19 al înregistrării video, am constatat că interfața back office EPIRM afișează neanonimizat (tuturor funcționarilor inclusiv celor din registratură și administratorului de sistem) toate datele personale ale cetățenilor în toate ecranele de lucru prezentate, fără a asigura respetarea principiului confidențialității datelor cu caracter personal și al accesului la date pe baza nevoii de a cunoaște. De asemenea nu a fost observat nicăieri în soluția ofertată capturarea motivului pentru care datele sunt accesate. Vă rugăm să clarificați aceste aspecte, raportat la oferta tehnică depusă și sesiunea demonstrative susținută’’. La solicitarea de mai sus, contestatoarea a răspuns prin adresa nr. SB/E/3272.322/30.03.2022, pag. 1 – 24, astfel: ,,În fișa produsului Product datasheet: ePortal Code: SOB-EPORT-V402-LITE și Product datasheet: EPRIM Code: SOB-EPRIM-V420-DMS la pag. 2 se precizează că produsul satisfice cerințele Regulamentului UE 679/2016 (GDPR). CU privire la măsurile implementate în soluția propusă privind protejarea accesului la datele personale, așa cum s-a precizat și în cadrul sesiunii demonstrative, printre măsurile implementate se numără și faptul că niciun utilizator nu are acces decât la documentele care trec pe la el, deci dpdv al securității, datele cu carcater personal afișate sunt exact ele la care funcționarul are acces fizic ca urmare a consultării documentelor pe care le are în lucru. Niciun alt funcționar/utilizator nu va putea vedea/regăsi vreun alt document (și implicit avea acces la informațiile digitale aferente) decât cel pe care îl are fizic la el în lucru și la care se presupune că implicit poate vedea/accesa informațiile cu caracter personal conținute. Cu privire la faptul că spre exemplu «la min 36:19 al Pagina 30 din 40

înregistrării video, am constatat că interfața back office EPRIM afișează neanonimizat (tuturor funționarilor inclusive a celor din registratură și a administratorului de sistem) toate datele personale ale cetățenilor în toate ecranele de lucru prezentate», precizăm că afirmația este una tendențioasă și neadevărată, ecranele la care vă referiți în sesiunea DEMO (min 36:19) sunt de la administratorul soluției (cum se vede în colțul din dreapta jos) care a primit o cerere de înrolare însistem și care are acces la această cerere (deci și la datele din ea). Datele personale ale cetățenilor nu sunt accesibile tuturor funcționarilor așa cum eronat afirmați. Ele pot fi vizibile funcțonarilor de la registrtură doar atunci când însoțesc o cerere/solicitare (pe care registratura poate să o deschidă și să o redirecționeze – dacă are competențe și dacă sistemul e configurat asstfel, sau poate să fie transferată automat la nivelul/funcționarul competent fără ca registratura să mai fie prezentă pe flux) în măsura în care solicitarea care conține aceste date este deja accesibilă (se află în lucru) la funcționarul de la registratură. Niciun alt funcționar nu va putea vedea solicitarea care nu se află ân lucru la el și nici nu va putea să o vadă în vreo listă. Ca și exemplu de anonimizare, de ex ddatele cu caracter personal sunt afișate protejat (anonimizat) în interfața funcționarului (vezi oferta tehnică – matricea de conformitate pag. 123 fig. 446, pag. 184, fig. 104). Cu privire la faptul că «nu a fost observat nicăieri în soluția ofertată capturarea motivului pentru care datele sunt accesate» facem precizarea că – așa cum s-a afirmat și în cadrul sesiunii demo – orice acces la o informație afișată pe ecran este auditată, deci sistemul poate răspunde în orice moment la întrebarea cine, de pe ce calculator, când a consultat date cu caracter personal, din ce motiv, care sunt aceste date cu caracter personal (indifferent dacă datele sunt afișate în liste/rapoarte, exportate sau afișate ca înregistrări individuale). Motivul accesului este completat automat atunci când utilizatorul utilizează informația via un link/buton care poate fi pentru operare a accesat link-ul Documente în lucru de ex, De rezolvat (a accesat link-ul Rezolvat), Exportat (a accesat link-ul de exportă și a completat obligatoriu motivul exportului și beneficiarul datelor exportate), etc sau manual obligatoriu când se face o procesare care presupun că datele să părăsească sistemul. Log-ul acestor operațiuni se poate vizualiza de către persoanele care au dreptul în urma interogării prin modulul GDPR. Chiar dacă în epica scenariului sesiunii demonstrative (pag. 67) nu a fost inclus acest aspect, s-a arătat un log complet de acces și operare atât pe document cât și pe utilizator din care să reiasă toate cele enumerate anterior’’. În urma evaluării răspunsului de mai sus, expertul tehnic a consemnat în cadrul raportului de specialitate nr. 8/1/6/19.04.2022, următoarele: ,,Administratorul (asumat ca utilizator) a avut acces la toate lucrările din sistem – inclusiv la date personale - fără a fi fost constrâns să prezinte sistemului, auditat, nevoia de a cunoaște datele ce Pagina 31 din 40

i-au fost dispuse – datele personale nu trebuiau să fie accesibile rolului de administrator, acest rol operând cu claritate în afara obligației de a procesa solicitări chiar dacă acestea vizau înrolarea. Furnizorul nu a înțeles cerința – anonimizarea datelor în ecranul de lucru presupune ”mascarea CNP/email” atât față de utilizatorul de la calculator (funcționarul care răspunde de lucrare) cât și față de orice altă persoană care ar putea avea acces sau ar putea vizualiza ecranul respectiv. – In aplicația EPRIM datele personale enumerate sunt afișate în clar astfel încât orice persoană care trece ocazional prin fața calculatorului poate privi datele digitale și la cine se referă ele chiar fără a accesa în mod explicit interfață. Capturarea explicită (și nu implicită – cum precizează furnizorul) a motivului accesului la date este menită să facă diferența dintre o accesare intenționată sau accidentală a informației prin precizarea contextului specific în care a apărut nevoia de acces. Concluzie: Din răspunsul la solicitarea de clarificări rezultă faptul că ofertantul prin soluția prezentată nu îndeplinește cerințele prevăzute la pag. 8 a Caietului de sarcini cu privire la: Respectarea, din punct de vedere funcțional, a reglementărilor europene în vigoare: Regulamentul (UE) nr. 679/2016, Art. 64, 74 și 78, cu privire la Protecția Datelor cu Caracter Personal, respectiv: (1) în aplicația EPRIM datele personale precum CNP, adresă email sunt afișate în clar, neanonimizate; (2) soluția propusă nu capturează explicit motivul accesului la datele personale. Cerință neîndeplinită’’. Față de cele de mai sus, Consiliul reține că la rubrica ,,Descrierea serviciilor solicitate’’ din caietul de sarcini se precizează faptul că ,,soluția de infrastructură digitală implementată va asigura: acoperirea completă a serviciilor publice digitalizate, ce implică în mod tradițional prezența cetățeanului la ghișeu; un mediu de lucru colaborativ între toate entitățile (autorități publice, instituții ș.a.m.d.) implicate în soluționarea petițiilor, gestiunea documentației de urbanism și furnizarea beneficiilor sociale către cetățeni, care au rol în eliberarea unor documente și dovezi necesare a fi incluse în dosarele cetățenilor și în aprobarea, monitorizarea și/sau suspendarea acordării beneficiilor sociale; transparență, predictibilitate și trasabilitate în operare; soluția implementată va reprezenta un instrument flexibil și adaptabil la nevoile instituționale specifice, care va permite eficientizarea proceselor de back-office și front-office și promovarea competenței și asumării responsabilității de către resursa umană în slujba cetățeanului, în acord cu Strategia pentru Consolidarea Administrației Publice 2014-2020 (SCAP)’’. De asemenea, se menționează că, din punct de vedere funcțional, soluția va respecta prevederile Regulamentului (UE) 2016/679/2016 privind protecţia persoanelor fizice în ceea ce priveşte prelucrarea datelor cu caracter personal şi privind libera circulaţie a datelor (RGPD), conform cărora ,,pseudonimizarea este operațiunea de prelucrarea Pagina 32 din 40

datelor cu caracter personal într-un asemenea mod încât acestea să nu mai poată fi atribuite unei anume persoane vizate fără a se utiliza informații suplimentare, cu condiția ca aceste informații suplimentare să fie stocate separat și să facă obiectul unor măsuri de natură tehnică și organizatorică care să asigure neatribuirea respectivelor date cu caracter personal unei persoane fizice identificate sau identificabile." Potrivit legislației comunitare, datele cu caracter personal sunt definite ca fiind ,,orice informații care se referă la o persoană fizică identificată sau identificabilă. Informațiile diferite care, adunate, pot duce la identificarea unei anumite persoane constituie și ele date cu caracter personal’’. Totodată, ,,datele cu caracter personal care au fost anonimizate, criptate sau pseudonimizate, dar pot fi utilizate pentru reidentificarea unei persoane rămân date cu caracter personal și sunt vizate de RGPD (Regulament general privind protecția datelor al Uniunii Europene)’. Pentru ca datele să fie cu adevărat anonimizate, anonimizarea trebuie să fie ireversibilă. În acest sens, RGPD protejează datele cu caracter personal indiferent de tehnologia utilizată pentru prelucrarea datelor respective, fiind neutru din punct de vedere tehnologic”. În corelare cu regulile de protecție a datelor cu caracter personal stabilite la nivelul Uniunii Europene, la rubrica ,,Entitatea de bază în contextul sistemului’’ din caietul de sarcini, pag. 21, s-au stabilit următoarele: ,,Persoana fizică identificată în mod unic prin Codul numeric personal (CNP) (…) constituie entitatea de bază a structurii digitale (…) În acest sens, este obligatorie implementarea principiilor de securitate progresivă bazate pe niveluri de încredere succesive care să permită utilizatorilor accesul la din ce în ce mai multe funcționalități pe măsură ce nivelul de încredere al contului lor crește (...) Platforma electronică de arhivare va fi complet auditabilă capturând în timp real accesul funcționarilor la documente, motivul accesării acestora, toate operațiunile efectuate cu documentul respectiv și detalii despre semnatarii documentului (...) Sistemul trebuie să respecte bunele practici, prevederile legale naționale și normativele europene (regulamente și directive) în materie de identitate electronică, protecția datelor personale și securitate cibernetică (...)’’. Altfel spus, soluția informatică, ce se urmărește a se achiziționa, gravitează în jurul unui singur element esențial și anume ,,cetățeanul’’, în numele căruia PRIMĂRIA MUNICIPIULUI ... urmărește ,,să eficientizeze activitatea funcționarilor publici și să îmbunătățească accesul cetățenilor la servicii online, asigurând fluidizarea circulării informațiilor și al documentelor specifice între cetățeni, instituție, intra/interinstituțional precum și creșterea gradului de trasabilitate la un înalt nivel de transparență decizională’’, după cum este menționat la pct. II.2.4.) Descrierea achiziției publice din anunțul de participare nr. CN…/ Pagina 33 din 40

…. Prin urmare, datele cu caracter personal ale fiecărui cetățean care va intra în sistem, trebuie protejate din toate punctele de vedere. Analizând propunerea tehnică a contestatoarei, Consiliul reține că la pag. 124 - ,,figura – 47 – Utilizatori după nivel – Sistem online de cunoaștere a utilizatorului (KYC) certificat’’, se regăsesc numele a 15 (cincisprezece) subiecți, precum și CNP –urile și adresele de email ale acestora (exemplu: … – CNP: …; email: …; … – CNP: …; email: …). De asemenea, Consiliul va lua în considerare că informațiile de mai sus, sunt prezentate inclusiv în cadrul sesiunii demonstrative (minutul: 36:07 – 36:19). Față de cele de mai sus, Consiliul nu va putea lua în considerare afirmațiile contestatoarei potrivit cărora ,,ecranele la care vă referiți (autoritatea contractantă) în sesiunea DEMO (min. 36:19) sunt de la administratorul soluției (cum se vede în colțul din dreapta jos) care a primit o cerere de înrolare în sistem și care are acces la această cerere (deci și la datele din ea)’’ în măsura în care ,,ecranele’’ în cauză sunt identice cu capturile de ecran prezentate în cadrul propunerii tehnice, cum este și firesc. Problema în cauză, nu este faptul că soluția tehnică a fost prezentată de către administratorul soluției, prin intermediului aplicației JITSI MEET, ci de faptul că în propunerea tehnică a contestatoarei, respectiv în cadrul sesiunii demonstrative, CNP-urile cetățenilor respectivi nu au fost protejate (pseudoanonimizate), astfel cum impunea caietul de sarcini, în consonanță cu regulamentele europene și naționale. Faptul că datele de identificare ale cetățenilor (CNP-urile) nu sunt protejate de către soluția propusă de contestatoare, este vizibil ca atare și la ,,pag. 123 – fig. 46’’; cu titlu de exemplu, fiind menționate următoarele: ,,Persoana fizică – … – CNP: …; email: …; Persoana fizică – … – CNP: …; email: …’’. În corelare cu cerința referitoare la protecția datelor personale se află și cea de la cap. Semnare și sigilare electronică din caietul de sarcini potrivit căreia ,,Infrastructura digitală trebuie să asigure nativ: (...) Platforma electronică de arhivare va fi complet auditabilă capturând în timp real accesul funcționarilor la documente, motivul accesării acestora, toate operațiunile efectuate cu documentul respectiv și detalii despre semnatarii documentului’’. Din analiza propunerii tehnice a contestatoarei, pe aspectele de mai sus, Consiliul constată că, atât în cadrul propunerii tehnice, cât și al sesiunii demonstrative, a rezultat că ,,funcționarul’’ din cadrul autorității contractante care a accesat informațiile și care avea ,,nivel de încredere: Scăzut’’, nu a prezentat motivul pentru care a putut accesa toate CNP- urile și adresele respective, contrar cerinței din caietul de sarcini de mai sus. Or, lipsa ,,motivului’’ precizat mai sus este contrară obligației contestatoarei de a demonstra, conform cerinței de la pct. 2.2.8 din Pagina 34 din 40

caietul de sarcini, că soluția ofertată respectă ,,principiul confidențialității datelor cu caracter personal și al accesului la date pe baza nevoii de a cunoaște (conformitate GDPR)’’, cu luarea în considerare a dispozițiilor art. 4 lit. k) din Legea nr. 363/2018 privind protecţia persoanelor fizice referitor la prelucrarea datelor cu caracter personal de către autorităţile competente în scopul prevenirii, descoperirii, cercetării, urmăririi penale şi combaterii infracţiunilor sau al executării pedepselor, măsurilor educative şi de siguranţă, precum şi privind libera circulaţie a acestor date, potrivit cărora se sancționează ,,accesul neautorizat la datele cu caracter personal’’. De altfel, referitor la motivul de respingere potrivit căruia ,,nu a fost observat nicăieri în soluția ofertată capturarea motivului pentru care datele sunt accesate’’, Consiliul reține că însăși contestatoarea recunoaște în adresa de răspuns la solicitarea de clarificări nr. SB/E/ 3272.322/30.03.2022, faptul că ,,în epica scenariului sesiunii demonstrative (pag. 67) nu a fost inclus acest aspect’’. Pe cale de consecință, Consiliul constată că față de propunerea tehnică a contestatoarei sunt incidente dispozițiile art. 134 alin. 5) din H.G. nr. 395/2016, conform cărora ,,În cazul în care comisia de evaluare solicită unui candidat/ofertant clarificări (...), potrivit dispoziţiilor art. 209 din Lege, iar (...) clarificările/completările solicitate sau clarificările/ completările transmise nu sunt concludente, oferta sa va fi considerată inacceptabilă’’, după cum, în mod corect, a consemnat și autoritatea contractantă în cadrul raportului procedurii nr. 13/ 13.05.2022. Un alt motiv de respingere, ca inacceptabilă, a propunerii tehnice a contestatoarei, astfel cum se regăsește acesta în comunicarea rezultatului procedurii nr. 36734/13.05.2022, se referă la faptul că ASOCIEREA .../..., inclusiv ca urmare a răspunsului la solicitarea de clarificări, ,,(...) nu îndeplinește cerințele prevăzute la pag. 20 a caietului de sarcini, respectiv nu clarifică aspectele sesizate în solicitarea de clarificări cu privire la modul în care interfața back office (EPRIM) îndeplinește cerințele privind interfața grafică. În sesiunea demonstrativă la min. 2.00.39 al înregistrării video, ofertantul nu demonstrează caracterul responsive pentru tema back office (EPRIM)’’. Referitor la motivul de mai sus, Consiliul va lua în considerare că la pct. 3.4.2.3.2 Cerințele funcționale ale infrastructurii digitale interinstituționale, interconectate și interoperabile de lucru – Interfața grafică din caietul de sarcini, pag. 20 – 21, se specifică următoarele: ,, (...) Având în vedere impactul semnificativ pe care îl are asupra ratei de adopție interfața grafică trebuie să fie modernă, ușor de înțeles și responsive. Standardele de design urmărite sunt cele specifice platformelor de tip social media, respectiv: (...) Caracterul responsive – indiferent de tipul de browser și de rezoluția dispozitivului pe care este afișat, conținutul trebuie să fie afișat fără erori, atât pe desktop, cât și Pagina 35 din 40

pe dispozitivele mobile. Toate interfețele, atât cele de front office, cât și cele de back office vor fi adaptate complet pentru dispozitivele mobile’’. Din analiza propunerii tehnice a contestatoarei, Consiliul reține că la pag. 81 – 82, se menționează următoarele: ,,Interfața grafică a sistemului informatic este modernă, construită folosind tehnologii de ultimă oră în domeniu, ușor de înțeles – cu denumiri de butoane/meniuri/interfețe care sunt auto-explicate astfel încât oricine le accesează își dă seama în context despre ceea ce urmează să obțină accesând acea zonă, și responsivă – se auto adaptează pentru o afișare cât mai naturală în funcție de dispozitivul de pe care este accesat/utilizat și respectă standardele de design astfel: (...) Caracterul responsiv în cadrul soluției ofertate conținutul este afișat fără erori, atât pe desktop cât și pe orice dispozitiv mobil, indiferent de tipul de browser și de rezoluția acestuia; practic soluția este independentă ca și utilizare de tipul de dispozitiv, sistem de operare, browser folosit’’. Privitor la cerința în cauză, ulterior analizării propunerii tehnice de mai sus, precum și derulării sesiunii demonstrative, în raportul de specialitate nr. 8/1/6/19.04.2022, elaborat de către expertul tehnic cooptat, se precizează următoarele: ,,Furnizorul justifică îndeplinirea cerinței (în toate etapele procedurii de atribuire, respectiv ofertare, sesiune demonstrativă) la strict ecrane din aplicația ePortal (ceea ce a determinat nevoia solicitării clarificării), în condițiile în care cerința vizează ca toate ecranele/temele prezentate să fie responsive. Reprezentații ofertantului argumentează în fapt motivul neîndeplinirii cerinței, afirmând pe parcursul sesiunii demonstrative că ”nu se poate prezenta pe mobil chiar totul”. Precizarea Ofertantului că „în Oferta tehnica depusă a exemplificat modul de îndeplinire a cerințelor apelând la exemple din ambele teme” nu se susține: toate capturile de ecran prezentate în Propunere tehnică – Matricea de conformitate la pag. 82 - 96 spre justificarea cerinței sunt ale interfeței/temei ePortal. Ofertantul nu a indicat prin clarificări unde anume în Propunerea tehnică se regăsesc informațiile care să demonstreze îndeplinirea cerinței de interfața back office (EPRIM). Informațiile prezentate cu privire la caracterul responsive al interfeței/temei back office EPRIM (recte, a afișa fără erori conținutul pe orice dispozitiv fix/mobil) nu se susțin, fapt relevat la min. 2:00:39 al înregistrării video (…) Prezentarea temei back office (EPRIM) în cadrul sesiunii demonstrative s-a dovedit a fi cu certitudine non-responsive, afișând cu erori doar fragmente ale unui ecran cuprinzător la nivelul rezoluției dispozitivului prezentate’’. Având în vedere informațiile de mai sus, prin adresa nr. 23352/25.03.2022, autoritatea contractantă a solicitat contestatoarei următoarele clarificări: ,,(…) Soluția tehnică propusă expune două interfețe distincte, fapt care rezultă nemijlocit din informațiile (și capturile de ecran) prezentate în anexa – Oferta tehnică – matrice de Pagina 36 din 40

conformitate, la pag. 83 – ePortal (destinată expunerii funcționalităților către cetățeni) și 147 – EPRIM (destinată expunerii funcționalităților către funcționari), informație confirmată și de reprezentanții ofertantului în cadrul sesiunii demonstrative prezentată comisiei de evaluare, la min. 11:06 din înregistrarea video. Vă rugăm să clarificați modul în care interfața back office (EPRIM) îndeplinește cerințele privind interfața grafică, raportat la oferta tehnică depusă și sesiune demonstrative susținută’’. La solicitarea de clarificări de mai sus, contestatoarea a răspuns prin adresa nr. SB/E/3272.322/30.03.2022, astfel: ,,Cele două interfețe ,,distincte’’ la care faceți referire nu sunt altceva decât implementarea a două teme responsive (bazate pe Bootstrap) pentru soluția ofertată: ambele teme sunt disponibile atât pentru zona ePortal cât și pentru EPRIM iar implicit fiecare produs are configurată una dintre ele ca fiind activă și poate fi schimbată de către funcționari (...)’’. Față de cele de mai sus, Consiliul va avea în vedere și cerințele de la rubrica Flexibilitatea și funcționalitatea sistemului din caietul de sarcini, pag. 36, potrivit cărora ,,Sistemul ofertat trebuie să fie bazat pe tehnologii web, astfel încât utilizatorul final, atât la nivel back-office (intranet) cât și la nivel front-office (servicii publice online), să nu fie dependent de o anumită tehnologie proprietară pentru a accesa serviciile’’. Potrivit literaturii de specialitate, paginile web sunt afișate pe mai multe tipuri de dispozitive, cum ar fi tablete, smartphone-uri, cărți electronice, calculatoare, fiecare dispozitiv având caracteristicile sale specifice: dimensiunea ecranului, rezoluție, putere CPU, capacitatea de memorie, printre altele. Specificul acestei tehnologii este faptul că permite ca paginile web, deși au un design unic sa poată fi vizualizată de pe orice dispozitiv. În ceea ce privește cerința privind caracterul responsive, din punct de vedere tehnic, înseamnă că un website este responsive dacă are capacitatea să-și adapteze layout-urile (designul) paginilor în funcție de mediul de vizionare (rezoluția ecranului – desktop, laptop, tableta, telefon), fără a suferi degradări majore, pentru a le oferi utilizatorilor o experiență excelentă de navigare. Pentru a asigura funcționalitățile de mai sus, printre limbajele de programare utilizate se află și Bootstrap, care permite codarea, într-un mod ordonat, a unor elemente cum ar CSS, HTML şi Java Script, pentru a crea structuri, ce pot fi refolosite cu comanda copy-paste sau dezvolta site-uri care repetă structuri de cod simple, cum ar fi butoane, formulare sau meniuri de navigare și carousel. Față de cele de mai sus, din analiza propunerii tehnice a contestatoarei a rezultat că aceasta a prezentat 2 (două) interfețe diferite, respectiv: interfața ePortal – figura 9, pag. 83 din matricea de conformitate, cu informații grupate în: Zone principale: 1, 2, 3; Zone de Pagina 37 din 40

interes mediu: 5, 6; Zone mai puțin importante: 7, 4 și interfața EPRIM – figura 102, pag. 182, în care se regăsesc informații aferente ,,solicitării depuse și înregistrate pe flux’’. Or, în aceste condiții, este evident că este vorba despre 2 (două) interfețe distincte care au configurații diferite (cel puțin în zonele de informații), în cadrul propunerii tehnice existând mențiunea ,,DataSheet- ul ePortal atașat ofertei; DataSheet-ul EPRIM atașat ofertei’’, astfel încât informațiile conținute nu vor fi integrate și prezentate uniform, fapt ce va conduce la o serie de impedimente în accesarea acestora pe dispozitivele mobile, cum ar fi afișarea într-un mod incorect a acestora. De altfel, faptul că informațiile nu sunt integrate, ca urmare a utilizării unor interfețe distincte, este recunoscut chiar de către ASOCIEREA .../... în cadrul contestației în cauză, aceasta utilizând sintagma ,,atât interfața ePortal, cât și interfața EPRIM’’, aspect care conduce la nerespectarea cerinței aferente din caietul de sarcini, respectiv a dispozițiilor art. 123 alin. 1) din H.G. nr. 395/2016, conform cărora ,,Ofertantul elaborează oferta în conformitate cu prevederile documentaţiei de atribuire (...)’’. Un alt motiv pentru care propunerea tehnică a contestatoarei a fost respinsă se referă la faptul că aceasta ,,nu îndeplinește cerințele prevăzute la pag. 21 a caietului de sarcini cu privire la conversia automata a fișierelor în format PDF (…)’’. Față de cele de mai sus, Consiliul reține că la rubrica ,,Funcționalități ce vor fi accesate de cetățeni’’ din caietul de sarcini, pag. 21, se solicită și cea privind ,,Conversia automata a fișierelor în format PDF’’. După analizarea propunerii tehnice a contestatoarei și derularea sesiunii demonstrative, prin adresa nr. 23352/25.03.2022, autoritatea contractantă a solicitat acesteia clarificări privind modul de îndeplinire a cerinței respective deoarece ,,funcționalitatea de conversie a fișierelor nu există în interfața front office ePortal; funcționalitatea de conversie a fișierelor nu este realizată automat în interfața back office (…)’’. La solicitarea de clarificări de mai sus, contestatoarea a răspuns prin adresa nr. SB/E/3272.322/30.03.2022, astfel: ,,Cerința de conversie automată în pdf. este una anormală ce presupune generarea unei versiuni alterate a documentului original (...) nu se poate vedea ca opțiune din interfață’’. Or, în situația în care în cazul de față este vorba în esență despre ,,un sistem de management al documentelor’’, care trebuie să aibă un ,,caracter responsiv’’, atunci funcționalitatea în cauză trebuia să fie accesibilă din interfață, astfel încât ,,cetățeanul/funcționarul utilizator’’ să-l poată coverti într-un format pdf. dacă este cazul, indifferent de dispozitivul de pe care accesează fișierul respectiv, comuter, tablet sau smartphone. Pagina 38 din 40

Prin urmare, și cu această ocazie, având în vedere modul în care contestatoarea a răspuns la solicitările de clarificări ale autorității contractante, față de propunerea tehnică a acesteia sunt incidente dispozițiile art. 134 alin. 5) din H.G. nr. 395/2016, citate anterior, în sensul respingerii acesteia ca inacceptabilă, după cum, în mod corect, respectând prevederile art. 137 alin. 1) din cadrul aceluiași act normativ (,,Comisia de evaluare are obligația de a respinge ofertele inacceptabile (...)’’ a consemnat și autoritatea contractantă în cadrul raportului procedurii nr. 13/13.05.2022. La acest moment, având în vedere că până în prezent au fost deja analizate 3 (trei) motive întemeiate de respingere a ofertei contestatoarei, prin raportare la principiul celerității, consacrat la art. 15 alin. 1) din Legea nr. 101/2016, Consiliul nu va mai proceda la analiza celorlalte întrucât caracterul inacceptabil/neconform al ofertei contestatoarei nu mai poate fi schimbat. Totodată, Consiliul iterează dispozițiile art. 26 alin. (9) din Legea nr. 101/2016, ,,Consiliul poate obliga, la cerere, partea în culpă, la plata cheltuielilor efectuate pentru soluţionarea contestaţiei. Cuantumul, detalierea şi documentele doveditoare ale cheltuielilor efectuate sunt prezentate în cerere, care trebuie depusă înainte de pronunţarea deciziei de soluţionare a contestaţiei’’. Având în vedere că, potrivit motivării anterioare, prezenta contestație a fost respinsă, Consiliul va respinge, pe cale de consecință și solicitarea contestatoarei de ,,obligarea autorității contractante la plata cheltuielilor generate de soluționarea acestei contestații”. Față de cele de mai sus, în temeiul art. 26 alin. (6) din Legea nr. 101/2016, Consiliul va respinge, ca nefondată, contestația formulată de către ..., în calitate de lider al ASOCIERII .../..., în contradictoriu cu autoritatea contractantă MUNICIPIUL ... și va dispune continuarea procedurii de atribuire în cauză. Prezenta decizie este obligatorie pentru părți, în conformitate cu dispozițiile art. 28 alin. (1) din Legea nr. 101/2016 și poate fi atacată cu plângere în temeiul art. 29 din același act normativ. Pentru cele constatate, în baza legii și a mijloacelor de probă aflate la dosar, CONSILIUL DECIDE: Respinge, ca nefondată, contestația formulată de către ..., în calitate de lider al ASOCIERII .../..., cu sediul în comuna …, satul … nr. …, județul …, în contradictoriu cu autoritatea contractantă MUNICIPIUL ..., cu sediul în municipiul …, str. … nr. …, județul …. Pagina 39 din 40

Pe cale de consecință, respinge solicitarea contestatoarei de ,,obligarea autorității contractante la plata cheltuielilor generate de soluționarea acestei contestații”. Obligatorie. Împotriva prezentei decizii, se poate formula plângere, în termen de 10 zile de la comunicare, conform dispozițiilor art. 29 din Legea nr. 101/2016.

PREȘEDINTE, MEMBRU, MEMBRU, … … … … … …

Redactată în 4(patru) exemplare originale, conține … (…) pagini. Pagina 40 din 40