Izstopne strategije DORA za IKT s kontrolami ISO 27001

V ponedeljek ob 07:42 vodja fintech operacij prejme sporočilo, ki ga nihče ne želi prebrati: ponudnik spremljanja transakcij v oblaku je utrpel resen regionalni izpad. Ob 08:15 vodja tveganj že sprašuje, ali prizadeta storitev podpira kritično ali pomembno funkcijo. Ob 08:40 želi pravna služba vedeti, ali pogodba podjetju zagotavlja pomoč pri prehodu, izvoz podatkov, izbris in pravice do revizije. Ob 09:05 CISO išče dokazila, da je bil izstopni načrt testiran, ne le napisan.

V drugem podjetju za finančne storitve Sarah, CISO hitro rastoče fintech platforme, odpre predrevizijsko zahtevo za informacije za presojo skladnosti z DORA. Vprašanja so znana, dokler ne pride do razdelka o tretjih ponudnikih storitev IKT, ki podpirajo kritične ali pomembne funkcije. Revizorji ne sprašujejo, ali ima podjetje politiko za dobavitelje. Zahtevajo dokumentirane, testirane in izvedljive izstopne strategije.

Njene misli se najprej ustavijo pri ključnem ponudniku storitev v oblaku, ki gosti platformo, nato pri ponudniku upravljanih varnostnih storitev, ki neprekinjeno spremlja grožnje. Kaj, če ponudnika storitev v oblaku prizadene geopolitična motnja? Kaj, če MSSP prevzame konkurent? Kaj, če kritični ponudnik SaaS postane insolventen, prekine storitev ali po večjem incidentu izgubi zaupanje strank?

Neprijeten odgovor je v številnih podjetjih enak. Obstajajo ocena tveganja dobavitelja, načrt neprekinjenega poslovanja, pogodbena mapa, evidenca storitev v oblaku in morda poročilo o varnostnem kopiranju. Ni pa ene same revizijsko pripravljene izstopne strategije DORA za tretje ponudnike storitev IKT, ki bi povezala poslovno kritičnost, pogodbene pravice, tehnično prenosljivost, načrte neprekinjenega poslovanja, dokazila o varnostnih kopijah, obveznosti glede zasebnosti in odobritev vodstva.

DORA spreminja pristop k upravljanju dobaviteljev. V skladu z Uredbo (EU) 2022/2554 morajo finančni subjekti upravljati tveganja tretjih ponudnikov storitev IKT kot del okvira upravljanja IKT-tveganj. Še naprej so v celoti odgovorni za skladnost, vodijo evidenco pogodb o storitvah IKT, razlikujejo ureditve IKT, ki podpirajo kritične ali pomembne funkcije, presojajo tveganja koncentracije in podizvajanja ter vzdržujejo izstopne strategije za kritične odvisnosti od tretjih ponudnikov storitev IKT. DORA se uporablja od 17. januarja 2025 in določa enotne zahteve EU za upravljanje IKT-tveganj, poročanje o incidentih, testiranje odpornosti, izmenjavo informacij in upravljanje tveganj tretjih ponudnikov storitev IKT za širok nabor finančnih subjektov.

Izstopna strategija DORA ni odstavek v dobaviteljski pogodbi. Je sistem kontrol. Mora biti upravljana, predmet ocene tveganja, tehnično izvedljiva, pogodbeno uveljavljiva, testirana, podprta z dokazili in stalno izboljševana.

Pristop Clarysec združuje Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, predloge politik za podjetja in Zenith Controls: The Cross-Compliance Guide Zenith Controls, da se ponedeljkovo jutranje vprašanje spremeni v pripravljen odgovor.

Zakaj izstopne strategije DORA padejo na dejanskih revizijah

Večina neuspehov izstopnih strategij DORA za IKT je najprej strukturnih in šele nato tehničnih. Organizacija ima skrbnika dobavitelja, nima pa imenovanega lastnika tveganja. Ima opravila varnostnega kopiranja, nima pa dokazil o obnovitvi. Ima vprašalnik za skrbni pregled dobavitelja, nima pa dokumentirane odločitve, ali ponudnik podpira kritično ali pomembno funkcijo. Ima pogodbena določila o odpovedi, nima pa prehodnega obdobja, usklajenega z načrtom neprekinjenega poslovanja.

