Presoji pripravljena ocena tveganj ISO 27001 za NIS2 in DORA

Kava na Sarahini mizi je bila hladna.

Kot vodja informacijske varnosti (CISO) v hitro rastočem fintech podjetju je bila vajena pritiska. Podjetje je pravkar pridobilo pomembnega bančnega partnerja, vprašalnik za skrbni pregled na njenem zaslonu pa bi moral biti zgolj formalnost. Prva vprašanja so bila znana: predložite Izjavo o uporabnosti ISO/IEC 27001:2022, posredujte najnovejši register tveganj, pojasnite metodologijo ocenjevanja tveganj.

Nato se je vprašalnik spremenil.

Dokažite, kako vaš program upravljanja tveganj obravnava DORA. Pojasnite svojo pripravljenost na Direktivo NIS2, vključno z odgovornostjo vodstva in ukrepi za tveganja v dobavni verigi. Predložite dokazila, da so kritični dobavitelji IKT ocenjeni, spremljani in vključeni v načrte odzivanja na incidente ter neprekinjenega poslovanja.

Do ponedeljkovega jutra je bilo isto vprašanje na dnevnem redu odbora za tveganja pri upravnem odboru. Certifikacijska presoja ISO 27001 čez osem tednov. Pritisk glede DORA s strani strank iz finančnega sektorja. Vprašanja o razvrstitvi po NIS2 za storitveno linijo, gostovano v oblaku, ki se širi v EU. Nabava je povedala, da pregledi dobaviteljev obstajajo, vendar so dokazila razpršena po e-pošti, pogodbenih mapah in preglednici dobaviteljev. Pravna služba je povedala, da je regulativna preslikava še v pripravi. Inženiring je povedal, da je register tveganj večinoma dokončan.

Upravni odbor je postavil edino vprašanje, ki je bilo pomembno:

Ali lahko dokažemo, da sta naša ocena tveganj in načrt obravnave tveganj zadostna?

To je dejanski problem za SaaS, fintech, ponudnike upravljanih storitev, oblačna podjetja in podjetja z digitalnimi platformami. Ne gre za vprašanje, ali register tveganj obstaja. Ne gre za vprašanje, ali so kontrole iz Priloge A prekopirane v preglednico. Ključno je, ali lahko organizacija pod pritiskom presoje in zahtev strank dokaže, da je njen proces ocenjevanja tveganj ISO 27001 ponovljiv, utemeljen na tveganjih, odobren s strani lastnikov tveganj, povezan z ukrepi obravnave, preslikan na zakonske obveznosti in operativno živ.

Če je izvedeno dobro, lahko ena ocena tveganj ISO 27001 in en načrt obravnave tveganj podpreta certifikacijo ISO/IEC 27001:2022, ukrepe za obvladovanje kibernetskih tveganj po NIS2 Article 21, zahteve DORA glede upravljanja tveganj IKT, odgovornost po GDPR, zagotovila dobaviteljev, pripravljenost na incidente in poročanje upravnemu odboru.

Če je izvedeno slabo, postane preglednica, ki jo bodo presojevalci razgradili v tridesetih minutah.

Ta vodnik prikazuje, kako Clarysec gradi presojevalno zanesljiva dokazila za oceno tveganj ISO 27001 in obravnavo tveganj z uporabo Zenith Blueprint: 30-koračni časovni načrt za presojevalce, politik Clarysec in Zenith Controls: vodnik za skladnost z več okviri.

Zakaj je ocena tveganj ISO 27001 danes središče skladnosti

Regulativno okolje EU se zbližuje okoli preprostega načela: kibernetsko tveganje mora biti upravljano, dokumentirano, testirano in imeti določenega lastnika.

