Analýza dopadů na podnikání pro ISO 27001, NIS2 a DORA

Auditní otázka, která odhalí skutečnou mezeru v kontinuitě

Je pondělní ráno a Maria, CISO rychle rostoucí fintechové společnosti, se připravuje na jednání výboru správní rady pro rizika. Předmět je stručný: „Připravenost na DORA a NIS2: přezkum BIA.“

Její tým připravil to, co většina vrcholového vedení očekává. Existuje certifikovaný ISMS podle ISO/IEC 27001:2022, playbooky reakce na incidenty, snímky obrazovek ze zálohování, zprávy o zranitelnostech, dodavatelské dotazníky, diagramy cloudové architektury a aktualizovaný registr rizik. Podnikoví zákazníci zasílají dotazníky k NIS2. Klienti z finančního sektoru vkládají do smluv ustanovení DORA. Dozorový audit ISO/IEC 27001:2022 je vzdálený jen měsíc.

Poté externí auditor položí otázku, která změní atmosféru v místnosti:

„Pokud je vaše platforma pro onboarding zákazníků nedostupná 18 hodin, které regulované služby jsou dotčeny, kteří dodavatelé jsou zapojeni, jaká je schválená priorita obnovy a kde jsou důkazy, že organizace akceptovala RTO a RPO?“

V místnosti nastane ticho.

Harmonogram záloh říká jedno. Plán obnovy po havárii říká něco jiného. Smlouva s dodavatelem obsahuje SLA dostupnosti, ale žádné důkazy z testů obnovy. Registr rizik zmiňuje dostupnost, ale nevysvětluje, proč musí být jedna služba obnovena rychleji než jiná. Vedení schválilo bezpečnostní politiku, nikoli však obchodní dopad nedostupnosti.

To je problém analýzy dopadů na podnikání v roce 2026.

Business Impact Analysis, tedy BIA, již není tabulka přiložená k plánu kontinuity. Je to důkazní most mezi obchodními službami, ICT aktivy, dodavateli, prioritami obnovy, RTO/RPO, prahovými hodnotami incidentů, testováním odolnosti a odpovědností řídicího orgánu. Pro organizace, které slaďují ISO/IEC 27001:2022 s kontinuitou podle NIS2 a odolností ICT podle DORA, je BIA místem, kde se soulad stává provozní realitou.

Nejvyspělejší organizace již mají mnoho správných opatření. Jejich slabinou je dohledatelnost. BIA mění roztříštěné důkazy v auditně připravený příběh: na čem záleží, proč na tom záleží, jak rychle se to musí obnovit, které závislosti to podporují, co bylo testováno, co selhalo, co bylo zlepšeno a kdo schválil zbytkové riziko.

Proč jsou staré tabulky BIA dnes rizikem

NIS2 a DORA změnily tón požadavků na soulad v oblasti kontinuity. Nepovažují kontinuitu činností, obnovu po havárii, reakci na incidenty, odolnost dodavatelů a správu a řízení za oddělené dokumenty. Očekávají, že budou fungovat jako jeden systém.

U subjektů podle NIS2 vyžaduje Article 21 technická, provozní a organizační opatření k řízení rizik pro sítě a informační systémy a k prevenci nebo minimalizaci dopadu incidentů na příjemce služeb a další služby. Mezi minimální opatření patří analýza rizik, zvládání incidentů, kontinuita činností včetně správy zálohování, obnova po havárii a krizové řízení, zabezpečení dodavatelského řetězce, zvládání zranitelností, posuzování účinnosti kontrol, školení, kryptografie, bezpečnost lidských zdrojů, řízení přístupu, správa aktiv, MFA a bezpečná komunikace.

NIS2 Article 20 přesouvá tuto otázku do jednací místnosti řídicího orgánu. Řídicí orgány musí schvalovat opatření k řízení rizik kybernetické bezpečnosti, dohlížet na jejich zavádění a mohou nést odpovědnost za porušení. Nepodložené čtyřhodinové RTO proto není jen technická nekonzistence. Je to slabina správy a řízení.