DORA te dele povezuje. 28. člen določa splošna načela za upravljanje tveganj tretjih ponudnikov storitev IKT, vključno s potrebo po upravljanju tveganj ponudnikov storitev IKT tretjih oseb skozi celoten življenjski cikel in vzdrževanju ustreznih izstopnih strategij. 30. člen določa podrobne pogodbene zahteve za storitve IKT, ki podpirajo kritične ali pomembne funkcije, vključno z opisi storitev, lokacijami obdelave podatkov, varnostnimi zaščitnimi ukrepi, pravicami dostopa in revizije, pomočjo pri incidentih, sodelovanjem s pristojnimi organi in pravicami do odpovedi.

Ureditev je tudi sorazmerna. 4. in 16. člen nekaterim manjšim ali izvzetim subjektom omogočata uporabo poenostavljenega okvira upravljanja IKT-tveganj. Vendar poenostavljeno ne pomeni nedokumentirano. Manjši finančni subjekti še vedno potrebujejo dokumentirano upravljanje IKT-tveganj, stalno spremljanje, odporne sisteme, hitro identifikacijo incidentov IKT, identifikacijo ključnih odvisnosti od tretjih ponudnikov storitev IKT, varnostno kopiranje in obnovitev, neprekinjeno poslovanje, odziv in obnovitev, testiranje, pridobljene izkušnje in usposabljanje.

Majhen fintech ne more reči: »Premajhni smo za načrtovanje izstopa.« Lahko pa reče: »Naša izstopna strategija DORA je prilagojena naši velikosti, profilu tveganja in kompleksnosti storitve.« Razlika so dokazila.

Za subjekte, ki so zajeti tudi v nacionalno področje uporabe NIS2, DORA deluje kot sektorski pravni akt Unije za prekrivajoče se obveznosti kibernetske varnosti v finančnem sektorju. NIS2 ostaja pomembna v širšem ekosistemu, zlasti za ponudnike upravljanih storitev, ponudnike upravljanih varnostnih storitev, ponudnike storitev v oblaku, podatkovne centre in subjekte digitalne infrastrukture. 21. člen NIS2 utrjuje iste teme: analiza tveganj, obravnava incidentov, neprekinjeno poslovanje, varnost dobavne verige, varna nabava, ocenjevanje učinkovitosti, usposabljanje, kriptografija, nadzor dostopa, upravljanje sredstev in avtentikacija.

Nadzorniki, stranke, revizorji in upravni odbori lahko vprašanje zastavijo različno, vendar je osrednje vprašanje enako: ali lahko zapustite kritičnega ponudnika IKT, ne da bi izgubili nadzor nad neprekinjenim izvajanjem storitve, podatki, dokazili ali vplivom na stranke?

Izstopna strategija naj bo del ISMS

ISO/IEC 27001:2022 zagotavlja upravljavski temelj za načrtovanje izstopa po DORA.

Klavzule 4.1 do 4.4 zahtevajo, da organizacija opredeli svoj kontekst, zainteresirane strani, zakonske, regulativne in pogodbene zahteve, obseg ISMS, vmesnike, odvisnosti in procese. Tu finančni subjekt znotraj meja ISMS identificira DORA, zaveze do strank, pričakovanja glede zunanjega izvajanja, odvisnosti od oblaka, obveznosti glede zasebnosti, podizvajalce in storitve IKT.

Klavzule 5.1 do 5.3 zahtevajo voditeljstvo, politiko, vire, dodelitev vlog in odgovornosti. To je skladno z modelom upravljanja DORA, v katerem organ upravljanja opredeli, odobri, nadzoruje in ostaja odgovoren za upravljanje IKT-tveganj, vključno z neprekinjenim poslovanjem IKT, načrti odziva in obnovitve, revizijskimi načrti IKT, proračuni, strategijo odpornosti in politiko tveganj tretjih ponudnikov storitev IKT.

Klavzule 6.1.1 do 6.1.3 načrtovanje izstopa pretvorijo v obravnavo tveganja. Organizacija opredeli merila tveganja, izvaja ponovljive ocene tveganja, identificira tveganja za zaupnost, celovitost in razpoložljivost, dodeli lastnike tveganj, ovrednoti posledice in verjetnost, izbere možnosti obravnave, primerja kontrole s Prilogo A, pripravi izjavo o uporabnosti, pripravi načrt obravnave tveganj ter pridobi odobritev lastnika tveganja in sprejem preostalega tveganja.

