Üzleti hatásvizsgálat ISO 27001-, NIS2- és DORA-megfeleléshez

Az auditkérdés, amely feltárja a valódi folytonossági hiányosságot

Hétfő reggel van, és Maria, egy gyorsan növekvő FinTech információbiztonsági vezetője, az igazgatóság kockázati bizottságának ülésére készül. A tárgysor rövid: „DORA- és NIS2-felkészültség: BIA-felülvizsgálat.”

A csapata elkészítette azt, amit a legtöbb felsővezető látni szeretne. Van tanúsított ISO/IEC 27001:2022 szerinti IBIR, incidensreagálási forgatókönyvek, biztonsági mentési képernyőképek, sérülékenységi jelentések, beszállítói kérdőívek, felhőarchitektúra-diagramok és frissített kockázati nyilvántartás. A nagyvállalati ügyfelek NIS2-kérdőíveket küldenek. A pénzügyi szektorbeli ügyfelek DORA-záradékokat építenek be a szerződésekbe. Az ISO/IEC 27001:2022 felügyeleti audit már csak egy hónapra van.

Ekkor a külső auditor felteszi azt a kérdést, amely megváltoztatja a helyiség hangulatát:

„Ha az ügyfél-belépési platform 18 órán keresztül nem érhető el, mely szabályozott szolgáltatásokat érinti, mely beszállítók érintettek, mi a jóváhagyott helyreállítási prioritás, és hol van annak bizonyítéka, hogy az üzlet elfogadta az RTO- és RPO-értékeket?”

A teremben csend lesz.

A biztonsági mentési ütemterv egy dolgot mond. A katasztrófa-helyreállítási terv mást. A beszállítói szerződés tartalmaz rendelkezésre állási SLA-t, de nincs helyreállítási tesztbizonyíték. A kockázati nyilvántartás említi a rendelkezésre állást, de nem magyarázza meg, miért kell az egyik szolgáltatásnak gyorsabban helyreállnia, mint a másiknak. A vezetés jóváhagyta a biztonsági szabályzatot, de az állásidő üzleti hatását nem.

Ez az üzleti hatásvizsgálat problémája 2026-ban.

Az üzleti hatásvizsgálat, vagy BIA, már nem egy folytonossági tervhez csatolt táblázat. Ez a bizonyítékhíd az üzleti szolgáltatások, IKT-eszközök, beszállítók, helyreállítási prioritások, RTO/RPO-célértékek, incidensküszöbök, rezilienciatesztelés és igazgatósági elszámoltathatóság között. Azoknál a szervezeteknél, amelyek az ISO/IEC 27001:2022 követelményeit a NIS2 folytonossági és a DORA IKT-reziliencia elvárásaival hozzák összhangba, a BIA az a pont, ahol a megfelelés operatívvá válik.

A legerősebb szervezeteknél már sok megfelelő kontroll rendelkezésre áll. A gyengeségük a visszakövethetőség. A BIA a szétszórt bizonyítékokat auditra alkalmas történetté rendezi: mi számít, miért számít, milyen gyorsan kell helyreállnia, milyen függőségek támogatják, mit teszteltek, mi hibásodott meg, mit javítottak, és ki hagyta jóvá a maradványkockázatot.

Miért jelentenek már kockázatot a régi BIA-táblázatok

A NIS2 és a DORA megváltoztatta a folytonossági megfelelés hangsúlyait. Nem külön dokumentumként kezelik az üzletmenet-folytonosságot, a katasztrófa-helyreállítást, az incidensreagálást, a beszállítói rezilienciát és az irányítást. Azt várják el, hogy ezek egyetlen rendszerként működjenek.

A NIS2 hatálya alá tartozó szervezetek esetében az Article 21 technikai, operatív és szervezeti intézkedéseket ír elő a hálózati és információs rendszereket érintő kockázatok kezelésére, valamint az incidensek szolgáltatást igénybe vevőkre és más szolgáltatásokra gyakorolt hatásának megelőzésére vagy minimalizálására. A minimális intézkedések közé tartozik a kockázatelemzés, az incidenskezelés, az üzletmenet-folytonosság — beleértve a biztonsági mentések kezelését —, a katasztrófa-helyreállítás és válságkezelés, az ellátási lánc biztonsága, a sérülékenységek kezelése, a kontrollhatékonyság értékelése, a képzés, a kriptográfia, a HR-biztonság, a hozzáférés-szabályozás, az eszközkezelés, a többtényezős hitelesítés és a biztonságos kommunikáció.

