ISO 27001 oporavak podataka: usklađenost i revizijska spremnost

Za usklađenost s ISO/IEC 27001:2022 morate imati dokumentiranu politiku sigurnosnog kopiranja povezanu s procjenom utjecaja na poslovanje (BIA) i dokaze o redovitim testovima vraćanja. Revizor traži tri stvari: Izjavu o primjenjivosti (SoA), definirane ciljeve RTO i RPO te zapisnike testova vraćanja s datumom, opsegom i rezultatom.

Tri kontrole nose najveću težinu u ovom području. Kontrola 8.13 odnosi se na sigurnosno kopiranje informacija, 5.29 na sigurnost informacija tijekom poremećaja, a 5.30 na spremnost ICT sustava za kontinuitet poslovanja. Sve tri zajedno čine ono što Clarysecov vodič za operativnu otpornost naziva stupovima otpornosti organizacije, a ne samo tehničkim detaljem u prilogu norme.

Dokazi koje revizor traži nisu apstraktni. Konkretno, priprema za reviziju treba sadržavati:

  • SoA s obrazloženjem zašto su 8.13, 5.29 i 5.30 primjenjive kontrole za vašu organizaciju
  • BIA koji povezuje kritične poslovne procese s maksimalno dopuštenim vremenom nedostupnosti
  • Zapisnike testova vraćanja s datumom, korištenom kopijom podataka i ostvarenim rezultatom
  • Dokumentirane RTO/RPO vrijednosti po sustavu, ne generički broj za cijelu organizaciju

Profesionalni savjet: Ako revizija dolazi za manje od mjesec dana, prioritet dajte trima stvarima odmah: provjerite kada je zadnji put stvarno testirano vraćanje podataka (ne samo backup), provjerite postoji li barem jedna imutabilna ili offline kopija izvan dosega administratorskih računa, i zapišite RTO/RPO za svaki kritični sustav ako to još nije učinjeno.

Ključne spoznaje

Usklađenost s ISO/IEC 27001:2022 u domeni oporavka podataka zahtijeva dokumentiranu politiku sigurnosnog kopiranja, testirane RTO/RPO ciljeve i zapisnike stvarnog vraćanja koji izdrže revizijsku provjeru.

Sadržaj

Kako dokumentirati testiranje vraćanja podataka za reviziju

Revizor ne traži dokaz da backup postoji. Traži dokaz da je vraćanje podataka iz tog backupa stvarno isprobano i da je rezultat zapisan. Clarysecov vodič o testiranju vraćanja jasno postavlja standard: zapisnik testa mora sadržavati opseg testa, ciljne vrijednosti RTO/RPO, stvarno postignute vrijednosti i eventualne korektivne radnje.

Postupak izrade dokumentacije koja prolazi reviziju izgleda kroz sljedeće korake:

  1. Provedite BIA za svaki kritični poslovni proces. Odredite maksimalno dopušteno vrijeme nedostupnosti (RTO) i maksimalni dopušteni gubitak podataka izražen u vremenu (RPO). Ove vrijednosti moraju biti specifične za sustav, ne generičke za cijelu organizaciju.
  2. Prenesite RTO/RPO vrijednosti u SoA. Izjava o primjenjivosti treba referencirati konkretne ciljeve, ne samo tvrdnju da “backup postoji”.
  3. Definirajte frekvenciju testiranja prema kritičnosti sustava. Sustavi visoke kritičnosti (ERP, financijske baze, sustavi za obradu narudžbi) trebaju se testirati redovito i često, primjerice nekoliko puta godišnje. Manje kritični sustavi mogu se testirati polugodišnje ili godišnje.
  4. Provedite test vraćanja u izoliranom okruženju. Vraćanje na produkcijski sustav nosi rizik i rijetko je prihvatljivo revizoru kao čist dokaz, jer se ne može razlikovati što je rezultat testa a što postojeće stanje.
  5. Zapišite rezultat odmah, ne retroaktivno. Revizori prepoznaju zapisnike koji su naknadno “rekonstruirani” jer nedostaju vremenske oznake ili su svi datirani istog dana.
  6. Ako test nije prošao, dokumentirajte korektivnu radnju i rok za ponovni test. Neuspjeli test s planom popravka je bolji dokaz zrelosti sustava nego odsutnost bilo kakvog testa.

