⚡ LIMITED TIME Get our FREE €500+ Compliance Starter Kit
Get It Now →

Testování obnovy připravené k auditu pro ISO 27001, NIS2 a DORA

Igor Petreski
14 min read
Mapa důkazů z testování obnovy připravená k auditu pro ISO 27001, NIS2 a DORA

Je 07:40 v pondělí ráno a Sarah, CISO rychle rostoucí fintech společnosti, sleduje, jak se v reálném čase rozvíjí krize. Finanční ředitel nemůže otevřít platformu pro schvalování plateb. Service desk se domnívá, že jde o problém s úložištěm. Tým infrastruktury má podezření na ransomware, protože několik sdílených složek nyní zobrazuje šifrované názvy souborů. Generální ředitel chce vědět, zda jsou mzdy v bezpečí. Právní oddělení se ptá, zda je nutné informovat regulační orgány.

Sarah otevírá řídicí panel zálohování. Je plný zelených zaškrtnutí.

Mělo by to být uklidňující, ale není. Úspěšná zálohovací úloha není důkazem úspěšné obnovy. Je to jako vidět hasicí přístroj na zdi, aniž by bylo jasné, zda je natlakovaný, dostupný a použitelný pod tlakem.

Společnost Sarah spadá do rozsahu ISO 27001:2022, podle NIS2 je považována za důležitý subjekt a jako finanční subjekt podléhá DORA. Otázkou už není, zda organizace provádí zálohování. Otázkou je, zda dokáže obnovit správné systémy ke správnému bodu v čase, v rámci schválených Recovery Time Objectives a Recovery Point Objectives, a to s důkazy dostatečně silnými pro auditora, regulační orgán, zákazníka, pojišťovnu i řídicí orgán.

Právě zde mnoho programů zálohování selhává. Mají zálohovací úlohy. Mají řídicí panely. Mají snapshoty. Mohou mít i cloudové úložiště. Když však přijde tlak, nedokážou doložit, že kritické systémy jsou obnovitelné, že byly provedeny testy obnovy, že neúspěšné testy spustily nápravná opatření a že se důkazy čistě mapují na očekávání ISO 27001:2022, NIS2, DORA, NIST a COBIT 2019.

Zálohování a testování obnovy se stalo otázkou provozní odolnosti na úrovni řídicího orgánu. NIS2 zvyšuje očekávání v oblasti řízení kybernetických rizik a kontinuity činností. DORA činí provozní odolnost ICT základní povinností finančních subjektů a jejich kritických poskytovatelů ICT služeb. ISO 27001:2022 poskytuje strukturu systému řízení pro rozsah, rizika, výběr kontrolních opatření, důkazy, audit a neustálé zlepšování.

Praktickou výzvou je převést technický test obnovy na důkazy připravené k auditu.

Záloha není důkazem, dokud není prokázána obnova

Úspěšně dokončená zálohovací úloha je pouze dílčí signál. Říká, že data byla někam zkopírována. Nedokládá, že data lze obnovit, že aplikační závislosti zůstaly neporušené, že jsou dostupné šifrovací klíče, že stále fungují služby identit ani že obnovený systém podporuje skutečné obchodní procesy.

Auditoři to vědí. Regulační orgány to vědí. Útočníci to vědí.

Technicky vyspělý auditor neskončí u snímku obrazovky ukazujícího 97% úspěšnost zálohovacích úloh. Zeptá se:

  • Které systémy jsou kritické nebo mají vysoký dopad?
  • Jaké RTO a RPO platí pro každý systém?
  • Kdy byl proveden poslední test obnovy?
  • Byl test úplný, částečný, na úrovni aplikace, databáze nebo souborů?
  • Kdo po obnově ověřil obchodní proces?
  • Byla selhání zaznamenána jako neshody nebo opatření ke zlepšení?
  • Jak dlouho se uchovávají logy a záznamy z testů obnovy?
  • Jsou kopie záloh odděleny napříč lokalitami?
  • Jak se důkazy mapují na registr rizik a Prohlášení o použitelnosti?

Proto je jazyk politik Clarysec záměrně přímý. Politika zálohování a obnovy pro SME [BRP-SME], sekce Požadavky na správu a řízení, ustanovení politiky 5.3.3, vyžaduje:

Testy obnovy se provádějí alespoň čtvrtletně a výsledky jsou dokumentovány za účelem ověření obnovitelnosti

Tato jediná věta mění auditní rozhovor. Posouvá organizaci od tvrzení „máme zálohy“ k tvrzení „ověřujeme obnovitelnost ve stanovené periodicitě a uchováváme výsledky“.

