Biznesa ietekmes analīze ISO 27001, NIS2 un DORA vajadzībām

Audita jautājums, kas atklāj patieso darbības nepārtrauktības trūkumu

Ir pirmdienas rīts, un strauji augoša FinTech uzņēmuma informācijas drošības vadītāja (CISO) Marija gatavojas valdes risku komitejas sanāksmei. Temata rinda ir īsa: “DORA un NIS2 gatavība: BIA pārskatīšana.”

Viņas komanda ir sagatavojusi to, ko sagaida lielākā daļa vadītāju. Ir sertificēta ISO/IEC 27001:2022 IDPS, incidentu reaģēšanas rokasgrāmatas, rezerves kopiju ekrānuzņēmumi, ievainojamību pārskati, piegādātāju anketas, mākoņarhitektūras shēmas un atjaunināts riska reģistrs. Korporatīvie klienti sūta NIS2 anketas. Finanšu sektora klienti līgumos iekļauj DORA klauzulas. ISO/IEC 27001:2022 uzraudzības audits ir tikai pēc mēneša.

Tad ārējais auditors uzdod jautājumu, kas maina sarunas gaitu:

“Ja jūsu klientu sākotnējās piesaistes platforma nav pieejama 18 stundas, kuri regulētie pakalpojumi tiek ietekmēti, kuri piegādātāji ir iesaistīti, kāda ir apstiprinātā atjaunošanas prioritāte un kur ir pierādījumi, ka uzņēmums ir akceptējis RTO un RPO?”

Telpā iestājas klusums.

Rezerves kopiju grafiks norāda vienu. Avārijas atjaunošanas plāns — ko citu. Piegādātāja līgumā ir iekļauts pieejamības SLA, bet nav atjaunošanas testu pierādījumu. Riska reģistrā ir minēta pieejamība, taču nav paskaidrots, kāpēc viens pakalpojums jāatjauno ātrāk nekā cits. Vadība apstiprināja drošības politiku, bet ne dīkstāves biznesa ietekmi.

Tā ir biznesa ietekmes analīzes problēma 2026. gadā.

Biznesa ietekmes analīze jeb BIA vairs nav izklājlapa, kas pievienota darbības nepārtrauktības plānam. Tā ir pierādījumu saikne starp biznesa pakalpojumiem, IKT aktīviem, piegādātājiem, atjaunošanas prioritātēm, RTO/RPO, incidentu sliekšņiem, noturības testēšanu un valdes pārskatatbildību. Organizācijām, kas saskaņo ISO/IEC 27001:2022 ar NIS2 nepārtrauktības prasībām un DORA IKT noturību, BIA ir vieta, kur atbilstība kļūst par praktiski īstenojamu pārvaldību.

Spēcīgākajām organizācijām jau ir daudzi pareizie kontroles pasākumi. To vājā vieta ir izsekojamība. BIA pārvērš izkaisītus pierādījumus auditam gatavā stāstā: kas ir svarīgs, kāpēc tas ir svarīgs, cik ātri tas jāatjauno, kuras atkarības to atbalsta, kas ir testēts, kas neizdevās, kas tika uzlabots un kurš apstiprināja atlikušo risku.

Kāpēc vecās BIA izklājlapas tagad rada risku

NIS2 un DORA ir mainījušas darbības nepārtrauktības atbilstības toni. Tās neuzskata darbības nepārtrauktību, avārijas atjaunošanu, reaģēšanu uz incidentiem, piegādātāju noturību un pārvaldību par atsevišķiem dokumentiem. Tiek sagaidīts, ka tie darbojas kā vienota sistēma.

NIS2 subjektiem Article 21 prasa tehniskus, darbības un organizatoriskus pasākumus, lai pārvaldītu tīklu un informācijas sistēmu riskus un novērstu vai mazinātu incidentu ietekmi uz pakalpojumu saņēmējiem un citiem pakalpojumiem. Minimālie pasākumi ietver riska analīzi, incidentu apstrādi, darbības nepārtrauktību, tostarp rezerves kopiju pārvaldību, avārijas atjaunošanu un krīzes pārvaldību, piegādes ķēdes drošību, ievainojamību apstrādi, kontroles efektivitātes izvērtēšanu, apmācību, kriptogrāfiju, personāla drošību, piekļuves kontroli, aktīvu pārvaldību, MFA un drošu saziņu.