DORA se použije od 17. ledna 2025 a vytváří jednotný rámec EU pro řízení rizik v oblasti ICT, hlášení incidentů, testování digitální provozní odolnosti, řízení rizik třetích stran v oblasti ICT, smluvní požadavky a dohled nad kritickými poskytovateli ICT služeb z řad třetích stran. Pro finanční subjekty a pro technologické poskytovatele, kteří je smluvně podporují, mění DORA provozní odolnost na strukturovaný požadavek na důkazy.

DORA Articles 5 a 6 vyžadují správu a řízení a zdokumentovaný rámec řízení rizik ICT. Articles 7 až 14 se týkají spolehlivých a odolných ICT systémů, identifikace aktiv a závislostí, ochrany, detekce, kontinuity činností v ICT, zálohování, obnovení, obnovy, poučení po incidentu, povědomí, školení a krizové komunikace. Articles 24 až 26 vyžadují testování digitální provozní odolnosti u finančních subjektů, které nejsou mikropodniky. Articles 28 až 30 formalizují riziko třetích stran v ICT, registry smluv o ICT službách, strategie ukončení, úrovně služeb, práva na audit a požadavky na mimořádné situace.

ISO/IEC 27001:2022 poskytuje páteř systému řízení. Její kapitoly vyžadují, aby organizace definovala kontext, zainteresované strany, právní a smluvní povinnosti, rozsah, vedení, politiku, role, posouzení rizik, ošetření rizik, prohlášení o použitelnosti, provozní plánování, hodnocení výkonnosti a neustálé zlepšování.

Chybějícím článkem je často BIA. Bez ní nejsou plány kontinuity jasně založené na rizicích, cíle zálohování nejsou schváleny z obchodního hlediska, dodavatelé nejsou mapováni ke kritickým službám a vedení nemůže spolehlivě doložit, že rozhodnutí o odolnosti vycházela z dopadu na podnikání.

BIA jako řídicí vrstva pro důkazy o odolnosti

Obhajitelná BIA odpovídá na sedm otázek, které auditoři, regulační orgány, zákazníci a řídicí orgány kladou stále častěji:

1. Které obchodní služby jsou kritické?
2. Která ICT aktiva, datová úložiště, osoby, dodavatelé a služby technické infrastruktury podporují jednotlivé služby?
3. Jaký je provozní, finanční, právní, smluvní, zákaznický, bezpečnostní a reputační dopad narušení v čase?
4. Jaká je maximální tolerovatelná doba výpadku, tedy MTD?
5. Jaké jsou schválené cílové doby obnovy, tedy RTO, a cílové body obnovy, tedy RPO?
6. Umožňují zálohování, redundance, cloud, dodavatelé, personální zajištění a komunikace dosažení těchto cílů?
7. Otestovala organizace cestu obnovy a přezkoumala výsledky?

Podniková Politika kontinuity činností a obnovy po havárii společnosti Clarysec P32 Business Continuity Policy and Disaster Recovery Policy stanoví požadavek jasně:

Analýza dopadů na podnikání (BIA) musí být provedena alespoň jednou ročně pro všechny kritické podnikové útvary a přezkoumána při významných změnách systémů, procesů nebo závislostí. Výstupy BIA musí definovat: 5.2.1. Maximální tolerovatelnou dobu výpadku (MTD) 5.2.2. Cílové doby obnovy (RTO) 5.2.3. Cílové body obnovy (RPO) 5.2.4. Kritické závislosti (systémy, dodavatelé, personál)

Toto ustanovení dává auditorům praktický výchozí bod. Zároveň brání častému selhání, kdy plán kontinuity činností, plán obnovy po havárii, harmonogram záloh, registr dodavatelů a proces reakce na incidenty používají každý jinou definici „kritičnosti“.

Stejná politika vyžaduje integrovaný přístup k řízení:

Organizace musí udržovat integrovaný systém řízení kontinuity činností (BCMS) sladěný s ISO 22301 a ISO/IEC 27001, který zajišťuje integraci těchto prvků: 5.1.1. Analýza dopadů na podnikání (BIA) 5.1.2. Posouzení bezpečnostních rizik hrozeb pro kontinuitu 5.1.3. Plány kontinuity činností (BCP) 5.1.4. Plány obnovy ICT po havárii (DRP) 5.1.5. Programy testování a cvičení 5.1.6. Dokumentace a neustálé zlepšování

To je rozdíl mezi kontrolním seznamem souladu a odolností připravenou na audit. BIA není jednorázový dokument. Stává se součástí důkazního řetězce ISMS a BCMS.

Jak ISO/IEC 27001:2022 mění BIA v auditovatelné důkazy

ISO/IEC 27001:2022 nevyžaduje, aby každá organizace používala slovní spojení „Business Impact Analysis“ v každé kapitole, ale její požadavky činí důkazy BIA mimořádně cennými.

Kapitoly 4.1 až 4.4 vyžadují, aby organizace porozuměla interním a externím otázkám, zainteresovaným stranám, právním a regulatorním povinnostem, smluvním požadavkům, rozhraním, závislostem a rozsahu ISMS. BIA je často nejpraktičtějším důkazem pro tato rozhraní a závislosti. Ukazuje, která cloudová služba, zpracovatel plateb, poskytovatel identit, telekomunikační poskytovatel, poskytovatel řízených bezpečnostních služeb, datové centrum nebo outsourcovaný tým podpory umožňuje kritickou službu.

Kapitoly 5.1 až 5.3 vyžadují vedení ze strany vrcholového vedení, zajištění zdrojů, komunikaci, přiřazení rolí a reporting. BIA dává vedení obchodní základ pro investice do kontinuity. Bez ní jsou cíle RTO a RPO technická přání, nikoli schválené obchodní požadavky.

Kapitoly 6.1.1 až 6.1.3 vyžadují opakovatelné posouzení rizik bezpečnosti informací a ošetření rizik. Organizace musí identifikovat rizika pro důvěrnost, integritu a dostupnost, analyzovat dopady a pravděpodobnost, stanovit úrovně rizika, prioritizovat ošetření, vybrat opatření, porovnat vybraná opatření s přílohou A, vytvořit prohlášení o použitelnosti, připravit plán ošetření rizik a získat schválení vlastníka rizika. BIA posiluje stránku „dopadů“ v posouzení rizik. Vysvětluje, proč je dvouhodinový výpadek jednoho systému tolerovatelný, zatímco dvouhodinový výpadek jiného systému způsobuje újmu zákazníkům, regulatorní expozici, porušení smlouvy nebo závažný dopad na výnosy.

Příloha A poskytuje katalog opatření. Pro BIA a kontinuitu patří mezi nejrelevantnější opatření přílohy A normy ISO/IEC 27001:2022 tato:

V Zenith Controls: The Cross-Compliance Guide Zenith Controls Clarysec profiluje opatření ISO/IEC 27002:2022 5.30, připravenost ICT na kontinuitu činností, jako nápravné opatření zaměřené na dostupnost, mapované na koncept kybernetické bezpečnosti Respond, provozní schopnost kontinuity a bezpečnostní doménu odolnosti. Opatření 5.29, bezpečnost informací při narušení, je profilováno jako preventivní a nápravné, chránící důvěrnost, integritu a dostupnost. Opatření 8.13, zálohování informací, je profilováno jako nápravné a podporuje integritu a dostupnost prostřednictvím obnovy.

Na tomto rozlišení záleží. BIA se nesmí ptát pouze: „Umíme obnovit?“ Musí se ptát také: „Umíme zůstat bezpeční i při narušení?“ Během ransomwarové události, výpadku cloudu, selhání dodavatele nebo incidentu datového centra organizace stále potřebuje řízení přístupu, protokolování, monitorování, uchování důkazů, bezpečnou komunikaci a ochranná opatření v oblasti soukromí.

Praktický důkazní model BIA