ISO/IEC 27001:2022 že deluje na ta način. Točke 4.1 do 4.4 zahtevajo, da organizacija razume svoj kontekst, zainteresirane strani, obseg ISMS in medsebojne vplive procesov, preden oceni tveganja. Točki 6.1.2 in 6.1.3 zahtevata opredeljen proces ocenjevanja in obravnave tveganj informacijske varnosti. Točki 8.2 in 8.3 zahtevata, da organizacija izvaja ocene tveganj in uresničuje načrt obravnave tveganj ter pri tem hrani dokumentirane informacije.

NIS2 in DORA isti logiki, utemeljeni na tveganjih, dodajata nujnost.

NIS2 Article 20 od poslovodnih organov bistvenih in pomembnih subjektov zahteva, da odobrijo ukrepe za obvladovanje kibernetskih tveganj, nadzirajo njihovo izvajanje in se udeležujejo usposabljanja s področja kibernetske varnosti. Article 21 zahteva ustrezne in sorazmerne tehnične, operativne in organizacijske ukrepe za obvladovanje tveganj za omrežne in informacijske sisteme. Ti ukrepi vključujejo analizo tveganj, obravnavanje incidentov, neprekinjeno poslovanje, varnost dobavne verige, varen razvoj, obravnavo ranljivosti, oceno učinkovitosti, kibernetsko higieno, kriptografijo, kadrovsko varnost, nadzor dostopa, upravljanje sredstev ter večfaktorsko avtentikacijo ali varovane komunikacije, kjer je to ustrezno.

DORA izvaja podoben pritisk na finančne subjekte. Articles 5 and 6 zahtevata, da poslovodni organ opredeli, odobri in nadzira ureditev upravljanja tveganj IKT ter zanjo ostaja odgovoren. DORA pričakuje dokumentiran okvir za upravljanje tveganj IKT, vključen v splošno upravljanje tveganj, ki ga podpirajo politike, postopki, protokoli, orodja, notranja revizija, odprava pomanjkljivosti, neprekinjenost poslovanja, testiranje, upravljanje incidentov in upravljanje tretjih oseb na področju IKT.

Zaključek je praktičen in neizogiben: register tveganj ni več delovni list tehnične ekipe. Je dokazilo o upravljanju.

Clarysecova podjetniška Politika upravljanja tveganj to pričakovanje jasno opredeljuje:

Formalni proces upravljanja tveganj se mora vzdrževati v skladu z ISO/IEC 27005 in ISO 31000 ter zajemati identifikacijo, analizo, vrednotenje, obravnavo, spremljanje in komuniciranje tveganj.

Iz podjetniške Politike upravljanja tveganj, razdelek »Zahteve upravljanja«, klavzula politike 5.1.

Ista politika opredeljuje presojevalno zanesljiv rezultat:

Vzdrževati centraliziran register tveganj in načrt obravnave tveganj z nadzorom različic, ki odražata trenutno stanje tveganj, pokritost kontrol in napredek pri zmanjševanju tveganj.

Iz podjetniške Politike upravljanja tveganj, razdelek »Cilji«, klavzula politike 3.3.

Besedna zveza »trenutno stanje tveganj, pokritost kontrol in napredek pri zmanjševanju tveganj« je razlika med statično datoteko za skladnost in zagovorljivim programom upravljanja tveganj.

Začnite z obsegom, obveznostmi in merili tveganj

Veliko šibkih ocen tveganj ISO 27001 se začne s kontrolnim seznamom kontrol. To je napačno zaporedje.

ISO 27001 zahteva, da organizacija pred izbiro kontrol določi kontekst, zahteve zainteresiranih strani, obseg ISMS, odgovornosti vodstva in načrtovanje tveganj. ISO/IEC 27005:2022 to dodatno utrjuje s priporočilom, naj organizacije pred ocenjevanjem tveganj opredelijo osnovne zahteve zainteresiranih strani. Te zahteve lahko izhajajo iz standardov ISO, sektorskih predpisov, nacionalne zakonodaje, pogodb s strankami, notranjih politik, prejšnjih dejavnosti obravnave tveganj in obveznosti do dobaviteljev.

Za SaaS ali fintech podjetje, usmerjeno v EU, se mora proces upravljanja tveganj začeti s popisom skladnostnih in drugih obveznosti.

