Upravljanje regijama oblaka za GDPR, NIS2 i DORA

U 08:17 u utorak ujutro Maria, CISO brzorastuće europske fintech organizacije, prima poruku od koje s vremenom strepi svaki regulirani korisnik usluga u oblaku.

Tim nabave prosljeđuje kratku obavijest dobavljača:

“Naš pružatelj analitike u oblaku premješta telemetriju EU korisnika u novu regiju radi performansi. Navode da nema utjecaja na sigurnost. Možemo li odobriti?”

Prije nego što Maria stigne odgovoriti, stiže druga obavijest od primarnog pružatelja usluga u oblaku. Za 90 dana pružatelj će “optimizirati svoj globalni model podrške” usmjeravanjem prijava podrške razine 2 preko novog podizvršitelja obrade. Brzi pregled pokazuje da podizvršitelj obrade ima sjedište u zemlji za koju ne postoji odluka o primjerenosti prema GDPR.

Do 09:00 u raspravu su uključeni pravni poslovi, privatnost, otpornost, nabava, inženjering oblaka i financijska usklađenost. DPO pita je li potrebna procjena učinka prijenosa. Voditelj otpornosti pita utječe li nova regija na plan oporavka za kritičnu uslugu. Voditelj financijske usklađenosti pita pojavljuje li se pružatelj u DORA registru IKT trećih strana. Tim za oblak provjerava produkcijski podatkovni sloj i shvaća da je problem širi od analitike. Sigurnosne kopije, operativni dnevnički zapisi, prijave podršci, izvozi iz podatkovnog jezera, hitni pristup i pristup podugovaratelja mogu svi biti u opsegu.

To je stvarni problem upravljanja oblakom u 2026.

Većina organizacija ima politiku korištenja usluga u oblaku. Mnoge imaju registar dobavljača. Neke imaju procjenu prijenosa prema GDPR. Manje ih može, uz dokaze, odgovoriti na teže revizijsko pitanje:

Gdje se točno nalaze regulirani podaci i kritična IKT obrada, tko im može pristupiti i odakle, što se događa tijekom prebacivanja na pričuvnu lokaciju i koja ugovorna kontrola sprječava pružatelja da promijeni odgovor bez odobrenja?

To je upravljanje regijama oblaka. Nije riječ o jednoj pravnoj kvačici. To je živi sustav kontrola kroz ISO/IEC 27001:2022, kontrole oblaka i dobavljača iz ISO/IEC 27002:2022, odgovornost prema GDPR, otpornost usluga prema NIS2 i DORA nadzor IKT trećih strana.

Rezidentnost podataka sada je operativna kontrola

Godinama se “hosting isključivo u EU” tretirao kao odredba u ugovoru o obradi podataka. To više nije dovoljno. Suvremeni program rezidentnosti podataka u oblaku i upravljanja regijama mora obuhvatiti najmanje šest operativnih slojeva:

1. Primarne produkcijske regije za pohranu i računalnu obradu.
2. Regije za sigurnosne kopije, arhive i oporavak od katastrofe.
3. Lokacije za podatke zapisivanja događaja, praćenja, SIEM-a i observabilnosti.
4. Pristup podrške, uključujući udaljenu administraciju i hitni pristup.
5. Podizvršitelje obrade i podugovaratelje, uključujući upravljane usluge i komponente s tržišta aplikacija.
6. Putove prijenosa podataka između okruženja, aplikacijskih programskih sučelja, analitičkih platformi i alata korisničke podrške.

GDPR to čini neizbježnim jer osobni podaci mogu uključivati mrežne identifikatore, IP adrese, identifikatore korisničkih računa, korisničke evidencije, identifikatore uređaja, operativne metapodatke i zapise podrške. Obrada je također široko definirana te uključuje pohranu, pristup, uporabu, otkrivanje, brisanje i uništenje. “Šaljemo samo dnevničke zapise” nije sigurna iznimka ako ti dnevnički zapisi sadržavaju identifikatore.

GDPR Article 5 uključuje i načelo odgovornosti. Voditelji obrade ne moraju samo poštovati načela zakonitosti, poštenosti, transparentnosti, ograničenja svrhe, smanjenja količine podataka, ograničenja pohrane, cjelovitosti i povjerljivosti. Moraju također moći dokazati usklađenost. Upravljanje regijama oblaka jedan je od načina na koji to dokazivanje postaje stvarno.