Silná BIA propojuje obchodní jazyk s technickým doložením. Clarysec obvykle strukturuje důkazní model do pěti vrstev.

Tento důkazní model funguje, protože odpovídá způsobu uvažování auditorů. Nejprve se ptají, co je kritické. Poté se ptají, co to podporuje. Následně se ptají, kdo schválil cíl obnovy. Poté se ptají, zda technická a dodavatelská opatření mohou cíl splnit. Nakonec se ptají, zda organizace schopnost otestovala a zlepšila.

NIST CSF 2.0 je užitečný jako komunikační vrstva. Metoda CSF Profiles podporuje organizace v definování rozsahu, shromažďování vstupů, jako jsou politiky, priority podnikových rizik, registry BIA, požadavky na kybernetickou bezpečnost, normy, postupy, ochranná opatření a pracovní role, vytváření současných a cílových profilů, analýze mezer, vytvoření prioritizovaného akčního plánu, implementaci tohoto plánu a aktualizaci profilu. To téměř přesně odpovídá tomu, jak má BIA napájet plán napříč rámci souladu.

Týdenní cvičení BIA, které vytváří skutečné důkazy

Předpokládejme, že poskytovatel SaaS podporuje zákazníky z oblasti finančních služeb. Jeho platforma podporuje onboarding klientů, ověření dokumentů a zákaznická oznámení. Sám není bankou, ale jeho zákazníci zasílají smluvní požadavky odvozené od DORA a dodavatelské dotazníky NIS2.

Cílené týdenní cvičení může rychle vytvořit použitelné důkazy.

Den 1: Identifikujte kritické služby a časová okna dopadu

Začněte službami, nikoli servery. Zapojte vlastníky podnikových procesů, IT, bezpečnost, právní oddělení, podporu, ochranu soukromí a řízení dodavatelů.

Tento rámec je důležitý. Regulační orgány a zákazníci rozpoznávají služby a funkce. Na aplikacích záleží proto, že tyto služby podporují.

Den 2: Mapujte závislosti

U každé služby zmapujte aplikace, databáze, infrastrukturu, cloudové služby, poskytovatele identit, monitorování, zálohovací nástroje, osoby, dodavatele a podpůrné služby technické infrastruktury.

Zde začíná BIA vytvářet hodnotu. Odhaluje neviditelnou cestu obnovy včetně závislostí, které se v technickém plánu obnovy po havárii často přehlížejí.

Den 3: Schvalte MTD, RTO a RPO

Vlastník podnikových procesů navrhne MTD. IT a bezpečnost ověří, zda jsou navržené RTO a RPO technicky dosažitelné. Vedení schválí konečné cíle.

Pro menší organizace poskytuje Business Continuity Policy and Disaster Recovery Policy - SME společnosti Clarysec P32S Business Continuity Policy and Disaster Recovery Policy - SME stejnou disciplínu jednodušším jazykem. Vyžaduje plány BCP/DR, které stanovují přístup k obnovení nezbytných funkcí:

Generální ředitel (GM) musí schválit a udržovat plány kontinuity činností a obnovy po havárii (BCP/DRP), které jasně stanovují přístup organizace k obnovení nezbytných funkcí.

Vyžaduje také, aby plán obsahoval:

prioritizované služby a systémy (kritické podnikové funkce)

A dále:

cílové doby obnovy (RTO) a cílové body obnovy (RPO) pro každý systém

Klíčem není nadměrná dokumentace. Klíčem je dohledatelnost, schválení a důkazy, že cíle obnovy vycházejí ze skutečného dopadu na podnikání.

Den 4: Slaďte zálohování s dopadem na podnikání

Mnoho organizací zde selhává. BIA může stanovit čtyřhodinové RPO, zatímco zálohy běží každých 24 hodin. Nebo zálohovací nástroj chrání produkční databáze, ale nikoli konfiguraci, tajemství, repozitáře infrastruktury jako kódu, objektové úložiště, DNS záznamy, nastavení identit nebo konfiguraci API brány.

