Analiza impactului asupra activității pentru ISO 27001, NIS2 și DORA

Întrebarea de audit care expune lacuna reală de continuitate

Este luni dimineață, iar Maria, CISO al unui FinTech cu creștere rapidă, se pregătește pentru o ședință a comitetului de risc al consiliului de administrație. Subiectul e-mailului este scurt: „Pregătire DORA și NIS2: revizuire BIA”.

Echipa ei a construit ceea ce majoritatea directorilor executivi se așteaptă să vadă. Există un Sistem de management al securității informației certificat conform ISO/IEC 27001:2022, playbook-uri de răspuns la incidente, capturi de ecran pentru backup, rapoarte de vulnerabilitate, chestionare pentru furnizori, diagrame de arhitectură cloud și un registru de riscuri actualizat. Clienții enterprise trimit chestionare NIS2. Clienții din sectorul financiar introduc clauze DORA în contracte. Auditul de supraveghere ISO/IEC 27001:2022 este la doar o lună distanță.

Apoi, auditorul extern pune întrebarea care schimbă atmosfera din sală:

„Dacă platforma de onboarding al clienților este indisponibilă timp de 18 ore, ce servicii reglementate sunt afectate, ce furnizori sunt implicați, care este prioritatea de recuperare aprobată și unde sunt dovezile că businessul a acceptat RTO și RPO?”

Sala amuțește.

Programul de backup spune un lucru. Planul de recuperare în caz de dezastru spune altceva. Contractul cu furnizorul include un SLA de disponibilitate, dar nu și dovezi ale testării recuperării. Registrul de riscuri menționează disponibilitatea, dar nu explică de ce un serviciu trebuie recuperat mai rapid decât altul. Conducerea a aprobat politica de securitate, dar nu și impactul timpului de indisponibilitate asupra activității.

Aceasta este problema analizei impactului asupra activității în 2026.

Analiza impactului asupra activității, sau BIA, nu mai este un tabel atașat unui plan de continuitate. Este puntea de dovezi dintre serviciile de business, activele TIC, furnizori, prioritățile de recuperare, RTO/RPO, pragurile de incident, testarea rezilienței și responsabilitatea consiliului de administrație. Pentru organizațiile care aliniază ISO/IEC 27001:2022 cu continuitatea NIS2 și reziliența TIC DORA, BIA este locul în care conformitatea devine operațională.

Cele mai solide organizații au deja multe dintre controalele corecte. Punctul lor slab este trasabilitatea. BIA transformă dovezile dispersate într-o narațiune pregătită pentru audit: ce contează, de ce contează, cât de repede trebuie recuperat, ce dependențe îl susțin, ce a fost testat, ce a eșuat, ce a fost îmbunătățit și cine a aprobat riscul rezidual.

De ce vechile foi de calcul BIA au devenit o vulnerabilitate

NIS2 și DORA au schimbat tonul conformității privind continuitatea. Ele nu tratează continuitatea activității, recuperarea în caz de dezastru, răspunsul la incidente, reziliența furnizorilor și guvernanța ca documente separate. Așteptarea este ca acestea să funcționeze ca un singur sistem.

Pentru entitățile NIS2, Article 21 impune măsuri tehnice, operaționale și organizatorice pentru gestionarea riscurilor la adresa sistemelor de rețea și informatice și pentru prevenirea sau minimizarea impactului incidentelor asupra destinatarilor serviciilor și asupra altor servicii. Măsurile minime includ analiza riscurilor, gestionarea incidentelor, continuitatea activității, inclusiv managementul backup-urilor, recuperarea în caz de dezastru și managementul crizelor, securitatea lanțului de aprovizionare, gestionarea vulnerabilităților, evaluarea eficacității controalelor, instruirea, criptografia, securitatea resurselor umane, controlul accesului, managementul activelor, MFA și comunicațiile securizate.

NIS2 Article 20 mută subiectul în sala consiliului de administrație. Organele de conducere trebuie să aprobe măsurile de management al riscurilor de securitate cibernetică, să supravegheze implementarea și pot fi trase la răspundere pentru încălcări. Aceasta înseamnă că un RTO de patru ore nesusținut de dovezi nu este doar o inconsecvență tehnică. Este o slăbiciune de guvernanță.

