Ärimõju analüüs ISO 27001, NIS2 ja DORA jaoks

Auditiküsimus, mis paljastab tegeliku talitluspidevuse lünga

On esmaspäeva hommik ja kiiresti kasvava FinTechi infoturbejuht Maria valmistub juhatuse riskikomitee koosolekuks. Teemareal on lühike sõnum: „DORA ja NIS2 valmisolek: BIA läbivaatamine.“

Tema meeskond on koostanud selle, mida enamik tippjuhte ootaks. Olemas on sertifitseeritud ISO/IEC 27001:2022 ISMS, intsidentidele reageerimise tööjuhised, varunduse kuvatõmmised, haavatavuste aruanded, tarnijate küsimustikud, pilvearhitektuuri skeemid ja ajakohastatud riskiregister. Suurkliendid saadavad NIS2 küsimustikke. Finantssektori kliendid lisavad lepingutesse DORA klausleid. ISO/IEC 27001:2022 järelevalveauditini on jäänud vaid kuu.

Siis esitab välisaudiitor küsimuse, mis muudab ruumi õhkkonna:

„Kui teie kliendi kasutuselevõtu platvorm ei ole 18 tundi kättesaadav, millised reguleeritud teenused on mõjutatud, millised tarnijad on kaasatud, milline on heakskiidetud taasteprioriteet ning kus on tõendusmaterjal selle kohta, et ettevõte on RTO ja RPO aktsepteerinud?“

Ruum jääb vaikseks.

Varundusgraafik ütleb üht. Katastroofitaaste plaan ütleb teist. Tarnijaleping sisaldab käideldavuse SLA-d, kuid taastetesti tõendusmaterjali ei ole. Riskiregister mainib käideldavust, kuid ei selgita, miks üks teenus peab taastuma kiiremini kui teine. Juhtkond on heaks kiitnud infoturbepoliitika, kuid mitte seisaku ärimõju.

See on 2026. aasta ärimõju analüüsi probleem.

Ärimõju analüüs ehk BIA ei ole enam talitluspidevuse plaanile lisatud arvutustabel. See on tõendussild äriteenuste, IKT-varade, tarnijate, taasteprioriteetide, RTO/RPO, intsidendilävendite, toimepidevuse testimise ja juhatuse vastutuse vahel. Organisatsioonides, mis viivad ISO/IEC 27001:2022 vastavusse NIS2 talitluspidevuse ja DORA IKT-tegevuskerksusega, on BIA koht, kus vastavus muutub toimivaks juhtimiseks.

Tugevaimatel organisatsioonidel on juba olemas paljud õiged kontrollimeetmed. Nende nõrkus on jälgitavus. BIA muudab hajutatud tõendusmaterjali auditiks valmis looks: mis on oluline, miks see on oluline, kui kiiresti peab see taastuma, millised sõltuvused seda toetavad, mida on testitud, mis ebaõnnestus, mida parandati ja kes aktsepteeris jääkriski.

Miks vanad BIA arvutustabelid on nüüd risk

NIS2 ja DORA muutsid talitluspidevuse vastavuse käsitlust. Need ei käsitle talitluspidevust, katastroofitaastet, intsidentidele reageerimist, tarnijate toimepidevust ja juhtimist eraldi dokumentidena. Eeldus on, et need toimivad ühe süsteemina.

NIS2 üksuste puhul nõuab Article 21 tehnilisi, operatiivseid ja korralduslikke meetmeid võrgu- ja infosüsteemide riskide juhtimiseks ning intsidentide mõju vältimiseks või minimeerimiseks teenuse saajatele ja muudele teenustele. Miinimummeetmed hõlmavad riskianalüüsi, intsidentide käsitlemist, talitluspidevust koos varundamise haldusega, katastroofitaastet ja kriisijuhtimist, tarneahela turvet, haavatavuste käsitlemist, kontrollimeetmete tõhususe hindamist, koolitust, krüptograafiat, personaliturvet, juurdepääsukontrolli, varahaldust, MFA-d ja turvalist sidet.

