Zgodność z CRA: wnioski ze schematu ENISA EUDI Wallet [2026]

3 kwietnia 2026 r. ENISA opublikowała wersję roboczą v0.4.614 schematu certyfikacji EU Digital Identity Wallet: 110 stron, konsultacje publiczne trwające do 30 kwietnia oraz webinar zaplanowany na 8 kwietnia. To pierwszy schemat certyfikacji cyberbezpieczeństwa dla usług ICT w historii opracowany w ramach unijnej ustawy o cyberbezpieczeństwie (Cybersecurity Act). EUCC obejmuje już produkty ICT; niniejszy schemat toruje nową drogę, stosując te same ramy do usług. Dotyczy portfeli tożsamości cyfrowej, a nie produktów ogólnie. Jednak standardy dowodowe, obowiązki łańcucha dostaw oraz infrastruktura zgodności, które schemat ustanawia, ukształtują funkcjonowanie całej unijnej certyfikacji cyberbezpieczeństwa, w tym schematów, które ostatecznie obejmą produkty objęte CRA. Poniżej przedstawiamy, czego wymaga schemat, gdzie CRA jest wprost przywoływane oraz co producenci produktów powinni śledzić.

Dlaczego schemat portfela ma znaczenie dla producentów produktów

Schemat EUDI Wallet i CRA operują na różnych obiektach prawnych. CRA reguluje produkty z elementami cyfrowymi wprowadzane na rynek UE. Schemat portfela reguluje określony typ usługi: rozwiązanie EUDI Wallet. To nie są te same przepisy.

Ale mają wspólną infrastrukturę prawną.

Artykuł 24 i artykuł 27 CRA odwołują się do unijnych schematów certyfikacji cyberbezpieczeństwa na podstawie ustawy o cyberbezpieczeństwie jako alternatywnej ścieżki zgodności. Produkt objęty mającym zastosowanie schematem CSA może korzystać z certyfikacji w ramach tego schematu, aby wykazać zgodność z odpowiednimi zasadniczymi wymaganiami CRA. Żaden taki schemat obejmujący produkty CRA jeszcze nie istnieje. Schemat EUDI Wallet jest pierwszym opracowanym, a wybory dokonane przez ENISA w zakresie formatów dowodów, wymagań łańcucha dostaw i metodologii oceny będą się propagować.

Schemat wyznacza na stronie 9 wyraźną granicę jurysdykcyjną. Tekst jest bezpośredni: CRA „nie ma bezpośredniego zastosowania do portfeli EUDI, które są certyfikowane w ramach niniejszego schematu, ponieważ są one certyfikowane jako usługi ICT, a nie produkty ICT." Dla większości uczestników EUDIW CRA nie jest równoległym obowiązkiem. Schemat selektywnie czerpie z metodologii CRA, jednak to zapożyczenie nie rozszerza zakresu stosowania rozporządzenia.

Wyjątkiem jest obszar mobilny. Gdy instancja portfela jest aplikacją mobilną wprowadzaną na rynek przez podmiot komercyjny, CRA stosuje się do tej aplikacji jako do produktu z elementami cyfrowymi. Dla firm komercyjnie dystrybuujących mobilną aplikację portfela oba reżimy obowiązują jednocześnie. CRA obejmuje obowiązki przedrynkowe w zakresie zgodności i posprzedażne w zakresie zarządzania podatnościami dotyczące produktu. Schemat portfela obejmuje ciągłą certyfikację usługi. Oba nakładają się, ale wyłącznie w tym konkretnym scenariuszu. Organizacja świadcząca rozwiązanie portfela wyłącznie jako usługę ICT nie ma obowiązku wynikającego z CRA w ramach tego schematu.

Wspólna infrastruktura obejmuje CSA i European Common Criteria-based evaluation framework (ECCF), CEN TS 18072 w zakresie wymagań dotyczących usług portfela oraz EUCC (EU Common Criteria-based cybersecurity certification scheme) jako podstawę kompozycyjną dla komponentów sprzętowych i platformowych. Żaden z tych elementów nie został zbudowany wyłącznie z myślą o portfelach. To szkielet, który będą wykorzystywać przyszłe schematy powiązane z CRA.

