Testiranje vraćanja spremno za reviziju za ISO 27001, NIS2 i DORA

Ponedjeljak je u 07:40, a Sarah, glavna direktorica za informacijsku sigurnost (CISO) u brzo rastućoj fintech organizaciji, u stvarnom vremenu promatra nastanak krize. CFO ne može otvoriti platformu za odobravanje plaćanja. Služba za podršku smatra da je riječ o problemu s pohranom. Infrastrukturni tim sumnja na ransomware jer nekoliko zajedničkih mapa sada prikazuje šifrirane nazive datoteka. CEO želi znati je li obračun plaća siguran. Pravni tim pita moraju li se obavijestiti regulatorna tijela.

Sarah otvara nadzornu ploču sigurnosnih kopija. Puna je zelenih kvačica.

To bi trebalo ulijevati sigurnost, ali ne ulijeva. Uspješno dovršen zadatak sigurnosnog kopiranja nije dokaz uspješnog vraćanja. To je kao vidjeti vatrogasni aparat na zidu, a ne znati je li napunjen, dostupan i upotrebljiv pod pritiskom.

Sarahina organizacija certificirana je prema ISO 27001:2022, smatra se važnim subjektom prema NIS2 i podliježe DORA kao financijski subjekt. Pitanje više nije izrađuje li organizacija sigurnosne kopije. Pitanje je može li vratiti prave sustave, na pravu točku u vremenu, unutar odobrenog ciljanog vremena oporavka i ciljane točke oporavka, uz dokaze dovoljno snažne za revizora, regulatorno tijelo, klijenta, osiguratelja i upravu.

Upravo tu mnogi programi sigurnosnog kopiranja zakazuju. Imaju zadatke sigurnosnog kopiranja. Imaju nadzorne ploče. Imaju snimke sigurnosnih kopija. Možda imaju i pohranu u oblaku. No kada nastupi pritisak, ne mogu dokazati da su kritični sustavi oporavljivi, da su testovi oporavka provedeni, da su neuspješni testovi pokrenuli korektivne radnje i da se dokazi jasno mapiraju na očekivanja ISO 27001:2022, NIS2, DORA, NIST i COBIT 2019.

Testiranje sigurnosnog kopiranja i vraćanja postalo je pitanje operativne otpornosti na razini uprave. NIS2 podiže očekivanja u pogledu upravljanja kibersigurnosnim rizicima i neprekidnosti poslovanja. DORA čini IKT operativnu otpornost temeljnom obvezom financijskih subjekata i njihovih kritičnih pružatelja IKT usluga. ISO 27001:2022 pruža strukturu sustava upravljanja za opseg, rizik, odabir kontrola, dokaze, reviziju i kontinuirano poboljšanje.

Praktični je izazov pretvoriti tehnički test vraćanja u dokaze spremne za reviziju.

Sigurnosna kopija nije dokaz dok se ne dokaže vraćanje

Uspješno dovršen zadatak sigurnosnog kopiranja samo je djelomičan signal. Govori da su podaci negdje kopirani. Ne dokazuje da se podaci mogu vratiti, da su ovisnosti aplikacije očuvane, da su ključevi za šifriranje dostupni, da usluge identiteta i dalje rade ili da oporavljeni sustav podržava stvarne poslovne operacije.

Revizori to znaju. Regulatorna tijela to znaju. Napadači to znaju.

Tehnički zreo revizor neće stati na snimci zaslona koja prikazuje 97 posto uspješno dovršenih zadataka sigurnosnog kopiranja. Pitat će:

• Koji su sustavi kritični ili visokog utjecaja?
• Koji se RTO i RPO primjenjuju na svaki sustav?
• Kada je proveden zadnji test vraćanja?
• Je li test bio potpun, djelomičan, na razini aplikacije, na razini baze podataka ili na razini datoteke?
• Tko je provjerio poslovni proces nakon vraćanja?
• Jesu li neuspjesi evidentirani kao nesukladnosti ili radnje poboljšanja?
• Koliko se dugo čuvaju zapisnici i zapisi o testovima oporavka?
• Jesu li sigurnosne kopije odvojene po lokacijama?
• Kako se dokazi mapiraju na registar rizika i Izjavu o primjenjivosti?