Klavzula 8.1 nato zahteva operativno načrtovanje in nadzor. Organizacija mora načrtovati, izvajati in nadzirati procese ISMS, vzdrževati dokumentirane informacije, ki dokazujejo, da so bili procesi izvedeni po načrtu, upravljati spremembe ter nadzirati zunanje zagotovljene procese, produkte ali storitve, pomembne za ISMS.

ISO/IEC 27005:2022 ta pristop dodatno okrepi. Klavzula 6.2 organizacijam priporoča, naj identificirajo zahteve zainteresiranih strani, vključno s kontrolami iz Priloge A standarda ISO/IEC 27001:2022, sektorskimi standardi, nacionalnimi in mednarodnimi predpisi, internimi pravili, pogodbenimi zahtevami in obstoječimi kontrolami iz predhodne obravnave tveganj. Klavzule 6.4.1 do 6.4.3 pojasnjujejo, da morajo merila tveganja upoštevati zakonske in regulativne vidike, odnose z dobavitelji, zasebnost, operativne vplive, kršitve pogodb, poslovanje tretjih oseb in posledice za ugled. Klavzule 8.2 do 8.6 podpirajo katalog kontrol in načrt obravnave tveganj, ki lahko združuje Prilogo A standarda ISO/IEC 27001:2022 z DORA, NIS2, GDPR, zavezami do strank in internimi politikami.

Operativni model je preprost: en popis zahtev, en register tveganj dobaviteljev, ena izjava o uporabnosti, en načrt obravnave tveganj in en paket dokazil za vsak kritični izstopni scenarij.

Kontrole ISO/IEC 27001:2022, ki podpirajo načrtovanje izstopa po DORA

Izstopne strategije DORA postanejo revizijsko pripravljene, ko se upravljanje dobaviteljev, prenosljivost v oblaku, načrtovanje neprekinjenega poslovanja in dokazila o varnostnih kopijah obravnavajo kot povezana veriga kontrol.

Clarysec Zenith Controls preslika kontrole iz Priloge A standarda ISO/IEC 27001:2022 na atribute kontrol, revizijske dokaze in pričakovanja navzkrižne skladnosti. To ni ločen okvir kontrol. Je Clarysecov vodnik za navzkrižno skladnost, ki pojasnjuje, kako kontrole ISO/IEC 27001:2022 podpirajo revizijske, regulativne in operativne rezultate.

Za izstopno strategijo DORA za tretje ponudnike storitev IKT mora revizijska sled pokazati:

• Dobavitelj je razvrščen in povezan s poslovnimi procesi.
• Storitev je ocenjena glede podpore kritični ali pomembni funkciji.
• Izstopno tveganje je evidentirano z odgovornim lastnikom tveganja.
• Pogodbene klavzule podpirajo prehod, dostop, revizijo, vračilo podatkov, izbris podatkov, sodelovanje in neprekinjeno poslovanje.
• Prenosljivost v oblaku in interoperabilnost sta bili preverjeni.
• Varnostne kopije in testi obnovitve dokazujejo zmožnost obnovitve.
• Začasna zamenjava ali alternativna obdelava je dokumentirana.
• Rezultati testiranja izstopa so bili pregledani, pomanjkljivosti odpravljene in poročani vodstvu.

Pogodbeni jezik je prva kontrola neprekinjenega poslovanja

Pogodba mora biti prva kontrola neprekinjenega poslovanja, ne ovira zanj. Če lahko ponudnik hitro odpove storitev, zamuja z izvozi, omeji dostop do dnevnikov, zaračuna neopredeljene stroške prehoda ali zavrne podporo pri migraciji, je izstopna strategija krhka.

V Zenith Blueprint, faza Kontrole v praksi, korak 23, kontrola 5.20, pojasnjuje, da morajo dogovori z dobavitelji vključevati praktične varnostne zahteve, ki omogočajo izstop:

Ključna področja, ki jih običajno urejajo dogovori z dobavitelji, vključujejo:

✓ obveznosti glede zaupnosti, vključno z obsegom, trajanjem in omejitvami razkritij tretjim osebam;