NIS2 Article 20 šo jautājumu pārnes valdes līmenī. Vadības struktūrām jāapstiprina kiberdrošības risku pārvaldības pasākumi, jāuzrauga to ieviešana, un tās var tikt sauktas pie atbildības par pārkāpumiem. Tas nozīmē, ka nepamatots četru stundu RTO nav tikai tehniska nekonsekvence. Tā ir pārvaldības vājā vieta.

DORA ir piemērojama no 2025. gada 17. janvāra un izveido vienotu ES ietvaru IKT risku pārvaldībai, incidentu ziņošanai, digitālās darbības noturības testēšanai, IKT trešo pušu risku pārvaldībai, līgumiskajām prasībām un kritisku IKT trešo pušu pakalpojumu sniedzēju pārraudzībai. Finanšu iestādēm un tehnoloģiju pakalpojumu sniedzējiem, kas tās atbalsta līgumu ietvaros, DORA pārvērš darbības noturību strukturētā pierādījumu prasībā.

DORA Articles 5 un 6 prasa pārvaldību un dokumentētu IKT risku pārvaldības ietvaru. Articles 7 līdz 14 aptver uzticamas un noturīgas IKT sistēmas, aktīvu un atkarību identificēšanu, aizsardzību, atklāšanu, IKT darbības nepārtrauktību, rezerves kopiju veidošanu, atjaunošanu, pēcincidenta mācīšanos, informētību, apmācību un krīzes komunikāciju. Articles 24 līdz 26 prasa digitālās darbības noturības testēšanu finanšu iestādēm, kas nav mikrouzņēmumi. Articles 28 līdz 30 formalizē IKT trešo pušu risku, IKT pakalpojumu līgumu reģistrus, izstāšanās stratēģijas, pakalpojumu līmeņus, audita tiesības un ārkārtas rīcības prasības.

ISO/IEC 27001:2022 nodrošina pārvaldības sistēmas pamatu. Tās punkti prasa organizācijai definēt kontekstu, ieinteresētās puses, juridiskos un līgumiskos pienākumus, darbības jomu, vadību, politiku, lomas, risku izvērtēšanu, riska apstrādi, piemērojamības deklarāciju, darbības plānošanu, veiktspējas izvērtēšanu un nepārtrauktu uzlabošanu.

Trūkstošā saikne bieži ir BIA. Bez tās darbības nepārtrauktības plāni nav skaidri balstīti riskā, rezerves kopiju mērķi nav biznesa apstiprināti, piegādātāji nav kartēti pret kritiskiem pakalpojumiem, un vadība nevar droši pierādīt, ka noturības lēmumi tika pieņemti, balstoties uz biznesa ietekmi.

BIA kā noturības pierādījumu kontroles plakne

Auditā aizstāvama BIA atbild uz septiņiem jautājumiem, kurus auditori, regulatori, klienti un valdes uzdod arvien biežāk:

1. Kuri biznesa pakalpojumi ir kritiski?
2. Kuri IKT aktīvi, datu krātuves, cilvēki, piegādātāji un inženierkomunikācijas atbalsta katru pakalpojumu?
3. Kāda ir darbības, finanšu, juridiskā, līgumiskā, klientu, drošuma un reputācijas ietekme, ja darbības traucējums turpinās ilgākā laikā?
4. Kāds ir maksimāli pieļaujamais dīkstāves laiks jeb MTD?
5. Kādi ir apstiprinātie atjaunošanas laika mērķi jeb RTO un atjaunošanas punkta mērķi jeb RPO?
6. Vai rezerves kopiju, redundances, mākoņpakalpojumu, piegādātāju, personāla un komunikācijas kārtība padara šos mērķus sasniedzamus?
7. Vai organizācija ir testējusi atjaunošanas ceļu un pārskatījusi rezultātus?

Clarysec uzņēmuma Darbības nepārtrauktības un avārijas atjaunošanas politika P32 Darbības nepārtrauktības un avārijas atjaunošanas politika prasību formulē skaidri:

Biznesa ietekmes analīze (BIA) ir jāveic vismaz reizi gadā visām kritiskajām biznesa vienībām un jāpārskata, ja sistēmās, procesos vai atkarībās notiek būtiskas izmaiņas. BIA rezultātos jādefinē: 5.2.1. Maksimāli pieļaujamais dīkstāves laiks (MTD) 5.2.2. Atjaunošanas laika mērķi (RTO) 5.2.3. Atjaunošanas punkta mērķi (RPO) 5.2.4. Kritiskās atkarības (sistēmas, piegādātāji, personāls)

Šis punkts dod auditoriem praktisku sākumpunktu. Tas arī novērš biežu kļūmi, kad darbības nepārtrauktības plāns, avārijas atjaunošanas plāns, rezerves kopiju grafiks, piegādātāju reģistrs un incidentu reaģēšanas process katrs izmanto atšķirīgu “kritiska” definīciju.

Tā pati politika prasa integrētu pārvaldības pieeju:

Organizācijai jāuztur integrēta darbības nepārtrauktības pārvaldības sistēma (BCMS), kas saskaņota ar ISO 22301 un ISO/IEC 27001 un nodrošina šādu elementu integrāciju: 5.1.1. Biznesa ietekmes analīze (BIA) 5.1.2. Drošības risku izvērtēšana attiecībā uz nepārtrauktības apdraudējumiem 5.1.3. Darbības nepārtrauktības plāni (BCP) 5.1.4. IKT avārijas atjaunošanas plāni (DRP) 5.1.5. Testēšanas un vingrinājumu programmas 5.1.6. Dokumentācija un nepārtraukta uzlabošana

Tā ir atšķirība starp kontrolsaraksta atbilstību un auditam gatavu noturību. BIA nav vienreizējs dokuments. Tā kļūst par daļu no IDPS un BCMS pierādījumu ķēdes.

Kā ISO/IEC 27001:2022 pārvērš BIA auditējamos pierādījumos

ISO/IEC 27001:2022 neprasa katrai organizācijai katrā punktā lietot frāzi “biznesa ietekmes analīze”, tomēr tās prasības padara BIA pierādījumus īpaši vērtīgus.

Punkti 4.1 līdz 4.4 prasa organizācijai izprast iekšējos un ārējos jautājumus, ieinteresētās puses, juridiskos un regulatīvos pienākumus, līgumiskās prasības, saskarnes, atkarības un IDPS darbības jomu. BIA bieži ir praktiskākie pierādījumi šīm saskarnēm un atkarībām. Tā parāda, kurš mākoņpakalpojums, maksājumu apstrādātājs, identitātes nodrošinātājs, telekomunikāciju pakalpojumu sniedzējs, pārvaldīts drošības pakalpojums, datu centrs vai ārpakalpojumā uzticēta atbalsta komanda nodrošina kritisku pakalpojumu.

Punkti 5.1 līdz 5.3 prasa augstākās vadības līderību, resursu nodrošināšanu, komunikāciju, lomu piešķiršanu un ziņošanu. BIA nodrošina vadībai biznesa pamatojumu ieguldījumiem nepārtrauktībā. Bez tās RTO un RPO mērķi ir tehniskas vēlmes, nevis apstiprinātas biznesa prasības.

Punkti 6.1.1 līdz 6.1.3 prasa atkārtojamu informācijas drošības risku izvērtēšanu un apstrādi. Organizācijai jāidentificē riski konfidencialitātei, integritātei un pieejamībai, jāanalizē sekas un iespējamība, jānosaka riska līmeņi, jāprioritizē apstrāde, jāatlasa kontroles pasākumi, jāsalīdzina atlasītie kontroles pasākumi ar Annex A, jāsagatavo piemērojamības deklarācija, jāizveido risku apstrādes plāns un jāsaņem riska īpašnieka apstiprinājums. BIA pastiprina risku izvērtēšanas “seku” daļu. Tā izskaidro, kāpēc vienas sistēmas divu stundu nepieejamība ir pieļaujama, bet citas sistēmas divu stundu nepieejamība rada kaitējumu klientiem, regulatīvo ietekmi, līguma pārkāpumu vai būtisku ietekmi uz ieņēmumiem.

