Matice sdílené odpovědnosti v cloudu pro ISO, NIS2 a DORA

COO fintech společnosti volá CISO v pondělí v 07:15.

Evropský bankovní zákazník žádá důkaz, že SaaS platforma společnosti dokáže splnit požadavky DORA na rizika třetích stran v oblasti ICT. Obchodní tým již zaslal obvyklý balíček pro bezpečnostní prověření dodavatele: certifikát ISO, manažerské shrnutí penetračního testu, potvrzení o kybernetickém pojištění, oznámení o ochraně osobních údajů a zprávu o zajištění od poskytovatele cloudových služeb.

Banka se vrací s přesnější otázkou:

„Ukažte nám, kdo vlastní jednotlivá opatření ve vašem cloudovém prostředí. Vy, váš poskytovatel cloudových služeb, poskytovatel spravované databáze, poskytovatel identit, dodavatel protokolování a všichni dílčí zpracovatelé. A poté ukažte důkazy.“

Později téhož rána má CISO jednání se správní radou. CEO položí tutéž otázku obchodním jazykem: „Máme jistotu, že je tato platforma bezpečná, a kdo nese odpovědnost, pokud se něco pokazí?“

Právě zde se mnoho programů cloudového souladu zastaví.

Organizace může mít silného poskytovatele cloudových služeb, kvalitní nástroje, přiměřené politiky a registr rizik. Když má ale doložit hranice odpovědnosti, důkazy jsou roztříštěné. Nákupní oddělení má smlouvy. Právní oddělení má DPA. Vývojový tým má architektonické diagramy. Bezpečnostní tým má logy a cloudové konfigurace. Tým ochrany soukromí má seznam dílčích zpracovatelů. Tým compliance má Prohlášení o použitelnosti. Nikdo nemá jeden řízený artefakt, který po jednotlivých opatřeních uvádí, co dělá poskytovatel, co musí konfigurovat zákazník, který dílčí zpracovatel je zapojen, která doložka činí povinnost vymahatelnou a jaké důkazy má auditor očekávat.

Tímto artefaktem je matice sdílené odpovědnosti v cloudu.

Ne obecný slide velkého cloudového poskytovatele, který říká, že poskytovatel zabezpečuje cloud a zákazník zabezpečuje to, co je v cloudu. Skutečná matice sdílené odpovědnosti v cloudu pro ISO/IEC 27001:2022, NIS2, DORA a GDPR je záznam správy a řízení. Obstojí při náležité péči zákazníka, auditu ISO, přezkumu podle DORA, výzvě k doložení odpovědnosti podle GDPR i při vyšetřování incidentu.

Proč se sdílená odpovědnost v cloudu stává auditním problémem

Model sdílené odpovědnosti se obvykle vysvětluje jako technická hranice. V IaaS poskytovatel spravuje fyzické prostory, hardware, virtualizaci a základní infrastrukturu. Zákazník spravuje identity, data, pracovní zátěže, síťová pravidla, volby šifrování a konfigurace. V SaaS přebírá poskytovatel větší provozní odpovědnost, ale zákazník nadále vlastní uživatelský přístup, správu dat, právní základ, konfiguraci, očekávání v oblasti monitorování a eskalaci incidentů.

Toto vysvětlení je užitečné, ale neúplné.

Auditoři, regulační orgány a podnikoví zákazníci se neptají pouze „kdo opatření provozuje?“. Chtějí vědět:

• Kdo odpovídá za riziko?
• Která smluvní doložka činí tuto odpovědnost vymahatelnou?
• Která politika opatření vyžaduje?
• Která cloudová služba, SaaS platforma nebo dílčí zpracovatel je v rozsahu?
• Které důkazy prokazují, že opatření v období přezkumu fungovalo?
• Který požadavek rámce dané důkazy naplňují?
• Co se stane, pokud poskytovatel změní službu, lokalitu, subdodavatele nebo stav svých opatření?