NIS2 proširuje pitanje iz privatnosti u otpornost. Prema Article 21, ključni i važni subjekti moraju provoditi odgovarajuće tehničke, operativne i organizacijske mjere za upravljanje rizicima za mrežne i informacijske sustave koji se koriste za poslovanje ili pružanje usluge. Navedene mjere uključuju sigurnost opskrbnog lanca, neprekidnost poslovanja, upravljanje sigurnosnim kopijama, oporavak od katastrofe, krizno upravljanje, kontrolu pristupa, upravljanje imovinom, šifriranje i procjenu učinkovitosti. Ako odluka o regiji oblaka utječe na dostupnost ili oporavak usluge u opsegu, to nije samo pitanje zaštite podataka. To je pitanje otpornosti.

Za financijske subjekte DORA dodatno podiže standard. DORA se primjenjuje od 17. siječnja 2025. i uspostavlja zahtjeve za upravljanje IKT rizicima, prijavljivanje incidenata, testiranje digitalne operativne otpornosti, upravljanje rizicima IKT trećih strana i ugovorne aranžmane. Article 28 zahtijeva od financijskih subjekata da upravljaju IKT rizikom trećih strana kao sastavnim dijelom okvira za upravljanje IKT rizicima, održavaju registre ugovornih aranžmana, procjenjuju rizik koncentracije i planiraju izlaz za kritične ili važne funkcije. Article 30 očekuje ugovornu jasnoću o lokacijama usluga i obrade podataka, pravima na reviziju i pristup, podršci za incidente, podugovaranju, oporavku, povratu i izlaznoj tranziciji.

DORA djeluje kao sektorski poseban režim za financijske subjekte, dok je NIS2 i dalje relevantan kroz širi opskrbni lanac, posebno za pružatelje usluga računalstva u oblaku, pružatelje usluga podatkovnih centara i pružatelje upravljanih usluga. Jedan neprovjereni podizvršitelj obrade zato može stvoriti domino-učinak kroz financijsku otpornost, sigurnost opskrbnog lanca i obveze privatnosti.

Jednostavno rečeno, ako regulirana organizacija ne može upravljati time gdje se odvija njezina obrada u oblaku, ne može vjerodostojno upravljati IKT rizikom trećih strana.

Koristite ISO 27001 kao sidro sustava upravljanja

ISO/IEC 27001:2022 pruža strukturu za pretvaranje nejasnoća oko rezidentnosti u kontrolirani sustav upravljanja.

Točke 4.1 do 4.4 zahtijevaju da organizacija definira ISMS u kontekstu, uključujući unutarnja i vanjska pitanja, zahtjeve zainteresiranih strana, pravne, regulatorne i ugovorne obveze, sučelja i ovisnosti s drugim organizacijama. Za upravljanje regijama oblaka opseg ISMS-a treba izričito uključivati usluge u oblaku, eksternaliziranu IKT obradu, kritične ovisnosti usluga i regulirane tokove podataka.

Točke 5.1 do 5.3 čine vodstvo odgovornim. Najviše rukovodstvo mora uskladiti politiku informacijske sigurnosti i ciljeve sa strateškim smjerom, osigurati resurse, dodijeliti odgovornosti i osigurati izvješćivanje o učinkovitosti ISMS-a. Tu rezidentnost oblaka postaje tema uprave i odbora, posebno za subjekte prema NIS2 kod kojih upravljačka tijela moraju odobriti i nadzirati mjere upravljanja rizicima kibernetičke sigurnosti te za financijske subjekte prema DORA kod kojih je upravljačko tijelo odgovorno za upravljanje IKT rizicima.

Točke 6.1.1 do 6.1.3 pružaju mehanizam upravljanja rizicima. Organizaciji je potreban ponovljiv postupak procjene rizika, vlasnici rizika, kriteriji utjecaja i vjerojatnosti, opcije obrade rizika, odabrane kontrole, Izjava o primjenjivosti i prihvaćanje preostalog rizika. Promjena regije oblaka ne smije se odobravati neformalnom e-poštom. Mora pokrenuti procjenu rizika ili pregled promjene kada utječe na regulirane podatke, kritične funkcije, dobavljače ili pretpostavke neprekidnosti.

Točka 8.1 pretvara planiranje u operativnu kontrolu. Procesi se moraju implementirati, kontrolirati, dokumentirati, mijenjati na upravljan način i proširiti na eksterno osigurane proizvode i usluge relevantne za ISMS. Točke 8.2 i 8.3 zahtijevaju preispitivanje i obradu rizika u planiranim intervalima ili kada nastupe značajne promjene. Migracija regije oblaka, replikacija sigurnosnih kopija, nova platforma za zapisivanje događaja ili promjena podizvršitelja obrade za podršku kandidati su za preispitivanje.

