klients jautā par mūsu atjaunošanas laiku pēc darbības pārrāvuma, ko man tur jāieraksta

Atveseļošanas laiks nav RTO/RPO skaitlis, bet procesa apraksts

Kas šeit parasti tiek jautāts, nav viens cipars, bet tas, vai pastāv nepārtrauktības process: vai ir ārkārtas nodrošinājums, vai tas ir pārbaudīts un cik ātri tiek atjaunota pakalpojuma sniegšana. Tāpēc neuznemeties konkrētu atveseļošanas laiku, ja tas nekur nav dokumentēts — piemēram, BCP (business continuity plan) vai DRP (disaster recovery plan) ar noteiktu RTO (recovery time objective) un RPO (recovery point objective). Ja tas nav norādīts, tad "nē, vēl formāli nav noteikts" ir godīga atbilde, iespējams, ar paskaidrojumu, ka rezerves kopijas jau pastāv, bet bez pārbaudīta atveseļošanas laika.

Daudzi klenti apvieno šo jautājumu ar jautājumu par pašu incidenta procedūru: vai ir process, lai atklātu un eskalētu bojājumu, pirms vispār var sākt atveseļošanu. Pārbaudiet arī drošības incidentu risināšanas procedūru, jo bez šī procesa atveseļošanas laiks nekādā gadījumā nav uzticams. Ja jūs esat definējis RTO/RPO, pierādījuma dokuments parasti ir pats BCP/DRP dokuments vai pēdējās failovera vai atjaunošanas testa atskaite. Ja šī testa atskaite trūkst, labāk sniedziet "nē", nevis nepārbaudītu pieņēmumu.

Kur tas izriet no: 21. panta 2. punkts un A pielikums

NIS2 direktīvas 21. panta 2. punkts no desmit pasākumiem skaidri min "business continuity, such as backup management and disaster recovery" kā obligātu entītijas drošības politikas daļu. ISO/IEC 27001 to detalizē Pielikumā A ar kontroles pasākumiem informācijas apstrādes iekārtu pieejamībai un nepārtrauktībai. Lai noskaidrotu, vai jūsu uzņēmums pats ir obligāts šim procesam, vispirms ir svarīgi noskaidrot, vai jūs ietilpstat direktīvā — pārbaudiet to caur vai uzņēmums atsevišķi ietilpst NIS2 direktīvas darbības jomā. Nīderlandes Kibernētiskās drošības likums transponē šo pienākumu, stājoties spēkā 2026. gada 15. augustā; līdz tam klenti to bieži jautā jau iepriekš, anticējot savus paša ķēdes pienākumus.