Annex A nodrošina kontroles katalogu. BIA un darbības nepārtrauktībai būtiskākie ISO/IEC 27001:2022 Annex A kontroles pasākumi ir šādi:

Zenith Controls: The Cross-Compliance Guide Zenith Controls Clarysec apraksta ISO/IEC 27002:2022 kontroli 5.30, IKT gatavība darbības nepārtrauktībai, kā koriģējošu kontroles pasākumu, kas vērsts uz pieejamību un kartēts pret Respond kiberdrošības konceptu, nepārtrauktības darbības spēju un noturības drošības jomu. Kontrole 5.29, informācijas drošība darbības traucējumu laikā, ir aprakstīta kā preventīva un koriģējoša, aizsargājot konfidencialitāti, integritāti un pieejamību. Kontrole 8.13, informācijas rezerves kopēšana, ir aprakstīta kā koriģējoša, atbalstot integritāti un pieejamību ar atjaunošanu.

Šī atšķirība ir svarīga. BIA nedrīkst jautāt tikai: “Vai mēs varam atjaunot?” Tai jāuzdod arī jautājums: “Vai darbības traucējumu laikā mēs varam saglabāt drošību?” Izspiedējprogrammatūras gadījuma, mākoņpakalpojuma nepieejamības, piegādātāja atteices vai datu centra incidenta laikā organizācijai joprojām ir nepieciešama piekļuves kontrole, žurnālfiksēšana, uzraudzība, pierādījumu saglabāšana, droša saziņa un privātuma aizsardzības pasākumi.

Praktiskais BIA pierādījumu modelis

Spēcīga BIA sasaista biznesa valodu ar tehniskiem pierādījumiem. Clarysec parasti strukturē pierādījumu modeli piecos slāņos.

Šis pierādījumu modelis darbojas, jo tas atbilst auditoru domāšanas veidam. Vispirms viņi jautā, kas ir kritisks. Tad viņi jautā, kas to atbalsta. Tad viņi jautā, kurš apstiprināja atjaunošanas mērķi. Tad viņi jautā, vai tehniskā un piegādātāju kārtība var sasniegt šo mērķi. Visbeidzot viņi jautā, vai organizācija ir testējusi un uzlabojusi šo spēju.

NIST CSF 2.0 ir noderīgs kā komunikācijas slānis. Tā CSF Profiles metode mudina organizācijas definēt darbības jomu, apkopot ievaddatus, piemēram, politikas, uzņēmuma riska prioritātes, BIA reģistrus, kiberdrošības prasības, standartus, procedūras, drošības pasākumus un darba lomas, izveidot pašreizējo un mērķa profilu, analizēt trūkumus, sagatavot prioritizētu rīcības plānu, ieviest šo plānu un atjaunināt profilu. Tas gandrīz precīzi atbilst tam, kā BIA būtu jānodrošina ievaddati starpatbilstības ceļkartei.

Vienas nedēļas BIA vingrinājums, kas rada reālus pierādījumus

Pieņemsim, ka SaaS pakalpojumu sniedzējs atbalsta finanšu pakalpojumu klientus. Tā platforma nodrošina klientu sākotnējo piesaisti, dokumentu verifikāciju un klientu paziņojumus. Tas pats nav banka, taču klienti sūta DORA virzītus līgumiskus pieprasījumus un NIS2 piegādātāju anketas.

Fokusēts vienas nedēļas vingrinājums var ātri radīt noderīgus pierādījumus.

1. diena: identificēt kritiskos pakalpojumus un ietekmes laika logus

Sāciet ar pakalpojumiem, nevis serveriem. Iesaistiet biznesa īpašniekus, IT, drošību, juridisko funkciju, atbalstu, privātuma funkciju un piegādātāju pārvaldību.

Šāds ietvars ir svarīgs. Regulatori un klienti atpazīst pakalpojumus un funkcijas. Lietojumprogrammas ir svarīgas tāpēc, ka tās atbalsta šos pakalpojumus.

2. diena: kartēt atkarības

Katram pakalpojumam kartējiet lietojumprogrammas, datubāzes, infrastruktūru, mākoņpakalpojumus, identitātes nodrošinātājus, uzraudzību, rezerves kopiju rīkus, cilvēkus, piegādātājus un atbalstošās inženierkomunikācijas.