NIS2 Article 20 viib küsimuse juhatuse tasandile. Juhtorganid peavad küberturberiski juhtimise meetmed heaks kiitma, nende rakendamist jälgima ning võivad rikkumiste eest vastutada. See tähendab, et põhjendamata neljatunnine RTO ei ole ainult tehniline vastuolu. See on juhtimisnõrkus.

DORA kohaldub alates 17. jaanuarist 2025 ning loob ühtse EL-i raamistiku IKT-riski juhtimiseks, intsidentidest teatamiseks, digitaalse tegevuskerksuse testimiseks, IKT kolmandate isikute riski juhtimiseks, lepinguliste nõuete täitmiseks ja kriitiliste kolmandast isikust IKT-teenuse osutajate järelevalveks. Finantsüksuste ning neid lepingute kaudu toetavate tehnoloogiapakkujate jaoks muudab DORA tegevuskerksuse struktureeritud tõendusnõudeks.

DORA Articles 5 ja 6 nõuavad juhtimist ning dokumenteeritud IKT-riski juhtimise raamistikku. Articles 7 kuni 14 käsitlevad usaldusväärseid ja vastupidavaid IKT-süsteeme, varade ja sõltuvuste tuvastamist, kaitset, tuvastamist, IKT talitluspidevust, varundust, taastamist, intsidendijärgset õppimist, teadlikkust, koolitust ja kriisikommunikatsiooni. Articles 24 kuni 26 nõuavad digitaalse tegevuskerksuse testimist finantsüksustelt, kes ei ole mikroettevõtted. Articles 28 kuni 30 formaliseerivad IKT kolmandate isikute riski, IKT-teenuste lepingute registrid, väljumisstrateegiad, teenustasemed, auditeerimisõigused ja talitluspidevuse nõuded.

ISO/IEC 27001:2022 annab juhtimissüsteemi selgroo. Selle klauslid nõuavad, et organisatsioon määratleks konteksti, huvitatud osapooled, õiguslikud ja lepingulised kohustused, kohaldamisala, eestvedamise, poliitika, rollid, riskihindamise, riskikäsitluse, kohaldatavusdeklaratsiooni, tegevuse planeerimise, toimivuse hindamise ja pideva parendamise.

Puuduv lüli on sageli BIA. Ilma selleta ei ole talitluspidevuse plaanid selgelt riskipõhised, varunduse eesmärgid ei ole äritegevuse poolt heaks kiidetud, tarnijad ei ole kriitiliste teenustega kaardistatud ning juhtkond ei saa usaldusväärselt tõendada, et toimepidevuse otsused lähtusid ärimõjust.

BIA kui toimepidevuse tõendusmaterjali kontrollitasand

Kaitstav BIA vastab seitsmele küsimusele, mida audiitorid, regulaatorid, kliendid ja juhatused üha sagedamini esitavad:

1. Millised äriteenused on kriitilised?
2. Millised IKT-varad, andmehoidlad, inimesed, tarnijad ja tugiteenused iga teenust toetavad?
3. Milline on katkestuse operatiivne, finantsiline, õiguslik, lepinguline, kliendiga seotud, ohutusalane ja mainealane mõju aja jooksul?
4. Mis on maksimaalne talutav katkestuse kestus ehk MTD?
5. Millised on heakskiidetud taasteaja eesmärk ehk RTO ja taastepunkti eesmärk ehk RPO?
6. Kas varunduse, liiasuse, pilve, tarnijate, personalikatte ja kommunikatsiooni korraldus võimaldab need eesmärgid saavutada?
7. Kas organisatsioon on taasteteekonda testinud ja tulemused läbi vaadanud?

Clarysec’i ettevõtte Talitluspidevuse ja katastroofitaaste poliitika P32 Talitluspidevuse ja katastroofitaaste poliitika sätestab nõude selgelt:

Kõigi kriitiliste äriüksuste kohta tuleb vähemalt kord aastas teha ärimõju analüüs (BIA) ning see tuleb läbi vaadata oluliste muudatuste korral süsteemides, protsessides või sõltuvustes. BIA väljundid peavad määratlema: 5.2.1. maksimaalne talutav katkestuse kestus (MTD) 5.2.2. taasteaja eesmärgid (RTO-d) 5.2.3. taastepunkti eesmärgid (RPO-d) 5.2.4. kriitilised sõltuvused (süsteemid, tarnijad, personal)

See klausel annab audiitoritele praktilise lähtekoha. Samuti väldib see levinud läbikukkumist, kus talitluspidevuse plaan, katastroofitaaste plaan, varundusgraafik, tarnijaregister ja intsidentidele reageerimise protsess kasutavad kõik erinevat „kriitilise“ määratlust.

Sama poliitika nõuab integreeritud juhtimiskäsitlust:

Organisatsioon peab haldama integreeritud talitluspidevuse juhtimissüsteemi (BCMS), mis on kooskõlas ISO 22301 ja ISO/IEC 27001-ga ning tagab järgmiste elementide lõimimise: 5.1.1. ärimõju analüüs (BIA) 5.1.2. turberiskide hindamine talitluspidevuse ohtude suhtes 5.1.3. talitluspidevuse plaanid (BCP-d) 5.1.4. IKT katastroofitaaste plaanid (DRP-d) 5.1.5. testimis- ja õppuseprogrammid 5.1.6. dokumentatsioon ja pidev parendamine

See eristab kontrollnimekirjapõhist vastavust auditiks valmis toimepidevusest. BIA ei ole ühekordne dokument. Sellest saab osa ISMS-i ja BCMS-i tõendusahelast.

Kuidas ISO/IEC 27001:2022 muudab BIA auditiks sobivaks tõendusmaterjaliks

ISO/IEC 27001:2022 ei nõua, et iga organisatsioon kasutaks igas klauslis väljendit „ärimõju analüüs“, kuid selle nõuded muudavad BIA tõendusmaterjali väga väärtuslikuks.

Klauslid 4.1 kuni 4.4 nõuavad, et organisatsioon mõistaks sisemisi ja väliseid teemasid, huvitatud osapooli, õiguslikke ja regulatiivseid kohustusi, lepingulisi nõudeid, liideseid, sõltuvusi ja ISMS-i kohaldamisala. BIA on sageli kõige praktilisem tõendusmaterjal nende liideste ja sõltuvuste kohta. See näitab, milline pilveteenus, maksetöötleja, identiteedipakkuja, telekommunikatsiooniteenuse osutaja, hallatav turbeteenus, andmekeskus või allhankena osutatav tugimeeskond võimaldab kriitilise teenuse toimimist.

Klauslid 5.1 kuni 5.3 nõuavad tippjuhtkonna eestvedamist, ressursside tagamist, teabevahetust, rollide määramist ja aruandlust. BIA annab juhtkonnale ärilise aluse talitluspidevuse investeeringuteks. Ilma selleta on RTO ja RPO eesmärgid tehnilised soovid, mitte heakskiidetud ärinõuded.

Klauslid 6.1.1 kuni 6.1.3 nõuavad korratavat infoturbe riskihindamist ja riskikäsitlust. Organisatsioon peab tuvastama riskid konfidentsiaalsusele, terviklusele ja käideldavusele, analüüsima tagajärgi ja tõenäosust, määrama riskitasemed, prioriseerima riskikäsitluse, valima kontrollimeetmed, võrdlema valitud kontrollimeetmeid lisaga A, koostama kohaldatavusdeklaratsiooni, looma riskikäsitluse plaani ning saama riskiomaniku heakskiidu. BIA tugevdab riskihindamise „tagajärje“ poolt. See selgitab, miks ühe süsteemi kahetunnine katkestus on talutav, samas kui teise süsteemi kahetunnine katkestus põhjustab kliendikahju, regulatiivse riski, lepingurikkumise või olulise mõju tulule.

