Důkazy k TOM podle GDPR Article 32 s vazbou na ISO 27001, NIS2 a DORA

E-mail dorazí do schránky CISO se známou tíhou obchodní příležitosti, která může ovlivnit výsledky společnosti za celé čtvrtletí.

Významný podnikový zájemce požaduje důkazy o „technických a organizačních opatřeních podle GDPR Article 32, namapovaných na ISO 27001:2022, NIS2 a DORA tam, kde jsou použitelné“. Právní oddělení zároveň informovalo řídicí orgán o odpovědnosti vedení podle NIS2 a o očekáváních DORA v oblasti provozní odolnosti. Pokyn řídicího orgánu zní jednoduše: doložit soulad, neduplikovat práci a neudělat z toho tři samostatné projekty.

Společnost má zavedená opatření. MFA je povinná. Zálohy běží. Vývojáři provádějí přezkum kódu. Tým ochrany soukromí vede záznamy o činnostech zpracování. Infrastrukturní tým vyhledává zranitelnosti. Dodavatelé jsou prověřováni v rámci nákupu. Jakmile si však zájemce vyžádá důkazy, odpověď se rozpadne na izolované části.

Výkaz poskytovatele identit je na jednom místě. Logy zálohování jsou jinde. Registr rizik nebyl aktualizován od poslední verze produktu. Bezpečnostní důkazy k dodavatelům jsou uložené v e-mailech nákupního oddělení. Zápisy ze scénářového cvičení reakce na incidenty existují, ale nikdo nedoloží, že získané poznatky byly promítnuty zpět do ošetření rizik. Řídicí orgán schválil výdaje na bezpečnost, ale schválení není propojeno s rizikem v oblasti ICT ani s dokumentovaným rozhodnutím o opatření.

To je skutečný problém technických a organizačních opatření podle GDPR Article 32, běžně označovaných jako TOM. Většina organizací neselhává proto, že by neměla žádná opatření. Selhává proto, že nedokáže doložit, že opatření jsou založená na rizicích, schválená, implementovaná, monitorovaná a zlepšovaná.

Odpovědnost podle GDPR toto očekávání výslovně stanoví. GDPR Article 5 vyžaduje, aby osobní údaje byly chráněny odpovídajícím zabezpečením proti neoprávněnému nebo protiprávnímu zpracování a proti náhodné ztrátě, zničení nebo poškození. Article 5(2) ukládá správci odpovědnost za prokázání souladu. Důležité jsou i definice v GDPR. Osobní údaje jsou široký pojem, zpracování zahrnuje téměř každou operaci s daty, pseudonymizace je uznávaným ochranným opatřením a porušení zabezpečení osobních údajů zahrnuje náhodné nebo protiprávní zničení, ztrátu, změnu, neoprávněné zpřístupnění nebo neoprávněný přístup.

Důkazní soubor k Article 32 proto nemůže být složkou náhodných snímků obrazovky. Musí jít o živý systém opatření.

Přístup Clarysec převádí TOM podle GDPR Article 32 na dohledatelný důkazní mechanismus postavený na ISO/IEC 27001:2022 ISO/IEC 27001:2022, posílený řízením rizik podle ISO/IEC 27005:2022 a křížově provázaný s povinnostmi podle NIS2 a DORA tam, kde se uplatní. Cílem není dokumentace pro dokumentaci. Cílem je zajistit připravenost organizace na audit dříve, než zákazník, auditor, regulační orgán nebo člen řídicího orgánu položí obtížnou otázku.

Proč TOM podle GDPR Article 32 v praxi selhávají

Article 32 se často chybně chápe jako seznam bezpečnostních nástrojů: šifrování, zálohování, protokolování, řízení přístupu a reakce na incidenty. Tato opatření jsou důležitá, ale obhajitelná jsou pouze tehdy, pokud odpovídají riziku a jsou propojena s životním cyklem osobních údajů.

U SaaS společnosti zpracovávající údaje o zaměstnancích zákazníků nestačí tvrzení „používáme šifrování“. Auditor se může zeptat, jaká data šifrování chrání, kde je šifrování vyžadováno, jak jsou spravovány klíče, zda jsou šifrovány zálohy, zda jsou produkční data maskována při testování, kdo může opatření obejít a jak se schvalují výjimky.