Šeit BIA sāk radīt vērtību. Tā atklāj neredzamo atjaunošanas ceļu, tostarp atkarības, kuras tehniskā DR plānā bieži netiek pamanītas.

3. diena: apstiprināt MTD, RTO un RPO

Biznesa īpašnieks ierosina MTD. IT un drošība validē, vai ierosinātie RTO un RPO ir tehniski sasniedzami. Vadība apstiprina galīgos mērķus.

Mazākām organizācijām Clarysec Darbības nepārtrauktības un avārijas atjaunošanas politika - SME P32S Darbības nepārtrauktības un avārijas atjaunošanas politika - SME nodrošina to pašu disciplīnu vienkāršākā valodā. Tā prasa BCP/DR plānus, kuros izklāstīta pieeja būtisko funkciju atjaunošanai:

Ģenerāldirektoram (GM) ir jāapstiprina un jāuztur darbības nepārtrauktības un avārijas atjaunošanas plāni (BCP/DRP), kuros skaidri izklāstīta organizācijas pieeja būtisko funkciju atjaunošanai.

Tā arī prasa, lai plānā būtu iekļauti:

prioritizēti pakalpojumi un sistēmas (kritiskās biznesa funkcijas)

Un:

Atjaunošanas laika mērķi (RTO) un atjaunošanas punkta mērķi (RPO) katrai sistēmai

Galvenais nav pārmērīga dokumentācija. Galvenais ir izsekojamība, apstiprinājums un pierādījumi, ka atjaunošanas mērķi balstās reālā biznesa ietekmē.

4. diena: saskaņot rezerves kopijas ar biznesa ietekmi

Daudzas organizācijas šeit kļūdās. BIA var noteikt četru stundu RPO, bet rezerves kopijas tiek veidotas ik pēc 24 stundām. Vai arī rezerves kopiju rīks aizsargā ražošanas datubāzes, bet ne konfigurāciju, noslēpumus, infrastruktūras kā koda repozitorijus, objektu krātuvi, DNS ierakstus, identitātes iestatījumus vai API vārtejas konfigurāciju.

Clarysec Rezerves kopiju veidošanas un atjaunošanas politika P15 Rezerves kopiju veidošanas un atjaunošanas politika prasa galveno rezerves kopiju grafiku, kas sasaistīts ar BIA rezultātiem:

Galvenais rezerves kopiju grafiks ir jāuztur un jāpārskata katru gadu. Tajā jānorāda: 5.1.1. Rezerves kopiju veidošanas biežums (piemēram, ikdienas inkrementālās rezerves kopijas un iknedēļas pilnās rezerves kopijas) 5.1.2. Glabāšanas termiņi pēc sistēmas vai datu tipa 5.1.3. Šifrēšanas prasības un glabāšanas vietas informācija 5.1.4. RTO/RPO mērķi, kas sasaistīti ar biznesa ietekmes izvērtēšanas rezultātiem

Šis punkts ir ļoti vērtīgs auditā. Tas liek rezerves kopiju dizainam atspoguļot biznesa ietekmi, nevis glabāšanas ērtību.

5. diena: testēt vienu atjaunošanas ceļu un atvērt korektīvās darbības

Netestējiet visu uzreiz. Izvēlieties vienu kritisku pakalpojumu un veiciet fokusētu atjaunošanas testu. Atjaunojiet datubāzi. Atjaunojiet lietojumprogrammas konfigurāciju. Validējiet autentifikāciju. Apstipriniet, ka žurnāli ir pieejami. Pārbaudiet klientu paziņošanas spēju. Reģistrējiet patērēto laiku, datu zudumu, defektus, lēmumus un korektīvās darbības.

Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint posmā Controls in Action, 23. solī, aplūko organizatoriskos kontroles pasākumus, tostarp IKT gatavību darbības nepārtrauktībai. Tas uzdod jautājumu, kas jāuzdod katrai audita komandai:

Vai jūsu sistēmas spēj atbalstīt darbības nepārtrauktības mērķus, kad raustās elektrība, kad nedarbojas tīkli, kad iestājas avārija?

Tas pats solis sniedz praktisku norādījumu:

Pārbaudiet, vai kritisko sistēmu atjaunošanas laika mērķi (RTO) un atjaunošanas punkta mērķi (RPO) atbilst darbības nepārtrauktības prasībām (5.30). Veiciet vismaz vienu tehnisku atjaunošanas testu vai pārslēgšanās simulāciju un dokumentējiet rezultātus.

Tā ir atšķirība starp BIA esamību un aizstāvamiem BIA pierādījumiem. Mērķis nav tikai dokumentēts. Tas ir testēts.

BIA pierādījumu kartēšana pret NIS2, DORA, GDPR, NIST un COBIT 2019

Labi izveidota BIA kļūst par starpatbilstības aktīvu. Viens pierādījumu kopums var atbildēt uz daudziem jautājumiem.

BIA diskusijās GDPR bieži tiek atstāts novārtā. Tomēr GDPR Article 5 prasa personas datus apstrādāt ar integritāti un konfidencialitāti, tostarp aizsargājot pret nejaušu zudumu, iznīcināšanu vai bojājumu, izmantojot atbilstošus tehniskos vai organizatoriskos pasākumus. Pārskatatbildība prasa pārzinim pierādīt atbilstību. Ja personas datu platformu nevar atjaunot apstiprinātā un testētā termiņā, privātuma risks ietekmē pieejamību, integritāti, pārkāpuma ietekmes izvērtēšanu un klientu uzticēšanos.

NIS2 incidentu ziņošana pievieno vēl vienu dimensiju. Article 23 prasa par būtiskiem incidentiem paziņot bez nepamatotas kavēšanās, tostarp sniegt agrīnu brīdinājumu 24 stundu laikā, incidenta paziņojumu 72 stundu laikā un gala ziņojumu viena mēneša laikā. BIA palīdz klasificēt smaguma pakāpi, jo tā definē ietekmētos pakalpojumus, pakalpojumu saņēmējus, darbības traucējumus un iespējamo pārrobežu ietekmi.

DORA incidentu klasifikācijā tiek ņemti vērā arī ietekmētie klienti vai darījumi, ilgums, ģeogrāfiskais tvērums, datu zudumi, ietekmēto pakalpojumu kritiskums un ekonomiskā ietekme. Tie ir BIA lauki. Ja BIA ir vāja, incidenta klasifikācija kļūst subjektīva tieši vissliktākajā brīdī.

Piegādātāju nepārtrauktība ir vieta, kur BIA satiekas ar līgumu realitāti

NIS2 un DORA kontekstā piegādātāju nepārtrauktība vairs nav izvēles jautājums. NIS2 Article 21 ietver piegādes ķēdes drošību un prasa pievērst uzmanību piegādātāju ievainojamībām, produktu kvalitātei un noturībai, piegādātāju kiberdrošības praksēm un drošas izstrādes procedūrām. DORA prasa IKT trešo pušu risku pārvaldīt IKT risku ietvarā, tostarp uzturēt IKT pakalpojumu līgumu reģistrus, veikt sākotnējo izpēti, pārvaldīt koncentrācijas risku, izstāšanās stratēģijas, audita un piekļuves tiesības, incidentu atbalstu, pakalpojumu līmeņus un ārkārtas rīcības prasības.

Uzņēmuma Darbības nepārtrauktības un avārijas atjaunošanas politika prasa:

Trešo pušu un piegādes ķēdes atkarības 6.5.1. Līgumos ar kritiskajiem piegādātājiem jāiekļauj nepārtrauktības pienākumi un reaģēšanas laika saistības. 6.5.2. Galvenajiem pakalpojumu sniedzējiem pēc pieprasījuma jāspēj pierādīt periodisku nepārtrauktības testēšanu un dalību incidentu vingrinājumos.

SME versija arī prasa:

piegādātāju nepārtrauktības kontaktpunkti

Šāds mazs lauks reālā incidentā var būt izšķirošs. Ja atjaunošanas plānā ir teikts “sazināties ar mākoņpakalpojumu sniedzēja atbalstu”, bet neviens nezina eskalācijas ceļu, līguma atsauci, smaguma pakāpes procesu vai ārpusdarba laika kontaktu, RTO ir fikcija.

