Upravljanje oblačnih regij za GDPR, NIS2 in DORA

Ob 08:17 v torek zjutraj Maria, vodja informacijske varnosti hitro rastočega evropskega fintech podjetja, prejme sporočilo, ki se ga prej ali slej ustraši vsak reguliran naročnik storitev v oblaku.

Ekipa za nabavo posreduje kratko obvestilo dobavitelja:

“Naš ponudnik analitike v oblaku zaradi zmogljivostnih razlogov seli telemetrijo strank iz EU v novo regijo. Navajajo, da to nima vpliva na varnost. Ali lahko odobrimo?”

Preden Maria odgovori, prispe drugo obvestilo glavnega ponudnika storitev v oblaku. Čez 90 dni bo ponudnik začel “optimizirati svoj globalni model podpore” tako, da bo zahtevke za podporo druge ravni usmerjal prek novega podobdelovalca. Hiter pregled pokaže, da ima podobdelovalec sedež v državi brez sklepa o ustreznosti po GDPR.

Do 09:00 so se razpravi pridružili pravna služba, funkcija zasebnosti, odpornost, nabava, inženiring oblaka in finančna skladnost. Pooblaščena oseba za varstvo podatkov (DPO) vpraša, ali je potrebna ocena učinka prenosa. Vodja odpornosti vpraša, ali nova regija vpliva na načrt obnovitve za kritično storitev. Vodja finančne skladnosti vpraša, ali je ponudnik naveden v registru tretjih ponudnikov IKT po DORA. Ekipa za oblak preveri produkcijsko podatkovno ravnino in ugotovi, da je vprašanje širše od analitike. V obseg lahko spadajo varnostne kopije, operativni dnevniki, zahtevki za podporo, izvozi iz podatkovnega jezera, nujni privilegirani dostop in dostop podizvajalcev.

To je dejanski problem upravljanja oblaka v letu 2026.

Večina organizacij ima politiko uporabe storitev v oblaku. Mnoge imajo evidenco dobaviteljev. Nekatere imajo presojo prenosov po GDPR. Manj jih lahko z dokazili odgovori na zahtevnejše revizijsko vprašanje:

Kje natančno se nahajajo regulirani podatki in kritična obdelava IKT, kdo lahko do njih dostopa in od kod, kaj se zgodi ob preklopu na rezervno okolje ter katera pogodbena kontrola ponudniku preprečuje, da bi odgovor spremenil brez odobritve?

To je upravljanje oblačnih regij. Ni ena sama pravna kljukica. Je živ sistem kontrol v okviru ISO/IEC 27001:2022, kontrol za oblak in dobavitelje po ISO/IEC 27002:2022, odgovornosti po GDPR, odpornosti storitev po NIS2 in nadzora nad tretjimi ponudniki IKT po DORA.

Lokacija hrambe podatkov je zdaj operativna kontrola

Leta se je “gostovanje samo v EU” obravnavalo kot klavzula v pogodbi o obdelavi osebnih podatkov. To ne zadostuje več. Sodoben program lokacije hrambe podatkov v oblaku in upravljanja regij mora zajemati najmanj šest operativnih ravni:

1. Primarne produkcijske regije za hrambo in obdelavo.
2. Regije za varnostno kopiranje, arhiviranje in obnovitev po nesreči.
3. Lokacije podatkov za beleženje, spremljanje, SIEM in opazljivost.
4. Podporni dostop, vključno z oddaljenim upravljanjem in nujnim privilegiranim dostopom.
5. Podobdelovalce in podizvajalce, vključno s ponudniki upravljanih storitev in komponentami iz tržnic.
6. Poti prenosa podatkov med okolji, API-ji, analitičnimi platformami in orodji za podporo strankam.

GDPR to zahteva, ker lahko osebni podatki vključujejo spletne identifikatorje, naslove IP, identifikatorje računov strank, uporabniške zapise, identifikatorje naprav, operativne metapodatke in zapise podpore. Tudi obdelava je opredeljena široko ter vključuje hrambo, dostop, uporabo, razkritje, izbris in uničenje. “Pošiljamo samo dnevnike” ni varna izjema, če ti dnevniki vsebujejo identifikatorje.

GDPR Article 5 vključuje tudi načelo odgovornosti. Upravljavci ne smejo le upoštevati načel zakonitosti, poštenosti, preglednosti, omejitve namena, najmanjšega obsega podatkov, omejitve hrambe, celovitosti in zaupnosti. Skladnost morajo biti sposobni tudi dokazati. Upravljanje oblačnih regij je eden od načinov, kako to dokazovanje postane izvedljivo.