Podniková Politika ochrany dat a soukromí Clarysec zachycuje provozní princip takto:

„Implementovat technická a organizační opatření (TOM), která chrání důvěrnost, integritu a dostupnost osobních informací (PII) po celou dobu jejich životního cyklu.“

Zdroj: Politika ochrany dat a soukromí, Cíle, ustanovení politiky 3.3. Politika ochrany dat a soukromí

Slovní spojení „po celou dobu jejich životního cyklu“ je místo, kde mnoho programů TOM oslabuje. Osobní údaje mohou být chráněny v produkčním prostředí, ale současně kopírovány do analytických systémů, logů, exportů podpory, testovacích prostředí, záloh, platforem dodavatelů a zařízení zaměstnanců. Každé takové umístění vytváří bezpečnostní riziko i riziko pro ochranu soukromí.

GDPR Article 6 vyžaduje právní základ pro zpracování, včetně souhlasu, smlouvy, právní povinnosti, životně důležitých zájmů, veřejného úkolu nebo oprávněných zájmů. Pokud jsou data znovu použita k dalšímu účelu, je nutné posoudit slučitelnost a ochranná opatření, například šifrování nebo pseudonymizaci. U rizikovějších dat roste důkazní zátěž. GDPR Article 9 stanoví přísná omezení pro zvláštní kategorie osobních údajů, například údaje o zdraví, biometrické údaje používané k identifikaci a další citlivé informace. Article 10 omezuje zpracování údajů o odsouzeních v trestních věcech a trestných činech.

Pro malé a střední podniky formuluje Clarysec ošetření rizik prakticky:

„Opatření musí být implementována za účelem snížení identifikovaných rizik, včetně šifrování, anonymizace, bezpečné likvidace a omezení přístupu.“

Zdroj: Politika ochrany dat a soukromí pro MSP, Ošetření rizik a výjimky, ustanovení politiky 7.2.1. Politika ochrany dat a soukromí pro MSP

To je silný základ pro TOM. Aby byl připravený na audit, musí být každé opatření zároveň propojeno s rizikem, vlastníkem, požadavkem politiky, důkazní položkou a kadencí přezkumu.

ISO 27001:2022 je páteří důkazů pro Article 32

ISO 27001:2022 dobře podporuje GDPR Article 32, protože nahlíží na bezpečnost jako na systém řízení, nikoli jako na nesouvisející kontrolní seznam opatření. Vyžaduje systém řízení bezpečnosti informací neboli ISMS navržený tak, aby prostřednictvím řízení rizik zachovával důvěrnost, integritu a dostupnost.

Prvním kritickým krokem je rozsah. Kapitoly ISO 27001:2022 4.1 až 4.4 vyžadují, aby organizace porozuměla interním a externím otázkám, identifikovala zainteresované strany a jejich požadavky, určila, které požadavky budou řešeny v rámci ISMS, a definovala rozsah ISMS včetně rozhraní a závislostí na externích organizacích. Pro TOM podle Article 32 by rozsah ISMS měl odrážet zpracování osobních údajů, závazky vůči zákazníkům, zpracovatele, dílčí zpracovatele, cloudové platformy, práci na dálku, podpůrné funkce a produktová prostředí.

Druhým krokem je vedení. Kapitoly 5.1 až 5.3 vyžadují závazek vrcholového vedení, politiku bezpečnosti informací, zdroje, role a odpovědnosti a vykazování výkonnosti. Je to důležité, protože GDPR Article 32, NIS2 i DORA stojí na správě a řízení. Opatření bez vlastnictví, financování nebo přezkumu je slabým důkazem.

Podniková Politika bezpečnosti informací Clarysec to stanoví výslovně:

„ISMS musí zahrnovat definované hranice rozsahu, metodiku hodnocení rizik, měřitelné cíle a dokumentovaná opatření odůvodněná v Prohlášení o použitelnosti (SoA).“

Zdroj: Politika bezpečnosti informací, Požadavky na implementaci politiky, ustanovení politiky 6.1.2. Politika bezpečnosti informací

Tatáž politika stanoví očekávání k důkazům:

„Všechna implementovaná opatření musí být auditovatelná, podložená dokumentovanými postupy a uchovávanými důkazy o provozu.“

Zdroj: Politika bezpečnosti informací, Požadavky na implementaci politiky, ustanovení politiky 6.6.1.

