Matrika deljene odgovornosti v oblaku za ISO 27001, NIS2, DORA in GDPR

Direktor operacij v fintech podjetju v ponedeljek ob 07:15 pokliče vodjo informacijske varnosti.

Evropska bančna stranka zahteva dokazila, da lahko platforma SaaS podjetja izpolni zahteve DORA glede IKT-tveganj tretjih oseb. Prodajna ekipa je že poslala običajni paket varnostnih dokazil o dobavitelju: certifikat ISO, povzetek poročila o penetracijskem testiranju za vodstvo, potrdilo o kibernetskem zavarovanju, obvestilo o zasebnosti in poročilo ponudnika storitev v oblaku o zagotovilih.

Banka se vrne z natančnejšim vprašanjem:

»Pokažite nam, kdo je odgovoren za posamezno kontrolo v vašem okolju v oblaku. Vi, vaš ponudnik storitev v oblaku, vaš ponudnik upravljane podatkovne baze, vaš ponudnik identitet, vaš dobavitelj za beleženje in vsi podobdelovalci. Nato pokažite dokazila.«

Pozneje istega dopoldneva ima vodja informacijske varnosti sestanek z upravnim odborom. Generalni direktor bo isto vprašanje zastavil v poslovnem jeziku: »Ali smo prepričani, da je ta platforma varna, in kdo je odgovoren, če gre kaj narobe?«

Tu se številni programi skladnosti v oblaku ustavijo.

Organizacija ima lahko močnega ponudnika storitev v oblaku, dobra orodja, ustrezne politike in register tveganj. Ko pa mora dokazati meje odgovornosti, so dokazila razpršena. Nabava ima pogodbe. Pravna služba ima DPA. Inženiring ima arhitekturne diagrame. Varnostna ekipa ima dnevnike in konfiguracije oblaka. Zasebnost ima seznam podobdelovalcev. Skladnost ima Izjavo o uporabnosti. Nihče pa nima enega nadzorovanega artefakta, ki po posamezni kontroli pove, kaj izvaja ponudnik, kaj mora konfigurirati naročnik, kateri podobdelovalec je vključen, katera klavzula naredi obveznost izvršljivo in katera dokazila naj pričakuje presojevalec.

Ta artefakt je matrika deljene odgovornosti v oblaku.

Ne gre za generični diapozitiv hiperskalerskega ponudnika, ki pravi, da ponudnik varuje oblak, naročnik pa varuje tisto, kar je v oblaku. Resnična matrika deljene odgovornosti v oblaku za ISO/IEC 27001:2022, NIS2, DORA in GDPR je zapis upravljanja. Prestane skrbni pregled stranke, presojo ISO, pregled DORA, preizkus odgovornosti po GDPR in preiskavo incidenta.

Zakaj deljena odgovornost v oblaku postane problem presoje

Model deljene odgovornosti se običajno razlaga kot tehnična meja. Pri IaaS ponudnik upravlja fizične prostore, strojno opremo, virtualizacijo in ključno infrastrukturo. Naročnik upravlja identitete, podatke, delovne obremenitve, omrežna pravila, izbire šifriranja in konfiguracije. Pri SaaS ponudnik prevzame več operativne odgovornosti, vendar naročnik še vedno obvladuje uporabniški dostop, upravljanje podatkov, pravno podlago, konfiguracijo, pričakovanja glede spremljanja in eskalacijo incidentov.

Ta razlaga je koristna, vendar ne zadostuje.

Presojevalci, regulatorji in poslovne stranke ne sprašujejo več samo »kdo izvaja kontrolo?«. Želijo vedeti:

• Kdo je odgovoren za tveganje?
• Katera pogodbena klavzula naredi to odgovornost izvršljivo?
• Katera politika zahteva kontrolo?
• Katera storitev v oblaku, platforma SaaS ali podobdelovalec je v obsegu?
• Katera dokazila dokazujejo, da je kontrola delovala v obdobju pregleda?
• Katero zahtevo okvira dokazilo izpolnjuje?
• Kaj se zgodi, če ponudnik spremeni storitev, lokacijo, podizvajalca ali stanje kontrol?