✓ odgovornosti glede nadzora dostopa, na primer kdo lahko dostopa do vaših podatkov, kako se upravljajo poverilnice in kakšno spremljanje je vzpostavljeno;

✓ tehnične in organizacijske ukrepe za varstvo podatkov, šifriranje, varen prenos, varnostno kopiranje in zaveze glede razpoložljivosti;

✓ časovne roke in protokole za poročanje o incidentih, pogosto z opredeljenimi časovnimi okviri;

✓ pravico do revizije, vključno s pogostostjo, obsegom in dostopom do relevantnih dokazil;

✓ kontrole podizvajalcev, ki od dobavitelja zahtevajo, da enakovredne varnostne obveznosti prenese na svoje nadaljnje partnerje;

✓ določila ob izteku pogodbe, kot so vračilo ali uničenje podatkov, vračilo sredstev in deaktivacija računov.

Ta seznam povezuje pogodbena pričakovanja iz 30. člena DORA in kontrolo A.5.20 iz Priloge A standarda ISO/IEC 27001:2022.

Jezik politik Clarysec za podjetja isto zahtevo postavi operativno. V Politiki upravljanja tveganj odvisnosti od dobaviteljev Politika upravljanja tveganj odvisnosti od dobaviteljev, razdelek »Zahteve za implementacijo«, klavzula 6.4.3 določa:

Tehnični nadomestni ukrepi: zagotovite prenosljivost podatkov in interoperabilnost za podporo prehodu storitve, kadar je to potrebno (npr. redne varnostne kopije v standardnih formatih od ponudnika SaaS za omogočanje migracije).

Ista politika v klavzuli 6.8.2 zahteva:

Pravico do pomoči pri prehodu (klavzula o podpori pri izstopu), kadar je potrebna zamenjava ponudnika, vključno z nadaljevanjem storitve v opredeljenem prehodnem obdobju.

Ta klavzula pogosto odloči, ali izstopna strategija prestane revizijo. Izstop iz dogodka na robu prepada spremeni v upravljan prehod.

Za manjše subjekte Politika varnosti tretjih oseb in dobaviteljev za MSP Politika varnosti tretjih oseb in dobaviteljev za MSP, razdelek »Zahteve upravljanja«, klavzula 5.3.6, zahteva:

pogoje odpovedi, vključno z varnim vračilom ali uničenjem podatkov

Za podjetniška okolja Politika varnosti tretjih oseb in dobaviteljev Politika varnosti tretjih oseb in dobaviteljev, razdelek »Zahteve za izvajanje politike«, klavzula 6.5.1.2, zahteva:

vračilo ali certificirano uničenje vseh informacij v lasti organizacije

Te zahteve iz politik morajo biti neposredno sledljive do pogodbenih klavzul, postopkov dobavitelja, operativnih priročnikov za izstop in revizijskih dokazov.

Izstop iz oblaka: preizkusite prenosljivost, preden jo potrebujete

Storitve v oblaku so področje, kjer izstopne strategije DORA pogosto postanejo nejasne. Podjetje predpostavlja, da lahko izvozi podatke, vendar nihče ni preizkusil formata. Predpostavlja, da bo izbris izveden, vendar model hrambe ponudnika vključuje varnostne kopije in replicirano hrambo. Predpostavlja, da lahko alternativni ponudnik prejme podatke, vendar sheme, integracije identitet, šifrirni ključi, skrivnosti, dnevniki, aplikacijski programski vmesniki in omejitve hitrosti zahtevkov migracijo upočasnijo prek dopustne tolerance vpliva.

Kontrola A.5.23 iz Priloge A standarda ISO/IEC 27001:2022 obravnava ta življenjski cikel tako, da zahteva kontrole informacijske varnosti za nabavo, uporabo, upravljanje in izstop iz storitev v oblaku.

Clarysec Politika uporabe storitev v oblaku za MSP Politika uporabe storitev v oblaku za MSP, razdelek »Zahteve za izvajanje politike«, klavzula 6.3.4, zahteva:

zmožnost izvoza podatkov, potrjena pred uvajanjem (npr. za preprečevanje vezanosti na dobavitelja)

Klavzula 6.3.5 zahteva:

potrditev postopkov varnega izbrisa pred zaprtjem računa

