# Contracte cu furnizorii IT: reglementarea clară a obligațiilor de securitate

> Ce ar trebui să reglementeze un contract cu agenția, hosterul sau furnizorul IT despre securitate: actualizări, notificări, jurnale, accese, ieșire.

Sursa: https://phpsos.de/ro/blog/dienstleistervertrag-sicherheit/  
Stadiu: 25.10.2026  
Furnizor: PHP SOS, Asistență de urgență PHP și securitatea serverelor. Ajutor imediat pe WhatsApp: https://wa.me/491736494914?text=Bun%C4%83%20ziua%2C%20PHP%20SOS%2C%20avem%20nevoie%20de%20ajutor%20cu%20serverul%20nostru%20PHP.%20Firma%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**Pe scurt:** Un contract cu un furnizor IT nu ar trebui să menționeze securitatea doar în treacăt, ci să o reglementeze concret: cine actualizează ce componente, în ce termen și cu ce dovadă, cum este informată compania despre vulnerabilități critice, cine participă la un incident, cum sunt păstrate jurnalele și administrate accesele și ce se întâmplă la ieșire. Această pagină oferă indicații generale și nu reprezintă consiliere juridică; contractele le verifică un avocat.

## Întrebarea pe care a pus-o PHP2Shell: cine este responsabil?

La 21.10.2026, la ora 16:00, ora Germaniei, proiectul PHP a publicat patch-urile. BSI (Oficiul Federal German pentru Securitatea Informațiilor) a recomandat actualizare imediată sau, acolo unde nu a fost posibil, scoaterea temporară a serverelor web din rețea. În multe companii a început după aceea nu munca, ci căutarea responsabilului. Agenția a trimis la furnizorul de hosting, furnizorul de hosting la contract, iar în contract scria „mentenanță după efort”.

Asemenea goluri în contract nu sunt un caz izolat. Multe contracte cu agenții și furnizori au fost încheiate când era vorba despre construirea unui site, nu despre operarea lui sigură de-a lungul anilor. O vulnerabilitate critică în mediul de execuție PHP, care nu privește nici CMS-ul, nici codul aplicației, cade atunci ușor între toate scaunele.

## Ce ar trebui să reglementeze în materie de securitate un contract cu furnizorul IT

Prezentarea următoare enumeră punctele care s-au dovedit importante în practică. Nu înlocuiește o verificare juridică, dar ajută la recunoașterea golurilor din contractul existent.

| Punct de reglementare | Ce ar trebui consemnat | Legătura cu PHP2Shell |
|---|---|---|
| Amploarea prestației | Ce straturi sunt întreținute: sistem de operare, mediu PHP, server web, CMS, pluginuri, cod propriu | Mediul PHP lipsea adesea din enumerare |
| Termene de actualizare | Eșalonate după gravitate, cu regulă de excepție pentru urgențe | Vulnerabilitate critică cu CVSS v4.0 9.2 |
| Repornire și dovadă | Actualizările se consideră încheiate abia după repornirea tuturor proceselor, cu dovadă scrisă | Fișierele noi singure nu închid vulnerabilitatea |
| Informare | Notificare activă la vulnerabilități critice, cu evaluare și plan | Mulți clienți au trebuit să întrebe singuri |
| Participare la incidente | Sprijin la analiză, salvare, restaurare, persoană de contact | Căutarea urmelor după patch |
| Jurnale | Tip, păstrare, predare la cerere | Presa de specialitate a sfătuit salvarea jurnalelor de la 20.10. |
| Accese | Conturi personale, autentificare în doi factori, lista tuturor accesărilor | Cine avea, de fapt, acces? |
| Subcontractanți | Cine mai participă, informare la schimbare | Furnizorul de hosting al furnizorului de hosting |
| Sfârșitul vieții software-ului | Avertizare din timp înainte de sfârșitul suportului, plan de migrare | PHP 8.2 se încheie la 31.12.2026 |
| Ieșire | Predarea datelor, a documentației și a accesărilor, retragerea drepturilor | Schimbare după un incident |

## Termene și dovezi: punctele care contează cel mai mult

Termenele sunt miezul. O formulare precum „în timp util” nu ajută în caz de urgență. Convenți termene separat pe gravitate și stabiliți după ce se măsoară gravitatea, de exemplu după încadrarea făcută de producător sau de BSI. Pentru situații excepționale ar trebui să se aplice o regulă de urgență: cine este disponibil, cine decide dacă un sistem este scos temporar din rețea și cum se facturează efortul suplimentar.