ISO/IEC 27001:2022 ISO/IEC 27001:2022 z toho činí otázku systému řízení. Články 4.1 až 4.4 vyžadují, aby organizace rozuměla interním a externím otázkám, zainteresovaným stranám, právním a smluvním povinnostem, rozsahu ISMS, rozhraním a závislostem. Články 6.1.1 až 6.1.3 vyžadují posouzení rizik, ošetření rizik, schválení vlastníkem rizika, přijetí zbytkového rizika a Prohlášení o použitelnosti. Článek 8.1 vyžaduje operativní plánování a řízení, včetně řízení externě poskytovaných procesů, produktů a služeb relevantních pro ISMS.

Jednoduše řečeno, pokud poskytovatel cloudových služeb, dodavatel SaaS nebo dílčí zpracovatel podporuje podnikový proces v rozsahu, nemůže stát mimo ISMS. Musí být viditelný v rozsahu, rizicích, ošetření rizik, smluvním řízení a důkazech.

NIS2 zvyšuje požadavky. Article 21 vyžaduje, aby základní a důležité subjekty zavedly vhodná a přiměřená technická, provozní a organizační opatření, včetně analýzy rizik, řízení incidentů, kontinuity, zabezpečení dodavatelského řetězce, bezpečného pořizování, bezpečného vývoje, řízení zranitelností, posouzení účinnosti, kybernetické hygieny, kryptografie, bezpečnosti lidských zdrojů, řízení přístupu, správy aktiv a vícefaktorové autentizace nebo průběžné autentizace tam, kde je to vhodné. Article 20 ukládá odpovědnost za správu a řízení řídicím orgánům.

DORA je pro finanční subjekty ještě explicitnější. Použije se od 17. ledna 2025 a vyžaduje, aby finanční subjekty řídily rizika ICT, hlášení závažných incidentů souvisejících s ICT, testování digitální provozní odolnosti a rizika třetích stran v oblasti ICT. Articles 28 až 30 vyžadují řízení rizik třetích stran v oblasti ICT, předběžné posouzení rizika koncentrace, smluvní ochranná opatření, práva na audit a přístup, viditelnost subdodávek, práva na ukončení a exit strategie.

GDPR přidává test odpovědnosti. Article 5 vyžaduje, aby osobní údaje byly zpracovávány s integritou a důvěrností, a Article 5(2) vyžaduje, aby správce byl schopen doložit soulad. Article 28 upravuje smlouvy se zpracovateli a dílčími zpracovateli. Article 32 vyžaduje zabezpečení zpracování. Articles 33 a 34 vyžadují oznámení porušení zabezpečení osobních údajů, pokud je relevantní.

Matice sdílené odpovědnosti v cloudu se stává mostem mezi těmito povinnostmi.

Definice Clarysec: artefakt správy a řízení, nikoli diagram

V projektech Clarysec je matice sdílené odpovědnosti v cloudu řízeným záznamem ISMS, který propojuje cloudové služby, dodavatele, dílčí zpracovatele, opatření, politiky, smluvní povinnosti, důkazy a auditní očekávání.

Nejsilnější vysvětlení uvádí Zenith Blueprint Zenith Blueprint, ve fázi Controls in Action, Step 23:

„Poskytovatelé cloudových služeb zabezpečují infrastrukturu, ale vy stále nesete odpovědnost za svá data, své konfigurace, své politiky přístupu a svou připravenost na reakci na incidenty.“

Tentýž krok vysvětluje, že používání cloudu musí být považováno za součást ISMS, včetně klasifikace cloudových služeb, porozumění zpracovávaným nebo ukládaným datům, hodnocení poskytovatele, smluvních doložek a řízení změn služby. Tím se sdílená odpovědnost převádí z konceptu na dohledatelnou strukturu opatření.

Zenith Controls Zenith Controls považuje opatření přílohy A ISO/IEC 27001:2022 a doporučení ISO/IEC 27002:2022 5.20, 5.21 a 5.23 za centrální kotvy:

• 5.20, řešení bezpečnosti informací ve smlouvách s dodavateli.
• 5.21, řízení bezpečnosti informací v dodavatelském řetězci ICT.
• 5.23, bezpečnost informací při používání cloudových služeb.

Nejde o izolované položky kontrolního seznamu. Tvoří páteř matice.

Matici mohou posílit podpůrné normy. ISO/IEC 27017 pomáhá s cloudově specifickými bezpečnostními postupy. ISO/IEC 27018 a ISO/IEC 27701 podporují správu PII a ochranu soukromí. ISO/IEC 27005 podporuje posouzení rizik. ISO 22301 podporuje kontinuitu a odolnost. ISO/IEC 27035 podporuje řízení incidentů. ISO/IEC 20000-1 může pomoci tam, kde jsou cloudové služby součástí řízeného poskytování služeb.

Minimální životaschopná matice sdílené odpovědnosti

Vyspělá matice nezačíná 200 řádky. Začíná cloudovými službami, na kterých nejvíce záleží.

U SaaS, fintech nebo regulovaného SME Clarysec obvykle začíná těmito oblastmi:

1. Produkční cloudové prostředí určené zákazníkům.
2. Poskytovatel identit.
3. Spravovaná databáze nebo služba úložiště.
4. Platforma pro protokolování, monitorování a SIEM.
5. Platební, KYC, analytická nebo zákaznická SaaS služba.
6. Služba zálohování a obnovy po havárii.
7. Poskytovatel řízených služeb nebo poskytovatel řízených bezpečnostních služeb.
8. Dílčí zpracovatelé, kteří přistupují k zákaznickým datům, ukládají je nebo zpracovávají.

První matice má obsahovat následující sloupce.

Praktický řádek pro protokolování může vypadat takto.

Tento řádek není jen dokumentace. Říká bezpečnostnímu týmu, co má konfigurovat, nákupnímu oddělení, jaký smluvní jazyk má ověřit, týmu ochrany soukromí, jaký tok dat má zaznamenat, a auditorům, jaké důkazy mají vyžádat.

Základ v politikách: přeměna matice na vymahatelný požadavek

Matice sdílené odpovědnosti v cloudu bez opory v politice je pouze tabulka. Politiky Clarysec z ní činí vymahatelný požadavek.

Pro SME vyžaduje Politika používání cloudových služeb - SME Politika používání cloudových služeb - SME, část „Požadavky na správu a řízení“, doložka 5.3:

„Registr cloudových služeb musí být veden poskytovatelem IT služeb nebo GM. Musí zaznamenávat:“

Tatáž politika pro SME, doložka 5.2.3, propojuje správu cloudových služeb s ochranou soukromí a rizikem umístění dat:

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

Pro podnikové prostředí uvádí Politika používání cloudových služeb Politika používání cloudových služeb, část „Požadavky na správu a řízení“, doložka 5.1:

„Organizace musí udržovat centralizovaný registr cloudových služeb, jehož vlastníkem je CISO, obsahující:“

Doložka 5.4 poté činí odpovědnosti v cloudu smluvně vymahatelnými:

„Všechny smlouvy s poskytovateli cloudových služeb (CSP) musí obsahovat vymahatelná ustanovení pro:“

Správa dodavatelů rozšiřuje matici za bezprostředního poskytovatele. Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran - SME Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran - SME, část „Požadavky na správu a řízení“, doložka 5.3.5 vyžaduje:

„Omezení dalšího subdodavatelství bez schválení“

Tatáž dodavatelská politika pro SME, část „Požadavky na implementaci politiky“, doložka 6.3.1 doplňuje pravidelný přezkum:

„Kritičtí nebo vysoce rizikoví dodavatelé musí být přezkoumáváni nejméně jednou ročně. Přezkum musí ověřit:“

Na podnikové úrovni uvádí Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran, část „Požadavky na správu a řízení“, doložka 5.3:

„Smlouvy s dodavateli musí obsahovat:“

Pro osobní údaje vyžaduje Politika ochrany dat a soukromí Politika ochrany dat a soukromí, část „Vynucování a dodržování“, doložka 8.5.1:

„Smlouvy se zpracovateli musí obsahovat:“

Pro viditelnost závislostí vyžaduje Politika řízení rizik závislostí na dodavatelích Politika řízení rizik závislostí na dodavatelích, doložka 6.5.4:

„Využití dodavatelského vztahu k získávání aktualizací o subdodavatelích nebo závislostech dodavatelského řetězce o jednu úroveň níže, pokud by nás mohly ovlivnit (například pokud kritický dodavatel softwaru výrazně spoléhá na knihovnu třetí strany, musí být tato skutečnost zaznamenána).“

Pro logy poskytuje Politika protokolování a monitorování - SME Politika protokolování a monitorování - SME, část „Požadavky na správu a řízení“, doložka 5.5.1.3 konkrétní smluvní požadavek:

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

Společně tyto politiky činí z matice povinný záznam správy a řízení, který podporuje schvalování dodavatelů, zavádění cloudových služeb, odpovědnost v oblasti ochrany soukromí, každoroční přezkum a auditní důkazy.

Mapování matice napříč ISO/IEC 27001:2022, NIS2, DORA a GDPR

Klasickou chybou je vytvářet čtyři samostatné sešity souladu. Jedno opatření může naplnit několik povinností, pokud jsou odpovědnost a důkazy dohledatelné.

ISO/IEC 27001:2022 poskytuje motor ISMS: kontext, zainteresované strany, rozsah, vedení, ošetření rizik, cíle, operativní řízení, hodnocení výkonnosti a zlepšování. Příloha A poskytuje praktickou strukturu opatření.

NIS2 Article 21 se do stejné matice přirozeně mapuje přes zabezpečení dodavatelského řetězce, řízení incidentů, kontinuitu, řízení přístupu, správu aktiv a bezpečné pořizování. Article 20 činí matici relevantní pro správní radu, protože řídicí orgány musí schvalovat opatření pro řízení kybernetických rizik a dohlížet na ně.

DORA mění matici v nástroj pro rizika třetích stran v oblasti ICT. Articles 5, 6 a 8 vyžadují správu a řízení, dokumentované řízení rizik v oblasti ICT a identifikaci aktiv, funkcí a závislostí. Articles 17 až 19 vyžadují detekci incidentů, klasifikaci, eskalaci, komunikaci a hlášení. Articles 28 až 30 vyžadují řízení rizik třetích stran, analýzu rizika koncentrace, smluvní doložky, kontroly subdodavatelství, práva na audit, práva na ukončení a exit strategie.

GDPR přidává pohled osobních údajů. Každý řádek cloudové služby má určit, zda jsou zpracovávány osobní údaje, zda je poskytovatel zpracovatelem nebo dílčím zpracovatelem, zda je relevantní umístění dat a jaké smluvní důkazy nebo důkazy DPA existují.

NIST CSF 2.0 pomáhá komunikovat stejnou matici jazykem výsledků. Funkce GOVERN řeší kontext organizace, právní a regulační požadavky, závislosti, řízení rizik, role, politiky a dohled. Výsledky GV.SC jsou zvláště užitečné pro kybernetické riziko dodavatelů, včetně rolí dodavatelů, kritičnosti, smluvních požadavků, náležité péče, monitorování, koordinace incidentů a plánování ukončení.

COBIT 2019 přidává pohled zajištění a správy. Ptá se, zda jsou odpovědnost, řídicí postupy, vlastnictví, monitorování a náprava problémů opakovatelné a doložené.

Vytvoření matice od registru k důkazům

Představte si SaaS společnost používající hyperscale platformu IaaS, spravovanou databázi, poskytovatele identit třetí strany, SaaS platformu zákaznické podpory a externí SIEM. Postup implementace je přímočarý.

Krok 1: Začněte registrem cloudových služeb

