Verslo poveikio analizė ISO 27001, NIS2 ir DORA kontekste

Audito klausimas, atskleidžiantis tikrąją veiklos tęstinumo spragą

Pirmadienio rytas. Sparčiai augančios FinTech įmonės vyriausioji informacijos saugumo vadovė (CISO) Maria rengiasi valdybos rizikos komiteto posėdžiui. El. laiško tema trumpa: „DORA ir NIS2 pasirengimas: BIA peržiūra.“

Jos komanda parengė tai, ką dauguma vadovų tikisi matyti: sertifikuotą ISO/IEC 27001:2022 ISVS, reagavimo į incidentus planus, atsarginių kopijų ekrano kopijas, pažeidžiamumų ataskaitas, tiekėjų klausimynus, debesijos architektūros schemas ir atnaujintą rizikų registrą. Įmonių klientai siunčia NIS2 klausimynus. Finansų sektoriaus klientai į sutartis įtraukia DORA nuostatas. Iki ISO/IEC 27001:2022 priežiūros audito liko tik mėnuo.

Tada išorės auditorius užduoda klausimą, kuris pakeičia visą pokalbio eigą:

„Jei jūsų klientų prijungimo platforma būtų nepasiekiama 18 valandų, kurios reglamentuojamos paslaugos būtų paveiktos, kurie tiekėjai būtų įtraukti, koks yra patvirtintas atkūrimo prioritetas ir kur yra įrodymai, kad verslas patvirtino RTO ir RPO?“

Patalpoje įsivyrauja tyla.

Atsarginių kopijų grafikas sako viena. Atkūrimo po katastrofos planas – kita. Tiekėjo sutartyje yra prieinamumo SLA, bet nėra atkūrimo testo įrodymų. Rizikų registre minima prieinamumo rizika, tačiau nepaaiškinama, kodėl viena paslauga turi būti atkurta greičiau nei kita. Vadovybė patvirtino saugumo politiką, bet ne prastovos verslo poveikį.

Tai yra 2026 m. verslo poveikio analizės problema.

Verslo poveikio analizė, arba BIA, nebėra skaičiuoklė, prisegta prie veiklos tęstinumo plano. Tai įrodymų jungtis tarp verslo paslaugų, IRT turto, tiekėjų, atkūrimo prioritetų, RTO/RPO, incidentų slenksčių, atsparumo testavimo ir valdybos atskaitomybės. Organizacijoms, derinančioms ISO/IEC 27001:2022 su NIS2 veiklos tęstinumu ir DORA IRT atsparumu, BIA yra vieta, kurioje atitiktis tampa veiklos praktika.

Stipriausios organizacijos jau turi daug tinkamų kontrolės priemonių. Jų silpnoji vieta – atsekamumas. BIA išskaidytus įrodymus paverčia auditui tinkama istorija: kas svarbu, kodėl tai svarbu, kaip greitai turi būti atkurta, kokios priklausomybės tai palaiko, kas buvo testuota, kas nepavyko, kas buvo patobulinta ir kas patvirtino likutinę riziką.

Kodėl senos BIA skaičiuoklės dabar tampa atsakomybės rizika

NIS2 ir DORA pakeitė veiklos tęstinumo atitikties toną. Jos nelaiko veiklos tęstinumo, atkūrimo po katastrofos, reagavimo į incidentus, tiekėjų atsparumo ir valdysenos atskirais dokumentais. Tikimasi, kad jie veiks kaip viena sistema.

NIS2 subjektams Article 21 reikalauja techninių, operacinių ir organizacinių priemonių tinklų ir informacinių sistemų rizikoms valdyti ir incidentų poveikiui paslaugų gavėjams bei kitoms paslaugoms užkirsti kelią arba jį sumažinti. Minimalios priemonės apima rizikos analizę, incidentų valdymą, veiklos tęstinumą, įskaitant atsarginių kopijų valdymą, atkūrimą po katastrofos ir krizių valdymą, tiekimo grandinės saugumą, pažeidžiamumų valdymą, kontrolės priemonių veiksmingumo vertinimą, mokymus, kriptografiją, žmogiškųjų išteklių saugumą, prieigos kontrolę, turto valdymą, MFA ir saugią komunikaciją.

