Mapa dowodów zgodności dla EU Digital Identity Wallet 2026

Zespół produktowy fintechu jest dwa tygodnie przed uruchomieniem onboardingu opartego na portfelu. Nowy proces pozwoli klientom z UE potwierdzać wybrane atrybuty tożsamości za pomocą EU Digital Identity Wallet zamiast ręcznego przesyłania dokumentów tożsamości. CISO widzi korzyści bezpieczeństwa. Inspektor ochrony danych (IOD) docenia możliwość minimalizacji danych. Osoba odpowiedzialna za zgodność widzi mniej porzuconych procesów onboardingu i lepsze doświadczenie klienta.

Wtedy komitet audytu zadaje pytanie, które zmienia przebieg rozmowy:

„Jeżeli regulator, partner bankowy, audytor klienta lub organ nadzorczy zapyta, jak zarządzamy tą integracją z portfelem, jakie dowody pokażemy?”

To jest rzeczywisty problem roku 2026.

EU Digital Identity Wallet, często skracany do EUDI Wallet, nie jest tylko kolejną funkcją produktu. Dla regulowanych usług cyfrowych, dostawców płatności, ekosystemów usług zaufania, interfejsów sektora publicznego oraz procesów onboardingu wymagających wysokiego poziomu zapewnienia staje się częścią organizacyjnego łańcucha zapewnienia tożsamości. Obejmuje dane osobowe, zdarzenia uwierzytelniania, zależności od dostawców, nadzór nad dostępem, logowanie, kryptografię, zgłaszanie incydentów oraz rozliczalność kierownictwa.

Pułapką jest traktowanie eIDAS2 i EUDI Wallet jako odrębnego wdrożenia prawnego. Praktyczna odpowiedź jest inna: wdrożenie strony ufającej portfelowi należy włączyć do tego samego systemu dowodowego, który jest wykorzystywany dla ISO/IEC 27001:2022, GDPR, NIS2, DORA, NIST CSF 2.0 i COBIT 2019.

W tym miejscu podejście Clarysec jest szczególnie skuteczne. Nie zamieniamy każdej nowej regulacji w kolejny arkusz kalkulacyjny. Mapujemy obowiązki na polityki, środki kontrolne, właścicieli, ścieżki audytowe i powtarzalne dowody.

Ten artykuł pokazuje, jak zbudować taki kręgosłup dowodowy z wykorzystaniem Zenith Blueprint: 30-etapowa mapa drogowa audytora, Zenith Controls: przewodnik zgodności przekrojowej oraz szablonów polityk Clarysec dotyczących prywatności, tożsamości, logowania, nadzoru nad dostawcami i zgodności regulacyjnej.

Problem dowodów dotyczących portfela w 2026 r. wykracza poza eIDAS2

Większość dyskusji o EU Digital Identity Wallet koncentruje się na zaufaniu, interoperacyjności i doświadczeniu użytkownika. To ważne obszary. Jednak CISO, menedżer zgodności, IOD lub audytor zadaje bardziej operacyjne pytanie: jakie środki kontrolne potwierdzają, że atrybuty tożsamości pochodzące z portfela są używane bezpiecznie, zgodnie z prawem i proporcjonalnie?

Strona ufająca, która akceptuje oświadczenia z portfela, powinna umieć odpowiedzieć na następujące pytania:

• Jakie atrybuty portfela są wymagane i dlaczego?
• Jaka podstawa prawna uzasadnia przetwarzanie?
• Czy użytkownicy, administratorzy i konta serwisowe są jednoznacznie identyfikowalne?
• Czy usługi weryfikacji portfela, brokerzy tożsamości, bramy API i komponenty chmurowe znajdują się w rejestrze dostawców?
• Czy zdarzenia uwierzytelniania i weryfikacji są logowane w sposób wspierający postępowanie wyjaśniające, bez nadmiernego gromadzenia danych osobowych?
• Czy istnieje proces obsługi incydentów na wypadek nadużycia, niedostępności lub naruszenia onboardingu opartego na portfelu?
• Czy w przypadku podmiotów finansowych integracja z portfelem jest objęta zarządzaniem ryzykiem ICT zgodnie z DORA, zarządzaniem ryzykiem stron trzecich i klasyfikacją incydentów?
• Czy w przypadku podmiotów NIS2 zależność od portfela wpływa na świadczenie usług kluczowych lub ważnych, kontrolę dostępu, ciągłość działania albo komunikację z klientami?