Jeszcze jedna wyraźna granica: schemat stwierdza, że certyfikaty EUDIW „nie będą odpowiednie do domniemania zgodności" z CRA (s. 9). Nawet w przypadku mobilnych aplikacji portfela, do których CRA ma zastosowanie, certyfikat EUDIW nie zaspokaja wymogów zgodności z CRA. Dwie ścieżki zgodności są odrębne i każda z nich musi zostać ukończona niezależnie.

Dystrybutorzy mobilnych portfeli: dwie niezależne ścieżki zgodności. Jeżeli jesteś podmiotem komercyjnym wprowadzającym mobilną aplikację portfela na rynek UE, CRA stosuje się do tej aplikacji jako do produktu z elementami cyfrowymi. Musisz przeprowadzić ocenę zgodności z CRA dla produktu oraz certyfikację EUDIW dla usługi portfela. Żadna z nich nie zastępuje drugiej. Obie muszą zostać ukończone niezależnie i utrzymywane w ramach odrębnych cykli nadzoru. Jeżeli świadczysz portfel wyłącznie jako usługę ICT bez osobno dystrybuowanej aplikacji mobilnej, CRA nie ma zastosowania do Ciebie w ramach tego schematu.

Jeżeli Twoje produkty będą ostatecznie podlegać schematowi certyfikacji CSA w ramach ścieżki z artykułu 27 CRA, schemat portfela jest najlepszym dostępnym zapowiedzią tego, jak taka ocena będzie wyglądać. Metodologie walidowane w tym schemacie to te, z którymi się spotkasz.

Przegląd aktualnych opcji modułów CRA w czasie oczekiwania na schematy CSA znajduje się w przewodniku decyzyjnym dotyczącym oceny zgodności.

Infrastruktura certyfikacji dzisiaj

Krajobraz zgodności CRA ma obecnie cztery poziomy. Produkty domyślne (zdecydowana większość) mogą korzystać z samooceny w Module A. Produkty Ważne klasy I mogą stosować Moduł A, jeżeli stosują normy zharmonizowane, lub skierować się do jednostki notyfikowanej. Produkty Ważne klasy II i Krytyczne wymagają oceny przez stronę trzecią, przy czym produkty Krytyczne potrzebują dodatkowo mającego zastosowanie schematu CSA, jeśli taki istnieje.

Luka jest następująca: żaden schemat CSA nie obejmuje aktualnie zasadniczych wymagań CRA. Oznacza to, że ścieżka z artykułu 27 -- w której certyfikacja CSA uruchamia domniemanie zgodności z CRA -- nie jest jeszcze dostępna dla żadnego produktu. Istnieje w przepisach, ale nie w praktyce.

Schemat EUDI Wallet tej luki nie wypełnia. Ale ustanawia model.

Schemat nakazuje wyłącznie poziom zapewnienia „wysoki", bez możliwości wyboru niższych poziomów. Uzasadnienie zawarte w dokumencie jest bezpośrednie: „wszystkie funkcje świadczone przez portfele EUDI są funkcjami bezpieczeństwa, niektóre o krytycznej wrażliwości" (s. 17). Schemat przesądza, że żadna funkcja portfela nie jest wystarczająco mało ryzykowna, by dopuścić samoocenę.

Samoocena nie jest jedynie odradzana. Jest zablokowana: „Samoocena zgodności... nie jest dozwolona" (s. 18).

Ta logika jest zbieżna z podejściem CRA do produktów Ważnych i Krytycznych. Wyższe stawki uzasadniają surowsze ścieżki zgodności. Konkretny próg różni się między reżimami, ale zasada jest identyczna. Gdy ENISA będzie opracowywać przyszłe schematy CSA dla kategorii produktów CRA, należy spodziewać się zastosowania tego samego rozumowania do produktów z Załącznika III i IV.

Aktualne zasady klasyfikacji produktów na podstawie CRA omówione są w przewodniku klasyfikacji produktów.

Czego schemat wymaga od podmiotów prywatnych

Schemat definiuje czteroetapowy cykl życia dla wnioskodawców.