Predložak zapisa testiranja vraćanja treba sadržavati sljedeća polja:

PoljeSadržaj
Datum i vrijeme testaTočan termin izvođenja, ne raspon dana
Testirani sustav i opsegNaziv sustava, verzija podataka, izolirano ili produkcijsko okruženje
Ciljni RTO/RPOVrijednosti definirane u BIA za taj sustav
Ostvareni RTO/RPOStvarno mjereno vrijeme oporavka i gubitka podataka
Rezultat testaUspješno, djelomično uspješno ili neuspješno, s obrazloženjem
Korektivne radnjeKonkretni koraci i rok za ponovni test ako je potrebno
Odgovorna osobaIme i uloga osobe koja je provela i potvrdila test

Ovaj format rješava najčešći propust: zapisnik koji samo kaže “backup uspješno vraćen” bez brojki. Bez mjerljivog RTO/RPO rezultata, revizor nema temelj za procjenu je li kontrola 5.30 stvarno zadovoljena.

Arhitektura backup sustava: separacija i imutabilnost kao standard

Tehnička arhitektura backup rješenja izravno utječe na to koliko brzo i pouzdano možete zadovoljiti kontrolu 8.13 nakon stvarnog incidenta. Standardno 3-2-1 pravilo, tri kopije podataka, na dva različita medija, s jednom kopijom izvan lokacije, ostaje polazna točka, ali danas se smatra nedovoljnim samostalno. Preporuke za kontrolu 8.13 dodaju zahtjev za imutabilnom kopijom, verzijom koju ni administrator s punim pristupom ne može izmijeniti ili obrisati unutar definiranog razdoblja.

Razlog je jednostavan: ransomware napadi danas ciljano traže i brišu backup sustave prije nego što šifriraju produkcijske podatke. Ako je vaša kopija dostupna preko istih administratorskih vjerodajnica kao i produkcijski sustav, napadač koji preuzme te vjerodajnice briše i backup. Objekt zaključavanje (object lock) ili offline kopija odvojena od mreže rješava taj problem jer onemogućuje brisanje unutar zadanog perioda čak i uz kompromitirane administratorske ovlasti.

Tri praktične mjere za arhitekturu koja podržava usklađenost:

  • Backup platforma mora biti logički odvojena od produkcijske domene, s posebnim skupom vjerodajnica koje se ne poklapaju s administratorskim pristupom produkciji
  • Upravljanje ključevima za enkriptirane kopije treba biti dokumentirano odvojeno, uz jasno definirano tko ima pristup ključevima i pod kojim uvjetima
  • Svaka promjena backup konfiguracije (retencija, raspored, ciljna lokacija) mora ostaviti trag u evidenciji promjena s vremenskom oznakom i identitetom osobe koja je izmjenu provela

Profesionalni savjet: Postavite pravilo da nijedna promjena backup rasporeda ne stupa na snagu bez odobrenja druge osobe, čak i u malim IT timovima. Ta jedna kontrola sprječava i grešku i zlonamjernu izmjenu, a revizoru je lako provjerljiva kroz evidenciju promjena.

Kada je enkripcija dio arhitekture, upravljanje ključevima postaje kritična točka. Podaci koji su enkriptirani bez dostupnog i sigurno pohranjenog ključa jednostavno nisu oporavljivi, a to je jedan od najčešćih razloga zašto enkriptirani podaci ostaju trajno nedostupni i nakon uspješnog vraćanja iz backupa.

Usklađenost backup politika s GDPR-om i pravilima zadržavanja

Sigurnosne kopije osobnih podataka nose specifičan pravni rizik koji često promakne IT timovima fokusiranima samo na tehničku stranu oporavka. Backup koji tehnički radi savršeno, ali sadrži osobne podatke duže nego što to dopušta vaša politika zadržavanja, postaje izvor izloženosti prema GDPR-u, a ne predstavlja dokaz usklađenosti.