Zbog toga je jezik Clarysec politika namjerno izravan. Politika sigurnosnog kopiranja i vraćanja podataka za MSP [BRP-SME], odjeljak Zahtjevi upravljanja, klauzula politike 5.3.3, zahtijeva:

Testovi oporavka provode se najmanje tromjesečno, a rezultati se dokumentiraju radi provjere mogućnosti oporavka.

Ta jedna rečenica mijenja revizijski razgovor. Organizaciju pomiče s tvrdnje „imamo sigurnosne kopije” na tvrdnju „provjeravamo mogućnost oporavka u definiranim intervalima i čuvamo rezultate”.

Ista Politika sigurnosnog kopiranja i vraćanja podataka za MSP, odjeljak Provedba i usklađenost, klauzula politike 8.2.2, dodatno naglašava obvezu dokazivanja:

Zapisnici i zapisi o testovima oporavka čuvaju se za potrebe revizije.

Ta klauzula sprječava da testiranje vraćanja postane nedokumentirano institucionalno pamćenje. Ako infrastrukturni inženjer kaže: „To smo testirali u ožujku”, ali zapis ne postoji, to nisu dokazi spremni za reviziju.

Ista politika uređuje i otpornost kroz raznolikost pohrane. U odjeljku Zahtjevi za provedbu politike, klauzula politike 6.3.1.1, sigurnosne kopije moraju biti:

Pohranjene na najmanje dvije lokacije (lokalno i u oblaku).

To je praktična polazna osnova. Ne zamjenjuje procjenu rizika, ali smanjuje vjerojatnost da jedna fizička ili logička domena otkaza uništi i produkcijske podatke i sigurnosne kopije.

Lanac dokaza za ISO 27001:2022 počinje prije testa

Organizacije često tretiraju usklađenost sigurnosnog kopiranja kao temu IT operacija. U smislu ISO 27001:2022, to je preusko. Testiranje sigurnosnog kopiranja i vraćanja treba biti ugrađeno u sustav upravljanja informacijskom sigurnošću, povezano s opsegom, rizikom, odabirom kontrola, praćenjem, internom revizijom i kontinuiranim poboljšanjem.

Clarysecov Zenith Blueprint: revizorov plan provedbe u 30 koraka [ZB] započinje taj lanac dokaza prije provedbe bilo kojeg testa vraćanja.

U fazi Temelji i vodstvo ISMS-a, korak 2, Potrebe dionika i opseg ISMS-a, Zenith Blueprint upućuje organizacije da definiraju što je unutar ISMS-a:

Akcijska stavka 4.3: Izradite nacrt izjave o opsegu ISMS-a. Navedite što je uključeno (poslovne jedinice, lokacije, sustavi) i sva isključenja. Podijelite taj nacrt s najvišim rukovodstvom radi povratnih informacija – ono se mora složiti koji će dijelovi poslovanja biti obuhvaćeni ISMS-om. Također je razumno provjeriti taj opseg u odnosu na ranije utvrđen popis zahtjeva dionika: obuhvaća li vaš opseg sva područja potrebna za ispunjenje tih zahtjeva?

Za testiranje vraćanja opseg definira područje oporavka. Ako su platforma za odobravanje plaćanja, pružatelj identiteta, ERP baza podataka, poslužitelj za upravljanje krajnjim uređajima i objektna pohrana u oblaku u opsegu, dokazi o vraćanju moraju ih uključiti ili obrazložiti zašto nisu uključeni. Ako je sustav isključen, isključenje mora biti dokazivo u odnosu na zahtjeve dionika, ugovorne obveze, regulatorne obveze i potrebe neprekidnosti poslovanja.

Sljedeća poveznica je rizik. U fazi Upravljanje rizicima, korak 11, Izrada i dokumentiranje registra rizika, Zenith Blueprint opisuje registar rizika kao glavni zapis rizika, imovine, prijetnji, ranjivosti, postojećih kontrola, vlasnika i odluka o obradi rizika.

Unos rizika povezan sa sigurnosnim kopiranjem treba biti praktičan, a ne teorijski.