Przygotowanie obejmuje zebranie dokumentacji, ocenę ryzyka i zgromadzenie dowodów zapewnienia dla komponentów. Na tym etapie dowody z łańcucha dostaw stają się warunkiem koniecznym, a nie elementem uzupełniającym.

Pierwsza ocena obejmuje przegląd projektu i analizę zależności. IT Security Evaluation Facility (ITSEF) analizuje architekturę, model zaufania oraz status zgodności każdego komponentu, od którego zależy portfel.

Druga ocena obejmuje testy funkcjonalne, testy penetracyjne i ocenę podatności w odniesieniu do zadeklarowanych funkcji bezpieczeństwa portfela. Nie jest to przegląd dokumentacji. Testerzy aktywnie badają system.

Utrzymanie trwa po wydaniu certyfikatu. Wymagany jest coroczny nadzór, w tym testy penetracyjne w każdą rocznicę. Nie jest to formalność. To stały koszt oceny wbudowany w cykl życia certyfikatu.

Certyfikat jest ważny przez 5 lat. Limit jest nieprzekraczalny. Schemat stwierdza, że żadne odstępstwo nie jest możliwe (s. 26). Po wygaśnięciu certyfikatu portfel musi zostać dezaktywowany. Nie ma okresu przejściowego do negocjowania.

Obowiązek integralności informacji jest ostrzejszy niż w większości ram zgodności. Przekazanie nieprawidłowych lub niepełnych informacji jednostce certyfikującej jest kwalifikowane jako niezgodność (non-compliance), a nie nonkonformność (nonconformity) (s. 23-24). Różnica ma znaczenie: nonkonformność uruchamia proces naprawczy. Niezgodność może prowadzić do zawieszenia lub cofnięcia na innych podstawach.

Po powiadomieniu o nonkonformności masz 30 dni na ocenę, czy ustalenie jest istotne (s. 38). Termin nie zaczyna się od wykrycia problemu przez organizację. Zaczyna się od powiadomienia przez jednostkę certyfikującą. Organizacje, które nie mają procedur przyjmowania powiadomień o zgodności, mogą przepuścić ten termin, zanim ktokolwiek przeczyta wiadomość.

Zawieszenie jest publiczne. Schemat wymaga obowiązkowego publicznego ujawnienia w przypadku zawieszenia certyfikatu (s. 40). Maksymalny okres zawieszenia wynosi 42 dni, z możliwością przedłużenia do 1 roku przez krajowy organ certyfikacji cyberbezpieczeństwa (NCCA). Nie jest to kwestia wewnętrzna. Klienci i strony ufające będą o tym wiedzieć.

Przechowywanie dokumentów obejmuje 5 lat po wygaśnięciu certyfikatu, w tym fizyczne egzemplarze produktów tam, gdzie ma to zastosowanie (s. 49). Dla produktów programowych z 5-letnim certyfikatem oznacza to co najmniej 10-letni łańcuch dowodowy.

Model CRA wymaga oceny zgodności przed wprowadzeniem na rynek i zarządzania podatnościami po wprowadzeniu. Schemat portfela wymaga ciągłej zgodności z corocznym testowaniem penetracyjnym i nadzorem przez cały cykl życia certyfikatu. Dla podmiotów objętych obydwoma reżimami obowiązki pocertyfikacyjne w schemacie portfela są bardziej wymagające niż w CRA pod względem zakresu i częstotliwości.

Twój łańcuch dostaw jest teraz elementem łańcucha certyfikacji

Schemat portfela stosuje model oceny kompozycyjnej z trzema odrębnymi warstwami.

Wallet Secure Cryptographic Application (WSCA) oraz jego podstawowa platforma sprzętowa są oceniane w ramach EUCC, europejskiego schematu Common Criteria. Obejmuje to sprzętowe moduły bezpieczeństwa, elementy bezpieczne i zaufane środowiska wykonawcze, od których zależy portfel.

Instancja portfela (oprogramowanie działające na urządzeniu użytkownika) jest oceniana w ramach FiTCEM -- Functional IT Common Evaluation Method -- która obsługuje ocenę oprogramowania w sytuacjach, gdy rozdzielenie sprzętowe jest niewykonalne.

