Analiza vpliva na poslovanje za ISO 27001, NIS2 in DORA

Presojevalsko vprašanje, ki razkrije dejansko vrzel v neprekinjenem poslovanju

Ponedeljek zjutraj je in Maria, vodja informacijske varnosti hitro rastočega finančnotehnološkega podjetja, se pripravlja na sejo odbora za tveganja pri organu upravljanja. Zadeva sporočila je kratka: »Pripravljenost na DORA in NIS2: pregled BIA.«

Njena ekipa je pripravila tisto, kar pričakuje večina izvršnega vodstva. Vzpostavljen je certificiran sistem upravljanja informacijske varnosti (ISMS) po ISO/IEC 27001:2022, pripravljeni so priročniki za odziv na incidente, posnetki zaslona varnostnih kopij, poročila o ranljivostih, vprašalniki za dobavitelje, diagrami arhitekture v oblaku in posodobljen register tveganj. Korporativne stranke pošiljajo vprašalnike NIS2. Stranke iz finančnega sektorja v pogodbe vključujejo klavzule DORA. Nadzorna presoja ISO/IEC 27001:2022 je oddaljena le še mesec dni.

Nato zunanji presojevalec zastavi vprašanje, ki spremeni vzdušje v prostoru:

»Če je vaša platforma za uvajanje strank nedostopna 18 ur, katere regulirane storitve so prizadete, kateri dobavitelji so vključeni, kakšna je odobrena prioriteta obnovitve in kje so dokazila, da je poslovanje sprejelo RTO in RPO?«

V prostoru nastane tišina.

Urnik varnostnega kopiranja pravi eno. Načrt obnovitve po nesreči pravi drugo. Pogodba z dobaviteljem vključuje SLA za razpoložljivost, vendar brez dokazil o testiranju obnovitve. Register tveganj omenja razpoložljivost, vendar ne pojasni, zakaj se mora ena storitev obnoviti hitreje kot druga. Vodstvo je odobrilo varnostno politiko, ne pa poslovnega vpliva nedelovanja.

To je problem analize vpliva na poslovanje v letu 2026.

Analiza vpliva na poslovanje oziroma BIA ni več preglednica, priložena načrtu neprekinjenega poslovanja. Je dokazilni most med poslovnimi storitvami, sredstvi IKT, dobavitelji, prioritetami obnovitve, RTO/RPO, pragovi incidentov, testiranjem odpornosti in odgovornostjo organa upravljanja. Za organizacije, ki ISO/IEC 27001:2022 usklajujejo z neprekinjenim poslovanjem po NIS2 in odpornostjo IKT po DORA, je BIA točka, kjer skladnost postane operativna.

Najzrelejše organizacije že imajo veliko ustreznih kontrol. Njihova šibkost je sledljivost. BIA razpršena dokazila pretvori v presojevalsko uporabno zgodbo: kaj je pomembno, zakaj je pomembno, kako hitro se mora obnoviti, katere odvisnosti ga podpirajo, kaj je bilo testirano, kaj ni delovalo, kaj je bilo izboljšano in kdo je odobril preostalo tveganje.

Zakaj so stare preglednice BIA postale tveganje

NIS2 in DORA sta spremenili ton skladnosti na področju neprekinjenega poslovanja. Neprekinjenega poslovanja, obnovitve po nesreči, odziva na incidente, odpornosti dobaviteljev in upravljanja ne obravnavata kot ločenih dokumentov. Pričakujeta, da delujejo kot enoten sistem.

Za subjekte po NIS2 Article 21 zahteva tehnične, operativne in organizacijske ukrepe za obvladovanje tveganj za omrežne in informacijske sisteme ter za preprečevanje ali zmanjševanje vpliva incidentov na prejemnike storitev in druge storitve. Minimalni ukrepi vključujejo analizo tveganj, obravnavanje incidentov, neprekinjeno poslovanje, vključno z upravljanjem varnostnega kopiranja, obnovitev po nesreči in krizno upravljanje, varnost dobavne verige, obravnavo ranljivosti, ocenjevanje učinkovitosti kontrol, usposabljanje, kriptografijo, kadrovsko varnost, nadzor dostopa, upravljanje sredstev, MFA in varne komunikacije.

