Řízení cloudových regionů pro GDPR, NIS2 a DORA

V úterý ráno v 08:17 obdrží Maria, CISO rychle rostoucí evropské fintech společnosti, zprávu, které se dříve či později obává každý regulovaný zákazník cloudových služeb.

Tým nákupu přeposílá krátké oznámení dodavatele:

“Náš poskytovatel cloudové analytiky přesouvá zákaznickou telemetrii z EU do nového regionu z výkonnostních důvodů. Tvrdí, že to nemá žádný bezpečnostní dopad. Můžeme to schválit?”

Než Maria stihne odpovědět, přichází druhé oznámení od primárního poskytovatele cloudových služeb. S účinností za 90 dní bude poskytovatel „optimalizovat svůj globální model podpory“ tím, že bude směrovat tikety podpory úrovně Tier 2 přes nového dílčího zpracovatele. Rychlý přezkum ukazuje, že dílčí zpracovatel má sídlo v zemi bez rozhodnutí o odpovídající ochraně podle GDPR.

V 09:00 už jsou ve vlákně právní oddělení, tým ochrany osobních údajů, tým odolnosti, nákup, cloudoví inženýři a tým regulatorního souladu ve finanční oblasti. DPO se ptá, zda je potřeba Transfer Impact Assessment. Manažer odolnosti se ptá, zda nový region ovlivní plán obnovy kritické služby. Vedoucí finančního souladu se ptá, zda je poskytovatel uveden v registru třetích stran v oblasti ICT podle DORA. Cloudový tým kontroluje produkční datovou rovinu a zjišťuje, že problém je širší než analytika. Do rozsahu mohou spadat zálohy, provozní logy, tikety podpory, exporty z data lake, nouzový přístup „break-glass“ i přístup subdodavatelů.

Toto je skutečný problém řízení cloudu v roce 2026.

Většina organizací má cloudovou politiku. Mnohé mají registr dodavatelů. Některé mají posouzení přenosů podle GDPR. Méně organizací však dokáže s důkazy odpovědět na náročnější auditní otázku:

Kde přesně se nacházejí regulovaná data a kritické zpracování ICT, kdo k nim může přistupovat a odkud, co se stane při přepnutí na záložní řešení a jaká smluvní opatření brání poskytovateli změnit odpověď bez schválení?

To je řízení cloudových regionů. Nejde o jednorázovou právní kontrolu. Jde o živý systém opatření napříč ISO/IEC 27001:2022, cloudovými a dodavatelskými opatřeními ISO/IEC 27002:2022, odpovědností podle GDPR, odolností služeb podle NIS2 a dohledem nad třetími stranami v oblasti ICT podle DORA.

Umístění dat je nyní provozním opatřením

Po léta se „hosting pouze v EU“ vnímal jako ustanovení ve smlouvě o zpracování osobních údajů. To již nestačí. Moderní program umístění cloudových dat a řízení regionů musí pokrývat alespoň šest provozních vrstev:

1. Primární produkční regiony pro ukládání a výpočetní kapacity.
2. Regiony pro zálohy, archivy a obnovu po havárii.
3. Umístění dat pro protokolování, monitorování, SIEM a observabilitu.
4. Přístup podpory, včetně vzdálené správy a nouzového přístupu „break-glass“.
5. Dílčí zpracovatelé a subdodavatelé, včetně řízených služeb a komponent z tržišť.
6. Cesty přenosu dat mezi prostředími, rozhraními API, analytickými platformami a nástroji zákaznické podpory.

GDPR z toho činí nevyhnutelný požadavek, protože osobní údaje mohou zahrnovat online identifikátory, IP adresy, identifikátory zákaznických účtů, uživatelské záznamy, identifikátory zařízení, provozní metadata a záznamy podpory. Také zpracování je definováno široce a zahrnuje ukládání, přístup, použití, zpřístupnění, výmaz i zničení. „Posíláme pouze logy“ není bezpečná výjimka, pokud tyto logy obsahují identifikátory.