Kapitoly ISO 27001:2022 6.1.1 až 6.1.3 následně vyžadují posouzení rizik, ošetření rizik, Prohlášení o použitelnosti, schválení zbytkového rizika a odpovědnost vlastníka rizika. Kapitola 6.2 vyžaduje měřitelné cíle. Kapitoly 7.5, 9.1, 9.2, 9.3 a 10.2 vyžadují dokumentované informace, monitorování, interní audit, přezkoumání vedením a nápravná opatření.

Pro GDPR Article 32 tím vzniká obhajitelná struktura.

ISO/IEC 27005:2022 tuto strukturu posiluje. Doporučuje organizacím identifikovat požadavky z přílohy A ISO 27001:2022, právních předpisů, smluv, odvětvových standardů, interních pravidel a stávajících opatření a následně je promítnout do posouzení a ošetření rizik. Vyžaduje také kritéria rizik a kritéria akceptace, která zohledňují právní, regulační, provozní, dodavatelské, technologické a lidské faktory včetně ochrany soukromí.

Politika řízení rizik Clarysec je s tím přímo sladěna:

„Formální proces řízení rizik musí být udržován v souladu s ISO/IEC 27005 a ISO 31000 a musí pokrývat identifikaci rizik, analýzu, hodnocení, ošetření, monitorování a komunikaci.“

Zdroj: Politika řízení rizik, Požadavky na správu a řízení, ustanovení politiky 5.1. Politika řízení rizik

Pro MSP se tentýž požadavek převádí do jednoduchého a použitelného pravidla:

„Každý záznam rizika musí obsahovat: popis, pravděpodobnost, dopad, skóre, vlastníka a plán ošetření.“

Zdroj: Politika řízení rizik pro MSP, Požadavky na správu a řízení, ustanovení politiky 5.1.2. Politika řízení rizik pro MSP

Tato věta je rychlým testem připravenosti na audit. Pokud riziko nemá vlastníka nebo plán ošetření, ještě není připraveno jako důkaz.

Most Clarysec: riziko, SoA, opatření a regulace

Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint chápe soulad jako práci s dohledatelností. Ve fázi řízení rizik se krok 13 zaměřuje na plánování ošetření rizik a Prohlášení o použitelnosti. Vysvětluje, že organizace mají mapovat opatření na rizika, přidávat odkazy na opatření z přílohy A do záznamů o ošetření rizik, křížově odkazovat externí regulace a získat schválení vedením.

Zenith Blueprint popisuje roli SoA přímo:

„SoA je fakticky přemosťující dokument: propojuje vaše posouzení/ošetření rizik se skutečnými opatřeními, která máte. Jeho dokončením zároveň ověříte, zda vám žádná opatření nechybí.“

Zdroj: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fáze řízení rizik, krok 13: Plánování ošetření rizik a Prohlášení o použitelnosti (SoA). Zenith Blueprint

Krok 14 v Zenith Blueprint přidává vrstvu křížových odkazů na regulaci. Doporučuje organizacím dokumentovat, jak jsou požadavky GDPR, NIS2 a DORA pokryty politikami a opatřeními. U GDPR zdůrazňuje ochranu osobních údajů v posouzeních rizik a ošetřeních rizik, včetně šifrování jako technického opatření a reakce na porušení zabezpečení jako součásti prostředí opatření. U NIS2 zdůrazňuje posouzení rizik, zabezpečení sítí, řízení přístupu, zvládání incidentů a kontinuitu činností. U DORA odkazuje na řízení rizik v oblasti ICT, reakci na incidenty, hlášení a dohled nad třetími stranami v oblasti ICT.

To je jádro metody Clarysec: jeden ISMS, jeden registr rizik, jedno SoA, jedna knihovna důkazů a více výsledků v oblasti souladu.

Zenith Controls: The Cross-Compliance Guide Zenith Controls tento přístup podporuje tím, že pomáhá organizacím používat témata opatření podle ISO/IEC 27002:2022 ISO/IEC 27002:2022 jako kotvy pro soulad napříč požadavky. Pro GDPR Article 32 mezi nejdůležitější kotvy často patří ochrana soukromí a PII, opatření 5.34; nezávislý přezkum bezpečnosti informací, opatření 5.35; a používání kryptografie, opatření 8.24.