Usługi portfela (komponenty po stronie serwera, wydawanie tożsamości, interfejsy stron ufających) są oceniane w odniesieniu do wymagań CEN TS 18072.

Każda warstwa ma własną ścieżkę oceny. Twój certyfikat zależy od certyfikatów leżących poniżej.

Schemat wprost wskazuje na ciężar, jaki to nakłada na wnioskodawców: musisz „zebrać dokumentację zapewnienia dla swoich komponentów, co może oznaczać konieczność certyfikacji niektórych z nich" (s. 14). Sformułowanie „może oznaczać" nie oddaje rzeczywistości. Jeżeli komponent nie posiada wymaganej dokumentacji zapewnienia, ocena nie może zostać zakończona.

Ujawnienie podwykonawców jest wyczerpujące. Każdy podwykonawca musi być wymieniony wraz z zakresem zastosowanej oceny zgodności w odniesieniu do jego wkładu (s. 78). Nie istnieje kategoria ogólna „korzystamy z renomowanych dostawców." Każda strona trzecia albo posiada udokumentowane dowody zgodności, albo nie -- a ta luka jest Twoim problemem w trakcie oceny.

Powiadomienia o podatnościach od podmiotów nadrzędnych są obowiązkowe w obu kierunkach. Gdy podatność dotyczy produktu ICT stanowiącego podstawę kompozycyjnej usługi ICT, posiadacz certyfikatu EUCC musi poinformować zależnych posiadaczy certyfikatów EUDIW (s. 43). Jest to konkretne zobowiązanie związane z ujawnieniami podatności, a nie ogólne powiadomienie o każdej zmianie certyfikatu. Jeżeli dostawca komponentu zidentyfikuje podatność i nie poinformuje Cię o tym, jest to naruszenie z jego strony. Jeżeli poinformuje, masz 30-dniowe okno na ocenę istotności.

Ciągłe monitorowanie nie zatrzymuje się na granicy Twojej organizacji. Gdy certyfikat komponentu bazowego zostaje zaktualizowany lub zastąpiony, CAB musi przeprowadzić różnicową analizę zależności względem dokonanych zmian (s. 84). Istotna aktualizacja zależności uruchamia formalną ocenę CAB, czy zakres Twojej certyfikacji jest naruszony.

Dostawcy chmury nie są zwolnieni. Schemat klasyfikuje infrastrukturę „dostarczaną przez dostawcę" (s. 61) jako komponent objęty oceną łańcucha dostaw. Jeżeli Twoja usługa portfela działa na platformie chmurowej, status zgodności tej platformy jest częścią Twojego pakietu dowodów.

Reguła propagacji ma istotne znaczenie: jeżeli w raporcie certyfikacyjnym komponentu bazowego oczekuje na realizację korekta nonkonformności, CAB musi ocenić jej wpływ na kompozycyjną usługę ICT (s. 84). Jeżeli ten wpływ jest istotny, ocena kompozycyjna nie może zostać zakończona do czasu usunięcia nonkonformności. Nie jest to mechanizm automatyczny -- zależy od tego, czy nonkonformność zostanie uznana za istotną dla Twojej usługi. Jednak poważna otwarta nonkonformność w raporcie certyfikacyjnym dostawcy WSCA może zablokować zakończenie Twojej oceny.

Nie jest to hipotetyczny model przyszłości dla CRA. Obowiązek SBOM wynikający z CRA (Załącznik I Część II) i wymagania dotyczące monitorowania podatności (artykuły 13 i 14) działają na tej samej zasadzie. Schemat portfela pokazuje, jak te obowiązki funkcjonują w praktyce w ramach formalnej certyfikacji: udokumentowane, dwustronne i blokujące.

Informacje o tym, jak obowiązki CRA w zakresie łańcucha dostaw będą współdziałać z przyszłymi schematami certyfikacji CSA, można znaleźć w artykule Cybersecurity Act 2. Praktyczne aspekty generowania i utrzymywania SBOM omówiono w przewodniku po generowaniu SBOM.

Co rzeczywiście są warte Twoje obecne certyfikaty

