NIS2 cu resurse interne sau cu o firmă de implementare? Comparație între cost, timp și risc

Decizia de a aborda NIS2 cu resurse interne sau cu sprijinul unei firme de implementare nu se reduce la compararea onorariului consultantului cu timpul alocat de echipa proprie. Rezultatul proiectului depinde de sfera obligațiilor, disponibilitatea decidenților, calitatea datelor despre procese și resurse, precum și de capacitatea organizației de a menține ulterior măsurile adoptate. Varianta aparent cea mai ieftină poate deveni cea mai costisitoare dacă duce la o încadrare greșită, la repetarea analizelor sau la elaborarea unei documentații care nu reflectă modul real de funcționare al companiei. De aceea, primul pas trebuie să fie stabilirea domeniului de aplicare și identificarea lacunelor. Abia apoi pot fi comparate costul total, durata și riscurile celor trei modele de implementare, înainte de alegerea furnizorului și a modului de lucru.

Nu selectați furnizorul înainte de a clarifica obligațiile

Comparația dintre implementarea cu resurse proprii și sprijinul unei firme externe este relevantă numai după ce organizația stabilește dacă intră sub incidența cerințelor NIS2 și a legislației naționale care le transpune. Dacă răspunsul este afirmativ, trebuie clarificat ce servicii, entități, sedii și resurse intră în analiză. Fără această încadrare nu pot fi estimate în mod credibil volumul de lucru, durata proiectului și costurile. Conducerea trebuie, de asemenea, să desemneze un responsabil de proiect cu autoritatea necesară pentru a coordona deciziile între operațiuni, funcția juridică și IT.

Punctul de plecare nu este achiziția unui set de documente sau a unei aplicații, ci descrierea modelului operațional. Trebuie identificate serviciile furnizate, procesele care le susțin, sistemele și datele utilizate, precum și furnizorii și dependențele esențiale pentru continuitate. Numai această hartă permite stabilirea unui domeniu care să acopere întreaga companie sau, după caz, doar anumite servicii și locații. Prima etapă ar trebui să genereze trei rezultate concrete: încadrarea documentată a entității, limitele clare ale domeniului și lista zonelor care necesită evaluare și măsuri corective.

Aplicabilitatea formală a legislației trebuie separată de necesitatea comercială de a crește reziliența. O organizație poate rămâne în afara obligațiilor legale, dar poate fi supusă cerințelor formulate de clienți, grupul din care face parte, asigurător sau partenerii din lanțul de aprovizionare. Un astfel de proiect nu trebuie prezentat drept îndeplinirea unei obligații legale, ci drept răspuns la cerințe contractuale și riscuri operaționale concrete.

Un exemplu relevant este o companie de producție care dispune de firewalluri, copii de siguranță și protecție pentru stațiile de lucru, dar nu poate indica proprietarul procesului de răspuns la incidente. În plus, nu a evaluat efectul unei indisponibilități a sistemului de planificare a producției asupra comenzilor, disponibilității materialelor și respectării termenelor de livrare. În acest caz, problema nu ține exclusiv de nivelul controalelor tehnice, ci și de lipsa responsabilităților definite și a unei analize a dependenței dintre sistemul informatic și furnizarea serviciului.

După descrierea activității trebuie efectuată o evaluare juridică pe baza criteriilor sectoriale, organizaționale și de dimensiune aplicabile la data publicării. Poziția formală ar trebui aprobată de organismul sau persoana autorizată să reprezinte organizația, cu participarea funcției juridice și a proprietarilor serviciilor și proceselor. Departamentul IT furnizează datele despre sisteme, dar nu ar trebui să decidă singur încadrarea. Subiectul este detaliat în materialul „Directiva NIS2 – cui i se aplică și ce companii trebuie să îndeplinească noile cerințe?”.

Costul implementării nu se limitează la factura consultantului

Varianta internă nu este gratuită, după cum nici onorariul firmei de implementare nu reprezintă costul integral al sprijinului extern. Calculul trebuie să includă timpul conducerii, al proprietarilor de procese, specialiștilor IT, achizițiilor, resurselor umane, funcției juridice și responsabilului sistemului de management. Timpul acestora trebuie evaluat pe baza costurilor interne și a orelor efectiv alocate, luând în considerare activitățile operaționale care nu vor mai fi realizate în perioada proiectului. Efortul este determinat în principal de numărul locațiilor, proceselor, sistemelor, furnizorilor și entităților incluse în domeniu.