NIS2 Article 20 vprašanje premakne v sejno sobo organa upravljanja. Organi upravljanja morajo odobriti ukrepe za obvladovanje kibernetskih tveganj, nadzirati njihovo izvajanje in so lahko odgovorni za kršitve. To pomeni, da nepodprt štiriurni RTO ni zgolj tehnična nedoslednost. Je slabost upravljanja.

DORA se uporablja od 17. januarja 2025 in vzpostavlja enoten okvir EU za upravljanje tveganj na področju IKT, poročanje o incidentih, testiranje digitalne operativne odpornosti, upravljanje tveganj tretjih oseb na področju IKT, pogodbene zahteve in nadzor nad kritičnimi ponudniki storitev IKT tretjih oseb. Za finančne subjekte in tehnološke ponudnike, ki jih pogodbeno podpirajo, DORA operativno odpornost spremeni v strukturirano zahtevo po dokazilih.

DORA Articles 5 in 6 zahtevata upravljanje in dokumentiran okvir upravljanja tveganj na področju IKT. Articles 7 do 14 zajemajo zanesljive in odporne sisteme IKT, identifikacijo sredstev in odvisnosti, zaščito, zaznavanje, neprekinjeno poslovanje IKT, varnostno kopiranje, obnovo, obnovitev, učenje po incidentu, ozaveščanje, usposabljanje in krizno komuniciranje. Articles 24 do 26 zahtevajo testiranje digitalne operativne odpornosti za finančne subjekte, ki niso mikropodjetja. Articles 28 do 30 formalizirajo tveganja tretjih oseb na področju IKT, registre pogodb o storitvah IKT, izhodne strategije, ravni storitev, pravice do revizije in zahteve za ukrepe ob nepredvidenih dogodkih.

ISO/IEC 27001:2022 zagotavlja hrbtenico sistema upravljanja. Njegove klavzule zahtevajo, da organizacija opredeli kontekst, zainteresirane strani, zakonske in pogodbene obveznosti, obseg, voditeljstvo, politiko, vloge, oceno tveganj, obravnavo tveganj, izjavo o uporabnosti, operativno načrtovanje, vrednotenje uspešnosti in nenehno izboljševanje.

Manjkajoča povezava je pogosto BIA. Brez nje načrti neprekinjenega poslovanja niso jasno utemeljeni na tveganju, cilji varnostnega kopiranja niso poslovno odobreni, dobavitelji niso povezani s kritičnimi storitvami, vodstvo pa ne more zanesljivo dokazati, da so bile odločitve o odpornosti sprejete na podlagi vpliva na poslovanje.

BIA kot kontrolna raven za dokazila o odpornosti

Dokazljiva BIA odgovarja na sedem vprašanj, ki jih presojevalci, regulatorji, stranke in organi upravljanja postavljajo vse pogosteje:

1. Katere poslovne storitve so kritične?
2. Katera sredstva IKT, podatkovne shrambe, ljudje, dobavitelji in infrastrukturne storitve podpirajo posamezno storitev?
3. Kakšen je operativni, finančni, pravni, pogodbeni, uporabniški, varnostni in ugledni vpliv motnje skozi čas?
4. Kakšen je največji dopustni čas izpada oziroma MTD?
5. Kateri sta odobrena ciljni čas obnovitve oziroma RTO in ciljna točka obnovitve oziroma RPO?
6. Ali ureditve varnostnega kopiranja, redundance, oblaka, dobaviteljev, kadrovanja in komuniciranja omogočajo doseganje teh ciljev?
7. Ali je organizacija testirala pot obnovitve in pregledala rezultate?

Clarysecova korporativna Politika neprekinjenega poslovanja in obnovitve po nesreči P32 Politika neprekinjenega poslovanja in obnovitve po nesreči zahtevo opredeljuje jasno:

Analiza vpliva na poslovanje (BIA) se izvede najmanj enkrat letno za vse kritične poslovne enote in se pregleda ob pomembnih spremembah sistemov, procesov ali odvisnosti. Izhodi BIA morajo opredeliti: 5.2.1. Največji dopustni čas izpada (MTD) 5.2.2. Ciljne čase obnovitve (RTO) 5.2.3. Ciljne točke obnovitve (RPO) 5.2.4. Kritične odvisnosti (sistemi, dobavitelji, osebje)

Ta klavzula presojevalcem daje praktično izhodišče. Preprečuje tudi pogosto napako, ko načrt neprekinjenega poslovanja, načrt obnovitve po nesreči, urnik varnostnega kopiranja, evidenca dobaviteljev in proces odziva na incidente uporabljajo različne opredelitve izraza »kritično«.