DORA se aplică de la 17 ianuarie 2025 și creează un cadru uniform al UE pentru managementul riscurilor TIC, raportarea incidentelor, testarea rezilienței operaționale digitale, managementul riscului asociat terților TIC, cerințe contractuale și supravegherea furnizorilor terți critici de servicii TIC. Pentru entitățile financiare și pentru furnizorii de tehnologie care le susțin prin contracte, DORA transformă reziliența operațională într-o cerință structurată de dovezi.

DORA Articles 5 și 6 impun guvernanță și un cadru documentat de management al riscurilor TIC. Articles 7 până la 14 acoperă sisteme TIC fiabile și reziliente, identificarea activelor și a dependențelor, protecția, detectarea, continuitatea activității TIC, backup-ul, restaurarea, recuperarea, lecțiile învățate după incidente, conștientizarea, instruirea și comunicarea de criză. Articles 24 până la 26 impun testarea rezilienței operaționale digitale pentru entitățile financiare care nu sunt microîntreprinderi. Articles 28 până la 30 formalizează riscul asociat terților TIC, registrele contractelor de servicii TIC, strategiile de ieșire, nivelurile de serviciu, drepturile de audit și acces, precum și cerințele de contingență.

ISO/IEC 27001:2022 oferă coloana vertebrală a sistemului de management. Clauzele sale impun organizației să definească contextul, părțile interesate, obligațiile legale și contractuale, domeniul de aplicare, leadershipul, politica, rolurile, evaluarea riscurilor, tratarea riscurilor, Declarația de aplicabilitate, planificarea operațională, evaluarea performanței și îmbunătățirea continuă.

Veriga lipsă este adesea BIA. Fără aceasta, planurile de continuitate nu sunt fundamentate clar pe risc, obiectivele de backup nu sunt aprobate de business, furnizorii nu sunt cartografiați în raport cu serviciile critice, iar conducerea nu poate demonstra în mod fiabil că deciziile privind reziliența au fost fundamentate pe impactul asupra activității.

BIA ca plan de control pentru dovezile de reziliență

O BIA robustă răspunde la șapte întrebări pe care auditorii, autoritățile de reglementare, clienții și consiliile de administrație le adresează din ce în ce mai des:

1. Ce servicii de business sunt critice?
2. Ce active TIC, depozite de date, persoane, furnizori și utilități susțin fiecare serviciu?
3. Care este impactul operațional, financiar, juridic, contractual, asupra clienților, asupra siguranței și reputațional al întreruperii în timp?
4. Care este perioada maximă de indisponibilitate tolerabilă, sau MTD?
5. Care sunt obiectivul privind timpul de recuperare, sau RTO, și obiectivul privind punctul de recuperare, sau RPO, aprobate?
6. Aranjamentele privind backup-ul, redundanța, cloud-ul, furnizorii, personalul și comunicarea fac aceste obiective realizabile?
7. A testat organizația traseul de recuperare și a revizuit rezultatele?

Politica organizațională Clarysec Politica privind continuitatea activității și recuperarea în caz de dezastru P32 Politica privind continuitatea activității și recuperarea în caz de dezastru formulează cerința în mod clar:

Analiza impactului asupra activității (BIA) trebuie efectuată cel puțin anual pentru toate unitățile de business critice și revizuită atunci când apar modificări semnificative ale sistemelor, proceselor sau dependențelor. Rezultatele BIA trebuie să definească: 5.2.1. Perioada maximă de indisponibilitate tolerabilă (MTD) 5.2.2. Obiectivele privind timpul de recuperare (RTO) 5.2.3. Obiectivele privind punctul de recuperare (RPO) 5.2.4. Dependențele critice (sisteme, furnizori, personal)

Această clauză oferă auditorilor un punct de pornire practic. De asemenea, previne eșecul frecvent în care planul de continuitate a activității, planul de recuperare în caz de dezastru, programul de backup, registrul furnizorilor și procesul de răspuns la incidente folosesc fiecare o definiție diferită a termenului „critic”.

Aceeași politică impune o abordare integrată de management:

Organizația trebuie să mențină un sistem integrat de management al continuității activității (BCMS), aliniat cu ISO 22301 și ISO/IEC 27001, asigurând integrarea următoarelor: 5.1.1. Analiza impactului asupra activității (BIA) 5.1.2. Evaluarea riscurilor de securitate pentru amenințările la adresa continuității 5.1.3. Planuri de continuitate a activității (BCP) 5.1.4. Planuri TIC de recuperare în caz de dezastru (DRP) 5.1.5. Programe de testare și exerciții 5.1.6. Documentație și îmbunătățire continuă

Aceasta este diferența dintre conformitatea bazată pe liste de verificare și reziliența pregătită pentru audit. BIA nu este un document punctual. Ea devine parte din lanțul de dovezi al SMSI și BCMS.

Cum transformă ISO/IEC 27001:2022 BIA în dovezi verificabile

ISO/IEC 27001:2022 nu impune fiecărei organizații să folosească expresia „analiza impactului asupra activității” în fiecare clauză, însă cerințele sale fac ca dovezile BIA să fie extrem de valoroase.

Clauzele 4.1 până la 4.4 impun organizației să înțeleagă aspectele interne și externe, părțile interesate, obligațiile legale și de reglementare, cerințele contractuale, interfețele, dependențele și domeniul de aplicare al SMSI. O BIA este adesea cea mai practică dovadă pentru aceste interfețe și dependențe. Ea arată ce serviciu cloud, procesator de plăți, furnizor de identitate, furnizor telecom, serviciu de securitate administrat, centru de date sau echipă externalizată de suport permite funcționarea unui serviciu critic.

Clauzele 5.1 până la 5.3 impun leadershipul conducerii de vârf, alocarea resurselor, comunicarea, atribuirea rolurilor și raportarea. O BIA oferă conducerii o bază de business pentru investițiile în continuitate. Fără aceasta, obiectivele RTO și RPO sunt dorințe tehnice, nu cerințe de business aprobate.

Clauzele 6.1.1 până la 6.1.3 impun o evaluare repetabilă a riscurilor de securitate a informației și tratarea riscurilor. Organizația trebuie să identifice riscurile la adresa confidențialității, integrității și disponibilității, să analizeze consecințele și probabilitatea, să determine nivelurile de risc, să prioritizeze tratarea riscurilor, să selecteze controale, să compare controalele selectate cu Anexa A, să producă o Declarație de aplicabilitate, să creeze un plan de tratare a riscurilor și să obțină aprobarea proprietarului de risc. O BIA consolidează partea de „consecințe” a evaluării riscurilor. Ea explică de ce o indisponibilitate de două ore a unui sistem este tolerabilă, în timp ce o indisponibilitate de două ore a altuia produce prejudicii clienților, expunere de reglementare, încălcare contractuală sau impact sever asupra veniturilor.

Anexa A oferă catalogul de controale. Pentru BIA și continuitate, cele mai relevante controale ISO/IEC 27001:2022 Anexa A includ:

În Zenith Controls: Ghidul de conformitate transversală Zenith Controls, Clarysec descrie controlul ISO/IEC 27002:2022 5.30, pregătirea TIC pentru continuitatea activității, ca un control corectiv axat pe disponibilitate, mapat la conceptul de securitate cibernetică Respond, la capabilitatea operațională de continuitate și la domeniul de securitate al rezilienței. Controlul 5.29, securitatea informației pe durata întreruperilor, este descris ca preventiv și corectiv, protejând confidențialitatea, integritatea și disponibilitatea. Controlul 8.13, backup-ul informațiilor, este descris ca un control corectiv, care susține integritatea și disponibilitatea prin recuperare.

Această distincție contează. O BIA nu trebuie să întrebe doar: „Putem restaura?” Trebuie să întrebe și: „Putem rămâne securizați în timpul întreruperii?” În timpul unui eveniment ransomware, al unei indisponibilități cloud, al unui eșec al furnizorului sau al unui incident de centru de date, organizația are în continuare nevoie de controlul accesului, jurnalizare, monitorizare, păstrarea dovezilor, comunicații securizate și măsuri de protecție a confidențialității.

Modelul practic de dovezi BIA