A NIS2 Article 20 az ügyet igazgatósági szintre emeli. A vezető testületeknek jóvá kell hagyniuk a kiberbiztonsági kockázatkezelési intézkedéseket, felügyelniük kell a végrehajtásukat, és jogsértések esetén felelősségre vonhatók. Ez azt jelenti, hogy egy alá nem támasztott négyórás RTO nem pusztán technikai ellentmondás. Irányítási gyengeség.

A DORA 2025. január 17-től alkalmazandó, és egységes EU-keretrendszert hoz létre az IKT-kockázatkezelésre, az incidensjelentésre, a digitális működési reziliencia tesztelésére, az IKT harmadik fél kockázatkezelésére, a szerződéses követelményekre, valamint a kritikus IKT harmadik fél szolgáltatók felügyeletére. A pénzügyi szervezetek, illetve a szerződéses úton őket támogató technológiai szolgáltatók számára a DORA az operatív rezilienciát strukturált bizonyítékkövetelménnyé alakítja.

A DORA Articles 5 és 6 irányítást és dokumentált IKT-kockázatkezelési keretrendszert követel meg. Az Articles 7–14 megbízható és reziliens IKT-rendszereket, eszköz- és függőségazonosítást, védelmet, észlelést, IKT üzletmenet-folytonosságot, biztonsági mentést, visszaállítást, helyreállítást, incidens utáni tanulást, tudatosságot, képzést és válságkommunikációt fednek le. Az Articles 24–26 digitális működési reziliencia tesztelést írnak elő a nem mikrovállalkozásnak minősülő pénzügyi szervezetek számára. Az Articles 28–30 formalizálják az IKT harmadik fél kockázatot, az IKT-szolgáltatási szerződések nyilvántartásait, a kilépési stratégiákat, a szolgáltatási szinteket, az auditálási jogokat és a vészhelyzeti követelményeket.

Az ISO/IEC 27001:2022 biztosítja az irányítási rendszer gerincét. Pontjai megkövetelik, hogy a szervezet meghatározza a környezetét, az érdekelt feleket, a jogi és szerződéses kötelezettségeket, a hatályt, a vezetői szerepvállalást, a szabályzatot, a szerepköröket, a kockázatértékelést, a kockázatkezelést, az alkalmazhatósági nyilatkozatot, a működéstervezést, a teljesítményértékelést és a folyamatos fejlesztést.

A hiányzó láncszem gyakran a BIA. Enélkül a folytonossági tervek nem egyértelműen kockázatalapúak, a biztonsági mentési célértékeket az üzlet nem hagyta jóvá, a beszállítók nincsenek kritikus szolgáltatásokhoz rendelve, és a vezetés nem tudja megbízhatóan igazolni, hogy a rezilienciára vonatkozó döntések üzleti hatáson alapultak.

A BIA mint a rezilienciabizonyítékok kontrollsíkja

Egy auditálható BIA hét olyan kérdésre ad választ, amelyet az auditorok, szabályozó hatóságok, ügyfelek és igazgatóságok egyre gyakrabban tesznek fel:

1. Mely üzleti szolgáltatások kritikusak?
2. Mely IKT-eszközök, adattárak, munkatársak, beszállítók és közművek támogatják az egyes szolgáltatásokat?
3. Időben előrehaladva mekkora a fennakadás operatív, pénzügyi, jogi, szerződéses, ügyfél-, biztonsági és reputációs hatása?
4. Mi a legnagyobb tolerálható kiesési idő (MTD)?
5. Melyek a jóváhagyott helyreállítási időcélok (RTO) és helyreállítási pontcélok (RPO)?
6. A biztonsági mentési, redundancia-, felhő-, beszállítói, személyzeti és kommunikációs megoldások elérhetővé teszik-e ezeket a célértékeket?
7. Tesztelte-e a szervezet a helyreállítási útvonalat, és felülvizsgálta-e az eredményeket?

A Clarysec vállalati Üzletmenet-folytonossági és katasztrófa-helyreállítási szabályzat című szabályzata P32 Üzletmenet-folytonossági és katasztrófa-helyreállítási szabályzat egyértelműen rögzíti a követelményt:

Az üzleti hatásvizsgálatot (BIA) legalább évente el kell végezni minden kritikus üzleti egységre, és felül kell vizsgálni a rendszerekben, folyamatokban vagy függőségekben bekövetkező jelentős változások esetén. A BIA kimeneteinek meg kell határozniuk: 5.2.1. legnagyobb tolerálható kiesési idő (MTD) 5.2.2. helyreállítási időcélok (RTO-k) 5.2.3. helyreállítási pontcélok (RPO-k) 5.2.4. kritikus függőségek (rendszerek, beszállítók, személyzet)

Ez a pont gyakorlati kiindulópontot ad az auditoroknak. Megelőzi azt a gyakori hibát is, amikor az üzletmenet-folytonossági terv, a katasztrófa-helyreállítási terv, a biztonsági mentési ütemterv, a beszállítói nyilvántartás és az incidensreagálási folyamat különbözőképpen határozza meg a „kritikus” fogalmát.

Ugyanez a szabályzat integrált irányítási megközelítést követel meg:

A szervezetnek integrált üzletmenet-folytonossági irányítási rendszert kell fenntartania az ISO 22301 és az ISO/IEC 27001 követelményeivel összhangban, biztosítva az alábbiak integrációját: 5.1.1. üzleti hatásvizsgálat (BIA) 5.1.2. folytonosságot veszélyeztető fenyegetések biztonsági kockázatértékelése 5.1.3. üzletmenet-folytonossági tervek (BCP) 5.1.4. IKT katasztrófa-helyreállítási tervek (DRP) 5.1.5. tesztelési és gyakorlási programok 5.1.6. dokumentálás és folyamatos fejlesztés

Ez különbözteti meg az ellenőrzőlista-alapú megfelelést az auditra alkalmas rezilienciától. A BIA nem egyszeri dokumentum. Az IBIR és a BCMS bizonyítékláncának részévé válik.

Hogyan alakítja az ISO/IEC 27001:2022 a BIA-t auditálható bizonyítékká

Az ISO/IEC 27001:2022 nem írja elő minden szervezet számára, hogy minden pontban a „Business Impact Analysis” kifejezést használja, de követelményei rendkívül értékessé teszik a BIA-bizonyítékokat.

A 4.1–4.4 pontok megkövetelik, hogy a szervezet megértse a belső és külső tényezőket, az érdekelt feleket, a jogi és szabályozási kötelezettségeket, a szerződéses követelményeket, az interfészeket, a függőségeket és az IBIR alkalmazási területét. A BIA gyakran a legpraktikusabb bizonyíték ezekre az interfészekre és függőségekre. Megmutatja, mely felhőszolgáltatás, fizetésfeldolgozó, identitásszolgáltató, távközlési szolgáltató, menedzselt biztonsági szolgáltatás, adatközpont vagy kiszervezett támogatási csapat tesz lehetővé egy kritikus szolgáltatást.

Az 5.1–5.3 pontok felső vezetői szerepvállalást, erőforrás-biztosítást, kommunikációt, szerepkör-hozzárendelést és jelentéstételt követelnek meg. A BIA üzleti alapot ad a vezetésnek a folytonossági beruházásokhoz. Enélkül az RTO- és RPO-célértékek technikai kívánságok, nem jóváhagyott üzleti követelmények.

A 6.1.1–6.1.3 pontok ismételhető információbiztonsági kockázatértékelést és kockázatkezelést írnak elő. A szervezetnek azonosítania kell a bizalmasságot, sértetlenséget és rendelkezésre állást érintő kockázatokat, elemeznie kell a következményeket és a valószínűséget, meg kell határoznia a kockázati szinteket, priorizálnia kell a kezelést, ki kell választania a kontrollokat, össze kell vetnie a kiválasztott kontrollokat az Annex A-val, el kell készítenie az alkalmazhatósági nyilatkozatot, kockázatkezelési tervet kell létrehoznia, és meg kell szereznie a kockázatgazda jóváhagyását. A BIA megerősíti a kockázatértékelés „következmény” oldalát. Megmagyarázza, miért tolerálható az egyik rendszer kétórás kiesése, miközben egy másik rendszer kétórás kiesése ügyfélkárt, szabályozói kitettséget, szerződésszegést vagy súlyos bevételi hatást okoz.

Az Annex A biztosítja a kontrollkatalógust. A BIA és a folytonosság szempontjából a legrelevánsabb ISO/IEC 27001:2022 Annex A kontrollok a következők:

A Zenith Controls: The Cross-Compliance Guide Zenith Controls kiadványban a Clarysec az ISO/IEC 27002:2022 5.30 kontrollt, az üzletmenet-folytonosságra vonatkozó IKT-felkészültséget, rendelkezésre állásra fókuszáló helyesbítő kontrollként mutatja be, a Respond kiberbiztonsági koncepcióhoz, a folytonossági működési képességhez és a reziliencia biztonsági területéhez rendelve. Az 5.29 kontrollt, az információbiztonságot fennakadás alatt, megelőző és helyesbítő kontrollként profilozza, amely a bizalmasságot, sértetlenséget és rendelkezésre állást védi. A 8.13 kontrollt, az információ biztonsági mentését, helyesbítő kontrollként mutatja be, amely helyreállításon keresztül támogatja a sértetlenséget és a rendelkezésre állást.

Ez a különbségtétel fontos. A BIA-nak nemcsak azt kell megkérdeznie, hogy „vissza tudunk-e állni?”. Azt is meg kell kérdeznie: „biztonságosak tudunk-e maradni fennakadás közben?”. Zsarolóvírus-esemény, felhőkiesés, beszállítói hiba vagy adatközponti incidens során a szervezetnek továbbra is szüksége van hozzáférés-szabályozásra, naplózásra, monitorozásra, bizonyítékmegőrzésre, biztonságos kommunikációra és adatvédelmi intézkedésekre.

A gyakorlati BIA-bizonyítékmodell

Az erős BIA összekapcsolja az üzleti nyelvet a technikai bizonyítékokkal. A Clarysec jellemzően öt rétegben strukturálja a bizonyítékmodellt.

Ez a bizonyítékmodell azért működik, mert az auditorok gondolkodásmódját követi. Először azt kérdezik, mi kritikus. Ezután azt, mi támogatja. Majd azt, ki hagyta jóvá a helyreállítási célértéket. Ezt követően azt, hogy a technikai és beszállítói megoldások képesek-e teljesíteni a célértéket. Végül azt, hogy a szervezet tesztelte-e és fejlesztette-e a képességet.

A NIST CSF 2.0 kommunikációs rétegként hasznos. A CSF Profiles módszere arra ösztönzi a szervezeteket, hogy határozzák meg a hatályt, gyűjtsenek be bemeneteket, például szabályzatokat, vállalati kockázati prioritásokat, BIA-nyilvántartásokat, kiberbiztonsági követelményeket, szabványokat, eljárásokat, védelmi intézkedéseket és munkaköri szerepeket, hozzanak létre jelenlegi és célprofilokat, elemezzék a hiányosságokat, készítsenek priorizált intézkedési tervet, hajtsák végre a tervet, és frissítsék a profilt. Ez szinte pontosan az, ahogyan a BIA-nak táplálnia kell egy több megfelelési követelményt lefedő ütemtervet.

Egyhetes BIA-gyakorlat, amely valódi bizonyítékot hoz létre

Tegyük fel, hogy egy SaaS-szolgáltató pénzügyi szolgáltatási ügyfeleket támogat. Platformja ügyfél-belépést, dokumentumellenőrzést és ügyfélértesítéseket támogat. Maga nem bank, de ügyfelei DORA-alapú szerződéses kéréseket és NIS2 beszállítói kérdőíveket küldenek.

Egy fókuszált egyhetes gyakorlat gyorsan hasznos bizonyítékokat hozhat létre.

1. nap: Kritikus szolgáltatások és hatásablakok azonosítása

Szolgáltatásokkal kezdjen, ne szerverekkel. Vonja be az üzlettulajdonosokat, az IT-t, az információbiztonsági, jogi, támogatási, adatvédelmi és beszállítókezelési területeket.

Ez a keretezés fontos. A szabályozó hatóságok és az ügyfelek szolgáltatásokat és funkciókat ismernek fel. Az alkalmazások azért fontosak, mert ezeket a szolgáltatásokat támogatják.

2. nap: Függőségek feltérképezése

Minden szolgáltatásnál térképezze fel az alkalmazásokat, adatbázisokat, infrastruktúrát, felhőszolgáltatásokat, identitásszolgáltatókat, monitorozást, biztonsági mentési eszközöket, munkatársakat, beszállítókat és támogató közműveket.