Ovdje sigurnosno kopiranje postaje revizijski provjerljivo. Više nije riječ o tvrdnji „imamo sigurnosne kopije”. Riječ je o tvrdnji „identificirali smo poslovni rizik, odabrali kontrole, dodijelili vlasništvo, testirali kontrolu i zadržali dokaze”.

Zenith Blueprint, faza Upravljanje rizicima, korak 13, Planiranje obrade rizika i Izjava o primjenjivosti, zatvara krug sljedivosti:

Mapirajte kontrole na rizike i klauzule (sljedivost)

Sada kada imate i plan obrade rizika i SoA:

✓ Mapirajte kontrole na rizike: u planu obrade u registru rizika naveli ste određene kontrole za svaki rizik. Možete dodati stupac „Referenca kontrole Priloga A” svakom riziku i navesti brojeve kontrola.

Za sigurnosno kopiranje i testiranje vraćanja Izjava o primjenjivosti treba povezati scenarij rizika s kontrolama iz ISO/IEC 27001:2022 Prilog A, osobito 8.13 Sigurnosno kopiranje informacija, 5.30 IKT spremnost za neprekidnost poslovanja, 8.14 Redundantnost kapaciteta za obradu informacija i 5.29 Informacijska sigurnost tijekom prekida.

SoA ne smije samo označiti te kontrole kao primjenjive. Treba objasniti zašto su primjenjive, koji dokazi provedbe postoje, tko je vlasnik kontrole i kako se postupa s iznimkama.

Mapa kontrola koju revizori očekuju vidjeti

Clarysecov Zenith Controls: vodič za međusobno usklađivanje zahtjeva [ZC] ne stvara odvojene ili vlasničke kontrole. On organizira službene standarde i okvire u praktičan prikaz međusobne usklađenosti kako bi organizacije razumjele kako jedna operativna praksa, primjerice testiranje vraćanja, podržava više obveza.

Za kontrolu ISO/IEC 27002:2022 8.13 Sigurnosno kopiranje informacija, Zenith Controls klasificira kontrolu kao korektivnu, povezanu s cjelovitošću i dostupnošću, usklađenu s konceptom kibersigurnosti Recover, podržava operativnu sposobnost neprekidnosti poslovanja i pripada sigurnosnoj domeni zaštite. Taj profil preoblikuje sigurnosne kopije u sposobnost oporavka, a ne samo u proces pohrane.

Za kontrolu ISO/IEC 27002:2022 5.30 IKT spremnost za neprekidnost poslovanja, Zenith Controls klasificira kontrolu kao korektivnu, usmjerenu na dostupnost, usklađenu s Respond, podržava neprekidnost poslovanja i smještenu u sigurnosnu domenu otpornosti. Tu se testiranje vraćanja izravno povezuje s operativnom otpornošću.

Za kontrolu ISO/IEC 27002:2022 8.14 Redundantnost kapaciteta za obradu informacija, Zenith Controls identificira preventivnu kontrolu usmjerenu na dostupnost, usklađenu s Protect, koja podržava neprekidnost poslovanja i upravljanje imovinom te je povezana s domenama zaštite i otpornosti. Redundantnost i sigurnosne kopije nisu isto. Redundantnost pomaže spriječiti prekid. Sigurnosne kopije omogućuju oporavak nakon gubitka, oštećenja ili napada.

Za kontrolu ISO/IEC 27002:2022 5.29 Informacijska sigurnost tijekom prekida, Zenith Controls prikazuje širi profil: preventivna i korektivna kontrola, pokriva povjerljivost, cjelovitost i dostupnost, usklađena je s Protect i Respond, podržava neprekidnost poslovanja te je povezana sa zaštitom i otpornošću. To je važno tijekom oporavka od ransomwarea jer vraćanje ne smije stvoriti nove sigurnosne propuste, primjerice vraćanjem ranjivih sistemskih slika, zaobilaženjem zapisivanja događaja ili ponovnim aktiviranjem prekomjernih privilegija.

Praktična je pouka jednostavna. Test vraćanja nije jedna izolirana kontrola. To je dokaz kroz cijeli lanac otpornosti.

Skrivena revizijska praznina: RTO i RPO bez dokaza

Jedan od najčešćih nalaza revizije neprekidnosti poslovanja jest razlika između dokumentiranog RTO/RPO-a i stvarne sposobnosti vraćanja.