Cel mai frecvent sunt subestimate colectarea datelor, clarificarea responsabilităților, inventarierea activelor și furnizorilor, pregătirea dovezilor, desfășurarea testelor și instruirilor, precum și corectarea reglementărilor interne necorelate. Firma de implementare poate reduce acest efort numai dacă este capabilă să traducă cerințele în procesele, rolurile și instrumentele existente. Furnizarea unor politici-tip fără înțelegerea activității nu elimină costul, ci îl transferă către etapele de validare, aplicare și actualizare ulterioară.

Documentația pentru gestionarea incidentelor poate fi elaborată rapid, dar rămâne formală dacă nu au fost stabilite permanența, traseul de escaladare, modul de conservare a probelor și înlocuitorii. Costul real devine vizibil la primul test sau incident, când procedura trebuie reproiectată. Bugetul trebuie să separe cheltuielile unice de cele recurente și să includă onorariul consultantului, investițiile tehnice, timpul neproductiv aferent proiectului, remedierile și costul anual de menținere: revizuiri, teste, instruiri, actualizarea documentației, evaluarea furnizorilor și gestionarea incidentelor.

Un sistem funcțional de management al securității informației sau existența unei certificări poate reduce volumul activităților de inventariere, evaluare a riscurilor, control al documentelor și audit, dacă mecanismele respective funcționează efectiv în domeniul analizat. Acestea nu înlocuiesc însă evaluarea obligațiilor concrete prevăzute de legislația aplicabilă și nici verificarea faptului că măsurile existente corespund serviciilor vizate. Relația este explicată în materialul NIS2 și SR EN ISO 27001: ce oferă certificarea și ce mai lipsește pentru conformitatea cu KSC.

Durata depinde de capacitatea organizației de a lua decizii

Durata pregătirii pentru cerințele NIS2 este rareori determinată de viteza cu care sunt redactate procedurile. Principalele constrângeri sunt disponibilitatea datelor credibile, a proprietarilor de procese și a persoanelor autorizate să aprobe schimbările. Planificarea trebuie să reflecte disponibilitatea reală a acestor persoane, frecvența reuniunilor comitetului de coordonare și timpul necesar soluționării divergențelor dintre departamente. Data promisă pentru predarea documentației nu reprezintă un indicator de progres dacă organizația nu a aprobat domeniul, responsabilitățile și prioritățile.

Activitățile trebuie planificate în ordinea dependențelor. Mai întâi se stabilesc domeniul, rolurile, procesele și activele. Urmează evaluarea riscurilor, aprobarea planului de tratare, implementarea măsurilor, testarea și colectarea dovezilor de funcționare. În paralel pot fi derulate activități bazate pe aceleași ipoteze aprobate, cum ar fi inventarierea contractelor și revizuirea controalelor existente. În schimb, o analiză detaliată a riscurilor nu ar trebui începută înainte de identificarea serviciilor, proceselor, sistemelor, informațiilor și dependențelor de furnizori care intră în evaluare.

La prioritizarea măsurilor trebuie diferențiate lacunele care necesită achiziții, modificări contractuale, integrări tehnice sau teste. Fiecare categorie urmează un traseu distinct de aprobare și are un termen diferit de realizare. Sprijinul extern poate accelera diagnosticul, poate structura atelierele și rezultatele acestora, însă consultantul nu poate decide în locul conducerii acceptarea riscului, ordinea investițiilor sau durata tolerabilă a întreruperii unui serviciu. Dacă aceste decizii sunt amânate până la final, documentația va devansa soluțiile operaționale, iar unele analize vor trebui reluate.

Progresul trebuie măsurat prin numărul deciziilor aprobate, al dependențelor clarificate și al măsurilor a căror funcționare a fost verificată, nu prin numărul documentelor redactate. Chiar și un calendar de câteva săptămâni este nerealist dacă organizația nu dispune de o listă actualizată a sistemelor, un registru al contractelor cu furnizorii și proprietari de procese desemnați. Într-o asemenea situație, echipa poate descrie starea declarată, dar nu poate stabili responsabilitatea pentru continuitate, restaurarea serviciilor și supravegherea furnizorilor.

Cartografierea proceselor trebuie să susțină aceste decizii, nu să amplifice inutil documentația. Alegerea nivelului potrivit de detaliu este facilitată de comparația „BPMN sau flowchart – ce instrument este mai potrivit pentru cartografierea proceselor de calitate?”. În acest context, instrumentul adecvat este cel care indică fără ambiguitate rolurile, punctele de transfer al responsabilității, dependențele informaționale și zonele care necesită măsuri de protecție sau înlocuitori.