Skup kontrola ISO/IEC 27002:2022 zatim pruža praktičnu obitelj kontrola. Najrelevantnije kontrole uključuju:

• 5.9 Popis informacija i druge povezane imovine.
• 5.14 Prijenos informacija.
• 5.15 Kontrola pristupa.
• 5.19 Informacijska sigurnost u odnosima s dobavljačima.
• 5.20 Uređivanje informacijske sigurnosti u ugovorima s dobavljačima.
• 5.22 Praćenje, pregled i upravljanje promjenama usluga dobavljača.
• 5.23 Informacijska sigurnost za korištenje usluga u oblaku.
• 5.29 Informacijska sigurnost tijekom poremećaja.
• 5.30 IKT spremnost za neprekidnost poslovanja.
• 5.31 Pravni, zakonski, regulatorni i ugovorni zahtjevi.
• 5.34 Privatnost i zaštita osobnih podataka (PII).
• 5.36 Usklađenost s politikama, pravilima i standardima informacijske sigurnosti.
• 8.11 Maskiranje podataka.
• 8.12 Sprječavanje curenja podataka.
• 8.13 Sigurnosno kopiranje informacija.
• 8.15 Zapisivanje događaja.
• 8.16 Aktivnosti praćenja.
• 8.20 Sigurnost mreža.
• 8.24 Korištenje kriptografije.
• 8.25 Sigurni životni ciklus razvoja softvera.
• 8.27 Sigurna arhitektura sustava i inženjerska načela.
• 8.32 Upravljanje promjenama.

Clarysecov Zenith Controls: Vodič za međusobnu usklađenost Zenith Controls tretira kontrolu ISO/IEC 27002:2022 5.23, Informacijska sigurnost za korištenje usluga u oblaku, kao preventivnu kontrolu koja podupire povjerljivost, cjelovitost i dostupnost, s operativnom sposobnošću u sigurnosti odnosa s dobavljačima i sigurnosnim domenama kroz upravljanje, ekosustav i zaštitu. Vodič povezuje 5.23 s 5.19 odnosima s dobavljačima, 5.14 prijenosom informacija, 5.9 popisom imovine, 8.11 i 8.12 maskiranjem podataka i sprječavanjem curenja podataka, 8.20 sigurnošću mreže i 8.25 sigurnim životnim ciklusom razvoja softvera.

Ključno opažanje iz Zenith Controls glasi:

“Pružatelji usluga u oblaku (CSP-ovi) djeluju kao kritični dobavljači, pa se primjenjuju sve kontrole koje se odnose na odabir dobavljača, ugovaranje i upravljanje rizicima prema 5.19. Međutim, 5.23 ide dalje jer obrađuje rizike specifične za oblak, kao što su višekorisničko okruženje, transparentnost lokacije podataka i modeli dijeljene odgovornosti.”

Ta rečenica obuhvaća promjenu u upravljanju. Pružatelj usluga u oblaku nije samo još jedan dobavljač. Često je to mjesto na kojem se nalazi regulirana obrada.

Skrivene zamke rezidentnosti: sigurnosne kopije, dnevnički zapisi, podrška i podizvršitelji obrade

Većina neuspjeha u pogledu rezidentnosti podataka ne počinje s produkcijskom bazom podataka. Počinje s pomoćnim sustavima koji nikada nisu bili pravilno uključeni u pregled tokova podataka.

Sigurnosne kopije klasičan su primjer. SaaS platforma može raditi u Frankfurtu ili Dublinu, dok se automatizirane sigurnosne kopije repliciraju drugdje radi otpornosti ili troškovnih razloga. Ako sigurnosna kopija sadržava osobne podatke, evidencije klijenata, dnevničke zapise autentikacije ili reguliranu povijest transakcija, regija sigurnosne kopije je bitna. Prema NIS2 Article 21, upravljanje sigurnosnim kopijama i oporavak od katastrofe dio su sigurnosne polazne osnove. Prema DORA, neprekidnost kritičnih ili važnih funkcija i testirane izlazne strategije zahtijevaju poznavanje lokacija oporavka i ovisnosti oporavka.

