Analýza dopadov na podnikanie pre ISO 27001, NIS2 a DORA

Auditná otázka, ktorá odhalí skutočnú medzeru v pripravenosti na kontinuitu

Je pondelkové ráno a Maria, CISO rýchlo rastúcej fintech spoločnosti, sa pripravuje na zasadnutie výboru predstavenstva pre riziká. Predmet e-mailu je stručný: „Pripravenosť na DORA a NIS2: preskúmanie BIA.“

Jej tím pripravil to, čo väčšina výkonných manažérov očakáva. Organizácia má certifikovaný systém manažérstva informačnej bezpečnosti (ISMS) podľa ISO/IEC 27001:2022, playbooky reakcie na incidenty, snímky obrazovky zo zálohovania, správy o zraniteľnostiach, dotazníky dodávateľov, diagramy cloudovej architektúry a aktualizovaný register rizík. Podnikoví zákazníci posielajú dotazníky k NIS2. Klienti z finančného sektora presadzujú doložky podľa DORA do zmlúv. Dozorný audit ISO/IEC 27001:2022 je už o mesiac.

Potom externý audítor položí otázku, ktorá zmení atmosféru v miestnosti:

„Ak bude vaša platforma na onboarding zákazníkov nedostupná 18 hodín, ktoré regulované služby budú dotknuté, ktorí dodávatelia sú zapojení, aká je schválená priorita obnovy a kde je dôkaz, že organizácia akceptovala RTO a RPO?“

V miestnosti nastane ticho.

Harmonogram zálohovania hovorí jedno. Plán obnovy po havárii hovorí niečo iné. Zmluva s dodávateľom obsahuje SLA dostupnosti, ale neobsahuje dôkaz z testu obnovy. Register rizík spomína dostupnosť, ale nevysvetľuje, prečo sa jedna služba musí obnoviť rýchlejšie než iná. Manažment schválil bezpečnostnú politiku, nie však dopad výpadku na podnikanie.

To je problém analýzy dopadov na podnikanie v roku 2026.

Analýza dopadov na podnikanie, teda BIA, už nie je tabuľkový prehľad priložený k plánu kontinuity. Je to dôkazový most medzi službami organizácie, aktívami IKT, dodávateľmi, prioritami obnovy, RTO/RPO, prahmi incidentov, testovaním odolnosti a zodpovednosťou predstavenstva. Pre organizácie, ktoré zosúlaďujú ISO/IEC 27001:2022 s kontinuitou podľa NIS2 a odolnosťou IKT podľa DORA, je BIA miestom, kde sa súlad mení na prevádzkovú realitu.

Najsilnejšie organizácie už majú mnoho správnych kontrol. Ich slabinou je sledovateľnosť. BIA premieňa rozptýlené dôkazy na auditovateľný príbeh: čo je dôležité, prečo je to dôležité, ako rýchlo sa to musí obnoviť, ktoré závislosti to podporujú, čo bolo otestované, čo zlyhalo, čo sa zlepšilo a kto schválil zvyškové riziko.

Prečo sú staré tabuľky BIA dnes rizikom

NIS2 a DORA zmenili prístup ku kontinuite a súladu. Kontinuitu činností, obnovu po havárii, reakciu na incidenty, odolnosť dodávateľov a správu a riadenie nevnímajú ako oddelené dokumenty. Očakávajú, že budú fungovať ako jeden systém.

Pre subjekty podľa NIS2 vyžaduje Article 21 technické, prevádzkové a organizačné opatrenia na riadenie rizík pre sieťové a informačné systémy a na prevenciu alebo minimalizáciu dopadu incidentov na príjemcov služieb a iné služby. Minimálne opatrenia zahŕňajú analýzu rizík, riešenie incidentov, kontinuitu činností vrátane správy zálohovania, obnovu po havárii a krízové riadenie, bezpečnosť dodávateľského reťazca, riešenie zraniteľností, posúdenie účinnosti kontrol, školenie, kryptografiu, bezpečnosť ľudských zdrojov, riadenie prístupu, správu aktív, MFA a bezpečnú komunikáciu.

NIS2 Article 20 presúva túto tému do rokovacej miestnosti predstavenstva. Riadiace orgány musia schvaľovať opatrenia riadenia kybernetických rizík, dohliadať na ich implementáciu a môžu niesť zodpovednosť za porušenia. To znamená, že nepodložené štvorhodinové RTO nie je len technická nekonzistentnosť. Je to slabina v správe a riadení.