ISO/IEC 27001:2022 ISO/IEC 27001:2022 to obravnava kot vprašanje sistema upravljanja. Klavzule 4.1 do 4.4 zahtevajo, da organizacija razume notranje in zunanje okoliščine, zainteresirane strani, zakonske in pogodbene obveznosti, obseg ISMS, vmesnike in odvisnosti. Klavzule 6.1.1 do 6.1.3 zahtevajo oceno tveganja, obravnavo tveganja, odobritev lastnika tveganja, sprejem preostalega tveganja in Izjavo o uporabnosti. Klavzula 8.1 zahteva operativno načrtovanje in nadzor, vključno z nadzorom zunanje zagotovljenih procesov, proizvodov in storitev, pomembnih za ISMS.

Preprosto povedano: če ponudnik storitev v oblaku, dobavitelj SaaS ali podobdelovalec podpira poslovni proces v obsegu, ne more biti zunaj ISMS. Viden mora biti v obsegu, tveganjih, obravnavi tveganj, pogodbenem nadzoru in dokazilih.

NIS2 zvišuje zahteve. Article 21 od bistvenih in pomembnih subjektov zahteva uvedbo ustreznih in sorazmernih tehničnih, operativnih in organizacijskih ukrepov, vključno z analizo tveganja, obravnavanjem incidentov, neprekinjenim poslovanjem, varnostjo dobavne verige, varno nabavo, varnim razvojem, obravnavo ranljivosti, oceno učinkovitosti, kibernetsko higieno, kriptografijo, varnostjo kadrov, nadzorom dostopa, upravljanjem sredstev ter večfaktorsko avtentikacijo ali neprekinjeno avtentikacijo, kadar je to ustrezno. Article 20 odgovornost za upravljanje nalaga organom vodenja.

DORA je za finančne subjekte še bolj izrecna. Uporablja se od 17. januarja 2025 in od finančnih subjektov zahteva upravljanje IKT-tveganj, poročanje o večjih incidentih, povezanih z IKT, testiranje digitalne operativne odpornosti in upravljanje IKT-tveganj tretjih oseb. Articles 28 do 30 zahtevajo upravljanje IKT-tveganj tretjih oseb, predhodno oceno tveganja koncentracije, pogodbena varovala, pravice do revizije in dostopa, preglednost podizvajanja, pravice do odpovedi in izhodne strategije.

GDPR dodaja preizkus odgovornosti. Article 5 zahteva obdelavo osebnih podatkov z zagotavljanjem celovitosti in zaupnosti, Article 5(2) pa zahteva, da lahko upravljavec dokaže skladnost. Article 28 ureja pogodbe z obdelovalci in podobdelovalce. Article 32 zahteva varnost obdelave. Articles 33 in 34 zahtevata obveščanje o kršitvah varnosti osebnih podatkov, kadar je to potrebno.

Matrika deljene odgovornosti v oblaku postane most med temi obveznostmi.

Clarysec definicija: artefakt upravljanja, ne diagram

Pri projektih Clarysec je matrika deljene odgovornosti v oblaku nadzorovan zapis ISMS, ki povezuje storitve v oblaku, dobavitelje, podobdelovalce, kontrole, politike, pogodbene obveznosti, dokazila in pričakovanja pri presoji.

Najbolj jasna razlaga je v Zenith Blueprint Zenith Blueprint, v fazi Controls in Action, Step 23:

»Ponudniki storitev v oblaku varujejo infrastrukturo, vendar ste še vedno odgovorni za svoje podatke, svoje konfiguracije, svoje politike dostopa in svojo pripravljenost na odziv na incidente.«

Isti korak pojasnjuje, da je treba uporabo oblaka obravnavati kot del ISMS, vključno z razvrščanjem storitev v oblaku, razumevanjem obdelanih ali shranjenih podatkov, ocenjevanjem ponudnika, pogodbenimi klavzulami in upravljanjem sprememb storitev. S tem se deljena odgovornost iz koncepta spremeni v sledljivo strukturo kontrol.

Zenith Controls Zenith Controls obravnava kontrole iz Priloge A ISO/IEC 27001:2022 in usmeritve ISO/IEC 27002:2022 5.20, 5.21 in 5.23 kot osrednja sidrišča:

• 5.20, obravnava informacijske varnosti v dogovorih z dobavitelji.
• 5.21, upravljanje informacijske varnosti v dobavni verigi IKT.
• 5.23, informacijska varnost pri uporabi storitev v oblaku.