Stejná Politika zálohování a obnovy pro SME, sekce Vynucování a dodržování, ustanovení politiky 8.2.2, posiluje povinnost vedení důkazů:

Logy a záznamy z testů obnovy se uchovávají pro účely auditu

Toto ustanovení brání tomu, aby se testování obnovy stalo nedokumentovanou kolektivní pamětí. Pokud inženýr infrastruktury řekne „testovali jsme to v březnu“, ale neexistuje žádný záznam, nejde o důkaz připravený k auditu.

Stejná politika řeší také přežitelnost prostřednictvím diverzity úložišť. V sekci Požadavky na implementaci politiky, ustanovení politiky 6.3.1.1, musí být zálohy:

Uloženy alespoň ve dvou lokalitách (lokálně a v cloudu)

Jde o praktický základní požadavek. Nenahrazuje posouzení rizik, ale snižuje pravděpodobnost, že jedna fyzická nebo logická doména selhání zničí produkční i záložní data.

Řetězec důkazů ISO 27001:2022 začíná před testem

Organizace často považují soulad v oblasti zálohování za téma provozu IT. Z pohledu ISO 27001:2022 je to příliš úzké pojetí. Zálohování a testování obnovy mají být začleněny do systému řízení bezpečnosti informací a propojeny s rozsahem, riziky, výběrem kontrolních opatření, monitorováním, interním auditem a neustálým zlepšováním.

Clarysec Zenith Blueprint: 30krokový plán auditora [ZB] zahajuje tento řetězec důkazů ještě před provedením jakéhokoli testu obnovy.

Ve fázi Základy ISMS a vedení, krok 2, Potřeby zainteresovaných stran a rozsah ISMS, Zenith Blueprint ukládá organizacím definovat, co do ISMS spadá:

Akční položka 4.3: Vypracujte návrh prohlášení o rozsahu ISMS. Uveďte, co je zahrnuto (obchodní jednotky, lokality, systémy) a případné výjimky. Sdílejte tento návrh s vrcholovým vedením k připomínkám – musí souhlasit s tím, které části organizace budou podléhat ISMS. Je také vhodné tento rozsah zkontrolovat proti dřívějšímu seznamu požadavků zainteresovaných stran: Pokrývá váš rozsah všechny oblasti potřebné ke splnění těchto požadavků?

Pro testování obnovy rozsah definuje prostředí obnovy. Pokud jsou v rozsahu platební platforma, poskytovatel identity, databáze ERP, server pro správu koncových bodů a cloudové objektové úložiště, musí je důkazy o obnově zahrnovat nebo musí zdůvodnit, proč zahrnuty nejsou. Pokud je systém vyloučen, musí být vyloučení obhajitelné vůči požadavkům zainteresovaných stran, smluvním povinnostem, regulatorním povinnostem a potřebám kontinuity činností.

Další vazbou je riziko. Ve fázi Řízení rizik, krok 11, Tvorba a dokumentace registru rizik, Zenith Blueprint popisuje registr rizik jako hlavní záznam rizik, aktiv, hrozeb, zranitelností, stávajících kontrolních opatření, vlastníků a rozhodnutí o ošetření.

Záznam rizika souvisejícího se zálohováním má být praktický, nikoli teoretický.

Prvek rizikaPříklad záznamu
AktivumPlatforma pro schvalování plateb a podpůrná databáze
HrozbaZašifrování ransomwarem nebo destruktivní zásah administrátora
ZranitelnostZálohy nejsou čtvrtletně obnovovány a aplikační závislosti nejsou ověřovány
DopadZpoždění výplat, regulatorní expozice, dopad na důvěru zákazníků
Stávající kontrolní opatřeníDenní zálohovací úlohy, neměnné cloudové úložiště, čtvrtletní test obnovy
Vlastník rizikaVedoucí infrastruktury
Rozhodnutí o ošetřeníZmírnit prostřednictvím testovaných záloh, dokumentovaných důkazů o obnově a aktualizací BCP

Zde se zálohování stává auditovatelným. Už nejde o „máme zálohy“. Jde o „identifikovali jsme obchodní riziko, vybrali kontrolní opatření, přiřadili vlastnictví, otestovali kontrolní opatření a uchovali důkazy“.

Zenith Blueprint, fáze Řízení rizik, krok 13, Plánování ošetření rizik a Prohlášení o použitelnosti, uzavírá smyčku dohledatelnosti:

Mapujte kontrolní opatření na rizika a kapitoly (dohledatelnost)

Nyní, když máte plán ošetření rizik i SoA:

✓ Mapujte kontrolní opatření na rizika: V plánu ošetření ve vašem registru rizik jste pro každé riziko uvedli určitá kontrolní opatření. Ke každému riziku můžete přidat sloupec „Odkaz na opatření přílohy A“ a uvést čísla opatření.

Pro zálohování a testování obnovy má Prohlášení o použitelnosti propojit rizikový scénář s opatřeními přílohy A ISO/IEC 27001:2022, zejména 8.13 Zálohování informací, 5.30 Připravenost ICT pro kontinuitu činností, 8.14 Redundance zařízení pro zpracování informací a 5.29 Bezpečnost informací při narušení činností.

SoA nemá tato opatření pouze označit jako použitelná. Má vysvětlit, proč jsou použitelná, jaké existují důkazy o implementaci, kdo opatření vlastní a jak se řeší výjimky.

Mapa kontrolních opatření, kterou auditoři očekávají

Clarysec Zenith Controls: průvodce souladem napříč rámci [ZC] nevytváří samostatná ani proprietární kontrolní opatření. Organizuje oficiální normy a rámce do praktického pohledu napříč požadavky na soulad, aby organizace rozuměly tomu, jak jedna provozní praxe, například testování obnovy, podporuje více povinností.

U opatření ISO/IEC 27002:2022 8.13 Zálohování informací klasifikuje Zenith Controls opatření jako nápravné, vázané na integritu a dostupnost, sladěné s konceptem kybernetické bezpečnosti Recover, podporující provozní schopnost kontinuity a zařazené do bezpečnostní domény ochrany. Tento profil rámuje zálohy jako schopnost obnovy, nikoli pouze jako proces ukládání.

U opatření ISO/IEC 27002:2022 5.30 Připravenost ICT pro kontinuitu činností klasifikuje Zenith Controls opatření jako nápravné, zaměřené na dostupnost, sladěné s Respond, podporující kontinuitu a umístěné v bezpečnostní doméně odolnosti. Právě zde se testování obnovy přímo propojuje s provozní odolností.

U opatření ISO/IEC 27002:2022 8.14 Redundance zařízení pro zpracování informací identifikuje Zenith Controls preventivní kontrolní opatření zaměřené na dostupnost, sladěné s Protect, podporující kontinuitu a správu aktiv a propojené s doménami ochrany a odolnosti. Redundance a zálohy nejsou totéž. Redundance pomáhá předcházet přerušení. Zálohy umožňují obnovu po ztrátě, poškození nebo útoku.

U opatření ISO/IEC 27002:2022 5.29 Bezpečnost informací při narušení činností ukazuje Zenith Controls širší profil: preventivní a nápravné, pokrývající důvěrnost, integritu a dostupnost, sladěné s Protect a Respond, podporující kontinuitu a propojené s ochranou a odolností. To je důležité při obnově po ransomwaru, protože obnova nesmí vytvářet nová bezpečnostní selhání, například obnovovat zranitelné image, obcházet protokolování nebo znovu aktivovat nadměrná oprávnění.

Opatření přílohy A ISO/IEC 27001:2022Role v odolnostiDůkazy očekávané auditory
8.13 Zálohování informacíDokládá, že data a systémy lze obnovit po ztrátě, poškození nebo útokuHarmonogram zálohování, záznamy z testů obnovy, kritéria úspěšnosti, logy, výjimky, důkazy o uchovávání
5.30 Připravenost ICT pro kontinuitu činnostíDokládá, že schopnosti ICT podporují cíle kontinuityBIA, mapování RTO/RPO, runbooky obnovy, zprávy z testů, získané poznatky
8.14 Redundance zařízení pro zpracování informacíSnižuje závislost na jednom zařízení pro zpracování nebo jedné servisní traseArchitektonické diagramy, výsledky testů přepnutí na záložní řešení, přezkum kapacity, mapování závislostí
5.29 Bezpečnost informací při narušení činnostíUdržuje bezpečnost během degradovaného provozu a obnovyZáznamy krizového přístupu, schválení nouzových změn, protokolování, časová osa incidentu, bezpečnostní ověření po obnově

Praktické ponaučení je jednoduché. Test obnovy není jedno izolované kontrolní opatření. Je to důkaz napříč řetězcem odolnosti.

Skrytá auditní mezera: RTO a RPO bez doložení

Jedním z nejčastějších zjištění auditů kontinuity je rozdíl mezi dokumentovanými RTO/RPO a skutečnou schopností obnovy.