Te zahteve sodijo na začetek življenjskega cikla dobavitelja. Ne čakajte do odpovedi, da vprašate, ali je podatke mogoče izvoziti. Ne čakajte do zaprtja računa, da vprašate, ali obstajajo dokazila o izbrisu.

Praktičen test izstopa iz oblaka po DORA mora vključevati:

1. Izvoz reprezentativnega podatkovnega niza v dogovorjenem formatu.
2. Preverjanje popolnosti, celovitosti, časovnih žigov, metapodatkov in kontrol dostopa.
3. Uvoz podatkovnega niza v pripravljalno okolje ali alternativno orodje.
4. Potrditev ravnanja s šifrirnimi ključi in menjave skrivnosti.
5. Potrditev izvoza dnevnikov in hrambe revizijske sledi.
6. Dokumentiranje postopkov izbrisa pri ponudniku, vključno s hrambo varnostnih kopij in potrdilom o izbrisu.
7. Evidentiranje težav, sanacijskih ukrepov, lastnikov in rokov.
8. Posodobitev ocene tveganja dobavitelja, izjave o uporabnosti in izstopnega načrta.

Prenosljivost ni obljuba iz nabavnega postopka. Je testirana zmogljivost.

Enotedenski sprint za revizijsko pripravljen izstopni načrt DORA

Predstavljajte si plačilno institucijo, ki uporablja ponudnika SaaS za analitiko prevar. Ponudnik zajema transakcijske podatke, identifikatorje strank, telemetrijske podatke naprav, vedenjske signale, pravila za preprečevanje prevar, rezultate točkovanja in zapiske primerov. Storitev podpira kritični proces zaznavanja prevar. Podjetje uporablja tudi podatkovno skladišče v oblaku za hrambo izvoženih analitičnih rezultatov.

CISO želi izstopno strategijo DORA za tretjega ponudnika storitev IKT, ki lahko prestane notranjo revizijo in nadzorni pregled. Enotedenski sprint lahko razkrije vrzeli in vzpostavi verigo dokazil.

1. dan: razvrstite dobavitelja in opredelite izstopni scenarij

Z uporabo Zenith Blueprint, faza Kontrole v praksi, korak 23, Akcijske točke za kontrole 5.19 do 5.37, ekipa začne s pregledom in razvrščanjem portfelja dobaviteljev:

Sestavite celovit seznam trenutnih dobaviteljev in ponudnikov storitev (5.19) ter jih razvrstite glede na dostop do sistemov, podatkov ali operativnega nadzora. Za vsakega razvrščenega dobavitelja preverite, da so varnostna pričakovanja jasno vključena v pogodbe (5.20), vključno z zaupnostjo, dostopom, poročanjem o incidentih in obveznostmi skladnosti.

Dobavitelj je razvrščen kot kritičen, ker podpira kritično ali pomembno funkcijo, obdeluje občutljive operativne podatke in vpliva na rezultate spremljanja transakcij.

Ekipa opredeli tri sprožilce izstopa:

• Insolventnost ponudnika ali prenehanje storitve.
• Bistvena varnostna kršitev ali izguba zaupanja.
• Strateška migracija za zmanjšanje tveganja koncentracije.

2. dan: vzpostavite popis zahtev in zapis tveganja

Ekipa pripravi enoten popis zahtev, ki zajema tveganja tretjih ponudnikov storitev IKT po DORA, kontrole ISO/IEC 27001:2022 za dobavitelje in oblak, obveznosti GDPR glede osebnih podatkov, pogodbene zaveze do strank in interni apetit po tveganju.

V okviru GDPR podjetje potrdi, ali se identifikatorji transakcij, ID-ji naprav, lokacijski signali in vedenjska analitika nanašajo na določene ali določljive posameznike. Načela iz 5. člena GDPR, vključno s celovitostjo, zaupnostjo, omejitvijo hrambe in odgovornostjo, postanejo del zahtev za izstopna dokazila. Če izstop vključuje prenos k novemu ponudniku, je treba dokumentirati pravno podlago, namen, minimizacijo, hrambo, pogodbena določila obdelovalca in zaščitne ukrepe.

Zapis tveganja vključuje naslednje:

3. dan: odpravite pogodbene vrzeli