Plan neprekidnosti poslovanja može navoditi da korisnički portal ima RTO od četiri sata i RPO od jednog sata. Platforma za sigurnosno kopiranje može se izvršavati svakih sat vremena. No tijekom prve realistične vježbe vraćanja tim otkriva da vraćanje baze podataka traje tri sata, promjene DNS-a zahtijevaju još jedan sat, certifikat aplikacije je istekao, a integracija identiteta nikada nije uključena u operativne upute za oporavak. Stvarno vrijeme oporavka iznosi osam sati.

Dokumentirani RTO bio je fikcija.

Clarysecova Politika neprekidnosti poslovanja i oporavka od katastrofe za MSP [BCDR-SME], odjeljak Zahtjevi upravljanja, klauzula politike 5.2.1.4, izričito definira zahtjev neprekidnosti poslovanja:

Ciljana vremena oporavka (RTO) i ciljane točke oporavka (RPO) za svaki sustav.

To je važno jer „brzo vratiti kritične usluge” nije mjerljivo. „Vratiti bazu podataka za odobravanje plaćanja unutar četiri sata, uz najviše jedan sat gubitka podataka” jest mjerljivo.

Ista Politika neprekidnosti poslovanja i oporavka od katastrofe za MSP, odjeljak Zahtjevi za provedbu politike, klauzula politike 6.4.2, pretvara testiranje u poboljšanje:

Svi rezultati testiranja moraju se dokumentirati, a naučene lekcije moraju se evidentirati i koristiti za ažuriranje BCP-a.

Neuspješno vraćanje nije automatski revizijska katastrofa. Neuspješno vraćanje bez dokumentirane lekcije, vlasnika, ispravka i ponovnog testiranja jest.

Za poslovna okruženja, Clarysecova Politika sigurnosnog kopiranja i vraćanja podataka [BRP] pruža formalnije upravljanje. U odjeljku Zahtjevi upravljanja, klauzula politike 5.1, navodi:

Glavni raspored sigurnosnog kopiranja mora se održavati i pregledavati jednom godišnje. Mora navoditi:

Taj uvodni zahtjev uspostavlja temeljni upravljački artefakt. Glavni raspored sigurnosnog kopiranja treba identificirati sustave, skupove podataka, učestalost sigurnosnog kopiranja, čuvanje, lokaciju, vlasništvo, klasifikaciju, ovisnosti i učestalost testiranja.

Ista Politika sigurnosnog kopiranja i vraćanja podataka, odjeljak Zahtjevi upravljanja, klauzula politike 5.2, povezuje očekivanja sigurnosnog kopiranja s utjecajem na poslovanje:

Svi sustavi i aplikacije klasificirani kao kritični ili visokog utjecaja u analizi utjecaja na poslovanje (BIA) moraju:

Tu se BIA i upravljanje sigurnosnim kopiranjem spajaju. Kritični sustavi i sustavi visokog utjecaja zahtijevaju snažnije dokazivanje oporavka, češće testiranje, bolje mapiranje ovisnosti i discipliniranije dokaze.

Jedan model dokaza za ISO 27001:2022, NIS2, DORA, NIST i COBIT 2019

Timovi za usklađenost često se bore s dupliciranjem okvira. ISO 27001:2022 traži odabir kontrola i dokaze na temelju rizika. NIS2 očekuje mjere upravljanja kibersigurnosnim rizicima, uključujući neprekidnost poslovanja. DORA očekuje IKT operativnu otpornost, odgovor i oporavak, postupke sigurnosnog kopiranja i vraćanja te testiranje digitalne operativne otpornosti. NIST i COBIT 2019 ponovno koriste drukčiji jezik.

Rješenje nije izgraditi zasebne programe sigurnosnog kopiranja za svaki okvir. Rješenje je izgraditi jedan model dokaza koji se može promatrati kroz više revizijskih perspektiva.

Za NIS2 najizravnija je referenca Article 21 o mjerama upravljanja kibersigurnosnim rizicima. Article 21(2)(c) posebno uključuje neprekidnost poslovanja, primjerice upravljanje sigurnosnim kopijama, oporavak od katastrofe i krizno upravljanje. Article 21(2)(f) također je važan jer se odnosi na politike i postupke za procjenu učinkovitosti mjera upravljanja kibersigurnosnim rizicima. Testiranje vraćanja upravo je to: dokaz da mjera funkcionira.