Itt kezd a BIA értéket teremteni. Feltárja a láthatatlan helyreállítási útvonalat, beleértve azokat a függőségeket is, amelyek gyakran kimaradnak egy technikai DR-tervből.

3. nap: MTD, RTO és RPO jóváhagyása

Az üzlettulajdonos javaslatot tesz az MTD-re. Az IT és az információbiztonsági terület ellenőrzi, hogy a javasolt RTO és RPO technikailag teljesíthető-e. A vezetés jóváhagyja a végleges célértékeket.

Kisebb szervezetek számára a Clarysec Üzletmenet-folytonossági és katasztrófa-helyreállítási szabályzat - SME című szabályzata P32S Üzletmenet-folytonossági és katasztrófa-helyreállítási szabályzat - SME egyszerűbb nyelvezettel biztosítja ugyanezt a fegyelmet. Megköveteli olyan BCP/DR-tervek kialakítását, amelyek rögzítik az alapvető funkciók helyreállításának megközelítését:

Az ügyvezetőnek (GM) jóvá kell hagynia és fenn kell tartania az üzletmenet-folytonossági és katasztrófa-helyreállítási terveket (BCP/DRP), amelyek egyértelműen meghatározzák a szervezet alapvető funkcióinak helyreállítására vonatkozó megközelítését.

Azt is előírja, hogy a terv tartalmazza:

priorizált szolgáltatások és rendszerek (kritikus üzleti funkciók)

Valamint:

helyreállítási időcélok (RTO-k) és helyreállítási pontcélok (RPO-k) minden rendszerre

A kulcs nem a túlzott dokumentálás. A kulcs a visszakövethetőség, a jóváhagyás és annak bizonyítéka, hogy a helyreállítási célkitűzések valós üzleti hatáson alapulnak.

4. nap: A biztonsági mentések összehangolása az üzleti hatással

Sok szervezet itt bukik el. A BIA négyórás RPO-t határozhat meg, miközben a biztonsági mentések 24 óránként futnak. Vagy a biztonsági mentési eszköz védi az éles adatbázisokat, de nem védi a konfigurációt, a titkos adatokat, az infrastructure-as-code adattárakat, az objektumtárolást, a DNS-bejegyzéseket, az identitásbeállításokat vagy az API-átjáró konfigurációját.

A Clarysec Biztonsági mentési és helyreállítási szabályzat című szabályzata P15 Biztonsági mentési és helyreállítási szabályzat a BIA-kimenetekhez kötött központi biztonsági mentési ütemtervet követel meg:

Központi biztonsági mentési ütemtervet kell fenntartani és évente felül kell vizsgálni. Ennek meg kell határoznia: 5.1.1. a biztonsági mentés gyakoriságát (például napi inkrementális mentések és heti teljes mentések) 5.1.2. megőrzési időtartamokat rendszerenként vagy adattípusonként 5.1.3. titkosítási követelményeket és tárolási hely adatait 5.1.4. az üzleti hatásvizsgálat eredményeihez kapcsolt RTO/RPO célértékeket

Ez a pont audit szempontból aranyat ér. Rákényszeríti a biztonsági mentések tervezését arra, hogy az üzleti hatást tükrözze, ne a tárolási kényelmet.

5. nap: Egy helyreállítási útvonal tesztelése és helyesbítő intézkedések megnyitása

Ne teszteljen mindent egyszerre. Válasszon ki egy kritikus szolgáltatást, és futtasson fókuszált helyreállítási tesztet. Állítsa vissza az adatbázist. Építse újra az alkalmazáskonfigurációt. Ellenőrizze a hitelesítést. Erősítse meg, hogy a naplók rendelkezésre állnak. Ellenőrizze az ügyfélértesítési képességet. Rögzítse a ráfordított időt, az adatvesztést, a hibákat, a döntéseket és a helyesbítő intézkedéseket.

A Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint Controls in Action szakaszának 23. lépése a szervezeti kontrollokkal foglalkozik, beleértve az üzletmenet-folytonosságra vonatkozó IKT-felkészültséget. Felteszi azt a kérdést, amelyet minden auditcsapatnak fel kell tennie:

Támogatni tudják-e a rendszerei az üzletmenet-folytonossági célkitűzéseket akkor, amikor a működés meginog, a hálózatok leállnak, vagy katasztrófa következik be?

Ugyanez a lépés gyakorlati utasítást is ad:

Ellenőrizze, hogy a kritikus rendszerek helyreállítási időcéljai (RTO) és helyreállítási pontcéljai (RPO) összhangban vannak-e az üzletmenet-folytonossági elvárásokkal (5.30). Végezzen legalább egy technikai helyreállítási tesztet vagy átkapcsolási szimulációt, és dokumentálja az eredményeket.

Ez a különbség aközött, hogy van BIA, és aközött, hogy auditálható BIA-bizonyíték áll rendelkezésre. A célérték nemcsak dokumentált. Tesztelt.

BIA-bizonyítékok megfeleltetése NIS2, DORA, GDPR, NIST és COBIT 2019 követelményeknek

A jól kialakított BIA több megfelelési követelményt lefedő eszközzé válik. Egyetlen bizonyítékkészlet számos kérdésre választ adhat.

A GDPR gyakran háttérbe szorul a BIA-val kapcsolatos beszélgetésekben. Pedig a GDPR Article 5 előírja, hogy a személyes adatokat sértetlenséggel és bizalmassággal kell kezelni, ideértve a véletlen elvesztés, megsemmisülés vagy károsodás elleni védelmet megfelelő technikai vagy szervezeti intézkedésekkel. Az elszámoltathatóság megköveteli, hogy az adatkezelő igazolni tudja a megfelelést. Ha egy személyesadat-platform nem állítható helyre jóváhagyott és tesztelt időkereten belül, az adatvédelmi kockázat érinti a rendelkezésre állást, a sértetlenséget, az incidens hatásvizsgálatát és az ügyfélbizalmat.

A NIS2 incidensjelentés újabb dimenziót ad. Az Article 23 előírja, hogy a jelentős incidenseket indokolatlan késedelem nélkül be kell jelenteni, beleértve a 24 órán belüli korai figyelmeztetést, a 72 órán belüli incidensbejelentést és az egy hónapon belüli zárójelentést. A BIA segít a súlyosság besorolásában, mert meghatározza az érintett szolgáltatásokat, a szolgáltatást igénybe vevőket, az operatív fennakadást és a lehetséges határokon átnyúló hatást.

A DORA incidensosztályozás figyelembe veszi az érintett ügyfeleket vagy tranzakciókat, az időtartamot, a földrajzi kiterjedést, az adatvesztéseket, az érintett szolgáltatások kritikusságát és a gazdasági hatást is. Ezek BIA-mezők. Ha a BIA gyenge, az incidensosztályozás éppen a lehető legrosszabb pillanatban válik szubjektívvé.

A beszállítói folytonosság az a pont, ahol a BIA találkozik a szerződéses valósággal

A NIS2 és a DORA esetében a beszállítói folytonosság már nem opcionális. A NIS2 Article 21 tartalmazza az ellátási lánc biztonságát, és figyelmet követel a beszállítói sérülékenységekre, a termékminőségre és rezilienciára, a beszállítói kiberbiztonsági gyakorlatokra és a biztonságos fejlesztési eljárásokra. A DORA megköveteli, hogy az IKT harmadik fél kockázatot az IKT-kockázatkezelési keretrendszeren belül kezeljék, beleértve az IKT-szolgáltatási szerződések nyilvántartásait, a kellő gondosságot, a koncentrációs kockázatot, a kilépési stratégiákat, az audit- és hozzáférési jogokat, az incidenshez nyújtott segítséget, a szolgáltatási szinteket és a vészhelyzeti követelményeket.

A vállalati Üzletmenet-folytonossági és katasztrófa-helyreállítási szabályzat előírja:

Harmadik felektől és ellátási lánctól való függőségek 6.5.1. A kritikus beszállítókkal kötött szerződéseknek folytonossági kötelezettségeket és helyreállítási időre vonatkozó vállalásokat kell tartalmazniuk. 6.5.2. A kulcsfontosságú szolgáltatóknak kérésre igazolniuk kell az időszakos folytonossági tesztelést és az incidensgyakorlatokban való részvételt.

Az SME-verzió ezt is megköveteli:

beszállítói folytonossági kapcsolattartási pontok

Ez a kis mező valós incidensben döntő lehet. Ha a helyreállítási terv azt mondja, hogy „kapcsolatfelvétel a felhőszolgáltató támogatásával”, de senki nem ismeri az eszkalációs útvonalat, a szerződéses hivatkozást, a súlyossági folyamatot vagy a munkaidőn kívüli elérhetőséget, az RTO csak fikció.