DORA sa uplatňuje od 17. januára 2025 a zavádza jednotný rámec EÚ pre riadenie rizík IKT, nahlasovanie incidentov, testovanie digitálnej prevádzkovej odolnosti, riadenie rizík tretích strán v oblasti IKT, zmluvné požiadavky a dohľad nad kritickými externými poskytovateľmi IKT. Pre finančné subjekty a pre poskytovateľov technológií, ktorí ich podporujú prostredníctvom zmlúv, DORA mení prevádzkovú odolnosť na štruktúrovanú požiadavku na dôkazy.

DORA Articles 5 and 6 vyžadujú správu a riadenie a zdokumentovaný rámec riadenia rizík IKT. Articles 7 to 14 pokrývajú spoľahlivé a odolné systémy IKT, identifikáciu aktív a závislostí, ochranu, detekciu, kontinuitu činností IKT, zálohovanie, rekonštrukciu, obnovu, poučenie sa z incidentov, povedomie, školenie a krízovú komunikáciu. Articles 24 to 26 vyžadujú testovanie digitálnej prevádzkovej odolnosti pre finančné subjekty, ktoré nie sú mikropodnikmi. Articles 28 to 30 formalizujú riziko tretích strán v oblasti IKT, registre zmlúv o službách IKT, stratégie ukončenia, úrovne služieb, práva na audit a požiadavky na mimoriadne situácie.

ISO/IEC 27001:2022 poskytuje oporu systému manažérstva. Jeho kapitoly vyžadujú, aby organizácia definovala kontext, zainteresované strany, zákonné a zmluvné povinnosti, rozsah, vedenie, politiku, roly, posúdenie rizík, ošetrenie rizík, vyhlásenie o uplatniteľnosti, prevádzkové plánovanie, hodnotenie výkonnosti a neustále zlepšovanie.

Chýbajúcim prepojením je často BIA. Bez nej plány kontinuity nie sú jednoznačne založené na riziku, ciele zálohovania nie sú schválené organizáciou, dodávatelia nie sú namapovaní na kritické služby a manažment nevie spoľahlivo preukázať, že rozhodnutia o odolnosti vychádzali z dopadu na podnikanie.

BIA ako riadiaca rovina dôkazov odolnosti

Obhájiteľná BIA odpovedá na sedem otázok, ktoré čoraz častejšie kladú audítori, regulátori, zákazníci a členovia predstavenstva:

1. Ktoré služby organizácie sú kritické?
2. Ktoré aktíva IKT, dátové úložiská, ľudia, dodávatelia a podporné služby podporujú každú službu?
3. Aký je prevádzkový, finančný, právny, zmluvný, zákaznícky, bezpečnostný a reputačný dopad narušenia v čase?
4. Aké je maximálne tolerovateľné trvanie výpadku (MTD)?
5. Aké sú schválené cieľové časy obnovy (RTO) a cieľové body obnovy (RPO)?
6. Umožňujú zálohovanie, redundancia, cloud, dodávatelia, personálne zabezpečenie a komunikačné opatrenia tieto ciele dosiahnuť?
7. Otestovala organizácia cestu obnovy a preskúmala výsledky?

Podniková Politika kontinuity činností a obnovy po havárii spoločnosti Clarysec P32 Politika kontinuity činností a obnovy po havárii stanovuje požiadavku jasne:

Analýza dopadov na podnikanie (BIA) sa musí vykonať najmenej raz ročne pre všetky kritické organizačné jednotky a musí sa preskúmať pri významných zmenách systémov, procesov alebo závislostí. Výstupy BIA musia definovať: 5.2.1. maximálne tolerovateľné trvanie výpadku (MTD) 5.2.2. cieľové časy obnovy (RTO) 5.2.3. cieľové body obnovy (RPO) 5.2.4. kritické závislosti (systémy, dodávatelia, personál)

Táto kapitola poskytuje audítorom praktický východiskový bod. Zároveň zabraňuje bežnému zlyhaniu, keď plán kontinuity činností, plán obnovy po havárii, harmonogram zálohovania, register dodávateľov a proces reakcie na incidenty používajú rozdielnu definíciu pojmu „kritické“.

Tá istá politika vyžaduje integrovaný prístup k riadeniu:

Organizácia musí udržiavať integrovaný systém riadenia kontinuity činností (BCMS) zosúladený s ISO 22301 a ISO/IEC 27001, ktorý zabezpečuje integráciu: 5.1.1. analýzy dopadov na podnikanie (BIA) 5.1.2. posúdenia bezpečnostných rizík pre hrozby kontinuity 5.1.3. plánov kontinuity činností (BCP) 5.1.4. plánov obnovy IKT po havárii (DRP) 5.1.5. programov testovania a cvičení 5.1.6. dokumentácie a neustáleho zlepšovania

Toto je rozdiel medzi súladom podľa kontrolného zoznamu a odolnosťou pripravenou na audit. BIA nie je jednorazový dokument. Stáva sa súčasťou dôkazového reťazca ISMS a BCMS.

Ako ISO/IEC 27001:2022 mení BIA na auditovateľné dôkazy

ISO/IEC 27001:2022 nevyžaduje, aby každá organizácia používala slovné spojenie „analýza dopadov na podnikanie“ v každej kapitole, ale jej požiadavky robia dôkazy BIA mimoriadne hodnotnými.

Kapitoly 4.1 až 4.4 vyžadujú, aby organizácia rozumela interným a externým otázkam, zainteresovaným stranám, zákonným a regulačným povinnostiam, zmluvným požiadavkám, rozhraniam, závislostiam a rozsahu ISMS. BIA je často najpraktickejším dôkazom týchto rozhraní a závislostí. Ukazuje, ktorá cloudová služba, spracovateľ platieb, poskytovateľ identít, telekomunikačný poskytovateľ, poskytovateľ riadených bezpečnostných služieb, dátové centrum alebo outsourcovaný tím podpory umožňuje kritickú službu.

Kapitoly 5.1 až 5.3 vyžadujú vedenie vrcholovým manažmentom, zabezpečenie zdrojov, komunikáciu, pridelenie rolí a reportovanie. BIA poskytuje vedeniu vecný základ pre investície do kontinuity. Bez nej sú RTO a RPO technickými želaniami, nie schválenými požiadavkami organizácie.

Kapitoly 6.1.1 až 6.1.3 vyžadujú opakovateľné posúdenie a ošetrenie rizík informačnej bezpečnosti. Organizácia musí identifikovať riziká pre dôvernosť, integritu a dostupnosť, analyzovať následky a pravdepodobnosť, určiť úrovne rizika, prioritizovať ošetrenie, vybrať kontroly, porovnať vybrané kontroly s Annex A, vypracovať vyhlásenie o uplatniteľnosti, vytvoriť plán ošetrenia rizík a získať schválenie vlastníka rizika. BIA posilňuje stránku „následkov“ v posúdení rizík. Vysvetľuje, prečo je dvojhodinový výpadok jedného systému tolerovateľný, zatiaľ čo dvojhodinový výpadok iného systému spôsobuje ujmu zákazníkom, regulačnú expozíciu, porušenie zmluvy alebo závažný výpadok výnosov.

Annex A poskytuje katalóg kontrol. Pre BIA a kontinuitu sú najrelevantnejšie tieto kontroly ISO/IEC 27001:2022 Annex A:

V publikácii Zenith Controls: Sprievodca krížovým súladom Zenith Controls Clarysec profiluje kontrolu ISO/IEC 27002:2022 5.30, pripravenosť IKT na kontinuitu činností, ako nápravnú kontrolu zameranú na dostupnosť, mapovanú na koncept kybernetickej bezpečnosti Respond, prevádzkovú spôsobilosť kontinuity a bezpečnostnú doménu odolnosti. Kontrola 5.29, informačná bezpečnosť počas narušenia, je profilovaná ako preventívna a nápravná, chrániaca dôvernosť, integritu a dostupnosť. Kontrola 8.13, zálohovanie informácií, je profilovaná ako nápravná a podporuje integritu a dostupnosť prostredníctvom obnovy.

Na tomto rozlíšení záleží. BIA sa nemá pýtať iba: „Vieme obnoviť?“ Musí sa pýtať aj: „Vieme zostať bezpeční počas narušenia?“ Počas ransomvérového incidentu, výpadku cloudu, zlyhania dodávateľa alebo incidentu v dátovom centre organizácia stále potrebuje riadenie prístupu, logovanie, monitorovanie, uchovanie dôkazov, bezpečnú komunikáciu a opatrenia na ochranu súkromia.

Praktický model dôkazov BIA