Ista politika zahteva integriran pristop upravljanja:

Organizacija mora vzdrževati integriran sistem upravljanja neprekinjenega poslovanja (BCMS), usklajen z ISO 22301 in ISO/IEC 27001, ter zagotoviti integracijo: 5.1.1. analize vpliva na poslovanje (BIA) 5.1.2. ocene tveganj informacijske varnosti za grožnje neprekinjenemu poslovanju 5.1.3. načrtov neprekinjenega poslovanja (BCP) 5.1.4. načrtov obnovitve IKT po nesreči (DRP) 5.1.5. programov testiranja in vaj 5.1.6. dokumentacije in nenehnega izboljševanja

To je razlika med skladnostjo po kontrolnem seznamu in odpornostjo, pripravljeno za presojo. BIA ni enkraten dokument. Postane del verige dokazil ISMS in BCMS.

Kako ISO/IEC 27001:2022 BIA spremeni v preverljiva dokazila

ISO/IEC 27001:2022 od organizacije ne zahteva, da v vsaki klavzuli uporablja izraz »analiza vpliva na poslovanje«, vendar njegove zahteve dokazila BIA naredijo izjemno dragocena.

Klavzule 4.1 do 4.4 zahtevajo, da organizacija razume notranja in zunanja vprašanja, zainteresirane strani, zakonske in regulativne obveznosti, pogodbene zahteve, vmesnike, odvisnosti in obseg ISMS. BIA je pogosto najbolj praktično dokazilo za te vmesnike in odvisnosti. Pokaže, katera storitev v oblaku, plačilni procesor, ponudnik identitete, telekomunikacijski ponudnik, upravljana varnostna storitev, podatkovni center ali zunanja podporna ekipa omogoča kritično storitev.

Klavzule 5.1 do 5.3 zahtevajo voditeljstvo najvišjega vodstva, zagotavljanje virov, komuniciranje, dodelitev vlog in poročanje. BIA vodstvu daje poslovno podlago za naložbe v neprekinjeno poslovanje. Brez nje so cilji RTO in RPO tehnične želje, ne odobrene poslovne zahteve.

Klavzule 6.1.1 do 6.1.3 zahtevajo ponovljivo ocenjevanje in obravnavo tveganj informacijske varnosti. Organizacija mora identificirati tveganja za zaupnost, celovitost in razpoložljivost, analizirati posledice in verjetnost, določiti ravni tveganja, določiti prednostno obravnavo, izbrati kontrole, primerjati izbrane kontrole s Prilogo A, pripraviti izjavo o uporabnosti, izdelati načrt obravnave tveganja in pridobiti odobritev lastnika tveganja. BIA okrepi del ocene tveganja, ki se nanaša na posledice. Pojasni, zakaj je dvourni izpad enega sistema sprejemljiv, medtem ko dvourni izpad drugega povzroči škodo strankam, regulativno izpostavljenost, kršitev pogodbe ali velik vpliv na prihodke.

Priloga A zagotavlja katalog kontrol. Za BIA in neprekinjeno poslovanje so najpomembnejše kontrole iz Priloge A ISO/IEC 27001:2022:

V Zenith Controls: The Cross-Compliance Guide Zenith Controls Clarysec obravnava kontrolo ISO/IEC 27002:2022 5.30, pripravljenost IKT za neprekinjeno poslovanje, kot korektivno kontrolo, osredotočeno na razpoložljivost, preslikano na koncept kibernetske varnosti Respond, operativno zmožnost neprekinjenega poslovanja in varnostno domeno odpornosti. Kontrola 5.29, informacijska varnost med motnjo, je predstavljena kot preventivna in korektivna ter ščiti zaupnost, celovitost in razpoložljivost. Kontrola 8.13, varnostno kopiranje informacij, je predstavljena kot korektivna in z obnovitvijo podpira celovitost in razpoložljivost.

Ta razlika je pomembna. BIA ne sme vprašati le: »Ali lahko obnovimo?« Vprašati mora tudi: »Ali lahko med motnjo ostanemo varni?« Med dogodkom izsiljevalske programske opreme, izpadom oblaka, odpovedjo dobavitelja ali incidentom podatkovnega centra organizacija še vedno potrebuje nadzor dostopa, beleženje, spremljanje, ohranjanje dokazil, varne komunikacije in varovala zasebnosti.