Politika zálohování a obnovy společnosti Clarysec P15 Backup and Restore Policy vyžaduje hlavní harmonogram zálohování navázaný na výsledky BIA:

Hlavní harmonogram zálohování musí být udržován a každoročně přezkoumán. Musí uvádět: 5.1.1 frekvenci zálohování (například denní přírůstkové zálohy a týdenní plné zálohy) 5.1.2 doby uchovávání podle systému nebo typu dat 5.1.3 požadavky na šifrování a podrobnosti o umístění úložiště 5.1.4 cíle RTO/RPO navázané na výsledky posouzení dopadů na podnikání

Toto ustanovení je pro audit mimořádně cenné. Nutí návrh zálohování odrážet dopad na podnikání, nikoli pohodlí úložiště.

Den 5: Otestujte jednu cestu obnovy a otevřete nápravná opatření

Netestujte vše najednou. Vyberte jednu kritickou službu a proveďte cílený test obnovy. Obnovte databázi. Znovu sestavte konfiguraci aplikace. Ověřte autentizaci. Potvrďte dostupnost logů. Zkontrolujte schopnost zákaznických oznámení. Zaznamenejte potřebný čas, ztrátu dat, vady, rozhodnutí a nápravná opatření.

V Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint řeší fáze Controls in Action, Step 23, organizační opatření včetně připravenosti ICT na kontinuitu činností. Klade otázku, kterou by si měl položit každý auditní tým:

Dokážou vaše systémy podpořit vaše cíle kontinuity činností, když kolísá napájení, když vypadnou sítě nebo když udeří havárie?

Stejný krok dává praktický pokyn:

Ověřte, že cílové doby obnovy (RTO) a cílové body obnovy (RPO) pro kritické systémy odpovídají očekáváním kontinuity činností (5.30). Proveďte alespoň jeden technický test obnovy nebo simulaci přepnutí na záložní řešení a zdokumentujte výsledky.

To je rozdíl mezi tím, že organizace BIA má, a tím, že má obhajitelné důkazy BIA. Cíl není jen zdokumentován. Je otestován.

Mapování důkazů BIA na NIS2, DORA, GDPR, NIST a COBIT 2019

Dobře vytvořená BIA se stává aktivem napříč rámci souladu. Jeden soubor důkazů může odpovědět na mnoho otázek.

GDPR se v diskusích o BIA často přehlíží. GDPR Article 5 však vyžaduje, aby osobní údaje byly zpracovávány s integritou a důvěrností, včetně ochrany před náhodnou ztrátou, zničením nebo poškozením pomocí vhodných technických nebo organizačních opatření. Odpovědnost vyžaduje, aby správce doložil soulad. Pokud platformu s osobními údaji nelze obnovit ve schváleném a otestovaném časovém rámci, riziko pro soukromí ovlivňuje dostupnost, integritu, posouzení porušení zabezpečení a důvěru zákazníků.

Hlášení incidentů podle NIS2 přidává další rozměr. Article 23 vyžaduje, aby významné incidenty byly oznámeny bez zbytečného odkladu, včetně včasného varování do 24 hodin, oznámení incidentu do 72 hodin a závěrečné zprávy do jednoho měsíce. BIA pomáhá klasifikovat závažnost, protože definuje dotčené služby, příjemce služeb, provozní narušení a možný přeshraniční dopad.

Klasifikace incidentů podle DORA zohledňuje také dotčené klienty nebo transakce, dobu trvání, geografický rozsah, ztráty dat, kritičnost dotčených služeb a ekonomický dopad. To jsou pole BIA. Pokud je BIA slabá, klasifikace incidentů se stává subjektivní právě v nejhorší možný okamžik.

Kontinuita dodavatelů je místo, kde se BIA setkává se smluvní realitou