To niso izolirane postavke kontrolnega seznama. Opredeljujejo hrbtenico matrike.

Podporni standardi lahko matriko okrepijo. ISO/IEC 27017 pomaga pri varnostnih praksah, specifičnih za oblak. ISO/IEC 27018 in ISO/IEC 27701 podpirata upravljanje osebno določljivih podatkov in zasebnosti. ISO/IEC 27005 podpira oceno tveganja. ISO 22301 podpira neprekinjeno poslovanje in odpornost. ISO/IEC 27035 podpira upravljanje incidentov. ISO/IEC 20000-1 lahko pomaga, kadar so storitve v oblaku del izvajanja upravljanih storitev.

Najmanjša uporabna matrika deljene odgovornosti

Zrela matrika se ne začne z 200 vrsticami. Začne se s storitvami v oblaku, ki so najpomembnejše.

Za SaaS, fintech ali regulirano malo oziroma srednje podjetje Clarysec običajno začne z:

1. Produkcijskim okoljem v oblaku, namenjenim strankam.
2. Ponudnikom identitet.
3. Upravljano podatkovno bazo ali storitvijo shranjevanja.
4. Platformo za beleženje, spremljanje in SIEM.
5. SaaS za plačila, KYC, analitiko ali podporo strankam.
6. Storitvijo varnostnega kopiranja in obnove po nesreči.
7. Ponudnikom upravljanih storitev ali ponudnikom upravljanih varnostnih storitev.
8. Podobdelovalci, ki dostopajo do podatkov strank, jih shranjujejo ali obdelujejo.

Prva matrika mora vključevati naslednje stolpce.

Praktična vrstica za beleženje je lahko videti tako.

Ta vrstica ni samo dokumentacija. Varnostni ekipi pove, kaj mora konfigurirati, nabavi, kateri pogodbeni jezik mora preveriti, zasebnosti, kateri tok podatkov mora evidentirati, presojevalcem pa, katera dokazila naj zahtevajo.

Temelj v politikah: kako matriko spremeniti v izvršljivo zahtevo

Matrika deljene odgovornosti v oblaku brez podpore politike je samo preglednica. Politike Clarysec jo naredijo izvršljivo.

Za mala in srednje velika podjetja Politika uporabe storitev v oblaku - SME Politika uporabe storitev v oblaku - SME, razdelek »Zahteve upravljanja«, klavzula 5.3 zahteva:

»Ponudnik IT ali GM mora vzdrževati register storitev v oblaku. V njem mora evidentirati:«

Ista politika za mala in srednje velika podjetja v klavzuli 5.2.3 povezuje upravljanje oblaka s tveganji zasebnosti in lokacije:

»Lokacija hrambe podatkov in prakse zasebnosti so skladne z veljavnimi zakonskimi zahtevami (npr. GDPR).«

Za poslovna okolja Politika uporabe storitev v oblaku Politika uporabe storitev v oblaku, razdelek »Zahteve upravljanja«, klavzula 5.1 določa:

»Organizacija mora vzdrževati centraliziran register storitev v oblaku, katerega lastnik je vodja informacijske varnosti (CISO), in ki vsebuje:«

Klavzula 5.4 nato naredi odgovornosti v oblaku pogodbeno izvršljive:

»Vse pogodbe s CSP (Cloud Service Provider) morajo vključevati izvršljive določbe za:«

Upravljanje dobaviteljev razširi matriko prek neposrednega ponudnika. Politika varnosti tretjih oseb in dobaviteljev - SME Politika varnosti tretjih oseb in dobaviteljev - SME, razdelek »Zahteve upravljanja«, klavzula 5.3.5 zahteva:

»Omejitve nadaljnjega podizvajanja brez odobritve.«

Ista politika za dobavitelje za mala in srednje velika podjetja v razdelku »Zahteve za izvajanje politike«, klavzula 6.3.1 dodaja periodični pregled:

»Kritične ali visoko tvegane dobavitelje je treba pregledati najmanj enkrat letno. Pregled mora preveriti:«

Na ravni podjetja Politika varnosti tretjih oseb in dobaviteljev Politika varnosti tretjih oseb in dobaviteljev, razdelek »Zahteve upravljanja«, klavzula 5.3 določa:

»Pogodbe z dobavitelji morajo vključevati:«

Za osebne podatke Politika varstva podatkov in zasebnosti Politika varstva podatkov in zasebnosti, razdelek »Uveljavljanje in skladnost«, klavzula 8.5.1 zahteva:

»Pogodbe z obdelovalci morajo vključevati:«

Za preglednost odvisnosti Politika upravljanja tveganj odvisnosti od dobaviteljev Politika upravljanja tveganj odvisnosti od dobaviteljev, klavzula 6.5.4 zahteva:

»Uporabo dobaviteljskega odnosa za pridobivanje posodobitev o podizvajalcih ali odvisnostih v dobavni verigi eno raven navzdol, kadar bi lahko vplivale na nas (na primer, če je kritični dobavitelj programske opreme močno odvisen od knjižnice tretje osebe, se to evidentira).«

Za dnevnike Politika beleženja in spremljanja - SME Politika beleženja in spremljanja - SME, razdelek »Zahteve upravljanja«, klavzula 5.5.1.3 določa konkretno pogodbeno zahtevo:

»Pogodbe morajo od ponudnikov zahtevati hrambo dnevnikov najmanj 12 mesecev in zagotovitev dostopa na zahtevo.«

Skupaj te politike naredijo matriko za obvezen zapis upravljanja, ki podpira odobritev dobaviteljev, uvajanje storitev v oblaku, odgovornost na področju zasebnosti, letni pregled in dokazila za presojo.

Preslikava matrike na ISO/IEC 27001:2022, NIS2, DORA in GDPR

Klasična napaka je ustvarjanje štirih ločenih delovnih zvezkov za skladnost. Ena kontrola lahko izpolni več obveznosti, če sta odgovornost in dokazila sledljiva.

ISO/IEC 27001:2022 zagotavlja mehanizem ISMS: kontekst, zainteresirane strani, obseg, voditeljstvo, obravnavo tveganja, cilje, operativni nadzor, vrednotenje uspešnosti in izboljševanje. Priloga A zagotavlja praktično strukturo kontrol.

NIS2 Article 21 se naravno preslika v isto matriko prek varnosti dobavne verige, obravnavanja incidentov, neprekinjenega poslovanja, nadzora dostopa, upravljanja sredstev in varne nabave. Article 20 naredi matriko pomembno za upravni odbor, ker morajo organi vodenja odobriti in nadzirati ukrepe za obvladovanje kibernetskih tveganj.

DORA matriko spremeni v orodje za upravljanje IKT-tveganj tretjih oseb. Articles 5, 6 in 8 zahtevajo upravljanje, dokumentirano upravljanje IKT-tveganj ter identifikacijo sredstev, funkcij in odvisnosti. Articles 17 do 19 zahtevajo odkrivanje, razvrščanje, eskalacijo, komuniciranje in poročanje o incidentih. Articles 28 do 30 zahtevajo upravljanje tveganj tretjih oseb, analizo tveganja koncentracije, pogodbene klavzule, kontrole podizvajanja, pravice do revizije, pravice do odpovedi in izhodne strategije.

GDPR prispeva pogled na osebne podatke. Vsaka vrstica storitve v oblaku mora opredeliti, ali se obdelujejo osebni podatki, ali je ponudnik obdelovalec ali podobdelovalec, ali je lokacija podatkov pomembna in katera pogodbena dokazila ali dokazila DPA obstajajo.

NIST CSF 2.0 pomaga isto matriko pojasniti v jeziku izidov. Funkcija GOVERN obravnava kontekst organizacije, zakonske in regulativne zahteve, odvisnosti, upravljanje tveganj, vloge, politike in nadzor. Izidi GV.SC so posebej uporabni za kibernetsko tveganje dobaviteljev, vključno z vlogami dobaviteljev, kritičnostjo, pogodbenimi zahtevami, skrbnim pregledom, spremljanjem, koordinacijo incidentov in načrtovanjem prenehanja.

COBIT 2019 dodaja vidik zagotovil in upravljanja. Sprašuje, ali so odgovornost, prakse upravljanja, lastništvo, spremljanje in odprava težav ponovljivi ter podprti z dokazili.

Gradnja matrike od registra do dokazila