O BIA solidă conectează limbajul de business cu dovezile tehnice. Clarysec structurează, de regulă, modelul de dovezi pe cinci niveluri.

Acest model de dovezi funcționează deoarece urmează modul în care gândesc auditorii. Mai întâi întreabă ce este critic. Apoi întreabă ce îl susține. Apoi întreabă cine a aprobat obiectivul de recuperare. Apoi întreabă dacă aranjamentele tehnice și cele cu furnizorii pot îndeplini obiectivul. În final, întreabă dacă organizația a testat și îmbunătățit capabilitatea.

NIST CSF 2.0 este util ca nivel de comunicare. Metoda CSF Profiles încurajează organizațiile să definească domeniul de aplicare, să colecteze intrări precum politici, priorități de risc la nivel organizațional, registre BIA, cerințe de securitate cibernetică, standarde, proceduri, măsuri de protecție și roluri de lucru, să creeze profiluri curente și țintă, să analizeze lacunele, să producă un plan de acțiune prioritizat, să implementeze acel plan și să actualizeze profilul. Acesta este aproape exact modul în care o BIA trebuie să alimenteze o foaie de parcurs de conformitate transversală.

Un exercițiu BIA de o săptămână care creează dovezi reale

Să presupunem că un furnizor SaaS susține clienți din servicii financiare. Platforma sa susține onboardingul clienților, verificarea documentelor și notificările către clienți. Nu este ea însăși o bancă, dar clienții săi trimit solicitări contractuale determinate de DORA și chestionare NIS2 pentru furnizori.

Un exercițiu concentrat de o săptămână poate crea rapid dovezi utile.

Ziua 1: Identificați serviciile critice și ferestrele de impact

Începeți cu serviciile, nu cu serverele. Implicați proprietarii de business, IT, securitatea, juridicul, suportul, confidențialitatea și managementul furnizorilor.

Această încadrare este importantă. Autoritățile de reglementare și clienții recunosc servicii și funcții. Aplicațiile contează deoarece susțin aceste servicii.

Ziua 2: Cartografiați dependențele

Pentru fiecare serviciu, cartografiați aplicațiile, bazele de date, infrastructura, serviciile cloud, furnizorii de identitate, monitorizarea, instrumentele de backup, persoanele, furnizorii și utilitățile suport.

Aici începe BIA să producă valoare. Ea dezvăluie traseul invizibil de recuperare, inclusiv dependențele care sunt adesea omise într-un plan DR tehnic.

Ziua 3: Aprobați MTD, RTO și RPO

Proprietarul de business propune MTD. IT și securitatea validează dacă RTO și RPO propuse sunt realizabile tehnic. Conducerea aprobă obiectivele finale.

Pentru organizațiile mai mici, Politica privind continuitatea activității și recuperarea în caz de dezastru - IMM Clarysec P32S Politica privind continuitatea activității și recuperarea în caz de dezastru - IMM oferă aceeași disciplină într-un limbaj mai simplu. Aceasta impune planuri BCP/DR care stabilesc abordarea pentru restaurarea funcțiilor esențiale:

Directorul general (GM) trebuie să aprobe și să mențină planuri de continuitate a activității și de recuperare în caz de dezastru (BCP/DRP) care stabilesc clar abordarea organizației pentru restaurarea funcțiilor esențiale.

De asemenea, planul trebuie să includă:

servicii și sisteme prioritizate (funcții critice de business)

Și:

Obiective privind timpul de recuperare (RTO) și Obiective privind punctul de recuperare (RPO) pentru fiecare sistem

Cheia nu este documentația excesivă. Cheia este trasabilitatea, aprobarea și dovezile că obiectivele de recuperare sunt bazate pe impact real asupra activității.

Ziua 4: Reconciliați backup-ul cu impactul asupra activității

Multe organizații eșuează aici. BIA poate stabili un RPO de patru ore, în timp ce backup-urile rulează la fiecare 24 de ore. Sau instrumentul de backup protejează bazele de date de producție, dar nu și configurația, secretele, depozitele infrastructure-as-code, stocarea de obiecte, înregistrările DNS, setările de identitate sau configurația API gateway.

Politica de backup și restaurare Clarysec P15 Politica de backup și restaurare impune un program general de backup corelat cu rezultatele BIA:

Trebuie menținut și revizuit anual un program general de backup. Acesta trebuie să specifice: 5.1.1 Frecvența backup-ului (de exemplu, backup-uri incrementale zilnice și backup-uri complete săptămânale) 5.1.2 Perioadele de retenție pe sistem sau tip de date 5.1.3 Cerințele de criptare și detaliile privind locația de stocare 5.1.4 Obiective RTO/RPO corelate cu rezultatele evaluării impactului asupra activității

Această clauză este aur pentru audit. Ea obligă proiectarea backup-ului să reflecte impactul asupra activității, nu comoditatea stocării.

Ziua 5: Testați un traseu de recuperare și deschideți acțiuni corective

Nu testați totul deodată. Alegeți un serviciu critic și rulați un test de recuperare concentrat. Restaurați baza de date. Reconstruiți configurația aplicației. Validați autentificarea. Confirmați că jurnalele sunt disponibile. Verificați capabilitatea de notificare a clienților. Înregistrați timpul necesar, pierderea de date, defectele, deciziile și acțiunile corective.

În Zenith Blueprint: Foaia de parcurs în 30 de pași a auditorului Zenith Blueprint, faza Controale în acțiune, pasul 23, abordează controalele organizaționale, inclusiv pregătirea TIC pentru continuitatea activității. Acesta pune întrebarea pe care fiecare echipă de audit ar trebui să o adreseze:

Pot sistemele dumneavoastră să susțină obiectivele de continuitate a activității atunci când apar fluctuații de alimentare, când rețelele cad, când lovește dezastrul?

Același pas oferă o instrucțiune practică:

Verificați că obiectivele privind timpul de recuperare (RTO) și obiectivele privind punctul de recuperare (RPO) pentru sistemele critice sunt aliniate cu așteptările de continuitate a activității (5.30). Efectuați cel puțin un test tehnic de recuperare sau o simulare de failover și documentați rezultatele.

Aceasta este diferența dintre a avea o BIA și a avea dovezi BIA robuste. Obiectivul nu este doar documentat. Este testat.

Maparea dovezilor BIA la NIS2, DORA, GDPR, NIST și COBIT 2019

O BIA bine construită devine un activ de conformitate transversală. Un singur set de dovezi poate răspunde la multe întrebări.

GDPR este adesea trecut cu vederea în discuțiile despre BIA. Totuși, GDPR Article 5 impune ca datele cu caracter personal să fie prelucrate cu integritate și confidențialitate, inclusiv protecție împotriva pierderii, distrugerii sau deteriorării accidentale prin măsuri tehnice sau organizatorice adecvate. Responsabilitatea impune operatorului de date să demonstreze conformitatea. Dacă o platformă de date cu caracter personal nu poate fi restaurată într-un interval aprobat și testat, riscul privind confidențialitatea afectează disponibilitatea, integritatea, evaluarea încălcării și încrederea clienților.

Raportarea incidentelor NIS2 adaugă o altă dimensiune. Article 23 impune notificarea incidentelor semnificative fără întârzieri nejustificate, inclusiv o avertizare timpurie în termen de 24 de ore, notificarea incidentului în termen de 72 de ore și raportarea finală în termen de o lună. O BIA ajută la clasificarea severității deoarece definește serviciile afectate, destinatarii serviciilor, întreruperea operațională și potențialul impact transfrontalier.

Clasificarea incidentelor DORA ia în considerare, de asemenea, clienții sau tranzacțiile afectate, durata, răspândirea geografică, pierderile de date, criticitatea serviciilor afectate și impactul economic. Acestea sunt câmpuri BIA. Dacă BIA este slabă, clasificarea incidentelor devine subiectivă exact în cel mai nepotrivit moment.

Continuitatea furnizorilor este locul în care BIA întâlnește realitatea contractuală

Pentru NIS2 și DORA, continuitatea furnizorilor nu mai este opțională. NIS2 Article 21 include securitatea lanțului de aprovizionare și impune atenție asupra vulnerabilităților furnizorilor, calității și rezilienței produselor, practicilor de securitate cibernetică ale furnizorilor și procedurilor de dezvoltare securizată. DORA impune gestionarea riscului asociat terților TIC în cadrul de management al riscurilor TIC, inclusiv registre ale contractelor de servicii TIC, verificare prealabilă, risc de concentrare, strategii de ieșire, drepturi de audit și acces, asistență în caz de incident, niveluri de serviciu și cerințe de contingență.