NIS2 jest szczególnie istotna, ponieważ jej zakres obejmuje wielu dostawców infrastruktury cyfrowej, usługi przetwarzania w chmurze, dostawców usług zarządzanych, dostawców zarządzanych usług bezpieczeństwa oraz dostawców usług zaufania. Dyrektywa klasyfikuje również kwalifikowanych dostawców usług zaufania, dostawców DNS, rejestry TLD i kilka innych kategorii podmiotów jako kluczowe w określonych okolicznościach. W 2026 r. wiele organizacji nie będzie już pytać, czy prawo zaczyna obowiązywać. Będą odpowiadać na pytania organów nadzorczych, klientów i audytu wewnętrznego dotyczące wdrożenia.

W usługach finansowych DORA dodaje kolejną warstwę. Ma zastosowanie od 17 stycznia 2025 r. i ustanawia jednolite ramy zarządzania ryzykiem ICT, incydentami, testowaniem i ryzykiem stron trzecich dla podmiotów finansowych. NIS2 uznaje DORA za sektorowy akt prawny Unii dla wielu nakładających się obowiązków cyberbezpieczeństwa w sektorze finansowym. W praktyce oznacza to, że funkcja onboardingu oparta na portfelu w instytucji płatniczej, dostawcy usług w zakresie kryptoaktywów, firmie inwestycyjnej lub dostawcy usług dostępu do informacji o rachunku musi być udokumentowana dowodowo zgodnie ze stylem nadzoru nad ryzykiem ICT wymaganym przez DORA, nawet jeżeli NIS2 nadal ma znaczenie dla koordynacji i zależności ekosystemowych.

Błędną reakcją jest tworzenie osobnego pakietu dowodowego dla eIDAS2, osobnego dla GDPR, osobnego dla NIS2, osobnego dla DORA i osobnego dla certyfikacji ISO. Właściwą reakcją jest wykorzystanie SZBI jako operacyjnego modelu dowodowego.

Wykorzystaj ISO 27001 jako kręgosłup dowodowy

ISO/IEC 27001:2022 jest użyteczna, ponieważ nie ogranicza się do technicznej listy kontrolnej. Wymaga od organizacji określenia kontekstu, stron zainteresowanych, obowiązków prawnych i umownych, zakresu, interfejsów, zależności, odpowiedzialności kierownictwa, oceny ryzyka, postępowania z ryzykiem, Deklaracji stosowania i ciągłego doskonalenia.

Ma to znaczenie dla adopcji portfela, ponieważ ryzyko nie występuje wyłącznie w wywołaniu API. Ryzyko występuje w całym procesie biznesowym od początku do końca.

Wdrożenie strony ufającej portfelowi wpływa na:

• onboarding klientów i dostęp do konta;
• informacje o prywatności, wpisy RoPA i zapisy dotyczące podstawy prawnej;
• potwierdzanie tożsamości i modele uwierzytelniania;
• umowy z dostawcami i zapewnienie skuteczności zabezpieczeń;
• logowanie, monitorowanie i zachowanie materiału dowodowego;
• klasyfikację i zgłaszanie incydentów;
• okres przechowywania danych, usuwanie i sprostowanie;
• audyt i monitorowanie zgodności;
• raportowanie ryzyka na poziomie zarządu.

Polityka zgodności dla przedsiębiorstw Clarysec jasno opisuje ten model operacyjny:

„Wszystkie obowiązki prawne i regulacyjne muszą być zmapowane na konkretne polityki, środki kontrolne i właścicieli w ramach Systemu Zarządzania Bezpieczeństwem Informacji (SZBI).”
Z Polityki zgodności prawnej i regulacyjnej, sekcja „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.2.1.

Dla MŚP ta sama zasada jest skalowana do praktycznego rejestru zgodności:

„Jeżeli regulacja ma zastosowanie do wielu obszarów (np. GDPR dotyczy okresu przechowywania, bezpieczeństwa i prywatności), należy to jasno zmapować w Rejestrze zgodności oraz materiałach szkoleniowych.”
Z Polityki zgodności prawnej i regulacyjnej — MŚP, sekcja „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.2.2.

Organizacja nie powinna pytać: „Który dział odpowiada za eIDAS2?”. Powinna zapytać: „Na które ryzyka SZBI, środki kontrolne, polityki, właścicieli i zapisy dowodowe wpływa zależność od portfela?”.

W Zenith Blueprint, w fazie Zarządzania ryzykiem, Krok 14, wskazano:

„Dla każdej regulacji, jeżeli ma zastosowanie, można utworzyć prostą tabelę mapowania (np. jako załącznik do raportu), która wymienia kluczowe wymagania bezpieczeństwa danej regulacji oraz odpowiadające im środki kontrolne/polityki w ISMS. Nie jest to obowiązkowe w ISO 27001, ale jest użytecznym ćwiczeniem wewnętrznym, które pomaga upewnić się, że nic nie zostało pominięte. Pokazuje też audytorom/asesorom, że organizacja nie zarządza bezpieczeństwem w próżni, lecz uwzględnia kontekst prawny.”

To jest fundament: należy zbudować jedną tabelę mapowania, która łączy obowiązki strony ufającej portfelowi z GDPR, NIS2, DORA, środkami kontrolnymi z załącznika A ISO/IEC 27001:2022, politykami Clarysec oraz zapisami dowodowymi.

Praktyczna mapa dowodów dla stron ufających EU Digital Identity Wallet

EUDI Wallet staje się możliwy do zarządzania, gdy jest traktowany jako zdefiniowany proces biznesowy w SZBI, z mapowaniem danych, tożsamości, dostawców, logów, incydentów i właścicieli.

Ta tabela nie jest opinią prawną. Jest modelem środków kontrolnych i dowodów, którego CISO, zespoły ds. zgodności i audytorzy mogą używać do uporządkowania dowodów.

Zarządzanie tożsamością to punkt startowy audytorów

Dla strony ufającej portfelowi tożsamość jest oczywistą rodziną środków kontrolnych. Zarządzanie tożsamością nie jest jednak tym samym co uwierzytelnianie. Zarządzanie tożsamością odpowiada na pytanie: „kto istnieje w systemie i jak ta tożsamość jest nadzorowana?”. Uwierzytelnianie odpowiada na pytanie: „jak deklarowana tożsamość jest weryfikowana w momencie dostępu?”.

W Zenith Controls środek kontrolny ISO/IEC 27002:2022 5.16, Zarządzanie tożsamością, jest traktowany jako kontrola zapobiegawcza wspierająca poufność, integralność i dostępność. Łączy się bezpośrednio z kontrolą dostępu, informacjami uwierzytelniającymi, prawami dostępu, relacjami z dostawcami, monitorowaniem zgodności i dostępem uprzywilejowanym. Mapowanie zgodności przekrojowej łączy ten obszar z bezpieczeństwem i rozliczalnością GDPR, kontrolą dostępu i zarządzaniem aktywami NIS2, nadzorem nad tożsamością i dostępem w DORA, zarządzaniem identyfikatorami w NIST SP 800-53 oraz nadzorem nad cyklem życia tożsamości w COBIT 2019.

W przypadku dowodów dotyczących portfela organizacja powinna móc wykazać, że:

• tożsamości klientów i personelu nie są ze sobą mylone;
• tożsamości administracyjne są unikalne i możliwe do prześledzenia;
• tożsamości dostawców są zarządzane z taką samą dyscypliną jak tożsamości pracowników;
• tożsamości nieosobowe, takie jak klienci API i konta serwisowe, mają właścicieli;
• tożsamości są odbierane, gdy nie są już wymagane;
• wyjątki, konta awaryjne break-glass i tożsamości uprzywilejowane są kontrolowane.

Polityka kont dla MŚP Clarysec ujmuje tę zasadę prostym językiem:

„Każde konto musi być unikalne, możliwe do powiązania z konkretną osobą i powiązane z rolą biznesową.”
Z Polityki zarządzania kontami użytkowników i uprawnieniami — MŚP, sekcja „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.1.2.

Dla przedsiębiorstw wymaganie dotyczące kont współdzielonych jest bardziej rygorystyczne:

„Wszystkie tożsamości użytkowników muszą być powiązane z unikalnym identyfikatorem. Korzystanie ze współdzielonych lub ogólnych kont jest zabronione, z wyjątkiem zatwierdzonych kont typu break-glass lub kont awaryjnych objętych ścisłymi kontrolami.”
Z Polityki zarządzania kontami użytkowników i uprawnieniami, sekcja „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.3.

Normy wspierające wzmacniają tę samą logikę dowodową. ISO/IEC 24760-1:2019 dostarcza pojęć cyklu życia tożsamości, takich jak rejestracja, powiązanie, użycie i wyrejestrowanie. ISO/IEC 29115:2013 wspiera zapewnienie tożsamości oparte na ryzyku. ISO/IEC 27005:2024 traktuje słabości tożsamości i dostępu jako tematy postępowania z ryzykiem. ISO/IEC 27018:2020 rozszerza oczekiwania dotyczące zarządzania tożsamością dla przetwarzania PII w chmurze publicznej. ISO/IEC 29100:2011 dodaje perspektywę prywatności, łącząc identyfikowalność z postępowaniem z informacjami osobowymi.