Lisa A annab kontrollikataloogi. BIA ja talitluspidevuse jaoks on kõige asjakohasemad ISO/IEC 27001:2022 lisa A kontrollimeetmed järgmised:

Dokumendis Zenith Controls: ristvastavuse juhend Zenith Controls käsitleb Clarysec ISO/IEC 27002:2022 kontrolli 5.30, IKT valmisolek talitluspidevuseks, korrigeeriva kontrollimeetmena, mis keskendub käideldavusele ning on kaardistatud Respond küberturbe funktsiooni, talitluspidevuse operatiivse võimekuse ja toimepidevuse turbevaldkonnaga. Kontroll 5.29, infoturve katkestuse ajal, on kirjeldatud ennetava ja korrigeerivana ning kaitseb konfidentsiaalsust, terviklust ja käideldavust. Kontroll 8.13, teabe varundamine, on kirjeldatud korrigeerivana ning toetab taastamise kaudu terviklust ja käideldavust.

See eristus on oluline. BIA ei tohi küsida ainult: „Kas me saame taastada?“ See peab küsima ka: „Kas me jääme katkestuse ajal turvaliseks?“ Lunavarasündmuse, pilvekatkestuse, tarnija rikke või andmekeskuse intsidendi ajal vajab organisatsioon endiselt juurdepääsukontrolli, logimist, seiret, tõendusmaterjali säilitamist, turvalist sidet ja privaatsuse kaitsemeetmeid.

Praktiline BIA tõendusmudel

Tugev BIA seob ärikeele tehnilise tõendusmaterjaliga. Clarysec struktureerib tõendusmudeli tavaliselt viieks kihiks.

See tõendusmudel töötab, sest järgib audiitorite mõtlemisviisi. Kõigepealt küsitakse, mis on kriitiline. Seejärel küsitakse, mis seda toetab. Siis küsitakse, kes taaste-eesmärgi heaks kiitis. Seejärel küsitakse, kas tehnilised ja tarnijatega seotud korraldused võimaldavad eesmärgi saavutada. Lõpuks küsitakse, kas organisatsioon on võimekust testinud ja parandanud.

NIST CSF 2.0 on kasulik kommunikatsioonikihina. Selle CSF profiilide meetod julgustab organisatsioone määratlema kohaldamisala, koguma sisendeid, nagu poliitikad, ettevõtte riskiprioriteedid, BIA registrid, küberturbenõuded, standardid, protseduurid, kaitsemeetmed ja töörollid, looma praegused ja sihtprofiilid, analüüsima lünki, koostama prioriseeritud tegevusplaani, seda plaani rakendama ning profiili ajakohastama. See on peaaegu täpselt see, kuidas BIA peaks toitma ristvastavuse teekaarti.

Ühenädalane BIA harjutus, mis loob tegeliku tõendusmaterjali

Oletame, et SaaS-teenuseosutaja toetab finantsteenuste kliente. Tema platvorm toetab klientide kasutuselevõttu, dokumentide kontrolli ja klienditeavitusi. Ta ei ole ise pank, kuid kliendid saadavad DORA-st lähtuvaid lepingulisi päringuid ja NIS2 tarnijaküsimustikke.

Fookustatud ühenädalane harjutus võib kiiresti luua kasulikku tõendusmaterjali.

1. päev: tuvastage kriitilised teenused ja mõjuaknad

Alustage teenustest, mitte serveritest. Kaasake äriprotsesside omanikud, IT, infoturbe eest vastutav üksus, õigus, kasutajatugi, andmekaitse ja tarnijate haldus.

Selline raamistik on oluline. Regulaatorid ja kliendid tunnevad ära teenused ja funktsioonid. Rakendused on olulised seetõttu, et need toetavad neid teenuseid.

2. päev: kaardistage sõltuvused