Politica organizațională Politica privind continuitatea activității și recuperarea în caz de dezastru impune:

Dependențe de terți și de lanțul de aprovizionare 6.5.1. Contractele cu furnizori critici trebuie să includă obligații privind continuitatea și angajamente privind timpii de recuperare. 6.5.2. Furnizorii-cheie de servicii trebuie, la cerere, să demonstreze testarea periodică a continuității și participarea la exerciții de incident.

Versiunea pentru IMM impune, de asemenea:

puncte de contact pentru continuitatea furnizorilor

Acest câmp mic poate fi decisiv într-un incident real. Dacă planul de recuperare spune „contactați suportul furnizorului cloud”, dar nimeni nu cunoaște calea de escaladare, referința contractuală, procesul de severitate sau contactul în afara programului, RTO este o ficțiune.

Acest tabel nu înlocuiește managementul riscului asociat furnizorilor. Îl face operațional.

Cum vă vor testa auditorii BIA

Un auditor ISO/IEC 27001:2022 va începe de obicei cu domeniul de aplicare, contextul, evaluarea riscurilor, tratarea riscurilor, Declarația de aplicabilitate, controalele din Anexa A, informațiile documentate, planificarea operațională, evaluarea performanței și îmbunătățirea. Va compara BIA cu evaluarea riscurilor și SoA. Dacă A.5.30, A.5.29 sau A.8.13 sunt incluse, va solicita dovezi de implementare și testare.

Un evaluator DORA se va concentra pe funcții critice sau importante, active TIC, dependențe de terți TIC, testarea rezilienței, clasificarea incidentelor, cerințe contractuale, strategii de ieșire și supravegherea de către organismul de conducere. Se va aștepta ca BIA să fie aliniată cu cadrul de management al riscurilor TIC, strategia de reziliență operațională digitală, planurile TIC de continuitate a activității, planurile de răspuns și recuperare și programul de testare.

Un supraveghetor NIS2 va solicita măsuri de continuitate a activității, managementul backup-urilor, recuperare în caz de dezastru, managementul crizelor, securitatea lanțului de aprovizionare, aprobarea guvernanței și capabilitatea de raportare a incidentelor semnificative. BIA trebuie să demonstreze că aceste măsuri se bazează pe impactul asupra serviciilor și pe priorități aprobate.

Un evaluator NIST CSF 2.0 va întreba cum informează BIA profilul curent, profilul țintă, analiza lacunelor și planul de acțiune. Va analiza rezultatele Govern pentru decizii juridice, de reglementare, contractuale, de risc, de rol, de politică, de supraveghere și de risc asociat furnizorilor. Va examina, de asemenea, rezultatele Identify, Protect, Detect, Respond și Recover.

Un auditor COBIT 2019 sau de tip ISACA se va concentra, de regulă, pe guvernanță. Cine deține serviciul? Cine a acceptat riscul? Sunt obiectivele aliniate cu obiectivele organizaționale? Sunt furnizorii monitorizați? Sunt beneficiile, riscul și resursele echilibrate? Sunt acțiunile corective urmărite până la închidere?

Politica de audit și monitorizare a conformității Clarysec Politica de audit și monitorizare a conformității face din BIA parte a ciclului de planificare a auditului:

Un plan de audit bazat pe risc trebuie elaborat și aprobat anual, luând în considerare: 5.2.1 Rezultatele celor mai recente evaluări de risc și ale analizei impactului asupra activității (BIA) 5.2.2 Constatările de audit anterioare și starea acțiunilor corective 5.2.3 Modificările proceselor, infrastructurii IT, sistemelor sau furnizorilor 5.2.4 Obligațiile externe, cum ar fi DORA Article 25 sau contractele cu clienții

Acesta este un pas de maturitate pe care multe organizații îl ratează. BIA nu trebuie să stea în afara asigurării. Ea trebuie să conducă planul de audit.

Eșecuri BIA frecvente identificate în evaluări reale