W przypadku adopcji EUDI Wallet pytanie audytowe jest proste: czy można powiązać każde działanie uprzywilejowane, zmianę konfiguracji, zmianę integracji weryfikacji portfela oraz zdarzenie dostępu dostawcy z unikalną tożsamością mającą zatwierdzoną rolę?

Jeżeli odpowiedź brzmi „nie”, projekt portfela nie jest gotowy do audytu.

Bezpieczne uwierzytelnianie: zaufanie do portfela nie znosi obowiązków kontrolnych

Częstym błędnym założeniem jest przekonanie, że potwierdzanie tożsamości oparte na portfelu usuwa obowiązki uwierzytelniania po stronie ufającej. Może ono zwiększyć poziom zapewnienia dla konkretnych atrybutów tożsamości, ale nie zwalnia z obowiązku zabezpieczenia systemów, sesji, interfejsów API, interfejsów administracyjnych i ścieżek klienta.

W Zenith Blueprint, w fazie Środki kontrolne w działaniu, Krok 19, Clarysec stwierdza:

„Uwierzytelnianie jest pierwszą i najważniejszą linią obrony między sprawcą zagrożenia a systemami, danymi i usługami organizacji. Jeżeli uwierzytelnianie jest słabe, wszystko inne — szyfrowanie, monitorowanie, segmentacja — może zostać ominięte.”

Ten sam krok wyjaśnia, że nowoczesne uwierzytelnianie musi być oparte na ryzyku, silniejsze dla celów o wyższej wartości oraz wspierane przez MFA, bezpieczne przechowywanie danych uwierzytelniających, TLS, ochronę tokenów, zarządzanie sekretami, bezpieczną obsługę sesji i przegląd logów uwierzytelniania.

W Zenith Controls środek kontrolny ISO/IEC 27002:2022 8.5, Bezpieczne uwierzytelnianie, jest mapowany jako kontrola zapobiegawcza w zdolności zarządzania tożsamością i dostępem. Łączy się z zarządzaniem tożsamością, informacjami uwierzytelniającymi, dostępem uprzywilejowanym, ograniczeniem dostępu do informacji, działaniami monitorowania, zarządzaniem incydentami oraz ochroną prywatności PII. Jest również mapowany przekrojowo na bezpieczeństwo i data protection by design w GDPR, zarządzanie ryzykiem cyberbezpieczeństwa NIS2 oraz MFA lub ciągłe uwierzytelnianie, gdy jest właściwe, nadzór nad ryzykiem ICT w DORA, rodziny IA i AC w NIST SP 800-53 oraz nadzór nad dostępem logicznym w COBIT 2019.

W przypadku strony ufającej portfelowi dowody bezpiecznego uwierzytelniania powinny obejmować:

• uwierzytelnianie i autoryzację punktów końcowych weryfikacji portfela;
• MFA administratorów paneli konfiguracji portfela;
• bezpieczne uwierzytelnianie API między usługami onboardingu;
• przechowywanie w sejfie sekretów kluczy lub certyfikatów integracji z portfelem;
• limity bezczynności sesji i ochronę tokenów, gdy są właściwe;
• alerty nieudanego uwierzytelniania i zabezpieczenia przed próbami brute force;
• odrębne środki kontrolne dla logowania klienta, dostępu pracowników i dostępu machine-to-machine.

Polityka logowania dla MŚP Clarysec podaje praktyczne wymaganie dowodowe:

„Logi uwierzytelniania: udane i nieudane próby logowania, czas trwania sesji, użycie MFA”
Z Polityki logowania i monitorowania — MŚP, sekcja „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.4.2.

W środowiskach przedsiębiorstw kluczowa staje się wiarygodność audytowa:

„Pliki logów muszą być niemodyfikowalne lub objęte kontrolą wersji, a dostęp do nich może być przyznany wyłącznie upoważnionemu personelowi.”
Z Polityki logowania i monitorowania, sekcja „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.5.1.

To jest pomost między zapewnieniem tożsamości a reagowaniem na incydenty. Jeżeli onboarding oparty na portfelu zostanie zaatakowany przez credential stuffing, ataki powtórzeniowe tokenów, naruszenie konta administracyjnego lub nadużycie ze strony dostawcy, logi uwierzytelniania stają się ścieżką dowodową.

GDPR: obietnicą portfela jest minimalizacja, ale trzeba ją wykazać