Retencijska politika mora se primjenjivati i na backup skup, ne samo na produkcijske baze. Ako je politika zadržavanja podataka klijenta definirana na tri godine od zadnje transakcije, backup kopije s podacima starijim od tog roka moraju biti obuhvaćene istim ciklusom brisanja. U praksi to znači:

  • Definirajte retencijski period za backup odvojeno za svaku kategoriju podataka, usklađeno s pravnom osnovom obrade
  • Automatizirajte rotaciju i brisanje starih backup kopija umjesto ručnog praćenja rokova
  • Dokumentirajte svaku iznimku od standardne retencije, primjerice kada je podatak pod pravnom zadrškom (legal hold) zbog spora ili istrage
  • Vodite zapis o tome kada je i kako podatak stvarno obrisan iz backup skupa, ne samo iz produkcije

Legal hold zahtijeva posebnu pažnju jer privremeno suspendira normalnu retenciju. Kada je sustav pod pravnom zadrškom, backup s tim podacima ne smije biti obrisan po standardnom rasporedu, ali ta iznimka mora biti eksplicitno dokumentirana s razlogom i očekivanim datumom ukidanja zadrške. Bez tog zapisa, revizor ne može razlikovati namjernu iznimku od propusta u provedbi politike.

Najčešća greška je zadržavanje backup kopija “zauvijek”, jer je jeftinije ne brisati ništa nego uspostaviti proces brisanja. To rješava kratkoročni tehnički problem, ali stvara dugoročni pravni rizik: predugo zadržani osobni podaci u backupu koji nitko aktivno ne prati postaju upravo onaj scenarij koji GDPR nadzorna tijela penaliziraju kada dođe do curenja podataka.

Kako isti dokazi zadovoljavaju DORA i NIS2 zahtjeve

Organizacije koje već ispunjavaju ISO 27001 zahtjeve za testiranje vraćanja imaju veći dio posla za DORA i NIS2 gotov, uz manje dodatne dokumentacije nego što se obično pretpostavlja. Za financijske subjekte DORA traži testiranje digitalne operativne otpornosti na razini usluge, ne samo na razini pojedinog servera, dok NIS2 postavlja slične zahtjeve za operatore kritičnih usluga.

Ključna razlika je opseg testa. ISO 27001 test vraćanja obično dokazuje da se sustav X može vratiti unutar RTO od Y sati. DORA i NIS2 traže da se dokaže da je usluga dostupna korisniku unutar tog vremena, što uključuje i ovisnosti o trećim stranama i dobavljačima.

Element izvještajaISO 27001DORA / NIS2 dodatak
RTO/RPO po sustavuObaveznoObavezno, uz agregaciju na razini usluge
Zapisnik testa vraćanjaObaveznoObavezno, uz vezu na incidentni scenarij
Popis kritičnih dobavljačaNije izravno traženoObavezno mapiranje ovisnosti o trećim stranama
Koordinacija s poslovnim timovimaPreporučenoObavezno dokumentirati odgovornost

Praktičan primjer skaliranja: ako ste testirali vraćanje baze podataka za interni ERP sustav prema ISO 27001 zahtjevima, DORA dodatak traži da isti test uključi i provjeru je li usluga koja se na tom ERP-u temelji dostupna klijentu, te je li dobavljač cloud infrastrukture (ako postoji) uključen u scenarij testa.

Najveći praktični savjet za timove koji rade paralelno na više regulatornih okvira: uspostavite jedan zajednički predložak zapisa testiranja koji sadrži sva polja potrebna za sva tri okvira, umjesto da compliance i IT timovi vode odvojenu dokumentaciju. Koordinacijski sastanak između compliance tima i IT operacija prije svakog planiranog testa štedi vrijeme i osigurava da rezultat testa odmah zadovoljava sve primjenjive zahtjeve.

Najčešće revizijske primjedbe i kako ih ispraviti

Većina primjedbi koje revizori upisuju u vezi s backupom i oporavkom ponavlja se kroz iste obrasce, bez obzira na veličinu organizacije.