Pravna služba in nabava primerjata pogodbo s Clarysecovimi klavzulami za dobavitelje. Dodajo pomoč pri prehodu, nadaljevanje storitve v opredeljenem prehodnem obdobju, dostop do revizije in dokazil, obvestila o podizvajalcih, format izvoza podatkov, potrdilo o varnem izbrisu, sodelovanje pri incidentih in zaveze glede časa obnovitve.

Politika neprekinjenega poslovanja in obnovitve po nesreči Politika neprekinjenega poslovanja in obnovitve po nesreči, razdelek »Zahteve za izvajanje politike«, klavzula 6.5.1 določa:

Pogodbe s kritičnimi dobavitelji morajo vključevati obveznosti glede neprekinjenega poslovanja in zaveze glede časa obnovitve.

Za MSP Politika neprekinjenega poslovanja in obnovitve po nesreči za MSP Politika neprekinjenega poslovanja in obnovitve po nesreči za MSP, razdelek »Obravnava tveganj in izjeme«, klavzula 7.2.1.4, od ekip zahteva, da:

dokumentirajo začasne načrte zamenjave dobavitelja ali partnerja

Ta klavzula pretvori izjavo »migrirali bomo« v izvedljiv nadomestni ukrep: kateri ponudnik, kateri interni nadomestni postopek, kateri ročni proces, kateri izvoz podatkov, kateri lastnik in katera pot odobritve.

4. dan: testirajte prenosljivost podatkov in zmožnost obnovitve iz varnostnih kopij

Tehnološka ekipa izvozi pravila za preprečevanje prevar, podatke primerov, rezultate točkovanja transakcij, dnevnike, konfiguracijo, dokumentacijo API in sezname uporabniških dostopov. Preveri, ali je podatke mogoče obnoviti ali ponovno uporabiti v nadzorovanem okolju.

Politika varnostnega kopiranja in obnove za MSP Politika varnostnega kopiranja in obnove za MSP, razdelek »Zahteve upravljanja«, klavzula 5.3.3, zahteva:

Testi obnovitve se izvajajo najmanj četrtletno, rezultati pa se dokumentirajo za preverjanje zmožnosti obnovitve

Podjetniška Politika varnostnega kopiranja in obnove Politika varnostnega kopiranja in obnove, razdelek »Uveljavljanje in skladnost«, klavzula 8.3.1, dodaja:

Periodično presojajte dnevnike varnostnega kopiranja, konfiguracijske nastavitve in rezultate testiranja

V Zenith Blueprint, faza Kontrole v praksi, korak 19, kontrola 8.13, Clarysec opozarja, zakaj je to pomembno:

Testiranje obnovitve je področje, kjer večina organizacij zaostaja. Varnostna kopija, ki je ni mogoče pravočasno ali sploh obnoviti, je breme, ne sredstvo. Načrtujte redne vaje obnovitve, tudi če so le delne, in dokumentirajte rezultat.

Ekipa ugotovi, da izvoženi zapiski primerov ne vključujejo priponk, omejitve hitrosti zahtevkov API pa polni izvoz preveč upočasnijo glede na opredeljeni cilj obnovitve. Težava se evidentira, dodeli in odpravi z aneksom k pogodbi ter tehnično prenovo izvoza.

5. dan: izvedite namizno vajo izstopa in pregled dokazil

Ekipa izvede namizno vajo: dobavitelj po večjem incidentu napove odpoved v 90 dneh. Operacije morajo nadaljevati spremljanje prevar, medtem ko se podatki migrirajo.

V Zenith Blueprint, faza Kontrole v praksi, korak 23, kontrola 5.30, Clarysec pojasnjuje standard testiranja:

Pripravljenost IKT se začne dolgo pred nastankom motnje. Vključuje identifikacijo kritičnih sistemov, razumevanje njihovih medsebojnih odvisnosti in njihovo preslikavo na poslovne procese.

Isti razdelek dodaja:

Ciljni časi obnovitve (RTO) in ciljne točke obnovitve (RPO), opredeljeni v načrtu neprekinjenega poslovanja, se morajo odražati v tehničnih konfiguracijah, pogodbah in zasnovi infrastrukture.

