Articolul acesta e despre cum construiești, concret, un plan de continuitate funcțional pentru o firmă de 50–150 de oameni. Cu structura paginilor, întrebările pe care le pui, și greșelile pe care le văd în 8 din 10 firme.
Cât de lung trebuie să fie
Maxim 15 pagini. Ideal 8–10. Mai mult de atât, nimeni nu-l mai citește, deci e inutil în practică.
Am văzut planuri de continuitate de 80 de pagini, scrise de consultanți, semnate de director, puse într-un dosar pe care nu-l mai deschide nimeni. Acelea sunt pentru audituri, nu pentru funcționarea firmei. Iar la audit, faptul că nimeni din firmă nu poate explica ce e în el e mai grav decât absența lui.
Planul real e scurt și acționabil – un director îl citește în 15 minute și îl înțelege complet, echipa de management îl poate executa la 3 dimineața fără să-l mai deschidă.
Structura planului secțiune cu secțiune
Secțiunea 1: Roluri și contacte (1 pagină)
Lista persoanelor cu rol în incident, cu nume, telefon mobil, email personal de rezervă (în caz că email-ul firmei nu funcționează).
- Director general (decizii finale, comunicare externă majoră)
- IT manager intern sau persoana de contact IT
- Furnizor IT extern (numele firmei, persoana de contact, număr direct)
- Firma de cybersecurity / MSSP cu care ai contract de incident response (dacă există)
- Avocat (pentru notificări legale GDPR / NIS2)
- Asigurator cyber (dacă ai poliță)
- DNSC (numărul oficial pentru incidente NIS2: 1911)
Lângă fiecare nume, în 1–2 fraze: ce decizii ia persoana respectivă în incident.
Tipărit. În telefoanele directorilor. Pe Drive personal. NU pe rețeaua firmei, pentru că rețeaua poate fi indisponibilă fix când ai nevoie de plan.
Secțiunea 2: Sisteme critice și impact (2–3 pagini)
Pentru fiecare sistem critic, un mini-fișier cu:
- Numele sistemului și ce face în firmă (în limbaj de business, nu tehnic)
- Furnizor și contact direct
- Cât timp poate firma funcționa fără el (în ore sau zile, concret)
- Pierdere estimată pe zi de indisponibilitate (în EUR sau RON)
- Alternativă temporară (cum funcționăm fără el dacă pică)
- Plan de recuperare (cum revenim, cine face ce)
Sistemele tipice pentru o firmă de 100 de oameni: ERP, email, file share / share-ul de rețea, telefonie, internet, sistem de access (pentru intrare în clădire), sistem de plăți / banking. La firmele de producție, plus sistemele OT – linia de producție, sistemele de control. La firmele de servicii B2B, plus CRM și platforme de comunicare cu clienții.
Important: nu copia un template generic. Lista ta e specifică firmei tale. Ce e critic pentru o firmă de producție alimentară (sistemul de trasabilitate) e irelevant pentru o firmă de consultanță.
Secțiunea 3: Scenarii și răspuns (3–4 pagini)
Aici e partea care lipsește din 80% din planurile pe care le văd. Patru-cinci scenarii concrete, fiecare cu pași de urmat.
Scenariu 1: Atac ransomware – sistemele sunt criptate
- În prima oră: izolare. Cine decide. Ce se oprește (deconectarea de la internet, oprirea VPN-ului, izolarea sistemelor afectate).
- În primele 4 ore: evaluare. Cine sună firma de incident response. Ce date colectăm înainte să atingem ceva (criminalistic — urmele se pierd dacă restartezi sisteme).
- În primele 24 de ore: notificări. GDPR (72 de ore către ANSPDCP), NIS2 (24 de ore către DNSC dacă aplicabil), asigurator, clienți afectați.
- În primele 72 de ore: decizia de plată. Ai decis dinainte că nu plătești, aici doar reconfirmi.
Recuperare: din backup, în ordinea sistemelor critice.
Scenariu 2: Pierdere de date majoră (corupere, ștergere accidentală)
- Diferit de ransomware: nu trebuie să izolezi rețeaua, dar trebuie să oprești operațiunile pe sistemul afectat ca să nu suprascrii datele
- Restaurare din backup
- Re-introducere date pierdute între ultimul backup și momentul incidentului
Scenariu 3: Indisponibilitate prelungită a unui furnizor cloud
- Microsoft 365 sau Google Workspace cad pentru câteva ore
- Cum comunicăm fără email
- Care sunt prioritățile pentru primele 4 ore
- Cine ține legătura cu clienții importanți
Scenariu 4: Pierdere de internet sau telefonie
- Backup intern (4G/5G ca redundanță)
- Dacă pică tot pe o zonă întreagă, ce facem
- Cum comunicăm intern și cu clienții
Scenariu 5: Compromitere date prin email (BEC, phishing reușit)
- Cine reinițializează parolele afectate
- Cum verificăm dacă au plecat email-uri în numele angajatului compromis
- Notificări dacă datele clienților au fost expuse
Pentru fiecare scenariu, două-trei pagini sunt suficiente. Mai mult înseamnă că plănuiești pentru audit, nu pentru utilizare.
Secțiunea 4: Comunicare în incident (1 pagină)
- Internă: cine anunță angajații, ce se comunică, prin ce canal (Slack, WhatsApp, email personal dacă email-ul de firmă nu funcționează)
- Către clienți importanți: cine sună, ce se comunică (template scurt)
- Către furnizori: cine îi anunță dacă suntem indisponibili
- Public / presă: niciodată comunicare inițială fără avocat. Decide cine vorbește dacă apare presa.
Template-uri scurte pentru fiecare. 3–4 fraze. Personalizezi în incident, dar baza e gata.
Secțiunea 5: Recuperare și revenire la normal (1 pagină)
- Ordinea în care revin sistemele (cele critice primele, cele auxiliare după)
- Validarea că totul funcționează (cum testezi că ERP-ul nu doar pornește, ci și salvează corect date)
- Comunicarea internă că suntem operaționali
- Post-mortem după 1–2 săptămâni: ce a mers, ce nu, ce schimbăm
Cum testezi planul
Un plan netestat e o ipoteză. Testarea poate fi simplă, nu e nevoie de exerciții elaborate.
Test trimestrial: 1 oră, scenariu pe hârtie. Toți cei din planul de incident se adună. Tu spui un scenariu (“e luni dimineața, IT-ul te sună și-ți zice că nu mai pornește niciun sistem”). Fiecare persoană spune ce ar face în primele 30 de minute. Notezi unde apare confuzie sau disagree-uri. Acolo trebuie clarificat planul.
Test semestrial: simulare reală pe un sistem. Programezi cu IT-ul să oprească un sistem necritic pentru 4 ore într-o zi de joi. Vezi ce se întâmplă. Ce nu funcționează? Cum reacționează echipa? Ce a fost prevăzut și ce nu?
Test anual: scenariu complex. O zi întreagă. Furnizor IT extern simulează un atac. Vedeți cum reacționați. Mai dureros, dar de aici învață firma cel mai mult.
Greșelile frecvente
Planul există dar e generic. Cumpărat dintr-un template, copiat de la altă firmă, scris de un consultant care n-a stat o zi în firma ta. Nu e specific firmei. La nevoie, nu ajută.
Planul e prea lung. 80 de pagini. Nimeni nu-l citește. La incident, nimeni nu-l deschide pentru că știe că nu va găsi rapid ce caută. Inutil în practică.
Planul nu e accesibil. Salvat pe rețeaua firmei, care e indisponibilă în incident. Sau în Drive-ul cuiva care e în concediu. Plan inaccesibil = plan inexistent.
Planul nu e testat. A fost scris acum 3 ani. Între timp, firma a schimbat ERP-ul, a trecut pe alt furnizor de email, a deschis un birou nou. Planul vorbește despre sisteme care nu mai există. La nevoie, e ficțiune.
Planul e despre IT, nu despre business. Scris în limbaj tehnic, cu detalii de configurări. Directorul nu îl înțelege. La incident, directorul nu poate lua deciziile pe care planul le cere de la el.
Planul nu are owner. Nimeni nu e responsabil să-l mențină. Lumea schimbă în firmă, planul rămâne static. După un an, e depășit.
Cum menții planul actualizat
Owner clar: o singură persoană (de obicei IT manager sau director operațional) răspunde de menținerea planului.
Revizuire trimestrială: 30 de minute, să verifici că datele de contact sunt corecte, sistemele critice listate sunt încă cele relevante, scenariile sunt încă aplicabile.
Revizuire majoră anuală: 2–3 ore, după testarea anuală. Ce s-a schimbat în firmă în ultimul an? Ce sisteme noi avem? Ce furnizori noi? Ce decizii noi de management?
Aprobare formală anuală de director: nu e doar formalism, e felul în care directorul revede ce decizii a luat anterior și confirmă că sunt încă valide.
Costul construirii unui plan
Pentru o firmă de 80–150 de oameni, construirea de la zero a unui plan funcțional durează 2–3 săptămâni de muncă distribuită. Persoana responsabilă investește 10–15 ore. Echipa de management – 2–3 ore în total, pentru întâlniri și aprobări.
Dacă lucrezi cu un consultant extern care te ghidează prin proces, costul tipic e 4.000–8.000 EUR pentru un plan adaptat firmei tale, plus 1–2 zile/an pentru menținere și testare.
Costul mediu al unui incident gestionat fără plan, pentru aceeași firmă: 250.000–800.000 EUR. Plus reputație, contracte pierdute, plus impactul asupra echipei care a trecut prin săptămâni de criză.
Raportul nu e apropiat. Și totuși, în 8 din 10 firme mid-market din România, planul de continuitate fie nu există, fie e atât de generic încât e inutil. Asta nu e o problemă tehnică — e o decizie de management amânată.
Dacă vrei să construiești un plan de continuitate pentru firma ta
Dacă nu ai un plan de continuitate sau cel existent nu mai reflectă realitatea firmei, poți începe cu o discuție scurtă în care analizăm structura actuală și identificăm prioritățile reale.