Šī tabula neaizstāj piegādātāju risku pārvaldību. Tā padara piegādātāju risku praktiski pārvaldāmu.

Kā auditori testēs jūsu BIA

ISO/IEC 27001:2022 auditors parasti sāks ar darbības jomu, kontekstu, risku izvērtēšanu, riska apstrādi, piemērojamības deklarāciju, Annex A kontroles pasākumiem, dokumentēto informāciju, darbības plānošanu, veiktspējas izvērtēšanu un uzlabošanu. Viņš salīdzinās BIA ar risku izvērtēšanu un SoA. Ja ir iekļautas A.5.30, A.5.29 vai A.8.13, viņš prasīs ieviešanas un testēšanas pierādījumus.

DORA pārskatītājs fokusēsies uz kritiskām vai svarīgām funkcijām, IKT aktīviem, IKT trešo pušu atkarībām, noturības testēšanu, incidentu klasifikāciju, līgumiskajām prasībām, izstāšanās stratēģijām un vadības struktūras pārraudzību. Viņš sagaidīs, ka BIA ir saskaņota ar IKT risku pārvaldības ietvaru, digitālās darbības noturības stratēģiju, IKT darbības nepārtrauktības plāniem, reaģēšanas un atjaunošanas plāniem un testēšanas programmu.

NIS2 uzraugs prasīs darbības nepārtrauktības pasākumus, rezerves kopiju pārvaldību, avārijas atjaunošanu, krīzes pārvaldību, piegādes ķēdes drošību, pārvaldības apstiprinājumu un spēju ziņot par būtiskiem incidentiem. BIA jāparāda, ka šie pasākumi balstās uz pakalpojuma ietekmi un apstiprinātām prioritātēm.

NIST CSF 2.0 izvērtētājs jautās, kā BIA informē pašreizējo profilu, mērķa profilu, trūkumu analīzi un rīcības plānu. Viņš aplūkos Govern rezultātus attiecībā uz juridiskiem, regulatīviem, līgumiskiem, riska, lomu, politikas, pārraudzības un piegādātāju riska lēmumiem. Viņš pārbaudīs arī Identify, Protect, Detect, Respond un Recover rezultātus.

COBIT 2019 vai ISACA stila auditors parasti koncentrēsies uz pārvaldību. Kam pieder pakalpojums? Kurš pieņēma risku? Vai mērķi ir saskaņoti ar uzņēmuma mērķiem? Vai piegādātāji tiek uzraudzīti? Vai ieguvumi, risks un resursi ir līdzsvaroti? Vai korektīvās darbības tiek izsekotas līdz slēgšanai?

Clarysec Audita un atbilstības uzraudzības politika Audita un atbilstības uzraudzības politika padara BIA par daļu no audita plānošanas cikla:

Uz risku balstīts audita plāns ir jāizstrādā un jāapstiprina katru gadu, ņemot vērā: 5.2.1. Jaunāko risku izvērtējumu un biznesa ietekmes analīzes (BIA) rezultātus 5.2.2. Iepriekšējos audita konstatējumus un korektīvo darbību statusu 5.2.3. Izmaiņas procesos, IT infrastruktūrā, sistēmās vai piegādātājos 5.2.4. Ārējos pienākumus, piemēram, DORA Article 25 vai klientu līgumus

Tas ir brieduma solis, ko daudzas organizācijas palaiž garām. BIA nedrīkst atrasties ārpus apliecinājuma procesa. Tai jāvirza audita plāns.

Biežākās BIA kļūdas reālos izvērtējumos

Vienas un tās pašas vājās vietas parādās atkārtoti.

Pirmkārt, BIA uzskaita lietojumprogrammas, nevis pakalpojumus. Klientiem un regulatoriem rūp pakalpojuma darbības traucējums. Lietojumprogrammas ir svarīgas tāpēc, ka tās atbalsta šos pakalpojumus.

Otrkārt, RTO un RPO mērķi tiek kopēti no veidnēm. Četru stundu RTO var izklausīties saprātīgi, līdz atjaunošanas tests parāda, ka identitātes integrācijas pārbūvei, konfigurācijas atjaunošanai, datu atjaunošanai, integritātes validācijai un uzraudzības atkārtotai aktivizēšanai nepieciešamas deviņas stundas.