Kaardistage iga teenuse puhul rakendused, andmebaasid, taristu, pilveteenused, identiteedipakkujad, seire, varundustööriistad, inimesed, tarnijad ja toetavad tugiteenused.

Siin hakkab BIA väärtust looma. See paljastab nähtamatu taasteteekonna, sealhulgas sõltuvused, mis tehnilises DR-plaanis sageli märkamata jäävad.

3. päev: kinnitage MTD, RTO ja RPO

Äriprotsessi omanik teeb MTD ettepaneku. IT ja infoturbe eest vastutav üksus valideerivad, kas pakutud RTO ja RPO on tehniliselt saavutatavad. Juhtkond kinnitab lõplikud eesmärgid.

Väiksemate organisatsioonide jaoks annab Clarysec’i Talitluspidevuse ja katastroofitaaste poliitika - VKE P32S Talitluspidevuse ja katastroofitaaste poliitika - VKE sama distsipliini lihtsamas keeles. See nõuab BCP/DR plaane, mis kirjeldavad oluliste funktsioonide taastamise käsitlust:

Tegevjuht (GM) peab heaks kiitma ja haldama talitluspidevuse ja katastroofitaaste plaane (BCP/DRP), mis kirjeldavad selgelt organisatsiooni käsitlust oluliste funktsioonide taastamisel.

Samuti nõuab plaan järgmist:

prioriseeritud teenused ja süsteemid (kriitilised ärifunktsioonid)

Ja:

taasteaja eesmärgid (RTO-d) ja taastepunkti eesmärgid (RPO-d) iga süsteemi kohta

Võti ei ole liigne dokumenteerimine. Võti on jälgitavus, heakskiit ja tõendusmaterjal selle kohta, et taaste-eesmärgid põhinevad tegelikul ärimõjul.

4. päev: viige varundus vastavusse ärimõjuga

Paljud organisatsioonid ebaõnnestuvad just siin. BIA võib määrata neljatunnise RPO, samal ajal kui varundus toimub iga 24 tunni järel. Või kaitseb varundustööriist tootmisandmebaase, kuid mitte konfiguratsiooni, saladusi, taristu kui koodi repositooriume, objektisalvestust, DNS-kirjeid, identiteediseadeid ega API-lüüsi konfiguratsiooni.

Clarysec’i Varundamise ja taastamise poliitika P15 Varundamise ja taastamise poliitika nõuab BIA tulemustega seotud põhilist varundusgraafikut:

Tuleb hallata põhilist varundusgraafikut ja vaadata see igal aastal läbi. See peab määratlema: 5.1.1 varundussagedus (näiteks igapäevased inkrementaalvarukoopiad ja iganädalased täisvarukoopiad) 5.1.2 säilitustähtajad süsteemi või andmetüübi kaupa 5.1.3 krüptimisnõuded ja salvestuskoha üksikasjad 5.1.4 RTO/RPO eesmärgid, mis on seotud ärimõju hindamise tulemustega

See klausel on auditi seisukohast väga väärtuslik. See sunnib varunduse disaini kajastama ärimõju, mitte salvestusmugavust.

5. päev: testige üht taasteteekonda ja avage parandusmeetmed

Ärge testige kõike korraga. Valige üks kriitiline teenus ja viige läbi fookustatud taastetest. Taastage andmebaas. Taastage rakenduse konfiguratsioon. Valideerige autentimine. Kinnitage, et logid on kättesaadavad. Kontrollige klienditeavituste võimekust. Kirjendage kulunud aeg, andmekadu, puudused, otsused ja parandusmeetmed.

Dokumendis Zenith Blueprint: audiitori 30-sammuline teekaart Zenith Blueprint käsitleb etapp „Kontrollimeetmed tegevuses“, samm 23, organisatsioonilisi kontrollimeetmeid, sealhulgas IKT valmisolekut talitluspidevuseks. See esitab küsimuse, mida iga auditimeeskond peaks küsima:

Kas teie süsteemid suudavad toetada teie talitluspidevuse eesmärke siis, kui tuled vilguvad, võrgud katkevad ja katastroof tabab?

Sama samm annab praktilise juhise:

Kontrollige, et kriitiliste süsteemide taasteaja eesmärgid (RTO) ja taastepunkti eesmärgid (RPO) oleksid kooskõlas talitluspidevuse ootustega (5.30). Tehke vähemalt üks tehniline taastetest või ümberlülituse simulatsioon ja dokumenteerige tulemused.

See on erinevus BIA olemasolu ja kaitstava BIA tõendusmaterjali vahel. Eesmärk ei ole üksnes dokumenteeritud. See on testitud.

BIA tõendusmaterjali vastendamine NIS2, DORA, GDPR, NIST ja COBIT 2019 nõuetega

Hästi üles ehitatud BIA muutub ristvastavuse varaks. Üks tõendusmaterjali kogum võib vastata paljudele küsimustele.

GDPR jääb BIA aruteludes sageli tähelepanuta. Ometi nõuab GDPR Article 5, et isikuandmeid töödeldaks tervikluse ja konfidentsiaalsusega, sealhulgas kaitstaks juhusliku kaotsimineku, hävimise või kahjustumise eest asjakohaste tehniliste või korralduslike meetmetega. Vastutus nõuab, et vastutav töötleja tõendaks vastavust. Kui isikuandmete platvormi ei saa taastada heakskiidetud ja testitud aja jooksul, mõjutab privaatsusrisk käideldavust, terviklust, rikkumise hindamist ja klientide usaldust.

NIS2 intsidenditeavitus lisab veel ühe mõõtme. Article 23 nõuab olulistest intsidentidest teatamist põhjendamatu viivituseta, sealhulgas varajast hoiatust 24 tunni jooksul, intsidenditeavitust 72 tunni jooksul ja lõpparuannet ühe kuu jooksul. BIA aitab tõsidust klassifitseerida, sest see määratleb mõjutatud teenused, teenuse saajad, tegevushäire ja võimaliku piiriülese mõju.

DORA intsidendiklassifikatsioon arvestab samuti mõjutatud kliente või tehinguid, kestust, geograafilist ulatust, andmekadusid, mõjutatud teenuste kriitilisust ja majanduslikku mõju. Need on BIA väljad. Kui BIA on nõrk, muutub intsidendi klassifitseerimine subjektiivseks just kõige halvemal hetkel.

Tarnijate talitluspidevus on koht, kus BIA kohtub lepingu tegelikkusega

NIS2 ja DORA puhul ei ole tarnijate talitluspidevus enam valikuline. NIS2 Article 21 hõlmab tarneahela turvet ning nõuab tähelepanu tarnijate haavatavustele, toodete kvaliteedile ja toimepidevusele, tarnijate küberturbepraktikatele ja turvalise arenduse protseduuridele. DORA nõuab, et IKT kolmandate isikute riski juhitaks IKT riskiraamistikus, sealhulgas IKT teenuslepingute registrid, taustakontroll, kontsentratsioonirisk, väljumisstrateegiad, auditi- ja juurdepääsuõigused, intsidentide korral abi osutamine, teenustasemed ja talitluspidevuse nõuded.

Ettevõtte Talitluspidevuse ja katastroofitaaste poliitika nõuab:

Kolmandate isikute ja tarneahela sõltuvused 6.5.1. Kriitiliste tarnijatega sõlmitud lepingud peavad sisaldama talitluspidevuskohustusi ja taasteaja kohustusi. 6.5.2. Olulised teenuseosutajad peavad taotluse korral tõendama perioodilist talitluspidevuse testimist ja osalemist intsidendiõppustel.

VKE versioon nõuab samuti:

tarnija talitluspidevuse kontaktpunktid

See väike väli võib reaalse intsidendi korral olla määrav. Kui teie taastamisplaan ütleb „võtke ühendust pilveteenuse pakkuja toega“, kuid keegi ei tea eskaleerimisteed, lepinguviidet, tõsidusprotsessi ega töövälise aja kontakti, on RTO fiktsioon.