NIS2 razširja vprašanje z zasebnosti na odpornost. Po Article 21 morajo bistveni in pomembni subjekti izvajati ustrezne tehnične, operativne in organizacijske ukrepe za obvladovanje tveganj za omrežne in informacijske sisteme, ki se uporabljajo za poslovanje ali izvajanje storitev. Navedeni ukrepi vključujejo varnost dobavne verige, neprekinjeno poslovanje, upravljanje varnostnega kopiranja, obnovitev po nesreči, krizno upravljanje, nadzor dostopa, upravljanje sredstev, šifriranje in oceno učinkovitosti. Če odločitev o oblačni regiji vpliva na razpoložljivost ali obnovitev storitve v obsegu, to ni le vprašanje varstva podatkov. Je vprašanje odpornosti.

Za finančne subjekte DORA dodatno zvišuje standard. DORA se uporablja od 17. januarja 2025 in določa zahteve za upravljanje IKT-tveganj, poročanje o incidentih, testiranje digitalne operativne odpornosti, upravljanje tveganj tretjih ponudnikov IKT in pogodbene ureditve. Article 28 od finančnih subjektov zahteva, da tveganje tretjih ponudnikov IKT obvladujejo kot sestavni del okvira upravljanja IKT-tveganj, vodijo evidence pogodbenih ureditev, ocenjujejo tveganje koncentracije in načrtujejo izstop za kritične ali pomembne funkcije. Article 30 pričakuje pogodbeno jasnost glede lokacij izvajanja storitev in obdelave podatkov, pravic do revizije in dostopa, podpore pri incidentih, podizvajanja, obnovitve, vračila in prehoda ob izstopu.

DORA deluje kot sektorsko specifičen režim za finančne subjekte, medtem ko je NIS2 še vedno pomembna v širši dobavni verigi, zlasti za ponudnike storitev računalništva v oblaku, ponudnike podatkovnih centrov in ponudnike upravljanih storitev. En sam nepreverjen podobdelovalec lahko zato sproži verižno reakcijo na področju finančne odpornosti, varnosti dobavne verige in obveznosti varstva zasebnosti.

Preprosto povedano: če regulirano podjetje ne more upravljati, kje poteka njegova obdelava v oblaku, ne more verodostojno obvladovati tveganja tretjih ponudnikov IKT.

Uporabite ISO 27001 kot sidro sistema upravljanja

ISO/IEC 27001:2022 zagotavlja strukturo, s katero se nejasnost glede lokacije hrambe spremeni v nadzorovan sistem upravljanja.

Klavzule 4.1 do 4.4 zahtevajo, da organizacija opredeli ISMS v kontekstu, vključno z notranjimi in zunanjimi vprašanji, zahtevami zainteresiranih strani, pravnimi, regulativnimi in pogodbenimi obveznostmi, vmesniki ter odvisnostmi od drugih organizacij. Za upravljanje oblačnih regij mora obseg ISMS izrecno vključevati storitve v oblaku, zunanje izvajano obdelavo IKT, odvisnosti kritičnih storitev in tokove reguliranih podatkov.

Klavzule 5.1 do 5.3 vzpostavljajo odgovornost vodstva. Najvišje vodstvo mora politiko informacijske varnosti in cilje uskladiti s strateško usmeritvijo, zagotoviti vire, dodeliti odgovornosti in zagotoviti poročanje o uspešnosti ISMS. Tu lokacija hrambe v oblaku postane tema vodstva in upravnega odbora, zlasti pri subjektih NIS2, kjer morajo organi upravljanja odobriti in nadzorovati ukrepe za obvladovanje tveganj kibernetske varnosti, ter pri finančnih subjektih DORA, kjer je organ upravljanja odgovoren za upravljanje IKT-tveganj.

Klavzule 6.1.1 do 6.1.3 zagotavljajo mehanizem tveganj. Organizacija potrebuje ponovljiv proces ocenjevanja tveganj, lastnike tveganj, merila vpliva in verjetnosti, možnosti obravnave tveganj, izbrane kontrole, izjavo o uporabnosti (SoA) in sprejem preostalega tveganja. Sprememba oblačne regije se ne sme odobriti z neformalnim e-poštnim sporočilom. Kadar vpliva na regulirane podatke, kritične funkcije, dobavitelje ali predpostavke neprekinjenega poslovanja, mora sprožiti oceno tveganja ali pregled spremembe.