Najčešća primjedba je nedostatak dokaza o testiranju, uz postojanje same politike backupa. Organizacija ima lijepo napisan dokument, ali nijedan zapisnik koji dokazuje da je vraćanje ikad stvarno isprobano. Rješenje je jednostavno u teoriji, teško u praksi: uspostaviti raspored testiranja i držati ga se, počevši od najkritičnijih sustava.

Druga česta zamka je RTO/RPO definiran generički za cijelu organizaciju, umjesto po sustavu. Revizor prepoznaje ovo odmah, jer je nerealno da svaki sustav, od e-mail poslužitelja do ERP baze, ima identično vrijeme oporavka.

Korektivne radnje (CAPA zapisi) vezane uz neuspjele testove vraćanja trebaju sadržavati:

  • Opis što je konkretno zapelo tijekom testa (predugo vrijeme, oštećena kopija, nedostupan ključ enkripcije)
  • Rok do kojeg se problem mora riješiti
  • Osobu odgovornu za provedbu popravka
  • Datum ponovnog testiranja nakon primijenjene korekcije

Profesionalni savjet: Odmah nakon stvarnog incidenta, prije nego što krenete u puni oporavak, izradite kopiju trenutnog stanja oštećenog medija ili sustava. To sprječava da pokušaj hitnog vraćanja dodatno ošteti izvorne podatke i čuva dokaz za internu istragu ili osiguravajuće društvo.

Kada backup sustav sam pokaže znakove kompromitacije, primjerice enkriptirane kopije zbog ransomware napada koji je pogodio i backup poslužitelj, hitni vodič za oporavak nakon ransomware napada opisuje korake koji smanjuju štetu prije nego što se pozove specijalizirana pomoć.

Kada pozvati laboratorij za spašavanje podataka

Postoje trenuci kada interni IT tim, koliko god dobro dokumentirao politike i testove, treba vanjsku stručnu intervenciju. Prepoznavanje tog trenutka na vrijeme čuva podatke koje bi daljnji pokušaji samostalnog vraćanja mogli trajno oštetiti.

Jasni signali za hitan kontakt s laboratorijem:

  • RAID polje postaje nečitljivo ili se prijavljuje kao degradirano nakon više istovremenih kvarova diskova
  • Disk proizvodi neobične zvukove (klikanje, škripanje) što upućuje na mehaničko oštećenje glave za čitanje ili podatkovnih ploča
  • Ransomware je pogodio i produkcijski sustav i backup kopije, a nema čiste kopije za vraćanje
  • Pokušaj samostalnog vraćanja podataka softverskim alatom je već doveo do djelomičnog gubitka ili prepisivanja podataka

Prije slanja uređaja u laboratorij, korisno je pripremiti kratak opis kronologije kvara (kada je uočen problem, koje su radnje poduzete prije javljanja) i naznačiti poslovni prioritet oporavka, jer to određuje redoslijed obrade slučaja.

Datarecovery je jedini laboratorij u regiji certificiran prema ISO 9001:2015, radi u čistim sobama i primjenjuje forenzičke metode rada koje čuvaju integritet podataka tijekom cijelog postupka. Za organizacije koje razmišljaju o samostalnom pokušaju spašavanja podataka, vrijedi znati da neispravan pokušaj kod kuće često pretvara rješiv slučaj u trajni gubitak.

Kako izraditi plan oporavka podataka korak po korak

Izrada funkcionalnog plana oporavka podataka (Disaster Recovery Plan) počinje popisom svih kritičnih sustava i njihovih međuovisnosti, a ne pisanjem dokumenta od nule.

Praktičan slijed izgleda ovako: prvo se identificiraju svi sustavi koji podržavaju ključne poslovne procese, uz njihove tehničke i podatkovne ovisnosti (baza podataka koja ovisi o autentifikacijskom serveru, na primjer). Zatim se za svaki sustav definira RTO i RPO na temelju BIA analize, ne proizvoljno.

Sljedeći korak je definiranje uloga i odgovornosti: tko pokreće plan, tko odlučuje o proglašenju incidenta, tko komunicira s klijentima i regulatorima. Bez ove strukture, plan postoji na papiru, ali se raspada pod stresom stvarnog incidenta jer nitko ne zna tko odlučuje.