GDPR Article 5 zahrnuje také zásadu odpovědnosti. Správci musí nejen dodržovat zásady zákonnosti, korektnosti, transparentnosti, účelového omezení, minimalizace údajů, omezení uložení, integrity a důvěrnosti. Musí být také schopni doložit soulad. Řízení cloudových regionů je jedním ze způsobů, jak se toto doložení stává v praxi proveditelným.

NIS2 rozšiřuje problém z oblasti ochrany osobních údajů do oblasti odolnosti. Podle Article 21 musí základní a důležité subjekty zavést vhodná technická, provozní a organizační opatření k řízení rizik pro sítě a informační systémy používané pro provoz nebo poskytování služeb. Uvedená opatření zahrnují zabezpečení dodavatelského řetězce, kontinuitu činností, správu záloh, obnovu po havárii, krizové řízení, řízení přístupu, správu aktiv, šifrování a posuzování účinnosti. Pokud rozhodnutí o cloudovém regionu ovlivňuje dostupnost nebo obnovu služby v rozsahu, nejde pouze o otázku ochrany údajů. Jde o otázku odolnosti.

U finančních subjektů DORA zvyšuje laťku ještě výše. DORA se použije od 17. ledna 2025 a stanovuje požadavky na řízení rizik v oblasti ICT, hlášení incidentů, testování digitální provozní odolnosti, řízení rizik třetích stran v oblasti ICT a smluvní ujednání. Article 28 vyžaduje, aby finanční subjekty řídily rizika třetích stran v oblasti ICT jako nedílnou součást rámce řízení rizik v oblasti ICT, vedly registry smluvních ujednání, posuzovaly riziko koncentrace a plánovaly ukončení pro kritické nebo důležité funkce. Article 30 očekává smluvní jasnost ohledně míst poskytování služby a zpracování dat, práv na audit a přístup, podpory při incidentech, subdodávek, obnovy, vrácení a přechodu při ukončení.

DORA působí jako sektorově specifický režim pro finanční subjekty, zatímco NIS2 zůstává relevantní v širším dodavatelském řetězci, zejména pro poskytovatele cloud computingu, poskytovatele datových center a poskytovatele řízených služeb (MSP). Jeden neprověřený dílčí zpracovatel proto může vyvolat dominový efekt napříč finanční odolností, zabezpečením dodavatelského řetězce a povinnostmi v oblasti ochrany osobních údajů.

Jednoduše řečeno, pokud regulovaná organizace nedokáže řídit, kde probíhá její cloudové zpracování, nemůže důvěryhodně řídit rizika třetích stran v oblasti ICT.

Použijte ISO 27001 jako kotvu systému řízení

ISO/IEC 27001:2022 poskytuje strukturu pro přeměnu nejasností ohledně umístění dat na řízený systém řízení.

Články 4.1 až 4.4 vyžadují, aby organizace definovala ISMS v kontextu, včetně interních a externích záležitostí, požadavků zainteresovaných stran, právních, regulačních a smluvních povinností, rozhraní a závislostí na jiných organizacích. Pro řízení cloudových regionů má rozsah ISMS výslovně zahrnovat cloudové služby, outsourcované zpracování ICT, závislosti kritických služeb a regulované datové toky.

Články 5.1 až 5.3 činí vedení odpovědným. Vrcholové vedení musí sladit politiku bezpečnosti informací a cíle se strategickým směřováním, zajistit zdroje, přiřadit odpovědnosti a zajistit vykazování výkonnosti ISMS. Zde se umístění dat v cloudu stává tématem pro vedení a řídicí orgány, zejména u subjektů NIS2, kde řídicí orgány musí schvalovat opatření k řízení kybernetických bezpečnostních rizik a dohlížet na ně, a u finančních subjektů DORA, kde je řídicí orgán odpovědný za řízení rizik ICT.

Články 6.1.1 až 6.1.3 poskytují rizikový mechanismus. Organizace potřebuje opakovatelný proces posuzování rizik, vlastníky rizik, kritéria dopadu a pravděpodobnosti, možnosti ošetření, vybraná opatření, Prohlášení o použitelnosti a přijetí zbytkového rizika. Změna cloudového regionu nemá být schválena neformálním e-mailem. Má vyvolat posouzení rizik nebo přezkum změny, pokud ovlivňuje regulovaná data, kritické funkce, dodavatele nebo předpoklady kontinuity.