Klavzula 8.1 spremeni načrtovanje v operativni nadzor. Procese je treba izvajati, nadzorovati, dokumentirati, spreminjati na upravljan način in razširiti na zunanje zagotovljene izdelke in storitve, pomembne za ISMS. Klavzuli 8.2 in 8.3 zahtevata ponovno oceno in obravnavo v načrtovanih intervalih ali ob pomembnih spremembah. Migracija oblačne regije, replikacija varnostnih kopij, nova platforma za beleženje ali sprememba podpornega podobdelovalca so vsi kandidati za ponovno oceno.

Nabor kontrol ISO/IEC 27002:2022 nato zagotavlja praktično družino kontrol. Najpomembnejše kontrole vključujejo:

• 5.9 Popis informacij in drugih povezanih sredstev.
• 5.14 Prenos informacij.
• 5.15 Nadzor dostopa.
• 5.19 Informacijska varnost v odnosih z dobavitelji.
• 5.20 Obravnava informacijske varnosti v sporazumih z dobavitelji.
• 5.22 Spremljanje, pregled in upravljanje sprememb storitev dobaviteljev.
• 5.23 Informacijska varnost pri uporabi storitev v oblaku.
• 5.29 Informacijska varnost med motnjo.
• 5.30 Pripravljenost IKT za neprekinjeno poslovanje.
• 5.31 Pravne, zakonske, regulativne in pogodbene zahteve.
• 5.34 Zasebnost in varstvo osebno določljivih podatkov.
• 5.36 Skladnost s politikami, pravili in standardi za informacijsko varnost.
• 8.11 Maskiranje podatkov.
• 8.12 Preprečevanje uhajanja podatkov.
• 8.13 Varnostno kopiranje informacij.
• 8.15 Beleženje.
• 8.16 Dejavnosti spremljanja.
• 8.20 Varnost omrežij.
• 8.24 Uporaba kriptografije.
• 8.25 Življenjski cikel varnega razvoja.
• 8.27 Varna arhitektura sistema in inženirska načela.
• 8.32 Upravljanje sprememb.

Clarysecov Zenith Controls: The Cross-Compliance Guide Zenith Controls obravnava kontrolo ISO/IEC 27002:2022 5.23, informacijska varnost pri uporabi storitev v oblaku, kot preventivno kontrolo, ki podpira zaupnost, celovitost in razpoložljivost, z operativno zmogljivostjo na področju varnosti odnosov z dobavitelji in varnostnih domen v upravljanju, ekosistemu in zaščiti. Vodnik povezuje 5.23 s 5.19 odnosi z dobavitelji, 5.14 prenos informacij, 5.9 popis sredstev, 8.11 in 8.12 maskiranje podatkov in preprečevanje uhajanja podatkov, 8.20 varnost omrežja in 8.25 življenjski cikel varnega razvoja.

Ključna ugotovitev iz Zenith Controls je:

“Ponudniki storitev v oblaku (CSP) delujejo kot kritični dobavitelji, zato zanje veljajo vse kontrole glede izbire dobaviteljev, sklepanja pogodb in upravljanja tveganj po 5.19. Vendar 5.23 presega to raven, saj obravnava tveganja, specifična za oblak, kot so večnajemništvo, preglednost lokacije podatkov in modeli deljene odgovornosti.”

Ta stavek zajame premik v upravljanju. Ponudnik storitev v oblaku ni le še en dobavitelj. Pogosto je kraj, kjer se izvaja regulirana obdelava.

Skrite pasti lokacije hrambe: varnostne kopije, dnevniki, podpora in podobdelovalci

Večina napak pri lokaciji hrambe podatkov se ne začne pri produkcijski podatkovni bazi. Začnejo se pri podpornih sistemih, ki nikoli niso bili ustrezno vključeni v pregled tokov podatkov.

Varnostne kopije so klasičen primer. Platforma SaaS lahko deluje v Frankfurtu ali Dublinu, avtomatizirane varnostne kopije pa se zaradi odpornosti ali stroškov replicirajo drugam. Če varnostna kopija vsebuje osebne podatke, evidence o strankah, dnevnike avtentikacije ali regulirano zgodovino transakcij, je regija varnostne kopije pomembna. Po NIS2 Article 21 sta upravljanje varnostnega kopiranja in obnovitev po nesreči del osnovne varnostne ravni. Po DORA neprekinjenost kritičnih ali pomembnih funkcij in preizkušene izstopne strategije zahtevajo poznavanje lokacij obnovitve in odvisnosti pri obnovitvi.