Riscul provine în primul rând din ipoteze greșite

Succesul pregătirii pentru NIS2 depinde mai des de corectitudinea ipotezelor decât de numărul activităților finalizate. În modelul intern, riscul principal este asociat interpretării greșite a domeniului, omiterii dependențelor de business și tratării securității cibernetice ca responsabilitate exclusivă a IT-ului. Organizația poate exclude astfel procesele de producție, logistica, mentenanța, continuitatea aprovizionării sau obligațiile față de clienți. Lipsește și perspectiva independentă asupra practicilor considerate suficiente doar pentru că, până în prezent, nu au generat perturbări vizibile.

Sprijinul extern nu elimină automat aceste riscuri. Dimpotrivă, ele cresc atunci când furnizorul livrează un pachet standard de documente fără să analizeze serviciile, procesele și dependențele organizației, nu implică proprietarii proceselor sau nu transferă cunoștințele necesare menținerii măsurilor adoptate. Rezultatul este un sistem dependent de autorul documentației, nu de persoanele care răspund de activitatea curentă.

Este recomandabil ca executarea lucrărilor să fie separată de evaluarea finală independentă, mai ales atunci când aceeași entitate a definit domeniul, a evaluat riscurile și a selectat măsurile. Decizia privind acceptarea riscului rezidual trebuie să rămână la nivelul conducerii competente.

Conformitatea aparentă se observă în discrepanța dintre documente și practică: politica descrie un mod de lucru diferit de procesul real, registrul de riscuri nu influențează prioritățile și investițiile, iar procedura de gestionare a incidentelor nu a fost testată. O lacună documentară înseamnă că o înregistrare necesară lipsește sau este incoerentă. O lacună operațională există atunci când organizația nu poate executa activitatea, nu poate atribui responsabilitatea sau nu poate prezenta dovezi privind eficacitatea. Completarea unui formular poate remedia prima lacună, dar nu poate înlocui un test, o decizie sau o schimbare reală a modului de lucru.

De exemplu, o unitate de producție poate avea o procedură aprobată de raportare a incidentelor, în timp ce personalul din producție nu știe cum să raporteze indisponibilitatea unui sistem de control sau planificare. În același timp, furnizorul serviciului nu are stabilite traseul de escaladare, persoanele de contact sau modul de intervenție în afara programului. Documentul există, însă primele minute ale incidentului sunt pierdute pentru clarificarea responsabilităților. O asemenea lacună poate fi identificată numai printr-un exercițiu care implică utilizatorul, proprietarul procesului, IT-ul, conducerea și furnizorul.

Auditul de pregătire trebuie să verifice capacitatea de acțiune și de prezentare a unor dovezi credibile, nu doar caracterul complet al documentației. Indicatorii utili includ numărul acțiunilor restante după audituri și teste anterioare, rezultatele testelor de restaurare, concluziile analizelor incidentelor și perturbărilor, precum și procentul furnizorilor critici evaluați și supuși unor cerințe convenite — întotdeauna pe baza datelor organizației. Modul de efectuare a acestei verificări este detaliat în materialul „Auditul NIS2 într-o companie de producție – cum verificăm dacă organizația este pregătită pentru noile obligații”.

Modelul mixt oferă, de regulă, cel mai bun nivel de control

Alegerea modelului de implementare trebuie să reflecte capacitatea reală a organizației de a executa activitățile, nu doar diferența dintre tarifele de consultanță. Implementarea internă este justificată atunci când proiectul are un responsabil competent, procesele de management al riscurilor sunt mature, inventarele activelor și dependențelor sunt actualizate, iar personalul-cheie dispune de timp și poate interpreta cerințele. Un sprijin extern mai amplu este indicat când există un deficit semnificativ de competențe, o structură dispersată, dependențe tehnologice importante, un termen scurt de pregătire sau lipsa unui sistem de management bine structurat.

În majoritatea cazurilor, modelul mixt asigură cel mai bun control asupra costurilor, duratei și riscurilor. Organizația își păstrează responsabilitatea pentru decizii, datele-sursă, asumarea riscurilor și realizarea activităților operaționale. Consultantul răspunde de diagnostic, metodologie, facilitarea atelierelor, analizele care necesită competențe de specialitate și controlul calității rezultatelor.

Cel puțin următoarele responsabilități trebuie să rămână în organizație:

• stabilirea importanței proceselor și serviciilor;
• desemnarea proprietarilor de risc;
• acceptarea riscului rezidual;
• stabilirea priorităților de investiții;
• confirmarea funcționării practice a măsurilor.

Conducerea nu poate transfera furnizorului responsabilitatea pentru reziliența organizației.

O companie cu mai multe unități poate colecta intern informațiile despre servicii, active, furnizori și efectele perturbărilor, deoarece evaluarea lor credibilă necesită cunoaștere operațională. Specialistul extern poate apoi structura metoda de evaluare, poate contesta inconsecvențele, facilita ateliere interdepartamentale și verifica integralitatea dovezilor. Rentabilitatea acestei diviziuni depinde de numărul și competențele persoanelor care pot fi efectiv alocate proiectului, nu de componența formală a echipei.

Ofertele trebuie comparate pe baza aceluiași set de livrabile și criterii de acceptare. Referințele furnizorului trebuie evaluate în funcție de similitudinea sectorului, dimensiunii, proceselor și mediului tehnologic, nu doar după numărul proiectelor realizate. Contractul trebuie să definească fără echivoc livrabilele, criteriile de acceptare, obligația de a adapta soluțiile la procesele reale, transferul de cunoștințe, regulile de confidențialitate și acces la date sensibile, responsabilitatea pentru remedieri și sprijinul post-implementare. Modelul de remunerare nu ar trebui să recompenseze numărul documentelor, ci obținerea rezultatelor convenite și verificabile.

Limitele practice ale responsabilității conducerii, proprietarilor de procese și funcțiilor suport sunt detaliate în materialul NIS2 în practica managerială: transpunerea cerințelor în decizii, responsabilități și reziliență organizațională reală.

Decizia trebuie bazată pe dovezi și pe capacitatea de menținere a sistemului

Alegerea modelului de implementare trebuie precedată de un diagnostic organizațional succint. Este necesară confirmarea domeniului proiectului, desemnarea responsabilului, evaluarea competențelor disponibile, inventarierea dovezilor existente și estimarea lacunelor principale. Numai după această etapă se poate decide ce activități va efectua organizația intern și unde implicarea unui specialist reduce riscul interpretărilor greșite, al omisiunilor sau al repetării lucrărilor.

Decizia conducerii trebuie să compare trei variante: implementarea cu resurse proprii, modelul mixt și sprijinul extern extins. Pentru toate trebuie aplicate aceleași criterii:

• costul total, inclusiv efortul personalului, remedierile și menținerea;
• timpul necesar pentru atingerea capacității operaționale;
• riscul de eroare și de repetare a activităților;
• disponibilitatea reală a competențelor;
• capacitatea organizației de a menține independent soluțiile.

Hotărârea sau decizia conducerii trebuie să indice varianta selectată, responsabilitățile, proprietarul proiectului, resursele, modul de raportare, criteriile de acceptare și indicatorii de eficacitate derivați din procesele organizației, nu din praguri universale lipsite de context.

Recepția implementării nu trebuie realizată pe baza numărului de politici redactate. Rezultatul urmărit este funcționarea repetabilă: roluri atribuite, decizii documentate privind riscurile, măsuri aplicate, răspunsuri testate la incidente și perturbări, supravegherea furnizorilor și înregistrări credibile. O procedură aprobată de răspuns nu demonstrează pregătirea dacă testul evidențiază date de contact neactualizate, o escaladare neclară sau lipsa persoanei autorizate să decidă.

Criteriile de acceptare trebuie să acopere concordanța dintre documente și practică, închiderea lacunelor convenite, rezultatele testelor, transferul de cunoștințe și un plan clar de îmbunătățire ulterioară, inclusiv planul auditurilor interne. Dovezile de recepție pot include aprobări, registre, rezultate ale testelor, procese-verbale ale instruirilor, decizii privind riscurile și confirmări ale acțiunilor finalizate. Pregătirea și menținerea acestor dovezi sunt detaliate în materialul Documentația NIS2 și KSC înaintea unui control: ce politici, registre și dovezi sunt necesare în mod real.

Durabilitatea soluției poate fi evaluată numai după reducerea implicării consultantului. Proprietarii proceselor trebuie să poată actualiza registrele, lua decizii privind riscurile, analiza rezultatele testelor și iniția acțiuni corective fără sprijin permanent. Dacă sistemul funcționează exclusiv datorită cunoștințelor furnizorului, proiectul nu este finalizat: organizația a primit documentație, dar nu și-a construit capacitatea de a o menține.