Analiza utjecaja na poslovanje za ISO 27001, NIS2 i DORA

Revizijsko pitanje koje otkriva stvarnu prazninu u neprekidnosti poslovanja

Ponedjeljak je ujutro, a CISO brzorastuće fintech tvrtke, Maria, priprema se za sastanak odbora za rizike. Predmet poruke kratak je: „Spremnost za DORA i NIS2: pregled BIA-e.”

Njezin je tim izgradio ono što većina izvršnih rukovoditelja očekuje vidjeti. Postoji certificirani ISO/IEC 27001:2022 ISMS, operativne upute za odgovor na incidente, snimke zaslona sigurnosnih kopija, izvješća o ranjivostima, upitnici za dobavljače, dijagrami arhitekture oblaka i ažurirani registar rizika. Korporativni klijenti šalju NIS2 upitnike. Klijenti iz financijskog sektora uvode DORA odredbe u ugovore. Nadzorna revizija ISO/IEC 27001:2022 udaljena je samo mjesec dana.

Zatim vanjski revizor postavlja pitanje koje mijenja atmosferu u prostoriji:

„Ako vaša platforma za uključivanje klijenata nije dostupna 18 sati, koje su regulirane usluge pogođene, koji su dobavljači uključeni, koji je odobreni prioritet oporavka i gdje su dokazi da je poslovna strana prihvatila RTO i RPO?”

U prostoriji nastaje tišina.

Raspored sigurnosnog kopiranja kaže jedno. Plan oporavka od katastrofe kaže drugo. Ugovor s dobavljačem uključuje SLA dostupnosti, ali nema dokaza o testiranju oporavka. Registar rizika spominje dostupnost, ali ne objašnjava zašto se jedna usluga mora oporaviti brže od druge. Uprava je odobrila sigurnosnu politiku, ali nije odobrila poslovni utjecaj nedostupnosti.

To je problem analize utjecaja na poslovanje u 2026. godini.

Analiza utjecaja na poslovanje, odnosno BIA, više nije proračunska tablica priložena planu neprekidnosti poslovanja. Ona je dokazni most između poslovnih usluga, IKT imovine, dobavljača, prioriteta oporavka, RTO/RPO ciljeva, pragova incidenata, testiranja otpornosti i odgovornosti uprave. Za organizacije koje usklađuju ISO/IEC 27001:2022 s neprekidnošću poslovanja prema NIS2 i IKT otpornošću prema DORA, BIA je mjesto na kojem usklađenost postaje operativna.

Najzrelije organizacije već imaju mnoge odgovarajuće kontrole. Njihova je slabost sljedivost. BIA pretvara raspršene dokaze u priču spremnu za reviziju: što je važno, zašto je važno, koliko se brzo mora oporaviti, koje ga ovisnosti podržavaju, što je testirano, što nije uspjelo, što je poboljšano i tko je odobrio preostali rizik.

Zašto su stare BIA proračunske tablice sada rizik

NIS2 i DORA promijenili su ton usklađenosti u području neprekidnosti poslovanja. Ne tretiraju neprekidnost poslovanja, oporavak od katastrofe, odgovor na incidente, otpornost dobavljača i upravljanje kao odvojene dokumente. Očekuju da djeluju kao jedinstveni sustav.

Za subjekte obuhvaćene NIS2, Article 21 zahtijeva tehničke, operativne i organizacijske mjere za upravljanje rizicima za mrežne i informacijske sustave te za sprječavanje ili smanjenje utjecaja incidenata na primatelje usluga i druge usluge. Minimalne mjere uključuju analizu rizika, postupanje s incidentima, neprekidnost poslovanja uključujući upravljanje sigurnosnim kopiranjem, oporavak od katastrofe i krizno upravljanje, sigurnost opskrbnog lanca, postupanje s ranjivostima, procjenu djelotvornosti kontrola, osposobljavanje, kriptografiju, sigurnost u području ljudskih resursa, kontrolu pristupa, upravljanje imovinom, višefaktorsku autentifikaciju (MFA) i sigurne komunikacije.

NIS2 Article 20 prenosi to pitanje u nadležnost upravljačkih tijela. Upravljačka tijela moraju odobriti mjere upravljanja rizicima kibernetičke sigurnosti, nadzirati njihovu provedbu i mogu snositi odgovornost za povrede. To znači da nepodržani četverosatni RTO nije samo tehnička nedosljednost. To je slabost upravljanja.