Dnevniki so še ena šibka točka. Varnostne ekipe centralizirajo telemetrijo v SIEM, storitve opazljivosti in podatkovna jezera. Ti dnevniki lahko vključujejo naslove IP, uporabniške identifikatorje, dejanja administratorjev, plačilne metapodatke, neuspešne poskuse avtentikacije, identifikatorje računov strank ali podatke sledi podpore. Če se dnevniki premaknejo v globalno storitev spremljanja, je organizacija morda ustvarila čezmejni prenos, ne da bi se tega zavedala.

Clarysecova Politika beleženja in spremljanja za MSP Politika beleženja in spremljanja - MSP neposredno obravnava dokazila dobaviteljev:

“Pogodbe morajo od ponudnikov zahtevati, da dnevnike hranijo najmanj 12 mesecev in na zahtevo omogočijo dostop.”

Ta navedek je iz razdelka “Zahteve upravljanja”, klavzula politike 5.5.1.3. Pri upravljanju lokacije hrambe podatkov mora isti pregled pogodbe potrditi, kje se ti dnevniki hranijo, kdo lahko do njih dostopa in ali so dokazila iz dnevnikov na voljo med preiskavo incidenta ali regulatorno poizvedbo.

Podporni dostop je bolj subtilen. Ponudnik lahko gosti podatke v EU, medtem ko lahko podporni inženirji zunaj EU dostopajo do okolij strank, posnetkov podatkovnih baz, diagnostičnih paketov ali priponk zahtevkov. Sprejemljivost tega je odvisna od zadevnih podatkov, mehanizma prenosa, vloge, pogodbenih zaščitnih ukrepov, kontrol dostopa in beleženja. Arhitektura je lahko regionalna, model človeškega dostopa pa globalen.

Podobdelovalci ustvarjajo zadnjo slepo pego. Vaš neposredni dobavitelj se lahko opira na infrastrukturo v oblaku, omrežja za dostavo vsebin, upravljane podatkovne baze, sisteme za upravljanje zahtevkov, analitične storitve, oddaljene ekipe v tujini ali varnostne dobavitelje. DORA Article 29 zahteva presojo tveganj podizvajanja, ponudnikov iz tretjih držav, omejitev pri obnovitvi podatkov, skladnosti varstva podatkov in kompleksnih podizvajalskih verig. NIS2 Article 21 od subjektov zahteva, da upoštevajo prakse kibernetske varnosti neposrednih dobaviteljev in izvajalcev storitev. GDPR od obdelovalcev zahteva upravljanje podobdelovalcev na način, ki ohranja sposobnost upravljavca za skladnost.

Clarysecova Politika varnosti tretjih oseb in dobaviteljev za MSP Politika varnosti tretjih oseb in dobaviteljev - MSP to operacionalizira:

“Kadar morajo dobavitelji hraniti podatke zunaj lokacije, mora podjetje pridobiti zagotovilo glede varstva podatkov, fizične varnosti in geografske lokacije hrambe (npr. gostovanje samo v EU, kadar to zahteva GDPR).”

To je iz razdelka “Zahteve za izvajanje politike”, klavzula politike 6.2.4. Ista politika zahteva tudi:

“Omejitve nadaljnjega podizvajanja brez odobritve.”

Ta navedek je iz razdelka “Zahteve upravljanja”, klavzula politike 5.3.5. Skupaj te klavzule lokacijo hrambe spremenijo v delovni tok upravljanja dobaviteljev, ne v nabavno preferenco.

Politiko spremenite v izvršljivo upravljanje oblačnih regij

Upravljanje oblačnih regij mora biti izvršljivo, pregledno in preverljivo.

Za MSP Politika uporabe storitev v oblaku za MSP Politika uporabe storitev v oblaku - MSP določa osnovno raven:

“Prakse lokacije hrambe podatkov in zasebnosti morajo biti skladne z veljavnimi pravnimi zahtevami (npr. GDPR).”

To je iz razdelka “Zahteve upravljanja”, klavzula politike 5.2.3. Ista politika zahteva, da evidence upravljanja oblaka vključujejo:

“Državo ali regijo, kjer se podatki hranijo.”

Ta navedek je iz razdelka “Zahteve upravljanja”, klavzula politike 5.3.4.

Za večje organizacije je Politika uporabe storitev v oblaku Politika uporabe storitev v oblaku bolj izrecna glede pogodbenega uveljavljanja:

“Zahteve glede lokacije hrambe podatkov morajo biti pogodbeno uveljavljene (npr. hramba samo v EU za podatke, regulirane po GDPR).”

To je iz razdelka “Zahteve za izvajanje politike”, klavzula politike 6.6.2. Navaja tudi:

“Čezmejni prenosi podatkov morajo biti skladni s poglavjem V GDPR in, kjer je relevantno, z DORA Article 28.”

To je iz razdelka “Zahteve za izvajanje politike”, klavzula politike 6.6.3.

Različica za podjetja pozornost namenja tudi:

“Zagotovilom glede lokacije hrambe podatkov in lastništva podatkov.”

Ta navedek je iz razdelka “Vloge in odgovornosti”, klavzula politike 4.5.1.2.

Politika varnosti tretjih oseb in dobaviteljev Politika varnosti tretjih oseb in dobaviteljev doda pogodbeno raven z zahtevo po:

“Zahtevah glede ravnanja s podatki, vključno z lokacijo hrambe, kontrolami dostopa ter klavzulami o vračilu ali uničenju.”

Ta navedek je iz razdelka “Zahteve upravljanja”, klavzula politike 5.3.2.

Nazadnje Politika pravne in regulativne skladnosti Politika pravne in regulativne skladnosti opredeljuje spremembe, ki morajo sprožiti pregled skladnosti, vključno s:

“Spremembami mehanizmov prenosa podatkov, podobdelovalcev ali čezmejnih tokov podatkov.”

To je iz razdelka “Zahteve upravljanja”, klavzula politike 5.3.1.1.

Ti dokumenti ne smejo delovati kot ločene datoteke. V zrelem ISMS postanejo en operativni model: evidenca oblaka, register tokov podatkov, evidenca dobaviteljev, matrika pogodb, ocena tveganja, pregled prenosa, odobritev spremembe in paket presojevalnih dokazil.

Vzpostavite register upravljanja oblačnih regij

Praktičen register spremeni lokacijo hrambe v oblaku iz predpostavke v dokazilo. Začnite z eno kritično storitvijo, namenjeno strankam, zlasti tako, ki bo verjetno spadala v obseg NIS2, skrbnega pregleda strank po DORA ali preverjanja po GDPR.

Zdaj register povežite z izvajanjem.

V Clarysecovem Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint se faza Kontrole v praksi, korak 23, osredotoča na organizacijske ukrepe 5.19 do 5.37, vključno s sporazumi z dobavitelji in upravljanjem storitev v oblaku. Blueprint opozarja, da morajo sporazumi z dobavitelji zajemati več kot splošno zaupnost:

“V številnih panogah sporazumi z dobavitelji opredeljujejo tudi lastništvo podatkov in jurisdikcijo. Kje se podatki obdelujejo? Kdo ohranja nadzor? Ali obstajajo omejitve prenosa? Ali obstajajo kontrole, specifične za oblak (na primer segmentacija podatkov, lastništvo ključev ali geografske omejitve)? Ti elementi niso le pravna vprašanja, temveč operativna vprašanja informacijske varnosti, zlasti v reguliranih sektorjih.”

Ista faza in korak obravnavata upravljanje sprememb dobaviteljev:

“Večina odnosov z dobavitelji se začne z dobrimi nameni. Temeljit pregled, jasna pričakovanja, podpisani sporazumi (glej 5.20), morda celo varnostni kontrolni seznam. Kaj pa se zgodi leto pozneje, ko dobavitelj predlaga selitev vaših podatkov v novo oblačno regijo?”

To je Marijin torkov jutranji problem. Register CISO omogoča, da odgovori pred odobritvijo selitve.

Zenith Blueprint pojasni tudi upravljavski pomen kontrole oblaka 5.23:

“Napačno konfigurirano vedro za shranjevanje, javno izpostavljena nadzorna plošča ali prekomerna dovoljenja v nastavitvi IAM v oblaku niso odpovedi oblaka. So odpovedi upravljanja.”

V fazi Kontrole v praksi, korak 22, Blueprint obravnava prenos informacij in navaja:

“Če se osebni podatki prenašajo čez meje, mora biti metoda skladna z obveznostmi glede zasebnosti in pravnimi obveznostmi, ne le z internimi preferencami.”

Ta poved je pomembna za ekipe za oblak. Šifriranje, varni API-ji in zasebna povezljivost so potrebni, vendar ne nadomeščajo pravnega in regulativnega upravljanja prenosov.