Aceleași slăbiciuni apar în mod repetat.

În primul rând, BIA listează aplicații, nu servicii. Clienții și autoritățile de reglementare sunt preocupați de întreruperea serviciilor. Aplicațiile contează deoarece susțin aceste servicii.

În al doilea rând, obiectivele RTO și RPO sunt copiate din șabloane. Un RTO de patru ore poate părea rezonabil până când un test de restaurare arată că sunt necesare nouă ore pentru a reconstrui integrarea identității, a recupera configurația, a restaura datele, a valida integritatea și a reactiva monitorizarea.

În al treilea rând, backup-urile nu sunt corelate cu impactul asupra activității. Frecvența, retenția, criptarea, locația de stocare, prioritatea de restaurare și testarea trebuie să reflecte obiectivele de recuperare aprobate.

În al patrulea rând, furnizorii sunt tratați ca elemente de chestionar, nu ca dependențe de recuperare. Angajamentele privind continuitatea furnizorilor, contactele de escaladare, dovezile de recuperare și participarea la exerciții de incident trebuie legate de serviciile critice.

În al cincilea rând, aprobarea conducerii lipsește. În temeiul NIS2 și DORA, responsabilitatea conducerii este explicită. În temeiul ISO/IEC 27001:2022, leadershipul, rolurile, aprobarea proprietarului de risc și raportarea performanței sunt cerințe de bază.

În al șaselea rând, testarea este prea îngustă. Restaurarea unui fișier este utilă, dar nu demonstrează recuperarea serviciului. Traseul de recuperare al unui serviciu critic poate include DNS, identitate, secrete, infrastructure-as-code, API gateways, monitorizare, jurnalizare, escaladarea furnizorilor, comunicarea cu clienții și revizuirea privind confidențialitatea.

Zenith Blueprint, în faza Controale în acțiune, pasul 19, surprinde așteptarea de audit pentru backup-uri:

Vă testați backup-urile?

Răspunsul trebuie să fie „da, cu dovezi”, iar aceste dovezi trebuie să se conecteze înapoi la BIA.

Pachetul de dovezi BIA pregătit pentru audit

Un program BIA practic trebuie să producă un pachet concis de dovezi care poate fi utilizat pentru audituri, verificarea prealabilă a clienților, raportarea către consiliul de administrație și îmbunătățirea rezilienței.

Acest pachet spune o poveste coerentă. De asemenea, face reziliența măsurabilă.

Pasul următor: transformați BIA în dovezi de conformitate

Maria nu are nevoie de un tabel mai mare. Are nevoie de un lanț de dovezi viu.

Începeți cu un serviciu critic. Cartografiați activele TIC, datele, persoanele, furnizorii și utilitățile care îl susțin. Aprobați MTD, RTO și RPO. Reconciliați programul de backup. Verificați angajamentele furnizorilor privind recuperarea. Rulați un test de recuperare. Înregistrați lacunele. Actualizați planul de tratare a riscurilor. Prezentați rezultatul conducerii.

Apoi repetați.

Clarysec poate ajuta la accelerarea acestui proces utilizând Politica privind continuitatea activității și recuperarea în caz de dezastru, Politica privind continuitatea activității și recuperarea în caz de dezastru - IMM, Politica de backup și restaurare, Politica de audit și monitorizare a conformității, Zenith Blueprint și Zenith Controls.

BIA nu trebuie să fie documentație de raft creată pentru audit. Trebuie să fie dovada operațională că cele mai importante servicii pot supraviețui întreruperilor, pot îndeplini așteptările clienților și ale autorităților de reglementare și se pot recupera în limitele aprobate efectiv de conducerea dumneavoastră.

Dacă organizația dumneavoastră se pregătește pentru supraveghere ISO/IEC 27001:2022, asigurarea clienților NIS2, revizuiri DORA pentru terți TIC sau raportare privind reziliența la nivelul consiliului de administrație, începeți prin a face BIA robustă. Descărcați politicile Clarysec de continuitate și audit, revizuiți foaia de parcurs de implementare Zenith sau solicitați o evaluare a dovezilor de reziliență pentru a transforma controalele dispersate într-o narațiune unică, pregătită pentru audit.