Paket dokazil vključuje razvrstitev dobavitelja, oceno tveganja, pogodbene klavzule, operativni priročnik za izstop, rezultate izvoza podatkov, dokazila o obnovitvi varnostnih kopij, postopek izbrisa, presojo alternativnega ponudnika, zapisnik namizne vaje, evidenco sanacijskih ukrepov, odobritev vodstva in odločitev o preostalem tveganju.

CISO lahko zdaj na vprašanje upravnega odbora odgovori z dokazili, ne z optimizmom.

Navzkrižna skladnost: en izstopni načrt, več revizijskih pogledov

Močna izstopna strategija DORA zmanjša podvajanje dela za skladnost v okviru ISO/IEC 27001:2022, NIS2, GDPR, NIST in pričakovanj upravljanja COBIT 2019.

Bistvo ni v tem, da en okvir nadomesti drugega. Vrednost je v tem, da dobro vzpostavljen ISMS organizaciji omogoča enkratno pripravo dokazil in njihovo smiselno ponovno uporabo.

Clarysec Zenith Controls ekipam pomaga pri pripravi na te revizijske poglede tako, da povezuje kontrole ISO/IEC 27001:2022 z revizijskimi dokazi in pričakovanji med okviri.

Pogosta revizijska pomanjkljivost je razdrobljenost dokazil. Skrbnik dobavitelja ima pogodbo. IT ima dnevnike varnostnega kopiranja. Pravna služba ima pogodbo o obdelavi osebnih podatkov. Funkcija tveganj ima oceno. Funkcija skladnosti ima regulativno preslikavo. Nihče nima celotne zgodbe.

Clarysec to rešuje z zasnovo paketa dokazil okoli izstopnega scenarija. Vsak dokument odgovarja na eno revizijsko vprašanje: katera storitev se opušča, zakaj je kritična, kateri podatki in sistemi so prizadeti, kdo je lastnik tveganja, katere pogodbene pravice omogočajo izstop, kateri tehnični mehanizmi omogočajo migracijo, katere ureditve neprekinjenega poslovanja ohranjajo poslovanje, kateri test dokazuje, da načrt deluje, katere pomanjkljivosti so bile odpravljene in kdo je odobril preostalo tveganje.

Kontrolni seznam Clarysec za izstopno strategijo DORA

S tem kontrolnim seznamom pretvorite izstopno strategijo DORA za tretje ponudnike storitev IKT iz dokumenta v preverljiv nabor kontrol.

Iz načrtovanja izstopa ustvarite kontrolo odpornosti za upravni odbor

Če je vaša izstopna strategija DORA le pogodbena klavzula, ni pripravljena. Če vaša varnostna kopija še nikoli ni bila obnovljena, ni pripravljena. Če lahko vaš ponudnik storitev v oblaku izvozi podatke, vendar nihče ni preveril popolnosti, ni pripravljena. Če vaš upravni odbor ne vidi odločitve o preostalem tveganju, ni pripravljena.

Clarysec pomaga CISO, vodjem skladnosti, revizorjem in lastnikom poslovanja vzpostaviti izstopne strategije DORA za tretje ponudnike storitev IKT, ki so praktične, sorazmerne in revizijsko pripravljene. Združujemo Zenith Blueprint Zenith Blueprint za zaporedje implementacije, Zenith Controls Zenith Controls za preslikavo navzkrižne skladnosti ter predloge politik, kot so Politika upravljanja tveganj odvisnosti od dobaviteljev Politika upravljanja tveganj odvisnosti od dobaviteljev, Politika uporabe storitev v oblaku za MSP Politika uporabe storitev v oblaku za MSP, Politika varnosti tretjih oseb in dobaviteljev za MSP Politika varnosti tretjih oseb in dobaviteljev za MSP in Politika neprekinjenega poslovanja in obnovitve po nesreči Politika neprekinjenega poslovanja in obnovitve po nesreči, da ustvarimo celovito verigo od kontrol do dokazil.

Vaš naslednji korak je preprost in zelo koristen: ta teden izberite enega kritičnega dobavitelja IKT. Razvrstite ga, preglejte njegovo pogodbo, testirajte en izvoz podatkov, preverite eno obnovitev, dokumentirajte en načrt zamenjave in ustvarite en paket dokazil.

Ta ena vaja bo pokazala, ali je vaša izstopna strategija DORA dejanska zmožnost odpornosti ali le dokument, ki bo padel pri reviziji.