DORA se primjenjuje od 17. siječnja 2025. i uspostavlja jedinstveni okvir EU-a za upravljanje IKT rizicima, prijavljivanje incidenata, testiranje digitalne operativne otpornosti, upravljanje rizicima trećih strana u području IKT-a, ugovorne zahtjeve i nadzor nad ključnim pružateljima IKT usluga trećih strana. Za financijske subjekte, kao i za pružatelje tehnologije koji ih podržavaju putem ugovora, DORA pretvara operativnu otpornost u strukturirani zahtjev za dokazima.

DORA Articles 5 i 6 zahtijevaju upravljanje i dokumentirani okvir za upravljanje IKT rizicima. Articles 7 do 14 obuhvaćaju pouzdane i otporne IKT sustave, identifikaciju imovine i ovisnosti, zaštitu, otkrivanje, IKT neprekidnost poslovanja, sigurnosno kopiranje, vraćanje podataka, oporavak, učenje nakon incidenata, podizanje svijesti, osposobljavanje i kriznu komunikaciju. Articles 24 do 26 zahtijevaju testiranje digitalne operativne otpornosti za financijske subjekte koji nisu mikropoduzeća. Articles 28 do 30 formaliziraju IKT rizik trećih strana, registre ugovora o IKT uslugama, izlazne strategije, razine usluga, prava na reviziju i zahtjeve za planiranje kontinuiteta.

ISO/IEC 27001:2022 pruža okosnicu sustava upravljanja. Njegove točke zahtijevaju da organizacija definira kontekst, zainteresirane strane, pravne i ugovorne obveze, opseg, vodstvo, politiku, uloge, procjenu rizika, obradu rizika, Izjavu o primjenjivosti, operativno planiranje, vrednovanje uspješnosti i kontinuirano poboljšanje.

Karika koja često nedostaje jest BIA. Bez nje planovi neprekidnosti poslovanja nisu jasno utemeljeni na riziku, ciljevi sigurnosnog kopiranja nisu poslovno odobreni, dobavljači nisu mapirani na kritične usluge, a uprava ne može pouzdano dokazati da su odluke o otpornosti donesene na temelju poslovnog utjecaja.

BIA kao upravljačka ravnina za dokaze otpornosti

Dokaziva BIA odgovara na sedam pitanja koja revizori, regulatori, klijenti i uprave sve češće postavljaju:

1. Koje su poslovne usluge kritične?
2. Koja IKT imovina, spremišta podataka, osobe, dobavljači i infrastrukturne usluge podržavaju svaku uslugu?
3. Kakav je operativni, financijski, pravni, ugovorni, korisnički, sigurnosni i reputacijski utjecaj prekida tijekom vremena?
4. Što je maksimalno prihvatljivo vrijeme prekida, odnosno MTD?
5. Koji su odobreni ciljano vrijeme oporavka, odnosno RTO, i ciljana točka oporavka, odnosno RPO?
6. Čine li aranžmani sigurnosnog kopiranja, redundancije, oblaka, dobavljača, osoblja i komunikacije te ciljeve ostvarivima?
7. Je li organizacija testirala put oporavka i pregledala rezultate?

Clarysecova korporativna Politika neprekidnosti poslovanja i oporavka od katastrofe P32 Politika neprekidnosti poslovanja i oporavka od katastrofe jasno navodi zahtjev:

Analiza utjecaja na poslovanje (BIA) mora se provoditi najmanje jednom godišnje za sve kritične poslovne jedinice i preispitati nakon značajnih promjena sustava, procesa ili ovisnosti. Izlazni rezultati BIA-e moraju definirati: 5.2.1. maksimalno prihvatljivo vrijeme prekida (MTD) 5.2.2. ciljeve vremena oporavka (RTO) 5.2.3. ciljeve točke oporavka (RPO) 5.2.4. kritične ovisnosti (sustavi, dobavljači, osoblje)

Ta točka revizorima daje praktično polazište. Također sprječava čest propust u kojem plan neprekidnosti poslovanja, plan oporavka od katastrofe, raspored sigurnosnog kopiranja, registar dobavljača i proces odgovora na incidente koriste različitu definiciju pojma „kritično”.

Ista politika zahtijeva integrirani pristup upravljanju:

Organizacija mora održavati integrirani sustav upravljanja kontinuitetom poslovanja (BCMS) usklađen s ISO 22301 i ISO/IEC 27001, osiguravajući integraciju sljedećeg: 5.1.1. analiza utjecaja na poslovanje (BIA) 5.1.2. procjena sigurnosnih rizika za prijetnje neprekidnosti poslovanja 5.1.3. planovi neprekidnosti poslovanja (BCP) 5.1.4. IKT planovi oporavka od katastrofe (DRP) 5.1.5. programi testiranja i vježbi 5.1.6. dokumentacija i kontinuirano poboljšanje

To je razlika između usklađenosti prema kontrolnom popisu i otpornosti spremne za reviziju. BIA nije jednokratni dokument. Ona postaje dio lanca dokaza ISMS-a i BCMS-a.

Kako ISO/IEC 27001:2022 pretvara BIA-u u dokaze koji se mogu revidirati

ISO/IEC 27001:2022 ne zahtijeva da svaka organizacija u svakoj točki koristi izraz „analiza utjecaja na poslovanje”, ali njegovi zahtjevi čine dokaze BIA-e iznimno vrijednima.

Točke 4.1 do 4.4 zahtijevaju da organizacija razumije unutarnja i vanjska pitanja, zainteresirane strane, pravne i regulatorne obveze, ugovorne zahtjeve, sučelja, ovisnosti i opseg ISMS-a. BIA je često najpraktičniji dokaz za ta sučelja i ovisnosti. Pokazuje koja usluga u oblaku, procesor plaćanja, pružatelj identiteta, telekomunikacijski pružatelj, upravljana sigurnosna usluga, podatkovni centar ili vanjski tim za podršku omogućuje kritičnu uslugu.

Točke 5.1 do 5.3 zahtijevaju vodstvo najvišeg rukovodstva, osiguravanje resursa, komunikaciju, dodjelu uloga i izvješćivanje. BIA vodstvu daje poslovnu osnovu za ulaganja u neprekidnost poslovanja. Bez nje su RTO i RPO ciljevi tehničke želje, a ne odobreni poslovni zahtjevi.

Točke 6.1.1 do 6.1.3 zahtijevaju ponovljivu procjenu i obradu rizika informacijske sigurnosti. Organizacija mora identificirati rizike za povjerljivost, cjelovitost i dostupnost, analizirati posljedice i vjerojatnost, odrediti razine rizika, prioritizirati obradu rizika, odabrati kontrole, usporediti odabrane kontrole s Prilogom A, izraditi Izjavu o primjenjivosti, izraditi plan obrade rizika i pribaviti odobrenje vlasnika rizika. BIA jača dio procjene rizika koji se odnosi na posljedice. Objašnjava zašto je dvosatni prekid jednog sustava prihvatljiv, dok dvosatni prekid drugoga stvara štetu za klijente, regulatornu izloženost, ugovornu povredu ili ozbiljan utjecaj na prihode.

Prilog A pruža katalog kontrola. Za BIA-u i neprekidnost poslovanja najrelevantnije kontrole ISO/IEC 27001:2022 Priloga A uključuju:

U Zenith Controls: The Cross-Compliance Guide Zenith Controls, Clarysec profilira kontrolu ISO/IEC 27002:2022 5.30, IKT spremnost za neprekidnost poslovanja, kao korektivnu kontrolu usmjerenu na dostupnost, mapiranu na koncept kibernetičke sigurnosti Respond, operativnu sposobnost neprekidnosti poslovanja i sigurnosnu domenu otpornosti. Kontrola 5.29, informacijska sigurnost tijekom prekida, profilirana je kao preventivna i korektivna te štiti povjerljivost, cjelovitost i dostupnost. Kontrola 8.13, sigurnosno kopiranje informacija, profilirana je kao korektivna te podržava cjelovitost i dostupnost kroz oporavak.

Ta je razlika važna. BIA ne smije postaviti samo pitanje: „Možemo li vratiti sustav?” Mora postaviti i pitanje: „Možemo li ostati sigurni tijekom prekida?” Tijekom ransomware događaja, ispada usluge u oblaku, neuspjeha dobavljača ili incidenta u podatkovnom centru organizaciji su i dalje potrebni kontrola pristupa, zapisivanje događaja, praćenje, očuvanje dokaza, sigurne komunikacije i mjere zaštite privatnosti.

Praktični model dokaza BIA-e

Snažna BIA povezuje poslovni jezik s tehničkim dokazima. Clarysec tipično strukturira model dokaza u pet slojeva.