Większość producentów zakłada, że posiadane certyfikaty mają znaczenie w nowych schematach. W przypadku EUDIW odpowiedź zależy całkowicie od tego, jaki certyfikat posiadasz i jak rygorystycznie audytor odwzorował jego zakres na kryteria schematu.

Schemat odnosi się do tego wprost w sekcji 5.3. Dopuszcza poleganie przez CAB na wcześniejszej pracy, ale warunki są rygorystyczne. Wymagane jest pismo pomostowe (bridge letter), gdy istnieje luka między okresem raportowania wcześniejszego audytu a bieżącą oceną (s. 85). Częściowe poleganie jest powszechne; pełne poleganie jest rzadkie.

Ustalenie dotyczące ISO 27001 zasługuje na bezpośrednią uwagę. Schemat stwierdza wyraźnie: „nie zapewnia sam w sobie wystarczającego poziomu zapewnienia, że poszczególne kontrole wybrane w deklaracji stosowania są zaprojektowane i działają z poziomem rygoru wymaganym przez ten schemat" (s. 88).

Logika ta ma zastosowanie szerzej niż tylko w kontekście EUDIW. Certyfikacja ISMS potwierdza dojrzałość procesów i istnienie systemu zarządzania. Nie potwierdza, że poszczególne kontrole działają na poziomie zapewnienia wymaganym przez konkretny schemat. To samo rozumowanie znajdzie zastosowanie pod CRA, gdy normy zharmonizowane zostaną ostatecznie określone.

Jeżeli zakres Twojego audytu SOC 2 Type II nie uwzględniał unijnych kryteriów cyberbezpieczeństwa, nie kwalifikuje się on do warunkowego polegania. Potrzebowałbyś zweryfikowanego mapowania od audytora. Zaplanuj tę rozmowę teraz, zanim będziesz w harmonogramie certyfikacji.

Szczegółowe porównanie tego, co faktycznie obejmuje ISO 27001 w odniesieniu do wymagań CRA, znajdziesz w naszym przewodniku porównawczym ISO 27001.

Zarządzanie podatnościami wykracza poza CRA

Wymagania schematu EUDIW dotyczące zarządzania podatnościami wprost czerpią z CRA. Schemat stwierdza: „Niniejsza sekcja... w dużej mierze czerpie z innych regulacji, takich jak artykuł 55 CSA... a także z CRA" (s. 43). To powiązanie ma znaczenie, ponieważ wymagania mają wspólną strukturę, ale różnią się mechanizmami.

W kwestii SBOM: schemat wymaga formatu maszynowo czytelnego (s. 43), zgodnego z CRA Aneksem I Część II. Nie jest to nowa koncepcja, jeśli już śledzisz obowiązki wynikające z CRA, ale potwierdza, że SBOM jako artefakt techniczny staje się oczekiwanym standardem we wszystkich schematach UE, a nie tylko w CRA.

Aktualizacje zabezpieczeń muszą być dostarczane oddzielnie od aktualizacji funkcjonalnych (s. 43). Ma to istotne znaczenie operacyjne. Łączone wydanie, które zarówno naprawia podatności, jak i dodaje funkcje, stwarza niejednoznaczność co do tego, na co użytkownicy wyrażają zgodę. Schemat traktuje je jako odrębne obowiązki.

Twoja polityka CVD musi być publiczna i zgodna z EN ISO/IEC 29147 (s. 47). Nie jest to dokument polityki ukryty w folderze zgodności. Musi być dostępna, aktualna i ustrukturyzowana zgodnie z normą.

W zakresie analizy wpływu: same wyniki CVSS są niewystarczające. Schemat wymaga analizy specyficznej dla kontekstu (s. 44). CVSS 9.8 w jednym kontekście wdrożeniowym może odpowiadać CVSS 4.0 w Twoim, ale musisz to uzasadnić dokumentacyjnie, a nie jedynie twierdzić.

Najistotniejsze operacyjnie wymaganie: istotna podatność bez ścieżki naprawczej uruchamia cofnięcie certyfikatu (s. 45). Tworzy to bezpośrednie powiązanie między rytmem wydawania poprawek a statusem certyfikacji. Zegar nie zatrzymuje się na ocenie.