Použijte Politiku používání cloudových služeb nebo Politiku používání cloudových služeb - SME jako spouštěč. Zaznamenejte každou cloudovou službu, vlastníka, účel, kategorie dat, umístění, podnikovou funkci, úroveň dodavatele, vlastníka smlouvy a datum přezkumu.

Pokud služba ukládá zákaznické záznamy, autentizační logy nebo tikety podpory, označte ji jako relevantní z hlediska ochrany soukromí. Pokud podporuje produkční dostupnost, označte ji jako provozně kritickou. Pokud podporuje kritickou nebo důležitou funkci finančního zákazníka, označte ji jako relevantní podle DORA.

Krok 2: Přidejte domény sdílené odpovědnosti

U každé služby definujte odpovědnosti v hlavních doménách.

Krok 3: Propojte opatření s rizikem a Prohlášením o použitelnosti

Zenith Blueprint, fáze Risk Management, Step 13, vysvětluje požadavek na dohledatelnost:

„Křížově odkazujte právní předpisy: Pokud jsou určitá opatření implementována konkrétně za účelem souladu s GDPR, NIS2 nebo DORA, můžete to uvést buď v registru rizik (jako součást odůvodnění dopadu rizika), nebo v poznámkách SoA.“

Například riziko „neoprávněný přístup k produkčním datům zákazníků prostřednictvím chybné cloudové konfigurace“ se může mapovat na řízení přístupu, používání cloudu, protokolování, kryptografii, řízení zranitelností a smlouvy s dodavateli. SoA může odkazovat na přílohu A ISO/IEC 27001:2022 5.15, 5.16, 5.20, 5.23, 8.8, 8.15, 8.16 a 8.24, s poznámkami pro GDPR Article 32, NIS2 Article 21 a řízení rizik ICT podle DORA, kde je to relevantní.

Krok 4: Připojte důkazy před auditní sezónou

Důkazy mají být navrženy přímo do matice, nikoli sbírány v panice.

Seznam důkazů mění odpovědnost v doložení. Pomáhá také obchodním týmům rychleji odpovídat na náležitou péči podnikových zákazníků, protože mohou ukázat nejen certifikace, ale také vlastnictví opatření a provozní důkazy.

Dílčí zpracovatelé: slepé místo většiny matic

Dílčí zpracovatelé jsou místem, kde se sdílená odpovědnost mění ve skutečné riziko dodavatelského řetězce.

Poskytovatel SaaS může být vaším zpracovatelem podle GDPR. Tento poskytovatel může spoléhat na poskytovatele cloudového hostingu, CDN, analytickou službu, platformu podpory, službu doručování e-mailů, spravovanou databázi, poskytovatele observability a zpracovatele plateb. Někteří mohou přistupovat k osobním údajům. Někteří mohou podporovat kritické poskytování služby, aniž by přímo viděli data. Někteří mohou být mimo EU. Někteří mohou být nahraditelní. Jiní mohou vytvářet riziko koncentrace.

DORA Article 29 vyžaduje posouzení rizika koncentrace u kritických nebo důležitých služeb ICT, včetně zastupitelnosti, více ujednání se stejnými nebo propojenými poskytovateli, řetězců subdodávek, subdodavatelů ze třetích zemí, insolvenčního práva, omezení obnovy dat a vymahatelnosti ochrany údajů v Unii. DORA Article 30 vyžaduje smluvní ustanovení týkající se podmínek subdodavatelství, lokalit, zpracování a ukládání dat, přístupu a obnovy, pomoci při incidentech, spolupráce s orgány, práv na audit, ukončení a exitu.

NIS2 Article 21 obdobně vyžaduje zabezpečení dodavatelského řetězce u přímých dodavatelů a poskytovatelů služeb a zohlednění zranitelností specifických pro dodavatele, postupů kybernetické bezpečnosti dodavatele a postupů bezpečného vývoje.