Ovaj model dokaza funkcionira jer slijedi način na koji revizori razmišljaju. Najprije pitaju što je kritično. Zatim pitaju što to podržava. Zatim pitaju tko je odobrio cilj oporavka. Zatim pitaju mogu li tehnički aranžmani i aranžmani s dobavljačima ostvariti taj cilj. Na kraju pitaju je li organizacija testirala i poboljšala sposobnost.

NIST CSF 2.0 koristan je kao komunikacijski sloj. Njegova metoda CSF Profiles potiče organizacije da definiraju opseg, prikupe ulazne podatke kao što su politike, prioriteti rizika organizacije, registri BIA-e, zahtjevi kibernetičke sigurnosti, standardi, postupci, zaštitne mjere i radne uloge, izrade trenutačne i ciljne profile, analiziraju praznine, izrade prioritizirani akcijski plan, provedu taj plan i ažuriraju profil. To je gotovo točno način na koji BIA treba hraniti plan usklađivanja kroz više regulatornih i standardizacijskih okvira.

Jednotjedna BIA vježba koja stvara stvarne dokaze

Pretpostavimo da pružatelj SaaS usluge podržava klijente iz financijskog sektora. Njegova platforma podržava uključivanje klijenata, provjeru dokumenata i obavijesti klijentima. Sam pružatelj nije banka, ali mu klijenti šalju ugovorne zahtjeve potaknute DORA te NIS2 upitnike za dobavljače.

Usmjerena jednotjedna vježba može brzo stvoriti korisne dokaze.

1. dan: Identificirati kritične usluge i vremenske prozore utjecaja

Počnite s uslugama, a ne s poslužiteljima. Uključite vlasnike poslovanja, IT, sigurnost, pravne poslove, podršku, privatnost i upravljanje dobavljačima.

Ovakvo je uokvirivanje važno. Regulatori i klijenti prepoznaju usluge i funkcije. Aplikacije su važne zato što podržavaju te usluge.

2. dan: Mapirati ovisnosti

Za svaku uslugu mapirajte aplikacije, baze podataka, infrastrukturu, usluge u oblaku, pružatelje identiteta, praćenje, alate za sigurnosno kopiranje, osobe, dobavljače i prateće infrastrukturne usluge.

Tu BIA počinje stvarati vrijednost. Otkriva nevidljivi put oporavka, uključujući ovisnosti koje se često propuste u tehničkom DR planu.

3. dan: Odobriti MTD, RTO i RPO

Vlasnik poslovanja predlaže MTD. IT i sigurnost provjeravaju jesu li predloženi RTO i RPO tehnički ostvarivi. Uprava odobrava konačne ciljeve.

Za manje organizacije Clarysecova Politika neprekidnosti poslovanja i oporavka od katastrofe - SME P32S Politika neprekidnosti poslovanja i oporavka od katastrofe - SME daje istu disciplinu jednostavnijim jezikom. Zahtijeva BCP/DR planove koji definiraju pristup vraćanju ključnih funkcija:

Generalni direktor (GM) mora odobriti i održavati Planove neprekidnosti poslovanja i oporavka od katastrofe (BCP/DRP) koji jasno utvrđuju pristup organizacije vraćanju ključnih funkcija.

Također zahtijeva da plan uključuje:

prioritizirane usluge i sustave (kritične poslovne funkcije)

I:

ciljeve vremena oporavka (RTO) i ciljeve točke oporavka (RPO) za svaki sustav

Ključ nije prekomjerna dokumentacija. Ključ su sljedivost, odobrenje i dokazi da se ciljevi oporavka temelje na stvarnom poslovnom utjecaju.

4. dan: Uskladiti sigurnosno kopiranje s poslovnim utjecajem

Mnoge organizacije ovdje ne uspijevaju. BIA može postaviti četverosatni RPO, dok se sigurnosne kopije izvode svakih 24 sata. Ili alat za sigurnosno kopiranje štiti produkcijske baze podataka, ali ne i konfiguraciju, tajne vrijednosti, repozitorije infrastrukture kao koda, objektnu pohranu, DNS zapise, postavke identiteta ili konfiguraciju API pristupnika.

Clarysecova Politika sigurnosnog kopiranja i vraćanja podataka P15 Politika sigurnosnog kopiranja i vraćanja podataka zahtijeva glavni raspored sigurnosnog kopiranja povezan s ishodima BIA-e:

Glavni raspored sigurnosnog kopiranja mora se održavati i preispitati jednom godišnje. Mora navesti: 5.1.1 učestalost sigurnosnog kopiranja (na primjer, dnevne inkrementalne sigurnosne kopije i tjedne pune sigurnosne kopije) 5.1.2 razdoblja zadržavanja prema sustavu ili vrsti podataka 5.1.3 zahtjeve za šifriranje i pojedinosti o lokaciji pohrane 5.1.4 ciljeve RTO/RPO povezane s ishodima procjene utjecaja na poslovanje

Ova je točka revizijski vrlo vrijedna. Prisiljava projektiranje sigurnosnog kopiranja da odražava poslovni utjecaj, a ne praktičnost pohrane.

5. dan: Testirati jedan put oporavka i otvoriti korektivne radnje

Ne testirajte sve odjednom. Odaberite jednu kritičnu uslugu i provedite usmjereni test oporavka. Vratite bazu podataka. Ponovno izgradite konfiguraciju aplikacije. Provjerite autentifikaciju. Potvrdite da su zapisi dnevnika dostupni. Provjerite sposobnost obavještavanja klijenata. Zabilježite utrošeno vrijeme, gubitak podataka, nedostatke, odluke i korektivne radnje.

U Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, faza Controls in Action, korak 23, obrađuje organizacijske kontrole uključujući IKT spremnost za neprekidnost poslovanja. Postavlja pitanje koje bi svaki revizijski tim trebao postaviti:

Mogu li vaši sustavi podržati ciljeve neprekidnosti poslovanja kada svjetla zatrepere, kada mreže padnu, kada nastupi katastrofa?

Isti korak daje praktičnu uputu:

Provjerite jesu li ciljevi vremena oporavka (RTO) i ciljevi točke oporavka (RPO) za kritične sustave usklađeni s očekivanjima neprekidnosti poslovanja (5.30). Provedite najmanje jedan tehnički test oporavka ili simulaciju prebacivanja na pričuvni sustav i dokumentirajte rezultate.

To je razlika između posjedovanja BIA-e i posjedovanja dokazivih dokaza BIA-e. Cilj nije samo dokumentiran. On je testiran.

Mapiranje dokaza BIA-e na NIS2, DORA, GDPR, NIST i COBIT 2019

Dobro izgrađena BIA postaje imovina za usklađenost kroz više okvira. Jedan skup dokaza može odgovoriti na mnoga pitanja.

GDPR se često previđa u raspravama o BIA-i. Ipak, GDPR Article 5 zahtijeva da se osobni podaci obrađuju uz cjelovitost i povjerljivost, uključujući zaštitu od slučajnog gubitka, uništenja ili oštećenja primjenom odgovarajućih tehničkih ili organizacijskih mjera. Odgovornost zahtijeva da voditelj obrade može dokazati usklađenost. Ako se platforma osobnih podataka ne može obnoviti u odobrenom i testiranom roku, rizik privatnosti utječe na dostupnost, cjelovitost, procjenu povrede i povjerenje klijenata.

Prijavljivanje incidenata prema NIS2 dodaje još jednu dimenziju. Article 23 zahtijeva da se značajni incidenti prijave bez nepotrebnog odgađanja, uključujući rano upozorenje u roku od 24 sata, prijavu incidenta u roku od 72 sata i završno izvješće u roku od jednog mjeseca. BIA pomaže klasificirati ozbiljnost jer definira pogođene usluge, primatelje usluga, operativni prekid i mogući prekogranični utjecaj.

Klasifikacija incidenata prema DORA također uzima u obzir pogođene klijente ili transakcije, trajanje, geografsku rasprostranjenost, gubitke podataka, kritičnost pogođenih usluga i ekonomski utjecaj. To su BIA polja. Ako je BIA slaba, klasifikacija incidenta postaje subjektivna u najgorem mogućem trenutku.

Neprekidnost poslovanja dobavljača mjesto je susreta BIA-e i ugovorne stvarnosti

Za NIS2 i DORA neprekidnost poslovanja dobavljača više nije opcionalna. NIS2 Article 21 uključuje sigurnost opskrbnog lanca i zahtijeva pozornost na ranjivosti dobavljača, kvalitetu i otpornost proizvoda, prakse kibernetičke sigurnosti dobavljača i postupke sigurnog razvoja. DORA zahtijeva upravljanje IKT rizikom trećih strana unutar okvira za upravljanje IKT rizicima, uključujući registre ugovora o IKT uslugama, dubinsku analizu dobavljača, rizik koncentracije, izlazne strategije, prava na reviziju i pristup, pomoć pri incidentima, razine usluga i zahtjeve za planiranje kontinuiteta.

