Mapa důkazů souladu pro Evropskou peněženku digitální identity 2026

Produktový tým ve fintechu je dva týdny před spuštěním onboardingu využívajícího peněženku. Nový proces umožní zákazníkům z EU prokazovat vybrané atributy identity prostřednictvím Evropské peněženky digitální identity namísto ručního nahrávání dokladů totožnosti. CISO oceňuje bezpečnostní přínos. DPO oceňuje příslib minimalizace údajů. Vedoucí útvaru compliance vidí méně nedokončených onboardingových procesů a čistší zákaznickou zkušenost.
Poté auditní výbor položí otázku, která změní atmosféru v místnosti:
„Pokud se regulátor, bankovní partner, auditor zákazníka nebo orgán dohledu zeptá, jak je tato integrace peněženky řízena, jaké důkazy předložíme?“
To je skutečný problém roku 2026.
Evropská peněženka digitální identity, často zkracovaná jako EUDI Wallet, není jen další produktová funkce. U regulovaných digitálních služeb, poskytovatelů platebních služeb, ekosystémů služeb vytvářejících důvěru, rozhraní veřejného sektoru a onboardingových procesů s vysokou úrovní jistoty se stává součástí řetězce ověřování identity organizace. Dotýká se osobních údajů, autentizačních událostí, závislostí na dodavatelích, řízení přístupů, protokolování, kryptografie, hlášení incidentů a odpovědnosti řídicích orgánů.
Chybou je považovat eIDAS2 a EUDI Wallet za samostatnou právní implementaci. Praktická odpověď je jiná: začlenit přijetí peněženky spoléhající se stranou do stejného systému důkazů, který se používá pro ISO/IEC 27001:2022, GDPR, NIS2, DORA, NIST CSF 2.0 a COBIT 2019.
Právě zde je přístup Clarysec nejsilnější. Neděláme z každého nového právního předpisu další tabulku. Mapujeme povinnosti na politiky, opatření, vlastníky, auditní stopy a opakovatelně doložitelné důkazy.
Tento článek ukazuje, jak takovou důkazní páteř vybudovat pomocí Clarysec Zenith Blueprint: 30krokový plán auditora, Zenith Controls: Průvodce napříč rámci souladu a šablon politik Clarysec pro ochranu soukromí, identitu, protokolování, správu a řízení dodavatelů a právní a regulační soulad.
Problém důkazů pro peněženku v roce 2026 je širší než eIDAS2
Většina diskusí o Evropské peněžence digitální identity se zaměřuje na důvěru, interoperabilitu a uživatelskou zkušenost. To je důležité. CISO, manažer compliance, DPO nebo auditor však mají provozněji zaměřenou otázku: která opatření prokazují, že atributy identity odvozené z peněženky se používají bezpečně, zákonně a přiměřeně?
Spoléhající se strana, která přijímá identitní tvrzení z peněženky, musí být schopna odpovědět:
- Které atributy peněženky požadujeme a proč?
- Jaký právní základ zpracování podporuje?
- Jsou uživatelé, správci a servisní účty jednoznačně identifikovatelní?
- Jsou služby ověřování peněženky, zprostředkovatelé identity, API brány a cloudové komponenty zahrnuty v registru dodavatelů?
- Jsou autentizační a ověřovací události protokolovány způsobem, který podporuje vyšetřování, aniž by docházelo k nadměrnému sběru osobních údajů?
- Existuje proces pro řešení incidentu, pokud je onboarding přes peněženku zneužit, nedostupný nebo kompromitovaný?
- U finančních subjektů: je integrace peněženky zahrnuta do řízení rizik ICT podle DORA, řízení rizik třetích stran a klasifikace incidentů?
- U subjektů NIS2: ovlivňuje spoléhání se na peněženku poskytování základních nebo důležitých služeb, řízení přístupu, kontinuitu činností nebo komunikaci se zákazníky?
NIS2 je obzvlášť relevantní, protože její rozsah zahrnuje mnoho poskytovatelů digitální infrastruktury, cloudové služby, poskytovatele řízených služeb, poskytovatele řízených bezpečnostních služeb a poskytovatele služeb vytvářejících důvěru. Směrnice také za určitých okolností klasifikuje kvalifikované poskytovatele služeb vytvářejících důvěru, poskytovatele DNS, registry TLD a několik dalších subjektů jako základní. V roce 2026 se mnoho organizací již nebude ptát, zda právní úprava přichází. Budou odpovídat na otázky orgánů dohledu, zákazníků a interního auditu ohledně implementace.
U finančních služeb přidává DORA další vrstvu. Použije se od 17. ledna 2025 a zavádí jednotný rámec pro rizika ICT, incidenty, testování a rizika třetích stran u finančních subjektů. NIS2 uznává DORA jako odvětvový právní akt Unie pro mnoho překrývajících se povinností v oblasti kybernetické bezpečnosti ve finančním sektoru. V praxi to znamená, že onboardingová funkce založená na peněžence u platební instituce, poskytovatele služeb souvisejících s kryptoaktivy, investiční společnosti nebo poskytovatele služeb informování o účtu musí být doložena prostřednictvím řízení rizik ICT ve stylu DORA, i když NIS2 zůstává důležitá pro koordinaci a závislosti v ekosystému.
Nesprávnou reakcí je vytvořit jeden balíček důkazů pro eIDAS2, jeden pro GDPR, jeden pro NIS2, jeden pro DORA a jeden pro certifikaci ISO. Správnou reakcí je použít ISMS jako provozní model pro důkazy.
Použijte ISO 27001 jako důkazní páteř
ISO/IEC 27001:2022 je užitečná, protože se neomezuje na technologický kontrolní seznam. Vyžaduje, aby organizace definovaly kontext, zainteresované strany, právní a smluvní povinnosti, rozsah, rozhraní, závislosti, odpovědnosti vedení, posouzení rizik, ošetření rizik, Prohlášení o použitelnosti a neustálé zlepšování.
To je u přijetí peněženky důležité, protože riziko nespočívá jen ve volání API. Riziko je v celém koncovém obchodním procesu.
Implementace peněženky spoléhající se stranou ovlivňuje:
- onboarding zákazníků a přístup k účtům;
- oznámení o ochraně soukromí, záznamy RoPA a záznamy právního základu;
- modely ověřování identity a autentizace;
- dodavatelské smlouvy a ujištění;
- protokolování, monitorování a uchování důkazů;
- klasifikaci a hlášení incidentů;
- uchovávání, mazání a opravy údajů;
- monitorování auditu a souladu;
- vykazování rizik na úrovni řídicích orgánů.
Podniková politika souladu Clarysec tento provozní model jasně stanoví:
„Všechny právní a regulační povinnosti musí být namapovány na konkrétní politiky, opatření a vlastníky v rámci Systému řízení bezpečnosti informací (ISMS).“
Z Politika právního a regulačního souladu, sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.2.1.
U malých a středních podniků (SME) je stejný princip převeden do praktického registru souladu:
„Pokud se právní předpis uplatní napříč více oblastmi (např. GDPR se vztahuje na uchovávání, bezpečnost a ochranu soukromí), musí být tato vazba jasně uvedena v registru souladu a školicích materiálech.“
Z Politika právního a regulačního souladu - SME, sekce „Požadavky na správu a řízení“, ustanovení politiky 5.2.2.
Organizace by se neměla ptát: „Které oddělení vlastní eIDAS2?“ Měla by se ptát: „Která rizika ISMS, opatření, politiky, vlastníci a důkazní záznamy jsou ovlivněny spoléháním se na peněženku?“
V Zenith Blueprint, ve fázi Řízení rizik, krok 14, se uvádí:
„Pro každý právní předpis, pokud je použitelný, můžete vytvořit jednoduchou mapovací tabulku (například jako přílohu zprávy), která uvádí klíčové bezpečnostní požadavky daného předpisu a odpovídající opatření/politiky ve vašem ISMS. V ISO 27001 to není povinné, ale je to užitečné interní cvičení, které pomáhá zajistit, že nic nepropadlo mezi procesy. Zároveň to působí dobře na auditory/hodnotitele, protože ukazuje, že bezpečnost neřídíte izolovaně, ale vnímáte právní kontext.“
To je základ: vytvořte jednu mapovací tabulku, která propojí povinnosti spoléhající se strany u peněženky s GDPR, NIS2, DORA, opatřeními přílohy A ISO/IEC 27001:2022, politikami Clarysec a důkazními záznamy.
Praktická mapa důkazů pro spoléhající se strany u Evropské peněženky digitální identity
EUDI Wallet je řiditelná, pokud je v ISMS chápána jako definovaný obchodní proces s namapovanými daty, identitami, dodavateli, logy, incidenty a vlastníky.
| Otázka k důkazům pro peněženku | Primární oblast opatření ISMS | Důkazy pro GDPR | Důkazy pro NIS2 nebo DORA | Důkazy ze sady nástrojů Clarysec |
|---|---|---|---|---|
| Které atributy z peněženky požadujeme? | Ochrana soukromí a PII, klasifikace informací, právní registr | Minimalizace údajů, právní základ, omezení účelu, uchovávání | Důvěrnost dat a řízení rizik ICT podle DORA, pokud se uplatní finanční služby | Politika ochrany dat a soukromí, Politika právního a regulačního souladu, registr souladu |
| Jak víme, že identity jsou jedinečné a dohledatelné? | Správa identit, přístupová práva, privilegovaný přístup | Odpovědnost a zabezpečení zpracování | NIS2 Article 21(2)(i) řízení přístupu a správa aktiv, správa přístupu podle DORA | Politika správy uživatelských účtů a oprávnění, důkazy životního cyklu IAM |
| Jak je chráněna autentizace peněženky? | Bezpečná autentizace, autentizační informace, monitorování | Řízení přístupů, bezpečnost již od návrhu, prevence porušení zabezpečení | NIS2 Article 21(2)(j) MFA nebo průběžná autentizace, kde je to vhodné, ochrana ICT podle DORA | Konfigurace autentizace, pokrytí MFA, řízení relací, logy |
| Kteří dodavatelé podporují ověřování nebo onboarding? | Vztahy s dodavateli, dodavatelské smlouvy, cloudové služby | Analýza role zpracovatele nebo správce, smlouvy o zpracování osobních údajů | Zabezpečení dodavatelského řetězce podle NIS2, registr třetích stran ICT a exit strategie podle DORA | Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran, prověrka dodavatelů, smluvní doložky |
| Co se protokoluje a uchovává? | Protokolování, monitorování, sběr důkazů | Odpovědnost, detekce porušení zabezpečení, přiměřené uchovávání | Zvládání incidentů podle NIS2, klasifikace a hlášení incidentů podle DORA | Politika protokolování a monitorování, neměnné logy, postupy reakce na incidenty |
| Co se stane, pokud onboarding přes peněženku selže nebo je zneužit? | Reakce na incidenty, kontinuita činností, připravenost ICT | Posouzení porušení zabezpečení osobních údajů, pokud je použitelné | 24hodinové a 72hodinové hlášení podle NIS2, počáteční, průběžné a závěrečné zprávy podle DORA | Scénář reakce na incident, sběr důkazů, přezkoumání po incidentu |
Tato tabulka není právním stanoviskem. Je to model opatření a důkazů, který mohou CISO, týmy compliance a auditoři použít ke strukturování důkazů.
Správa identit je místo, kde auditoři začnou
U spoléhající se strany u peněženky je identita zřejmou rodinou opatření. Správa identit však není totéž co autentizace. Správa identit odpovídá na otázku „kdo v systému existuje a jak je tato identita řízena?“ Autentizace odpovídá na otázku „jak se v okamžiku přístupu ověřuje nárokovaná identita?“
V Zenith Controls je opatření ISO/IEC 27002:2022 5.16, Správa identit, chápáno jako preventivní opatření podporující důvěrnost, integritu a dostupnost. Přímo se váže na řízení přístupu, autentizační informace, přístupová práva, vztahy s dodavateli, monitorování souladu a privilegovaný přístup. Mapování napříč rámci souladu propojuje tuto oblast se zabezpečením a odpovědností podle GDPR, řízením přístupu a správou aktiv podle NIS2, správou identit a přístupů podle DORA, správou identifikátorů podle NIST SP 800-53 a řízením životního cyklu identit podle COBIT 2019.
U důkazů pro peněženku musí být organizace schopna doložit, že:
- identity zákazníků a pracovníků nejsou zaměňovány;
- administrátorské identity jsou jedinečné a dohledatelné;
- identity dodavatelů jsou řízeny se stejnou disciplínou jako identity zaměstnanců;
- nelidské identity, jako jsou klienti API a servisní účty, mají vlastníky;
- identity jsou odebrány, jakmile již nejsou potřeba;
- výjimky, účty nouzového přístupu „break-glass“ a privilegované identity jsou řízeny.
Politika účtů Clarysec pro SME vyjadřuje princip srozumitelně:
„Každý účet musí být jedinečný, dohledatelný ke konkrétní osobě a propojený s obchodní rolí.“
Z Politika správy uživatelských účtů a oprávnění - SME, sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.1.2.
U podnikových prostředí je požadavek na sdílené účty přísnější:
„Všechny uživatelské identity musí být spojeny s jedinečným identifikátorem. Používání sdílených nebo generických účtů je zakázáno, s výjimkou schválených nouzových účtů typu „break-glass“ nebo nouzových účtů podléhajících přísným kontrolám.“
Z Politika správy uživatelských účtů a oprávnění, sekce „Požadavky na správu a řízení“, ustanovení politiky 5.3.
Podpůrné normy posilují stejnou důkazní logiku. ISO/IEC 24760-1:2019 poskytuje koncepty životního cyklu identity, jako je registrace, vazba, použití a zrušení registrace. ISO/IEC 29115:2013 podporuje ujištění identity založené na rizicích. ISO/IEC 27005:2024 považuje slabiny v oblasti identity a přístupu za témata ošetření rizik. ISO/IEC 27018:2020 rozšiřuje očekávání správy identit pro zpracování PII ve veřejném cloudu. ISO/IEC 29100:2011 doplňuje pohled ochrany soukromí propojením identifikovatelnosti s nakládáním s osobními informacemi.
U přijetí EUDI Wallet je auditní otázka jednoduchá: dokážete přiřadit každou privilegovanou akci, změnu konfigurace, změnu integrace ověřování peněženky a událost přístupu dodavatele k jedinečné identitě se schválenou rolí?
Pokud odpověď zní ne, projekt peněženky není připraven na audit.
Bezpečná autentizace: důvěra v peněženku neruší vaše povinnosti v oblasti opatření
Častým omylem je představa, že ověření identity založené na peněžence ruší autentizační povinnosti spoléhající se strany. Může zvýšit úroveň jistoty u konkrétních atributů identity, ale neruší povinnost zabezpečit systémy, relace, rozhraní API, administrátorská rozhraní a zákaznické procesy.
V Zenith Blueprint, ve fázi Opatření v praxi, krok 19, Clarysec uvádí:
„Autentizace je první a nejkritičtější obrannou linií mezi aktérem hrozby a vašimi systémy, daty a službami. Pokud je autentizace slabá, vše ostatní — šifrování, monitorování, segmentace — lze obejít.“
Stejný krok vysvětluje, že moderní autentizace musí být založena na rizicích, silnější u cílů s vyšší hodnotou a podporovaná MFA, bezpečným ukládáním přihlašovacích údajů, TLS, ochranou tokenů, nástroji pro správu tajemství, bezpečným řízením relací a přezkumem autentizačních logů.
V Zenith Controls je opatření ISO/IEC 27002:2022 8.5, Bezpečná autentizace, namapováno jako preventivní opatření v rámci schopnosti řízení identit a přístupů. Váže se na správu identit, autentizační informace, privilegovaný přístup, omezení přístupu k informacím, monitorovací činnosti, řízení incidentů a ochranu soukromí PII. Zároveň se mapuje na zabezpečení a ochranu údajů již od návrhu podle GDPR, řízení rizik kybernetické bezpečnosti a MFA nebo průběžnou autentizaci podle NIS2, kde je to vhodné, správu rizik ICT podle DORA, rodiny IA a AC podle NIST SP 800-53 a správu logického přístupu podle COBIT 2019.
U spoléhající se strany u peněženky musí důkazy bezpečné autentizace zahrnovat:
- autentizaci a autorizaci koncového bodu pro ověřování peněženky;
- MFA administrátorů pro konfigurační panely peněženky;
- bezpečnou autentizaci API mezi onboardingovými službami;
- ukládání tajných údajů do trezoru pro integrační klíče nebo certifikáty peněženky;
- časové limity relací a ochranu tokenů, kde je to vhodné;
- upozornění na neúspěšnou autentizaci a ochranu proti pokusům hrubou silou;
- samostatná opatření pro přihlášení zákazníků, přístup zaměstnanců a přístup mezi stroji.
Politika protokolování Clarysec pro SME poskytuje praktický důkazní požadavek:
„Autentizační logy: úspěšné a neúspěšné pokusy o přihlášení, doba trvání relace, používání MFA“
Z Politika protokolování a monitorování - SME, sekce „Požadavky na správu a řízení“, ustanovení politiky 5.4.2.
U podnikových prostředí je klíčová auditní spolehlivost:
„Log soubory musí být neměnné nebo vedené v režimu správy verzí, s přístupem uděleným pouze autorizovanému personálu.“
Z Politika protokolování a monitorování, sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.5.1.
Toto je most mezi ujištěním identity a reakcí na incidenty. Pokud je onboarding přes peněženku napaden prostřednictvím credential stuffing, opakovaného použití tokenu, kompromitace administrátora nebo zneužití dodavatelem, autentizační logy se stávají důkazní stopou.
GDPR: příslib peněženky je minimalizace, ale musíte ji doložit
Evropská peněženka digitální identity může podpořit onboarding šetrný k soukromí, protože spoléhající se strana může požadovat konkrétní atributy namísto shromažďování celých dokladů totožnosti. Odpovědnost podle GDPR však nestojí na dobrých úmyslech. Vyžaduje prokazatelný soulad.
Atributy odvozené z peněženky jsou osobní údaje, pokud se týkají identifikované nebo identifikovatelné osoby. Některé případy použití se mohou dotýkat také biometrických údajů, údajů o ověření identity, screeningu sankcí, rizika podvodu nebo jiných citlivých kontextů zpracování.
Zásady GDPR vyžadují zákonné, korektní a transparentní zpracování, stanovené účely, minimalizaci údajů, přesnost, omezení uložení, integritu a důvěrnost a také odpovědnost. Spoléhající se strana musí být schopna prokázat, proč je každý atribut peněženky požadován, jak dlouho je uchováván, kdo k němu má přístup, jak je chráněn a jak je řízeno opětovné použití.
Podniková politika ochrany soukromí Clarysec uvádí:
„Shromažďovány a zpracovávány mohou být pouze údaje nezbytné pro konkrétní legitimní obchodní účel.“
Z Politika ochrany dat a soukromí, sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.2.1.
Verze pro SME je záměrně stručná:
„Shromažďovány a uchovávány musí být pouze minimální nezbytné osobní údaje“
Z Politika ochrany dat a soukromí - SME, sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.2.1.
V Zenith Controls je opatření ISO/IEC 27002:2022 5.34, Ochrana soukromí a ochrana PII, namapováno na evidenci aktiv, maskování dat, správu a řízení cloudových služeb, klasifikaci informací, bezpečný přenos, řízení přístupu, správu identit a přezkum změn projektů. Propojuje se také s ISO/IEC 27701:2021 pro řízení ochrany soukromí, ISO/IEC 27018 pro zpracování PII v cloudu a zásadami ochrany soukromí ISO/IEC 29100.
U přijetí peněženky musí balíček důkazů k ochraně soukromí obsahovat:
- diagram toku dat pro atributy peněženky;
- záznam v registru právních základů;
- záznam rozhodnutí o minimalizaci atributů;
- harmonogram uchovávání údajů odvozených z peněženky;
- aktualizaci oznámení o ochraně soukromí;
- DPIA nebo posouzení rizik ochrany soukromí, pokud je případ použití vysoce rizikový;
- matici řízení přístupu k datům z peněženky;
- proces mazání a opravy údajů;
- důkazy z monitorování ukazující, že přístup k PII odvozeným z peněženky je řízen.
Mnoho organizací shromažďuje příliš mnoho údajů, protože peněženka usnadňuje získání ověřených dat. To je opačný směr. Bezpečnostní přínos a přínos pro ochranu soukromí vzniká tím, že se požaduje méně, nikoli tím, že se ukládá více ověřených identitních dat, než podnik potřebuje.
NIS2 a DORA: odpovědnost řídicích orgánů se potkává s odolností peněženky
NIS2 i DORA posouvají kybernetickou bezpečnost do oblasti správy a řízení. Vyžadují, aby řídicí orgány schvalovaly riziková opatření, dohlížely na ně a nesly za ně odpovědnost. Zároveň očekávají přiměřená technická, provozní a organizační opatření.
NIS2 Article 21 vyžaduje opatření řízení rizik zahrnující politiky, zvládání incidentů, kontinuitu činností, zabezpečení dodavatelského řetězce, bezpečné pořizování a vývoj, řešení zranitelností, účinnost kontrol, kybernetickou hygienu, školení, kryptografii, bezpečnost HR, řízení přístupu, správu aktiv a tam, kde je to vhodné, MFA nebo průběžnou autentizaci. U spoléhajících se stran u peněženky v sektorech NIS2 musí být integrace peněženky uvedena v posouzení rizik, evidenci aktiv, registru dodavatelů, plánu zvládání incidentů a rámci řízení přístupu.
NIS2 Article 23 doplňuje postupné hlášení významných incidentů. Základní a důležité subjekty musí poskytnout včasné varování do 24 hodin, oznámení do 72 hodin a závěrečnou zprávu do jednoho měsíce, případně také komunikaci s příjemci. Pokud by selhání integrace peněženky mohlo způsobit provozní narušení, finanční ztrátu nebo hmotnou či nehmotnou újmu příjemcům služby, musí být zahrnuto do logiky klasifikace incidentů.
DORA je pro finanční subjekty konkrétnější. Vyžaduje interní rámec správy a řízení a kontrol pro rizika ICT, strategii odolnosti schválenou řídicím orgánem, politiky ICT, plány kontinuity činností a reakce, plány auditů, politiky třetích stran, kanály pro hlášení incidentů a dokumentovaný rámec řízení rizik ICT. Vyžaduje také řízení incidentů souvisejících s ICT, klasifikaci podle kritérií, jako jsou dotčení klienti, nedostupnost, geografický rozsah, ztráta dat, kritičnost a ekonomický dopad, a hlášení závažných incidentů souvisejících s ICT.
U onboardingu založeného na peněžence ve finančních službách musí důkazy ukazovat, že:
- integrace peněženky je uvedena v evidenci ICT aktiv a procesů;
- rizika jsou posouzena a akceptována příslušným vlastníkem;
- je posouzena kritičnost pro onboarding zákazníků nebo přístup k účtu;
- existují možnosti odolnosti a záložní režim;
- incidenty lze klasifikovat podle kritérií DORA;
- jsou naplánována oznámení klientům, pokud jsou ovlivněny finanční zájmy;
- outsourcované hlášení, pokud je využito, neodstraňuje odpovědnost.
Klíčem je přiměřenost. Malý fintech a velká banka nevytvoří stejný objem důkazů, ale oba potřebují dohledatelnou správu a řízení.
Závislosti na dodavatelích a cloudu: váš proces s peněženkou je jen tak silný jako celý řetězec
Většina implementací peněženky spoléhající se stranou zahrnuje externí služby: cloud hosting, API brány, ověřovací knihovny, zprostředkovatele identity, dodavatele KYC, antifraud enginy, platformy pro protokolování, poskytovatele řízené detekce a reakce nebo nástroje zákaznické podpory. Proto je správa a řízení dodavatelů klíčová.
NIS2 vyžaduje, aby subjekty zohledňovaly zranitelnosti specifické pro dodavatele a celkovou kvalitu a kybernetické postupy dodavatelů a poskytovatelů služeb. DORA jde u finančních subjektů dále a vyžaduje registr smluvních ujednání o službách ICT, posouzení před uzavřením smlouvy, analýzu rizika koncentrace, náležitou péči, přístupy k auditům a inspekcím, práva na ukončení a otestované exit strategie pro služby ICT podporující kritické nebo důležité funkce.
V Zenith Blueprint, ve fázi Opatření v praxi, krok 23, Clarysec instruuje týmy, aby sestavily úplný seznam dodavatelů, klasifikovaly poskytovatele podle přístupu k systémům, datům nebo provoznímu řízení, zakotvily očekávání ve smlouvách, identifikovaly subdodavatele, definovaly spouštěče změn a vybudovaly proces hodnocení cloudových služeb. Stejný krok doporučuje před schválením budoucích cloudových služeb hodnotit umístění dat, přístupový model, protokolování a šifrování.
Dodavatelská politika Clarysec pro SME stanoví jasné pravidlo minimálního přístupu:
„Dodavatelům musí být udělen přístup pouze k minimálním systémům a datům nezbytným k výkonu jejich funkce.“
Z Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran - SME, sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.2.1.
NIST CSF 2.0 podporuje tento integrovaný pohled. Jeho funkce GOVERN zahrnuje právní, regulační, smluvní povinnosti a povinnosti v oblasti ochrany soukromí, ochotu podstupovat riziko, odpovědnost, politiku, zajištění zdrojů a dohled. Výstupy pro dodavatelský řetězec požadují role dodavatelů, prioritizaci kritičnosti, smluvní požadavky na kybernetickou bezpečnost, náležitou péči, monitorování, plánování incidentů a ustanovení po ukončení vztahu.
Auditoři COBIT 2019 budou sledovat vyspělost správy a řízení. Budou se ptát, zda jsou odpovědnosti dodavatelů, životní cyklus identit, opatření ochrany soukromí a monitorování začleněny do obchodních procesů, nejen do kontrolních seznamů bezpečnostního týmu. Pro identitu a logický přístup je při posuzování, zda jsou vlastnictví účtů, schvalování, přidělování oprávnění a odebrání přístupů řízeny, zvlášť relevantní COBIT 2019 DSS05.04, řízení uživatelské identity a logického přístupu.
Sestavte balíček důkazů spoléhající se strany u peněženky během jednoho odpoledne
Praktické cvičení ve stylu Clarysec začíná jedním konkrétním případem použití, nikoli širokým programovým prohlášením. Jako první záznam použijte „onboarding zákazníka pomocí zákonného jména, data narození a adresy poskytnutých peněženkou“. Přidejte vlastníka obchodního procesu, vlastníka systému, vlastníka dat a vlastníka rizika.
Zaznamenejte:
- účel zpracování;
- požadované atributy peněženky;
- zda jsou atributy ukládány, ukládány do mezipaměti, nebo pouze ověřovány;
- zapojené systémy a rozhraní API;
- dodavatele a dílčí zpracovatele;
- dotčené země nebo cloudové regiony;
- záložní proces pro případ selhání ověření peněženky;
- kontaktní body komunikace se zákazníkem.
Poté případ použití přidejte do registru souladu.
| Oblast požadavků | Výklad specifický pro peněženku | Vlastník | Důkazy |
|---|---|---|---|
| Minimalizace údajů podle GDPR | Požadovat pouze zákonné jméno, datum narození a adresu, protože jsou nezbytné pro onboarding | DPO | DPIA, registr právních základů, rozhodnutí o minimalizaci atributů |
| Správa identit | Administrátorský a podpůrný přístup k záznamům onboardingu přes peněženku musí být jedinečný a založený na rolích | Vlastník IAM | Export IAM, přezkum přístupových práv, záznamy o nástupech, přesunech a odchodech |
| Bezpečná autentizace | Administrátorské konzole a rozhraní API musí používat MFA nebo silnou strojovou autentizaci | Bezpečnostní inženýrství | Report MFA, evidence přihlašovacích údajů API, důkazy z trezoru tajných údajů |
| Správa a řízení dodavatelů | Poskytovatelé ověřování a cloudu musí být posouzeni a smluvně řízeni | Nákup a CISO | Posouzení dodavatele, smlouva o zpracování osobních údajů, bezpečnostní příloha, exit plán |
| Reakce na incidenty | Zneužití nebo výpadek onboardingu přes peněženku musí být klasifikovatelný a podléhat hlášení | Manažer incidentů | Scénář reakce na incident, matice hlášení NIS2 nebo DORA, záznam stolního cvičení |
Dále přezkoumejte Prohlášení o použitelnosti a Plán ošetření rizik. Pro případy použití EUDI Wallet jsou běžně relevantní následující oblasti opatření ISO/IEC 27002:2022.
| Opatření ISO/IEC 27002:2022 | Název opatření | Relevance důkazů pro peněženku |
|---|---|---|
| 5.16 | Správa identit | Jedinečné identity, vlastnictví účtů, životní cyklus nástupů, přesunů a odchodů a správa nelidských identit |
| 8.5 | Bezpečná autentizace | MFA, autentizace API, bezpečné relace, ochrana přihlašovacích údajů a autentizační logy |
| 5.34 | Ochrana soukromí a ochrana PII | Minimalizace atributů, zákonné zpracování, posouzení rizik ochrany soukromí a přístup k PII odvozeným z peněženky |
| 5.19 | Bezpečnost informací ve vztazích s dodavateli | Klasifikace dodavatelů, náležitá péče a odpovědnosti dodavatelů v oblasti bezpečnosti |
| 5.20 | Řešení bezpečnosti informací ve smlouvách s dodavateli | Smluvní bezpečnostní, soukromí, auditní, incidentní a ukončovací doložky |
| 5.21 | Řízení bezpečnosti informací v dodavatelském řetězci ICT | Riziko dodavatelského řetězce, subdodavatelé, integrační závislosti a zranitelnosti dodavatelů |
| 5.23 | Bezpečnost informací při používání cloudových služeb | Schvalování cloudu, umístění dat, šifrování, protokolování a přístupový model |
| 8.15 | Protokolování | Autentizační, ověřovací, administrativní a incidentně relevantní události |
| 8.16 | Monitorovací činnosti | Upozorňování, detekce, přezkum a eskalace podezřelé aktivity |
| 5.24 | Plánování a příprava řízení incidentů bezpečnosti informací | Postupy reakce na incidenty související s peněženkou, role, komunikační trasy a kritéria eskalace |
| 5.25 | Posouzení a rozhodnutí o událostech bezpečnosti informací | Triáž a klasifikace událostí souvisejících s peněženkou |
| 5.26 | Reakce na incidenty bezpečnosti informací | Zamezení šíření, eradikace, obnova a komunikace |
| 5.28 | Sběr důkazů | Uchování logů, záznamů z vyšetřování a řetězce předání důkazů |
| 5.31 | Právní, zákonné, regulační a smluvní požadavky | Mapování eIDAS2, GDPR, NIS2, DORA a smluvních povinností |
| 5.36 | Soulad s politikami, pravidly a normami pro bezpečnost informací | Interní testování opatření, výjimky a monitorování souladu |
Nakonec proveďte mini-audit. Vyberte jednu onboardingovou transakci přes peněženku a vysledujte:
- odůvodnění požadavku na atribut;
- krok transparentnosti nebo záznam souhlasu, je-li použitelný;
- log systémové události;
- důkaz autentizace API;
- záznam řízení přístupu pro pracovníky zobrazující výsledek onboardingu;
- zapojeného dodavatele;
- pravidlo uchovávání;
- cestu klasifikace incidentu, pokud by daná transakce byla podvodná nebo zpřístupněná.
Pokud cestu nedokážete vysledovat, proces ještě není důkazně připravený.
Jak různí auditoři otestují stejný proces s peněženkou
Různí auditoři přistupují k Evropské peněžence digitální identity různou profesní optikou. Stejné důkazy mohou uspokojit více otázek, pokud jsou dobře strukturovány.
| Profil auditora | Pravděpodobné zaměření auditu | Důkazy, které si vyžádá |
|---|---|---|
| Auditor ISO/IEC 27001:2022 | Rozsah, zainteresované strany, rizika, opatření SoA, účinnost kontrol a dokumentované důkazy | Rozsah ISMS, posouzení rizik, SoA, politiky, přezkum přístupových práv, logy, záznamy dodavatelů |
| Auditor ISO/IEC 27007 nebo ISO/IEC 19011 | Auditní stopa, vzorkování, rozhovory, konzistence mezi politikou a implementací | Vzorky životního cyklu uživatelů, konfigurace autentizace, záznamy incidentů, rozhovory se zaměstnanci |
| Hodnotitel orientovaný na NIST | Správa a řízení, rizikové profily, dodavatelský řetězec, výstupy detekce, reakce a obnovy | Současný a cílový profil, POA&M, kritičnost dodavatelů, důkazy monitorování a reakce |
| Auditor COBIT 2019 | Cíle správy a řízení, vlastnictví procesů, vyspělost a manažerské postupy | RACI, procesní KPI, reporting řídicím orgánům, správa a řízení dodavatelů, záznamy programu ochrany soukromí |
| Auditor ISACA ITAF | Spolehlivost důkazů, testování kontrol, dohledatelnost a dostatečnost | Neměnné logy, vzorkované transakce, důkazy přístupu, schválení výjimek |
| Orgán dohledu DORA nebo interní přezkoumávající osoba | Rámec rizik ICT, životní cyklus incidentů, registr třetích stran a provozní odolnost | Registr rizik ICT, klasifikace incidentů, registr třetích stran, exit strategie, testy odolnosti |
| Přezkoumávající osoba GDPR | Právní základ, minimalizace, transparentnost, zabezpečení PII a odpovědnost | Záznam RoPA, DPIA, oznámení o ochraně soukromí, pravidlo uchovávání, logy přístupu, posouzení porušení zabezpečení |
Zenith Controls poskytuje pro tyto oblasti užitečné detaily auditní metodiky. U správy identit auditoři běžně sledují uživatelské identity napříč onboardingem, změnami a ukončením, porovnávají HR záznamy se seznamy účtů, kontrolují účty osob mimo zaměstnanecký poměr a servisní účty a hledají používání sdílených administrátorských účtů. U bezpečné autentizace auditoři porovnávají politiky s technickými konfiguracemi, přezkoumávají pokrytí MFA, kontrolují hesla a řízení relací a prověřují logy úspěšných a neúspěšných přihlášení. U ochrany soukromí a PII auditoři vzorkují DPIA, procesy žádostí subjektů údajů, školení ochrany soukromí, inventáře PII, šifrování, logy přístupu a kontroly uchovávání.
Clarysec Politika monitorování auditu a souladu vysvětluje cíl důkazů jasně:
„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í zajištění.“
Z Politika monitorování auditu a souladu, sekce „Cíle“, ustanovení politiky 3.4.
Právě výraz obhajitelné důkazy odlišuje knihovnu politik od systému souladu připraveného na audit.
Časté chyby v projektech připravenosti na peněženku
První chybou je sběr příliš velkého množství údajů. Peněženky mohou usnadnit získávání ověřených atributů, ale GDPR tlačí opačným směrem: shromažďovat a uchovávat pouze to, co je nezbytné. Pokud produktový tým požaduje úplné identifikační informace, když stačí pouze potvrzení věku, návrh opatření ochrany soukromí je od začátku chybný.
Druhou chybou je ignorování nelidských identit. Integrace peněženky často spoléhají na klienty API, certifikáty, servisní účty, automatizační skripty a tajné údaje. Pokud tyto identity nemají vlastníky, nejsou rotovány, monitorovány a vyřazovány, prostředí spoléhající se strany je slabé, i když je ekosystém peněženky silný.
Třetí chybou je zacházet s dodavateli jako s nákupní administrativou. Podle NIS2 a DORA je bezpečnost dodavatelů provozní otázkou. Potřebujete náležitou péči, smluvní doložky, monitorování, spolupráci při incidentech, práva na audit a exit plány. U subjektů regulovaných DORA je registr třetích stran ICT klíčovým důkazem souladu.
Čtvrtou chybou je protokolování bez správy a řízení. Nadměrné protokolování může vytvářet riziko pro soukromí. Nedostatečné protokolování ničí schopnost vyšetřování. Definujte autentizační, ověřovací, administrativní a incidentně relevantní události, chraňte logy před změnou, omezte přístup a slaďte uchovávání s právními a obchodními potřebami.
Pátou chybou je neprocvičit hlášení. NIS2 má pro významné incidenty očekávání hlášení do 24 hodin, 72 hodin a jednoho měsíce. DORA má u závažných incidentů souvisejících s ICT počáteční, průběžné a závěrečné hlášení. Pokud organizace poprvé mapuje incident související s peněženkou na tyto lhůty až během skutečné události, správa a řízení selhaly.
Proměňte přijetí EUDI Wallet v důkazy připravené na audit
Evropská peněženka digitální identity změní onboarding a digitální důvěru v celé Evropě. Pro CISO, DPO, manažery compliance, auditory a vlastníky společností však vítězným krokem není vytvořit další izolovaný program souladu. Vítězným krokem je začlenit přijetí peněženky do ISMS a namapovat je napříč ochranou soukromí, identitou, autentizací, dodavateli, protokolováním, odolností a reakcí na incidenty.
Clarysec vám s tím může strukturovaně pomoci:
- Použijte Zenith Blueprint k zařazení přijetí peněženky do fáze Řízení rizik, krok 14 pro regulační křížové odkazy, krok 19 pro bezpečnou autentizaci a krok 23 pro implementaci opatření pro dodavatele, ochranu soukromí a právní požadavky.
- Použijte Zenith Controls k mapování správy identit, bezpečné autentizace a opatření ochrany soukromí podle ISO/IEC 27002:2022 na důkazy pro GDPR, NIS2, DORA, NIST a COBIT 2019.
- Použijte šablony politik Clarysec, jako jsou Politika právního a regulačního souladu, Politika ochrany dat a soukromí, Politika správy uživatelských účtů a oprávnění, Politika protokolování a monitorování, Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran - SME a Politika monitorování auditu a souladu k převodu povinností na vlastněné a testovatelné postupy.
- Sestavte balíček důkazů spoléhající se strany u peněženky před spuštěním, nikoli až po první žádosti auditora.
Pokud vaše organizace plánuje v roce 2026 spoléhat na Evropskou peněženku digitální identity, nyní je čas položit si jednu otázku: dokážeme obhajitelnými důkazy prokázat, že tento identitní proces je bezpečný, zákonný, odolný a řízený?
Odpověď Clarysec je praktická: namapujte jej, přiřaďte vlastnictví, otestujte jej a mějte důkazy připravené.
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


