Un plan de continuitate a activității elaborat în contextul cerințelor NIS2 nu poate rămâne o procedură separată, administrată exclusiv de departamentul IT. Acesta trebuie să pornească de la analiza impactului întreruperilor asupra activității și de la analiza riscurilor, să stabilească prioritățile de restabilire a proceselor și să fie validat prin exerciții periodice. Eficacitatea sa nu este demonstrată prin declarații, ci prin capacitatea organizației de a lua decizii, de a activa modul alternativ de operare, de a atinge nivelul minim acceptat de funcționare și de a reveni în siguranță la activitatea normală.
Continuitatea activității este o decizie de management
Planul de continuitate a activității nu începe cu un model de procedură și nici cu inventarul sistemelor informatice. Punctul de plecare îl reprezintă serviciile, produsele și procesele a căror întrerupere poate pune în pericol îndeplinirea obligațiilor, securitatea, conformarea cu cerințele aplicabile sau stabilitatea financiară a companiei. Domeniul planului trebuie stabilit pe baza analizei impactului asupra activității. Organizația trebuie să determine cum cresc consecințele în timp, când depășesc nivelul acceptat de conducere și în ce ordine trebuie restabilite capabilitățile operaționale.
Durata maximă tolerabilă a întreruperii și nivelul acceptabil al pierderilor nu trebuie stabilite unilateral de departamentul IT. Acești parametri sunt aprobați de conducere pe baza informațiilor furnizate de proprietarii proceselor și de funcțiile financiară, de conformitate, securitate și tehnologie. Proprietarul procesului definește cerințele de continuitate, iar responsabilul planului coordonează elaborarea și menținerea soluției. Dacă aceste roluri nu sunt reunite printr-un mecanism comun de decizie, IT-ul protejează infrastructura, operațiunile răspund de furnizarea produselor sau serviciilor, iar conducerea nu primește o imagine coerentă asupra priorităților de restabilire și a întreruperilor tolerate.
Într-o unitate de producție, simpla restabilire a sistemului de planificare sau de control nu înseamnă reluarea livrărilor. Producția poate rămâne oprită din cauza indisponibilității datelor tehnologice, a lipsei operatorilor autorizați, a alimentării cu energie, a comunicațiilor furnizate de un terț sau a unei proceduri aprobate pentru lucrul în regim alternativ. Reziliența operațională există numai atunci când planul acoperă întregul lanț de dependențe al procesului, nu doar resursele controlate de departamentul IT.
De asemenea, trebuie diferențiate continuitatea activității, recuperarea resurselor IT, răspunsul la incidente și managementul crizelor. Primul domeniu urmărește menținerea sau reluarea proceselor, al doilea — restabilirea tehnologiei și a datelor, al treilea — limitarea efectelor evenimentului și gestionarea acestuia, iar al patrulea — luarea deciziilor în condițiile unei perturbări majore. Aceste mecanisme trebuie să utilizeze scenarii, praguri de escaladare și reguli de responsabilitate comune, fără a fi considerate interschimbabile.
Doar un model operațional definit în acest mod poate fi corelat cu obligațiile privind managementul riscurilor, continuitatea activității, gestionarea incidentelor și responsabilitatea conducerii care decurg din NIS2 și din legislația națională aplicabilă, ținând cont de încadrarea organizației. Un context 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.
Riscul trebuie transformat într-un scenariu operațional
Registrul riscurilor poate orienta planul de continuitate numai dacă evidențiază legătura dintre amenințare, vulnerabilitate, resursă, proces și impactul asupra activității. O simplă listă de amenințări cibernetice nu explică modul în care organizația își va menține activitatea. Scenariile trebuie construite în jurul efectelor perturbării, precum indisponibilitatea sistemului de control, pierderea datelor, întreruperea comunicațiilor, lipsa personalului sau indisponibilitatea unui furnizor. Cauze diferite pot genera aceeași stare operațională și pot necesita aceeași strategie de continuitate.
Analiza impactului asupra activității și analiza riscurilor au funcții distincte, dar complementare. Prima stabilește importanța întreruperii, ritmul în care cresc pierderile și momentul în care este depășit nivelul acceptat de conducere. A doua permite identificarea surselor posibile ale evenimentului, a vulnerabilităților și a eficacității măsurilor existente. Metoda și scala de evaluare adoptate trebuie să permită compararea scenariilor și acceptarea conștientă a riscului rezidual, în concordanță cu apetitul la risc.
Numărul scenariilor ar trebui limitat la efectele distincte care impun decizii, resurse sau secvențe de restabilire diferite. Analizarea separată a fiecărei variante tehnice nu crește, de regulă, utilitatea planului, ci îngreunează menținerea și aplicarea acestuia sub presiunea timpului.
| Proces și impact | Scenariu | Strategie de continuitate | Responsabilul deciziei | Criteriu de activare |
|---|---|---|---|---|
| Producție: lipsa controlului liniei | Indisponibilitatea sistemului de control, indiferent de cauză | Oprire în condiții de siguranță, regim alternativ, restabilirea controlului conform priorității | Managerul operațional desemnat în plan | Durata estimată a indisponibilității depășește întreruperea tolerată sau activitatea nu poate continua în siguranță |
| Procesarea comenzilor: indisponibilitatea datelor | Pierderea sau indisponibilitatea datelor tranzacționale | Trecerea la evidența alternativă convenită, verificarea integrității și recuperarea datelor | Proprietarul procesului împreună cu persoana autorizată să aprobe recuperarea | Lipsa accesului la date fiabile împiedică îndeplinirea obligațiilor |
| Relații cu clienții: indisponibilitatea unui serviciu extern | Întreruperea comunicațiilor sau a serviciului furnizorului | Activarea soluției alternative, escaladare contractuală, limitarea domeniului serviciilor | Proprietarul serviciului | Nu există un termen confirmat de restabilire înainte de atingerea pragului critic |
Pentru fiecare scenariu trebuie stabilite durata tolerată a întreruperii, nivelul minim de funcționare, resursele necesare, ordinea restabilirii și persoana autorizată să activeze planul. Parametrii trebuie fundamentați pe duratele reale ale întreruperilor și recuperării observate în incidente, defecțiuni și exerciții, precum și pe cerințele contractuale privind disponibilitatea, termenele de livrare și notificarea perturbărilor. Pe această bază pot fi măsurate timpul necesar luării deciziei, atingerea nivelului minim și restabilirea completă.
Analiza trebuie să includă dependențele reale ale procesului față de aplicații, date, infrastructură, locații, utilități, competențe-cheie, furnizori IT, integratori și subcontractanți. Dacă strategia presupune sprijinul unui terț, trebuie verificate disponibilitatea, timpii de răspuns, canalele de escaladare și soluțiile alternative ale acestuia, fără a vă limita la clauzele contractuale. Tema este dezvoltată în materialul NIS2 și securitatea lanțului de aprovizionare: cum se evaluează furnizorii IT, integratorii și subcontractanții.
Planul trebuie să ghideze organizația pe durata perturbării
Un plan de continuitate util nu descrie toate evenimentele posibile, ci îi conduce pe responsabili prin succesiunea deciziilor necesare. Acesta trebuie să precizeze cine evaluează situația, cine declară activarea continuității, ce procese trebuie menținute la nivelul minim, în ce ordine se restabilesc capabilitățile, cum se gestionează comunicarea de criză și în ce condiții se încheie regimul de urgență.
Nivelul de detaliu este adecvat atunci când planul reduce nevoia de interpretare sub presiunea timpului, fără a înlocui instrucțiunile tehnice și operaționale. Într-o organizație mai mare, o soluție practică este un plan-cadru care stabilește principiile de comandă, escaladare și cooperare, completat cu planuri pentru procesele individuale.
Procedura de activare necesită criterii măsurabile. Formularea „în cazul unei defecțiuni grave” mută disputa privind sensul termenului „grav” în cel mai nepotrivit moment. Criteriul poate viza depășirea duratei tolerate a întreruperii, pierderea încrederii în date, imposibilitatea desfășurării activității în siguranță, indisponibilitatea persoanelor-cheie sau scăderea anticipată sub nivelul minim de funcționare aprobat de proprietarul procesului. Fiecare abatere trebuie asociată unei acțiuni, unei persoane autorizate să decidă, unui termen de escaladare și unei înregistrări obligatorii. O logică similară, deși aplicată la un alt nivel operațional, este prezentată în Planul de reacție din planul de control – cum se definesc acțiunile când procesul iese din limite.
Rolurile trebuie atribuite funcțiilor, nu doar persoanelor nominalizate. Matricea responsabilităților trebuie să includă înlocuitorii, limitele autorității, disponibilitatea și canalele principale și alternative de contact. Lista nominală de contacte poate fi păstrată ca anexă controlată, astfel încât schimbările de personal să nu impună refacerea întregului plan.
Conducerea trebuie să ia deciziile care depășesc cadrul operațional aprobat, inclusiv cele privind acceptarea unui risc semnificativ pentru activitate, alocarea unor resurse extraordinare sau comunicarea cu importanță strategică. În schimb, decizia de trecere la un mod alternativ aprobat anterior trebuie menținută cât mai aproape de proces.
După indisponibilitatea sistemului de comenzi, persoana de serviciu poate confirma incidentul și durata estimată a întreruperii, proprietarul procesului poate activa evidența alternativă, iar coordonatorul continuității poate escalada evenimentul la atingerea pragului stabilit. Planul trebuie să precizeze limitele acestei soluții provizorii: capacitatea de procesare, durata maximă de utilizare, regulile privind protecția și integritatea datelor, reconcilierile manuale necesare și modul de introducere ulterioară a înregistrărilor în sistem.
Revenirea la activitatea normală poate avea loc numai după confirmarea stabilității soluției, a integralității datelor și a reconcilierii operațiunilor efectuate manual. Înregistrările rezultate trebuie să permită evaluarea timpului de decizie, a timpului până la atingerea nivelului minim și a duratei restabilirii complete.
Costurile cele mai mari apar la interfața dintre planuri
Amploarea pierderii nu este determinată numai de cauza defecțiunii. Întreruperea este prelungită și de așteptarea aprobărilor, clasificarea ambiguă a evenimentului, prioritățile divergente de restabilire și lipsa cunoașterii dependențelor dintre procese, sisteme și furnizori. Planul de răspuns la incidente urmărește în primul rând detectarea, evaluarea, limitarea și gestionarea evenimentului. Planul de continuitate trebuie să mențină activitatea la nivelul acceptat. Ambele mecanisme trebuie să definească puncte comune pentru transferul informațiilor și al deciziilor: cine constată amenințarea la adresa continuității, cine activează modul alternativ și cine aprobă revenirea la activitatea normală.
Prioritatea recuperării tehnice trebuie să derive din prioritatea procesului, fără a o copia mecanic. Un sistem care susține procesul cel mai important poate necesita activarea prealabilă a serviciilor de identitate, rețea, baze de date sau integrare. În același timp, trebuie protejate integritatea datelor, ordinea corectă de pornire și mecanismele de securitate. Alinierea priorităților de business și tehnice se verifică prin compararea disponibilității solicitate de proces cu rezultatele efective ale testelor de restaurare din copii de siguranță, pierderea tolerată de date și dependențele infrastructurii.
Operațiunile pot solicita reluarea primirii comenzilor înaintea proceselor de decontare, în timp ce echipa IT intenționează să restabilească mai întâi sistemul de decontare, deoarece acesta conține registrul central al partenerilor. Dacă dependența nu a fost clarificată anterior, decizia se ia sub presiune, iar soluția manuală poate genera date care ulterior nu mai pot fi reconciliate în siguranță. Un astfel de caz trebuie evaluat pe baza timpilor reali de detectare, escaladare, decizie și restabilire, precum și a rezultatelor testelor care confirmă caracterul complet și integritatea datelor.
O lacună similară apare la limita responsabilității furnizorului. Declarația contractuală privind disponibilitatea serviciului nu înlocuiește o rută nominală sau funcțională de escaladare, parametrii de recuperare conveniți, accesul la informații despre evoluția perturbării ori obligația de cooperare în timpul exercițiilor. Cerințele proceselor critice trebuie comparate cu condițiile contractuale și cu posibilitățile reale ale furnizorului. Numai astfel organizația poate decide în cunoștință de cauză dacă menține o soluție de rezervă, acceptă întreruperea sau utilizează resurse proprii ori un serviciu extern.
Bugetul trebuie să răspundă deficiențelor de capabilitate, nu să finanțeze numărul de documente. Cheltuielile pot viza redundanța suplimentară, scurtarea traseului decizional, testări mai frecvente ale recuperării, modificarea condițiilor contractuale sau asigurarea unui mod alternativ de realizare a procesului. Structurarea acestor costuri este dezvoltată în analiza Cât costă implementarea NIS2 și uKSC – cum se construiește bugetul pentru audit, documentație, instruire și măsuri de securitate fără erori costisitoare.
Exercițiul trebuie să testeze deciziile
Un exercițiu de continuitate nu se poate limita la citirea procedurii sau confirmarea prezenței participanților. Acesta trebuie să verifice o ipoteză formulată clar, de exemplu dacă organizația poate activa un proces alternativ fără sistemul principal, poate păstra controlul asupra datelor introduse și le poate reconcilia în siguranță după restabilirea serviciului.
Programul de exerciții trebuie dezvoltat progresiv: de la revizuirea rolurilor și exerciții de tip tabletop, la testarea unei proceduri sau a unei restaurări selectate și, ulterior, la exerciții tehnico-operaționale care implică funcțiile de business, IT, conducerea și furnizorii. Domeniul trebuie extins proporțional cu riscul, importanța procesului și nivelul de pregătire al organizației.
Scenariul trebuie să oblige participanții să decidă în condiții apropiate de o perturbare reală. Pot fi introduse informații incomplete, presiune de timp, priorități conflictuale și indisponibilitatea unei dependențe importante, precum persoana care aprobă, serviciul unui furnizor sau lista actualizată de contacte. Exercițiul nu trebuie însă transformat într-o capcană pentru participanți. Este evaluat sistemul — repartizarea responsabilităților, calitatea informațiilor, aplicabilitatea procedurilor și capacitatea de escaladare — nu performanța individuală a angajaților.
Participarea conducerii este necesară atunci când scenariul impune acceptarea riscului, schimbarea priorităților sau activarea unei soluții alternative costisitoare. Furnizorul trebuie implicat dacă reacția sa condiționează continuitatea procesului.
Un exercițiu poate începe, de exemplu, cu indisponibilitatea sistemului de gestionare a comenzilor. Ulterior, coordonatorul transmite informații despre o copie incompletă a datelor și despre răspunsul întârziat al furnizorului. Echipa trebuie să decidă dacă activează procesarea manuală, ce comenzi acceptă și cum marchează înregistrările pentru a evita duplicatele și pierderea integrității datelor după restabilirea serviciului.
În timpul exercițiului trebuie măsurate intervalele necesare pentru identificarea perturbării, escaladare, activarea continuității, atingerea nivelului minim de funcționare și restabilire. În paralel se evaluează calitatea fluxului de informații și a înregistrărilor, utilizarea unor date de contact neactualizate, escaladările ineficiente și etapele planului care nu au putut fi executate. Timpii obținuți trebuie comparați cu obiectivele de continuitate aprobate.
Frecvența și forma exercițiilor trebuie stabilite în funcție de risc, schimbările proceselor, rezultatele testelor anterioare și importanța dependențelor, nu exclusiv pe baza unui calendar anual. Exercițiile anunțate susțin mai bine învățarea și clarificarea rolurilor. Cele neanunțate permit evaluarea pregătirii reale, dar impun controlarea riscului operațional. Utilizarea sistemului de producție este justificată numai dacă domeniul, măsurile de protecție și posibilitatea opririi testului au fost aprobate în mod conștient; în celelalte situații este preferabil un mediu de testare.
Fiecare exercițiu trebuie să se încheie cu acțiuni care au un responsabil, un termen, un criteriu de eficacitate și o decizie privind retestarea. Procentul acțiunilor închise la termen este un indicator util, însă statutul „finalizat” nu demonstrează singur îmbunătățirea. Rezultatul retestării rămâne decisiv. Abordarea descrisă în materialul Cum se construiește o bibliotecă de modele pentru calitate: FMEA, Control Plan, 8D, audit, CAPA și KPI poate sprijini structurarea scenariilor, proceselor-verbale, acțiunilor corective și indicatorilor.
Închideți ciclul prin dovezi și analiza managementului
Un set complet de proceduri nu demonstrează capacitatea de menținere a activității. Un lanț credibil de dovezi trebuie să coreleze ipotezele aprobate ale analizei riscurilor și continuității, deciziile proprietarilor de procese, înregistrările testelor, rezultatele exercițiilor, neconformitățile identificate, acțiunile corective și evaluarea eficacității lor. Registrul reviziilor planului de continuitate trebuie să indice nu doar data și autorul modificării, ci și evenimentul, decizia sau rezultatul analizei care a justificat-o.
Frecvența revizuirii planului trebuie adaptată criticității proceselor și dinamicii riscurilor. O dată periodică nu este suficientă. Revizuirea trebuie declanșată și după un incident, un exercițiu sau o schimbare semnificativă a procesului, tehnologiei, locației, furnizorului, structurii organizaționale ori profilului de risc. Criteriile de acceptare a rezultatelor exercițiului trebuie stabilite înainte de începere, pentru ca evaluarea să nu se reducă la concluzia subiectivă că organizația „s-a descurcat”.
Monitorizarea lunară poate confirma că programul de exerciții a fost realizat conform planificării, dar poate arăta și că un proces nu a atins timpul de recuperare solicitat sau că pentru un serviciu critic furnizat extern nu există încă o soluție alternativă. Un asemenea rezultat nu trebuie ascuns într-un raport tehnic. Conducerea trebuie să primească informații despre procesele care nu ating capabilitatea necesară, diferențele neacceptate, riscurile asumate în mod conștient și investițiile sau deciziile organizaționale necesare. Analiza managementului trebuie să se încheie cu decizii documentate, nu doar cu luarea la cunoștință a informațiilor.
Auditul intern trebuie să verifice concordanța dintre declarații și practică: dacă procesul declarat critic participă efectiv la exerciții, dacă obiectivele tehnice de recuperare corespund nevoilor operaționale și dacă acțiunile rezultate din teste au fost închise, iar eficacitatea lor a fost confirmată. Auditorului sau autorității de supraveghere trebuie să i se poată prezenta o succesiune de înregistrări care arată traseul de la riscul identificat, prin decizie și testare, până la îmbunătățirea verificată. Indicatorii auxiliari pot include gradul de realizare a programului aprobat de exerciții, respectarea termenelor pentru acțiunile corective și numărul diferențelor neacceptate dintre capabilitatea de continuitate necesară și cea confirmată.
Lista finală de acțiuni poate fi integrată în calendarul mai amplu descris în materialul Implementarea NIS2 după înscrierea în registrul KSC – plan de acțiuni până la 3 aprilie 2027. Termenele, domeniul obligațiilor și măsurile aplicabile trebuie însă verificate de fiecare dată în raport cu cadrul juridic actual, statutul organizației în sistemul național de securitate cibernetică și profilul său real de risc.
Masz pytania? Porozmawiajmy.
Bezpłatna konsultacja – bez zobowiązań.