EU Digital Identity Wallet może wspierać onboarding zwiększający prywatność, ponieważ strona ufająca może żądać konkretnych atrybutów zamiast gromadzenia pełnych dokumentów tożsamości. Rozliczalność w GDPR nie opiera się jednak na dobrych intencjach. Wymaga wykazania zgodności.

Atrybuty pochodzące z portfela są danymi osobowymi, gdy dotyczą osoby zidentyfikowanej lub możliwej do zidentyfikowania. Niektóre przypadki użycia mogą również obejmować dane biometryczne, dane weryfikacji tożsamości, screening sankcyjny, ryzyko oszustw lub inne wrażliwe konteksty przetwarzania.

Zasady GDPR wymagają zgodnego z prawem, rzetelnego i przejrzystego przetwarzania, określonych celów, minimalizacji danych, prawidłowości, ograniczenia przechowywania, integralności i poufności oraz rozliczalności. Strona ufająca powinna umieć wykazać, dlaczego żąda każdego atrybutu z portfela, jak długo go przechowuje, kto ma do niego dostęp, jak jest chroniony i jak kontrolowane jest jego ponowne użycie.

Polityka prywatności dla przedsiębiorstw Clarysec stanowi:

„Zbierane i przetwarzane mogą być wyłącznie dane niezbędne do konkretnego, uzasadnionego celu biznesowego.”
Z Polityki ochrony danych i prywatności, sekcja „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.2.1.

Wersja dla MŚP jest celowo zwięzła:

„Należy zbierać i przechowywać wyłącznie minimalny zakres niezbędnych danych osobowych”
Z Polityki ochrony danych i prywatności — MŚP, sekcja „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.2.1.

W Zenith Controls środek kontrolny ISO/IEC 27002:2022 5.34, Prywatność i ochrona PII, jest mapowany na inwentarz aktywów, maskowanie danych, nadzór nad usługami chmurowymi, klasyfikację informacji, bezpieczny transfer, kontrolę dostępu, zarządzanie tożsamością i przegląd zmian projektowych. Łączy się również z ISO/IEC 27701:2021 dla zarządzania prywatnością, ISO/IEC 27018 dla przetwarzania PII w chmurze oraz zasadami prywatności ISO/IEC 29100.

Dla adopcji portfela pakiet dowodów prywatności powinien obejmować:

• diagram przepływu danych dla atrybutów portfela;
• wpis w rejestrze podstaw prawnych;
• zapis decyzji o minimalizacji atrybutów;
• harmonogram okresów przechowywania danych pochodzących z portfela;
• aktualizację informacji o prywatności;
• DPIA lub ocenę ryzyka prywatności, gdy przypadek użycia jest wysokiego ryzyka;
• macierz kontroli dostępu do danych portfela;
• proces usuwania i sprostowania danych;
• dowody monitorowania pokazujące, że dostęp do PII pochodzących z portfela jest kontrolowany.

Wiele organizacji gromadzi nadmiarowe dane, ponieważ portfel ułatwia uzyskanie zweryfikowanych informacji. To odwrócenie właściwej logiki. Korzyść w zakresie bezpieczeństwa i prywatności wynika z żądania mniejszej ilości danych, a nie z przechowywania większej liczby zweryfikowanych danych tożsamości niż wymaga tego biznes.

NIS2 i DORA: rozliczalność kierownictwa spotyka odporność portfela

NIS2 i DORA przenoszą cyberbezpieczeństwo na poziom zarządzania. Wymagają, aby organy zarządzające zatwierdzały, nadzorowały i ponosiły odpowiedzialność za środki zarządzania ryzykiem. Oczekują również proporcjonalnych technicznych, operacyjnych i organizacyjnych środków kontrolnych.

NIS2 Article 21 wymaga środków zarządzania ryzykiem obejmujących polityki, obsługę incydentów, ciągłość działania, bezpieczeństwo łańcucha dostaw, bezpieczne nabywanie i rozwój, obsługę podatności, skuteczność kontroli, cyberhigienę, szkolenia, kryptografię, bezpieczeństwo HR, kontrolę dostępu, zarządzanie aktywami oraz, gdy jest to właściwe, MFA lub ciągłe uwierzytelnianie. W przypadku stron ufających portfelowi w sektorach NIS2 integracja z portfelem powinna pojawić się w ocenie ryzyka, inwentarzu aktywów, rejestrze dostawców, planie obsługi incydentów i ramach kontroli dostępu.