NIS2 Article 20 šį klausimą perkelia į valdybos lygmenį. Valdymo organai turi patvirtinti kibernetinio saugumo rizikos valdymo priemones, prižiūrėti jų įgyvendinimą ir gali būti laikomi atsakingais už pažeidimus. Tai reiškia, kad nepagrįstas keturių valandų RTO nėra vien techninis neatitikimas. Tai valdysenos silpnybė.

DORA taikomas nuo 2025 m. sausio 17 d. ir sukuria vieningą ES IRT rizikos valdymo, incidentų pranešimo, skaitmeninės veiklos atsparumo testavimo, IRT trečiųjų šalių rizikos valdymo, sutartinių reikalavimų ir kritinių IRT trečiųjų šalių paslaugų teikėjų priežiūros sistemą. Finansų subjektams ir technologijų paslaugų teikėjams, kurie juos palaiko pagal sutartis, DORA veiklos atsparumą paverčia struktūrizuotu įrodymų reikalavimu.

DORA Articles 5 ir 6 reikalauja valdysenos ir dokumentuotos IRT rizikos valdymo sistemos. Articles 7–14 apima patikimas ir atsparias IRT sistemas, turto ir priklausomybių identifikavimą, apsaugą, aptikimą, IRT veiklos tęstinumą, atsargines kopijas, atkūrimą, mokymąsi po incidentų, informuotumą, mokymus ir krizių komunikaciją. Articles 24–26 reikalauja skaitmeninės veiklos atsparumo testavimo finansų subjektams, kurie nėra labai mažos įmonės. Articles 28–30 formalizuoja IRT trečiųjų šalių riziką, IRT paslaugų sutarčių registrus, pasitraukimo strategijas, paslaugų lygius, audito teises ir nenumatytų atvejų reikalavimus.

ISO/IEC 27001:2022 suteikia valdymo sistemos pagrindą. Jo skyriai reikalauja, kad organizacija apibrėžtų kontekstą, suinteresuotąsias šalis, teisines ir sutartines prievoles, taikymo sritį, lyderystę, politiką, vaidmenis, rizikos vertinimą, rizikos tvarkymą, Taikomumo pareiškimą, veiklos planavimą, veiklos rezultatų vertinimą ir nuolatinį tobulinimą.

Trūkstama grandis dažnai yra BIA. Be jos veiklos tęstinumo planai nėra aiškiai grindžiami rizika, atsarginių kopijų tikslai nėra patvirtinti verslo, tiekėjai nėra susieti su kritinėmis paslaugomis, o vadovybė negali patikimai parodyti, kad atsparumo sprendimai priimti remiantis verslo poveikiu.

BIA kaip atsparumo įrodymų valdymo lygmuo

Pagrįsta BIA atsako į septynis klausimus, kuriuos vis dažniau užduoda auditoriai, reguliuotojai, klientai ir valdybos:

1. Kurios verslo paslaugos yra kritinės?
2. Koks IRT turtas, duomenų saugyklos, žmonės, tiekėjai ir inžinerinės paslaugos palaiko kiekvieną paslaugą?
3. Koks yra veiklos, finansinis, teisinis, sutartinis, klientų, saugos ir reputacinis sutrikimo poveikis laikui bėgant?
4. Kokia yra maksimaliai toleruotina prastovos trukmė, arba MTD?
5. Kokie yra patvirtinti atkūrimo laiko tikslas, arba RTO, ir atkūrimo taško tikslas, arba RPO?
6. Ar atsarginių kopijų, perteklumo, debesijos, tiekėjų, personalo ir komunikacijos priemonės leidžia pasiekti šiuos tikslus?
7. Ar organizacija testavo atkūrimo kelią ir peržiūrėjo rezultatus?

Clarysec įmonių Veiklos tęstinumo ir atkūrimo po katastrofos politika P32 Veiklos tęstinumo ir atkūrimo po katastrofos politika reikalavimą suformuluoja aiškiai:

Verslo poveikio analizė (BIA) turi būti atliekama bent kartą per metus visiems kritiniams verslo padaliniams ir peržiūrima įvykus reikšmingiems sistemų, procesų ar priklausomybių pokyčiams. BIA rezultatai turi apibrėžti: 5.2.1. Maksimaliai toleruotiną prastovos trukmę (MTD) 5.2.2. Atkūrimo laiko tikslus (RTO) 5.2.3. Atkūrimo taško tikslus (RPO) 5.2.4. Kritines priklausomybes (sistemas, tiekėjus, personalą)

Ši nuostata auditoriams suteikia praktinį atspirties tašką. Ji taip pat užkerta kelią dažnai klaidai, kai veiklos tęstinumo planas, atkūrimo po katastrofos planas, atsarginių kopijų grafikas, tiekėjų registras ir reagavimo į incidentus procesas naudoja skirtingą sąvokos „kritinis“ apibrėžimą.

Ta pati politika reikalauja integruoto valdymo požiūrio:

Organizacija turi palaikyti integruotą veiklos tęstinumo valdymo sistemą (BCMS), suderintą su ISO 22301 ir ISO/IEC 27001, užtikrindama šių elementų integravimą: 5.1.1. Verslo poveikio analizė (BIA) 5.1.2. Saugumo rizikos vertinimas dėl veiklos tęstinumo grėsmių 5.1.3. Veiklos tęstinumo planai (BCP) 5.1.4. IRT atkūrimo po katastrofos planai (DRP) 5.1.5. Testavimo ir pratybų programos 5.1.6. Dokumentacija ir nuolatinis tobulinimas

Tai yra skirtumas tarp kontrolinio sąrašo atitikties ir auditui parengto atsparumo. BIA nėra vienkartinis dokumentas. Ji tampa ISVS ir BCMS įrodymų grandinės dalimi.

Kaip ISO/IEC 27001:2022 paverčia BIA audituojamais įrodymais

ISO/IEC 27001:2022 nereikalauja, kad kiekviena organizacija kiekviename skyriuje vartotų frazę „verslo poveikio analizė“, tačiau jo reikalavimai daro BIA įrodymus itin vertingus.

4.1–4.4 skyriai reikalauja, kad organizacija suprastų vidaus ir išorės klausimus, suinteresuotąsias šalis, teisines ir reglamentavimo prievoles, sutartinius reikalavimus, sąsajas, priklausomybes ir ISVS taikymo sritį. BIA dažnai yra praktiškiausias šių sąsajų ir priklausomybių įrodymas. Ji parodo, kuri debesijos paslauga, mokėjimų tvarkytojas, tapatybės teikėjas, telekomunikacijų paslaugų teikėjas, valdoma saugumo paslauga, duomenų centras ar išorės pagalbos komanda leidžia teikti kritinę paslaugą.

5.1–5.3 skyriai reikalauja aukščiausiosios vadovybės lyderystės, išteklių skyrimo, komunikacijos, vaidmenų priskyrimo ir ataskaitų teikimo. BIA suteikia vadovybei verslo pagrindą investicijoms į veiklos tęstinumą. Be jos RTO ir RPO tikslai yra techniniai pageidavimai, o ne patvirtinti verslo reikalavimai.

6.1.1–6.1.3 skyriai reikalauja pakartojamo informacijos saugumo rizikos vertinimo ir tvarkymo. Organizacija turi identifikuoti rizikas konfidencialumui, vientisumui ir prieinamumui, analizuoti pasekmes ir tikimybę, nustatyti rizikos lygius, prioritetizuoti rizikos tvarkymą, pasirinkti kontrolės priemones, palyginti pasirinktas kontrolės priemones su Annex A, parengti Taikomumo pareiškimą, sudaryti rizikos tvarkymo planą ir gauti rizikos savininko patvirtinimą. BIA sustiprina rizikos vertinimo „pasekmių“ dalį. Ji paaiškina, kodėl vienos sistemos dviejų valandų prastova yra toleruotina, o kitos sistemos dviejų valandų prastova sukelia žalą klientams, reglamentavimo riziką, sutarties pažeidimą ar reikšmingą pajamų poveikį.