Korporativna Politika neprekidnosti poslovanja i oporavka od katastrofe zahtijeva:

Ovisnosti o trećim stranama i opskrbnom lancu 6.5.1. Ugovori s kritičnim dobavljačima moraju uključivati obveze neprekidnosti poslovanja i obveze u pogledu vremena oporavka. 6.5.2. Ključni pružatelji usluga moraju, na zahtjev, dokazati periodično testiranje neprekidnosti poslovanja i sudjelovanje u vježbama incidenata.

Verzija za SME također zahtijeva:

kontaktne točke dobavljača za neprekidnost poslovanja

To malo polje može biti presudno u stvarnom incidentu. Ako vaš plan oporavka kaže „kontaktirati podršku pružatelja usluge u oblaku”, ali nitko ne zna put eskalacije, referencu ugovora, postupak po ozbiljnosti ili kontakt izvan radnog vremena, RTO je fikcija.

Ova tablica ne zamjenjuje upravljanje rizicima dobavljača. Ona rizik dobavljača čini operativnim.

Kako će revizori testirati vašu BIA-u

Revizor ISO/IEC 27001:2022 obično će početi s opsegom, kontekstom, procjenom rizika, obradom rizika, Izjavom o primjenjivosti, kontrolama iz Priloga A, dokumentiranim informacijama, operativnim planiranjem, vrednovanjem uspješnosti i poboljšanjem. Usporedit će BIA-u s procjenom rizika i SoA. Ako su uključene A.5.30, A.5.29 ili A.8.13, tražit će dokaze o implementaciji i testiranju.

Pregledavatelj prema DORA usredotočit će se na kritične ili važne funkcije, IKT imovinu, ovisnosti o IKT trećim stranama, testiranje otpornosti, klasifikaciju incidenata, ugovorne zahtjeve, izlazne strategije i nadzor upravljačkog tijela. Očekivat će da je BIA usklađena s okvirom upravljanja IKT rizicima, strategijom digitalne operativne otpornosti, IKT planovima neprekidnosti poslovanja, planovima odgovora i oporavka te programom testiranja.

Nadzorno tijelo prema NIS2 tražit će mjere neprekidnosti poslovanja, upravljanje sigurnosnim kopiranjem, oporavak od katastrofe, krizno upravljanje, sigurnost opskrbnog lanca, odobrenje uprave i sposobnost prijavljivanja značajnih incidenata. BIA treba dokazati da se te mjere temelje na utjecaju na usluge i odobrenim prioritetima.

Procjenitelj prema NIST CSF 2.0 pitat će kako BIA informira Current Profile, Target Profile, analizu praznina i akcijski plan. Promatrat će ishode Govern za odluke povezane s pravnim, regulatornim i ugovornim zahtjevima, rizikom, ulogama, politikama, nadzorom i rizikom dobavljača. Također će ispitati ishode Identify, Protect, Detect, Respond i Recover.

Revizor u stilu COBIT 2019 ili ISACA obično će se usredotočiti na upravljanje. Tko je vlasnik usluge? Tko je prihvatio rizik? Jesu li ciljevi usklađeni s ciljevima organizacije? Prate li se dobavljači? Jesu li koristi, rizik i resursi uravnoteženi? Prate li se korektivne radnje do zatvaranja?

Clarysecova Politika praćenja revizije i usklađenosti Politika praćenja revizije i usklađenosti čini BIA-u dijelom ciklusa planiranja revizije:

Plan revizije temeljen na riziku mora se izraditi i odobriti jednom godišnje, uzimajući u obzir: 5.2.1 rezultate najnovijih procjena rizika i analize utjecaja na poslovanje (BIA) 5.2.2 prethodne nalaze revizije i status korektivnih radnji 5.2.3 promjene u procesima, IKT infrastrukturi, sustavima ili dobavljačima 5.2.4 vanjske obveze kao što su DORA Article 25 ili ugovori s klijentima

To je korak zrelosti koji mnoge organizacije propuštaju. BIA ne smije stajati izvan funkcije osiguranja. Treba usmjeravati plan revizije.