Dnevnički zapisi još su jedna slaba točka. Sigurnosni timovi centraliziraju telemetriju u SIEM, observabilnost i usluge podatkovnog jezera. Ti dnevnički zapisi mogu uključivati IP adrese, korisničke identifikatore, administratorske radnje, metapodatke plaćanja, neuspjele pokušaje autentifikacije, identifikatore korisničkih računa ili podatke tragova podrške. Ako se dnevnički zapisi premjeste u globalnu uslugu praćenja, organizacija je možda nesvjesno stvorila prekogranični prijenos.

Clarysecova Politika zapisivanja događaja i praćenja-sme Politika zapisivanja događaja i praćenja - SME izravno adresira dokaze dobavljača:

“Ugovori moraju zahtijevati od pružatelja da zadrže dnevničke zapise najmanje 12 mjeseci i osiguraju pristup na zahtjev”

Ovaj citat dolazi iz odjeljka “Zahtjevi upravljanja”, točka politike 5.5.1.3. Za upravljanje rezidentnošću podataka isti pregled ugovora mora potvrditi gdje se ti dnevnički zapisi zadržavaju, tko im može pristupiti i jesu li dokazi iz dnevničkih zapisa dostupni tijekom istrage incidenta ili upita regulatornog tijela.

Pristup podrške suptilniji je. Pružatelj može hostirati podatke u EU, dok inženjeri podrške izvan EU mogu pristupati korisničkim okruženjima, snimkama baza podataka, dijagnostičkim paketima ili privicima prijava. Je li to prihvatljivo ovisi o uključenim podacima, mehanizmu prijenosa, ulozi, ugovornim zaštitnim mjerama, kontrolama pristupa i zapisivanju događaja. Arhitektura može biti regionalna, dok je model ljudskog pristupa globalan.

Podizvršitelji obrade stvaraju završnu slijepu točku. Vaš izravni dobavljač može se oslanjati na infrastrukturu u oblaku, mreže za isporuku sadržaja, upravljane baze podataka, platforme za evidentiranje zahtjeva, analitičke usluge, offshore timove podrške ili sigurnosne dobavljače. DORA Article 29 zahtijeva procjenu rizika podugovaranja, pružatelja iz trećih zemalja, ograničenja oporavka podataka, usklađenosti zaštite podataka i složenih lanaca podugovaranja. NIS2 Article 21 zahtijeva od subjekata da razmotre prakse kibernetičke sigurnosti izravnih dobavljača i pružatelja usluga. GDPR zahtijeva od izvršitelja obrade da upravljaju podizvršiteljima obrade na način koji čuva sposobnost voditelja obrade da ostane usklađen.

Clarysecova Politika sigurnosti trećih strana i dobavljača-sme Politika sigurnosti trećih strana i dobavljača - SME to čini praktičnim:

“Kada su dobavljači obvezni pohranjivati podatke izvan lokacije, društvo mora pribaviti potvrdu u pogledu zaštite podataka, fizičke sigurnosti i geografske lokacije pohrane (npr. hosting isključivo u EU kada to zahtijeva GDPR).”

Ovo je iz odjeljka “Zahtjevi implementacije politike”, točka politike 6.2.4. Ista politika također zahtijeva:

“Ograničenja daljnjeg podugovaranja bez odobrenja”

Ovaj citat dolazi iz odjeljka “Zahtjevi upravljanja”, točka politike 5.3.5. Zajedno, ove točke pretvaraju rezidentnost u radni tok upravljanja dobavljačima, a ne u preferenciju nabave.

Pretvorite politiku u provedivo upravljanje regijama oblaka

Upravljanje regijama oblaka mora biti provedivo, podložno pregledu i provjerljivo u reviziji.

Za MSP-ove, Politika korištenja usluga u oblaku-sme Politika korištenja usluga u oblaku - SME postavlja polaznu osnovu:

“Prakse rezidentnosti podataka i privatnosti usklađene su s primjenjivim pravnim zahtjevima (npr. GDPR)”

Ovo je iz odjeljka “Zahtjevi upravljanja”, točka politike 5.2.3. Ista politika zahtijeva da zapisi upravljanja oblakom uključuju:

“Zemlju ili regiju u kojoj se podaci pohranjuju”

Ovaj citat dolazi iz odjeljka “Zahtjevi upravljanja”, točka politike 5.3.4.

Za veće organizacije, Politika korištenja usluga u oblaku Politika korištenja usluga u oblaku izričitija je u pogledu ugovorne provedbe:

“Zahtjevi rezidentnosti podataka moraju se ugovorno provesti (npr. pohrana isključivo u EU za podatke regulirane prema GDPR).”

Ovo je iz odjeljka “Zahtjevi implementacije politike”, točka politike 6.6.2. Također navodi:

“Prekogranični prijenosi podataka moraju biti usklađeni s Poglavljem V GDPR i, gdje je primjenjivo, DORA Article 28.”

Ovo je iz odjeljka “Zahtjevi implementacije politike”, točka politike 6.6.3.

Verzija za poduzeća također usmjerava pozornost na:

“Jamstva rezidentnosti podataka i vlasništva nad podacima”

Ovaj citat dolazi iz odjeljka “Uloge i odgovornosti”, točka politike 4.5.1.2.

Politika sigurnosti trećih strana i dobavljača Politika sigurnosti trećih strana i dobavljača dodaje ugovorni sloj zahtijevajući:

“Zahtjeve postupanja s podacima, uključujući lokaciju pohrane, kontrole pristupa te odredbe o povratu ili uništenju”

Ovaj citat dolazi iz odjeljka “Zahtjevi upravljanja”, točka politike 5.3.2.

Na kraju, Politika pravne i regulatorne usklađenosti Politika pravne i regulatorne usklađenosti identificira promjene koje moraju pokrenuti pregled usklađenosti, uključujući:

“Promjene mehanizama prijenosa podataka, podizvršitelja obrade ili prekograničnih tokova podataka”

Ovo je iz odjeljka “Zahtjevi upravljanja”, točka politike 5.3.1.1.

Ti dokumenti ne smiju funkcionirati kao zasebne datoteke. U zrelom ISMS-u postaju jedan operativni model: popis oblaka, registar tokova podataka, registar dobavljača, matrica ugovora, procjena rizika, pregled prijenosa, odobravanje promjena i paket revizijskih dokaza.

Izradite registar upravljanja regijama oblaka

Praktičan registar pretvara rezidentnost oblaka iz pretpostavke u dokaz. Počnite s jednom kritičnom uslugom dostupnom klijentima, osobito onom koja će vjerojatno biti u opsegu NIS2, DORA dubinske analize klijenta ili provjere prema GDPR.

Sada povežite registar s implementacijom.

U Clarysecovu Zenith Blueprint: Revizorov plan u 30 koraka Zenith Blueprint, faza Kontrole u praksi, korak 23, usmjerena je na organizacijske kontrole 5.19 do 5.37, uključujući ugovore s dobavljačima i upravljanje uslugama u oblaku. Blueprint upozorava da ugovori s dobavljačima moraju obuhvatiti više od generičke povjerljivosti:

“U mnogim industrijama ugovori s dobavljačima također definiraju vlasništvo nad podacima i jurisdikciju. Gdje se podaci obrađuju? Tko zadržava kontrolu? Postoje li ograničenja prijenosa? Postoje li kontrole specifične za oblak (kao što su segmentacija podataka, vlasništvo nad ključevima ili geografska ograničenja)? Ti elementi nisu samo pravni; oni su operativna sigurnosna pitanja, osobito u reguliranim sektorima.”

Ista faza i korak obrađuju upravljanje promjenama dobavljača:

“Većina odnosa s dobavljačima počinje dobrim namjerama. Temeljit pregled, jasna očekivanja, potpisani ugovori (vidi 5.20), možda čak i sigurnosni kontrolni popis. Ali što se događa godinu dana kasnije, kada dobavljač predloži premještanje vaših podataka u novu regiju oblaka?”

To je Marijin problem utorkom ujutro. Registar daje CISO-u način da odgovori prije odobravanja premještanja.

Zenith Blueprint također pojašnjava značenje upravljanja za kontrolu oblaka 5.23:

“Pogrešno konfiguriran spremnik za pohranu, javno izložena nadzorna ploča ili prekomjerna ovlaštenja u cloud IAM postavci nisu kvarovi oblaka. To su neuspjesi upravljanja.”

U fazi Kontrole u praksi, korak 22, Blueprint obrađuje prijenos informacija i navodi:

“Ako se osobni podaci prenose preko granica, metoda mora biti usklađena s obvezama privatnosti i pravnim obvezama, a ne samo s internim preferencijama.”

Ta je rečenica važna za timove za oblak. Šifriranje, sigurna aplikacijska programska sučelja i privatna povezivost nužni su, ali ne zamjenjuju pravno i regulatorno upravljanje prijenosima.