Izvedite prvo 90-minutno delavnico o dokazilih

Ne začnite z mapiranjem celotnega podjetja. Začnite z eno kritično storitvijo in izvedite osredotočeno delavnico z inženiringom oblaka, nabavo, pravno službo, zasebnostjo, odpornostjo in varnostnimi operacijami.

Najprej naštejte vsako komponento oblaka ali dobavitelja, ki storitev hrani, obdeluje, prenaša, varnostno kopira, spremlja ali podpira. Vključite manjše sisteme, kot so spremljanje razpoložljivosti, priponke zahtevkov, sledenje napakam, orodja za deljenje zaslona pri podpori in diagnostični izvozi.

Drugič, označite vsako kategorijo podatkov. Če ekipa reče “samo metapodatki”, izpodbijte predpostavko. Metapodatki so lahko še vedno osebni podatki ali zaupni podatki strank.

Tretjič, regijo preverite z dokazili. Uporabite konfiguracijo konzole oblaka, politike varnostnega kopiranja, nastavitve okolja SIEM, priloge DPA, sezname podobdelovalcev, pogodbene pogoje, dokumentacijo podpornega dostopa in revizijska poročila CSP. Ne zanašajte se samo na prodajna zagotovila.

Četrtič, vrzeli zabeležite v register tveganj ISMS. Primeri vključujejo “regija replikacije varnostnih kopij ni pogodbeno omejena”, “podporni dostop iz tretje države nima dokumentiranega odobritvenega delovnega toka”, “dnevniki SIEM se hranijo globalno”, “seznam podobdelovalcev ne identificira regije gostovanja” ali “register DORA ne razlikuje odvisnosti kritične ali pomembne funkcije”.

Petič, odločite o obravnavi tveganja. Obravnave lahko vključujejo spremembo pogodbe, zaklep regije, obvestilo stranki, šifriranje s ključi, ki jih upravlja naročnik (CMK), tokenizacijo, minimizacijo dnevnikov, odobritev novega dobavitelja, posodobitev izstopne strategije ali sprejem preostalega tveganja s strani lastnika tveganja.

Šestič, ohranite dokazila. Presojevalci ne bodo vprašali le, kaj ste se odločili. Vprašali bodo, kako veste, da je bilo izvedeno.

En sklop dokazil preslikajte na ISO, GDPR, NIS2, DORA in NIST CSF 2.0

Močan program upravljanja oblačnih regij se izogiba podvajanju dela za skladnost. Ista dokazila lahko podpirajo več obveznosti, če so pravilno strukturirana.

NIST CSF 2.0 je uporaben kot povezovalna plast. Njegova funkcija GOVERN se usklajuje s pravnimi, regulativnimi, pogodbenimi in zasebnostnimi obveznostmi, apetitom po tveganju, odgovornostjo, politikami in nadzorom. Njegova kategorija dobavne verige GV.SC se dobro preslika na pričakovanja DORA za tretje ponudnike IKT, zahteve NIS2 glede dobavne verige in kontrole dobaviteljev po ISO.

COBIT 2019 in revizijski vidik ISACA pogosto preverjata ista dejstva skozi cilje upravljanja: lastništvo, pravice odločanja, optimizacijo tveganj, uspešnost dobaviteljev, uresničevanje koristi in zagotovila. Pregledovalec v slogu COBIT morda ne bo začel z vprašanjem “katera oblačna regija je konfigurirana?”. Lahko začne z vprašanjem “kdo ima pooblastilo za odobritev spremembe regije, kako se tveganje eskalira in kako vodstvo ve, da dobavitelji oblaka ostajajo znotraj tolerance?”

Zato model Clarysec zajema lastnike, odobritvene točke, pogodbena dokazila in poročanje vodstvu, ne le tehničnih nastavitev.

Pripravite se na vprašanja presojevalcev

Upravljanje oblačnih regij je odličen primer, kako različni presojevalci isto kontrolo obravnavajo z različnih zornih kotov.

Presojevalec ISO/IEC 27001:2022 bo začel z obsegom, zahtevami zainteresiranih strani, oceno tveganja in izjavo o uporabnosti. Vprašal bo, ali so pravne, regulativne in pogodbene zahteve identificirane, ali so kontrole oblaka in dobaviteljev vključene, ali so bila tveganja ocenjena, ali so kontrole izvedene in ali se dokazila hranijo. Lahko vzorči eno storitev v oblaku in zahteva pregled uvajanja, pogodbene klavzule, konfiguracijo regije, pregled spremljanja in odobritev spremembe.