Praktični model dokazil BIA

Močna BIA povezuje poslovni jezik s tehničnimi dokazili. Clarysec model dokazil običajno strukturira v pet plasti.

Ta model dokazil deluje, ker sledi načinu razmišljanja presojevalcev. Najprej vprašajo, kaj je kritično. Nato vprašajo, kaj to podpira. Potem vprašajo, kdo je odobril cilj obnovitve. Nato preverijo, ali tehnične ureditve in ureditve dobaviteljev lahko cilj dosežejo. Na koncu vprašajo, ali je organizacija zmožnost testirala in izboljšala.

NIST CSF 2.0 je uporaben kot komunikacijska plast. Njegova metoda CSF Profiles spodbuja organizacije, da opredelijo obseg, zberejo vhodne informacije, kot so politike, prednostna tveganja podjetja, registri BIA, zahteve kibernetske varnosti, standardi, postopki, varovalni ukrepi in delovne vloge, ustvarijo trenutne in ciljne profile, analizirajo vrzeli, pripravijo prednostni akcijski načrt, ga izvedejo in posodobijo profil. To je skoraj natanko način, kako mora BIA podpirati časovni načrt večokvirne skladnosti.

Enotedenska vaja BIA, ki ustvari dejanska dokazila

Predpostavimo, da ponudnik SaaS podpira stranke iz finančnih storitev. Njegova platforma podpira uvajanje strank, preverjanje dokumentov in obveščanje strank. Sam ni banka, vendar njegove stranke pošiljajo pogodbene zahteve, ki izhajajo iz DORA, in vprašalnike za dobavitelje po NIS2.

Osredotočena enotedenska vaja lahko hitro ustvari uporabna dokazila.

1. dan: Identifikacija kritičnih storitev in časovnih oken vpliva

Začnite s storitvami, ne s strežniki. Vključite lastnike poslovnih procesov, IT, varnost, pravno službo, podporo, zasebnost in upravljanje dobaviteljev.

Ta okvir je pomemben. Regulatorji in stranke prepoznajo storitve in funkcije. Aplikacije so pomembne zato, ker te storitve podpirajo.

2. dan: Popis odvisnosti

Za vsako storitev popišite aplikacije, podatkovne baze, infrastrukturo, storitve v oblaku, ponudnike identitete, spremljanje, orodja za varnostno kopiranje, ljudi, dobavitelje in podporne infrastrukturne storitve.

Tu BIA začne ustvarjati vrednost. Razkrije nevidno pot obnovitve, vključno z odvisnostmi, ki so v tehničnem načrtu DR pogosto spregledane.

3. dan: Odobritev MTD, RTO in RPO

Lastnik poslovnega procesa predlaga MTD. IT in varnost preverita, ali sta predlagana RTO in RPO tehnično dosegljiva. Vodstvo odobri končne cilje.

Za manjše organizacije Clarysecova Politika neprekinjenega poslovanja in obnovitve po nesreči - SME P32S Politika neprekinjenega poslovanja in obnovitve po nesreči - SME zagotavlja enako disciplino v preprostejšem jeziku. Zahteva načrte BCP/DR, ki določajo pristop k obnovitvi bistvenih funkcij:

Generalni direktor (GM) mora odobriti in vzdrževati načrte neprekinjenega poslovanja in obnovitve po nesreči (BCP/DRP), ki jasno določajo pristop organizacije k obnovitvi bistvenih funkcij.

Prav tako zahteva, da načrt vključuje:

storitve in sisteme, razvrščene po prioriteti (kritične poslovne funkcije)

In:

ciljne čase obnovitve (RTO) in ciljne točke obnovitve (RPO) za vsak sistem

Ključno ni pretirano dokumentiranje. Ključni so sledljivost, odobritev in dokazila, da cilji obnovitve temeljijo na dejanskem vplivu na poslovanje.

4. dan: Uskladitev varnostnega kopiranja z vplivom na poslovanje

Veliko organizacij tu odpove. BIA lahko določi štiriurni RPO, varnostne kopije pa se izvajajo vsakih 24 ur. Ali pa orodje za varnostno kopiranje ščiti produkcijske podatkovne baze, ne pa konfiguracije, skrivnosti, repozitorijev infrastrukture kot kode, objektne shrambe, zapisov DNS, nastavitev identitete ali konfiguracije API prehoda.