Plán kontinuity činností může uvádět, že zákaznický portál má čtyřhodinové RTO a jednohodinové RPO. Zálohovací platforma může běžet každou hodinu. Při prvním realistickém cvičení obnovy však tým zjistí, že obnova databáze trvá tři hodiny, změny DNS vyžadují další hodinu, aplikační certifikát expiroval a integrace identity nebyla nikdy zahrnuta do runbooku. Skutečná doba obnovy je osm hodin.

Dokumentované RTO bylo fikcí.

Clarysec Politika kontinuity činností a obnovy po havárii pro SME [BCDR-SME], sekce Požadavky na správu a řízení, ustanovení politiky 5.2.1.4, výslovně stanoví požadavek kontinuity:

Recovery Time Objectives (RTOs) a Recovery Point Objectives (RPOs) pro každý systém

To je důležité, protože „rychle obnovit kritické služby“ není měřitelné. „Obnovit databázi pro schvalování plateb do čtyř hodin s nejvýše jednou hodinou ztráty dat“ měřitelné je.

Stejná Politika kontinuity činností a obnovy po havárii pro SME, sekce Požadavky na implementaci politiky, ustanovení politiky 6.4.2, převádí testování na zlepšování:

Všechny výsledky testů musí být dokumentovány a získané poznatky musí být zaznamenány a použity k aktualizaci BCP.

Neúspěšná obnova sama o sobě nepředstavuje auditní katastrofu. Neúspěšná obnova bez dokumentovaného poznatku, vlastníka, nápravy a opakovaného testu ano.

Pro podniková prostředí poskytuje Clarysec Politika zálohování a obnovy [BRP] formálnější správu. V sekci Požadavky na správu a řízení, ustanovení politiky 5.1, uvádí:

Hlavní harmonogram zálohování musí být udržován a každoročně přezkoumáván. Musí specifikovat:

Tento úvodní požadavek stanoví klíčový artefakt správy. Hlavní harmonogram zálohování má identifikovat systémy, datové sady, frekvenci zálohování, uchovávání, lokalitu, vlastnictví, klasifikaci, závislosti a periodicitu testování.

Stejná Politika zálohování a obnovy, sekce Požadavky na správu a řízení, ustanovení politiky 5.2, propojuje očekávání v oblasti zálohování s dopadem na činnost:

Všechny systémy a aplikace klasifikované jako kritické nebo s vysokým dopadem v analýze dopadů na obchodní činnost (BIA) musí:

Zde se BIA a správa zálohování propojují. Kritické systémy a systémy s vysokým dopadem vyžadují silnější ujištění o obnově, častější testování, lepší mapování závislostí a disciplinovanější evidenci důkazů.

Jeden model důkazů pro ISO 27001:2022, NIS2, DORA, NIST a COBIT 2019

Týmy pro soulad často narážejí na duplicitu rámců. ISO 27001:2022 vyžaduje výběr kontrolních opatření na základě rizik a důkazy. NIS2 očekává opatření řízení kybernetických rizik, včetně kontinuity činností. DORA očekává provozní odolnost ICT, reakci a obnovu, postupy zálohování a obnovy a testování digitální provozní odolnosti. NIST a COBIT 2019 používají zase jiný jazyk.

Řešením není budovat samostatné programy zálohování pro každý rámec. Řešením je vybudovat jeden model důkazů, na který lze nahlížet různými auditními perspektivami.

Perspektiva rámceCo zálohování a testování obnovy dokládáDůkazy, které mají být připravené k auditu
ISO 27001:2022Rizika jsou ošetřena vybranými kontrolními opatřeními, testována, monitorována a zlepšována prostřednictvím ISMSRozsah, registr rizik, SoA, harmonogram zálohování, záznamy o obnově, výsledky interního auditu, evidence CAPA
NIS2Základní nebo důležité služby dokážou odolat kybernetickému narušení a obnovit se po němPlány kontinuity činností, krizové postupy, testy záloh, vazby na reakci na incidenty, dohled vedení
DORAICT služby podporující kritické nebo důležité funkce jsou odolné a obnovitelnéMapování ICT aktiv, RTO/RPO, zprávy z testů obnovy, důkazy o závislostech na třetích stranách, postupy obnovy
NIST CSFSchopnosti obnovy podporují odolné výsledky kybernetické bezpečnostiPlány obnovy, kontroly integrity záloh, komunikační postupy, získané poznatky
COBIT 2019Cíle správy a řízení a cíle řízení jsou podporovány měřitelnými kontrolními opatřeními a přiřazenou odpovědnostíVlastnictví procesů, metriky, výkonnost kontrol, sledování problémů, reportování vedení