Treškārt, rezerves kopijas nav sasaistītas ar biznesa ietekmi. Biežumam, glabāšanai, šifrēšanai, glabāšanas vietai, atjaunošanas prioritātei un testēšanai jāatspoguļo apstiprinātie atjaunošanas mērķi.

Ceturtkārt, piegādātāji tiek uztverti kā anketu pozīcijas, nevis atjaunošanas atkarības. Piegādātāju nepārtrauktības saistības, eskalācijas kontaktpersonas, atjaunošanas pierādījumi un dalība incidentu vingrinājumos ir jāsasaista ar kritiskajiem pakalpojumiem.

Piektkārt, trūkst vadības apstiprinājuma. NIS2 un DORA ietvaros vadības pārskatatbildība ir skaidri noteikta. ISO/IEC 27001:2022 ietvaros līderība, lomas, riska īpašnieka apstiprinājums un veiktspējas ziņošana ir pamatprasības.

Sestkārt, testēšana ir pārāk šaura. Vienas datnes atjaunošana ir noderīga, taču tā nepierāda pakalpojuma atjaunošanu. Kritiska pakalpojuma atjaunošanas ceļš var ietvert DNS, identitāti, noslēpumus, infrastruktūru kā kodu, API vārtejas, uzraudzību, žurnālfiksēšanu, piegādātāju eskalāciju, klientu komunikāciju un privātuma pārskatīšanu.

Zenith Blueprint posmā Controls in Action, 19. solī, formulē audita gaidas attiecībā uz rezerves kopijām:

Vai jūs testējat savas rezerves kopijas?

Atbildei jābūt “jā, ar pierādījumiem”, un šiem pierādījumiem jābūt sasaistītiem atpakaļ ar BIA.

Auditam gatava BIA pierādījumu pakotne

Praktiskai BIA programmai jāizveido kodolīga pierādījumu pakotne, ko var izmantot auditos, klientu sākotnējā izpētē, valdes ziņošanā un noturības uzlabošanā.

Šī pakotne stāsta saskaņotu stāstu. Tā arī padara noturību izmērāmu.

Nākamais solis: pārvērtiet BIA atbilstības pierādījumos

Marijai nav vajadzīga lielāka izklājlapa. Viņai ir vajadzīga dzīva pierādījumu ķēde.

Sāciet ar vienu kritisku pakalpojumu. Kartējiet tā IKT aktīvus, datus, cilvēkus, piegādātājus un inženierkomunikācijas. Apstipriniet MTD, RTO un RPO. Saskaņojiet rezerves kopiju grafiku. Pārbaudiet piegādātāju atjaunošanas saistības. Veiciet vienu atjaunošanas testu. Reģistrējiet trūkumus. Atjauniniet risku apstrādes plānu. Iesniedziet rezultātu vadībai.

Tad atkārtojiet.

Clarysec var palīdzēt paātrināt šo procesu, izmantojot Darbības nepārtrauktības un avārijas atjaunošanas politiku, Darbības nepārtrauktības un avārijas atjaunošanas politiku - SME, Rezerves kopiju veidošanas un atjaunošanas politiku, Audita un atbilstības uzraudzības politiku, Zenith Blueprint un Zenith Controls.

Jūsu BIA nedrīkst būt auditam izveidots plaukta dokuments. Tai jābūt darbības pierādījumam, ka jūsu svarīgākie pakalpojumi var pārdzīvot darbības traucējumus, izpildīt klientu un regulatīvās gaidas un atjaunoties robežās, kuras jūsu vadība patiešām ir apstiprinājusi.

Ja jūsu organizācija gatavojas ISO/IEC 27001:2022 uzraudzības auditam, NIS2 klientu apliecinājumam, DORA IKT trešo pušu pārskatīšanām vai valdes līmeņa noturības ziņošanai, sāciet ar BIA aizstāvamības nodrošināšanu. Lejupielādējiet Clarysec nepārtrauktības un audita politikas, pārskatiet Zenith ieviešanas ceļvedi vai pieprasiet noturības pierādījumu izvērtēšanu, lai izkaisītus kontroles pasākumus pārvērstu vienā auditam gatavā stāstā.