Nadzorni organ za varstvo podatkov ali pregledovalec GDPR se bo osredotočil na osebne podatke. Vprašal bo, kateri osebni podatki se obdelujejo, kje se hranijo, od kod se do njih dostopa, kateri obdelovalci in podobdelovalci so vključeni, ali so mehanizmi prenosa dokumentirani, ali je potrebna ocena učinka prenosa in ali so vzpostavljeni ustrezni tehnični in organizacijski ukrepi. Dnevniki, podporni podatki in varnostne kopije so pogosto deležni pozornosti, ker jih organizacije podcenjujejo.

Presojevalec NIS2 ali pristojni organ se bo osredotočil na storitve v obsegu. Preveril bo odgovornost vodstva po Article 20, ukrepe obvladovanja tveganj po Article 21, neprekinjenost, upravljanje varnostnega kopiranja, obnovitev po nesreči, obravnavanje incidentov, varnost dobavne verige, nadzor dostopa, upravljanje sredstev in oceno učinkovitosti.

Nadzornik DORA ali skupina za notranjo revizijo bo iskala upravljanje IKT-tveganj, nadzor organa upravljanja, register informacij za ureditve s tretjimi ponudniki IKT, mapiranje kritičnih ali pomembnih funkcij, tveganje koncentracije, tveganje podizvajanja, lokacije obdelave podatkov, pravice do revizije, podporo pri poročanju o incidentih, testiranje neprekinjenosti in izstopne načrte. DORA jasno določa, da zunanje izvajanje ne prenese odgovornosti.

Zenith Controls vodjem varnosti pomaga pri pripravi na te revizijske sloge, ker navzkrižno sklicuje razmerja med kontrolami. Pri kontroli ISO/IEC 27002:2022 5.20, obravnava informacijske varnosti v sporazumih z dobavitelji, Zenith Controls jo povezuje s 5.19 odnosi z dobavitelji, 5.14 prenos informacij, 5.22 spremljanje dobaviteljev, 5.11 vračilo sredstev in 5.36 skladnost s politikami, pravili in standardi. Pri kontroli 5.22, spremljanje, pregled in upravljanje sprememb storitev dobaviteljev, povezuje stalni nadzor nad dobavitelji s 5.29 varnostjo med motnjo, 8.8 upravljanjem tehničnih ranljivosti, 5.15 nadzorom dostopa, 8.27 varno arhitekturo sistema in inženirskimi načeli ter 5.36 skladnostjo.

Ta pogled čez več kontrol je pomemben, ker sprememba regije nikoli ni samo sprememba regije. Lahko spremeni tveganje dobavitelja, tveganje prenosa, tveganje dostopa, tveganje neprekinjenosti, dokazila odziva na incidente in pogodbeno skladnost.

Uporabite ta kontrolni seznam CISO za leto 2026 pred odobritvijo spremembe v oblaku

Ta kontrolni seznam uporabite pred odobritvijo nove oblačne regije, poti čezmejne obdelave, lokacije varnostnega kopiranja, platforme za beleženje, modela podpore ali spremembe kritičnega dobavitelja IKT.

Če je odgovor na katero koli vprašanje “predpostavljamo”, kontrola ni dovolj zrela za regulirano poslovanje.

Načrt odprave vrzeli

Pot odprave vrzeli je praktična, kadar je zasidrana v ISMS.

1. Potrdite, da obseg ISMS vključuje storitve v oblaku, kritične odvisnosti IKT in obdelavo reguliranih podatkov.
2. Vzpostavite register upravljanja oblačnih regij za prednostne storitve.
3. Vsako storitev preslikajte na kategorije podatkov, regije, lokacije varnostnih kopij, podporni dostop in podobdelovalce.
4. Preglejte sporazume z dobavitelji glede lokacije hrambe, prenosa, revizije, incidentov, podizvajanja, vračila in klavzul o uničenju.
5. Posodobite register tveganj za vrzeli, tveganja koncentracije in nedokumentirane prenose.
6. Kjer je relevantno, uskladite register tretjih ponudnikov IKT po DORA in mapiranje odvisnosti storitev po NIS2.
7. Preverite tehnično uveljavljanje, vključno z zaklepi regij, politikami varnostnega kopiranja, nastavitvami beleženja, šifriranjem, kontrolami dostopa in upravljanjem ključev.
8. Pripravite paket presojevalnih dokazil s posnetki zaslona, pogodbami, zapisi tveganj, odobritvami, zapisniki pregledov in rezultati testiranja.
9. Vzpostavite sprožilec spremembe za nove regije, podobdelovalce, mehanizme prenosa ali spremembe kritičnih storitev dobaviteljev.
10. Vodstvu poročajte o tveganju lokacije hrambe v oblaku, izjemah in odločitvah o sprejemu preostalega tveganja.