Porównanie z CRA jest tu istotne. CRA wymaga powiadomienia ENISA w ciągu 24 godzin od wykrycia aktywnie wykorzystywanej podatności. EUDIW stosuje formułę „bez zbędnej zwłoki" przez łańcuch CAB. Inny zegar, inna droga, podobne intencje. Jeżeli budujesz procesy dla jednego reżimu, zaprojektuj je tak, by spełniały oba.

Szczegółowe omówienie 24-godzinnego obowiązku raportowania znajdziesz w naszym artykule o raportowaniu podatności do ENISA. Punkt wyjścia dla polityki CVD oferuje szablon polityki CVD.

Co jest potwierdzone, a co jest naszą analizą

Pięć obszarów do obserwowania

Schemat nie jest ostateczny. Termin konsultacji 30 kwietnia oznacza, że zmiany są nadal możliwe. Poniżej przedstawiamy obszary, w których wynik ma istotne znaczenie dla Twojego planowania.

1. Wymagania dotyczące formatu dowodów: Schemat odwołuje się do SBOM w formacie maszynowo czytelnym i struktury pliku technicznego, ale nie w pełni standaryzuje, jak wyglądają „wystarczające" wymagania w praktyce. Interpretacji dokonają CAB. Do czasu ich określenia buduj możliwie najbardziej ustrukturyzowany format, jaki jesteś w stanie obronić.

2. Zdolności CAB: Autoryzacja wymaga zarówno akredytacji, jak i zgody NCCA oraz ukończenia oceny pilotażowej (s. 30). Problem startowy jest realny. Jeżeli kwalifikowanych CAB będzie mało w momencie wejścia schematu w życie, harmonogramy przesuną się niezależnie od tego, jak dobrze jesteś przygotowany. Nie masz na to wpływu, ale wpływa to na Twoje założenia harmonogramowe.

3. Wzajemne uznawanie: Schemat nie przyjmuje przepisów EUCC dotyczących wzajemnego uznawania dla schematów państw trzecich (s. 52). Wzajemne uznawanie przez państwa trzecie jest wprost pozostawione do późniejszego etapu: „warunki te mogą zostać dodane w późniejszej fazie." Jest to kwestia otwarta, a nie rozstrzygnięta. Nie licz na to, że Twoje certyfikaty wydane w USA będą respektowane, jednak jest to aktywna kwestia otwarta, a nie trwałe odrzucenie.

4. Wygasanie schematów krajowych: Istniejące schematy krajowe mają 12-miesięczne okno po wejściu w życie, przez które pozostają ważne (s. 56). Jeżeli Twoja aktualna certyfikacja jest wydana w ramach schematu krajowego, ustal, kiedy to okno się zamknie.

5. Otwarte kwestie: Odpowiedzialność za testy penetracyjne, progi poziomu potencjału ataku oraz kwalifikatory głębokości analizy podatności pozostają nierozstrzygnięte w obecnym tekście (s. 97-98). To nie są luki redakcyjne. Wpływają na zakres i budżet ocen.

Co wiemy na pewno

• CRA jest wprost przywołane jako źródło wymagań schematu.
• SBOM w formacie maszynowo czytelnym jest wymagany.
• Sam ISO 27001 nie spełnia wymagań dotyczących kontroli organizacyjnych.
• Samoocena nie jest dostępna na żadnym poziomie zapewnienia dla komponentów EUDIW.
• Ważność certyfikatu jest ograniczona do 5 lat.

Nasza analiza (niepotwierdzona)

• Schematy oceny zgodności CRA prawdopodobnie będą podążać za podobnymi wzorcami w zakresie wymagań SBOM, polityki CVD i niewystarczalności ISO 27001 w izolacji. Schemat EUDIW daje podgląd tego, jak ENISA myśli o tych obowiązkach.
• Presja certyfikacyjna w łańcuchu dostaw wzrośnie. Wymagania na poziomie komponentów EUDIW sugerują, że producenci downstream zaczną wymagać od dostawców upstream niezależnych certyfikatów, a nie wyłącznie własnych deklaracji.
• Mapowanie SOC 2 to realna szansa. Jeżeli już teraz zaangażujesz audytora w ustrukturyzowanie mapowania kryteriów na wymagania cyberbezpieczeństwa UE, możesz pozycjonować swój następny SOC 2 Type II do warunkowego uznania zamiast zaczynać od zera.