Annex A pateikia kontrolės priemonių katalogą. BIA ir veiklos tęstinumui aktualiausios ISO/IEC 27001:2022 Annex A kontrolės priemonės yra:

Zenith Controls: The Cross-Compliance Guide Zenith Controls Clarysec ISO/IEC 27002:2022 kontrolės priemonę 5.30, IRT pasirengimą veiklos tęstinumui, aprašo kaip korekcinę kontrolės priemonę, orientuotą į prieinamumą, susietą su Respond kibernetinio saugumo koncepcija, veiklos tęstinumo veiklos pajėgumu ir atsparumo saugumo sritimi. Kontrolės priemonė 5.29, informacijos saugumas sutrikimo metu, aprašoma kaip prevencinė ir korekcinė, sauganti konfidencialumą, vientisumą ir prieinamumą. Kontrolės priemonė 8.13, informacijos atsarginės kopijos, aprašoma kaip korekcinė, palaikanti vientisumą ir prieinamumą atkūrimo metu.

Šis skirtumas svarbus. BIA turi klausti ne tik „Ar galime atkurti?“ Ji taip pat turi klausti „Ar galime išlikti saugūs sutrikimo metu?“ Išpirkos reikalaujančios programinės įrangos įvykio, debesijos sutrikimo, tiekėjo nesėkmės ar duomenų centro incidento metu organizacijai vis dar reikia prieigos kontrolės, žurnalavimo, stebėsenos, įrodymų išsaugojimo, saugios komunikacijos ir privatumo apsaugos priemonių.

Praktinis BIA įrodymų modelis

Stipri BIA susieja verslo kalbą su techniniais įrodymais. Clarysec įrodymų modelį paprastai struktūrizuoja penkiais sluoksniais.

Šis įrodymų modelis veikia, nes atitinka auditorių mąstymo logiką. Pirmiausia jie klausia, kas yra kritiška. Tada klausia, kas tai palaiko. Tada klausia, kas patvirtino atkūrimo tikslą. Tada klausia, ar techninės ir tiekėjų priemonės gali tą tikslą pasiekti. Galiausiai klausia, ar organizacija testavo ir patobulino pajėgumą.

NIST CSF 2.0 yra naudinga kaip komunikacijos sluoksnis. Jo CSF profilių metodas skatina organizacijas apibrėžti taikymo sritį, surinkti įvestis, tokias kaip politikos, įmonės rizikos prioritetai, BIA registrai, kibernetinio saugumo reikalavimai, standartai, procedūros, apsaugos priemonės ir darbo vaidmenys, sukurti esamus ir tikslinius profilius, analizuoti spragas, parengti prioritetizuotą veiksmų planą, jį įgyvendinti ir atnaujinti profilį. Tai beveik tiksliai atitinka būdą, kuriuo BIA turėtų maitinti kompleksinės atitikties veiksmų planą.

Vienos savaitės BIA pratybos, sukuriančios realius įrodymus

Tarkime, SaaS teikėjas palaiko finansinių paslaugų klientus. Jo platforma palaiko klientų prijungimą, dokumentų tikrinimą ir klientų pranešimus. Jis pats nėra bankas, tačiau jo klientai siunčia DORA pagrįstas sutartines užklausas ir NIS2 tiekėjų klausimynus.

Tikslingos vienos savaitės pratybos gali greitai sukurti naudingų įrodymų.

1 diena: identifikuokite kritines paslaugas ir poveikio langus

Pradėkite nuo paslaugų, o ne nuo serverių. Įtraukite verslo savininkus, IT, saugumą, teisės, palaikymo, privatumo ir tiekėjų valdymo funkcijas.

Toks įrėminimas svarbus. Reguliuotojai ir klientai atpažįsta paslaugas ir funkcijas. Taikomosios programos svarbios todėl, kad palaiko šias paslaugas.

2 diena: atvaizduokite priklausomybes

Kiekvienai paslaugai atvaizduokite taikomąsias programas, duomenų bazes, infrastruktūrą, debesijos paslaugas, tapatybės teikėjus, stebėseną, atsarginių kopijų įrankius, žmones, tiekėjus ir palaikančias inžinerines paslaugas.