Článek 8.1 převádí plánování do provozního řízení. Procesy musí být zavedeny, řízeny, dokumentovány, měněny řízeným způsobem a rozšířeny na externě poskytované produkty a služby relevantní pro ISMS. Články 8.2 a 8.3 vyžadují opětovné posouzení a ošetření v plánovaných intervalech nebo při významných změnách. Migrace cloudového regionu, replikace záloh, nová platforma pro protokolování nebo změna dílčího zpracovatele podpory jsou všechno kandidáti na opětovné posouzení.

Soubor opatření ISO/IEC 27002:2022 následně poskytuje praktickou rodinu opatření. Nejrelevantnější opatření zahrnují:

• 5.9 evidence informací a dalších souvisejících aktiv.
• 5.14 přenos informací.
• 5.15 řízení přístupu.
• 5.19 bezpečnost informací ve vztazích s dodavateli.
• 5.20 řešení bezpečnosti informací ve smlouvách s dodavateli.
• 5.22 monitorování, přezkum a řízení změn služeb dodavatelů.
• 5.23 bezpečnost informací při používání cloudových služeb.
• 5.29 bezpečnost informací během narušení.
• 5.30 připravenost ICT pro kontinuitu činností.
• 5.31 právní, zákonné, regulační a smluvní požadavky.
• 5.34 ochrana soukromí a ochrana osobně identifikovatelných údajů (PII).
• 5.36 soulad s politikami, pravidly a normami pro bezpečnost informací.
• 8.11 maskování dat.
• 8.12 prevence úniku dat.
• 8.13 zálohování informací.
• 8.15 protokolování.
• 8.16 monitorovací činnosti.
• 8.20 zabezpečení sítí.
• 8.24 používání kryptografie.
• 8.25 životní cyklus bezpečného vývoje.
• 8.27 principy bezpečné systémové architektury a inženýrství.
• 8.32 řízení změn.

Clarysec Zenith Controls: The Cross-Compliance Guide Zenith Controls považuje opatření ISO/IEC 27002:2022 5.23, bezpečnost informací při používání cloudových služeb, za preventivní opatření podporující důvěrnost, integritu a dostupnost, s provozní schopností v oblasti bezpečnosti dodavatelských vztahů a v bezpečnostních doménách správy, ekosystému a ochrany. Průvodce propojuje 5.23 s 5.19 vztahy s dodavateli, 5.14 přenos informací, 5.9 evidence aktiv, 8.11 a 8.12 maskování dat a prevence úniku dat, 8.20 zabezpečení sítí a 8.25 životní cyklus bezpečného vývoje.

Klíčové pozorování ze Zenith Controls zní:

“Poskytovatelé cloudových služeb (CSP) fungují jako kritičtí dodavatelé, a proto se na ně vztahují všechna opatření týkající se výběru dodavatelů, uzavírání smluv a řízení rizik podle 5.19. Opatření 5.23 však jde dále, protože řeší specifická cloudová rizika, jako je multi-tenancy, transparentnost umístění dat a modely sdílené odpovědnosti.”

Tato věta vystihuje posun v řízení. Poskytovatel cloudu není jen další dodavatel. Často je místem, kde regulované zpracování skutečně probíhá.

Skryté pasti umístění dat: zálohy, logy, podpora a dílčí zpracovatelé

Většina selhání v oblasti umístění dat nezačíná u produkční databáze. Začíná u podpůrných systémů, které nikdy nebyly řádně zahrnuty do přezkumu datových toků.

Klasickým příkladem jsou zálohy. Platforma SaaS může běžet ve Frankfurtu nebo Dublinu, zatímco automatické zálohy se z důvodů odolnosti nebo nákladů replikují jinam. Pokud záloha obsahuje osobní údaje, zákaznické záznamy, autentizační logy nebo regulovanou historii transakcí, region zálohy je podstatný. Podle NIS2 Article 21 jsou správa záloh a obnova po havárii součástí základního souboru bezpečnostních opatření. Podle DORA vyžaduje kontinuita kritických nebo důležitých funkcí a otestované strategie ukončení znalost míst obnovy a závislostí obnovy.

