Un contract cu furnizorul IT adaptat cerințelor NIS2 nu ar trebui să se limiteze la o declarație de conformitate, o clauză generală de securitate și un indicator lunar de disponibilitate. Riscurile asociate serviciului trebuie transpuse într-o delimitare clară a responsabilităților, niveluri măsurabile ale serviciului, un flux rapid de informații despre incidente, acces la dovezi și un plan de ieșire aplicabil. Punctul de plecare îl reprezintă criticitatea serviciului și distribuția reală a controlului între părți. Numai pe această bază pot fi stabilite măsurile de securitate, termenele, drepturile de verificare și obligațiile de notificare care trebuie incluse în contract.
Contractul ca mecanism de control al riscului
Revizuirea contractelor nu ar trebui să înceapă de la un model standard de clauză de securitate, ci de la cartografierea dependențelor organizației față de furnizori. Pentru fiecare furnizor trebuie identificate serviciile, procesele, sistemele, datele și locațiile implicate, urmate de evaluarea consecințelor indisponibilității sau ale unui incident de securitate. Prioritate au dependențele a căror perturbare poate opri activitatea, limita îndeplinirea obligațiilor sau îngreuna gestionarea unui incident. Prin urmare, nu toate serviciile IT necesită același nivel de protecție contractuală.
Clasificarea criticității furnizorului ar trebui să rezulte din analiza impactului asupra activității și din evaluarea riscurilor, nu doar din valoarea contractului. O atenție deosebită necesită serviciile pentru care întreprinderea rămâne responsabilă de continuitate și de gestionarea incidentelor, în timp ce furnizorul controlează informațiile tehnice, jurnalele de evenimente, copiile de siguranță sau mediul necesar restaurării serviciului. Organizația trebuie, de asemenea, să desemneze un proprietar al riscului asociat furnizorului. În lipsa acestui rol, responsabilitățile achizițiilor, IT-ului, funcției de securitate și proprietarului procesului rămân dispersate.
Conținutul contractului trebuie proiectat pornind de la scenarii de perturbare: indisponibilitatea serviciului, un atac, pierderea sau deteriorarea datelor, indisponibilitatea personalului furnizorului, întreruperea lanțului de subcontractanți și încetarea colaborării. Pentru fiecare scenariu trebuie definite acțiunile părților, responsabilitățile, fluxul de informații și condițiile de restaurare. Din aceste decizii rezultă nivelurile de disponibilitate, timpii de răspuns și de restabilire, documentația necesară și drepturile de verificare.
O declarație privind asigurarea unei disponibilități ridicate nu stabilește cât timp poate rămâne indisponibil un sistem de control al producției, din ce moment se măsoară întreruperea sau cine furnizează datele necesare evaluării incidentului. De asemenea, nu garantează accesul la copii ale jurnalelor de evenimente, la informații despre subcontractanți sau la datele necesare transferului securizat al serviciului. Aceste lacune devin vizibile, de regulă, în timpul unei întreruperi, când delimitarea responsabilităților nu mai poate rămâne implicită.
Trimiterea la NIS2 sau la cerințele KSC aplicabile ar trebui să încheie analiza riscurilor și a responsabilităților, nu să înlocuiască prevederile operaționale ale contractului. Contextul managerial mai larg este prezentat în materialul NIS2 pentru companiile de producție: cui i se aplică, ce obligații introduce și cum trebuie pregătită organizația fără a reduce subiectul exclusiv la IT. Modificările contractuale trebuie adaptate de fiecare dată rolului organizației, criticității serviciului și distribuției efective a controlului între părți.
Domeniul serviciului și delimitarea responsabilităților
Responsabilitățile trebuie descrise într-o anexă tehnică, nu lăsate la nivelul unei definiții generale a obiectului contractului. Anexa ar trebui să indice activele și mediile deservite, categoriile de date, locațiile de prelucrare și de furnizare a serviciilor, interfețele, programul de suport și excluderile. Fără aceste informații nu se poate stabili fără echivoc unde se încheie responsabilitatea furnizorului, ce eveniment declanșează măsurarea SLA și cine securizează componentele aflate la interfața dintre sisteme.
Măsurile de securitate ar trebui descrise prin rezultatul urmărit, partea responsabilă și dovada executării, iar detaliile tehnologice să fie păstrate în documentația tehnică supusă controlului. Această abordare reduce riscul ca prevederile contractuale să devină rapid depășite. Catalogul standard de controale al furnizorului poate fi acceptat numai după compararea sa cu riscurile serviciului concret și după tratarea lacunelor identificate. Matricea responsabilităților trebuie să diferențieze proprietarul controlului, executantul și partea autorizată să aprobe derogările.
| Domeniu | Client | Furnizor sau subcontractant | Dovadă necesară |
|---|---|---|---|
| Acces și configurare | Aprobă rolurile și cerințele | Acordă, înregistrează și revocă drepturile; menține configurația | Evidența drepturilor, revizuiri, istoricul modificărilor |
| Actualizări, vulnerabilități și protecție împotriva programelor malware | Stabilește ferestrele acceptate și excepțiile | Monitorizează, evaluează și implementează măsurile de protecție | Raport de vulnerabilități, registrul actualizărilor și al excepțiilor |
| Înregistrarea evenimentelor | Definește conținutul și disponibilitatea necesară a jurnalelor | Colectează, protejează și pune la dispoziție jurnalele | Eșantion de jurnale, confirmarea perioadei de păstrare și a controlului accesului |
| Copii de siguranță și restaurare | Definește cerințele de continuitate | Realizează copiile și testele de restaurare | Raport privind efectuarea copiilor și testul de restaurare |
| Ștergerea datelor | Aprobă domeniul și termenul | Șterge datele și copiile acestora conform metodei convenite | Proces-verbal sau confirmare a ștergerii |
Dacă mediul este administrat de furnizor, contractul trebuie să reglementeze suplimentar accesul privilegiat: separarea responsabilităților, metoda de autentificare, evidența activităților administrative și revocarea imediată a drepturilor după schimbarea rolului sau încetarea colaborării. O simplă declarație privind efectuarea copiilor de siguranță este insuficientă dacă clientul nu știe cine le criptează, unde sunt păstrate, cine le poate restaura și ce document confirmă rezultatul testului de restaurare.
Furnizorul ar trebui să mențină o listă actualizată a subcontractanților care influențează serviciul, împreună cu descrierea rolurilor și a locațiilor de prelucrare, și să le impună cerințe cel puțin echivalente celor convenite cu clientul. Contractul trebuie să stabilească ce modificări necesită aprobare prealabilă și pentru care este suficientă notificarea urmată de reevaluarea riscului. Certificarea unui sistem de management poate sprijini evaluarea, dar nu înlocuiește responsabilitățile definite pentru serviciul concret. Această relație este analizată în materialul NIS2 și SR EN ISO 27001: ce oferă certificatul și ce mai lipsește pentru conformitatea cu KSC.
Clauze de securitate care pot fi verificate
O clauză de securitate devine verificabilă numai dacă definește rezultatul așteptat, domeniul de aplicare, frecvența activității, modul de confirmare a executării și procedura de gestionare a derogărilor. Formulări precum „în conformitate cu bunele practici” sau „cu diligența necesară” pot completa cerințele, dar nu permit evaluarea obiectivă a modului în care furnizorul și-a îndeplinit obligația. Pentru fiecare control trebuie stabilite proprietarul cerinței, perioada de păstrare a dovezilor și partea autorizată să accepte o excepție.
Cerințele construite în acest mod ar trebui să acopere cel puțin gestionarea vulnerabilităților și a actualizărilor, menținerea configurațiilor securizate, criptarea, protejarea și păstrarea jurnalelor de evenimente, realizarea copiilor de siguranță, testele de restaurare, managementul schimbărilor și controlul accesului. Frecvența revizuirii drepturilor, a testelor de restaurare și a raportării, precum și termenele de remediere a vulnerabilităților trebuie stabilite în funcție de riscul serviciului. Acestea nu ar trebui uniformizate pentru toți furnizorii.
Fiecare derogare trebuie înscrisă într-un registru, împreună cu justificarea, termenul de eliminare, proprietarul riscului și controalele compensatorii. Acceptarea sa necesită evaluarea faptului că aceste controale reduc într-adevăr riscul la nivelul acceptat de organizație.
O prevedere privind efectuarea periodică a copiilor de siguranță rămâne incompletă dacă nu precizează datele și sistemele incluse, perioada de păstrare, protecția împotriva modificării sau ștergerii, regulile de acces și frecvența testelor de restaurare. De asemenea, trebuie definit modul în care furnizorul raportează o copie sau un test nereușit, cine aprobă acțiunile corective și ce raport confirmă închiderea lor. În mod similar, obligația de remediere a vulnerabilităților necesită stabilirea metodei de clasificare, a termenelor de răspuns proporționale cu riscul, a regulilor de amânare a actualizărilor și a modului de documentare a măsurilor temporare.
Dovezile trebuie împărțite între cele transmise periodic și cele puse la dispoziție la cerere. Prima categorie poate include sinteze ale vulnerabilităților, rapoarte privind actualizările, rezultatele testelor de restaurare și confirmările revizuirilor de acces. După un incident, o schimbare semnificativă sau identificarea unei abateri pot fi necesare rezultatele detaliate ale testelor, jurnalele de evenimente, istoricul modificărilor, registrul excepțiilor și planul de acțiuni corective. Domeniul, proprietarii și perioada de păstrare a acestor materiale ar trebui corelate cu regulile prezentate în materialul Documentația NIS2 și KSC înaintea controlului: ce politici, registre și dovezi sunt necesare în mod real.
Dreptul de verificare trebuie să fie gradual și aplicabil inclusiv în relația cu un furnizor de servicii cloud. Primul nivel poate include analiza documentelor și o reuniune de clarificare; nivelul următor poate presupune rapoarte independente sau teste convenite, iar auditul la fața locului poate fi rezervat situațiilor de risc ridicat, incidentelor semnificative ori lipsei unor dovezi credibile. Contractul trebuie să reglementeze termenele, confidențialitatea, domeniul tehnic și modul de tratare a constatărilor, fără a acorda clientului drepturi imposibil de exercitat într-un mediu partajat.
SLA pentru reziliență, nu doar pentru disponibilitate
SLA-ul ar trebui să rezulte din analiza impactului asupra activității, nu din catalogul standard de parametri al furnizorului. Proprietarul procesului stabilește mai întâi durata tolerabilă a întreruperii, pierderea de date acceptabilă și efectele indisponibilității asupra producției, serviciilor pentru clienți, decontărilor și obligațiilor legale. Numai apoi se stabilesc obiectivele de restaurare, cerințele pentru serviciul alternativ și modul de lucru în situații de urgență, precum și prioritățile solicitărilor. Un indicator lunar de disponibilitate nu arată dacă o singură întrerupere produsă într-un moment critic va bloca procesul mai mult decât poate accepta organizația.
Pe lângă disponibilitate, contractul trebuie să stabilească timpul de confirmare a solicitării, timpul de începere a diagnosticării, timpul de restabilire a funcției și timpul de eliminare a cauzei, precum și frecvența comunicărilor, nivelurile de escaladare și modul de intervenție în afara programului standard. Timpul de răspuns nu este identic cu timpul de restaurare, iar activarea unei soluții alternative nu înseamnă eliminarea completă a problemei. Separarea acestor concepte permite echipei operaționale să știe când își poate relua activitatea, iar proprietarului serviciului să stabilească momentul în care furnizorul finalizează analiza cauzelor și implementează o acțiune corectivă durabilă.
În cazul unui sistem care controlează un proces de producție, un incident critic poate necesita escaladare imediată și comunicare continuă până la activarea modului de urgență. Aceeași defecțiune într-un mediu de instruire poate primi o prioritate mai redusă. Clasificarea trebuie, prin urmare, să se bazeze pe impactul asupra activității, nu exclusiv pe descrierea tehnică a erorii. Dacă organizația dispune de date istorice credibile, stabilirea pragurilor ar trebui să țină cont de timpii reali de răspuns și restaurare, de nivelurile de disponibilitate și de numărul incidentelor repetitive.
Mecanismul de măsurare trebuie să indice sursa datelor, fusul orar, momentul pornirii și opririi cronometrului, intervalele convenite de furnizare a serviciului, ferestrele de mentenanță și regulile de modificare a categoriei incidentului. Excluderile din măsurare trebuie definite într-o listă închisă și verificabilă. Acestea nu pot include evenimente aflate în sfera de responsabilitate a furnizorului. Coerența dintre aceste prevederi și capacitatea operațională reală poate fi evaluată în cadrul unui Audit NIS2 într-o companie de producție – cum se verifică dacă organizația este pregătită pentru noile obligații.
Creditele de servicii și compensațiile simbolice nu restaurează procesul și nu limitează consecințele unei întreruperi. Mai relevante sunt obligația de a prezenta un plan de remediere, escaladarea la nivel managerial, testele suplimentare de reziliență și dreptul de încetare a contractului în cazul nerespectării persistente sau repetate a nivelurilor convenite. Sancțiunea financiară poate consolida răspunderea, dar nu înlocuiește mecanismele de restabilire a serviciului, eliminare a cauzelor și prevenire a incidentelor recurente.
Incidentul și obligațiile de notificare
Contractul trebuie să oblige furnizorul să notifice fără întârziere orice eveniment care poate afecta serviciul, datele, continuitatea activității sau securitatea clientului. Notificarea inițială nu ar trebui condiționată de confirmarea completă a cauzei, a amplorii prejudiciului sau a încadrării juridice a evenimentului. Termenul contractual trebuie stabilit cu o marjă care să îi permită clientului să efectueze propria evaluare și să respecte eventualele termene externe. Acesta ar trebui să rezulte din criticitatea serviciului și din disponibilitatea unui punct de contact permanent, nu din comoditatea organizatorică a părților.
Fluxul informațional trebuie împărțit în avertizarea inițială, actualizările de situație, raportul ulterior incidentului și analiza cauzei-rădăcină. Pentru fiecare etapă trebuie stabilite informațiile necesare, canalul autorizat, destinatarii, frecvența actualizărilor și regulile de escaladare în lipsa contactului. Prima comunicare ar trebui să includă cel puțin momentul detectării, activele și serviciile afectate, impactul estimat, măsurile întreprinse, indicatorii tehnici disponibili, evaluarea riscului de propagare și termenul următoarei actualizări. Lista persoanelor de contact trebuie să includă înlocuitori și să fie testată periodic, inclusiv în afara programului standard.
Dacă furnizorul detectează trafic neobișnuit într-un mediu care găzduiește o aplicație critică, acesta ar trebui să avertizeze clientul înainte de a stabili definitiv dacă a avut loc o compromitere. Clientul își activează propriul proces de management al incidentelor, desemnează persoana responsabilă de decizii, implică echipa de răspuns și, după caz, asigurătorul, și stabilește cine aprobă notificarea externă și comunicarea cu clienții. Furnizorul conservă jurnalele și urmele tehnice convenite și sprijină analiza, limitarea efectelor și stabilirea amplorii evenimentului, fără a prelua responsabilitatea de reglementare a clientului.
Clauzele trebuie să stabilească și regulile privind păstrarea și punerea la dispoziție a dovezilor, protejarea integrității acestora, documentarea deciziilor și pregătirea datelor necesare notificărilor și analizei ulterioare a cauzei-rădăcină. Termenele, destinatarii și conținutul notificărilor externe trebuie verificate de fiecare dată în raport cu cadrul juridic actual, statutul organizației și natura evenimentului. Registrele notificărilor, deciziilor, escaladărilor și acțiunilor trebuie corelate cu materialul Documentația NIS2 și KSC înaintea controlului: ce politici, registre și dovezi sunt necesare în mod real, iar calendarul de adaptare — cu materialul Implementarea NIS2 după înscrierea în registrul KSC – plan de acțiune până la 3 aprilie 2027.
Implementare, monitorizare și ieșire controlată
Semnarea actului adițional nu încheie procesul de management al furnizorului. Proprietarul contractului trebuie să efectueze revizuiri periodice ale rezultatelor SLA, incidentelor, derogărilor, acțiunilor corective, modificărilor privind subcontractanții și actualității dovezilor care confirmă îndeplinirea cerințelor. Baza monitorizării o reprezintă un registru al contractelor care include cel puțin data reînnoirii, proprietarul, criticitatea serviciului și stadiul convenirii măsurilor de securitate. Declarația de conformitate nu înlocuiește rapoartele, rezultatele testelor sau înregistrările care demonstrează executarea obligațiilor.
Înainte de reînnoirea contractului sau de o modificare semnificativă a serviciului trebuie reevaluate criticitatea, dependențele tehnice și de proces, concentrarea serviciilor la un singur furnizor, aplicabilitatea măsurilor de securitate și posibilitatea migrării către o soluție alternativă. O astfel de revizuire permite stabilirea faptului dacă este suficient un act adițional sau dacă trebuie inițiată o nouă procedură de achiziție. Dacă un furnizor strategic refuză auditul sau modificarea condițiilor, organizația ar trebui să documenteze lacuna și să aleagă între implementarea unui control compensatoriu, acceptarea formală a riscului rezidual și schimbarea furnizorului.
Planul de ieșire trebuie să fie aplicabil înainte de denunțarea contractului. Acesta trebuie să acopere returnarea și transferul datelor într-un format utilizabil, asistența pentru migrare, menținerea continuității în perioada de tranziție, revocarea accesurilor, ștergerea copiilor și confirmarea îndeplinirii acestor activități. În același timp, trebuie păstrate înregistrările necesare în scopuri juridice, probatorii și de audit. Un test practic îl reprezintă restaurarea de probă a datelor la un alt furnizor, împreună cu verificarea caracterului complet, a duratei migrării și a posibilității de dezactivare a conturilor existente.
Actualizarea portofoliului de contracte trebuie să înceapă cu serviciile care au cel mai mare impact asupra activității, iar lacunele trebuie prioritizate în funcție de consecințe și urgență. Eficacitatea mecanismelor adoptate ar trebui verificată printr-un exercițiu de gestionare a incidentelor și prin auditarea unui eșantion de dovezi. Rezultatele revizuirilor SLA, incidentelor, derogărilor, acțiunilor corective și testelor de ieșire vor arăta dacă cerințele funcționează în practică sau au rămas simple prevederi contractuale.
Domeniul evaluării poate fi corelat cu materialul Audit NIS2 într-o companie de producție – cum se verifică dacă organizația este pregătită pentru noile obligații. Obligațiile organizației trebuie stabilite ținând cont de statutul acesteia, analizat în materialul Directiva NIS2 – cui i se aplică și ce companii trebuie să îndeplinească noile cerințe?
Masz pytania? Porozmawiajmy.
Bezpłatna konsultacja – bez zobowiązań.