Predstavljajte si podjetje SaaS, ki uporablja hiperskalersko platformo IaaS, upravljano podatkovno bazo, ponudnika identitet tretje osebe, platformo SaaS za podporo strankam in zunanji SIEM. Potek implementacije je neposreden.

1. korak: Začnite z registrom storitev v oblaku

Kot sprožilec uporabite Politiko uporabe storitev v oblaku ali Politiko uporabe storitev v oblaku - SME. Evidentirajte vsako storitev v oblaku, lastnika, namen, kategorije podatkov, lokacijo, poslovno funkcijo, raven dobavitelja, lastnika pogodbe in datum pregleda.

Če storitev hrani evidence o strankah, dnevnike avtentikacije ali zahtevke za podporo, jo označite kot pomembno z vidika zasebnosti. Če podpira produkcijsko razpoložljivost, jo označite kot operativno kritično. Če podpira kritično ali pomembno funkcijo finančne stranke, jo označite kot relevantno za DORA.

2. korak: Dodajte področja deljene odgovornosti

Za vsako storitev določite odgovornosti po ključnih področjih.

3. korak: Povežite kontrole s tveganjem in Izjavo o uporabnosti

Zenith Blueprint, faza Risk Management, Step 13, pojasnjuje zahtevo po sledljivosti:

»Navzkrižno sklicevanje na predpise: če so nekatere kontrole uvedene posebej zaradi skladnosti z GDPR, NIS2 ali DORA, lahko to navedete bodisi v registru tveganj (kot del utemeljitve vpliva tveganja) bodisi v opombah SoA.«

Na primer, tveganje »nepooblaščen dostop do produkcijskih podatkov strank zaradi napačne konfiguracije oblaka« se lahko preslika na nadzor dostopa, uporabo storitev v oblaku, beleženje, kriptografijo, upravljanje ranljivosti in dogovore z dobavitelji. SoA se lahko sklicuje na ISO/IEC 27001:2022 Priloga A 5.15, 5.16, 5.20, 5.23, 8.8, 8.15, 8.16 in 8.24, z opombami za GDPR Article 32, NIS2 Article 21 in upravljanje IKT-tveganj po DORA, kadar je ustrezno.

4. korak: Priložite dokazila pred sezono presoje

Dokazila je treba vgraditi v matriko, ne zbirati v paniki.

Seznam dokazil spremeni odgovornost v dokaz. Komercialnim ekipam pomaga tudi hitreje odgovarjati na skrbne preglede poslovnih strank, saj lahko pokažejo ne le certifikate, temveč tudi lastništvo kontrol in operativna dokazila.

Podobdelovalci: slepa pega večine matrik

Podobdelovalci so točka, kjer deljena odgovornost postane resnično tveganje dobavne verige.

Ponudnik SaaS je lahko vaš obdelovalec po GDPR. Ta ponudnik se lahko zanaša na ponudnika gostovanja v oblaku, CDN, analitično storitev, platformo za podporo, storitev dostave e-pošte, upravljano podatkovno bazo, ponudnika opazljivosti in obdelovalca plačil. Nekateri lahko dostopajo do osebnih podatkov. Nekateri lahko podpirajo kritično izvajanje storitve, ne da bi neposredno videli podatke. Nekateri so lahko zunaj EU. Nekateri so zamenljivi. Drugi lahko ustvarijo tveganje koncentracije.

DORA Article 29 zahteva oceno tveganja koncentracije za kritične ali pomembne IKT-storitve, vključno z zamenljivostjo, več dogovori z istimi ali povezanimi ponudniki, verigami podizvajanja, podizvajalci iz tretjih držav, insolvenčnim pravom, omejitvami obnovitve podatkov in izvršljivostjo varstva podatkov Unije. DORA Article 30 zahteva pogodbene določbe o pogojih podizvajanja, lokacijah, obdelavi in hrambi podatkov, dostopu in obnovitvi, pomoči pri incidentih, sodelovanju z organi, pravicah do revizije, odpovedi in izhodu.

NIS2 Article 21 podobno zahteva varnost dobavne verige za neposredne dobavitelje in ponudnike storitev ter upoštevanje ranljivosti, specifičnih za dobavitelja, praks kibernetske varnosti dobaviteljev in postopkov varnega razvoja.