Dalším slabým místem jsou logy. Bezpečnostní týmy centralizují telemetrii do SIEM, observability a služeb data lake. Tyto logy mohou obsahovat IP adresy, identifikátory uživatelů, administrátorské akce, platební metadata, neúspěšné pokusy o autentizaci, identifikátory zákaznických účtů nebo trasovací data podpory. Pokud se logy přesunou do globální monitorovací služby, organizace mohla nevědomky vytvořit přeshraniční přenos.

Clarysec Logging and Monitoring Policy-sme Politika protokolování a monitorování – SME přímo řeší důkazy od dodavatelů:

“Smlouvy musí vyžadovat, aby poskytovatelé uchovávali logy po dobu alespoň 12 měsíců a na vyžádání k nim poskytli přístup.”

Tato citace pochází ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.5.1.3. Pro řízení umístění dat má stejný smluvní přezkum potvrdit, kde jsou tyto logy uchovávány, kdo k nim může přistupovat a zda jsou důkazy z logů dostupné během vyšetřování incidentu nebo regulačního šetření.

Přístup podpory je méně zjevný. Poskytovatel může hostovat data v EU, zatímco inženýři podpory mimo EU mohou přistupovat k zákaznickým prostředím, snapshotům databází, diagnostickým balíčkům nebo přílohám tiketů. Zda je to přijatelné, závisí na dotčených datech, mechanismu přenosu, roli, smluvních ochranných opatřeních, řízení přístupu a protokolování. Architektura může být regionální, zatímco model lidského přístupu je globální.

Dílčí zpracovatelé vytvářejí poslední slepé místo. Váš přímý dodavatel se může opírat o cloudovou infrastrukturu, sítě pro doručování obsahu, spravované databáze, ticketovací systémy, analytické služby, offshore týmy podpory nebo bezpečnostní dodavatele. DORA Article 29 vyžaduje posouzení rizik subdodávek, poskytovatelů ze třetích zemí, omezení obnovy dat, souladu s ochranou údajů a složitých subdodavatelských řetězců. NIS2 Article 21 vyžaduje, aby subjekty zohlednily postupy kybernetické bezpečnosti přímých dodavatelů a poskytovatelů služeb. GDPR vyžaduje, aby zpracovatelé řídili dílčí zpracovatele způsobem, který zachovává schopnost správce plnit povinnosti.

Clarysec Third-Party and Supplier Security Policy-sme Bezpečnostní politika dodavatelů a třetích stran – SME to převádí do praxe:

“Pokud jsou dodavatelé povinni ukládat data mimo pracoviště, musí společnost získat ujištění týkající se ochrany údajů, fyzické bezpečnosti a geografického umístění úložiště (např. hosting pouze v EU, pokud to vyžaduje GDPR).”

Tato citace pochází ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.2.4. Stejná politika také vyžaduje:

“Omezení dalšího subdodavatelského zajištění bez schválení.”

Tato citace pochází ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.3.5. Společně tato ustanovení převádějí umístění dat do pracovního postupu řízení dodavatelů, nikoli do nákupní preference.

Přeměňte politiku na vymahatelné řízení cloudových regionů

Řízení cloudových regionů musí být vymahatelné, přezkoumatelné a auditovatelné.

Pro SME stanovuje Cloud Usage Policy-sme Politika používání cloudových služeb – SME výchozí požadavek:

“Umístění dat a postupy ochrany soukromí jsou v souladu s příslušnými právními požadavky (např. GDPR).”

Toto pochází ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.2.3. Stejná politika vyžaduje, aby záznamy správy cloudu obsahovaly:

“Zemi nebo region, kde jsou data uložena.”

Tato citace pochází ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.3.4.

Pro větší organizace je Cloud Usage Policy Politika používání cloudových služeb explicitnější ohledně smluvního prosazení:

“Požadavky na umístění dat musí být prosazeny smluvně (např. ukládání pouze v EU pro data regulovaná GDPR).”

Toto pochází ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.6.2. Dále uvádí:

“Přeshraniční přenosy dat musí být v souladu s GDPR Chapter V a případně s DORA Article 28.”

Toto pochází ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.6.3.

Podniková verze také klade důraz na:

“Záruky umístění dat a vlastnictví dat.”

Tato citace pochází ze sekce „Role a odpovědnosti“, ustanovení politiky 4.5.1.2.

Third party and supplier security policy Bezpečnostní politika dodavatelů a třetích stran doplňuje smluvní vrstvu požadavkem na:

“Požadavky na nakládání s daty, včetně umístění úložiště, řízení přístupu a ustanovení o vrácení nebo zničení.”

Tato citace pochází ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.3.2.

Nakonec Legal and Regulatory Compliance Policy Politika právního a regulačního souladu identifikuje změny, které mají vyvolat přezkum souladu, včetně:

“Změny mechanismů přenosu dat, dílčích zpracovatelů nebo přeshraničních toků dat.”

Toto pochází ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.3.1.1.

Tyto dokumenty nemají fungovat jako samostatné soubory. Ve vyspělém ISMS se z nich stává jeden provozní model: evidence cloudových služeb, registr datových toků, registr dodavatelů, smluvní matice, posouzení rizik, přezkum přenosů, schvalování změn a balíček auditních důkazů.

Vytvořte registr řízení cloudových regionů

Praktický registr mění umístění dat v cloudu z předpokladu na důkaz. Začněte jednou kritickou službou určenou zákazníkům, zejména takovou, která pravděpodobně spadá do rozsahu NIS2, náležité péče zákazníků podle DORA nebo prověrky podle GDPR.

Nyní registr propojte s implementací.

V Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint se fáze Controls in Action, krok 23, zaměřuje na organizační opatření 5.19 až 5.37, včetně smluv s dodavateli a správy cloudových služeb. Blueprint upozorňuje, že smlouvy s dodavateli musí pokrývat více než obecnou důvěrnost:

“V mnoha odvětvích smlouvy s dodavateli definují také vlastnictví dat a jurisdikci. Kde jsou data zpracovávána? Kdo si ponechává kontrolu? Existují omezení přenosu? Existují cloudově specifická opatření (například segmentace dat, vlastnictví klíčů nebo geografická omezení)? Tyto prvky nejsou pouze právní. Jsou to provozní otázky bezpečnosti, zejména v regulovaných sektorech.”

Stejná fáze a krok řeší řízení změn dodavatelů:

“Většina dodavatelských vztahů začíná s dobrými úmysly. Důkladný přezkum, jasná očekávání, podepsané smlouvy (viz 5.20), možná i bezpečnostní kontrolní seznam. Co se ale stane o rok později, když dodavatel navrhne přesun vašich dat do nového cloudového regionu?”

To je Mariin úterní ranní problém. Registr dává CISO způsob, jak odpovědět před schválením přesunu.

Zenith Blueprint také objasňuje význam správy u cloudového opatření 5.23:

“Chybně nakonfigurované cloudové úložiště, veřejně exponovaný řídicí panel nebo nadměrná oprávnění v cloudovém nastavení IAM nejsou selhání cloudu. Jsou to selhání správy.”

Ve fázi Controls in Action, krok 22, se Blueprint věnuje přenosu informací a uvádí:

“Pokud jsou osobní údaje přenášeny přes hranice, metoda musí být v souladu s povinnostmi v oblasti ochrany soukromí a právními povinnostmi, nikoli pouze s interními preferencemi.”

Tento řádek je pro cloudové týmy důležitý. Šifrování, zabezpečená rozhraní API a privátní konektivita jsou nezbytné, ale nenahrazují právní a regulační řízení přenosů.

Uspořádejte první 90minutový workshop k důkazům

Nezačínejte mapováním celého podniku. Začněte jednou kritickou službou a uspořádejte cílený workshop s cloudovými inženýry, nákupem, právním oddělením, týmem ochrany osobních údajů, týmem odolnosti a bezpečnostním provozem.