Czego jeszcze nikt nie wie

• Kiedy zostanie opublikowany schemat certyfikacji specyficzny dla CRA i jak będzie wyglądać harmonogram konsultacji.
• Które normy zharmonizowane zostaną wyznaczone na podstawie CRA i jakie progi zapewnienia będą ustanawiać.
• Jak krajowe zdolności CAB będą się rozwijać w stosunku do popytu, gdy wiele schematów będzie aktywnych jednocześnie.

Co producenci powinni zrobić teraz

Okno konsultacji i ostateczna publikacja schematu dają Ci określony czas na przygotowanie. Poniżej przedstawiamy konkretne kroki, a nie ogólne porady.

• Zrozum swoją ścieżkę oceny zgodności. Poziomy zapewnienia schematu odpowiadają różnym kategoriom produktów. To, co się do Ciebie stosuje, nie zawsze jest oczywiste. Przed podjęciem założeń skorzystaj ze strukturyzowanego procesu decyzyjnego. Zacznij od naszego przewodnika decyzyjnego dotyczącego oceny zgodności.

• Zacznij budować dowody teraz. SBOM, oceny ryzyka, polityki ujawniania podatności i pliki techniczne wymagają czasu, by powstać prawidłowo. Rozpoczęcie w okresie konsultacji pozwoli iterować przed tym, jak CAB będzie o nie prosić.

• Nie zakładaj, że ISO 27001 Cię obejmuje. Schemat jest wprost. Jeżeli Twoja postawa zgodności opiera się na ISO 27001 jako proxy dla zapewnienia cyberbezpieczeństwa, masz lukę. Zidentyfikuj, które kontrole wymagają niezależnej weryfikacji.

• Skonstruuj swój następny SOC 2 z mapowaniem kryteriów UE. Jeżeli zbliża się odnowienie SOC 2, porozmawiaj z audytorem przed ustaleniem zakresu. Udokumentowane mapowanie kryteriów na wymagania EUDIW (i docelowo CRA) to to, co przekształca Type II z częściowego w warunkowe uznanie.

• Śledź proces konsultacyjny. Webinar 8 kwietnia i pisemny termin 30 kwietnia to ostatnie formalne punkty wkładu przed przejściem schematu do finalizacji. Jeżeli schemat dotyczy Twoich produktów, przekaż uwagi lub przynajmniej monitoruj wprowadzane zmiany.

• Mapuj swój łańcuch dostaw. Zidentyfikuj, które komponenty upstream mieszczą się w zakresie schematu. Jeżeli dostawca nie może wykazać certyfikacji dla komponentu, który integrujesz, ta luka stanie się Twoim problemem w czasie oceny.

Jak pomaga CRA Evidence

CRA Evidence wspiera infrastrukturę dokumentacji i procesów wymaganą przez oceny EUDIW i CRA:

• Zarządzanie SBOM: Generuj, przechowuj i eksportuj SBOM w formatach maszynowo czytelnych zgodnych z wymaganiami CRA Załącznik I Część II.
• VDP z przepływem pracy CVD: Publikuj swoją politykę ujawniania podatności i zarządzaj nią za pomocą strukturyzowanego przepływu przyjmowania i reagowania zgodnego z EN ISO/IEC 29147.
• Śledzenie powiadomień ENISA: Śledź okna raportowania 24-godzinne, 72-godzinne i 14-dniowe z dokumentacją gotową do audytu dla każdego powiadomienia.
• Portal dostawców: Zarządzaj powiadomieniami w górę i w dół łańcucha dostaw z udokumentowanymi dowodami komunikacji dla plików technicznych.

Dowiedz się, co obejmuje CRA Evidence na craevidence.com.

Niniejszy artykuł ma charakter wyłącznie informacyjny i nie stanowi porady prawnej. W celu uzyskania szczegółowych wskazówek dotyczących zgodności skonsultuj się z wykwalifikowanym radcą prawnym.