zákazník se ptá na naši dobu obnovení po výpadku, co tam vyplním

Doba obnovy není číslo RTO/RPO, ale popis procesu

Co se zde obvykle požaduje, není jediné číslo, ale existence procesu kontinuity: existuje nouzové opatření, bylo vyzkoušeno a jak rychle se služba obnoví. Nezadávejte tedy konkrétní dobu obnovy, pokud není nikde zdokumentována — například v BCP (business continuity plan) nebo DRP (disaster recovery plan) s definovaným RTO (recovery time objective) a RPO (recovery point objective). Pokud to tam není, pak je "ne, zatím není formálně definováno" upřímná odpověď, případně s vysvětlením, že zálohování existuje, ale bez vyzkoušené doby obnovy.

Mnoho zákazníků kombinuje tuto otázku s otázkou na samotný postup incidentu: existuje proces k detekci poruchy a její eskalaci, než vůbec lze začít s obnovou. Zkontroluj tedy také postupem pro řešení bezpečnostních incidentů, neboť bez tohoto procesu nelze dobu zotavení nijak zajistit. Máš-li definován RTO/RPO, důkazním materiálem je obvykle samotný dokument BCP/DRP, nebo testovací zpráva z poslední zkoušky převzetí služeb či obnovení. Chybí-li ti tato testovací zpráva, raději odpověz "ne" než aby jsi se spoléhal na netestovaný předpoklad.

Odkud to vyplývá: článek 21 odstavec 2 a Příloha A

Článek 21 odstavec 2 směrnice NIS2 výslovně jmenuje mezi deseti opatřeními "business continuity, such as backup management and disaster recovery" jako povinnou součást bezpečnostní politiky subjektu. ISO/IEC 27001 to rozpracovává v příloze A mezi kontrolními opatřeními pro dostupnost a kontinuitu zařízení zpracovávajících informace. Pro rozhodnutí, zda je tvůj podnik sám povinen mít tento proces, je nejprve relevantní, zda podléháš směrnici — ověř si to prostřednictvím zda podnik sám spadá pod směrnici NIS2Tento závazek implementuje Zákon o kybernetické bezpečnosti v Nizozemsku, který vstoupí v účinnost 15. srpna 2026; do té doby si jej zákazníci často již vyžadují v rámci svých vlastních povinností v dodavatelském řetězci.