Pro NIS2 a DORA již kontinuita dodavatelů není volitelná. NIS2 Article 21 zahrnuje zabezpečení dodavatelského řetězce a vyžaduje pozornost vůči zranitelnostem dodavatelů, kvalitě a odolnosti produktů, postupům kybernetické bezpečnosti dodavatelů a postupům bezpečného vývoje. DORA vyžaduje, aby riziko třetích stran v ICT bylo řízeno v rámci rizik ICT, včetně registrů smluv o ICT službách, náležité péče, rizika koncentrace, strategií ukončení, práv na audit a přístup, podpory při incidentech, úrovní služeb a požadavků na mimořádné situace.

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

Závislosti na třetích stranách a dodavatelském řetězci 6.5.1. Smlouvy s kritickými dodavateli musí obsahovat povinnosti v oblasti kontinuity a závazky k době obnovy. 6.5.2. Klíčoví poskytovatelé služeb musí na vyžádání prokázat pravidelné testování kontinuity a účast na incidentních cvičeních.

Verze pro SME také vyžaduje:

kontaktní místa dodavatelů pro kontinuitu

Toto malé pole může být při skutečném incidentu rozhodující. Pokud váš plán obnovy říká „kontaktujte podporu poskytovatele cloudových služeb“, ale nikdo nezná eskalační cestu, referenci smlouvy, proces závažnosti ani mimopracovní kontakt, RTO je fikce.

Tato tabulka nenahrazuje řízení dodavatelských rizik. Převádí dodavatelské riziko do provozní roviny.

Jak budou auditoři testovat vaši BIA

Auditor ISO/IEC 27001:2022 obvykle začne rozsahem, kontextem, posouzením rizik, ošetřením rizik, prohlášením o použitelnosti, opatřeními přílohy A, dokumentovanými informacemi, provozním plánováním, hodnocením výkonnosti a zlepšováním. Porovná BIA s posouzením rizik a SoA. Pokud jsou zahrnuta A.5.30, A.5.29 nebo A.8.13, vyžádá si důkazy o implementaci a testování.

Přezkum podle DORA se zaměří na kritické nebo důležité funkce, ICT aktiva, závislosti na třetích stranách v ICT, testování odolnosti, klasifikaci incidentů, smluvní požadavky, strategie ukončení a dohled řídicího orgánu. Bude očekávat, že BIA bude sladěna s rámcem řízení rizik ICT, strategií digitální provozní odolnosti, plány kontinuity činností ICT, plány reakce a obnovy a testovacím programem.

Dozorový orgán podle NIS2 se bude ptát na opatření kontinuity činností, správu zálohování, obnovu po havárii, krizové řízení, zabezpečení dodavatelského řetězce, schválení v rámci správy a řízení a schopnost hlášení významných incidentů. BIA má prokazovat, že tato opatření vycházejí z dopadu na služby a schválených priorit.

Hodnotitel NIST CSF 2.0 se zeptá, jak BIA informuje Current Profile, Target Profile, analýzu mezer a akční plán. Bude sledovat výstupy Govern pro právní, regulační, smluvní, riziková, rolová, politická, dohledová a dodavatelsko-riziková rozhodnutí. Posoudí také výstupy Identify, Protect, Detect, Respond a Recover.

Auditor COBIT 2019 nebo auditor ve stylu ISACA se obvykle zaměří na správu a řízení. Kdo službu vlastní? Kdo akceptoval riziko? Jsou cíle sladěny s podnikovými cíli? Jsou dodavatelé monitorováni? Jsou přínosy, rizika a zdroje vyváženy? Jsou nápravná opatření sledována až do uzavření?

Politika monitorování auditu a souladu společnosti Clarysec Audit and Compliance Monitoring Policy začleňuje BIA do cyklu plánování auditů:

Plán auditů založený na rizicích musí být každoročně vypracován a schválen s přihlédnutím k těmto skutečnostem: 5.2.1 výsledky nejnovějších posouzení rizik a analýzy dopadů na podnikání (BIA) 5.2.2 předchozí zjištění auditu a stav nápravných opatření 5.2.3 změny procesů, IT infrastruktury, systémů nebo dodavatelů 5.2.4 externí povinnosti, jako je DORA Article 25 nebo zákaznické smlouvy

To je krok vyspělosti, který mnoho organizací opomíjí. BIA nemá stát mimo ujištění. Má řídit plán auditů.