Silná BIA prepája jazyk organizácie s technickými dôkazmi. Clarysec zvyčajne štruktúruje model dôkazov do piatich vrstiev.

Tento model dôkazov funguje, pretože sleduje spôsob uvažovania audítorov. Najprv sa pýtajú, čo je kritické. Potom sa pýtajú, čo to podporuje. Následne sa pýtajú, kto schválil cieľ obnovy. Potom preverujú, či technické a dodávateľské opatrenia dokážu cieľ splniť. Napokon sa pýtajú, či organizácia schopnosť otestovala a zlepšila.

NIST CSF 2.0 je užitočný ako komunikačná vrstva. Jeho metóda profilov CSF povzbudzuje organizácie, aby definovali rozsah, zhromaždili vstupy, ako sú politiky, priority podnikových rizík, registre BIA, požiadavky kybernetickej bezpečnosti, normy, postupy, ochranné opatrenia a pracovné roly, vytvorili aktuálne a cieľové profily, analyzovali medzery, pripravili prioritizovaný akčný plán, implementovali ho a aktualizovali profil. To takmer presne vystihuje, ako má BIA napájať cestovnú mapu krížového súladu.

Týždňové cvičenie BIA, ktoré vytvorí skutočné dôkazy

Predpokladajme, že poskytovateľ SaaS podporuje zákazníkov z finančných služieb. Jeho platforma podporuje onboarding klientov, overovanie dokumentov a zákaznícke notifikácie. Sám nie je bankou, ale jeho zákazníci posielajú zmluvné požiadavky vyvolané DORA a dodávateľské dotazníky NIS2.

Cielené týždňové cvičenie môže rýchlo vytvoriť použiteľné dôkazy.

Deň 1: Identifikujte kritické služby a časové okná dopadu

Začnite službami, nie servermi. Zapojte vlastníkov biznisu, IT, bezpečnosť, právne oddelenie, podporu, ochranu súkromia a riadenie dodávateľov.

Tento rámec je dôležitý. Regulátori a zákazníci rozumejú službám a funkciám. Aplikácie sú dôležité preto, že tieto služby podporujú.

Deň 2: Zmapujte závislosti

Pre každú službu zmapujte aplikácie, databázy, infraštruktúru, cloudové služby, poskytovateľov identít, monitorovanie, nástroje zálohovania, ľudí, dodávateľov a podporné služby.

Tu BIA začína prinášať hodnotu. Odhaľuje neviditeľnú cestu obnovy vrátane závislostí, ktoré sa v technickom DR pláne často prehliadnu.

Deň 3: Schváľte MTD, RTO a RPO

Vlastník biznisu navrhne MTD. IT a bezpečnosť overia, či sú navrhované RTO a RPO technicky dosiahnuteľné. Manažment schváli konečné ciele.

Pre menšie organizácie poskytuje Politika kontinuity činností a obnovy po havárii - MSP spoločnosti Clarysec P32S Politika kontinuity činností a obnovy po havárii - SME rovnakú disciplínu jednoduchším jazykom. Vyžaduje plány BCP/DR, ktoré stanovujú prístup k obnoveniu základných funkcií:

Generálny manažér (GM) musí schváliť a udržiavať plány kontinuity činností a obnovy po havárii (BCP/DRP), ktoré jasne stanovujú prístup organizácie k obnoveniu základných funkcií.

Vyžaduje tiež, aby plán obsahoval:

prioritizované služby a systémy (kritické funkcie organizácie)

A:

cieľové časy obnovy (RTO) a cieľové body obnovy (RPO) pre každý systém

Kľúčom nie je nadmerná dokumentácia. Kľúčom je sledovateľnosť, schválenie a dôkaz, že ciele obnovy vychádzajú zo skutočného dopadu na podnikanie.

Deň 4: Zosúlaďte zálohovanie s dopadom na podnikanie

Mnohé organizácie tu zlyhávajú. BIA môže stanoviť štvorhodinové RPO, zatiaľ čo zálohy bežia každých 24 hodín. Alebo nástroj zálohovania chráni produkčné databázy, ale nie konfiguráciu, tajomstvá, repozitáre infraštruktúry ako kódu, objektové úložisko, záznamy DNS, nastavenia identít alebo konfiguráciu API gateway.

Politika zálohovania a obnovy spoločnosti Clarysec P15 Politika zálohovania a obnovy vyžaduje hlavný harmonogram zálohovania naviazaný na výstupy BIA:

Musí sa udržiavať a každoročne preskúmať hlavný harmonogram zálohovania. Musí špecifikovať: 5.1.1 frekvenciu zálohovania (napríklad denné prírastkové zálohy a týždenné úplné zálohy) 5.1.2 lehoty uchovávania podľa systému alebo typu údajov 5.1.3 požiadavky na šifrovanie a údaje o mieste uloženia 5.1.4 ciele RTO/RPO prepojené s výstupmi posúdenia dopadu na podnikanie

Táto kapitola má vysokú auditnú hodnotu. Núti návrh zálohovania odrážať dopad na podnikanie, nie pohodlie úložiska.

Deň 5: Otestujte jednu cestu obnovy a otvorte nápravné opatrenia

Netestujte všetko naraz. Vyberte jednu kritickú službu a vykonajte cielený test obnovy. Obnovte databázu. Znovu vytvorte konfiguráciu aplikácie. Overte autentifikáciu. Potvrďte dostupnosť logov. Skontrolujte schopnosť zákazníckych notifikácií. Zaznamenajte čas potrebný na obnovu, stratu údajov, chyby, rozhodnutia a nápravné opatrenia.

V publikácii Zenith Blueprint: 30-kroková cestovná mapa audítora Zenith Blueprint sa fáza Controls in Action, krok 23, venuje organizačným opatreniam vrátane pripravenosti IKT na kontinuitu činností. Kladie otázku, ktorú by si mal položiť každý auditný tím:

Dokážu vaše systémy podporiť ciele kontinuity činností, keď začnú problémy s elektrickou energiou, vypadnú siete alebo nastane havária?

Ten istý krok poskytuje praktické usmernenie:

Overte, že cieľové časy obnovy (RTO) a cieľové body obnovy (RPO) pre kritické systémy sú zosúladené s očakávaniami kontinuity činností (5.30). Vykonajte aspoň jeden technický test obnovy alebo simuláciu prepnutia na záložné prostredie a zdokumentujte výsledky.

To je rozdiel medzi tým, že organizácia má BIA, a tým, že má obhájiteľné dôkazy BIA. Cieľ nie je iba zdokumentovaný. Je otestovaný.

Mapovanie dôkazov BIA na NIS2, DORA, GDPR, NIST a COBIT 2019

Dobre vybudovaná BIA sa stáva aktívom krížového súladu. Jeden súbor dôkazov dokáže odpovedať na mnoho otázok.

GDPR sa v diskusiách o BIA často prehliada. GDPR Article 5 však vyžaduje, aby sa osobné údaje spracúvali s integritou a dôvernosťou vrátane ochrany proti náhodnej strate, zničeniu alebo poškodeniu prostredníctvom primeraných technických alebo organizačných opatrení. Zodpovednosť vyžaduje, aby prevádzkovateľ preukázal súlad. Ak platformu s osobnými údajmi nemožno obnoviť v schválenom a otestovanom čase, riziko ochrany súkromia ovplyvňuje dostupnosť, integritu, posúdenie porušenia ochrany údajov a dôveru zákazníkov.

Nahlasovanie incidentov podľa NIS2 pridáva ďalší rozmer. Article 23 vyžaduje, aby sa významné incidenty oznamovali bez zbytočného odkladu vrátane včasného varovania do 24 hodín, oznámenia incidentu do 72 hodín a záverečnej správy do jedného mesiaca. BIA pomáha klasifikovať závažnosť, pretože definuje dotknuté služby, príjemcov služieb, prevádzkové narušenie a potenciálny cezhraničný dopad.

Klasifikácia incidentov podľa DORA tiež zohľadňuje dotknutých klientov alebo transakcie, trvanie, geografické rozšírenie, straty údajov, kritickosť dotknutých služieb a ekonomický dopad. Toto sú polia BIA. Ak je BIA slabá, klasifikácia incidentov sa stáva subjektívnou práve v najhoršom možnom okamihu.

Kontinuita dodávateľov je miesto, kde sa BIA stretáva so zmluvnou realitou