Nejprve uveďte každou cloudovou nebo dodavatelskou komponentu, která službu ukládá, zpracovává, přenáší, zálohuje, monitoruje nebo podporuje. Zahrňte i menší systémy, jako je monitorování dostupnosti, přílohy tiketů, sledování chyb, nástroje pro sdílení obrazovky podpory a diagnostické exporty.

Zadruhé označte každou kategorii dat. Pokud tým řekne „pouze metadata“, zpochybněte tento předpoklad. Metadata mohou stále být osobními údaji nebo důvěrnými zákaznickými daty.

Zatřetí ověřte region na základě důkazů. Použijte konfiguraci cloudové konzole, politiky zálohování, nastavení tenancy SIEM, přílohy DPA, seznamy dílčích zpracovatelů, smluvní podmínky, dokumentaci přístupu podpory a auditní reporty CSP. Nespoléhejte pouze na obchodní ujištění.

Začtvrté zaznamenejte mezery do registru rizik ISMS. Příklady zahrnují „region replikace záloh není smluvně omezen“, „přístup podpory ze třetí země nemá dokumentovaný schvalovací pracovní postup“, „logy SIEM jsou uchovávány globálně“, „seznam dílčích zpracovatelů neuvádí hostingový region“ nebo „registr DORA nerozlišuje závislost kritické nebo důležité funkce“.

Zapáté rozhodněte o ošetření. Ošetření mohou zahrnovat dodatek ke smlouvě, uzamčení regionu, oznámení zákazníkovi, šifrování s klíči spravovanými zákazníkem, tokenizaci, minimalizaci logů, schválení nového dodavatele, aktualizaci strategie ukončení nebo přijetí zbytkového rizika vlastníkem rizika.

Zašesté uchovejte důkazy. Auditoři se nebudou ptát pouze na to, co jste rozhodli. Budou se ptát, jak víte, že to bylo implementováno.

Namapujte jednu sadu důkazů na ISO, GDPR, NIS2, DORA a NIST CSF 2.0

Silný program řízení cloudových regionů se vyhýbá duplicitní práci na souladu. Stejné důkazy mohou podporovat více povinností, pokud jsou správně strukturovány.

NIST CSF 2.0 je užitečný jako integrační vrstva. Jeho funkce GOVERN je v souladu s právními, regulačními, smluvními povinnostmi a povinnostmi v oblasti ochrany soukromí, ochotou podstupovat riziko, odpovědností, politikami a dohledem. Kategorie dodavatelského řetězce GV.SC se dobře mapuje na očekávání DORA pro třetí strany v oblasti ICT, požadavky NIS2 na dodavatelský řetězec a dodavatelská opatření ISO.

COBIT 2019 a auditní pohled ISACA často testují stejné skutečnosti prostřednictvím cílů správy: vlastnictví, rozhodovací pravomoci, optimalizace rizik, výkonnost dodavatelů, realizace přínosů a ujištění. Přezkoumávající osoba ve stylu COBIT nemusí začít otázkou „který cloudový region je nakonfigurován?“ Může začít otázkou „kdo má pravomoc schválit změnu regionu, jak se eskaluje riziko a jak vedení ví, že cloudoví dodavatelé zůstávají v toleranci?"

Proto model Clarysec zachycuje vlastníky, schvalovací body, smluvní důkazy a reportování vedení, nikoli pouze technická nastavení.

Připravte se na otázky auditora

Řízení cloudových regionů je dokonalým příkladem toho, jak různí auditoři nahlížejí na stejné opatření z různých úhlů.

Auditor ISO/IEC 27001:2022 začne rozsahem, požadavky zainteresovaných stran, posouzením rizik a Prohlášením o použitelnosti. Bude se ptát, zda jsou identifikovány právní, regulační a smluvní požadavky, zda jsou zahrnuta cloudová a dodavatelská opatření, zda byla posouzena rizika, zda jsou opatření implementována a zda jsou uchovávány důkazy. Může vybrat vzorek jedné cloudové služby a požádat o přezkum onboardingu, smluvní ustanovení, konfiguraci regionu, přezkum monitorování a schválení změny.