See tabel ei asenda tarnijate riskijuhtimist. See muudab tarnijariski operatiivseks.

Kuidas audiitorid teie BIA-d testivad

ISO/IEC 27001:2022 audiitor alustab tavaliselt kohaldamisalast, kontekstist, riskihindamisest, riskikäsitlusest, kohaldatavusdeklaratsioonist, lisa A kontrollimeetmetest, dokumenteeritud teabest, tegevuse planeerimisest, toimivuse hindamisest ja parendamisest. Ta võrdleb BIA-d riskihindamise ja SoA-ga. Kui A.5.30, A.5.29 või A.8.13 on hõlmatud, küsib ta rakendamise ja testimise tõendusmaterjali.

DORA hindaja keskendub kriitilistele või olulistele funktsioonidele, IKT-varadele, IKT kolmandate isikute sõltuvustele, toimepidevuse testimisele, intsidendiklassifikatsioonile, lepingulistele nõuetele, väljumisstrateegiatele ja juhtorgani järelevalvele. Ta eeldab, et BIA on kooskõlas IKT riskijuhtimise raamistikuga, digitaalse tegevuskerksuse strateegiaga, IKT talitluspidevuse plaanidega, reageerimis- ja taastamisplaanidega ning testimisprogrammiga.

NIS2 järelevalveasutus küsib talitluspidevuse meetmete, varundamise halduse, katastroofitaaste, kriisijuhtimise, tarneahela turbe, juhtkonna heakskiidu ja olulistest intsidentidest teatamise võimekuse kohta. BIA peab tõendama, et need meetmed põhinevad teenuse mõjul ja heakskiidetud prioriteetidel.

NIST CSF 2.0 hindaja küsib, kuidas BIA annab sisendi praegusele profiilile, sihtprofiilile, lünkade analüüsile ja tegevusplaanile. Ta vaatab Govern tulemusi õiguslike, regulatiivsete, lepinguliste, riski-, rolli-, poliitika-, järelevalve- ja tarnijariski otsuste osas. Samuti uurib ta Identify, Protect, Detect, Respond ja Recover tulemusi.

COBIT 2019 või ISACA-stiilis audiitor keskendub tavaliselt juhtimisele. Kes on teenuse omanik? Kes aktsepteeris riski? Kas eesmärgid on kooskõlas ettevõtte eesmärkidega? Kas tarnijaid seiratakse? Kas kasud, riskid ja ressursid on tasakaalus? Kas parandusmeetmete täitmist jälgitakse kuni sulgemiseni?

Clarysec’i Auditi ja vastavuse seire poliitika Auditi ja vastavuse seire poliitika muudab BIA auditi planeerimistsükli osaks:

Riskipõhine auditiplaan tuleb koostada ja heaks kiita igal aastal, võttes arvesse: 5.2.1 viimaste riskihindamiste ja ärimõju analüüsi (BIA) tulemusi 5.2.2 varasemaid auditileide ja parandusmeetmete staatust 5.2.3 muudatusi protsessides, IT-taristus, süsteemides või tarnijates 5.2.4 väliseid kohustusi, nagu DORA Article 25 või kliendilepingud

See on küpsusaste, mis paljudel organisatsioonidel jääb saavutamata. BIA ei tohiks olla kindlust andvast tegevusest eraldi. See peaks auditiplaani juhtima.

Levinud BIA puudused tegelikes hindamistes

Samad nõrkused korduvad sageli.

Esiteks loetleb BIA rakendusi, mitte teenuseid. Kliente ja regulaatoreid huvitab teenusekatkestus. Rakendused on olulised seetõttu, et need toetavad neid teenuseid.

Teiseks kopeeritakse RTO ja RPO eesmärgid mallidest. Neljatunnine RTO võib tunduda mõistlik, kuni taastetest näitab, et identiteediintegratsiooni taastamine, konfiguratsiooni taastamine, andmete taastamine, tervikluse valideerimine ja seire uuesti lubamine võtab üheksa tundi.