U NIS2 je nejpřímějším odkazem Article 21 o opatřeních řízení kybernetických rizik. Article 21(2)(c) výslovně zahrnuje kontinuitu činností, například správu záloh, obnovu po havárii a krizové řízení. Důležitý je také Article 21(2)(f), protože se zabývá politikami a postupy pro posuzování účinnosti opatření řízení kybernetických rizik. Testování obnovy je přesně tímto: důkazem, že opatření funguje.

U DORA jsou nejsilnější vazby na Article 11 o reakci a obnově, Article 12 o politikách a postupech zálohování, postupech a metodách obnovy a Article 24 o obecných požadavcích na testování digitální provozní odolnosti. U finančních subjektů nemusí samotný test obnovy databáze stačit, pokud obchodní služba závisí na cloudové identitě, konektivitě platební brány, outsourcovaném hostingu nebo řízeném monitorování. Důkazy ve stylu DORA mají být na úrovni služby, nikoli pouze na úrovni serveru.

Opatření ISO/IEC 27001:2022Vazba na DORAVazba na NIS2
8.13 Zálohování informacíArticle 12 vyžaduje politiky zálohování, postupy a metody obnovyArticle 21(2)(c) zahrnuje správu záloh a obnovu po havárii jako opatření kontinuity činností
5.30 Připravenost ICT pro kontinuitu činnostíArticle 11 vyžaduje schopnost reakce a obnovy a Article 24 vyžaduje testování odolnostiArticle 21(2)(c) zahrnuje kontinuitu činností a krizové řízení
8.14 Redundance zařízení pro zpracování informacíArticle 6 a Article 9 podporují řízení rizik ICT, ochranu, prevenci a omezení jediných bodů selháníArticle 21 vyžaduje přiměřená a úměrná opatření k řízení rizik pro síťové a informační systémy
5.29 Bezpečnost informací při narušení činnostíReakce a obnova podle Article 11 vyžaduje řízenou obnovu během incidentůOpatření řízení rizik podle Article 21 vyžadují kontinuitu bez opuštění bezpečnostních opatření

To je efektivita sjednocené strategie souladu. Čtvrtletní test obnovy platebního systému může podporovat důkazy podle přílohy A ISO 27001:2022, očekávání kontinuity podle NIS2, požadavky DORA na obnovu ICT, výsledky NIST CSF Recover a reportování správy a řízení podle COBIT 2019, pokud jsou důkazy správně strukturovány.

Praktický test obnovy, který se stane důkazem připraveným k auditu

Vraťme se k pondělnímu rannímu scénáři Sarah, ale představme si, že její organizace byla připravena pomocí nástrojů Clarysec.

Platforma pro schvalování plateb je v BIA klasifikována jako kritická. Schválené RTO je čtyři hodiny. Schválené RPO je jedna hodina. Platforma závisí na databázovém clusteru, poskytovateli identity, trezoru tajemství, pipeline pro protokolování, DNS, certifikátech a odchozím e-mailovém relay.

Tým Sarah staví čtvrtletní test obnovy kolem šesti kroků.

Krok 1: Potvrďte rozsah a závislosti

Pomocí kroku 2 Zenith Blueprint Sarah potvrzuje, že platební platforma, databáze, integrace identity, zálohovací infrastruktura a prostředí obnovy jsou v rozsahu ISMS. Právní oddělení potvrzuje regulatorní relevanci. Finance potvrzují dopad na činnost. IT potvrzuje závislosti.

Tím se předchází klasické chybě, kdy se obnoví pouze databáze a ignoruje se autentizační služba potřebná pro přístup k aplikaci.

Krok 2: Propojte test s registrem rizik

Pomocí kroku 11 Zenith Blueprint obsahuje registr rizik scénář: „Ztráta nebo zašifrování dat platformy pro schvalování plateb znemožní platební operace a vytvoří regulatorní expozici.“

Stávající kontrolní opatření zahrnují denní zálohy, neměnné cloudové úložiště, kopie záloh ve více lokalitách, čtvrtletní testování obnovy a dokumentované runbooky obnovy. Vlastníkem rizika je vedoucí infrastruktury. Vlastníkem obchodního procesu jsou finanční operace. Rozhodnutím o ošetření je zmírnění.

Krok 3: Namapujte ošetření na SoA