Plan zatim mora sadržavati konkretne tehničke korake vraćanja za svaki kritični sustav: gdje se nalazi backup, koje vjerodajnice su potrebne za pristup, koji redoslijed vraćanja sustava osigurava da ovisnosti budu zadovoljene (autentifikacijski server prije aplikacije koja se na njega oslanja, na primjer).

Zadnji, često zanemaren korak je redovito testiranje i ažuriranje plana. Plan napisan prije dvije godine, bez ažuriranja nakon promjene infrastrukture, gotovo je jednako beskoristan kao da plan ne postoji. Organizacije s velikim brojem sustava i kompleksnim okruženjima često trebaju strukturiran pristup pisanju backup politika koji povezuje IT timove, pravnu službu i poslovne dionike u jedinstven proces.

Zašto je procjena rizika temelj svakog plana oporavka

Procjena rizika određuje gdje uložiti ograničene resurse za oporavak podataka, umjesto da se svi sustavi tretiraju kao jednako važni. Bez ove procjene, organizacije često rasipaju budžet na zaštitu manje kritičnih sustava dok ostavljaju stvarno kritične procese nedovoljno pokrivene.

Procjena rizika u kontekstu oporavka podataka odgovara na tri pitanja: koja je vjerojatnost gubitka podataka za svaki sustav, koja je posljedica ako se to dogodi, i koliko brzo mora doći do vraćanja da se posljedica ograniči. Ta procjena izravno hrani BIA analizu i, kroz nju, RTO/RPO vrijednosti.

Rizici koje treba posebno razmotriti uključuju hardverski kvar (diskovi, RAID kontroleri), ljudsku pogrešku (slučajno brisanje, pogrešna konfiguracija), zlonamjeran napad (ransomware, sabotaža od strane insajdera) i vanjske događaje (poplava, požar u podatkovnom centru). Svaki od ovih rizika nosi drugačiji profil vjerojatnosti i drugačiji zahtjev za vrstom zaštite. Ransomware, na primjer, traži imutabilne kopije koje fizički kvar diska ne bi zahtijevao u istoj mjeri.

Procjena rizika nije jednokratan zadatak. Nova aplikacija, promjena infrastrukture ili novi regulatorni zahtjev mijenjaju profil rizika, a plan oporavka koji se ne ažurira u skladu s tim postaje sve manje precizan alat za stvarnu zaštitu. Organizacije koje procjenu rizika provode godišnje, umjesto ad hoc, imaju bolju osnovu za obranu svojih RTO/RPO vrijednosti pred revizorom.

Integracija oporavka podataka s planom kontinuiteta poslovanja

Plan oporavka podataka i plan kontinuiteta poslovanja (BCP) nisu isti dokument, ali moraju biti čvrsto povezani. BCP opisuje kako organizacija nastavlja funkcionirati tijekom i nakon poremećaja, na razini cijelog poslovanja, uključujući ljude, lokacije i procese koji nisu isključivo tehnički. Plan oporavka podataka je tehnička komponenta koja BCP-u omogućuje da uopće funkcionira kada je infrastruktura pogođena.

Integracija znači da RTO i RPO vrijednosti definirane za tehničke sustave moraju odgovarati vremenskim okvirima koje BCP obećava poslovnim dionicima i klijentima. Ako BCP tvrdi da će usluga korisničke podrške biti dostupna unutar dva sata od incidenta, ali plan oporavka podataka za sustav koji tu podršku pokreće definira RTO od osam sati, ta dva dokumenta su u sukobu, i revizor će to prepoznati.

Praktičan način provjere integracije je zajedničko testiranje: umjesto da IT tim testira tehničko vraćanje odvojeno od vježbe kontinuiteta poslovanja, kombinirana vježba provjerava i tehnički oporavak i poslovnu sposobnost nastavka rada istovremeno. To otkriva rupe koje se ne vide kada se testovi provode izolirano, primjerice da je tehnički sustav vraćen unutar RTO-a, ali osoblje koje treba nastaviti rad na tom sustavu nema pristupne podatke ili upute.