Zato Clarysec obravnava mapiranje podobdelovalcev kot obvezno razširitev upravljanja dobaviteljev, ne kot seznam samo za zasebnost. Register podobdelovalcev mora pokazati, kateri dobavitelj uporablja podobdelovalca, od katere storitve je odvisen, ali se obdelujejo osebni podatki, ali podpira kritično funkcijo, regijo obdelave, kadar je relevantna, prenesene obveznosti, pravice do odobritve ali ugovora, razpoložljiva zagotovila, metodo spremljanja in izhodno možnost.

Zenith Blueprint, faza Controls in Action, Step 23 določa:

»Za vsakega kritičnega dobavitelja ugotovite, ali uporablja podizvajalce (podobdelovalce), ki lahko dostopajo do vaših podatkov ali sistemov. Dokumentirajte, kako se vaše zahteve informacijske varnosti prenašajo na te stranke, bodisi prek pogodbenih pogojev vašega dobavitelja bodisi prek vaših neposrednih klavzul.«

To je raven dokazil, ki jo pričakujejo presojevalci, ko vprašajo, ali so odgovornosti v oblaku nadzorovane tudi navzdol po verigi.

Kako presojevalci testirajo isto matriko

Močna matrika deljene odgovornosti v oblaku prestane različne načine presoje, ker temelji na lastništvu, izvršljivosti in dokazilih.

Matrika ni končni cilj. Je zemljevid, ki ga presojevalci uporabljajo za testiranje, ali je sistem upravljanja resničen.

Presojevalec ISO lahko izbere tveganje dostopa do oblaka z velikim vplivom in mu sledi od registra tveganj do SoA, nato do pregledov pravic dostopa, dokazil MFA in opozoril spremljanja. Ocenjevalec DORA lahko izbere kritičnega ponudnika IKT ter zahteva izhodni test, analizo podizvajanja in pogodbene pravice do revizije. Pregledovalec GDPR se lahko osredotoči na izbris, lokacijo hrambe podatkov, obveščanje o kršitvah in preglednost podobdelovalcev.

Pogosti vzorci neuspeha

Najpogostejše napake pri deljeni odgovornosti niso eksotične.

Prvič, organizacije se zanašajo na poročila ponudnika o zagotovilih, ne da bi jih preslikale na odgovornosti naročnika. Ponudnik storitev v oblaku lahko dokaže fizično varnost, odpornost infrastrukture in kontrole platforme, ne pa tega, ali je bilo vaše vedro za shranjevanje zasebno, ali so vloge IAM sledile načelu najmanjših privilegijev ali ali so bili dnevniki omogočeni.

Drugič, pogodbe vsebujejo generičen varnostni jezik, vendar ne določajo rokov za obveščanje o incidentih, pravic dostopa do dnevnikov, pravic do revizije, omejitev podizvajanja, določb o vračilu podatkov ali podpore pri izhodu. Zenith Blueprint, faza Controls in Action, Step 23 poudarja tipična področja dogovorov z dobavitelji, kot so zaupnost, nadzor dostopa, tehnični in organizacijski ukrepi, roki za obveščanje o incidentih, pravica do revizije, kontrole podizvajalcev in določbe ob koncu pogodbe.

Tretjič, podobdelovalci so navedeni za namene zasebnosti, vendar niso povezani z varnostjo, neprekinjenim poslovanjem ali tveganjem koncentracije. Nadaljnji ponudnik opazljivosti ali podpore se morda nikoli ne pojavi v registru tveganj, čeprav bi njegov izpad ali kršitev lahko vplivala na izvajanje storitev za stranke.

Četrtič, SoA navaja, da je kontrola uporabna, vendar nihče ne more predložiti operativnih dokazil. Beleženje v oblaku je lahko označeno kot implementirano, organizacija pa ne more dokazati nastavitev hrambe, pregledov pravic dostopa, obravnave opozoril ali zavez ponudnika glede dostopa do dnevnikov.

Petič, načrti odzivanja na incidente ne odražajo odvisnosti od ponudnika. Če ponudnik sporoči incident platforme, kdo oceni vpliv na stranke? Kdo določi, ali je potrebno obvestilo po NIS2, DORA ali GDPR? Kdo kontaktira prizadete stranke? Kaj, če je temeljni vzrok pri podobdelovalcu?