Za DORA najsnažnije su poveznice Article 11 o odgovoru i oporavku, Article 12 o politikama i postupcima sigurnosnog kopiranja, postupcima i metodama vraćanja i oporavka te Article 24 o općim zahtjevima za testiranje digitalne operativne otpornosti. Za financijske subjekte sam test vraćanja baze podataka može biti nedostatan ako poslovna usluga ovisi o identitetu u oblaku, povezivosti s pristupnikom za plaćanja, eksternaliziranom hostingu ili upravljanom nadzoru. Dokazi u skladu s DORA trebaju biti na razini usluge, ne samo na razini poslužitelja.

To je učinkovitost objedinjene strategije usklađenosti. Tromjesečni test vraćanja za sustav plaćanja može podržati dokaze za ISO 27001:2022 Prilog A, očekivanja neprekidnosti poslovanja prema NIS2, zahtjeve IKT oporavka prema DORA, ishode NIST CSF Recover i izvješćivanje o upravljanju prema COBIT 2019, ako su dokazi pravilno strukturirani.

Praktičan test vraćanja koji postaje dokaz spreman za reviziju

Vratimo se Sarahinu ponedjeljku ujutro, ali zamislimo da se njezina organizacija pripremila koristeći Clarysecov komplet alata.

Platforma za odobravanje plaćanja klasificirana je kao kritična u BIA. Odobreni RTO iznosi četiri sata. Odobreni RPO iznosi jedan sat. Platforma ovisi o klasteru baze podataka, pružatelju identiteta, trezoru tajnih vrijednosti, kanalu za zapisivanje događaja, DNS-u, certifikatima i izlaznom releju e-pošte.

Sarahin tim gradi tromjesečni test vraćanja oko šest koraka.

Korak 1: Potvrdite opseg i ovisnosti

Koristeći Zenith Blueprint korak 2, Sarah potvrđuje da su platforma za plaćanja, baza podataka, integracija identiteta, infrastruktura sigurnosnog kopiranja i okruženje za oporavak unutar opsega ISMS-a. Pravni tim potvrđuje regulatornu relevantnost. Financije potvrđuju utjecaj na poslovanje. IT potvrđuje ovisnosti.

Time se izbjegava klasična pogreška vraćanja samo baze podataka uz zanemarivanje autentifikacijske usluge potrebne za pristup aplikaciji.

Korak 2: Povežite test s registrom rizika

Koristeći Zenith Blueprint korak 11, registar rizika uključuje scenarij: „Gubitak ili šifriranje podataka platforme za odobravanje plaćanja sprječava platne operacije i stvara regulatornu izloženost.”

Postojeće kontrole uključuju dnevne sigurnosne kopije, nepromjenjivu pohranu u oblaku, sigurnosne kopije na više lokacija, tromjesečno testiranje vraćanja i dokumentirane operativne upute za oporavak. Vlasnik rizika je voditelj infrastrukture. Poslovni vlasnik su financijske operacije. Odluka o obradi rizika je ublažavanje.

Korak 3: Mapirajte obradu rizika na SoA

Koristeći Zenith Blueprint korak 13, SoA mapira rizik na kontrole ISO/IEC 27001:2022 Prilog A 8.13, 5.30, 8.14 i 5.29. SoA objašnjava da testiranje sigurnosnih kopija pruža korektivnu sposobnost oporavka, IKT postupci neprekidnosti podržavaju neprekidnost poslovanja, redundantnost smanjuje vjerojatnost prekida, a sigurnost tijekom prekida sprječava nesigurne prečace u oporavku.

Korak 4: Koristite klauzule politika kao kriterije testa

Tim koristi klauzulu 5.3.3 iz Politike sigurnosnog kopiranja i vraćanja podataka za MSP za tromjesečno testiranje vraćanja, klauzulu 8.2.2 za čuvanje dokaza i klauzulu 6.3.1.1 za pohranu na više lokacija. Koristi klauzulu 5.2.1.4 iz Politike neprekidnosti poslovanja i oporavka od katastrofe za MSP za ciljeve RTO/RPO-a i klauzulu 6.4.2 za naučene lekcije i ažuriranja BCP-a.