Pomocí kroku 13 Zenith Blueprint mapuje SoA riziko na opatření přílohy A ISO/IEC 27001:2022 8.13, 5.30, 8.14 a 5.29. SoA vysvětluje, že testování záloh poskytuje nápravnou schopnost obnovy, postupy kontinuity ICT podporují kontinuitu činností, redundance snižuje pravděpodobnost výpadku a bezpečnost při narušení činností brání nebezpečným zkratkám při obnově.

Krok 4: Použijte ustanovení politik jako testovací kritéria

Tým používá ustanovení 5.3.3 Politiky zálohování a obnovy pro SME pro čtvrtletní testování obnovy, ustanovení 8.2.2 pro uchovávání důkazů a ustanovení 6.3.1.1 pro ukládání ve více lokalitách. Používá ustanovení 5.2.1.4 Politiky kontinuity činností a obnovy po havárii pro SME pro cíle RTO/RPO a ustanovení 6.4.2 pro získané poznatky a aktualizace BCP.

Testovací kritériumCílDůkaz
Periodicita obnovyČtvrtletněKalendář testů a schválený harmonogram
RTO4 hodinyČas zahájení, čas ukončení, uplynulá doba obnovy
RPO1 hodinaČasové razítko zálohy a validace transakce
LokalityDostupné místní a cloudové zdroje zálohReport záložního repozitáře
IntegritaKontroly konzistence databáze prošlyValidační logy
AplikaceUživatel z financí může schválit testovací platbuSchválení obchodní validace
BezpečnostPo obnově ověřeno protokolování, řízení přístupu a tajemstvíBezpečnostní kontrolní seznam a snímky obrazovky

Krok 5: Proveďte obnovu a zaznamenejte fakta

Obnova se provádí v izolovaném prostředí obnovy. Tým zaznamenává časová razítka, identifikátory zálohovací sady, kroky obnovy, chyby, výsledky validace a schválení.

Kvalitní záznam testu obnovy má obsahovat:

Pole testu obnovyPříklad
ID testuQ2-2026-PAY-RESTORE
Testovaný systémPlatforma pro schvalování plateb
Použitá zálohovací sadaZáloha platební platformy ze schváleného bodu obnovy
Lokalita obnovyIzolované prostředí obnovy
Cílové RTO4 hodiny
Cílové RPO1 hodina
Skutečná doba obnovy2 hodiny 45 minut
Skutečný bod obnovy42 minut
Validace integrityKontroly konzistence databáze prošly
Obchodní validaceUživatel z financí schválil testovací platbu
Bezpečnostní validacePotvrzeno protokolování, řízení přístupu, tajemství a monitorování
VýsledekSplněno s podmínkou
SchváleníCISO, vedoucí infrastruktury, vlastník finančních operací

Během testu tým zjistí jeden problém. Obnovená aplikace nemůže odesílat notifikační e-maily, protože seznam povolených položek e-mailového relay nezahrnuje podsíť obnovy. Základní schvalování plateb funguje, ale workflow je degradované.

Krok 6: Zaznamenejte získané poznatky a nápravné opatření

Právě zde mnoho organizací končí příliš brzy. Přístup Clarysec posouvá problém do systému zlepšování.

Ve fázi Audit, přezkum a zlepšování, krok 29, Neustálé zlepšování, používá Zenith Blueprint evidenci CAPA ke sledování popisu problému, kořenové příčiny, nápravného opatření, vlastníka, cílového data a stavu.

Pole CAPAPříklad
Popis problémuObnovená platforma pro schvalování plateb nemohla odesílat e-mailové notifikace z podsítě obnovy
Kořenová příčinaSíť obnovy nebyla zahrnuta v návrhu seznamu povolených položek e-mailového relay
Nápravné opatřeníAktualizovat architekturu obnovy a postup seznamu povolených položek e-mailového relay
VlastníkVedoucí infrastruktury
Cílové datum15 pracovních dnů
StavOtevřeno, čeká na opakovaný test

Tento jediný test obnovy nyní vytváří řetězec důkazů připravený k auditu: požadavek politiky, potvrzení rozsahu, mapování rizik, mapování SoA, plán testu, záznam o provedení, obchodní validace, bezpečnostní validace, záznam problému, nápravné opatření a aktualizace BCP.

Jak různí auditoři prověřují stejné důkazy

Silný balíček důkazů předjímá perspektivu auditora.