Odgovornost vodstva: zakaj mora biti upravni odbor pozoren

NIS2 Article 20 od organov vodenja zahteva, da odobrijo ukrepe za obvladovanje kibernetskih tveganj, nadzirajo implementacijo in se usposabljajo. DORA Article 5 od organa vodenja zahteva, da opredeli, odobri in nadzira ureditve upravljanja IKT-tveganj ter je zanje odgovoren, vključno s politikami za IKT tretje osebe, načrti neprekinjenega poslovanja in obnovitve, načrti presoj, usposabljanjem in kanali poročanja.

To spremeni namen matrike. Ni več samo varnostni delovni list. Postane dokazilo, da vodstvo ve:

• Katere storitve v oblaku podpirajo kritične operacije.
• Katere tretje osebe in podobdelovalci so pomembni.
• Katere obveznosti veljajo po pogodbah s strankami, GDPR, NIS2 in DORA.
• Katere odgovornosti ostanejo pri organizaciji.
• Katere zaveze ponudnika so pogodbeno izvršljive.
• Katere vrzeli zahtevajo financiranje, odpravo pomanjkljivosti ali sprejem tveganja.

Za mala in srednje velika podjetja je pomembna sorazmernost. Manjši subjekt ne potrebuje težke birokracije, še vedno pa potrebuje dokumentacijo, spremljanje, odporne sisteme, zaznavanje virov IKT-tveganj, identifikacijo ključnih odvisnosti od tretjih oseb, ukrepe neprekinjenega poslovanja, testiranje, pridobljene izkušnje in periodični pregled, kadar je v obsegu.

Matrika je eno najučinkovitejših sorazmernih orodij, ker združuje obveznosti, namesto da bi jih množila.

30-dnevni sprint, da bo vaš model oblaka pripravljen na presojo

Če ne morete odgovoriti, kdo je lastnik posamezne kontrole v oblaku, katera dokazila to dokazujejo in kateri podobdelovalec lahko nanjo vpliva, je vaš model deljene odgovornosti še vedno diagram, ne artefakt upravljanja.

Praktični 30-dnevni sprint je videti tako:

1. Ustvarite ali posodobite register storitev v oblaku z uporabo Politike uporabe storitev v oblaku ali Politike uporabe storitev v oblaku - SME.
2. Identificirajte kritične storitve, obdelavo osebnih podatkov, sisteme, namenjene strankam, ter relevantnost za DORA ali NIS2.
3. Prvo matriko zgradite okoli kontrol iz Priloge A ISO/IEC 27001:2022 5.20, 5.21 in 5.23 z uporabo Zenith Controls.
4. Vsako vrstico povežite z registrom tveganj in Izjavo o uporabnosti z uporabo Step 13 iz Zenith Blueprint.
5. Preverite klavzule dobaviteljev in obdelovalcev z uporabo Politike varnosti tretjih oseb in dobaviteljev, Politike varnosti tretjih oseb in dobaviteljev - SME ter Politike varstva podatkov in zasebnosti.
6. Dodajte dokazila o hrambi dnevnikov, eskalaciji incidentov, odobritvi podobdelovalcev, pravicah do revizije in izhodu.
7. Kritične dobavitelje preglejte letno ter po večjih spremembah, incidentih, novih podobdelovalcih ali ugotovitvah presoje.

Cilj je preprost. Ko stranka, presojevalec, regulator ali upravni odbor vpraša »kdo je lastnik te kontrole?«, ne iščete po pogodbah, zahtevkih in mapah. Odprete matriko, pokažete lastnika, pokažete klavzulo, pokažete dokazila in pokažete sled navzdol po verigi.

Clarysec vam lahko pomaga pretvoriti pakete zagotovil ponudnikov storitev v oblaku v integrirano matriko deljene odgovornosti za presoje ISO/IEC 27001:2022, pripravljenost na NIS2, IKT-tveganja tretjih oseb po DORA, odgovornost po GDPR in skrbni pregled poslovnih strank.

Začnite z registrom. Zgradite matriko. Priložite dokazila. Nato jo uporabite kot dokazilo za upravni odbor, da tveganje v oblaku ni oddano zunanjim izvajalcem, temveč se upravlja.