Ez a táblázat nem váltja ki a beszállítói kockázatkezelést. Operatívvá teszi a beszállítói kockázatot.

Hogyan fogják az auditorok tesztelni a BIA-t

Egy ISO/IEC 27001:2022 auditor általában a hatállyal, a környezettel, a kockázatértékeléssel, a kockázatkezeléssel, az alkalmazhatósági nyilatkozattal, az Annex A kontrollokkal, a dokumentált információkkal, a működéstervezéssel, a teljesítményértékeléssel és a fejlesztéssel kezdi. Összeveti a BIA-t a kockázatértékeléssel és az SoA-val. Ha az A.5.30, A.5.29 vagy A.8.13 szerepel, bizonyítékot fog kérni a bevezetésről és a tesztelésről.

Egy DORA-felülvizsgáló a kritikus vagy fontos funkciókra, az IKT-eszközökre, az IKT harmadik fél függőségekre, a rezilienciatesztelésre, az incidensosztályozásra, a szerződéses követelményekre, a kilépési stratégiákra és a vezető testületi felügyeletre fókuszál. Elvárja, hogy a BIA összhangban legyen az IKT-kockázatkezelési keretrendszerrel, a digitális működési reziliencia stratégiával, az IKT üzletmenet-folytonossági tervekkel, a reagálási és helyreállítási tervekkel, valamint a tesztelési programmal.

Egy NIS2-felügyeleti szerv üzletmenet-folytonossági intézkedéseket, biztonsági mentéskezelést, katasztrófa-helyreállítást, válságkezelést, ellátásilánc-biztonságot, irányítási jóváhagyást és jelentős incidensek bejelentésére való képességet fog kérni. A BIA-nak igazolnia kell, hogy ezek az intézkedések szolgáltatáshatáson és jóváhagyott prioritásokon alapulnak.

Egy NIST CSF 2.0 értékelő azt kérdezi majd, hogyan táplálja a BIA a Current Profile, Target Profile, hiányelemzés és intézkedési terv kialakítását. Megvizsgálja a Govern eredményeket a jogi, szabályozási, szerződéses, kockázati, szerepköri, szabályzati, felügyeleti és beszállítói kockázati döntések tekintetében. Emellett az Identify, Protect, Detect, Respond és Recover eredményeket is vizsgálni fogja.

Egy COBIT 2019 vagy ISACA-stílusú auditor általában az irányításra fókuszál. Ki a szolgáltatás tulajdonosa? Ki fogadta el a kockázatot? A célkitűzések összhangban vannak a vállalati célokkal? Monitorozzák a beszállítókat? Egyensúlyban vannak az előnyök, kockázatok és erőforrások? Nyomon követik a helyesbítő intézkedéseket a lezárásig?

A Clarysec Audit- és megfelelésfelügyeleti szabályzat című szabályzata Audit- és megfelelésfelügyeleti szabályzat a BIA-t az audittervezési ciklus részévé teszi:

Kockázatalapú audittervet kell kidolgozni és évente jóváhagyni, figyelembe véve: 5.2.1. a legutóbbi kockázatértékelések és üzleti hatásvizsgálat (BIA) eredményeit 5.2.2. korábbi auditmegállapításokat és a helyesbítő intézkedések státuszát 5.2.3. folyamatokban, informatikai infrastruktúrában, rendszerekben vagy beszállítókban bekövetkezett változásokat 5.2.4. külső kötelezettségeket, például DORA Article 25 vagy ügyfélszerződéseket

Ez olyan érettségi lépés, amelyet sok szervezet kihagy. A BIA-nak nem szabad a bizonyossági tevékenységeken kívül állnia. Vezérelnie kell az audittervet.

Valós értékelésekben feltárt gyakori BIA-hibák

Ugyanazok a gyengeségek ismétlődnek.

Először: a BIA alkalmazásokat sorol fel, nem szolgáltatásokat. Az ügyfelek és a szabályozó hatóságok a szolgáltatás-fennakadással foglalkoznak. Az alkalmazások azért fontosak, mert ezeket a szolgáltatásokat támogatják.

Másodszor: az RTO- és RPO-célértékeket sablonokból másolják. Egy négyórás RTO ésszerűnek tűnhet mindaddig, amíg a helyreállítási teszt ki nem mutatja, hogy kilenc órába telik az identitásintegráció újraépítése, a konfiguráció helyreállítása, az adatok visszaállítása, a sértetlenség ellenőrzése és a monitorozás újraengedélyezése.