Provedite prvu 90-minutnu radionicu o dokazima

Nemojte početi mapiranjem cijele organizacije. Počnite s jednom kritičnom uslugom i provedite fokusiranu radionicu s inženjeringom oblaka, nabavom, pravnim poslovima, privatnošću, otpornošću i sigurnosnim operacijama.

Prvo, navedite svaku komponentu oblaka ili dobavljača koja pohranjuje, obrađuje, prenosi, sigurnosno kopira, prati ili podržava uslugu. Uključite manje sustave kao što su praćenje raspoloživosti, privici prijava, praćenje pogrešaka, alati za dijeljenje zaslona podrške i dijagnostički izvozi.

Drugo, označite svaku kategoriju podataka. Ako tim kaže “samo metapodaci”, osporite pretpostavku. Metapodaci i dalje mogu biti osobni podaci ili povjerljivi podaci klijenata.

Treće, provjerite regiju na temelju dokaza. Koristite konfiguraciju konzole oblaka, politike sigurnosnog kopiranja, postavke SIEM zakupca, DPA priloge, popise podizvršitelja obrade, ugovorne uvjete, dokumentaciju pristupa podrške i CSP revizijska izvješća. Ne oslanjajte se samo na prodajna uvjeravanja.

Četvrto, evidentirajte praznine u registar rizika ISMS-a. Primjeri uključuju “regija replikacije sigurnosnih kopija nije ugovorno ograničena”, “pristup podrške iz treće zemlje nema dokumentirani radni tok odobravanja”, “SIEM dnevnički zapisi zadržavaju se globalno”, “popis podizvršitelja obrade ne navodi regiju hostinga” ili “DORA registar ne razlikuje ovisnost kritične ili važne funkcije”.

Peto, odlučite o obradi rizika. Obrada može uključivati izmjenu ugovora, zaključavanje regije, obavijest klijentu, šifriranje s ključevima kojima upravlja korisnik, tokenizaciju, minimizaciju dnevničkih zapisa, odobrenje novog dobavljača, ažuriranje izlazne strategije ili prihvaćanje preostalog rizika od strane vlasnika rizika.

Šesto, sačuvajte dokaze. Revizori neće pitati samo što ste odlučili. Pitat će kako znate da je to implementirano.

Mapirajte jedan skup dokaza na ISO, GDPR, NIS2, DORA i NIST CSF 2.0

Snažan program upravljanja regijama oblaka izbjegava dvostruki rad na usklađenosti. Isti dokazi mogu poduprijeti više obveza ako su pravilno strukturirani.

NIST CSF 2.0 koristan je kao integracijski sloj. Njegova funkcija GOVERN usklađena je s pravnim, regulatornim, ugovornim i privatnosnim obvezama, apetitom za rizik, odgovornošću, politikama i nadzorom. Njegova kategorija GV.SC za opskrbni lanac dobro se mapira na DORA očekivanja za IKT treće strane, NIS2 zahtjeve opskrbnog lanca i ISO kontrole dobavljača.

COBIT 2019 i ISACA revizijska perspektiva često testiraju iste činjenice kroz ciljeve upravljanja: vlasništvo, prava odlučivanja, optimizaciju rizika, učinkovitost dobavljača, ostvarenje koristi i osiguranje. Revizor u COBIT stilu možda neće početi pitanjem “koja je regija oblaka konfigurirana?” Može početi pitanjem “tko ima ovlast odobriti promjenu regije, kako se rizik eskalira i kako uprava zna da dobavljači oblaka ostaju unutar tolerancije?”

Zato Clarysecov model obuhvaća vlasnike, točke odobravanja, ugovorne dokaze i izvješćivanje upravi, a ne samo tehničke postavke.

Pripremite se za pitanja revizora

Upravljanje regijama oblaka savršen je primjer kako različiti revizori promatraju istu kontrolu iz različitih kutova.

Revizor ISO/IEC 27001:2022 počet će s opsegom, zahtjevima zainteresiranih strana, procjenom rizika i Izjavom o primjenjivosti. Pitat će jesu li pravni, regulatorni i ugovorni zahtjevi identificirani, jesu li kontrole oblaka i dobavljača uključene, jesu li rizici procijenjeni, jesu li kontrole implementirane i jesu li dokazi zadržani. Može uzorkovati jednu uslugu u oblaku i zatražiti pregled uvođenja, ugovorne odredbe, konfiguraciju regije, pregled praćenja i odobrenje promjene.