Kontrola 5.30 iz ISO/IEC 27001:2022 upravo traži ovu vrstu poveznice: ICT infrastruktura mora biti spremna podržati poslovni kontinuitet, ne postojati kao odvojen tehnički projekt. Organizacije koje BCP i plan oporavka podataka razvijaju u istom timu, s istim vlasnikom procesa, rjeđe imaju ovaj tip revizijske primjedbe.

Najbolje prakse za sigurnosne kopije prema ISO 27001

Nekoliko praksi konzistentno razlikuje organizacije koje prolaze reviziju bez primjedbi od onih koje ne prolaze, bez obzira na veličinu ili industriju.

Prva je jasno vlasništvo: svaki backup sustav ima imenovanu osobu odgovornu za njegovo funkcioniranje, ne generički “IT odjel”. Druga je redovita rotacija testiranja: umjesto testiranja svih sustava jednom godišnje u istom tjednu, kritični sustavi se testiraju kvartalno, a manje kritični prema unaprijed definiranom rasporedu koji se stvarno poštuje.

Treća praksa je odvajanje backup okruženja od produkcijske mreže, kako je opisano u arhitektonskim preporukama za kontrolu 8.13. Četvrta je dokumentiranje svake promjene backup konfiguracije, jer neprijavljena promjena rasporeda kopiranja jedan je od najčešćih razloga zašto se otkriva da backup nekoliko tjedana nije radio ispravno.

Peta praksa, često podcijenjena, je redovita provjera integriteta backup medija, ne samo provjera da je proces kopiranja “završen bez greške”. Datoteka backupa može biti tehnički kompletna, ali oštećena na način koji se otkriva samo pokušajem stvarnog vraćanja.

Šesta praksa odnosi se na obuku osoblja: osoba koja provodi test vraćanja treba jasnu proceduru, ne improvizaciju pod pritiskom. Organizacije koje svaki test tretiraju kao priliku za usavršavanje procedure, ne samo kao formalnost za revizora, dugoročno smanjuju vrijeme stvarnog oporavka tijekom prave krize.

Tehnologije koje podržavaju usklađenost u oporavku podataka

Tehnički alati koji podržavaju usklađenost s ISO 27001 u domeni oporavka podataka dijele se u nekoliko kategorija, svaka s drugačijom ulogom u dokazivanju spremnosti.

Sustavi za upravljanje backup rasporedom i verzioniranjem omogućuju automatsku rotaciju kopija i primjenu retencijskih politika bez ručne intervencije, što smanjuje rizik od ljudske pogreške u brisanju ili čuvanju podataka. Tehnologija imutabilnog spremanja (object lock) sprječava brisanje ili izmjenu kopije unutar definiranog razdoblja, čak i uz kompromitirane administratorske vjerodajnice, što je izravan odgovor na ransomware scenarije.

Alati za enkripciju i upravljanje ključevima štite sadržaj backupa tijekom prijenosa i pohrane, ali zahtijevaju odvojenu, dobro dokumentiranu proceduru pristupa ključevima. Bez takve procedure, gubitak ključa jednako je štetan kao gubitak samog backupa.

Sustavi za praćenje i evidenciju promjena (audit logging) bilježe svaku izmjenu backup konfiguracije, uključujući promjene rasporeda, retencije ili pristupnih dozvola, i time stvaraju trag koji revizor može provjeriti bez ovisnosti o memoriji zaposlenika. Ovi zapisi postaju kritični dokaz kada revizor pita “tko je i kada promijenio ovu postavku”.

Za organizacije koje procjenjuju sigurnost šireg okruženja, uključujući i proizvodne pogone gdje se backup infrastruktura kombinira s kontrolom pristupa fizičkim sustavima, korisno je pogledati i pregled alata za kontrolu kvalitete u proizvodnji, koji ilustrira kako se slična logika evidencije promjena primjenjuje izvan čisto IT okruženja. Nijedan alat sam po sebi ne jamči usklađenost. Dokaz o poslovnoj odluci iza svake tehničke konfiguracije, povezanoj s BIA analizom, jednako je važan kao i sama tehnologija.