Harmadszor: a biztonsági mentések nincsenek üzleti hatáshoz kötve. A gyakoriságnak, megőrzésnek, titkosításnak, tárolási helynek, helyreállítási prioritásnak és tesztelésnek a jóváhagyott helyreállítási célkitűzéseket kell tükröznie.

Negyedszer: a beszállítókat kérdőíves tételekként kezelik, nem helyreállítási függőségekként. A beszállítói folytonossági vállalásokat, eszkalációs kapcsolattartókat, helyreállítási bizonyítékokat és incidensgyakorlatokban való részvételt kritikus szolgáltatásokhoz kell kötni.

Ötödször: hiányzik a vezetői jóváhagyás. A NIS2 és a DORA alatt a vezetői elszámoltathatóság kifejezett. Az ISO/IEC 27001:2022 alatt a vezetői szerepvállalás, a szerepkörök, a kockázatgazda jóváhagyása és a teljesítményjelentés alapkövetelmények.

Hatodszor: a tesztelés túl szűk. Egy fájl visszaállítása hasznos, de nem igazolja a szolgáltatás helyreállítását. Egy kritikus szolgáltatás helyreállítási útvonala tartalmazhat DNS-t, identitást, titkos adatokat, infrastructure-as-code elemeket, API-átjárókat, monitorozást, naplózást, beszállítói eszkalációt, ügyfélkommunikációt és adatvédelmi felülvizsgálatot.

A Zenith Blueprint Controls in Action szakaszának 19. lépése így foglalja össze a biztonsági mentésekkel kapcsolatos auditelvárást:

Teszteli a biztonsági mentéseit?

A válasznak „igen, bizonyítékokkal” kell lennie, és ezeknek a bizonyítékoknak vissza kell kapcsolódniuk a BIA-hoz.

Az auditra alkalmas BIA-bizonyítékcsomag

Egy gyakorlati BIA-programnak tömör bizonyítékcsomagot kell előállítania, amely auditokhoz, ügyfél-átvilágításhoz, igazgatósági jelentéstételhez és rezilienciafejlesztéshez használható.

Ez a csomag koherens történetet mond el. A rezilienciát mérhetővé is teszi.

Következő lépés: alakítsa a BIA-t megfelelési bizonyítékká

Mariának nincs szüksége nagyobb táblázatra. Élő bizonyítékláncra van szüksége.

Kezdjen egy kritikus szolgáltatással. Térképezze fel annak IKT-eszközeit, adatait, munkatársait, beszállítóit és közműveit. Hagyassa jóvá az MTD-, RTO- és RPO-értékeket. Hangolja össze a biztonsági mentési ütemtervet. Ellenőrizze a beszállítói helyreállítási vállalásokat. Futtasson egy helyreállítási tesztet. Rögzítse a hiányosságokat. Frissítse a kockázatkezelési tervet. Mutassa be az eredményt a vezetésnek.

Majd ismételje meg.

A Clarysec segíthet felgyorsítani ezt a folyamatot az Üzletmenet-folytonossági és katasztrófa-helyreállítási szabályzat, az Üzletmenet-folytonossági és katasztrófa-helyreállítási szabályzat - SME, a Biztonsági mentési és helyreállítási szabályzat, az Audit- és megfelelésfelügyeleti szabályzat, a Zenith Blueprint és a Zenith Controls használatával.

A BIA nem lehet audit céljából létrehozott polctartalom. Annak operatív bizonyítékának kell lennie, hogy a legfontosabb szolgáltatásai képesek túlélni a fennakadást, teljesíteni az ügyfél- és szabályozói elvárásokat, és olyan határokon belül helyreállni, amelyeket a vezetés ténylegesen jóváhagyott.

Ha szervezete ISO/IEC 27001:2022 felügyeleti auditra, NIS2 ügyfélbizonyossági vizsgálatra, DORA IKT harmadik fél felülvizsgálatra vagy igazgatósági szintű rezilienciajelentésre készül, kezdje a BIA igazolhatóvá tételével. Töltse le a Clarysec folytonossági és auditszabályzatait, tekintse át a Zenith bevezetési ütemtervét, vagy kérjen rezilienciabizonyíték-értékelést, hogy a szétszórt kontrollokat egyetlen auditra alkalmas történetté alakítsa.