Čia BIA pradeda kurti vertę. Ji atskleidžia nematomą atkūrimo kelią, įskaitant priklausomybes, kurios dažnai praleidžiamos techniniame DR plane.

3 diena: patvirtinkite MTD, RTO ir RPO

Verslo savininkas pasiūlo MTD. IT ir saugumo komandos validuoja, ar siūlomi RTO ir RPO yra techniškai pasiekiami. Vadovybė patvirtina galutinius tikslus.

Mažesnėms organizacijoms Clarysec Veiklos tęstinumo ir atkūrimo po katastrofos politika – MVĮ P32S Veiklos tęstinumo ir atkūrimo po katastrofos politika – MVĮ suteikia tą pačią discipliną paprastesne kalba. Ji reikalauja BCP/DR planų, kurie nustato požiūrį į esminių funkcijų atkūrimą:

Generalinis direktorius privalo patvirtinti ir palaikyti veiklos tęstinumo ir atkūrimo po katastrofos planus (BCP/DRP), kuriuose aiškiai nustatytas organizacijos požiūris į esminių funkcijų atkūrimą.

Ji taip pat reikalauja, kad planas apimtų:

prioritetizuotas paslaugas ir sistemas (kritines verslo funkcijas)

Ir:

kiekvienos sistemos atkūrimo laiko tikslus (RTO) ir atkūrimo taško tikslus (RPO)

Svarbiausia ne perteklinė dokumentacija. Svarbiausia – atsekamumas, patvirtinimas ir įrodymai, kad atkūrimo tikslai grindžiami realiu verslo poveikiu.

4 diena: suderinkite atsargines kopijas su verslo poveikiu

Daug organizacijų čia suklysta. BIA gali nustatyti keturių valandų RPO, o atsarginės kopijos daromos kas 24 valandas. Arba atsarginių kopijų įrankis saugo produkcines duomenų bazes, bet ne konfigūraciją, paslaptis, infrastruktūros kaip kodo saugyklas, objektinę saugyklą, DNS įrašus, tapatybės nustatymus ar API šliuzo konfigūraciją.

Clarysec Atsarginių kopijų ir atkūrimo politika P15 Atsarginių kopijų ir atkūrimo politika reikalauja pagrindinio atsarginių kopijų grafiko, susieto su BIA rezultatais:

Pagrindinis atsarginių kopijų grafikas turi būti palaikomas ir peržiūrimas kasmet. Jame turi būti nurodyta: 5.1.1 Atsarginių kopijų dažnumas (pavyzdžiui, kasdienės prieauginės atsarginės kopijos ir savaitinės pilnos atsarginės kopijos) 5.1.2 Saugojimo laikotarpiai pagal sistemą arba duomenų tipą 5.1.3 Šifravimo reikalavimai ir saugojimo vietos duomenys 5.1.4 RTO/RPO tikslai, susieti su verslo poveikio vertinimo rezultatais

Ši nuostata auditui yra itin vertinga. Ji verčia atsarginių kopijų projektavimą atspindėti verslo poveikį, o ne saugyklos patogumą.

5 diena: testuokite vieną atkūrimo kelią ir inicijuokite korekcinius veiksmus

Netestuokite visko vienu metu. Pasirinkite vieną kritinę paslaugą ir atlikite tikslingą atkūrimo testą. Atkurkite duomenų bazę. Iš naujo sukurkite taikomosios programos konfigūraciją. Validuokite autentifikavimą. Patvirtinkite, kad žurnalai pasiekiami. Patikrinkite klientų pranešimų pajėgumą. Užfiksuokite sugaištą laiką, duomenų praradimą, trūkumus, sprendimus ir korekcinius veiksmus.

Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint etape „Controls in Action“, 23 žingsnyje, nagrinėjamos organizacinės kontrolės priemonės, įskaitant IRT pasirengimą veiklos tęstinumui. Jame užduodamas klausimas, kurį turėtų užduoti kiekviena audito komanda:

Ar jūsų sistemos gali palaikyti veiklos tęstinumo tikslus, kai „mirkteli šviesos“, kai tinklai neveikia, kai ištinka katastrofa?