NIS2 Article 23 dodaje etapowe zgłaszanie znaczących incydentów. Podmioty kluczowe i ważne muszą przekazać wczesne ostrzeżenie w ciągu 24 godzin, zgłoszenie w ciągu 72 godzin oraz raport końcowy w ciągu jednego miesiąca, wraz z komunikacją do odbiorców, gdy ma zastosowanie. Jeżeli awaria integracji z portfelem mogłaby spowodować zakłócenie operacyjne, stratę finansową albo istotną szkodę materialną lub niematerialną dla odbiorców usług, powinna zostać uwzględniona w logice klasyfikacji incydentów.

DORA jest bardziej szczegółowa dla podmiotów finansowych. Wymaga wewnętrznych ram ładu zarządczego i kontroli dla ryzyka ICT, zatwierdzonej przez zarząd strategii odporności, polityk ICT, planów ciągłości działania i reagowania, planów audytu, polityk stron trzecich, kanałów zgłaszania incydentów oraz udokumentowanych ram zarządzania ryzykiem ICT. Wymaga również zarządzania incydentami związanymi z ICT, klasyfikacji z użyciem kryteriów takich jak dotknięci klienci, czas niedostępności, zasięg geograficzny, utrata danych, krytyczność i wpływ ekonomiczny, a także zgłaszania poważnych incydentów związanych z ICT.

W przypadku onboardingu opartego na portfelu w usługach finansowych dowody powinny wykazywać, że:

• integracja z portfelem znajduje się w inwentarzu aktywów i procesów ICT;
• ryzyka są ocenione i zaakceptowane przez właściwego właściciela;
• krytyczność onboardingu klienta lub dostępu do konta została oceniona;
• istnieją opcje odporności i przełączenia w tryb awaryjny;
• incydenty mogą być klasyfikowane według kryteriów DORA;
• powiadomienia klientów są zaplanowane tam, gdzie naruszone mogą być interesy finansowe;
• zgłaszanie realizowane w outsourcingu, jeżeli jest stosowane, nie znosi rozliczalności.

Kluczowa jest proporcjonalność. Mały fintech i duży bank nie wytworzą takiego samego wolumenu dowodów, ale oba podmioty potrzebują możliwego do prześledzenia nadzoru.

Zależności od dostawców i chmury: proces portfela jest tak silny jak jego łańcuch

Większość wdrożeń strony ufającej portfelowi obejmuje usługi zewnętrzne: hosting w chmurze, bramy API, biblioteki weryfikacyjne, brokerów tożsamości, dostawców KYC, silniki antyfraudowe, platformy logowania, dostawców Managed Detection and Response lub narzędzia obsługi klienta. To sprawia, że nadzór nad dostawcami jest kluczowy.

NIS2 wymaga, aby podmioty uwzględniały podatności specyficzne dla dostawców oraz ogólną jakość i praktyki cyberbezpieczeństwa dostawców i usługodawców. DORA idzie dalej w przypadku podmiotów finansowych, wymagając rejestru umownych uzgodnień dotyczących usług ICT, ocen przedkontraktowych, analizy ryzyka koncentracji, due diligence, podejść do audytu i inspekcji, praw rozwiązania umowy oraz przetestowanych strategii wyjścia dla usług ICT wspierających funkcje krytyczne lub ważne.

W Zenith Blueprint, w fazie Środki kontrolne w działaniu, Krok 23, Clarysec instruuje zespoły, aby przygotowały pełną listę dostawców, sklasyfikowały dostawców według dostępu do systemów, danych lub kontroli operacyjnej, osadziły oczekiwania w umowach, zidentyfikowały podwykonawców, określiły wyzwalacze zmian i zbudowały proces oceny usług chmurowych. Ten sam krok zaleca ocenę lokalizacji danych, modelu dostępu, logowania i szyfrowania przed zatwierdzeniem przyszłych usług przetwarzania w chmurze.

Polityka dostawców dla MŚP Clarysec zawiera jasną zasadę minimalnego dostępu:

„Dostawcom wolno przyznać dostęp wyłącznie do minimalnego zakresu systemów i danych wymaganego do wykonania ich funkcji.”
Z Polityki bezpieczeństwa dostawców i stron trzecich — MŚP, sekcja „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.2.1.

NIST CSF 2.0 wspiera to zintegrowane podejście. Jego funkcja GOVERN obejmuje obowiązki prawne, regulacyjne, umowne i prywatnościowe, apetyt na ryzyko, rozliczalność, politykę, zasoby i nadzór. Wyniki dotyczące łańcucha dostaw wymagają określenia ról dostawców, priorytetyzacji według krytyczności, umownych wymagań cyberbezpieczeństwa, due diligence, monitorowania, planowania incydentowego i postanowień po zakończeniu relacji.