Korak 5: Provedite vraćanje i zabilježite činjenice

Vraćanje se provodi u izoliranom okruženju za oporavak. Tim bilježi vremenske oznake, identifikatore skupova sigurnosnih kopija, korake vraćanja, pogreške, rezultate provjere i odobrenja.

Snažan zapis o testu vraćanja treba uključivati:

Tijekom testa tim otkriva jedan problem. Vraćena aplikacija ne može slati e-poruke obavijesti jer popis dopuštenih za relej e-pošte ne uključuje podmrežu za oporavak. Temeljno odobravanje plaćanja radi, ali je radni tok degradiran.

Korak 6: Evidentirajte naučene lekcije i korektivnu radnju

Ovdje mnoge organizacije prerano stanu. Clarysecov pristup usmjerava problem u sustav poboljšanja.

U fazi Revizija, pregled i poboljšanje, korak 29, Kontinuirano poboljšanje, Zenith Blueprint koristi CAPA zapisnik za praćenje opisa problema, analize temeljnog uzroka, korektivne radnje, vlasnika, ciljnog datuma i statusa.

Ovaj jedan test vraćanja sada proizvodi lanac dokaza spreman za reviziju: zahtjev politike, potvrdu opsega, mapiranje rizika, mapiranje SoA, plan testa, zapis provedbe, poslovnu provjeru, sigurnosnu provjeru, zapis problema, korektivnu radnju i ažuriranje BCP-a.

Kako različiti revizori pregledavaju iste dokaze

Snažan paket dokaza predviđa revizorsku perspektivu.

Revizor za ISO 27001:2022 obično će krenuti od sustava upravljanja. Pitat će jesu li zahtjevi za sigurnosno kopiranje i vraćanje obuhvaćeni opsegom, temeljeni na riziku, provedeni, praćeni, interno revidirani i poboljšavani. Očekivat će sljedivost od registra rizika preko SoA do operativnih zapisa. Također može povezati neuspješne testove i korektivne radnje s klauzulom ISO/IEC 27001:2022 10.2 o nesukladnosti i korektivnoj radnji.

Pregledavatelj u kontekstu DORA usmjerit će se na IKT operativnu otpornost kritičnih ili važnih funkcija. Željet će vidjeti oporavak na razini usluge, ovisnosti o trećim stranama u području IKT-a, testiranje temeljeno na scenarijima, nadzor upravljačkog tijela i dokaze da su postupci vraćanja učinkoviti.

Nadzorna perspektiva NIS2 tražit će odgovarajuće i razmjerne mjere upravljanja kibersigurnosnim rizicima. Dokazi o sigurnosnom kopiranju i oporavku od katastrofe trebaju pokazati da ključne ili važne usluge mogu održati ili obnoviti rad nakon incidenata, uz svijest uprave o preostalom riziku.

Procjenitelj usmjeren na NIST usredotočit će se na ishode kibersigurnosti kroz Identify, Protect, Detect, Respond i Recover. Može postavljati pitanja o nepromjenjivim sigurnosnim kopijama, privilegiranom pristupu repozitorijima sigurnosnih kopija, vraćanju u čista okruženja, komunikaciji i naučenim lekcijama.

Revizor u stilu COBIT 2019 ili ISACA naglasit će upravljanje, vlasništvo nad procesima, metrike, izvješćivanje rukovodstvu i praćenje problema. Manje će ga impresionirati tehnički elegantno vraćanje ako vlasništvo i izvješćivanje nisu jasni.

Isti dokazi mogu zadovoljiti sve ove perspektive, ali samo ako su potpuni.

Uobičajeni neuspjesi testiranja vraćanja koji stvaraju revizijske nalaze

Clarysec opetovano vidi iste sprječive praznine u dokazima.

Cilj nije birokracija. Cilj je pouzdan oporavak pod pritiskom i dokazivost u reviziji.

Izgradite paket dokaza o oporavku za razinu uprave