Clarysecova Politika varnostnega kopiranja in obnovitve P15 Politika varnostnega kopiranja in obnovitve zahteva osrednji urnik varnostnega kopiranja, povezan z izidi BIA:

Osrednji urnik varnostnega kopiranja se vzdržuje in pregleda letno. Določati mora: 5.1.1 pogostost varnostnega kopiranja (na primer dnevne inkrementalne kopije in tedenske polne kopije) 5.1.2 roke hrambe po sistemu ali vrsti podatkov 5.1.3 zahteve glede šifriranja in podrobnosti lokacije hrambe 5.1.4 cilje RTO/RPO, povezane z izidi analize vpliva na poslovanje

Ta klavzula je revizijsko zlato. Zasnovo varnostnega kopiranja prisili, da odraža vpliv na poslovanje, ne priročnost shranjevanja.

5. dan: Testiranje ene poti obnovitve in odprtje korektivnih ukrepov

Ne testirajte vsega naenkrat. Izberite eno kritično storitev in izvedite osredotočen test obnovitve. Obnovite podatkovno bazo. Ponovno zgradite konfiguracijo aplikacije. Preverite avtentikacijo. Potrdite, da so dnevniki na voljo. Preverite zmožnost obveščanja strank. Zabeležite porabljeni čas, izgubo podatkov, pomanjkljivosti, odločitve in korektivne ukrepe.

V Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint faza Controls in Action, korak 23, obravnava organizacijske ukrepe, vključno s pripravljenostjo IKT za neprekinjeno poslovanje. Zastavi vprašanje, ki bi ga morala zastaviti vsaka presojevalska ekipa:

Ali lahko vaši sistemi podprejo cilje neprekinjenega poslovanja, ko luči utripajo, ko omrežja odpovejo, ko nastopi nesreča?

Isti korak daje praktično navodilo:

Preverite, ali so ciljni časi obnovitve (RTO) in ciljne točke obnovitve (RPO) za kritične sisteme usklajeni s pričakovanji neprekinjenega poslovanja (5.30). Izvedite najmanj en tehnični test obnovitve ali simulacijo preklopa na rezervno okolje in dokumentirajte rezultate.

To je razlika med tem, da BIA obstaja, in tem, da obstajajo dokazljiva dokazila BIA. Cilj ni le dokumentiran. Je testiran.

Preslikava dokazil BIA na NIS2, DORA, GDPR, NIST in COBIT 2019

Dobro zasnovana BIA postane sredstvo za večokvirno skladnost. En sklop dokazil lahko odgovori na številna vprašanja.

GDPR je v razpravah o BIA pogosto spregledan. Vendar GDPR Article 5 zahteva, da se osebni podatki obdelujejo z zagotavljanjem celovitosti in zaupnosti, vključno z zaščito pred nenamerno izgubo, uničenjem ali poškodovanjem z ustreznimi tehničnimi ali organizacijskimi ukrepi. Odgovornost zahteva, da upravljavec lahko dokaže skladnost. Če platforme z osebnimi podatki ni mogoče obnoviti v odobrenem in testiranem časovnem okviru, tveganje za zasebnost vpliva na razpoložljivost, celovitost, oceno kršitve in zaupanje strank.

Poročanje o incidentih po NIS2 dodaja še eno razsežnost. Article 23 zahteva, da se pomembni incidenti prijavijo brez nepotrebnega odlašanja, vključno z zgodnjim opozorilom v 24 urah, obvestilom o incidentu v 72 urah in končnim poročilom v enem mesecu. BIA pomaga razvrstiti resnost, ker opredeli prizadete storitve, prejemnike storitev, operativno motnjo in možen čezmejni vpliv.

Razvrščanje incidentov po DORA upošteva tudi prizadete stranke ali transakcije, trajanje, geografsko razširjenost, izgube podatkov, kritičnost prizadetih storitev in ekonomski vpliv. To so polja BIA. Če je BIA šibka, razvrščanje incidentov postane subjektivno prav v najslabšem možnem trenutku.

Neprekinjeno poslovanje dobaviteljev je točka, kjer BIA sreča pogodbeno realnost