Auditor ISO 27001:2022 obvykle začne systémem řízení. Zeptá se, zda jsou požadavky na zálohování a obnovu zahrnuty do rozsahu, založeny na riziku, implementovány, monitorovány, interně auditovány a zlepšovány. Bude očekávat dohledatelnost od registru rizik přes SoA až po provozní záznamy. Může také propojit neúspěšné testy a nápravná opatření s kapitolou 10.2 ISO/IEC 27001:2022 o neshodách a nápravných opatřeních.

Přezkum podle DORA se zaměří na provozní odolnost ICT u kritických nebo důležitých funkcí. Bude vyžadovat obnovu na úrovni služby, závislosti na poskytovatelích ICT služeb třetích stran, scénářové testování, dohled řídicího orgánu a důkazy, že postupy obnovy jsou účinné.

Dohledová perspektiva NIS2 bude hledat přiměřená a úměrná opatření řízení kybernetických rizik. Důkazy o zálohování a obnově po havárii mají ukázat, že základní nebo důležité služby dokážou po incidentech udržet nebo obnovit provoz, přičemž vedení zná zbytkové riziko.

Hodnotitel orientovaný na NIST se zaměří na výsledky kybernetické bezpečnosti napříč Identify, Protect, Detect, Respond a Recover. Může se ptát na neměnné zálohy, privilegovaný přístup k záložním repozitářům, obnovu do čistých prostředí, komunikaci a získané poznatky.

Auditor ve stylu COBIT 2019 nebo ISACA zdůrazní správu a řízení, vlastnictví procesů, metriky, reportování vedení a sledování problémů. Technicky elegantní obnova na něj udělá menší dojem, pokud není jasné vlastnictví a reportování.

Stejné důkazy mohou uspokojit všechny tyto perspektivy, ale pouze tehdy, jsou-li úplné.

Běžná selhání testování obnovy, která vytvářejí auditní zjištění

Clarysec opakovaně vidí stejné preventabilní mezery v důkazech.

Vzorec selháníProč vytváří auditní rizikoPraktická náprava
Úspěch zálohování se považuje za úspěch obnovyDokončení kopírování nedokládá obnovitelnostProvádějte dokumentované testy obnovy s validací
RTO a RPO jsou definovány, ale netestují seCíle kontinuity mohou být nerealistickéBěhem testů měřte skutečnou dobu obnovy a bod obnovy
Obnovu ověřuje pouze infrastrukturaObchodní proces může zůstat nepoužitelnýVyžadujte schválení vlastníkem obchodního procesu u kritických systémů
Záznamy z testů jsou roztříštěnéAuditoři nemohou ověřit konzistenciPoužijte standardní šablonu zprávy z testu obnovy a složku důkazů
Neúspěšné testy se prodiskutují, ale nesledujíChybí důkazy o neustálém zlepšováníZaznamenejte problémy do CAPA s vlastníkem, termínem splnění a opakovaným testem
Zálohy jsou uloženy v jedné logické doméně selháníRansomware nebo chybná konfigurace mohou zničit obnovitelnostPoužijte oddělené lokality, neměnné úložiště a řízení přístupu
Závislosti jsou vyloučenyObnovené aplikace nemusí fungovatMapujte identity, DNS, tajemství, certifikáty, integrace a protokolování
Bezpečnost se během obnovy ignorujeObnovené služby mohou být zranitelné nebo nemonitorovanéZahrňte bezpečnostní validaci po obnově

Cílem není byrokracie. Cílem je spolehlivá obnova pod tlakem a obhajitelné důkazy při auditu.

Vytvořte balíček důkazů o obnově pro řídicí orgán

Vrcholové vedení nepotřebuje surové logy zálohování. Potřebuje ujištění, že kritické služby jsou obnovitelné, výjimky jsou známé a opatření ke zlepšení postupují.

Pro každou kritickou službu reportujte:

  • Název služby a vlastník obchodního procesu
  • Kritičnost podle BIA
  • Schválené RTO a RPO
  • Datum posledního testu obnovy
  • Dosažené RTO a RPO
  • Výsledek testu
  • Otevřená nápravná opatření
  • Závislosti na třetích stranách ovlivňující obnovu
  • Prohlášení o zbytkovém riziku
  • Příští plánovaný test
Kritická službaRTO/RPOPoslední testVýsledekOtevřený problémSdělení pro vedení
Platforma pro schvalování plateb4h/1h2026-04-12Splněno s podmínkouSeznam povolených položek e-mailového relay pro podsíť obnovyZákladní schvalování plateb obnoveno v cílovém čase, náprava workflow notifikací probíhá
Zákaznický portál8h/2h2026-03-20NesplněnoObnova databáze překročila RTO o 90 minutVyžaduje se zlepšení kapacity a procesu obnovy
Obnova poskytovatele identity2h/15m2026-04-05SplněnoŽádnéPodporuje obnovu závislých kritických služeb