Pre NIS2 a DORA už kontinuita dodávateľov nie je voliteľná. NIS2 Article 21 zahŕňa bezpečnosť dodávateľského reťazca a vyžaduje pozornosť voči zraniteľnostiam dodávateľov, kvalite a odolnosti produktov, praktikám kybernetickej bezpečnosti dodávateľov a postupom bezpečného vývoja. DORA vyžaduje, aby sa riziko tretích strán v oblasti IKT riadilo v rámci rámca riadenia rizík IKT vrátane registrov zmlúv o službách IKT, due diligence, rizika koncentrácie, stratégií ukončenia, práv na audit a prístup, podpory pri incidentoch, úrovní služieb a požiadaviek na mimoriadne situácie.

Podniková Politika kontinuity činností a obnovy po havárii vyžaduje:

Závislosti od tretích strán a dodávateľského reťazca 6.5.1. Zmluvy s kritickými dodávateľmi musia obsahovať povinnosti v oblasti kontinuity a záväzky týkajúce sa časov obnovy. 6.5.2. Kľúčoví poskytovatelia služieb musia na požiadanie preukázať pravidelné testovanie kontinuity a účasť na incidentných cvičeniach.

Verzia pre MSP vyžaduje aj:

kontaktné miesta dodávateľov pre kontinuitu

Toto malé pole môže byť pri skutočnom incidente rozhodujúce. Ak váš plán obnovy uvádza „kontaktovať podporu cloudového poskytovateľa“, ale nikto nepozná eskalačnú cestu, referenciu zmluvy, proces závažnosti alebo kontakt mimo pracovného času, RTO je fikcia.

Táto tabuľka nenahrádza riadenie dodávateľského rizika. Robí dodávateľské riziko prevádzkovým.

Ako budú audítori testovať vašu BIA

Audítor ISO/IEC 27001:2022 zvyčajne začne rozsahom, kontextom, posúdením rizík, ošetrením rizík, vyhlásením o uplatniteľnosti, kontrolami Annex A, zdokumentovanými informáciami, prevádzkovým plánovaním, hodnotením výkonnosti a zlepšovaním. Porovná BIA s posúdením rizík a SoA. Ak sú zahrnuté A.5.30, A.5.29 alebo A.8.13, bude požadovať dôkazy o implementácii a testovaní.

Preskúmavateľ podľa DORA sa zameria na kritické alebo dôležité funkcie, aktíva IKT, závislosti od tretích strán v oblasti IKT, testovanie odolnosti, klasifikáciu incidentov, zmluvné požiadavky, stratégie ukončenia a dohľad riadiaceho orgánu. Bude očakávať, že BIA je zosúladená s rámcom riadenia rizík IKT, stratégiou digitálnej prevádzkovej odolnosti, plánmi kontinuity činností IKT, plánmi reakcie a obnovy a programom testovania.

Dohľadový orgán podľa NIS2 sa bude pýtať na opatrenia kontinuity činností, správu zálohovania, obnovu po havárii, krízové riadenie, bezpečnosť dodávateľského reťazca, schválenie správy a riadenia a schopnosť nahlasovania významných incidentov. BIA má preukázať, že tieto opatrenia vychádzajú z dopadu na službu a schválených priorít.

Posudzovateľ NIST CSF 2.0 sa bude pýtať, ako BIA informuje aktuálny profil, cieľový profil, analýzu medzier a akčný plán. Bude skúmať výstupy Govern pre právne, regulačné, zmluvné, rizikové, rolové, politické, dohľadové a dodávateľské rizikové rozhodnutia. Preskúma aj výstupy Identify, Protect, Detect, Respond a Recover.

Audítor COBIT 2019 alebo audítor v štýle ISACA sa zvyčajne zameria na správu a riadenie. Kto vlastní službu? Kto akceptoval riziko? Sú ciele zosúladené s cieľmi organizácie? Sú dodávatelia monitorovaní? Sú prínosy, riziká a zdroje vyvážené? Sledujú sa nápravné opatrenia až do uzavretia?

Politika monitorovania auditov a súladu spoločnosti Clarysec Politika monitorovania auditov a súladu robí z BIA súčasť cyklu plánovania auditov:

Plán auditov založený na riziku sa musí vypracovať a schváliť každoročne, pričom sa zohľadnia: 5.2.1 výsledky najnovších posúdení rizík a analýzy dopadov na podnikanie (BIA) 5.2.2 predchádzajúce auditné zistenia a stav nápravných opatrení 5.2.3 zmeny procesov, IT infraštruktúry, systémov alebo dodávateľov 5.2.4 externé povinnosti, ako napríklad DORA Article 25 alebo zákaznícke zmluvy