Za MSP Clarysecova Politika pravne in regulativne skladnosti - MSP določa izhodišče:

Generalni direktor mora vzdrževati preprosto, strukturirano evidenco skladnosti, ki vsebuje:

Iz Politike pravne in regulativne skladnosti za MSP, razdelek »Zahteve upravljanja«, klavzula politike 5.1.1.

Ta preprosta evidenca je most med skladnostjo in upravljanjem tveganj. Če kaže, da se GDPR uporablja, ker se obdelujejo osebni podatki iz EU, da se NIS2 lahko uporablja, ker organizacija zagotavlja digitalne ali upravljane storitve, ali da je DORA relevantna zaradi strank iz finančnega sektorja, morajo te obveznosti vplivati na merila tveganj in prioritete obravnave.

Zenith Blueprint je pri tem neposreden v fazi upravljanja tveganj, Step 10, »Vzpostavitev meril tveganj in matrike vpliva«:

V merilih za sprejem upoštevajte tudi pravne/regulativne zahteve. Nekatera tveganja so lahko nesprejemljiva ne glede na verjetnost zaradi zakonodaje.

Iz Zenith Blueprint, faza upravljanja tveganj, Step 10.

Podaja tudi praktično pravilo za delavnice:

»Vsako tveganje, ki bi lahko povzročilo neskladnost z veljavnimi zakoni (GDPR itd.), ni sprejemljivo in ga je treba zmanjšati.«

Iz Zenith Blueprint, faza upravljanja tveganj, Step 10.

Za Sarahino fintech podjetje to spremeni model točkovanja. Ranljivost API dobavitelja ima lahko nizko verjetnost, vendar če bi izkoriščanje lahko sprožilo večji incident, povezan z IKT, po DORA, pomemben incident po NIS2, oceno kršitve po GDPR, neizpolnitev SLA za stranko ali eskalacijo na raven upravnega odbora, je vpliv visok ali kritičen. Izpostavljenost skladnosti postane del logike tveganj, ne ločena preglednica.

Zgradite register tveganj, ki ga lahko presojevalci testirajo

Presojevalci ne sprašujejo samo, katera so vaša najpomembnejša tveganja. Preverjajo, ali je vaša metoda opredeljena, ponovljiva, sledljiva in uporabljena.

Vprašali bodo:

• Kako ste ta tveganja identificirali?
• Katera sredstva, storitve, dobavitelji, vrste podatkov in procesi so bili v obsegu?
• Katera merila so bila uporabljena za verjetnost in vpliv?
• Kdo je lastnik posameznega tveganja?
• Katere obstoječe kontrole zmanjšujejo tveganje?
• Zakaj je bila izbrana določena odločitev o obravnavi?
• Kje so dokazila, da je bila obravnava izvedena?
• Kdo je odobril preostalo tveganje?
• Kdaj bo tveganje ponovno ocenjeno?

Clarysecova Politika upravljanja tveganj - MSP zajema minimalni vnos tveganja, pripravljen za presojo:

Vsak vnos tveganja mora vključevati: opis, verjetnost, vpliv, oceno, lastnika in načrt obravnave tveganja.

Iz Politike upravljanja tveganj za MSP, razdelek »Zahteve upravljanja«, klavzula politike 5.1.2.

Za podjetniške programe Zenith Blueprint, faza upravljanja tveganj, Step 11, »Vzpostavitev in dokumentiranje registra tveganj«, razširi strukturo. Priporoča stolpce, kot so identifikator tveganja, sredstvo, grožnja, ranljivost, opis tveganja, verjetnost, vpliv, raven tveganja, obstoječe kontrole, lastnik tveganja, odločitev o obravnavi, načrt obravnave tveganja ali kontrole in status.

Močan vnos tveganja je videti tako:

To je bistveno drugače od »tveganje tretje osebe, visoko, zmanjšati«. Različica, pripravljena za presojo, povezuje sredstvo, grožnjo, ranljivost, posledico, obstoječe kontrole, lastnika, predpis, dokazila in upravljanje.