To ni teoretična skladnost. To je razlika med oblačnim okoljem, ki prestane presojevalno preverjanje, in okoljem, ki temelji na ustnih zagotovilih.

Poslovni primer: suverenost, odpornost in zaupanje

Izvršno vodstvo upravljanje lokacije hrambe podatkov včasih vidi kot omejitev agilnosti v oblaku. V praksi zrelo upravljanje regij izboljša agilnost, ker ekipe poznajo pravila, preden kupujejo, gradijo ali migrirajo.

Produktna ekipa lahko hitreje lansira, ko so odobrene regije jasne. Nabava se lahko hitreje pogaja, ko so obvezne klavzule že opredeljene. Pravna služba lahko hitreje presoja prenose, ko so tokovi podatkov dokumentirani. Varnostne operacije lahko hitreje preiskujejo, ko so lokacije dnevnikov in pravice dostopa znane. Upravni odbor lahko hitreje sprejema odločitve o tveganjih, ko so tveganje koncentracije, vpliv na neprekinjenost in sprejem preostalega tveganja vidni.

Za stranke, zlasti regulirane stranke, to postane signal zaupanja. Ponudnik SaaS, ki zna pojasniti, kje se podatki nahajajo, kako se upravljajo varnostne kopije, kako je nadzorovan podporni dostop, kako se odobrijo podobdelovalci in kako se pregledujejo spremembe regij, bo uspešnejši od ponudnika, ki pove samo “uporabljamo vodilnega ponudnika oblaka”.

V letu 2026 je ta razlika pomembna. NIS2 je upravljanje kibernetske varnosti prinesla bistvenim in pomembnim subjektom po vsej EU. DORA je nadzor nad tretjimi ponudniki IKT spremenila v formalno disciplino finančnega sektorja. Odgovornost po GDPR ostaja osrednja. ISO/IEC 27001:2022 zagotavlja sistem upravljanja, ki vse to povezuje.

Naslednji koraki s Clarysec

Če vaša organizacija ne more odgovoriti, kje se regulirani podatki in kritična obdelava IKT nahajajo v produkciji, varnostnih kopijah, dnevnikih, podpornem dostopu in pri podizvajalcih, je zdaj čas, da zaprete vrzel.

Clarysec vam lahko pomaga vzpostaviti paket dokazil za upravljanje oblačnih regij z uporabo:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint za fazno implementacijo ISO in pripravljenost na presojo.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls za preslikavo kontrol oblaka in dobaviteljev po ISO/IEC 27002:2022 na operativna dokazila in pričakovanja različnih okvirov.
• Politika uporabe storitev v oblaku Politika uporabe storitev v oblaku in Politika uporabe storitev v oblaku za MSP Politika uporabe storitev v oblaku - MSP za zahteve glede lokacije hrambe podatkov v oblaku.
• Politika varnosti tretjih oseb in dobaviteljev Politika varnosti tretjih oseb in dobaviteljev in Politika varnosti tretjih oseb in dobaviteljev za MSP Politika varnosti tretjih oseb in dobaviteljev - MSP za pogodbe z dobavitelji, podizvajanje in zagotovila glede geografske hrambe.
• Politika beleženja in spremljanja za MSP Politika beleženja in spremljanja - MSP za hrambo dnevnikov in dokazila ponudnikov.
• Politika pravne in regulativne skladnosti Politika pravne in regulativne skladnosti za sprožilce pregleda skladnosti glede mehanizmov prenosa, podobdelovalcev in čezmejnih tokov podatkov.

Začnite z eno kritično storitvijo, enim ponudnikom oblaka in enim registrom. V nekaj delavnicah lahko preidete od predpostavk k dokazilom in od razdrobljene skladnosti k upravljani odpornosti v oblaku.

Prenesite zbirko orodij Clarysec, zahtevajte predstavitev ali rezervirajte presojo upravljanja oblačnih regij, da svoje zaveze glede lokacije hrambe v oblaku spremenite v dokazila, pripravljena za presojo.