Proto Clarysec považuje mapování dílčích zpracovatelů za povinné rozšíření správy dodavatelů, nikoli pouze za seznam pro účely ochrany soukromí. Registr dílčích zpracovatelů má ukazovat, který dodavatel dílčího zpracovatele používá, která služba na něm závisí, zda jsou zpracovávány osobní údaje, zda podporuje kritickou funkci, relevantní region zpracování, přenesené smluvní povinnosti, práva na schválení nebo námitku, dostupné ujištění, metodu monitorování a možnost exitu.

Zenith Blueprint, fáze Controls in Action, Step 23 uvádí:

„U každého kritického dodavatele zjistěte, zda využívá subdodavatele (dílčí zpracovatele), kteří mohou přistupovat k vašim datům nebo systémům. Zdokumentujte, jak jsou vaše požadavky na bezpečnost informací přenášeny na tyto strany, ať již prostřednictvím smluvních podmínek vašeho dodavatele, nebo vašich vlastních přímých doložek.“

To je úroveň důkazů, kterou auditoři očekávají, když se ptají, zda jsou cloudové odpovědnosti řízeny i dále v řetězci.

Jak auditoři testují stejnou matici

Silná matice sdílené odpovědnosti v cloudu obstojí v různých stylech auditu, protože je postavena na vlastnictví, vymahatelnosti a důkazech.

Matice není cílem sama o sobě. Je mapou, podle níž auditoři testují, zda je systém správy a řízení skutečný.

Auditor ISO může vybrat vysoce dopadové riziko cloudového přístupu a sledovat jej z registru rizik do SoA, následně k přezkumu přístupových práv, důkazům MFA a monitorovacím upozorněním. Posuzovatel DORA může vybrat kritického poskytovatele ICT a požádat o exit test, analýzu subdodavatelství a smluvní práva na audit. Posuzovatel GDPR se může zaměřit na výmaz, umístění dat, oznamování porušení zabezpečení a transparentnost dílčích zpracovatelů.

Časté vzorce selhání

Nejčastější selhání sdílené odpovědnosti nejsou exotická.

Za prvé, organizace spoléhají na zprávy o zajištění od poskytovatele, aniž by je mapovaly na odpovědnosti zákazníka. Poskytovatel cloudových služeb může prokázat fyzickou bezpečnost, odolnost infrastruktury a opatření platformy, ale nikoli to, zda byl váš úložný bucket neveřejný, role IAM byly nastaveny podle zásady minimálních oprávnění nebo logy byly povoleny.

Za druhé, smlouvy obsahují obecný bezpečnostní jazyk, ale chybí časové lhůty pro incidenty, práva na přístup k logům, práva na audit, limity subdodavatelství, ustanovení o vrácení dat nebo podpora exitu. Zenith Blueprint, fáze Controls in Action, Step 23 zdůrazňuje typické oblasti dodavatelských smluv, jako jsou důvěrnost, řízení přístupu, technická a organizační opatření, lhůty pro incidenty, právo na audit, kontroly subdodavatelů a ustanovení při ukončení smlouvy.

Za třetí, dílčí zpracovatelé jsou uvedeni pro účely ochrany soukromí, ale nejsou propojeni s bezpečností, kontinuitou nebo rizikem koncentrace. Navazující poskytovatel observability nebo podpory se nemusí nikdy objevit v registru rizik, přestože jeho výpadek nebo porušení zabezpečení může ovlivnit poskytování služeb zákazníkům.

Za čtvrté, SoA uvádí, že opatření je použitelné, ale nikdo nedokáže předložit provozní důkazy. Cloudové protokolování může být označeno jako implementované, ale organizace nedokáže prokázat nastavení uchovávání, přezkumy přístupových práv, zpracování upozornění nebo závazky poskytovatele týkající se přístupu k logům.

Za páté, plány reakce na incidenty neodrážejí závislost na poskytovateli. Pokud poskytovatel oznámí incident platformy, kdo posoudí dopad na zákazníky? Kdo určí, zda je vyžadováno oznámení podle NIS2, DORA nebo GDPR? Kdo kontaktuje dotčené zákazníky? Co když je kořenová příčina u dílčího zpracovatele?