Obravnavo tveganj pretvorite v načrt dokazil

Načrt obravnave tveganj mora odgovoriti na štiri operativna vprašanja:

1. Kaj bomo naredili?
2. Kdo je lastnik?
3. Kdaj bo izvedeno?
4. Kako bomo dokazali, da je zmanjšalo tveganje?

ISO/IEC 27001:2022 točka 6.1.3 zahteva, da organizacija izbere možnosti obravnave, določi potrebne kontrole, jih primerja s Prilogo A, da prepreči izpuste, pripravi Izjavo o uporabnosti, oblikuje načrt obravnave tveganj ter pridobi odobritev lastnika tveganja za načrt in preostala tveganja. Točka 8.3 nato zahteva izvedbo načrta obravnave tveganj in hrambo dokumentiranih informacij o rezultatih.

Podjetniška Politika upravljanja tveganj to naredi praktično:

Odgovorna oseba za tveganja mora zagotoviti, da so obravnave realistične, časovno omejene in preslikane na kontrole ISO/IEC 27001 Priloge A.

Iz podjetniške Politike upravljanja tveganj, razdelek »Zahteve za izvajanje politike«, klavzula politike 6.4.2.

Politika za MSP dodatno pojasnjuje, da sprejem tveganja ni bližnjica:

Sprejmi: utemelji, zakaj nadaljnji ukrepi niso potrebni, in zabeleži preostalo tveganje.

Iz Politike upravljanja tveganj za MSP, razdelek »Zahteve za izvajanje politike«, klavzula politike 6.1.1.

Sprejem mora biti utemeljen glede na merila, odobren s strani ustreznega lastnika in spremljan. Po NIS2 in DORA lahko neodobreno preostalo tveganje postane neuspeh upravljanja.

Celovit načrt obravnave tveganj mora vsebovati ta polja:

Za Sarahin R-042 načrt obravnave postane seznam ukrepov za skladnost z več okviri.

Ta načrt je močan, ker ustvari neposredno povezavo od enega scenarija tveganja do kontrol ISO 27001, obveznosti NIS2, členov DORA, lastnikov in dokazil.

Izjava o uporabnosti naj opravi več dela

Izjava o uporabnosti se pogosto obravnava kot certifikacijski artefakt. Biti mora več kot to.

ISO/IEC 27001:2022 točka 6.1.3 zahteva, da SoA vključuje potrebne kontrole, utemeljitev vključitve, status implementacije in utemeljitev izključitev. Smernice ISO/IEC 27005:2022 dodatno poudarjajo potrebo po primerjavi izbranih kontrol z ISO/IEC 27001 Prilogo A, da se preprečijo izpusti.

V programu, pripravljenem za presojo, SoA postane most med obravnavo tveganj in dokazili za skladnost z več okviri. Če načrt obravnave zahteva MFA, beleženje, spremljanje dobaviteljev, obnovitev varnostnih kopij, varen razvoj, eskalacijo incidentov ali načrtovanje izstopa iz oblaka, mora SoA pokazati, da so ustrezne kontrole Priloge A vključene, utemeljene, implementirane ali načrtovane ter podprte z dokazili.

To pomaga preprečiti tudi pogost neuspeh pri presoji: register tveganj pravi eno, načrt obravnave drugo, SoA pa o tem molči. Ko se ti artefakti ne ujemajo, presojevalci hitro izgubijo zaupanje.

Preslikava obravnave tveganj ISO 27001 na NIS2, DORA in GDPR

ISO 27001 ne nadomešča NIS2, DORA ali GDPR. Daje vam strukturiran mehanizem za pripravo dokazil zanje.

Ključno je, da preslikavo vgradite v proces upravljanja tveganj, namesto da jo dodate pozneje.