Tas pats žingsnis pateikia praktinę instrukciją:

Patikrinkite, ar kritinių sistemų atkūrimo laiko tikslai (RTO) ir atkūrimo taško tikslai (RPO) atitinka veiklos tęstinumo lūkesčius (5.30). Atlikite bent vieną techninį atkūrimo testą arba perjungimo į rezervinę aplinką simuliaciją ir dokumentuokite rezultatus.

Tai skirtumas tarp BIA turėjimo ir pagrįstų BIA įrodymų turėjimo. Tikslas ne tik dokumentuotas. Jis testuotas.

BIA įrodymų susiejimas su NIS2, DORA, GDPR, NIST ir COBIT 2019

Gerai sukurta BIA tampa kompleksinės atitikties ištekliumi. Vienas įrodymų rinkinys gali atsakyti į daugelį klausimų.

GDPR BIA diskusijose dažnai pamirštamas. Tačiau GDPR Article 5 reikalauja, kad asmens duomenys būtų tvarkomi užtikrinant vientisumą ir konfidencialumą, įskaitant apsaugą nuo atsitiktinio praradimo, sunaikinimo ar sugadinimo taikant tinkamas technines arba organizacines priemones. Atskaitomybė reikalauja, kad duomenų valdytojas galėtų įrodyti atitiktį. Jei asmens duomenų platformos negalima atkurti per patvirtintą ir testuotą laikotarpį, privatumo rizika paveikia prieinamumą, vientisumą, pažeidimo vertinimą ir klientų pasitikėjimą.

NIS2 pranešimas apie incidentus prideda dar vieną dimensiją. Article 23 reikalauja apie reikšmingus incidentus pranešti nepagrįstai nedelsiant, įskaitant ankstyvą įspėjimą per 24 valandas, pranešimą apie incidentą per 72 valandas ir galutinę ataskaitą per vieną mėnesį. BIA padeda klasifikuoti sunkumą, nes apibrėžia paveiktas paslaugas, paslaugų gavėjus, veiklos sutrikimą ir galimą tarpvalstybinį poveikį.

DORA incidentų klasifikavime taip pat vertinami paveikti klientai ar operacijos, trukmė, geografinė aprėptis, duomenų praradimas, paveiktų paslaugų kritiškumas ir ekonominis poveikis. Tai yra BIA laukai. Jei BIA silpna, incidentų klasifikavimas tampa subjektyvus pačiu blogiausiu momentu.

Tiekėjų tęstinumas – vieta, kur BIA susiduria su sutarčių realybe

NIS2 ir DORA kontekste tiekėjų tęstinumas nebėra pasirenkamas. NIS2 Article 21 apima tiekimo grandinės saugumą ir reikalauja atsižvelgti į tiekėjų pažeidžiamumus, produktų kokybę ir atsparumą, tiekėjų kibernetinio saugumo praktiką ir saugaus kūrimo procedūras. DORA reikalauja IRT trečiųjų šalių riziką valdyti IRT rizikos sistemoje, įskaitant IRT paslaugų sutarčių registrus, deramą patikrinimą, koncentracijos riziką, pasitraukimo strategijas, audito ir prieigos teises, pagalbą incidentų metu, paslaugų lygius ir nenumatytų atvejų reikalavimus.

Įmonių Veiklos tęstinumo ir atkūrimo po katastrofos politika reikalauja:

Trečiųjų šalių ir tiekimo grandinės priklausomybės 6.5.1. Sutartyse su kritiniais tiekėjais turi būti įtraukti veiklos tęstinumo įsipareigojimai ir atkūrimo laiko įsipareigojimai. 6.5.2. Pagrindiniai paslaugų teikėjai, gavę prašymą, turi pademonstruoti periodinį veiklos tęstinumo testavimą ir dalyvavimą incidentų pratybose.

MVĮ versija taip pat reikalauja:

tiekėjų veiklos tęstinumo kontaktinių punktų

Šis mažas laukas realiame incidente gali būti lemiamas. Jei atkūrimo plane nurodyta „susisiekti su debesijos paslaugų teikėjo palaikymu“, bet niekas nežino eskalavimo kelio, sutarties nuorodos, sunkumo proceso ar kontaktinio asmens ne darbo valandomis, RTO yra fikcija.