Česti nedostaci BIA-e pronađeni u stvarnim procjenama

Iste se slabosti ponavljaju.

Prvo, BIA navodi aplikacije, a ne usluge. Klijentima i regulatorima važan je prekid usluge. Aplikacije su važne zato što podržavaju te usluge.

Drugo, ciljevi RTO i RPO prepisuju se iz predložaka. Četverosatni RTO može zvučati razumno dok test vraćanja ne pokaže da je potrebno devet sati za ponovnu izgradnju integracije identiteta, oporavak konfiguracije, vraćanje podataka, provjeru cjelovitosti i ponovno omogućavanje praćenja.

Treće, sigurnosne kopije nisu povezane s poslovnim utjecajem. Učestalost, zadržavanje, šifriranje, lokacija pohrane, prioritet vraćanja i testiranje moraju odražavati odobrene ciljeve oporavka.

Četvrto, dobavljači se tretiraju kao stavke upitnika, a ne kao ovisnosti oporavka. Obveze dobavljača u pogledu neprekidnosti poslovanja, kontakti za eskalaciju, dokazi oporavka i sudjelovanje u vježbama incidenata trebaju biti povezani s kritičnim uslugama.

Peto, nedostaje odobrenje uprave. Prema NIS2 i DORA odgovornost uprave izričita je. Prema ISO/IEC 27001:2022 vodstvo, uloge, odobrenje vlasnika rizika i izvješćivanje o učinkovitosti temeljni su zahtjevi.

Šesto, testiranje je preusko. Vraćanje jedne datoteke korisno je, ali ne dokazuje oporavak usluge. Put oporavka kritične usluge može uključivati DNS, identitet, tajne vrijednosti, infrastrukturu kao kod, API pristupnike, praćenje, zapisivanje događaja, eskalaciju dobavljaču, komunikaciju s klijentima i pregled privatnosti.

Zenith Blueprint, u fazi Controls in Action, korak 19, sažima revizijsko očekivanje za sigurnosne kopije:

Testirate li svoje sigurnosne kopije?

Odgovor mora biti „da, uz dokaze”, a ti se dokazi moraju povezati natrag s BIA-om.

Paket dokaza BIA-e spreman za reviziju

Praktičan BIA program treba proizvesti sažet paket dokaza koji se može koristiti za revizije, dubinsku analizu klijenata, izvješćivanje upravi i poboljšanje otpornosti.

Ovaj paket priča koherentnu priču. Također čini otpornost mjerljivom.

Sljedeći korak: pretvorite svoju BIA-u u dokaze usklađenosti

Maria ne treba veću proračunsku tablicu. Treba joj živi lanac dokaza.

Počnite s jednom kritičnom uslugom. Mapirajte njezinu IKT imovinu, podatke, osobe, dobavljače i infrastrukturne usluge. Odobrite MTD, RTO i RPO. Uskladite raspored sigurnosnog kopiranja. Provjerite obveze dobavljača u pogledu oporavka. Provedite jedan test oporavka. Zabilježite praznine. Ažurirajte plan obrade rizika. Predstavite rezultat upravi.

Zatim ponovite.

Clarysec može ubrzati taj proces korištenjem Politike neprekidnosti poslovanja i oporavka od katastrofe, Politike neprekidnosti poslovanja i oporavka od katastrofe - SME, Politike sigurnosnog kopiranja i vraćanja podataka, Politike praćenja revizije i usklađenosti, Zenith Blueprint i Zenith Controls.

Vaša BIA ne smije biti dokument koji stoji na polici i izrađen je radi revizije. Treba biti operativni dokaz da vaše najvažnije usluge mogu preživjeti prekid, ispuniti očekivanja klijenata i regulatora te se oporaviti unutar granica koje je vaše vodstvo stvarno odobrilo.

Ako se vaša organizacija priprema za nadzornu reviziju ISO/IEC 27001:2022, potvrđivanje sigurnosti prema zahtjevima klijenata u kontekstu NIS2, preglede IKT trećih strana prema DORA ili izvješćivanje o otpornosti na razini uprave, počnite tako da BIA-u učinite dokazivom. Preuzmite Clarysec politike neprekidnosti poslovanja i revizije, pregledajte Zenith plan implementacije ili zatražite procjenu dokaza otpornosti kako biste raspršene kontrole pretvorili u jedinstvenu priču spremnu za reviziju.