Tijelo za zaštitu podataka ili GDPR pregledavatelj usredotočit će se na osobne podatke. Pitat će koji se osobni podaci obrađuju, gdje se pohranjuju, odakle im se pristupa, koji su izvršitelji obrade i podizvršitelji obrade uključeni, jesu li mehanizmi prijenosa dokumentirani, je li potrebna procjena učinka prijenosa i jesu li uspostavljene odgovarajuće tehničke i organizacijske mjere. Dnevnički zapisi, podaci podrške i sigurnosne kopije često dobivaju pozornost jer ih organizacije podcjenjuju.

Revizor NIS2 ili nadležno tijelo usredotočit će se na usluge u opsegu. Promatrat će odgovornost uprave prema Article 20, mjere upravljanja rizicima prema Article 21, neprekidnost, upravljanje sigurnosnim kopijama, oporavak od katastrofe, postupanje s incidentima, sigurnost opskrbnog lanca, kontrolu pristupa, upravljanje imovinom i procjenu učinkovitosti.

DORA nadzorno tijelo ili tim unutarnje revizije tražit će upravljanje IKT rizicima, nadzor upravljačkog tijela, registar informacija za IKT aranžmane s trećim stranama, mapiranje kritičnih ili važnih funkcija, rizik koncentracije, rizik podugovaranja, lokacije obrade podataka, prava na reviziju, podršku prijavljivanju incidenata, testiranje neprekidnosti i izlazne planove. DORA jasno navodi da izdvajanje usluge ne prenosi odgovornost.

Zenith Controls pomaže sigurnosnim voditeljima pripremiti se za te revizijske stilove jer unakrsno upućuje na odnose među kontrolama. Za kontrolu ISO/IEC 27002:2022 5.20, Uređivanje informacijske sigurnosti u ugovorima s dobavljačima, Zenith Controls povezuje je s 5.19 odnosima s dobavljačima, 5.14 prijenosom informacija, 5.22 praćenjem dobavljača, 5.11 povratom imovine i 5.36 usklađenošću s politikama, pravilima i standardima. Za kontrolu 5.22, Praćenje, pregled i upravljanje promjenama usluga dobavljača, povezuje kontinuirani nadzor nad dobavljačima s 5.29 sigurnošću tijekom poremećaja, 8.8 upravljanjem tehničkim ranjivostima, 5.15 kontrolom pristupa, 8.27 sigurnom arhitekturom sustava i inženjerskim načelima te 5.36 usklađenošću.

Taj pogled kroz više kontrola važan je jer promjena regije nikada nije samo promjena regije. Može promijeniti rizik dobavljača, rizik prijenosa, rizik pristupa, rizik neprekidnosti, dokaze za odgovor na incidente i ugovornu usklađenost.

Upotrijebite ovaj CISO kontrolni popis za 2026. prije odobravanja promjene u oblaku

Upotrijebite ovaj kontrolni popis prije odobravanja bilo koje nove regije oblaka, puta prekogranične obrade, lokacije sigurnosnih kopija, platforme za zapisivanje događaja, modela podrške ili promjene kritičnog IKT dobavljača.

Ako je odgovor na bilo koje pitanje “pretpostavljamo”, kontrola nije dovoljno zrela za regulirane operacije.

Plan otklanjanja nedostataka

Put otklanjanja nedostataka praktičan je kada je utemeljen u ISMS-u.

1. Potvrdite da opseg ISMS-a uključuje usluge u oblaku, kritične IKT ovisnosti i reguliranu obradu podataka.
2. Izradite registar upravljanja regijama oblaka za prioritetne usluge.
3. Mapirajte svaku uslugu na kategorije podataka, regije, lokacije sigurnosnih kopija, pristup podrške i podizvršitelje obrade.
4. Pregledajte ugovore s dobavljačima u pogledu lokacije pohrane, prijenosa, revizije, incidenata, podugovaranja, povrata i odredbi o uništenju.
5. Ažurirajte registar rizika za praznine, rizike koncentracije i nedokumentirane prijenose.
6. Uskladite DORA registar IKT trećih strana i NIS2 mapiranje ovisnosti usluga gdje je primjenjivo.
7. Provjerite tehničku provedbu, uključujući zaključavanje regija, politike sigurnosnog kopiranja, postavke zapisivanja događaja, šifriranje, kontrole pristupa i upravljanje ključevima.
8. Pripremite paket revizijskih dokaza sa snimkama zaslona, ugovorima, zapisima rizika, odobrenjima, zapisnicima pregleda i rezultatima testiranja.
9. Uspostavite okidač promjene za nove regije, podizvršitelje obrade, mehanizme prijenosa ili promjene usluga kritičnih dobavljača.
10. Izvješćujte upravu o riziku rezidentnosti oblaka, iznimkama i odlukama o preostalom riziku.