NIS2 mění TOM na téma kybernetické bezpečnosti pro řídicí orgán

Mnoho organizací vnímá TOM podle GDPR jako odpovědnost týmu ochrany soukromí. NIS2 tuto debatu mění.

NIS2 se vztahuje na řadu středních a velkých subjektů ve vyjmenovaných odvětvích a v některých případech bez ohledu na velikost. Mezi dotčená digitální a technologická odvětví patří poskytovatelé cloudových služeb, poskytovatelé datových center, sítě pro doručování obsahu, poskytovatelé služeb DNS, registry TLD, poskytovatelé služeb vytvářejících důvěru, poskytovatelé veřejných elektronických komunikací, poskytovatelé řízených služeb, poskytovatelé řízených bezpečnostních služeb, online tržiště, vyhledávače a platformy sociálních sítí. Použitelnost pro SaaS a technologické MSP závisí na odvětví, velikosti, určení členským státem a systémovém nebo přeshraničním dopadu.

NIS2 Article 20 ukládá odpovědnost za kybernetickou bezpečnost řídicím orgánům. Ty musí schvalovat opatření pro řízení rizik kybernetické bezpečnosti, dohlížet na jejich implementaci a absolvovat školení. Základním subjektům mohou být uloženy správní pokuty nejméně 10 milionů EUR nebo nejméně 2 procenta celkového celosvětového ročního obratu. Důležité subjekty mohou čelit pokutám nejméně 7 milionů EUR nebo nejméně 1,4 procenta.

NIS2 Article 21 přímo souvisí s TOM podle Article 32, protože vyžaduje vhodná a přiměřená technická, provozní a organizační opatření. Tato opatření musí zohlednit stav techniky, evropské a mezinárodní normy, náklady, expozici, velikost, pravděpodobnost, závažnost a společenský nebo ekonomický dopad. Požadované oblasti zahrnují analýzu rizik, bezpečnostní politiky, zvládání incidentů, kontinuitu činností, zabezpečení dodavatelského řetězce, bezpečné pořizování a vývoj, zvládání zranitelností, posuzování účinnosti, kybernetickou hygienu, školení, kryptografii, personální bezpečnost, řízení přístupu, správu aktiv, MFA nebo průběžnou autentizaci a bezpečnou komunikaci tam, kde je vhodná.

NIS2 Article 23 doplňuje fázované hlášení incidentů: včasné varování do 24 hodin, oznámení incidentu do 72 hodin, průběžné aktualizace na vyžádání a závěrečnou zprávu nejpozději jeden měsíc po oznámení v 72hodinové lhůtě. Pokud se porušení zabezpečení osobních údajů zároveň kvalifikuje jako významný incident podle NIS2, musí váš důkazní soubor podporovat rozhodnutí o hlášení jak z pohledu ochrany soukromí, tak kybernetické bezpečnosti.

DORA zvyšuje laťku pro finanční odolnost a poskytovatele ICT

DORA se použije od 17. ledna 2025 a vytváří pravidla pro digitální provozní odolnost ve finančním sektoru. Pokrývá řízení rizik v oblasti ICT, hlášení závažných incidentů souvisejících s ICT, testování provozní odolnosti, sdílení informací o kybernetických hrozbách a zranitelnostech, rizika třetích stran v oblasti ICT, smluvní požadavky na poskytovatele ICT, dohled nad kritickými poskytovateli služeb ICT třetích stran a dohledovou činnost.

Pro finanční subjekty, které jsou zároveň identifikovány podle vnitrostátních pravidel NIS2, funguje DORA jako sektorově specifický právní akt Unie pro překrývající se povinnosti v oblasti řízení rizik kybernetické bezpečnosti a hlášení incidentů. V praxi by dotčené finanční subjekty měly v těchto překrývajících se oblastech upřednostnit DORA a zároveň udržovat koordinaci s příslušnými orgány podle NIS2 a CSIRT, kde je to relevantní.

Pro důkazy podle GDPR Article 32 je DORA důležitá dvěma způsoby. Zaprvé mohou fintech společnosti spadat přímo do její působnosti jako finanční subjekty, včetně úvěrových institucí, platebních institucí, poskytovatelů služeb informování o účtu, institucí elektronických peněz, investičních podniků, poskytovatelů služeb souvisejících s kryptoaktivy, obchodních systémů a poskytovatelů služeb skupinového financování. Zadruhé mohou být poskytovatelé SaaS, cloudových, datových, softwarových a řízených služeb finančními zákazníky považováni za poskytovatele služeb ICT třetích stran, protože DORA definuje služby ICT široce.