Tento styl reportování vytváří most mezi technickými týmy, auditory a vedením. Podporuje také přezkoumání ISMS vedením a dohled nad odolností podle NIS2 a DORA.

Praktický auditní kontrolní seznam na příštích 30 až 90 dní

Pokud se blíží audit, začněte s důkazy, které již máte, a nejprve uzavřete mezery s nejvyšším rizikem.

  • Identifikujte všechny kritické systémy a systémy s vysokým dopadem podle BIA.
  • Potvrďte RTO a RPO pro každý kritický systém.
  • Ověřte, že každý kritický systém je uveden v hlavním harmonogramu zálohování.
  • Potvrďte lokality záloh, včetně místních, cloudových, neměnných nebo oddělených repozitářů.
  • Vyberte alespoň jeden nedávný test obnovy pro každou kritickou službu nebo test okamžitě naplánujte.
  • Zajistěte, aby záznamy z testů obnovy uváděly rozsah, časová razítka, zálohovací sadu, výsledek, dosažené RTO/RPO a validaci.
  • Získejte schválení vlastníkem obchodního procesu pro obnovu na úrovni aplikace.
  • Po obnově ověřte bezpečnost, včetně řízení přístupu, protokolování, monitorování, tajemství, certifikátů a expozice zranitelnostem.
  • Namapujte důkazy na registr rizik a SoA.
  • Zaznamenejte problémy do CAPA, přiřaďte vlastníky a sledujte opakovaný test.
  • Shrňte výsledky pro přezkoumání vedením.
  • Připravte pohled napříč požadavky na soulad pro auditní diskuse k ISO 27001:2022, NIS2, DORA, NIST CSF a COBIT 2019.

Pokud před auditem nedokážete dokončit každou položku, buďte transparentní. Auditoři obvykle lépe reagují na dokumentovanou mezeru s plánem nápravných opatření než na vágní tvrzení o vyspělosti.

Udělejte z testování obnovy svůj nejsilnější důkaz odolnosti

Zálohování a testování obnovy je jedním z nejjasnějších způsobů, jak doložit provozní odolnost. Je hmatatelné, měřitelné, relevantní pro činnost organizace a přímo propojené s ISO 27001:2022, NIS2, DORA, NIST, COBIT 2019, reportováním řídicímu orgánu, ujištěním zákazníků a očekáváními pojišťoven.

Ale pouze tehdy, je-li řádně dokumentováno.

Clarysec pomáhá organizacím převést provoz zálohování na důkazy připravené k auditu prostřednictvím Politiky zálohování a obnovy, Politiky zálohování a obnovy pro SME, Politiky kontinuity činností a obnovy po havárii pro SME, Zenith Blueprint a Zenith Controls.

Váš další praktický krok je jednoduchý. Vyberte tento týden jednu kritickou službu. Proveďte test obnovy proti jejím schváleným RTO a RPO. Zdokumentujte výsledek. Namapujte jej na registr rizik a SoA. Zaznamenejte každý získaný poznatek.

Pokud chcete, aby byl tento proces opakovatelný napříč ISO 27001:2022, NIS2, DORA, NIST a COBIT 2019, sada nástrojů Clarysec vám poskytne strukturu k doložení obnovy bez budování labyrintu souladu od nuly.

Frequently Asked Questions

About the Author

Igor Petreski

Igor Petreski

Compliance Systems Architect, Clarysec LLC

Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council

Share this article

Related Articles

Mapování NIS2 2024/2690 na ISO 27001 pro poskytovatele cloudových služeb

Mapování NIS2 2024/2690 na ISO 27001 pro poskytovatele cloudových služeb

Jednotné mapování opatření prováděcího nařízení NIS2 2024/2690 na ISO/IEC 27001:2022 pro poskytovatele cloudových služeb, MSP, MSSP a poskytovatele datových center. Zahrnuje ustanovení politik Clarysec, auditní důkazy, sladění s DORA a GDPR a praktický implementační plán.

ISO 27001 SoA pro připravenost na NIS2 a DORA

ISO 27001 SoA pro připravenost na NIS2 a DORA

Zjistěte, jak využít Prohlášení o použitelnosti podle ISO 27001 jako auditně připravený most mezi NIS2, DORA, GDPR, ošetřením rizik, dodavateli, reakcí na incidenty a důkazy.