Toto je krok zrelosti, ktorý mnohé organizácie vynechávajú. BIA nemá stáť mimo uistenia. Má riadiť plán auditov.

Bežné zlyhania BIA zistené v reálnych posúdeniach

Rovnaké slabiny sa objavujú opakovane.

Po prvé, BIA uvádza aplikácie, nie služby. Zákazníkov a regulátorov zaujíma narušenie služby. Aplikácie sú dôležité preto, že tieto služby podporujú.

Po druhé, ciele RTO a RPO sa kopírujú zo šablón. Štvorhodinové RTO môže znieť rozumne, kým test obnovy neukáže, že obnovenie integrácie identít, konfigurácie, údajov, validácia integrity a opätovné zapnutie monitorovania trvá deväť hodín.

Po tretie, zálohy nie sú prepojené s dopadom na podnikanie. Frekvencia, uchovávanie, šifrovanie, miesto uloženia, priorita obnovy a testovanie musia odrážať schválené ciele obnovy.

Po štvrté, dodávatelia sa vnímajú ako položky v dotazníku, nie ako závislosti obnovy. Záväzky dodávateľov v oblasti kontinuity, eskalačné kontakty, dôkazy obnovy a účasť na incidentných cvičeniach majú byť viazané na kritické služby.

Po piate, chýba schválenie manažmentom. Podľa NIS2 a DORA je zodpovednosť manažmentu výslovná. Podľa ISO/IEC 27001:2022 sú vedenie, roly, schválenie vlastníkom rizika a reportovanie výkonnosti kľúčové požiadavky.

Po šieste, testovanie je príliš úzke. Obnovenie jedného súboru je užitočné, ale nepreukazuje obnovu služby. Cesta obnovy kritickej služby môže zahŕňať DNS, identity, tajomstvá, infraštruktúru ako kód, API gateway, monitorovanie, logovanie, eskaláciu dodávateľa, komunikáciu so zákazníkmi a preskúmanie ochrany súkromia.

Zenith Blueprint vo fáze Controls in Action, krok 19, zachytáva auditné očakávanie pri zálohách:

Testujete svoje zálohy?

Odpoveď musí znieť „áno, s dôkazmi“ a tieto dôkazy musia byť spätne prepojené s BIA.

Balík dôkazov BIA pripravený na audit

Praktický program BIA má vytvoriť stručný balík dôkazov, ktorý možno použiť na audity, due diligence zákazníkov, reportovanie predstavenstvu a zlepšovanie odolnosti.

Tento balík rozpráva súvislý príbeh. Zároveň robí odolnosť merateľnou.

Ďalší krok: premeňte svoju BIA na dôkazy súladu

Maria nepotrebuje väčší tabuľkový prehľad. Potrebuje živý dôkazový reťazec.

Začnite jednou kritickou službou. Zmapujte jej aktíva IKT, údaje, ľudí, dodávateľov a podporné služby. Schváľte MTD, RTO a RPO. Zosúlaďte harmonogram zálohovania. Skontrolujte záväzky dodávateľov v oblasti obnovy. Vykonajte jeden test obnovy. Zaznamenajte medzery. Aktualizujte plán ošetrenia rizík. Predložte výsledok manažmentu.

Potom postup zopakujte.

Clarysec vám môže pomôcť tento proces urýchliť použitím dokumentov Politika kontinuity činností a obnovy po havárii, Politika kontinuity činností a obnovy po havárii - MSP, Politika zálohovania a obnovy, Politika monitorovania auditov a súladu, Zenith Blueprint a Zenith Controls.

Vaša BIA nemá byť dokument odložený v knižnici a vytvorený pre audit. Má byť prevádzkovým dôkazom, že vaše najdôležitejšie služby dokážu prežiť narušenie, splniť očakávania zákazníkov a regulátorov a obnoviť sa v limitoch, ktoré vaše vedenie skutočne schválilo.

Ak sa vaša organizácia pripravuje na dozorný audit ISO/IEC 27001:2022, zákaznícke uistenie podľa NIS2, preskúmania tretích strán v oblasti IKT podľa DORA alebo reportovanie odolnosti na úrovni predstavenstva, začnite tým, že urobíte BIA obhájiteľnou. Stiahnite si politiky kontinuity a auditu od Clarysec, preskúmajte implementačnú cestovnú mapu Zenith alebo požiadajte o posúdenie dôkazov odolnosti, aby ste rozptýlené kontroly premenili na jeden príbeh pripravený na audit.