Za NIS2 in DORA neprekinjeno poslovanje dobaviteljev ni več izbirno. NIS2 Article 21 vključuje varnost dobavne verige in zahteva pozornost na ranljivosti dobaviteljev, kakovost in odpornost produktov, prakse kibernetske varnosti dobaviteljev ter postopke varnega razvoja. DORA zahteva, da se tveganja tretjih oseb na področju IKT upravljajo znotraj okvira tveganj IKT, vključno z registri pogodb o storitvah IKT, skrbnim pregledom, tveganjem koncentracije, izhodnimi strategijami, pravicami do revizije in dostopa, pomočjo pri incidentih, ravnmi storitev in zahtevami za ukrepe ob nepredvidenih dogodkih.

Korporativna Politika neprekinjenega poslovanja in obnovitve po nesreči zahteva:

Odvisnosti od tretjih oseb in dobavne verige 6.5.1. Pogodbe s kritičnimi dobavitelji morajo vključevati obveznosti neprekinjenega poslovanja in zaveze glede časa obnovitve. 6.5.2. Ključni izvajalci storitev morajo na zahtevo dokazati periodično testiranje neprekinjenega poslovanja in sodelovanje pri vajah incidentov.

Različica za SME zahteva tudi:

kontaktne točke dobaviteljev za neprekinjeno poslovanje

To majhno polje je lahko odločilno v resničnem incidentu. Če vaš načrt obnovitve pravi »kontaktiraj podporo ponudnika oblaka«, nihče pa ne pozna eskalacijske poti, referenčne pogodbe, postopka glede resnosti ali kontakta izven delovnega časa, je RTO fikcija.

Ta tabela ne nadomešča upravljanja tveganj dobaviteljev. Tveganje dobaviteljev naredi operativno.

Kako bodo presojevalci testirali vašo BIA

Presojevalec ISO/IEC 27001:2022 običajno začne z obsegom, kontekstom, oceno tveganja, obravnavo tveganja, izjavo o uporabnosti, kontrolami Priloge A, dokumentiranimi informacijami, operativnim načrtovanjem, vrednotenjem uspešnosti in izboljševanjem. BIA bo primerjal z oceno tveganja in SoA. Če so vključene A.5.30, A.5.29 ali A.8.13, bo zahteval dokazila o implementaciji in testiranju.

Pregledovalec DORA se bo osredotočil na kritične ali pomembne funkcije, sredstva IKT, odvisnosti od tretjih oseb na področju IKT, testiranje odpornosti, razvrščanje incidentov, pogodbene zahteve, izhodne strategije in nadzor organov upravljanja. Pričakoval bo, da je BIA usklajena z okvirom upravljanja tveganj na področju IKT, strategijo digitalne operativne odpornosti, načrti neprekinjenega poslovanja IKT, načrti odziva in obnovitve ter programom testiranja.

Nadzornik NIS2 bo zahteval ukrepe neprekinjenega poslovanja, upravljanje varnostnega kopiranja, obnovitev po nesreči, krizno upravljanje, varnost dobavne verige, odobritev upravljanja in zmožnost poročanja o pomembnih incidentih. BIA mora dokazati, da ti ukrepi temeljijo na vplivu na storitve in odobrenih prioritetah.

Ocenjevalec NIST CSF 2.0 bo vprašal, kako BIA informira Current Profile, Target Profile, analizo vrzeli in akcijski načrt. Preveril bo izide Govern za pravne, regulativne, pogodbene, tvegane, vloge, politike, nadzor in odločitve glede tveganj dobaviteljev. Pregledal bo tudi izide Identify, Protect, Detect, Respond in Recover.

Presojevalec COBIT 2019 ali presojevalec v slogu ISACA se običajno osredotoči na upravljanje. Kdo je lastnik storitve? Kdo je sprejel tveganje? Ali so cilji usklajeni s cilji podjetja? Ali se dobavitelji spremljajo? Ali so koristi, tveganja in viri uravnoteženi? Ali se korektivni ukrepi spremljajo do zaprtja?

Clarysecova Politika spremljanja presoj in skladnosti Politika spremljanja presoj in skladnosti BIA vključi v cikel načrtovanja presoj:

Na tveganjih temelječ načrt presoj se pripravi in odobri letno, pri čemer se upoštevajo: 5.2.1 rezultati najnovejših ocen tveganja in analize vpliva na poslovanje (BIA) 5.2.2 prejšnje ugotovitve presoje in status korektivnih ukrepov 5.2.3 spremembe procesov, IT infrastrukture, sistemov ali dobaviteljev 5.2.4 zunanje obveznosti, kot so DORA Article 25 ali pogodbe s strankami

To je stopnja zrelosti, ki jo veliko organizacij spregleda. BIA ne sme stati zunaj zagotovil. Usmerjati mora načrt presoj.