Ši lentelė nepakeičia tiekėjų rizikos valdymo. Ji tiekėjų riziką paverčia operacine.

Kaip auditoriai testuos jūsų BIA

ISO/IEC 27001:2022 auditorius paprastai pradės nuo taikymo srities, konteksto, rizikos vertinimo, rizikos tvarkymo, Taikomumo pareiškimo, Annex A kontrolės priemonių, dokumentuotos informacijos, veiklos planavimo, veiklos rezultatų vertinimo ir tobulinimo. Jis palygins BIA su rizikos vertinimu ir SoA. Jei A.5.30, A.5.29 ar A.8.13 įtrauktos, jis prašys įgyvendinimo ir testavimo įrodymų.

DORA vertintojas daugiausia dėmesio skirs kritinėms ar svarbioms funkcijoms, IRT turtui, IRT trečiųjų šalių priklausomybėms, atsparumo testavimui, incidentų klasifikavimui, sutartiniams reikalavimams, pasitraukimo strategijoms ir valdymo organo priežiūrai. Jis tikėsis, kad BIA bus suderinta su IRT rizikos valdymo sistema, skaitmeninės veiklos atsparumo strategija, IRT veiklos tęstinumo planais, reagavimo ir atkūrimo planais bei testavimo programa.

NIS2 priežiūros institucija klaus apie veiklos tęstinumo priemones, atsarginių kopijų valdymą, atkūrimą po katastrofos, krizių valdymą, tiekimo grandinės saugumą, valdysenos patvirtinimą ir pajėgumą pranešti apie reikšmingus incidentus. BIA turi įrodyti, kad šios priemonės grindžiamos paslaugų poveikiu ir patvirtintais prioritetais.

NIST CSF 2.0 vertintojas klaus, kaip BIA informuoja esamą profilį, tikslinį profilį, spragų analizę ir veiksmų planą. Jis vertins Govern rezultatus dėl teisinių, reglamentavimo, sutartinių, rizikos, vaidmenų, politikos, priežiūros ir tiekėjų rizikos sprendimų. Jis taip pat nagrinės Identify, Protect, Detect, Respond ir Recover rezultatus.

COBIT 2019 arba ISACA stiliaus auditorius paprastai daugiausia dėmesio skirs valdysenai. Kas valdo paslaugą? Kas priėmė riziką? Ar tikslai suderinti su įmonės tikslais? Ar tiekėjai stebimi? Ar nauda, rizika ir ištekliai subalansuoti? Ar korekciniai veiksmai sekami iki uždarymo?

Clarysec Audito ir atitikties stebėsenos politika Audito ir atitikties stebėsenos politika įtraukia BIA į audito planavimo ciklą:

Rizika grindžiamas audito planas turi būti rengiamas ir tvirtinamas kasmet, atsižvelgiant į: 5.2.1 Naujausių rizikos vertinimų ir verslo poveikio analizės (BIA) rezultatus 5.2.2 Ankstesnes audito išvadas ir korekcinių veiksmų būseną 5.2.3 Procesų, IT infrastruktūros, sistemų ar tiekėjų pokyčius 5.2.4 Išorės prievoles, tokias kaip DORA Article 25 ar klientų sutartys

Tai brandos žingsnis, kurio daugelis organizacijų praleidžia. BIA neturėtų būti už patikinimo ribų. Ji turi valdyti audito planą.

Dažnos BIA klaidos, nustatomos realiuose vertinimuose

Tos pačios silpnybės kartojasi nuolat.

Pirma, BIA išvardija taikomąsias programas, o ne paslaugas. Klientams ir reguliuotojams rūpi paslaugų sutrikimas. Taikomosios programos svarbios todėl, kad palaiko šias paslaugas.

Antra, RTO ir RPO tikslai nukopijuojami iš šablonų. Keturių valandų RTO gali atrodyti pagrįstas, kol atkūrimo testas parodo, kad reikia devynių valandų tapatybės integracijai atkurti, konfigūracijai susigrąžinti, duomenims atkurti, vientisumui validuoti ir stebėsenai vėl įjungti.