DORA Article 5 vyžaduje správu a interní kontroly pro řízení rizik v oblasti ICT, přičemž řídicí orgán definuje, schvaluje, dohlíží a zůstává odpovědný za uspořádání řízení rizik ICT. Article 6 vyžaduje dokumentovaný rámec řízení rizik v oblasti ICT včetně strategií, politik, postupů, protokolů ICT a nástrojů na ochranu informací a aktiv ICT. Article 17 vyžaduje proces řízení incidentů souvisejících s ICT zahrnující detekci, řízení, oznamování, zaznamenávání, analýzu kořenové příčiny, indikátory včasného varování, klasifikaci, role, komunikaci, eskalaci a reakci. Article 19 vyžaduje, aby závažné incidenty související s ICT byly hlášeny příslušným orgánům.

DORA Articles 28 a 30 činí z rizik třetích stran v oblasti ICT regulovanou oblast opatření. Finanční subjekty zůstávají odpovědné za soulad při využívání služeb ICT. Potřebují strategii pro rizika třetích stran, smluvní registry, posouzení kritičnosti, náležitou péči, přezkum rizika koncentrace, práva na audit a inspekci, spouštěče ukončení, exit strategie a smluvní ustanovení pokrývající umístění dat, dostupnost, autenticitu, integritu, důvěrnost, podporu při incidentech, obnovu, úrovně služeb a spolupráci s orgány.

Pro Article 32 to znamená, že dodavatelé jsou součástí souboru TOM. Bez řízení kritických zpracovatelů, cloudových platforem, analytických nástrojů, nástrojů podpory a poskytovatelů ICT nelze prokázat zabezpečení zpracování.

Praktická týdenní tvorba důkazů podle Article 32

Silný důkazní soubor začíná jedním jasným rizikovým scénářem.

Použijte tento příklad: „Neoprávněný přístup k osobním údajům zákazníků v produkční aplikaci.“

Vytvořte nebo aktualizujte záznam rizika. Zahrňte popis, pravděpodobnost, dopad, skóre, vlastníka a plán ošetření. Přiřaďte vlastníka vedoucímu vývoje, manažerovi bezpečnosti nebo rovnocenné odpovědné roli. Ohodnoťte pravděpodobnost podle modelu přístupu, vystavené útočné plochy, známých zranitelností a předchozích incidentů. Ohodnoťte dopad podle objemu osobních údajů, citlivosti, zákaznických smluv, důsledků podle GDPR a možného dopadu na službu podle NIS2 nebo DORA.

Vyberte ošetření, například MFA pro privilegovaný přístup, řízení přístupu založené na rolích, čtvrtletní přezkum přístupových práv, šifrování dat v klidu, TLS, skenování zranitelností, protokolování, upozorňování, bezpečné zálohování, postupy reakce na incidenty a maskování dat v neprodukčních prostředích.

Poté namapujte riziko na SoA. Přidejte odkazy ISO/IEC 27002:2022, například 5.34 ochrana soukromí a PII, 8.24 používání kryptografie, 5.15 řízení přístupu, 5.18 přístupová práva, 8.13 zálohování informací, 8.15 protokolování, 8.16 monitorovací činnosti, 8.8 řízení technických zranitelností, 8.25 bezpečný životní cyklus vývoje a 8.10 mazání informací tam, kde jsou použitelné. Přidejte poznámky ukazující, jak tato opatření podporují GDPR Article 32, NIS2 Article 21 a řízení rizik ICT podle DORA, kde je to relevantní.

U regulačního mapování zachovejte přesné názvy opatření a nevynucujte nepravdivou rovnocennost.

Nyní vybudujte složku důkazů. Politika monitorování auditu a souladu pro MSP od Clarysec stanoví jednoduché pravidlo:

„Všechny důkazy musí být uloženy v centralizované auditní složce.“

Zdroj: Politika monitorování auditu a souladu pro MSP, Požadavky na implementaci politiky, ustanovení politiky 6.2.1. Politika monitorování auditu a souladu pro MSP

Pro tento jeden rizikový scénář by složka měla obsahovat:

Důkazy o přístupu nemají končit u snímků obrazovky. Politika řízení přístupu pro MSP doplňuje užitečný provozní požadavek:

„IT manažer musí dokumentovat výsledky přezkumu a nápravná opatření.“

Zdroj: Politika řízení přístupu pro MSP, Požadavky na správu a řízení, ustanovení politiky 5.5.3. Politika řízení přístupu pro MSP

Důkazy o zálohování musí prokazovat obnovitelnost, nikoli pouze úspěšné úlohy. Politika zálohování a obnovy pro MSP uvádí:

„Testy obnovy se provádějí nejméně čtvrtletně a výsledky se dokumentují za účelem ověření obnovitelnosti.“

Zdroj: Politika zálohování a obnovy pro MSP, Požadavky na správu a řízení, ustanovení politiky 5.3.3. Politika zálohování a obnovy pro MSP

Tím vzniká úplná důkazní smyčka: regulace vytváří požadavek, riziko vysvětluje jeho význam, SoA vybírá opatření, politika definuje provoz a uchovávané důkazy prokazují, že opatření funguje.

Opatření v praxi: převod politiky na provozní důkazy

Fáze Zenith Blueprint Controls in Action, krok 19, se zaměřuje na technické ověření. Doporučuje přezkoumávat soulad zabezpečení koncových bodů, řízení identit a přístupů, konfigurace autentizace, zabezpečení správy zdrojového kódu, kapacitu a dostupnost, řízení zranitelností a záplat, bezpečné výchozí konfigurace, ochranu před škodlivým kódem, mazání a minimalizaci dat, maskování a testovací data, DLP, zálohování a obnovu, redundanci, protokolování a monitorování a synchronizaci času.

U TOM podle GDPR Article 32 je krok 19 místem, kde se abstraktní jazyk opatření mění v důkaz. Silný důkazní soubor má ukazovat, že:

• Šifrování koncových bodů je zapnuté a monitorované.
• Privilegovaní uživatelé mají MFA.
• Procesy nástupů, přesunů a odchodů jsou slaďovány se záznamy HR.
• Servisní účty jsou dokumentované a omezené.
• Repozitáře kódu mají řízení přístupu a probíhá skenování tajemství.
• Skeny zranitelností se provádějí a jsou sledovány až do nápravy.
• Produkční data se svévolně nekopírují do testovacích prostředí.
• Politiky bezpečného mazání a uchovávání se prosazují.
• Upozornění DLP jsou přezkoumávána.
• Testy obnovy ze záloh prokazují obnovitelnost.
• Logy jsou centralizované, uchovávané a přezkoumatelné.
• Synchronizace času podporuje spolehlivé vyšetřování incidentů.

Klíčové je propojení. Výkaz o záplatách bez odkazu na riziko, politiku a SoA je IT artefakt. Výkaz o záplatách propojený s GDPR Article 32, NIS2 Article 21, řízením rizik ICT podle DORA a plánem ošetření rizik podle ISO 27001:2022 je důkaz připravený na audit.

Jeden důkazní soubor, více auditních pohledů

Stejný důkazní materiál k TOM budou různé zainteresované strany číst odlišně. Přezkoumávající osoba pro ochranu soukromí se může zaměřit na osobní údaje, nezbytnost, přiměřenost a odpovědnost. Auditor ISO 27001 se může zaměřit na rozsah, ošetření rizik, SoA a důkazy o provozu. Orgán podle NIS2 se může zaměřit na dohled vedení, opatření podle Article 21 a připravenost na hlášení podle Article 23. Orgán dohledu podle DORA nebo finanční zákazník se může zaměřit na správu rizik ICT, testování odolnosti a závislosti na třetích stranách.

Clarysec používá Zenith Controls jako průvodce pro tento převod napříč požadavky na soulad.

Tím se předchází duplicitní práci na souladu. Namísto samostatných balíčků důkazů pro GDPR, NIS2 a DORA vytvořte jeden soubor důkazů o opatřeních a každou položku označte podle povinností, které podporuje.

Časté mezery v programech TOM podle Article 32

Nejčastější mezerou je osiřelé opatření. Společnost má opatření, například šifrování, ale nedokáže vysvětlit, které riziko ošetřuje, která politika ho vyžaduje, kdo ho vlastní nebo jak je přezkoumáváno.