Izvršnim rukovoditeljima nisu potrebni sirovi zapisnici sigurnosnih kopija. Potrebno im je uvjerenje da su kritične usluge oporavljive, da su iznimke poznate i da radnje poboljšanja napreduju.

Za svaku kritičnu uslugu izvijestite o sljedećem:

• Naziv usluge i vlasnik poslovanja
• Kritičnost prema BIA
• Odobreni RTO i RPO
• Datum zadnjeg testa vraćanja
• Ostvareni RTO i RPO
• Rezultat testa
• Otvorene korektivne radnje
• Ovisnosti o trećim stranama koje utječu na oporavak
• Izjava o preostalom riziku
• Sljedeći planirani test

Ovakav stil izvješćivanja stvara most između tehničkih timova, revizora i vodstva. Također podržava preispitivanje sustava upravljanja informacijskom sigurnošću od strane uprave i nadzor otpornosti prema NIS2 i DORA.

Praktični revizijski kontrolni popis za sljedećih 30 do 90 dana

Ako se revizija približava, krenite od dokaza koje već imate i prvo zatvorite praznine najvećeg rizika.

• Identificirajte sve kritične sustave i sustave visokog utjecaja iz BIA.
• Potvrdite RTO i RPO za svaki kritični sustav.
• Provjerite nalazi li se svaki kritični sustav u glavnom rasporedu sigurnosnog kopiranja.
• Potvrdite lokacije sigurnosnih kopija, uključujući lokalne, oblačne, nepromjenjive ili odvojene repozitorije.
• Odaberite barem jedan nedavni test vraćanja po kritičnoj usluzi ili odmah zakažite test.
• Osigurajte da zapisi o testiranju vraćanja prikazuju opseg, vremenske oznake, skup sigurnosnih kopija, rezultat, ostvareni RTO/RPO i provjeru.
• Pribavite odobrenje vlasnika poslovanja za oporavak na razini aplikacije.
• Provjerite sigurnost nakon vraćanja, uključujući kontrolu pristupa, zapisivanje događaja, praćenje, tajne vrijednosti, certifikate i izloženost ranjivostima.
• Mapirajte dokaze na registar rizika i SoA.
• Evidentirajte probleme u CAPA, dodijelite vlasnike i pratite ponovno testiranje.
• Sažmite rezultate za preispitivanje od strane uprave.
• Pripremite prikaz međusobne usklađenosti za revizijske razgovore o ISO 27001:2022, NIS2, DORA, NIST CSF i COBIT 2019.

Ako ne možete dovršiti svaku stavku prije revizije, budite transparentni. Revizori obično bolje reagiraju na dokumentiranu prazninu s planom korektivnih radnji nego na neodređene tvrdnje o zrelosti.

Učinite testiranje vraćanja svojim najjačim dokazom otpornosti

Testiranje sigurnosnog kopiranja i vraćanja jedan je od najjasnijih načina dokazivanja operativne otpornosti. Opipljivo je, mjerljivo, relevantno za poslovanje i izravno povezano s ISO 27001:2022, NIS2, DORA, NIST, COBIT 2019, izvješćivanjem upravi, programima dokazivanja sigurnosti prema zahtjevima klijenata i očekivanjima osiguratelja.

Ali samo ako je pravilno dokumentirano.

Clarysec pomaže organizacijama pretvoriti operacije sigurnosnog kopiranja u dokaze spremne za reviziju kroz Politiku sigurnosnog kopiranja i vraćanja podataka, Politiku sigurnosnog kopiranja i vraćanja podataka za MSP, Politiku neprekidnosti poslovanja i oporavka od katastrofe za MSP, Zenith Blueprint i Zenith Controls.

Vaš sljedeći praktični korak jednostavan je. Odaberite jednu kritičnu uslugu ovaj tjedan. Provedite test vraćanja u odnosu na njezin odobreni RTO i RPO. Dokumentirajte rezultat. Mapirajte ga na registar rizika i SoA. Zabilježite svaku naučenu lekciju.

Ako želite da taj proces bude ponovljiv kroz ISO 27001:2022, NIS2, DORA, NIST i COBIT 2019, Clarysecov komplet alata daje vam strukturu za dokazivanje oporavka bez izgradnje labirinta usklađenosti od nule.