Audytorzy COBIT 2019 będą szukać dojrzałości ładu zarządczego. Zapytają, czy odpowiedzialności dostawców, cykl życia tożsamości, kontrole prywatności i monitorowanie są osadzone w procesach biznesowych, a nie wyłącznie w listach kontrolnych zespołu bezpieczeństwa. Dla tożsamości i dostępu logicznego szczególnie istotny jest COBIT 2019 DSS05.04, Manage user identity and logical access, gdy oceniane jest, czy własność kont, zatwierdzenia, przypisywanie uprawnień i odbieranie dostępu są kontrolowane.

Zbuduj pakiet dowodowy strony ufającej portfelowi w jedno popołudnie

Praktyczne ćwiczenie w stylu Clarysec rozpoczyna się od jednego konkretnego przypadku użycia, a nie od szerokiej deklaracji programowej. Jako pierwszy zapis można przyjąć: „onboarding klienta z użyciem imienia i nazwiska zgodnego z dokumentami, daty urodzenia i adresu udostępnionych przez portfel”. Dodaj właściciela biznesowego, właściciela systemu, właściciela danych i właściciela ryzyka.

Zapisz:

• cel przetwarzania;
• żądane atrybuty portfela;
• czy atrybuty są przechowywane, cache’owane czy wyłącznie weryfikowane;
• zaangażowane systemy i interfejsy API;
• dostawców i podwykonawców przetwarzania;
• kraje lub regiony chmurowe objęte procesem;
• proces awaryjny w przypadku niepowodzenia weryfikacji portfela;
• punkty komunikacji z klientem.

Następnie dodaj przypadek użycia do rejestru zgodności.

Następnie przejrzyj Deklarację stosowania i plan postępowania z ryzykiem. Dla przypadków użycia EUDI Wallet powszechnie istotne są następujące obszary środków kontrolnych ISO/IEC 27002:2022.

Na koniec przeprowadź mini-audyt. Wybierz jedną transakcję onboardingu portfela i prześledź:

1. uzasadnienie żądania atrybutów;
2. krok przejrzystości lub zapis zgody, gdy ma zastosowanie;
3. log zdarzenia systemowego;
4. dowód uwierzytelniania API;
5. zapis kontroli dostępu dla personelu przeglądającego wynik onboardingu;
6. zaangażowanego dostawcę;
7. regułę okresu przechowywania;
8. ścieżkę klasyfikacji incydentu, gdyby dana transakcja była oszukańcza lub ujawniona.

Jeżeli nie da się prześledzić tej ścieżki, proces nie jest jeszcze gotowy dowodowo.

Jak różni audytorzy przetestują ten sam proces portfela

Różni audytorzy podchodzą do EU Digital Identity Wallet przez różne profesjonalne perspektywy. Te same dowody mogą odpowiedzieć na wiele pytań, jeżeli są dobrze ustrukturyzowane.

Zenith Controls dostarcza użytecznych szczegółów metodyki audytu dla tych obszarów. W przypadku zarządzania tożsamością audytorzy często prześledzą tożsamości użytkowników przez onboarding, modyfikację i zakończenie współpracy, uzgadniają zapisy HR z wykazami kont, kontrolują konta osób niebędących pracownikami oraz konta serwisowe, a także szukają współdzielonego użycia kont administratorów. W przypadku bezpiecznego uwierzytelniania audytorzy porównują polityki z konfiguracjami technicznymi, przeglądają pokrycie MFA, badają kontrole haseł i sesji oraz analizują logi udanych i nieudanych logowań. W przypadku prywatności i ochrony PII audytorzy próbkują DPIA, procesy żądań osób, których dane dotyczą, szkolenia z prywatności, inwentarze PII, szyfrowanie, logi dostępu i kontrole okresu przechowywania.

Polityka audytu i monitorowania zgodności Clarysec jasno wyjaśnia cel dowodowy:

„Generowanie możliwych do obrony dowodów oraz ścieżki audytowej na potrzeby zapytań regulacyjnych, postępowań sądowych lub wniosków klientów o zapewnienie.”
Z Polityki audytu i monitorowania zgodności, sekcja „Cele”, klauzula polityki 3.4.

To sformułowanie — możliwe do obrony dowody — odróżnia bibliotekę polityk od systemu zgodności gotowego do audytu.

Typowe błędy w projektach gotowości portfela