Druhou mezerou jsou slabé důkazy k dodavatelům. Podle GDPR jsou zpracovatelé a dílčí zpracovatelé důležití. Podle NIS2 je zabezpečení dodavatelského řetězce součástí řízení rizik kybernetické bezpečnosti. Podle DORA jsou rizika třetích stran v oblasti ICT regulovanou doménou s registry, náležitou péčí, smluvními ochrannými opatřeními, právy na audit a exit plánováním. Tabulka dodavatelů nestačí, pokud kritické závislosti nejsou posouzeny z hlediska rizik a řízeny.

Třetí mezerou jsou důkazy k incidentům. Organizace často mají plán reakce na incidenty, ale nemají důkaz, že klasifikace, eskalace, hlášení orgánům a komunikace se zákazníky byly otestovány. NIS2 a DORA zde zvyšují očekávání a posouzení porušení zabezpečení osobních údajů podle GDPR musí být integrováno do stejného pracovního postupu.

Čtvrtou mezerou jsou důkazy o zálohách. Úspěšná zálohovací úloha neprokazuje obnovitelnost. Dokumentovaný test obnovy ano.

Pátou mezerou je přezkoumání vedením. TOM podle Article 32 musí být přiměřená riziku. Pokud vedení nikdy nepřezkoumává rizika, incidenty, problémy dodavatelů, rozpočet, zjištění auditu a zbytkové riziko, přiměřenost se prokazuje obtížně.

Finální toolkit připravený na audit

Fáze Audit, Review and Improvement v Zenith Blueprint, krok 30, poskytuje finální kontrolní seznam připravenosti. Zahrnuje rozsah a kontext ISMS, podepsanou politiku bezpečnosti informací, dokumenty posouzení a ošetření rizik, SoA, politiky a postupy k příloze A, záznamy o školení, provozní záznamy, zprávu z interního auditu, evidenci nápravných opatření, zápisy z přezkoumání vedením, důkazy o neustálém zlepšování a záznamy o povinnostech v oblasti souladu.

Podniková Politika monitorování auditu a souladu Clarysec stanoví účel této disciplíny:

„Vytvářet obhajitelné důkazy a auditní stopu na podporu regulačních šetření, soudních řízení nebo požadavků zákazníků na doložení ujištění.“

Zdroj: Politika monitorování auditu a souladu, Cíle, ustanovení politiky 3.4. Politika monitorování auditu a souladu

Vyspělý důkazní soubor TOM podle Article 32 by měl obsahovat:

Další kroky: vybudujte důkazy k TOM podle Article 32 s Clarysec

Pokud potřebujete prokázat technická a organizační opatření podle GDPR Article 32, nezačínejte sběrem náhodných snímků obrazovky. Začněte dohledatelností.

1. Definujte rozsah ISMS a hranice zpracování osobních údajů.
2. Identifikujte požadavky GDPR, NIS2, DORA, smluvní požadavky a požadavky zákazníků.
3. Vytvořte kritéria rizik s využitím ISO/IEC 27005:2022 a ochoty podstupovat riziko schválené vedením.
4. Vytvořte nebo aktualizujte registr rizik.
5. Namapujte každé ošetření na opatření ISO 27001:2022 a SoA.
6. Použijte Zenith Controls ke křížovému odkazování opatření pro ochranu soukromí, kryptografii, dodavatele, incidenty a nezávislý přezkum napříč očekáváními v oblasti souladu.
7. Postupujte podle Zenith Blueprint kroku 13 a kroku 14 a propojte rizika, opatření a regulační povinnosti.
8. Použijte Zenith Blueprint krok 19 k ověření technických opatření v provozu.
9. Použijte Zenith Blueprint krok 30 k sestavení finálního důkazního souboru připraveného na audit.
10. Ukládejte všechny důkazy centrálně, označujte je podle rizika a tématu opatření a udržujte nápravná opatření viditelná.

Clarysec vám pomůže převést GDPR Article 32 z vágní povinnosti v oblasti souladu na obhajitelný důkazní systém založený na rizicích a sladěný s ISO 27001:2022, NIS2 a DORA.

Začněte s Zenith Blueprint, posilte jej politikami Clarysec a použijte Zenith Controls, aby každé TOM bylo dohledatelné, testovatelné a připravené na audit.