Kolmandaks ei ole varukoopiad seotud ärimõjuga. Sagedus, säilitustähtaeg, krüptimine, salvestuskoht, taastamise prioriteet ja testimine peavad kajastama heakskiidetud taaste-eesmärke.

Neljandaks käsitletakse tarnijaid küsimustiku objektidena, mitte taastamise sõltuvustena. Tarnijate talitluspidevuskohustused, eskalatsioonikontaktid, taastamise tõendusmaterjal ja intsidendiõppustel osalemine tuleb siduda kriitiliste teenustega.

Viiendaks puudub juhtkonna heakskiit. NIS2 ja DORA alusel on juhtkonna vastutus selgesõnaline. ISO/IEC 27001:2022 alusel on eestvedamine, rollid, riskiomaniku heakskiit ja toimivusaruandlus põhinõuded.

Kuuendaks on testimine liiga kitsas. Ühe faili taastamine on kasulik, kuid see ei tõenda teenuse taastamist. Kriitilise teenuse taasteteekond võib hõlmata DNS-i, identiteeti, saladusi, taristu kui koodi, API-lüüse, seiret, logimist, tarnija eskalatsiooni, kliendikommunikatsiooni ja andmekaitse läbivaatust.

Zenith Blueprint kirjeldab etapis „Kontrollimeetmed tegevuses“, samm 19, varundusega seotud auditi ootust:

Kas te testite oma varukoopiaid?

Vastus peab olema „jah, koos tõendusmaterjaliga“ ning see tõendusmaterjal peab olema seotud BIA-ga.

Auditiks valmis BIA tõenduspakett

Praktiline BIA programm peaks looma kokkuvõtliku tõenduspaketi, mida saab kasutada auditites, klientide hoolsuskontrollis, juhatuse aruandluses ja toimepidevuse parandamisel.

See pakett räägib sidusa loo. Samuti muudab see toimepidevuse mõõdetavaks.

Järgmine samm: muutke oma BIA vastavuse tõendusmaterjaliks

Maria ei vaja suuremat arvutustabelit. Ta vajab elavat tõendusahelat.

Alustage ühest kriitilisest teenusest. Kaardistage selle IKT-varad, andmed, inimesed, tarnijad ja tugiteenused. Kinnitage MTD, RTO ja RPO. Viige varundusgraafik vastavusse. Kontrollige tarnijate taastekohustusi. Tehke üks taastetest. Kirjendage lüngad. Ajakohastage riskikäsitluse plaani. Esitage tulemus juhtkonnale.

Seejärel korrake.

Clarysec saab seda protsessi kiirendada, kasutades Talitluspidevuse ja katastroofitaaste poliitikat, Talitluspidevuse ja katastroofitaaste poliitikat - VKE, Varundamise ja taastamise poliitikat, Auditi ja vastavuse seire poliitikat, Zenith Blueprinti ja Zenith Controlsi.

Teie BIA ei tohiks olla auditi jaoks loodud riiulidokument. See peaks olema operatiivne tõendus, et teie kõige olulisemad teenused suudavad katkestuse üle elada, täita klientide ja regulatiivseid ootusi ning taastuda piirides, mille teie juhtkond on tegelikult heaks kiitnud.

Kui teie organisatsioon valmistub ISO/IEC 27001:2022 järelevalveauditiks, NIS2 kliendikindluse tõendamiseks, DORA IKT kolmanda isiku ülevaatusteks või juhatuse tasandi toimepidevusaruandluseks, alustage BIA kaitstavaks muutmisest. Laadige alla Clarysec’i talitluspidevuse ja auditi poliitikad, vaadake läbi Zenith rakendamise teekaart või taotlege toimepidevuse tõendusmaterjali hindamist, et muuta hajutatud kontrollimeetmed üheks auditiks valmis looks.