Ta preslikava je posebej pomembna tam, kjer se predpisi prekrivajo. DORA je sektorski režim odpornosti IKT za številne finančne subjekte, medtem ko lahko NIS2 ostane neposredno relevantna za določene ponudnike, usklajevanje ali subjekte zunaj obsega DORA. Fintech podjetje lahko potrebuje DORA kot svoj primarni okvir odpornosti IKT, medtem ko je ponudnik upravljanih storitev, ki podpira to fintech podjetje, lahko neposredno zavezan po NIS2.

Register tveganj mora znati prikazati obe strani te odvisnosti.

Uporabite Zenith Controls kot kompas za skladnost z več okviri

Clarysec uporablja Zenith Controls kot vodnik za skladnost z več okviri, da prepreči pogosto napako, pri kateri kontrole ISO, regulativni členi in presojevalna vprašanja živijo v ločenih svetovih. Ne ustvarja ločenega okvira kontrol. Področja kontrol ISO/IEC 27001:2022 in ISO/IEC 27002:2022 preslika na druge standarde, presojevalna pričakovanja in vidike skladnosti.

Za oceno in obravnavo tveganj ISO 27001 so posebej pomembni ti sklici:

Nauk skladnosti z več okviri je preprost. Če zakonske obveznosti niso del metode ocenjevanja tveganj, je vaše točkovanje nepopolno. Če je točkovanje nepopolno, so lahko prioritete obravnave napačne. Če so prioritete napačne, postaneta SoA in poročanje upravnemu odboru nezanesljiva.

Zenith Blueprint isto poudari v fazi upravljanja tveganj, Step 14, »Politike obravnave tveganj in regulativni navzkrižni sklici«. Organizacijam svetuje, naj ustvarijo tabelo preslikave, v kateri navedejo ključne regulativne varnostne zahteve in ustrezne kontrole ali politike v ISMS. To ni obvezno za certifikacijo ISO 27001, vendar je zelo uporabno za dokazovanje, da se varnost upravlja v pravnem in pogodbenem kontekstu.

Kaj bodo vprašali različni presojevalci

Certifikacijski presojevalec, pregledovalec, usmerjen v NIS2, stranka, usmerjena v DORA, pregledovalec GDPR, ocenjevalec NIST ali praktik COBIT lahko preučujejo ista dokazila, vendar postavljajo različna vprašanja.

Zato je arhitektura dokazil pomembna. Isti vnos tveganja mora biti sledljiv od poslovnega cilja do sredstva, grožnje, ranljivosti, kontrole, lastnika, regulativnega razloga, ukrepa obravnave, rezultata testa in odločitve vodstva.

Politike Clarysec so zasnovane tako, da podpirajo to arhitekturo. Podjetniška Politika upravljanja tveganj v razdelku »Referenčni standardi in okviri« določa:

Article 5: zahteva dokumentiran okvir upravljanja tveganj IKT, ki je v celoti zajet s strukturo te politike, vključno s preslikavo SoA in KRI.

To politiko spremeni iz statičnega dokumenta v presojevalno dokazilo, da je bilo upravljanje tveganj IKT namensko zasnovano z DORA v mislih.

Pogoste ugotovitve, ki porušijo programe tveganj

Ko Clarysec pregleduje dokazila o ocenjevanju in obravnavi tveganj ISO 27001, se iste ugotovitve ponavljajo.

Prvič, merila tveganj ne upoštevajo pravnega, regulativnega, pogodbenega, dobaviteljskega in zasebnostnega vpliva. To povzroči šibko točkovanje. Kršitev osebnih podatkov ali odpoved kritičnega dobavitelja je lahko ocenjena kot srednja, ker je verjetnost nizka, čeprav bi moral vpliv po GDPR, NIS2, DORA ali za stranko pomeniti visoko ali kritično raven.

Drugič, lastniki tveganj so generični. »IT« ni lastnik tveganja. Lastnik tveganja mora biti vloga ali oseba, odgovorna za odločitve o obravnavi, proračun, časovnico in preostalo tveganje.