Dozorový úřad pro ochranu osobních údajů nebo přezkoumávající osoba podle GDPR se zaměří na osobní údaje. Bude se ptát, jaké osobní údaje jsou zpracovávány, kde jsou ukládány, odkud je k nim přistupováno, kteří zpracovatelé a dílčí zpracovatelé jsou zapojeni, zda jsou dokumentovány mechanismy přenosu, zda je potřeba Transfer Impact Assessment a zda jsou zavedena vhodná technická a organizační opatření. Logům, datům podpory a zálohám se často věnuje pozornost, protože je organizace podceňují.

Auditor NIS2 nebo příslušný orgán se zaměří na služby v rozsahu. Bude zkoumat odpovědnost vedení podle Article 20, opatření řízení rizik podle Article 21, kontinuitu, správu záloh, obnovu po havárii, zvládání incidentů, zabezpečení dodavatelského řetězce, řízení přístupu, správu aktiv a posouzení účinnosti.

Orgán dohledu podle DORA nebo tým interního auditu bude hledat řízení rizik ICT, dohled řídicího orgánu, informační registr smluvních ujednání s třetími stranami v oblasti ICT, mapování kritických nebo důležitých funkcí, riziko koncentrace, riziko subdodávek, místa zpracování dat, práva na audit, podporu hlášení incidentů, testování kontinuity a plány ukončení. DORA jasně stanoví, že outsourcing nepřenáší odpovědnost.

Zenith Controls pomáhá bezpečnostním lídrům připravit se na tyto auditní styly, protože křížově odkazuje vztahy mezi opatřeními. U opatření ISO/IEC 27002:2022 5.20, řešení bezpečnosti informací ve smlouvách s dodavateli, Zenith Controls propojuje toto opatření s 5.19 vztahy s dodavateli, 5.14 přenos informací, 5.22 monitorování dodavatelů, 5.11 vrácení aktiv a 5.36 soulad s politikami, pravidly a normami. U opatření 5.22, monitorování, přezkum a řízení změn služeb dodavatelů, propojuje průběžný dohled nad dodavateli s 5.29 bezpečnost během narušení, 8.8 řízení technických zranitelností, 5.15 řízení přístupu, 8.27 principy bezpečné systémové architektury a inženýrství a 5.36 soulad.

Tento pohled napříč opatřeními je důležitý, protože změna regionu nikdy není pouze změnou regionu. Může změnit dodavatelské riziko, riziko přenosu, riziko přístupu, riziko kontinuity, důkazy pro reakci na incidenty a smluvní soulad.

Použijte tento kontrolní seznam CISO pro rok 2026 před schválením cloudové změny

Použijte tento kontrolní seznam před schválením jakéhokoli nového cloudového regionu, přeshraniční cesty zpracování, umístění záloh, platformy pro protokolování, modelu podpory nebo změny kritického dodavatele ICT.

Pokud odpověď na jakoukoli otázku zní „předpokládáme“, opatření není dostatečně vyspělé pro regulovaný provoz.

Plán nápravy

Cesta nápravy je praktická, pokud je ukotvena v ISMS.

1. Potvrďte, že rozsah ISMS zahrnuje cloudové služby, kritické závislosti ICT a regulované zpracování dat.
2. Vytvořte registr řízení cloudových regionů pro prioritní služby.
3. Namapujte každou službu na kategorie dat, regiony, umístění záloh, přístup podpory a dílčí zpracovatele.
4. Přezkoumejte smlouvy s dodavateli z hlediska ustanovení o umístění úložiště, přenosu, auditu, incidentech, subdodávkách, vrácení a zničení.
5. Aktualizujte registr rizik o mezery, rizika koncentrace a nedokumentované přenosy.
6. Slaďte registr třetích stran v oblasti ICT podle DORA a mapování závislostí služeb podle NIS2 tam, kde je to relevantní.
7. Ověřte technické prosazování, včetně uzamčení regionů, politik zálohování, nastavení protokolování, šifrování, řízení přístupu a správy klíčů.
8. Připravte balíček auditních důkazů se snímky obrazovky, smlouvami, záznamy rizik, schváleními, zápisy z přezkumů a výsledky testů.
9. Zaveďte spouštěč změny pro nové regiony, dílčí zpracovatele, mechanismy přenosu nebo kritické změny služeb dodavatelů.
10. Reportujte vedení rizika umístění dat v cloudu, výjimky a rozhodnutí o zbytkovém riziku.