Odpovědnost vedení: proč by to mělo zajímat správní radu

NIS2 Article 20 vyžaduje, aby řídicí orgány schvalovaly opatření pro řízení kybernetických rizik, dohlížely na jejich implementaci a absolvovaly školení. DORA Article 5 vyžaduje, aby řídicí orgán definoval, schvaloval a dohlížel na ujednání pro řízení rizik ICT a nesl za ně odpovědnost, včetně politik třetích stran v oblasti ICT, plánů kontinuity a obnovy, plánů auditů, školení a oznamovacích kanálů.

Tím se mění účel matice. Už nejde jen o pracovní list bezpečnosti. Stává se důkazem, že vedení ví:

• Které cloudové služby podporují kritické provozní činnosti.
• Které třetí strany a dílčí zpracovatelé jsou významní.
• Které povinnosti vyplývají ze zákaznických smluv, GDPR, NIS2 a DORA.
• Které odpovědnosti zůstávají organizaci.
• Které závazky poskytovatele jsou smluvně vymahatelné.
• Které mezery vyžadují financování, nápravu nebo přijetí rizika.

U SME záleží na proporcionalitě. Menší subjekt nepotřebuje těžkopádnou byrokracii, ale stále potřebuje dokumentaci, monitorování, odolné systémy, detekci zdrojů rizik ICT, identifikaci klíčových závislostí na třetích stranách, opatření kontinuity, testování, získané poznatky a pravidelný přezkum tam, kde je v rozsahu.

Matice je jedním z nejefektivnějších proporcionálních nástrojů, protože povinnosti konsoliduje, místo aby je násobila.

30denní sprint pro auditně připravený cloudový model

Pokud nedokážete odpovědět, kdo vlastní jednotlivá cloudová opatření, jaké důkazy to prokazují a který dílčí zpracovatel je může ovlivnit, váš model sdílené odpovědnosti je stále diagram, nikoli artefakt správy a řízení.

Praktický 30denní sprint vypadá takto:

1. Vytvořte nebo aktualizujte registr cloudových služeb pomocí Politiky používání cloudových služeb nebo Politiky používání cloudových služeb - SME.
2. Identifikujte kritické služby, zpracování osobních údajů, systémy určené zákazníkům a relevanci podle DORA nebo NIS2.
3. Vytvořte první matici kolem opatření přílohy A ISO/IEC 27001:2022 5.20, 5.21 a 5.23 pomocí Zenith Controls.
4. Propojte každý řádek s registrem rizik a Prohlášením o použitelnosti pomocí Step 13 v Zenith Blueprint.
5. Ověřte doložky pro dodavatele a zpracovatele pomocí Bezpečnostní politiky dodavatelů a poskytovatelů služeb třetích stran, Bezpečnostní politiky dodavatelů a poskytovatelů služeb třetích stran - SME a Politiky ochrany dat a soukromí.
6. Doplňte důkazy o uchovávání logů, eskalaci incidentů, schvalování dílčích zpracovatelů, právech na audit a exitu.
7. Přezkoumávejte kritické dodavatele každoročně a po významných změnách, incidentech, nových dílčích zpracovatelích nebo zjištěních auditu.

Cíl je jednoduchý. Když se zákazník, auditor, regulační orgán nebo správní rada zeptá „kdo vlastní toto opatření?“, neprohledáváte smlouvy, tikety a složky. Otevřete matici, ukážete vlastníka, ukážete doložku, ukážete důkazy a ukážete stopu směrem dále v řetězci.

Clarysec vám může pomoci převést balíčky ujištění od poskytovatelů cloudových služeb na integrovanou matici sdílené odpovědnosti pro audity ISO/IEC 27001:2022, připravenost na NIS2, rizika třetích stran v oblasti ICT podle DORA, odpovědnost podle GDPR a náležitou péči podnikových zákazníků.

Začněte registrem. Vytvořte matici. Připojte důkazy. Poté ji používejte jako důkaz pro správní radu, že cloudové riziko není outsourcováno, ale řízeno.