Pierwszym błędem jest gromadzenie zbyt dużej ilości danych. Portfele mogą ułatwiać uzyskiwanie zweryfikowanych atrybutów, ale GDPR wymusza przeciwne zachowanie: zbieraj i przechowuj tylko to, co jest konieczne. Jeżeli zespół produktowy żąda pełnych danych tożsamości, gdy wymagana jest jedynie weryfikacja wieku, projekt kontroli prywatności jest już wadliwy.

Drugim błędem jest ignorowanie tożsamości nieosobowych. Integracje z portfelem często opierają się na klientach API, certyfikatach, kontach serwisowych, skryptach automatyzacji i sekretach. Jeżeli te tożsamości nie mają właścicieli, nie są rotowane, monitorowane i wycofywane, środowisko strony ufającej jest słabe, nawet jeżeli ekosystem portfela jest silny.

Trzecim błędem jest traktowanie dostawców jako dokumentacji zakupowej. W ramach NIS2 i DORA bezpieczeństwo dostawców ma charakter operacyjny. Potrzebne są due diligence, klauzule umowne, monitorowanie, współpraca incydentowa, prawa do audytu i plany wyjścia. Dla podmiotów regulowanych przez DORA rejestr stron trzecich ICT jest kluczowym dowodem zgodności.

Czwartym błędem jest logowanie bez nadzoru. Nadmierne logowanie może tworzyć ryzyko prywatności. Niedostateczne logowanie niszczy zdolność dochodzeniową. Należy zdefiniować zdarzenia uwierzytelniania, weryfikacji, administracyjne i istotne dla incydentów, chronić logi przed modyfikacją, ograniczać dostęp i dostosować okres przechowywania do potrzeb prawnych i biznesowych.

Piątym błędem jest brak przećwiczenia raportowania. NIS2 przewiduje oczekiwania dotyczące raportowania znaczących incydentów w terminach 24 godzin, 72 godzin i jednego miesiąca. DORA przewiduje raportowanie wstępne, pośrednie i końcowe dla poważnych incydentów związanych z ICT. Jeżeli organizacja po raz pierwszy mapuje incydent związany z portfelem do tych osi czasu dopiero podczas rzeczywistego zdarzenia, ład zarządczy zawiódł.

Zamień adopcję EUDI Wallet w dowody gotowe do audytu

EU Digital Identity Wallet zmieni onboarding i zaufanie cyfrowe w całej Europie. Jednak dla CISO, IOD, menedżerów zgodności, audytorów i właścicieli biznesowych właściwym ruchem nie jest tworzenie kolejnego odizolowanego programu zgodności. Właściwym ruchem jest włączenie adopcji portfela do SZBI i zmapowanie jej na prywatność, tożsamość, uwierzytelnianie, dostawców, logowanie, odporność i reagowanie na incydenty.

Clarysec może pomóc zrobić to w uporządkowany sposób:

1. Użyj Zenith Blueprint, aby umieścić adopcję portfela w fazie Zarządzania ryzykiem, Krok 14 dla przekrojowych odniesień regulacyjnych, Krok 19 dla bezpiecznego uwierzytelniania oraz Krok 23 dla wdrożenia środków kontrolnych dotyczących dostawców, prywatności i wymagań prawnych.
2. Użyj Zenith Controls, aby zmapować środki kontrolne ISO/IEC 27002:2022 dotyczące zarządzania tożsamością, bezpiecznego uwierzytelniania i prywatności na dowody GDPR, NIS2, DORA, NIST i COBIT 2019.
3. Użyj szablonów polityk Clarysec, takich jak Polityka zgodności prawnej i regulacyjnej, Polityka ochrony danych i prywatności, Polityka zarządzania kontami użytkowników i uprawnieniami, Polityka logowania i monitorowania, Polityka bezpieczeństwa dostawców i stron trzecich — MŚP oraz Polityka audytu i monitorowania zgodności, aby przekształcić obowiązki w praktyki przypisane właścicielom i możliwe do przetestowania.
4. Zbuduj pakiet dowodowy strony ufającej portfelowi przed uruchomieniem, a nie dopiero po pierwszym żądaniu audytowym.

Jeżeli Twoja organizacja planuje polegać na EU Digital Identity Wallet w 2026 r., teraz należy zadać jedno pytanie: czy możemy wykazać, za pomocą możliwych do obrony dowodów, że ten przepływ tożsamości jest bezpieczny, zgodny z prawem, odporny i objęty nadzorem?

Odpowiedź Clarysec jest praktyczna: zmapuj, przypisz właścicieli, przetestuj i utrzymuj dowody w gotowości.