To nije teorijska usklađenost. To je razlika između okruženja u oblaku koje može izdržati revizijsku provjeru i onoga koje ovisi o usmenim uvjeravanjima.

Poslovni razlog: suverenitet, otpornost i povjerenje

Izvršni rukovoditelji ponekad promatraju upravljanje rezidentnošću podataka kao ograničenje agilnosti oblaka. U praksi zrelo upravljanje regijama poboljšava agilnost jer timovi znaju pravila prije kupnje, izgradnje ili migracije.

Produktni tim može brže pokretati usluge kada su odobrene regije jasne. Nabava može brže pregovarati kada su obvezne odredbe već definirane. Pravni poslovi mogu brže procijeniti prijenose kada su tokovi podataka dokumentirani. Sigurnosne operacije mogu brže istraživati kada su lokacije dnevničkih zapisa i prava pristupa poznati. Odbor može brže donositi odluke o riziku kada su rizik koncentracije, utjecaj na neprekidnost i prihvaćanje preostalog rizika vidljivi.

Za klijente, osobito regulirane klijente, to postaje signal povjerenja. SaaS pružatelj koji može objasniti gdje se podaci nalaze, kako se upravlja sigurnosnim kopijama, kako se kontrolira pristup podrške, kako se odobravaju podizvršitelji obrade i kako se pregledavaju promjene regija nadmašit će pružatelja koji samo kaže “koristimo vodećeg pružatelja usluga u oblaku”.

U 2026. ta je razlika važna. NIS2 je doveo upravljanje kibernetičkom sigurnošću do ključnih i važnih subjekata diljem EU. DORA je nadzor IKT trećih strana učinila formalnom disciplinom financijskog sektora. Odgovornost prema GDPR ostaje središnja. ISO/IEC 27001:2022 pruža sustav upravljanja koji sve to drži na okupu.

Sljedeći koraci s Clarysec

Ako vaša organizacija ne može odgovoriti gdje se regulirani podaci i kritična IKT obrada nalaze kroz produkciju, sigurnosne kopije, dnevničke zapise, pristup podrške i podugovaratelje, sada je vrijeme za zatvaranje praznine.

Clarysec vam može pomoći izraditi paket dokaza za upravljanje regijama oblaka koristeći:

• Zenith Blueprint: Revizorov plan u 30 koraka Zenith Blueprint za faznu ISO implementaciju i spremnost za reviziju.
• Zenith Controls: Vodič za međusobnu usklađenost Zenith Controls za mapiranje ISO/IEC 27002:2022 kontrola oblaka i dobavljača na operativne dokaze i očekivanja kroz više okvira.
• Politika korištenja usluga u oblaku Politika korištenja usluga u oblaku i Politika korištenja usluga u oblaku-sme Politika korištenja usluga u oblaku - SME za zahtjeve rezidentnosti podataka u oblaku.
• Politika sigurnosti trećih strana i dobavljača Politika sigurnosti trećih strana i dobavljača i Politika sigurnosti trećih strana i dobavljača-sme Politika sigurnosti trećih strana i dobavljača - SME za ugovore s dobavljačima, podugovaranje i potvrde o geografskoj lokaciji pohrane.
• Politika zapisivanja događaja i praćenja-sme Politika zapisivanja događaja i praćenja - SME za zadržavanje dnevničkih zapisa i dokaze pružatelja.
• Politika pravne i regulatorne usklađenosti Politika pravne i regulatorne usklađenosti za okidače pregleda usklađenosti oko mehanizama prijenosa, podizvršitelja obrade i prekograničnih tokova podataka.

Počnite s jednom kritičnom uslugom, jednim pružateljem usluga u oblaku i jednim registrom. U nekoliko radionica možete prijeći s pretpostavki na dokaze i s fragmentirane usklađenosti na upravljanu otpornost oblaka.

Preuzmite Clarysec toolkit, zatražite demo ili rezervirajte procjenu upravljanja regijama oblaka kako biste svoje obveze rezidentnosti oblaka pretvorili u dokaz spreman za reviziju.