Pogoste napake BIA, ugotovljene v dejanskih ocenah

Iste slabosti se ponavljajo.

Prvič, BIA navaja aplikacije, ne storitev. Stranke in regulatorje zanima motnja storitve. Aplikacije so pomembne, ker te storitve podpirajo.

Drugič, cilji RTO in RPO so prepisani iz predlog. Štiriurni RTO se lahko zdi razumen, dokler test obnovitve ne pokaže, da za ponovno vzpostavitev integracije identitete, obnovitev konfiguracije, obnovitev podatkov, preverjanje celovitosti in ponovno omogočanje spremljanja potrebujete devet ur.

Tretjič, varnostne kopije niso povezane z vplivom na poslovanje. Pogostost, rok hrambe, šifriranje, lokacija hrambe, prioriteta obnovitve in testiranje morajo odražati odobrene cilje obnovitve.

Četrtič, dobavitelji se obravnavajo kot postavke v vprašalniku, ne kot odvisnosti obnovitve. Zaveze dobaviteljev glede neprekinjenega poslovanja, eskalacijski kontakti, dokazila o obnovitvi in sodelovanje pri vajah incidentov morajo biti povezani s kritičnimi storitvami.

Petič, manjka odobritev vodstva. Po NIS2 in DORA je odgovornost vodstva izrecna. Po ISO/IEC 27001:2022 so voditeljstvo, vloge, odobritev lastnika tveganja in poročanje o uspešnosti temeljne zahteve.

Šestič, testiranje je preozko. Obnovitev ene datoteke je koristna, vendar ne dokazuje obnovitve storitve. Pot obnovitve kritične storitve lahko vključuje DNS, identiteto, skrivnosti, infrastrukturo kot kodo, API prehode, spremljanje, beleženje, eskalacijo dobavitelja, komuniciranje s strankami in pregled zasebnosti.

Zenith Blueprint v fazi Controls in Action, korak 19, povzema presojevalsko pričakovanje glede varnostnih kopij:

Ali testirate svoje varnostne kopije?

Odgovor mora biti »da, z dokazili«, ta dokazila pa morajo biti povezana nazaj z BIA.

Paket dokazil BIA, pripravljen za presojo

Praktičen program BIA mora ustvariti jedrnat paket dokazil, ki se lahko uporablja za presoje, skrbni pregled strank, poročanje organu upravljanja in izboljšanje odpornosti.

Ta paket pripoveduje skladno zgodbo. Odpornost naredi tudi merljivo.

Naslednji korak: spremenite BIA v dokazila o skladnosti

Maria ne potrebuje večje preglednice. Potrebuje živo verigo dokazil.

Začnite z eno kritično storitvijo. Popišite njena sredstva IKT, podatke, ljudi, dobavitelje in infrastrukturne storitve. Odobrite MTD, RTO in RPO. Uskladite urnik varnostnega kopiranja. Preverite zaveze dobaviteljev glede obnovitve. Izvedite en test obnovitve. Zabeležite vrzeli. Posodobite načrt obravnave tveganja. Rezultat predstavite vodstvu.

Nato ponovite.

Clarysec lahko ta proces pospeši z uporabo Politike neprekinjenega poslovanja in obnovitve po nesreči, Politike neprekinjenega poslovanja in obnovitve po nesreči - SME, Politike varnostnega kopiranja in obnovitve, Politike spremljanja presoj in skladnosti, Zenith Blueprint in Zenith Controls.

Vaša BIA ne sme biti dokument za na polico, ustvarjen za presojo. Biti mora operativno dokazilo, da lahko vaše najpomembnejše storitve preživijo motnjo, izpolnijo pričakovanja strank in regulatorjev ter se obnovijo znotraj meja, ki jih je vaše vodstvo dejansko odobrilo.

Če se vaša organizacija pripravlja na nadzorno presojo ISO/IEC 27001:2022, zagotavljanje zaupanja strank po NIS2, preglede tretjih oseb na področju IKT po DORA ali poročanje o odpornosti na ravni organa upravljanja, začnite tako, da BIA naredite dokazljivo. Prenesite Clarysecove politike za neprekinjeno poslovanje in presojo, preglejte izvedbeni časovni načrt Zenith ali zahtevajte oceno dokazil o odpornosti, da razpršene kontrole povežete v eno zgodbo, pripravljeno za presojo.