La fel de importantă este dovada. La PHP2Shell, numărul de versiune afișat spunea adesea puțin, deoarece distribuțiile și furnizorii de hosting aplică corecțiile ca backport. O dovadă solidă indică nivelul pachetului, momentul instalării și repornirea tuturor proceselor PHP. Ce informații contează exact descrie [Cum vă întrebați furnizorul de hosting despre starea patch-urilor](https://phpsos.de/ro/ratgeber/hoster-patch-status-erfragen/). Includeți aceste informații ca conținut obligatoriu în contract.

> **Sfat:**
> Cereți furnizorului o matrice de sarcini pentru contract: un rând pentru fiecare componentă, o coloană pentru fiecare sarcină, în fiecare celulă un nume. Golurile ies atunci imediat în evidență, cu mult înainte de următorul avertisment.

## Accese, subcontractanți și ieșire

Furnizorii au nevoie de accese și tocmai acestea sunt o cale frecventă de atac. Reglementați ca fiecare persoană să primească un cont propriu, ca autentificarea în doi factori să fie obligatorie acolo unde tehnica o permite și ca dumneavoastră să puteți cere oricând o listă actuală a tuturor accesărilor. Angajații plecați ai furnizorului trebuie eliminați la timp din toate sistemele.

Dacă furnizorul lucrează el însuși cu parteneri, de exemplu un centru de date sau o echipă specializată de criminalistică, ar trebui să știți acest lucru. Dacă unul dintre acești parteneri prelucrează date cu caracter personal, se adaugă obligații privind protecția datelor. Mai multe în articolul [Prelucrarea datelor în numele operatorului, când furnizorii accesează serverele](https://phpsos.de/ro/blog/auftragsverarbeitung-serverzugriff/).

Ieșirea este cel mai des uitată la încheierea contractului. Consemnați că la încheierea contractului datele, configurarea, documentația și datele de acces sunt predate integral, toate accesele furnizorului sunt retrase și acest lucru este confirmat în scris. Tocmai după un incident, o schimbare ordonată este altfel dificilă.

## Verificarea contractelor existente: cum procedați

Nu trebuie să renegociați toate contractele. Pentru început este suficient un flux pragmatic:

1. Adunați toate contractele cu agenții, furnizori de hosting și furnizori IT care privesc site-uri sau servere.
2. Comparați fiecare contract cu tabelul de mai sus și marcați punctele deschise.
3. Abordați în scris, la furnizor, cele mai importante goluri, începând cu amploarea prestației, termenele și dovada.
4. Consemnați rezultatele ca acord adițional și lăsați-le să fie verificate juridic.
5. Preluați matricea de sarcini în planul de urgență.

Pentru conducere, acest pas este și o chestiune de diligență. Cine reglementează clar responsabilitățile și documentează deciziile stă mai bine dacă se pun ulterior întrebări. Context oferă [Răspunderea conducerii în cazul vulnerabilităților de securitate IT](https://phpsos.de/ro/compliance/geschaeftsfuehrer-haftung/). Împărțirea tipică a sarcinilor la serverele administrate o descrie [Server administrat: clarificarea responsabilității](https://phpsos.de/ro/server/managed-server/).

## Cum ajută PHP SOS concret?

- Citim contractele și descrierile de prestații existente din perspectivă tehnică și marcăm ce componente și sarcini lipsesc.
- Elaborăm o matrice de sarcini pentru toate site-urile și serverele, pe care o puteți conveni cu furnizorii dumneavoastră.
- Formulăm cerințele tehnice privind termene, dovezi și căi de notificare, pe care avocatul dumneavoastră le poate prelua în contract.
- Acolo unde nu este responsabil nimeni, preluăm noi înșine sarcinile printr-un [contract de mentenanță de securitate](https://phpsos.de/ro/leistungen/security-wartungsvertrag/) cu amploare descrisă clar.

**Concluzie:** Un contract bun nu previne o vulnerabilitate de securitate, dar previne pierderea timpului, în caz de urgență, cu întrebarea despre responsabil. Această pagină este informație generală și nu reprezintă consiliere juridică.


## Întrebări frecvente

**Trebuie un furnizor IT să aplice actualizări de securitate fără comandă?**  
Depinde de contract. Fără o reglementare clară, este adesea disputat dacă actualizările fac parte din prestația datorată. De aceea contractul ar trebui să stabilească explicit cine actualizează ce componente și în ce termen. Pentru evaluarea juridică în cazul individual este competent un avocat.

**Am nevoie în plus de un AVV?**  
Dacă furnizorul prelucrează în numele dumneavoastră date cu caracter personal sau poate accesa astfel de date, este necesar de regulă un contract de prelucrare a datelor (AVV) conform art. 28 RGPD. Acesta nu înlocuiește contractul de prestări, ci îl completează. Clarificați aceasta cu responsabilul dumneavoastră cu protecția datelor.

**Ce termene pentru actualizările de securitate sunt uzuale?**  
Nu există valori fixe. Utilă este o eșalonare în funcție de gravitate, de exemplu termene separate pentru vulnerabilități critice, ridicate și restul. Important este ca termenele să fie scrise și să conțină o regulă de excepție pentru urgențe precum PHP2Shell.

**Ce se întâmplă cu accesele când contractul se încheie?**  
Contractul ar trebui să reglementeze aceasta: restituirea sau ștergerea datelor, predarea datelor de acces și a documentației, retragerea tuturor accesărilor furnizorului și o confirmare în acest sens.

## Surse

- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [BSI](https://www.bsi.bund.de/)
- [php.net: versiuni acceptate](https://www.php.net/supported-versions.php)