Častá selhání BIA zjišťovaná ve skutečných posouzeních

Stejné slabiny se objevují opakovaně.

Za prvé, BIA uvádí aplikace, nikoli služby. Zákazníky a regulační orgány zajímá narušení služeb. Na aplikacích záleží proto, že tyto služby podporují.

Za druhé, cíle RTO a RPO jsou kopírovány ze šablon. Čtyřhodinové RTO může znít rozumně, dokud test obnovy neukáže, že trvá devět hodin obnovit integraci identit, obnovit konfiguraci, obnovit data, ověřit integritu a znovu aktivovat monitorování.

Za třetí, zálohy nejsou propojeny s dopadem na podnikání. Frekvence, uchovávání, šifrování, umístění úložiště, priorita obnovení a testování musí odrážet schválené cíle obnovy.

Za čtvrté, dodavatelé jsou bráni jako položky dotazníku, nikoli jako závislosti obnovy. Závazky dodavatelů v oblasti kontinuity, eskalační kontakty, důkazy obnovy a účast na incidentních cvičeních mají být navázány na kritické služby.

Za páté, chybí schválení vedením. Podle NIS2 a DORA je odpovědnost vedení výslovná. Podle ISO/IEC 27001:2022 jsou vedení, role, schválení vlastníkem rizika a reporting výkonnosti základní požadavky.

Za šesté, testování je příliš úzké. Obnovení jednoho souboru je užitečné, ale neprokazuje obnovu služby. Cesta obnovy kritické služby může zahrnovat DNS, identity, tajemství, infrastrukturu jako kód, API brány, monitorování, protokolování, eskalaci dodavatelů, komunikaci se zákazníky a přezkum dopadů na soukromí.

Zenith Blueprint ve fázi Controls in Action, Step 19, zachycuje auditní očekávání pro zálohy:

Testujete své zálohy?

Odpověď musí znít „ano, s důkazy“ a tyto důkazy musí být propojeny zpět s BIA.

Balíček důkazů BIA připravený na audit

Praktický program BIA má vytvářet stručný balíček důkazů použitelný pro audity, náležitou péči zákazníků, reporting řídicímu orgánu a zlepšování odolnosti.

Tento balíček vypráví konzistentní příběh. Zároveň činí odolnost měřitelnou.

Další krok: proměňte svou BIA v důkazy souladu

Maria nepotřebuje větší tabulku. Potřebuje živý důkazní řetězec.

Začněte jednou kritickou službou. Zmapujte její ICT aktiva, data, osoby, dodavatele a podpůrné služby. Schvalte MTD, RTO a RPO. Slaďte harmonogram záloh. Zkontrolujte závazky dodavatelů k obnově. Proveďte jeden test obnovy. Zaznamenejte mezery. Aktualizujte plán ošetření rizik. Předložte výsledek vedení.

Poté postup opakujte.

Clarysec může tento proces urychlit pomocí Business Continuity Policy and Disaster Recovery Policy, Business Continuity Policy and Disaster Recovery Policy - SME, Backup and Restore Policy, Audit and Compliance Monitoring Policy, Zenith Blueprint a Zenith Controls.

Vaše BIA nemá být dokument do šuplíku vytvořený pro audit. Má být provozním důkazem, že vaše nejdůležitější služby dokážou přežít narušení, splnit očekávání zákazníků a regulačních orgánů a obnovit se v mezích, které vaše vedení skutečně schválilo.

Pokud se vaše organizace připravuje na dozorový audit ISO/IEC 27001:2022, zákaznické ujištění podle NIS2, přezkumy třetích stran v ICT podle DORA nebo reporting odolnosti na úrovni řídicího orgánu, začněte tím, že učiníte BIA obhajitelnou. Stáhněte si politiky kontinuity a auditu Clarysec, projděte si implementační plán Zenith nebo si vyžádejte posouzení důkazů odolnosti, abyste roztříštěná opatření proměnili v jeden příběh připravený na audit.