Kako Datarecovery podržava vašu ISO 27001 spremnost

Kada test vraćanja pokaže da backup ne radi kako je planirano, ili kada incident ošteti i produkcijski sustav i backup kopije, dokumentacija za reviziju postaje sporedna dok se ne rješi hitniji problem: stvarni gubitak podataka. Datarecovery je specijalizirani laboratorij za spašavanje podataka s hard diskova, SSD-ova, RAID polja, NAS sustava i mobilnih uređaja, s iskustvom koje datira od 1993. godine.

Datarecovery

Za razliku od pokušaja samostalnog vraćanja podataka rizičnim softverskim alatima, koji često dodatno oštete medij i smanje šanse za oporavak, Datarecovery radi u čistim sobama uz forenzičke metode koje čuvaju integritet podataka tijekom cijelog postupka. Laboratorij je jedini u regiji certificiran prema ISO 9001:2015, standardu koji potvrđuje dosljednu kvalitetu procesa, a ne samo pojedinačni uspješan slučaj. Usluge relevantne za organizacije koje pripremaju ISO 27001 reviziju uključuju spašavanje podataka s oštećenih RAID sustava, sigurno brisanje podataka s izdavanjem certifikata za potrebe retencijskih politika, IT forenziku za analizu incidenata i udaljenu tehničku podršku za hitne slučajeve.

Ako je backup sustav kompromitiran, RAID polje nečitljivo ili je sigurnosna kopija oštećena u trenutku kada vam najviše treba, prijavite gubitak podataka laboratoriju odmah, prije daljnjih pokušaja samostalnog vraćanja. Vremenski faktor odlučuje hoće li slučaj biti rješiv.

Često postavljana pitanja o ISO 27001 oporavku podataka

Koja je razlika između backupa i disaster recovery plana prema ISO 27001?

Backup je tehnički mehanizam stvaranja kopije podataka. Plan oporavka podataka je širi operativni dokument koji definira uloge, procedure i redoslijed koraka potrebnih za vraćanje cijelog sustava ili usluge nakon incidenta, uz testirane RTO/RPO ciljeve.

Koliko često treba testirati vraćanje podataka za ISO 27001 usklađenost?

Frekvencija ovisi o kritičnosti sustava definiranoj kroz BIA analizu. Kritični sustavi obično trebaju test vraćanja najmanje kvartalno, dok manje kritični sustavi mogu imati polugodišnji ili godišnji raspored testiranja.

Koje dokumente revizor najčešće traži za kontrolu 8.13?

Revizor traži Izjavu o primjenjivosti (SoA) s referencom na backup politiku, BIA analizu koja opravdava RTO/RPO vrijednosti i zapisnike stvarnih testova vraćanja s mjerljivim rezultatima, ne samo potvrdu da backup postoji.

Može li isti zapisnik testa vraćanja zadovoljiti i ISO 27001 i DORA zahtjeve?

Da, ako zapisnik sadrži sve potrebne elemente: RTO/RPO ciljeve, rezultat testa i, za DORA, dodatnu razinu detalja o dostupnosti usluge i uključenim trećim stranama, ne samo o pojedinom serveru.

Što učiniti ako se backup pokvario zajedno s produkcijskim sustavom tijekom ransomware napada?

Prvi korak je prekid daljnjeg pokušaja samostalnog vraćanja koji bi mogao dodatno oštetiti medije, i hitan kontakt sa specijaliziranim laboratorijem za spašavanje podataka koji radi u kontroliranim uvjetima čiste sobe.

Je li imutabilna kopija obavezna prema ISO 27001?

Norma ne propisuje imutabilnost kao formalni zahtjev, ali preporuke uz kontrolu 8.13 snažno je podržavaju kao tehničku mjeru protiv brisanja backupa kompromitiranim administratorskim vjerodajnicama, posebno u kontekstu ransomware napada.

Izvori

Za formalne detalje i ažuriranja norme vrijedi konzultirati izvorne dokumente, ne samo sekundarne tumačenja.

Preporučeno

Objave