Registr informací podle DORA: průvodce pro ISO 27001

Je úterý 09:15. Sarah, ředitelka informační bezpečnosti rychle rostoucí fintech společnosti, sedí na posouzení připravenosti se svým manažerem pro soulad s předpisy, právním poradcem, vedoucím nákupu a architektem cloudové bezpečnosti. Externí konzultant vystupuje v roli orgánu dohledu podle DORA.
„Děkuji za prezentaci,“ říká. „Předložte prosím svůj registr informací podle požadavků DORA Article 28, včetně smluvních ujednání o IKT službách podporujících kritické nebo důležité funkce, přehledu subdodavatelských vazeb, vlastnictví aktiv a důkazů, že je registr udržován v rámci vašeho rámce řízení rizik v oblasti IKT.“
První odpověď zní sebejistě: „Máme seznam dodavatelů.“
Pak začnou otázky.
Kteří dodavatelé podporují autorizaci plateb? Které smlouvy obsahují práva na audit, podporu při incidentech, závazky k umístění dat, práva na ukončení smlouvy a podporu při ukončení spolupráce? Které platformy SaaS zpracovávají osobní údaje zákazníků? Které cloudové služby podporují kritické nebo důležité funkce? Kteří subdodavatelé stojí za poskytovatelem řízených bezpečnostních služeb? Který interní vlastník aktiva schválil danou závislost? Která rizika v plánu ošetření rizik podle ISO/IEC 27001:2022 jsou na tyto poskytovatele navázána? Které položky v Prohlášení o použitelnosti odůvodňují zvolená opatření?
V 10:30 má tým otevřené čtyři tabulky, export z CMDB, složku SharePoint se smlouvami ve formátu PDF, seznam zpracovatelů pro účely ochrany osobních údajů, report cloudové fakturace a ručně vedený přehled SaaS. Žádný z těchto zdrojů si navzájem neodpovídá.
To je praktická výzva registru informací podle DORA v roce 2026. Implementace DORA se posunula z fáze „potřebujeme roadmapu“ do fáze „ukažte důkazy“. Pro finanční subjekty, externí poskytovatele IKT služeb, CISO, interní auditory a týmy compliance již registr není administrativní šablonou. Je spojovací vrstvou mezi smlouvami o IKT službách, rizikem dodavatelů, subdodavatelskými řetězci, cloudovými službami, IKT aktivy, kritickými funkcemi, vlastnictvím v rámci správy a řízení a důkazy podle ISO/IEC 27001:2022.
Přístup Clarysec je jednoduchý: nevytvářejte registr informací podle DORA jako samostatný artefakt compliance. Vytvořte jej jako živou důkazní vrstvu uvnitř svého ISMS, podpořenou správou aktiv, bezpečností dodavatelů, řízením používání cloudových služeb, mapováním právních a regulačních povinností, auditními metadaty a dohledatelností ošetření rizik.
Clarysec Zenith Controls: The Cross-Compliance Guide Zenith Controls identifikuje tři kotvicí opatření z přílohy A ISO/IEC 27001:2022 jako obzvlášť relevantní pro toto téma: A.5.9, evidence informací a dalších souvisejících aktiv; A.5.19, bezpečnost informací ve vztazích s dodavateli; a A.5.20, řešení bezpečnosti informací ve smlouvách s dodavateli. Tato opatření nejsou dodatečnou administrativou. Jsou provozní páteří pro doložení, že registr je úplný, má přiřazené vlastníky, je aktuální a auditovatelný.
Co DORA očekává od registru informací
DORA se použije od 17. ledna 2025 a zavádí pro finanční sektor soubor pravidel digitální provozní odolnosti, který zahrnuje řízení rizik v oblasti IKT, hlášení incidentů, testování odolnosti, rizika třetích stran, smluvní ujednání, dohled nad kritickými externími poskytovateli IKT služeb a dohledové prosazování. U finančních subjektů, které jsou zároveň identifikovány podle národní transpozice NIS2, funguje DORA jako odvětvový právní akt Unie pro odpovídající požadavky na řízení kybernetických rizik a hlášení incidentů.
Povinnost vést registr je součástí disciplíny řízení rizik externích poskytovatelů IKT služeb podle DORA. DORA Article 28 vyžaduje, aby finanční subjekty řídily riziko třetích stran v oblasti IKT jako součást rámce řízení rizik v oblasti IKT, zůstaly plně odpovědné za soulad i při využívání poskytovatelů IKT služeb, vedly registr informací pro smluvní ujednání o IKT službách a rozlišovaly ujednání podporující kritické nebo důležité funkce.
DORA Article 29 doplňuje hlediska rizika koncentrace a subdodavatelských vztahů. Patří sem nahraditelnost, vícenásobné závislosti na stejných nebo propojených poskytovatelích, subdodávky ve třetích zemích, omezení související s insolvencí, obnova dat, soulad v oblasti ochrany údajů a dlouhé nebo složité subdodavatelské řetězce.
DORA Article 30 následně definuje obsah smluv, který budou auditoři očekávat. Zahrnuje popis služeb, podmínky subdodávek, místa zpracování dat, závazky k ochraně údajů, povinnosti týkající se přístupu a obnovy, úrovně služeb, podporu při incidentech, spolupráci s orgány, práva na ukončení smlouvy, účast na školeních, práva na audit a strategie ukončení pro ujednání podporující kritické nebo důležité funkce.
Vyspělý registr informací podle DORA musí odpovědět na čtyři praktické otázky.
| Otázka k registru | Co orgány dohledu a auditoři skutečně testují |
|---|---|
| Jaké IKT služby používáte? | Úplnost smluvních ujednání o IKT službách, cloudových služeb, platforem SaaS a řízených služeb |
| Kdo je poskytuje a kdo stojí za nimi? | Vlastnictví dodavatelů, subdodavatelské řetězce, dílčí zpracovatelé a riziko koncentrace |
| Co podporují? | Vazba na kritické nebo důležité funkce, obchodní procesy, IKT aktiva a data |
| Dokážete doložit správu a řízení? | Smlouvy, posouzení rizik, opatření, vlastníci, monitorování, práva na audit, připravenost na ukončení spolupráce a metadata přezkumu |
Slabý registr je tabulka, kterou nákup aktualizuje jednou ročně. Silný registr je řízená datová sada, která propojuje portfolio dodavatelů, evidenci aktiv, registr cloudových služeb, repozitář smluv, záznamy o ochraně soukromí, plány kontinuity činností, playbooky pro incidenty, registr rizik a důkazy podle ISO/IEC 27001:2022.
Proč je ISO 27001 nejrychlejší cestou k obhajitelnému registru podle DORA
ISO/IEC 27001:2022 poskytuje organizacím strukturu systému řízení, která důkazům pro DORA často chybí. Kapitoly 4.1 až 4.4 vyžadují, aby organizace definovala kontext, zainteresované strany, právní, regulační a smluvní povinnosti, rozsah, rozhraní a závislosti. Přesně sem DORA v ISMS patří, protože registr závisí na znalosti toho, které finanční služby, poskytovatelé IKT, zákazníci, orgány, cloudové platformy a outsourcované procesy spadají do rozsahu.
Kapitoly 5.1 až 5.3 vyžadují vedení, sladění politik, zdroje, odpovědnosti a reportování vrcholovému vedení. To je důležité, protože DORA Article 5 ukládá řídicímu orgánu odpovědnost za definování, schvalování, dohled a zachování odpovědnosti za rámec řízení rizik v oblasti IKT, včetně politik pro služby IKT poskytované třetími stranami a reportovacích kanálů.
Kapitoly 6.1.1 až 6.1.3 jsou místem, kde se registr stává rizikově orientovaným. ISO/IEC 27001:2022 vyžaduje opakovatelný proces posouzení rizik, vlastníky rizik, analýzu pravděpodobnosti a dopadů, ošetření rizik, výběr opatření, Prohlášení o použitelnosti a schválení zbytkového rizika vlastníkem rizika. Registr podle DORA, který není propojen s ošetřením rizik, je statický seznam. Registr propojený s rizikovými scénáři, opatřeními a vlastníky se stává auditním důkazem.
Kapitoly 8.1 až 8.3 následně převádějí plánování do řízeného provozu. Podporují dokumentované informace, provozní plánování a řízení, řízení změn, řízení externě poskytovaných procesů, plánovaná opakovaná posouzení rizik, implementaci ošetření a uchovávání důkazů. To je pro rok 2026 zásadní, protože orgány dohledu se neptají jen na to, zda registr existoval v určitém okamžiku. Ptají se, zda jsou nové smlouvy, změněné služby, noví subdodavatelé, migrace do cloudu a ukončení vztahů zachyceny v cyklu správy a řízení.
Vrstva opatření přílohy A potvrzuje totéž. Vztahy s dodavateli, smlouvy s dodavateli, riziko v dodavatelském řetězci IKT, monitorování služeb dodavatelů, pořizování a ukončování cloudových služeb, řízení incidentů, kontinuita činností, právní a regulační povinnosti, ochrana soukromí, zálohy, protokolování, monitorování, kryptografie a řízení zranitelností – to vše přispívá ke kvalitě registru.
Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint vysvětluje základ ve správě aktiv ve fázi Controls in Action, krok 22:
Ve své nejstrategičtější podobě slouží evidence aktiv jako centrální nervový systém vašeho ISMS. Určuje, jak se zřizuje přístup (8.2), kde musí být uplatněno šifrování (8.24), které systémy vyžadují zálohování (8.13), jaké logy se shromažďují (8.15), a dokonce jak se prosazují politiky klasifikace a uchovávání (5.10, 8.10).
Tento citát vystihuje praktickou podstatu. Spolehlivý registr informací podle DORA nelze udržovat, pokud není spolehlivá podkladová evidence aktiv. Pokud váš registr uvádí „Core Banking SaaS“, ale evidence aktiv neukazuje rozhraní API, servisní účty, datové sady, zdroje logů, šifrovací klíče, závislosti zálohování a vlastníky, je registr z auditního pohledu neúplný.
Datový model Clarysec: jeden registr, více důkazních pohledů
Registr informací podle DORA nemá nahrazovat registr dodavatelů, evidenci aktiv ani registr cloudových služeb. Má je propojit. Clarysec obvykle navrhuje registr jako hlavní důkazní vrstvu s řízenými vazbami na stávající záznamy ISMS.
Minimální použitelný model má sedm propojených objektů.
| Objekt | Příklad polí | Vlastník důkazů |
|---|---|---|
| Smluvní ujednání o IKT službách | ID smlouvy, popis služby, datum zahájení, datum ukončení, obnovení, práva na ukončení smlouvy, práva na audit | Právní oddělení nebo řízení dodavatelů |
| Externí poskytovatel IKT služeb | Právnická osoba, lokalita, kritičnost, certifikace, stav náležité péče, rizikové hodnocení | Řízení dodavatelů |
| Subdodavatel nebo dílčí zpracovatel | Role ve službě, přístup k datům, země, stav schválení, přenesené povinnosti | Řízení dodavatelů a ochrana soukromí |
| IKT služba | SaaS, cloud hosting, řízená bezpečnost, platební brána, datová analytika | IT nebo vlastník služby |
| Podporovaná funkce | Příznak kritické nebo důležité funkce, obchodní proces, priorita obnovy | Vlastník obchodní funkce |
| Informační a IKT aktiva | Aplikace, datové sady, rozhraní API, logy, klíče, účty, repozitáře, infrastruktura | Vlastník aktiva |
| Důkazy ISMS | Posouzení rizik, mapování SoA, smluvní ustanovení, přezkum monitorování, playbook pro incidenty, test ukončení | CISO nebo compliance |
Tato struktura umožňuje, aby jeden registr podporoval více požadavků na důkazy. Orgán dohledu podle DORA může zobrazit smluvní ujednání podporující kritické nebo důležité funkce. Auditor ISO může dohledat dodavatelská opatření k odkazům na přílohu A a k ošetření rizik. Osoba provádějící přezkum podle GDPR vidí zpracovatele, kategorie dat, lokality a závazky k ochraně údajů. Hodnotitel orientovaný na NIST může přezkoumat řízení dodavatelského řetězce, kritičnost dodavatelů, smluvní požadavky a monitorování životního cyklu.
Registr se stává něčím víc než odpovědí na otázku „kdo jsou naši dodavatelé?“ Stává se grafem závislostí.
Základy politik, které činí registr auditovatelným
Soubor politik Clarysec dává registru provozní domov. Pro malé a střední podniky začíná Bezpečnostní politika dodavatelů a externích poskytovatelů služeb – SME Bezpečnostní politika dodavatelů a externích poskytovatelů služeb - SME jasným požadavkem na registr:
Registr dodavatelů musí být udržován a aktualizován administrativní nebo nákupní kontaktní osobou. Musí obsahovat:
Stejná politika pro SME stanoví, že smlouvy musí obsahovat definované bezpečnostní povinnosti:
Smlouvy musí obsahovat povinná ustanovení pokrývající:
I když citovaná ustanovení v samotné politice uvádějí seznamy polí a kategorie povinných smluvních ustanovení, implementační sdělení je přímé: správa dodavatelů musí být dokumentovaná, přiřazená a smluvně vynutitelná.
Pro podniková prostředí je Clarysec Politika řízení rizik závislostí na dodavatelích Politika řízení rizik závislostí na dodavatelích ještě blíže očekáváním orgánů dohledu podle DORA:
Registr závislostí na dodavatelích: VMO musí udržovat aktuální registr všech kritických dodavatelů, včetně údajů, jako jsou poskytované služby/produkty; zda je dodavatel jediný zdroj; dostupní alternativní dodavatelé nebo zastupitelnost; aktuální smluvní podmínky; a posouzení dopadu, pokud by dodavatel selhal nebo byl kompromitován. Registr musí jasně identifikovat dodavatele s vysokou mírou závislosti (např. ty, pro které neexistuje rychlá alternativa).
To přesně odpovídá DORA Article 29 a riziku koncentrace a nahraditelnosti. Pokud je dodavatel jediným zdrojem, podporuje kritickou funkci, působí ve třetí zemi, využívá dlouhý subdodavatelský řetězec a nemá otestovanou cestu ukončení, registr nesmí toto riziko skrývat ve volné textové poznámce. Musí je označit, přiřadit vlastníka a propojit s ošetřením rizik.
Podniková Bezpečnostní politika dodavatelů a externích poskytovatelů služeb Clarysec Bezpečnostní politika dodavatelů a externích poskytovatelů služeb výslovně vymezuje rozsah:
Pokrývá jak přímé dodavatele, tak případně jejich subdodavatele a zahrnuje software třetích stran, infrastrukturu, podporu a řízené služby.
Tato věta odpovídá časté mezeře podle DORA. Mnoho organizací zachycuje přímé poskytovatele IKT, ale nedokumentuje subdodavatele, dílčí zpracovatele, nástroje řízených služeb, platformy podpory nebo software třetích stran vložený do služby.
Důležité jsou také smluvní důkazy. Stejná podniková politika obsahuje:
Práva na audit, kontrolu a vyžádání bezpečnostních důkazů
Tato formulace musí být viditelná ve vašem kontrolním seznamu pro přezkum smluv. Pokud smlouva s kritickým poskytovatelem IKT neobsahuje práva na audit nebo právo vyžádat si důkazy, registr musí označit nápravné opatření.
Stejně důležité jsou důkazy o aktivech. SME Politika správy aktiv Clarysec Politika správy aktiv - SME stanoví:
Vedoucí IT musí udržovat strukturovanou evidenci aktiv, která obsahuje minimálně následující pole:
Podniková Politika správy aktiv Politika správy aktiv obdobně stanoví:
Evidence aktiv musí obsahovat minimálně:
Registr nemusí duplikovat každé pole evidence aktiv, ale musí na evidenci aktiv odkazovat. Pokud SaaS pro monitorování plateb podporuje detekci podvodů, registr podle DORA má odkazovat na aplikační aktivum, datovou sadu, servisní účty, integrace API, zdroje logů a vlastníka obchodní funkce.
Cloudové služby si zaslouží samostatný pohled. SME Politika používání cloudových služeb Clarysec Politika používání cloudových služeb - SME vyžaduje:
Registr cloudových služeb musí být udržován poskytovatelem IT služeb nebo GM. Musí zaznamenávat:
To je obzvlášť cenné pro odhalování shadow IT. Registr podle DORA, který nezahrnuje cloudové služby pořízené mimo nákup, neprojde praktickým testem úplnosti.
Nakonec Politika právního a regulačního souladu Clarysec Politika právního a regulačního souladu převádí cross-compliance na požadavek ISMS:
Všechny právní a regulační povinnosti musí být mapovány na konkrétní politiky, opatření a vlastníky v rámci Systému řízení bezpečnosti informací (ISMS).
To je most mezi registrem podle DORA a důkazy ISO 27001. Registr nemá ukazovat pouze dodavatele. Má ukazovat, které politiky, opatření a vlastníci plní regulační povinnost.
Mapování požadavků DORA na ISO 27001 a důkazy Clarysec
Níže uvedená tabulka kombinuje klíčová očekávání od registru s opatřeními přílohy A ISO/IEC 27001:2022 a praktickými důkazními artefakty Clarysec.
| Požadavek registru podle DORA | Důkazní kotva ISO/IEC 27001:2022 | Politika nebo nástroj Clarysec | Praktický důkazní artefakt |
|---|---|---|---|
| Registr všech smluvních ujednání o IKT službách | A.5.20, řešení bezpečnosti informací ve smlouvách s dodavateli | Bezpečnostní politika dodavatelů a externích poskytovatelů služeb – SME | Registr smluv s ID smlouvy, vlastníkem, daty, stavem obnovení a klíčovými ustanoveními |
| Identifikace kritických nebo důležitých funkcí | Kapitoly 4.3, 6.1.2, 8.1 a A.5.9 | Politika řízení rizik závislostí na dodavatelích | Příznak kritičnosti propojený s obchodní funkcí, posouzením rizik a vlastníkem aktiva |
| Mapování dodavatelů na aktiva | A.5.9, evidence informací a dalších souvisejících aktiv | Politika správy aktiv | Záznamy evidence aktiv propojené se záznamy dodavatele a IKT služby |
| Přehled o subdodavatelském řetězci | A.5.19, vztahy s dodavateli, a A.5.21, řízení bezpečnosti informací v dodavatelském řetězci IKT | Bezpečnostní politika dodavatelů a externích poskytovatelů služeb | Záznamy náležité péče, záznamy o dílčích zpracovatelích a důkazy o přenesených povinnostech |
| Monitorování dodavatelů | A.5.22, monitorování, přezkum a řízení změn služeb dodavatelů | Politika řízení rizik závislostí na dodavatelích | Čtvrtletní přezkumy, důkazy o ujištění, reportování SLA a sledování problémů |
| Správa cloudových služeb a ukončení | A.5.23, bezpečnost informací při používání cloudových služeb | Politika používání cloudových služeb - SME | Registr cloudových služeb, posouzení cloudových rizik a plán ukončení |
| Práva na audit a kontrolu | A.5.20 a A.5.35, nezávislý přezkum bezpečnosti informací | Bezpečnostní politika dodavatelů a externích poskytovatelů služeb | Kontrolní seznam smluvních ustanovení a práva na vyžádání důkazů |
| Mapování právních a regulačních povinností | Kapitoly 4.2, 4.3, 6.1.3 a A.5.31, právní, statutární, regulační a smluvní požadavky | Politika právního a regulačního souladu | Mapa povinností DORA propojená s politikami, opatřeními a vlastníky |
| Aktuálnost důkazů a metadata | Kapitola 7.5 a kapitola 9.1 | Politika monitorování auditu a souladu - SME | Export registru se zdrojovým systémem, osobou, která data shromáždila, datem, přezkoumávající osobou a stavem schválení |
Právě v tomto mapování registr přestává být tabulkou a stává se důkazním modelem. Každý řádek má mít vlastníka smlouvy, vlastníka dodavatele, vlastníka služby, vlastníka obchodní funkce a vlastníka compliance. Každý kritický vztah má mít záznam rizika, kontrolní seznam smluvních ustanovení, vazbu na aktivum a periodicitu monitorování.
Praktický příklad: mapování jedné smlouvy o IKT službě na důkazy ISO 27001
Představte si finanční subjekt, který používá cloudovou platformu pro analytiku podvodů. Služba přijímá metadata transakcí, podporuje skórování podvodů v reálném čase, integruje se s platební platformou, ukládá pseudonymizované identifikátory zákazníků, využívá subdodavatele cloudového hostingu a poskytuje řízenou podporu ze schválené lokality ve třetí zemi.
Slabý řádek registru uvádí: „Dodavatel: FraudCloud. Služba: analytika podvodů. Smlouva podepsána. Kritické: ano.“
Řádek registru na úrovni očekávané dohledem vypadá zcela jinak.
| Pole registru | Příklad záznamu |
|---|---|
| Poskytovatel IKT služeb | FraudCloud Ltd |
| IKT služba | Cloudová analytika podvodů a skórovací API |
| ID smlouvy | LEG-ICT-2026-014 |
| Podporovaná funkce | Detekce platebních podvodů, kritická nebo důležitá funkce |
| Vlastník obchodní funkce | Vedoucí platebního provozu |
| Vlastník IKT | Vedoucí platformního inženýrství |
| Vazby na aktiva | APP-042 API pro skórování podvodů, DATA-119 metadata transakcí, API-017 integrace platební brány, LOG-088 auditní logy podvodů |
| Role v oblasti dat | Zpracovatel metadat transakcí a pseudonymizovaných identifikátorů zákazníků |
| Lokality | Primární zpracování v regionu EU, podpůrný přístup ze schválené lokality ve třetí zemi |
| Subdodavatelé | Poskytovatel cloudového hostingu, platforma podpůrných tiketů |
| Klíčová ustanovení | Podpora při incidentech, práva na audit, oznámení subdodavatele, vrácení dat, úrovně služeb, podpora při ukončení |
| Důkazy ISO | Posouzení rizik dodavatele, záznam evidence aktiv, odkazy na SoA, kontrolní seznam přezkumu smlouvy, cloudové posouzení, přezkum monitorování |
| Rizikové příznaky DORA | Kritická funkce, podpora ze třetí země, subdodávky, riziko koncentrace při absenci alternativy |
| Periodicita přezkumu | Čtvrtletní přezkum výkonnosti, každoroční ujištění od dodavatele, přezkum spouštěný změnou subdodavatele nebo architektury |
Tým compliance nyní může vytvořit ucelený balíček důkazů. Registr dodavatelů dokládá existenci poskytovatele a jeho vlastníka. Evidence aktiv dokládá, že interní systémy, rozhraní API, datové sady a logy jsou známé. Kontrolní seznam smlouvy dokládá, že povinná ustanovení podle DORA byla přezkoumána. Posouzení rizik dokládá, že byla zohledněna koncentrace, subdodávky, ochrana údajů a provozní odolnost. Prohlášení o použitelnosti ukazuje, která opatření byla vybrána. Přezkum monitorování dokládá, že ujednání po onboardingu nezůstalo bez správy.
Zenith Blueprint, fáze Risk Management, krok 13, doporučuje přesně tento typ dohledatelnosti:
Křížově odkazujte právní předpisy: Pokud jsou určitá opatření implementována konkrétně za účelem splnění 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.
Tak se registr podle DORA stává důkazem ISO 27001 místo paralelní byrokracie.
Dodavatelský a subdodavatelský řetězec je místo, kde kvalita registru selhává
Největší selhání registru nejsou způsobena chybějícími hlavními dodavateli. Způsobují je skryté řetězce závislostí.
Poskytovatel řízených bezpečnostních služeb může používat platformu SIEM, agenta telemetrie koncových bodů, ticketovací systém a offshore tým pro triáž. Zpracovatel plateb může záviset na cloudovém hostingu, službách identit, databázích podvodů a napojení na vypořádání. Poskytovatel SaaS se může spoléhat na více dílčích zpracovatelů pro analytiku, e-mail, observabilitu, zákaznickou podporu a zálohy.
DORA Article 29 soustředí pozornost na riziko koncentrace a subdodávek. NIS2 Article 21 rovněž vyžaduje zabezpečení dodavatelského řetězce pro přímé dodavatele a poskytovatele služeb a očekává, že subjekty budou zohledňovat zranitelnosti specifické pro každého přímého dodavatele, celkovou kvalitu produktu, postupy kybernetické bezpečnosti dodavatele a postupy bezpečného vývoje. Pro finanční subjekty pokryté DORA působí DORA jako odvětvový soubor pravidel pro překrývající se požadavky NIS2 na řízení kybernetických rizik a hlášení incidentů, ale logika dodavatelského řetězce je sladěná.
Clarysec Zenith Blueprint, fáze Controls in Action, krok 23, poskytuje praktický pokyn:
U každého kritického dodavatele zjistěte, zda využívá subdodavatele (dílčí zpracovatele), kteří mohou mít přístup 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, buď prostřednictvím smluvních podmínek vašeho dodavatele, nebo prostřednictvím vašich vlastních přímých ustanovení.
Právě zde mnoho organizací v roce 2026 potřebuje nápravu. Smlouvy podepsané před přípravou na DORA nemusí obsahovat transparentnost subdodavatelů, práva na auditní důkazy, spolupráci s orgány, podporu při incidentech, podporu při ukončení nebo závazky k lokalitám. Registr má proto obsahovat stav nápravy smlouvy, například dokončeno, mezera přijata, probíhá renegociace nebo požadována varianta ukončení.
Cross-compliance: DORA, NIS2, GDPR a NIST potřebují stejnou pravdu o závislostech
Dobře navržený registr informací podle DORA podporuje více než jen DORA.
NIS2 Article 20 činí z kybernetické bezpečnosti odpovědnost řídicího orgánu prostřednictvím schvalování, dohledu a školení. Article 21 vyžaduje analýzu rizik, politiky, zvládání incidentů, kontinuitu, zabezpečení dodavatelského řetězce, bezpečné pořizování a údržbu, hodnocení účinnosti, kybernetickou hygienu, kryptografii, bezpečnost HR, řízení přístupu, správu aktiv a MFA tam, kde je to vhodné. Tyto oblasti se silně překrývají s ISO/IEC 27001:2022 a důkazním modelem registru.
GDPR doplňuje odpovědnost za ochranu soukromí. Jeho územní působnost se může vztahovat na organizace v EU i mimo EU, které zpracovávají osobní údaje v souvislosti s provozovnami v EU, nabízejí zboží nebo služby fyzickým osobám v EU nebo monitorují jejich chování. Definice GDPR pro správce, zpracovatele, zpracování, pseudonymizaci a porušení zabezpečení osobních údajů jsou přímo relevantní pro mapování dodavatelů IKT. Pokud registr podle DORA identifikuje poskytovatele IKT a subdodavatele, ale neidentifikuje role při zpracování osobních údajů, kategorie dat, lokality a ochranná opatření, nebude podporovat důkazy GDPR.
NIST CSF 2.0 poskytuje další užitečný pohled. Jeho funkce GOVERN vyžaduje, aby organizace rozuměly poslání, očekáváním zainteresovaných stran, závislostem, právním a smluvním požadavkům, službám, na nichž závisejí ostatní, i službám, na nichž závisí organizace. Výstupy GV.SC pro dodavatelský řetězec vyžadují program řízení rizik dodavatelského řetězce, definované role dodavatelů, integraci do podnikového řízení rizik, kritičnost dodavatelů, smluvní požadavky, náležitou péči, monitorování životního cyklu, koordinaci incidentů a plánování po ukončení vztahu.
Praktický pohled cross-compliance vypadá takto.
| Potřeba důkazů | Pohled DORA | Pohled důkazů ISO 27001 | Pohled NIST CSF 2.0 | Pohled GDPR |
|---|---|---|---|---|
| Úplnost dodavatelů IKT | Registr smluvních ujednání o IKT službách | Registr dodavatelů a řízení externě poskytovaných procesů | GV.SC identifikace a prioritizace dodavatelů | Záznamy o zpracovatelích a dílčích zpracovatelích |
| Kritičnost | Příznak kritické nebo důležité funkce | Posouzení rizik, dopad na obchodní činnost a vlastnictví aktiv | Kontext organizace a kritické služby | Riziko pro subjekty údajů, pokud jsou zapojeny osobní údaje |
| Smluvní ustanovení | Smluvní obsah podle DORA Article 30 | Důkazy opatření pro smlouvy s dodavateli | Smluvní požadavky na kybernetickou bezpečnost | Podmínky zpracování osobních údajů a ochranná opatření |
| Subdodávky | Subdodavatelský řetězec a riziko koncentrace | Monitorování dodavatelů a přenesené povinnosti | Monitorování životního cyklu dodavatelského řetězce | Transparentnost dílčích zpracovatelů a ochranná opatření pro předávání |
| Ukončení | Ukončení, přechod a vrácení dat | Ukončení cloudových služeb, kontinuita a důkazy životního cyklu aktiv | Plánování po ukončení vztahu | Důkazy o vrácení, výmazu a uchovávání |
Cílem není vytvořit pět pracovních proudů compliance. Cílem je vytvořit jeden důkazní model, který lze filtrovat pro každý rámec.
Pohledem auditora
Orgán dohledu podle DORA se zaměří na úplnost, kritické nebo důležité funkce, smluvní ujednání, subdodávky, riziko koncentrace, správu a řízení, reportování a to, zda je registr udržován. Může si vyžádat vzorek kritických poskytovatelů a očekávat smluvní ustanovení, posouzení rizik, strategie ukončení, podmínky podpory při incidentech a důkazy o dohledu vedení.
Auditor ISO/IEC 27001:2022 začne u rozsahu ISMS, zainteresovaných stran, regulačních povinností, posouzení rizik, Prohlášení o použitelnosti, provozního řízení a dokumentovaných informací. Ověří, zda jsou udržovány vztahy s dodavateli a evidence aktiv, zda jsou řízeny externě poskytované procesy, zda změny spouštějí opakované posouzení a zda důkazy podporují deklarovanou implementaci opatření.
Hodnotitel NIST CSF 2.0 se často zeptá na aktuální a cílové profily, očekávání v oblasti správy a řízení, mapování závislostí, kritičnost dodavatelů, integraci smluv, monitorování životního cyklu a prioritizovaná zlepšovací opatření.
Auditor orientovaný na COBIT 2019 bude typicky zkoumat vlastnictví v oblasti správy a řízení, odpovědnost za procesy, rozhodovací pravomoci, monitorování výkonnosti, reportování rizik a zajištění. Zeptá se, zda je registr začleněn do správy a řízení podniku, nikoli pouze udržován týmem compliance.
Zenith Controls pomáhá tyto pohledy převést tím, že téma ukotvuje v opatřeních A.5.9, A.5.19 a A.5.20 přílohy A ISO/IEC 27001:2022 a následně pomocí výkladu cross-compliance propojuje aktiva, vztahy s dodavateli a smlouvy s dodavateli s regulačními, řídicími a auditními očekáváními. To je rozdíl mezi „máme registr“ a „dokážeme registr obhájit“.
SME Politika monitorování auditu a souladu Clarysec Politika monitorování auditu a souladu - SME řeší také kvalitu důkazů:
Metadata (např. kdo je shromáždil, kdy a z jakého systému) musí být dokumentována.
Tento požadavek je malý, ale silný. Při požadavku na důkazy v roce 2026 je tabulka bez metadat sběru slabá. Export registru, který ukazuje zdrojový systém, datum extrakce, odpovědného vlastníka, stav schválení a periodicitu přezkumu, je podstatně silnější.
Častá zjištění k registru informací podle DORA v roce 2026
Nejčastější zjištění jsou praktická.
Za prvé, neúplnost registru. Cloudové služby, nástroje podpory, monitorovací platformy, vývojářské nástroje, ticketovací systémy a platformy datové analytiky často chybí, protože je nákup neklasifikoval jako IKT služby.
Za druhé, slabá logika kritičnosti. Některé týmy označují dodavatele jako kritické podle výše výdajů, nikoli podle dopadu na činnost. DORA se zajímá o to, zda IKT služba podporuje kritickou nebo důležitou funkci.
Za třetí, mezery ve smluvních důkazech. Starší smlouvy s dodavateli často postrádají ustanovení připravená pro DORA, například práva na audit, podporu při incidentech, subdodávky, spolupráci s orgány, lokality služeb, vrácení dat, ukončení a podporu při ukončení.
Za čtvrté, slabé vazby na aktiva. Registry uvádějí dodavatele, ale neodkazují na aplikace, datové sady, rozhraní API, identity, logy, infrastrukturu nebo obchodní služby. To komplikuje analýzu dopadů při incidentech a selháních dodavatelů.
Za páté, netransparentnost subdodavatelů. Organizace zná hlavního poskytovatele, ale neumí vysvětlit, kteří dílčí zpracovatelé nebo techničtí poskytovatelé službu podporují.
Za šesté, chybějící spouštěče změn. Poskytovatel přidá nového dílčího zpracovatele, změní hostingový region, migruje architekturu nebo upraví podpůrný přístup, ale nikdo neaktualizuje registr ani znovu neposoudí riziko.
Za sedmé, chybějící periodicita důkazů. Není definována četnost přezkumu dodavatelů, přezkumu smluv, ověření aktiv, sladění registru cloudových služeb ani reportování vedení.
Tyto problémy jsou řešitelné, ale pouze pokud má registr vlastníky a pracovní postupy.
Praktický 30denní plán zlepšení
Začněte rozsahem. Identifikujte všechny obchodní funkce, které mohou být podle DORA kritické nebo důležité. Pro každou funkci uveďte IKT služby, na nichž závisí. Nezačínejte výdaji na nákup. Začněte provozní závislostí.
Slaďte hlavní datové zdroje: registr dodavatelů, repozitář smluv, evidenci aktiv a registr cloudových služeb. Tam, kde je to relevantní, doplňte záznamy o zpracovatelích z oblasti ochrany soukromí a závislosti reakce na incidenty. Cílem není dokonalost první den. Cílem je jednotná páteř registru s jasně označenými neznámými položkami.
Klasifikujte dodavatele a služby pomocí kritérií, jako jsou podporovaná funkce, citlivost dat, provozní nahraditelnost, koncentrace, subdodávky, lokality, dopad incidentu, doba obnovy a regulační relevance.
Přezkoumejte smlouvy pro každé kritické nebo důležité ujednání o IKT službách. Ověřte, zda smlouva obsahuje popisy služeb, podmínky subdodávek, lokality, závazky k ochraně údajů, přístup a obnovu, úrovně služeb, podporu při incidentech, práva na audit, spolupráci s orgány, ukončení, účast na školeních a podporu při ukončení.
Namapujte důkazy ISO pro každé kritické ujednání. Propojte je se záznamy aktiv, položkami posouzení rizik, opatřeními SoA, prověrkou dodavatelů, přezkumy monitorování, plány kontinuity, playbooky pro incidenty a důkazy o strategii ukončení.
Přiřaďte periodicitu. Kritičtí poskytovatelé mohou vyžadovat čtvrtletní přezkum, každoroční ujištění, přezkum smlouvy před obnovením a okamžité opakované posouzení při významné změně. Nekritičtí poskytovatelé mohou být přezkoumáváni ročně nebo při spouštěcích událostech.
Použijte tento kontrolní seznam k přeměně registru na provozní proces:
- Určete vlastníka registru DORA a jeho zástupce.
- Propojte každý řádek registru s ID smlouvy a vlastníkem dodavatele.
- Propojte každou kritickou nebo důležitou IKT službu s obchodní funkcí a záznamy aktiv.
- Doplňte pole pro subdodavatele a dílčí zpracovatele, i když jsou zpočátku označena jako neznámá.
- Doplňte stav smluvních ustanovení pro podmínky kritické podle DORA.
- Doplňte odkazy na rizika podle ISO/IEC 27001:2022 a SoA.
- Tam, kde je to relevantní, doplňte roli podle GDPR, osobní údaje a lokality.
- Doplňte periodicitu přezkumu a metadata posledního přezkumu.
- Vytvořte pravidla eskalace pro chybějící ustanovení, neznámé subdodavatele a vysoké riziko koncentrace.
- Reportujte metriky kvality registru vedení.
Právě zde spolu fungují 30kroková implementační metoda Clarysec, soubor politik a Zenith Controls. Zenith Blueprint poskytuje implementační cestu od ošetření rizik a dohledatelnosti SoA v kroku 13 přes evidenci aktiv v kroku 22 až po dodavatelská opatření v kroku 23. Politiky definují, kdo musí registry udržovat, jaké smluvní důkazy a důkazy o aktivech musí existovat a jak se zachycují metadata souladu. Zenith Controls poskytuje kompas cross-compliance pro mapování stejných důkazů napříč očekáváními auditů DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST a COBIT 19.
Proměňte registr v důkazy dříve, než se zeptá orgán dohledu
Pokud je váš registr informací podle DORA stále jen tabulkou odpojenou od smluv, aktiv, dodavatelů, subdodavatelů a důkazů ISO 27001, rok 2026 je čas to napravit.
Začněte tím, že použijete Zenith Blueprint Zenith Blueprint k propojení ošetření rizik, evidence aktiv a řízení dodavatelů. Použijte Zenith Controls Zenith Controls k namapování opatření A.5.9, A.5.19 a A.5.20 přílohy A ISO/IEC 27001:2022 na důkazy cross-compliance. Poté požadavky zaveďte do provozu prostřednictvím politik Clarysec pro dodavatele, aktiva, cloud, právní soulad a monitorování auditu, včetně Bezpečnostní politika dodavatelů a externích poskytovatelů služeb - SME, Politika řízení rizik závislostí na dodavatelích, Bezpečnostní politika dodavatelů a externích poskytovatelů služeb, Politika správy aktiv - SME, Politika správy aktiv, Politika používání cloudových služeb - SME, Politika právního a regulačního souladu a Politika monitorování auditu a souladu - SME.
Nejlepší čas na nápravu kvality registru je před žádostí orgánu, interním auditem, výpadkem dodavatele nebo obnovením smlouvy. Druhý nejlepší čas je nyní. Stáhněte si příslušné politiky Clarysec, namapujte svůj aktuální registr proti výše uvedenému důkaznímu modelu a objednejte si posouzení registru podle DORA, abyste roztříštěná dodavatelská data proměnili v důkazy na úrovni očekávané dohledem.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council