Toto není teoretický soulad. Je to rozdíl mezi cloudovým prostředím, které obstojí při auditní kontrole, a prostředím, které závisí na ústních ujištěních.

Obchodní důvod: suverenita, odolnost a důvěra

Vrcholové vedení někdy vnímá řízení umístění dat jako omezení agility cloudu. V praxi vyspělé řízení regionů agilitu zvyšuje, protože týmy znají pravidla dříve, než nakupují, budují nebo migrují.

Produktový tým může spouštět rychleji, když jsou schválené regiony jasné. Nákup může vyjednávat rychleji, když jsou povinná ustanovení již definována. Právní oddělení může posuzovat přenosy rychleji, když jsou datové toky zdokumentovány. Bezpečnostní provoz může rychleji vyšetřovat, když jsou známa umístění logů a přístupová práva. Správní rada může rychleji rozhodovat o rizicích, když jsou viditelná rizika koncentrace, dopad na kontinuitu a přijetí zbytkového rizika.

Pro zákazníky, zejména regulované zákazníky, se z toho stává signál důvěry. Poskytovatel SaaS, který dokáže vysvětlit, kde se data nacházejí, jak jsou řízeny zálohy, jak je kontrolován přístup podpory, jak jsou schvalováni dílčí zpracovatelé a jak se přezkoumávají změny regionů, překoná poskytovatele, který pouze říká „používáme předního poskytovatele cloudu“.

V roce 2026 na tomto rozdílu záleží. NIS2 přinesla řízení kybernetické bezpečnosti základním a důležitým subjektům napříč EU. DORA učinila z dohledu nad třetími stranami v oblasti ICT formální disciplínu finančního sektoru. Odpovědnost podle GDPR zůstává ústřední. ISO/IEC 27001:2022 poskytuje systém řízení, který to drží pohromadě.

Další kroky s Clarysec

Pokud vaše organizace nedokáže odpovědět, kde se regulovaná data a kritické zpracování ICT nacházejí napříč produkcí, zálohami, logy, přístupem podpory a subdodavateli, je nyní čas mezeru uzavřít.

Clarysec vám pomůže vytvořit balíček důkazů pro řízení cloudových regionů pomocí:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint pro fázovanou implementaci ISO a připravenost na audit.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls pro mapování cloudových a dodavatelských opatření ISO/IEC 27002:2022 na provozní důkazy a očekávání napříč rámci.
• Cloud Usage Policy Politika používání cloudových služeb a Cloud Usage Policy-sme Politika používání cloudových služeb – SME pro požadavky na umístění cloudových dat.
• Third party and supplier security policy Bezpečnostní politika dodavatelů a třetích stran a Third-Party and Supplier Security Policy-sme Bezpečnostní politika dodavatelů a třetích stran – SME pro smlouvy s dodavateli, subdodávky a ujištění o geografickém umístění úložiště.
• Logging and Monitoring Policy-sme Politika protokolování a monitorování – SME pro uchovávání logů a důkazy od poskytovatelů.
• Legal and Regulatory Compliance Policy Politika právního a regulačního souladu pro spouštěče přezkumu souladu kolem mechanismů přenosu, dílčích zpracovatelů a přeshraničních toků dat.

Začněte jednou kritickou službou, jedním poskytovatelem cloudu a jedním registrem. Během několika workshopů se můžete posunout od předpokladů k důkazům a od roztříštěného souladu k řízené cloudové odolnosti.

Stáhněte si sadu nástrojů Clarysec, požádejte o demo nebo si objednejte posouzení řízení cloudových regionů, abyste své závazky k umístění dat v cloudu proměnili v důkaz připravený k auditu.