Trečia, atsarginės kopijos nesusietos su verslo poveikiu. Dažnumas, saugojimo terminai, šifravimas, saugojimo vieta, atkūrimo prioritetas ir testavimas turi atitikti patvirtintus atkūrimo tikslus.

Ketvirta, tiekėjai vertinami kaip klausimyno eilutės, o ne atkūrimo priklausomybės. Tiekėjų veiklos tęstinumo įsipareigojimai, eskalavimo kontaktai, atkūrimo įrodymai ir dalyvavimas incidentų pratybose turi būti susieti su kritinėmis paslaugomis.

Penkta, trūksta vadovybės patvirtinimo. Pagal NIS2 ir DORA vadovybės atskaitomybė yra aiški. Pagal ISO/IEC 27001:2022 lyderystė, vaidmenys, rizikos savininko patvirtinimas ir veiklos rezultatų ataskaitos yra pagrindiniai reikalavimai.

Šešta, testavimas per siauras. Vieno failo atkūrimas naudingas, bet jis neįrodo paslaugos atkūrimo. Kritinės paslaugos atkūrimo kelias gali apimti DNS, tapatybę, paslaptis, infrastruktūrą kaip kodą, API šliuzus, stebėseną, žurnalavimą, tiekėjo eskalavimą, klientų komunikaciją ir privatumo peržiūrą.

Zenith Blueprint etape „Controls in Action“, 19 žingsnyje, užfiksuoja audito lūkestį atsarginėms kopijoms:

Ar testuojate savo atsargines kopijas?

Atsakymas turi būti „taip, su įrodymais“, o tie įrodymai turi būti susieti su BIA.

Auditui parengtas BIA įrodymų paketas

Praktinė BIA programa turėtų sukurti glaustą įrodymų paketą, kurį galima naudoti auditams, klientų deramam patikrinimui, ataskaitoms valdybai ir atsparumo gerinimui.

Šis paketas pateikia nuoseklią istoriją. Jis taip pat leidžia atsparumą matuoti.

Kitas žingsnis: paverskite savo BIA atitikties įrodymais

Mariai nereikia didesnės skaičiuoklės. Jai reikia gyvos įrodymų grandinės.

Pradėkite nuo vienos kritinės paslaugos. Atvaizduokite jos IRT turtą, duomenis, žmones, tiekėjus ir inžinerines paslaugas. Patvirtinkite MTD, RTO ir RPO. Suderinkite atsarginių kopijų grafiką. Patikrinkite tiekėjų atkūrimo įsipareigojimus. Atlikite vieną atkūrimo testą. Užfiksuokite spragas. Atnaujinkite rizikos tvarkymo planą. Pateikite rezultatą vadovybei.

Tada kartokite.

Clarysec gali padėti pagreitinti šį procesą naudojant Veiklos tęstinumo ir atkūrimo po katastrofos politiką, Veiklos tęstinumo ir atkūrimo po katastrofos politiką – MVĮ, Atsarginių kopijų ir atkūrimo politiką, Audito ir atitikties stebėsenos politiką, Zenith Blueprint ir Zenith Controls.

Jūsų BIA neturėtų būti auditui sukurta ir lentynoje palikta dokumentacija. Ji turėtų būti operacinis įrodymas, kad svarbiausios jūsų paslaugos gali atlaikyti sutrikimą, atitikti klientų ir reglamentavimo lūkesčius ir atsikurti per ribas, kurias jūsų vadovybė faktiškai patvirtino.

Jei jūsų organizacija rengiasi ISO/IEC 27001:2022 priežiūros auditui, NIS2 klientų patikinimo procesui, DORA IRT trečiųjų šalių peržiūroms arba valdybos lygmens atsparumo ataskaitoms, pradėkite nuo BIA pagrindimo. Atsisiųskite Clarysec veiklos tęstinumo ir audito politikas, peržiūrėkite Zenith įgyvendinimo veiksmų planą arba paprašykite atsparumo įrodymų vertinimo, kad išskaidytos kontrolės priemonės taptų viena auditui parengta istorija.