Tretjič, načrti obravnave tveganj niso časovno omejeni. »Izboljšati spremljanje« ni načrt. »Do 30. junija uvesti opozorila za privilegirane seje v SIEM za produkcijske administratorske račune, lastnik je vodja SOC, testirano s simulirano administratorsko prijavo, z dodanimi dokazili o opozorilu« je načrt.

Četrtič, SoA je ločena od obravnave. Če načrt obravnave zahteva spremljanje dobaviteljev, testiranje varnostnih kopij, eskalacijo incidentov, MFA ali beleženje, mora SoA odražati ustrezne kontrole in status implementacije.

Petič, preostalo tveganje ni odobreno. ISO 27001 zahteva odobritev načrta obravnave in preostalih tveganj s strani lastnika tveganja. NIS2 in DORA to naredita še pomembnejše, ker je odgovornost vodstva izrecna.

Šestič, tveganje dobaviteljev se obravnava kot administracija nabave. Po NIS2 Article 21(2)(d) in DORA Articles 28 and 30 morajo biti tveganja dobaviteljev in tretjih oseb na področju IKT del upravljanja tveganj, ne letni vprašalnik, shranjen ločeno.

Sedmič, ni dokazil o učinkovitosti. ISO 27001 točka 6.1.1 zahteva, da se načrtovani ukrepi ocenijo glede učinkovitosti. NIS2 vključuje oceno učinkovitosti v Article 21(2)(f). DORA pričakuje testiranje in odpravo pomanjkljivosti. Kontrola, ki obstaja, vendar ni nikoli testirana, je šibko dokazilo.

Politika upravljanja tveganj - MSP pričakovanje jasno opredeljuje:

Generalni direktor in koordinator za tveganja morata zagotoviti, da so dejavnosti upravljanja tveganj pripravljene za presojo. Register tveganj in povezani ukrepi so predmet notranje in zunanje presoje.

Iz Politike upravljanja tveganj za MSP, razdelek »Uveljavljanje in skladnost«, klavzula politike 8.2.1.

Poročanje upravnemu odboru brez preobremenitve vodstva

NIS2, DORA in ISO 27001 vsi usmerjajo k odgovornosti vodstva, vendar upravni odbori ne potrebujejo vsake vrstice tveganja. Potrebujejo poročanje, uporabno za odločanje.

Dober paket poročanja o tveganjih za upravni odbor mora prikazati:

• visoka in kritična tveganja po področjih;
• zapadle ukrepe obravnave tveganj;
• regulativna tveganja, povezana z NIS2, DORA, GDPR ali pogodbami;
• tveganja dobaviteljev, ki vplivajo na kritične ali pomembne storitve;
• trende incidentov in skorajšnjih incidentov;
• preostala tveganja, ki čakajo na sprejem;
• rezultate testov učinkovitosti kontrol;
• pomembne spremembe obsega, dobaviteljev, tehnologije ali zakonodaje;
• ugotovitve notranje presoje in korektivne ukrepe.

Clarysec običajno priporoča mesečne operativne preglede tveganj in četrtletne vodstvene preglede. Mesečni pregledi se osredotočajo na izvedbo obravnave. Četrtletni pregledi se osredotočajo na sprejem, financiranje, prednostno razvrščanje, regulativno izpostavljenost in strateške odločitve o tveganjih.

Ta ritem podpira tudi nenehno izboljševanje. Ocene tveganj je treba posodobiti ob incidentih, pojavu ranljivosti, uvedbi novih sredstev, spremembah tehnologije, spremembah dobaviteljev, spremembah zakonodaje, spremembah obveznosti do strank ali spremembah apetita po tveganju.

Pot implementacije Clarysec

Enoten program tveganj preprečuje nepovezane preglednice za ISO, NIS2, DORA, GDPR in zagotovila strank. Praktična pot je:

1. Potrdite obseg ISMS, storitve, sredstva, dobavitelje, jurisdikcije in obveznosti do strank.
2. Vzpostavite ali posodobite evidenco skladnosti z uporabo Politike pravne in regulativne skladnosti - MSP, kjer je to primerno.
3. Opredelite metodologijo tveganj, merila sprejemljivosti, lestvice verjetnosti, lestvice vpliva in pravila regulativnega vpliva.
4. Zgradite register tveganj z uporabo faze upravljanja tveganj Zenith Blueprint ter Clarysecovega pristopa k registru tveganj in gradniku SoA.
5. Identificirajte tveganja na podlagi sredstev in scenarijev, vključno s scenariji dobaviteljev, oblaka, zasebnosti, neprekinjenosti poslovanja, incidentov, ranljivosti, varnega razvoja in dostopa.
6. Ocenite tveganja z merili, ki vključujejo pravni, regulativni, pogodbeni, operativni, zasebnostni, dobaviteljski in finančni vpliv.
7. Izberite možnosti obravnave: zmanjšati, izogniti se, prenesti ali sprejeti.
8. Preslikajte potrebne kontrole na ISO/IEC 27001:2022 Prilogo A in smernice ISO/IEC 27002:2022.
9. Ustvarite ali posodobite Izjavo o uporabnosti.
10. Preslikajte obravnave na NIS2 Article 21, upravljanje tveganj IKT in pričakovanja glede tretjih oseb po DORA, odgovornost po GDPR in pogodbene obveznosti do strank.
11. Zberite dokazila, preverite učinkovitost kontrol in pridobite odobritev preostalega tveganja.
12. Pripravite presojevalni paket, organiziran po tveganjih, kontrolah, predpisih in dokaznih artefaktih.
13. Rezultate vključite v vodstveni pregled, notranjo presojo, korektivne ukrepe in nenehno izboljševanje.

To ni dokumentacija sama sebi namen. Je operacijski sistem za zagovorljivo kibernetsko upravljanje.

Zgradite paket obravnave tveganj, pripravljen za presojo

Sarahina zgodba se konča dobro, ker je ISO 27001, NIS2 in DORA prenehala obravnavati kot ločene projekte skladnosti. Oceno tveganj ISO 27001 je uporabila kot osrednji mehanizem, regulativne obveznosti vgradila v merila tveganj, ukrepe obravnave preslikala na Prilogo A in zahteve EU ter zbrala dokazila, ki jih lahko razumejo stranke, presojevalci in upravni odbor.

Enako lahko stori tudi vaša organizacija.

Uporabite Zenith Blueprint: 30-koračni časovni načrt za presojevalce za opredelitev meril tveganj, vzpostavitev registra tveganj, pripravo načrta obravnave tveganj in navzkrižno sklicevanje regulativnih zahtev.

Uporabite Zenith Controls: vodnik za skladnost z več okviri za povezavo področij kontrol ISO/IEC 27001:2022 Priloge A z upravljanjem, pravno skladnostjo, zagotavljanjem zaupanja in presojevalnimi vidiki.

Uporabite Clarysecovo Politiko upravljanja tveganj, Politiko upravljanja tveganj - MSP in Politiko pravne in regulativne skladnosti - MSP za standardizacijo lastništva, registrov, odločitev o obravnavi in dokazil, pripravljenih za presojo.

Najhitrejši praktični naslednji korak je, da vzamete svojih deset najpomembnejših tveganj in jih preverite s petimi vprašanji:

1. Ali je regulativni vpliv viden?
2. Ali je načrt obravnave tveganj časovno omejen in ima določenega lastnika?
3. Ali je vsaka obravnava preslikana na Prilogo A in SoA?
4. Ali je relevantnost za NIS2, DORA, GDPR ali stranko dokumentirana, kjer je to primerno?
5. Ali obstajajo dokazila, da kontrola deluje?

Če je odgovor ne, vam lahko Clarysec pomaga pretvoriti register tveganj v zagovorljiv program obravnave tveganj za skladnost z več okviri, ki mu lahko zaupajo presojevalci, regulatorji, stranke in upravni odbori.