CRA vs ISO 27001: luki w zgodności, których Twój SZBI nie pokrywa

ISO 27001 nie obejmuje CRA w pełni. Przewodnik mapuje luki, to co SZBI przenosi, i to co trzeba dodać przed terminem 2027.

CRA Evidence Team Opublikowano 12 stycznia 2026 Zaktualizowano 30 maja 2026
Trzy warstwy pokrycia bezpieczeństwa: organizacyjne (ISO 27001), wspólne procesy wytwórcze, bezpieczeństwo produktu (CRA)
W tym artykule

Firma z certyfikatem ISO 27001 często zakłada, że jest dobrze przygotowana na akt o cyberodporności (Rozporządzenie (UE) 2024/2847). Nie jest. Przynajmniej nie bez poważnych dodatkowych prac.

ISO 27001 chroni zasoby informacyjne organizacji. Rozporządzenie (UE) 2024/2847 wymaga, aby każdy produkt z elementami cyfrowymi wprowadzany na rynek UE był bezpieczny już w fazie projektowania, zawierał wykaz materiałów oprogramowania (SBOM) i był objęty aktualizacjami bezpieczeństwa przez cały przewidywany czas eksploatacji. To obowiązki na poziomie produktu, nie organizacji. Niezgodność grozi karami do 15 mln EUR lub 2,5% globalnego rocznego obrotu (Artykuł 64). Zobacz przewodnik po karach i egzekwowaniu CRA.

Obowiązki sprawozdawcze z Artykułu 14 zaczynają obowiązywać 11 września 2026 r. Pełna zgodność jest wymagana do 11 grudnia 2027 r. Zobacz pełny harmonogram wdrożenia CRA.

Ten przewodnik mapuje, gdzie SZBI pomaga, gdzie nie wystarcza i co trzeba dodać.

Podsumowanie

  • ISO 27001 = zarządzanie bezpieczeństwem informacji na poziomie organizacji
  • CRA = wymagania cyberbezpieczeństwa produktów (Załącznik I, Rozporządzenie (UE) 2024/2847)
  • ISO 27001 NIE oznacza zgodności z CRA
  • ISO 27001 daje podstawę dla procesów bezpiecznego wytwarzania
  • CRA wymaga dowodów na poziomie produktu: SBOM, obsługa podatności, oznakowanie CE
  • Oba standardy razem dają silną ogólną pozycję bezpieczeństwa
15 mln EUR
Maksymalna kara
lub 2,5% globalnego rocznego obrotu
11 wrz 2026
Artykuł 14
start obowiązków sprawozdawczych
11 gru 2027
Pełne stosowanie CRA
wymagana ocena zgodności
5 lat
Minimalne wsparcie
lub czas eksploatacji (Art. 13 ust. 8)

Źródło: Rozporządzenie (UE) 2024/2847, Artykuły 13, 14 i 64.

Co obejmuje ISO 27001, a czego wymaga CRA?

Co obejmuje ISO 27001

ISO 27001 to standard systemu zarządzania bezpieczeństwem informacji (SZBI) dla kontroli na poziomie organizacji.

Kontrole na poziomie organizacji
  • Polityki bezpieczeństwa informacji
  • Zarządzanie aktywami
  • Kontrola dostępu do systemów i danych
  • Stosowanie kryptografii
  • Bezpieczeństwo fizyczne, operacyjne i komunikacyjne
  • Relacje z dostawcami
  • Zarządzanie incydentami
  • Ciągłość działania
  • Zarządzanie zgodnością

Cel: ochrona zasobów informacyjnych organizacji.

Co obejmuje CRA

CRA to rozporządzenie produktowe obejmujące wymagania cyberbezpieczeństwa dla produktów z elementami cyfrowymi (Załącznik I).

Wymagania na poziomie produktu
  • Bezpieczeństwo w fazie projektowania
  • Brak znanych, możliwych do wykorzystania podatności
  • Bezpieczna konfiguracja domyślna
  • Ochrona przed nieautoryzowanym dostępem w produkcie
  • Ochrona danych i możliwość aktualizacji produktu
  • Obsługa podatności i zgłaszanie do ENISA
  • SBOM komponentów produktu (Załącznik I, Część II(1))
  • Polityka skoordynowanego ujawniania podatności (Załącznik I, Część II(5))
  • Publiczny kontakt ds. podatności (Załącznik I, Część II(6))
  • Oznakowanie CE i ocena zgodności

Cel: zapewnienie, że produkty wprowadzane na rynek są bezpieczne.

CRA klasyfikuje produkty na kategorie: domyślne, Ważne Klasa I, Ważne Klasa II oraz Krytyczne (Załączniki III i IV). Każda kategoria pociąga za sobą inne wymagania oceny zgodności. Produkt Ważny Klasy II wymaga obowiązkowej oceny przez jednostkę notyfikowaną, niezależnie od statusu certyfikatu ISO 27001. Zobacz przewodnik po klasyfikacji produktów CRA.

Zasadnicza różnica

Diagram ISO 27001 vs CRA: warstwy pokrycia bezpieczeństwa, trzy ułożone warstwy: bezpieczeństwo organizacji objęte przez ISO 27001, wspólne procesy wytwórcze, bezpieczeństwo produktu wymagane przez CRA

Gdzie ISO 27001 pomaga w CRA, a gdzie nie wystarcza

Gdzie ISO 27001 pomaga

Wymaganie CRA Wsparcie ISO 27001 W jaki sposób pomaga
Bezpieczne wytwarzanie A.8.25-28 (Bezpieczne wytwarzanie) Podstawa procesowa
Obsługa podatności A.8.8 (Podatności techniczne) Proces organizacyjny
Reagowanie na incydenty A.5.24-26 (Zarządzanie incydentami) Gotowość do reagowania
Zarządzanie dostawcami A.5.19-22 (Relacje z dostawcami) Bezpieczeństwo łańcucha dostaw
Kontrola dostępu A.5.15-18, A.8.2-5 Bezpieczeństwo środowiska wytwórczego
Kryptografia A.8.24 (Kryptografia) Podstawa polityki kryptograficznej
Dokumentacja A.5.1 (Polityki), 7.5 (Udokumentowane informacje) Kultura dokumentowania
Ocena ryzyka 6.1 (Ocena ryzyka) Metodologia ryzyka

Gdzie ISO 27001 nie wystarcza

Wymaganie CRA Luka ISO 27001 Czego brakuje
SBOM Częściowe: A.8.26/A.8.28 obejmują świadomość komponentów, nie maszynowo czytelny format SBOM Maszynowo czytelny SBOM obejmujący co najmniej zależności najwyższego poziomu, np. CycloneDX lub SPDX (Załącznik I, Część II(1))
Oznakowanie CE Nie pokryte Proces oceny zgodności
Testy bezpieczeństwa produktu Ograniczone Dowody testów produktu do pliku technicznego
Bezpieczna konfiguracja domyślna Brak ukierunkowania na produkt Wymagania konfiguracji produktu
Okres wsparcia Nie pokryte Co najmniej 5 lat lub czas eksploatacji, jeśli krótszy (Art. 13 ust. 8)
Zgłaszanie do ENISA Nie pokryte Powiadomienie 24 h/72 h + raport końcowy do krajowego CSIRT przez Single Reporting Platform (Art. 14)
Polityka CVD Nie pokryte Udokumentowana polityka skoordynowanego ujawniania podatności (Załącznik I, Część II(5))
Publiczny kontakt ds. podatności Nie pokryte Jeden punkt kontaktu do zgłoszeń, np. security.txt (Załącznik I, Część II(6))
Dokumentacja użytkownika Ograniczone Instrukcje bezpieczeństwa produktu
Plik techniczny Nie pokryte Format dokumentacji CRA zgodnie z Załącznikiem VII

Podsumowanie analizy luk

Mocna podstawa (ISO 27001 znacząco pomaga):

  • Kultura i świadomość bezpieczeństwa
  • Metodologia zarządzania ryzykiem
  • Gotowość do reagowania na incydenty
  • Zarządzanie bezpieczeństwem dostawców
  • Polityki bezpiecznego cyklu wytwarzania
  • Ramy kontroli dostępu
  • Praktyki dokumentowania

Częściowe pokrycie (ISO 27001 pomaga, ale nie wystarcza):

  • Zarządzanie podatnościami (zakres organizacyjny vs produktowy)
  • Kryptografia (polityka vs implementacja w produkcie)
  • Testy bezpieczeństwa (systemy korporacyjne vs testy produktu)
  • Zarządzanie zmianami (zmiany IT vs modyfikacje produktu)
  • SBOM (świadomość komponentów w A.8.26/A.8.28 vs maszynowo czytelny format)

Luki (specyficzne dla CRA, nie pokryte przez ISO 27001):

  • Generowanie i utrzymanie SBOM w standardowym formacie
  • Ocena zgodności produktu
  • Proces oznakowania CE
  • Zgłaszanie podatności do krajowego CSIRT przez Single Reporting Platform (Art. 14)
  • Plik techniczny produktu (Załącznik VII)
  • Zobowiązanie dotyczące okresu wsparcia (Art. 13 ust. 8)
  • Weryfikacja bezpiecznej konfiguracji domyślnej
  • Wymagania mechanizmu aktualizacji produktu
  • Polityka skoordynowanego ujawniania podatności (Załącznik I, Część II(5))
  • Publiczny kontakt do zgłaszania podatności (Załącznik I, Część II(6))

Jak wykorzystać ISO 27001 do spełnienia wymagań CRA

SZBI jako fundament

Producent z certyfikatem ISO 27001 ma solidne podstawy. Klucz to rozszerzenie istniejących procesów na obowiązki produktowe, zamiast budowania od zera.

Rozszerz istniejące procesy:

Proces ISO 27001 Rozszerzenie CRA
Ocena ryzyka (6.1) Ocena ryzyka produktu
Zarz. podatnościami (A.8.8) Obsługa podatności produktu + zgłoszenia do CSIRT
Zarz. dostawcami (A.5.19-22) Zbieranie SBOM od dostawców
Zarz. incydentami (A.5.24-26) Zgłoszenia do CSIRT zgodnie z Art. 14
Bezpieczne wytwarzanie (A.8.25-28) Testy bezpieczeństwa produktu i plik techniczny

Nowe procesy do dodania:

Nowy proces Cel
Generowanie SBOM Śledzenie komponentów zgodnie z Załącznik I, Część II(1)
Ocena zgodności Oznakowanie CE
Plik techniczny produktu Dokumentacja regulacyjna wg Załącznika VII
Zarządzanie okresem wsparcia Zobowiązanie wg Art. 13 ust. 8
Procedura zgłaszania do ENISA Powiadamianie o podatnościach przez krajowy CSIRT
Polityka CVD Skoordynowane ujawnianie wg Załącznik I, Część II(5)

Praktyczne kroki integracji

Krok 1: rozszerzenie zakresu

  • Dodać bezpieczeństwo produktu do zakresu SZBI
  • Uwzględnić wytwarzanie produktu w ocenie ryzyka
  • Rozszerzyć inwentarz aktywów o komponenty produktu

Krok 2: aktualizacja procesów

  • Zaktualizować procedurę obsługi podatności o zgłaszanie produktu do krajowego CSIRT przez Single Reporting Platform
  • Dodać SBOM do zarządzania zmianami
  • Uwzględnić w reagowaniu na incydenty wczesne ostrzeżenie w 24 h, powiadomienie wstępne w 72 h i raport końcowy

Krok 3: uzupełnienia dokumentacji

  • Pliki techniczne produktu
  • Rejestry SBOM
  • Dowody oceny zgodności
  • Dokumentacja okresu wsparcia

Krok 4: role i odpowiedzialności

  • Przydzielić właściciela bezpieczeństwa produktu
  • Zdefiniować odpowiedzialność za zgłoszenia do CSIRT
  • Ustanowić właściciela utrzymania SBOM
  • Przydzielić właściciela polityki CVD

Kontrole Załącznika A w ISO 27001 a CRA

Najbardziej istotne kontrole

Kontrola Rola ISO 27001 Zastosowanie w CRA
A.8.25 Bezpieczny cykl wytwarzania

Rola ISO 27001Polityki bezpiecznego wytwarzania.

Zastosowanie w CRAPodstawa wymagań bezpieczeństwa produktu (Załącznik I, Część I).

A.8.26 Wymagania bezpieczeństwa aplikacji

Rola ISO 27001Wymagania bezpieczeństwa w procesie wytwarzania.

Zastosowanie w CRAPodstawa zasadniczych wymagań produktu; częściowa podstawa dla inwentaryzacji komponentów SBOM.

A.8.27 Bezpieczna architektura systemu

Rola ISO 27001Zasady bezpiecznej architektury.

Zastosowanie w CRAArchitektura bezpieczeństwa produktu.

A.8.28 Bezpieczne kodowanie

Rola ISO 27001Praktyki bezpiecznego kodowania, w tym śledzenie zależności.

Zastosowanie w CRABezpieczeństwo kodu produktu; częściowa podstawa dla świadomości komponentów SBOM.

A.8.8 Zarządzanie podatnościami technicznymi

Rola ISO 27001Organizacyjna obsługa podatności.

Zastosowanie w CRARozszerzenie na podatności produktu i zgłoszenia do krajowego CSIRT przez Single Reporting Platform (Art. 14).

A.5.19-22 Relacje z dostawcami

Rola ISO 27001Zarządzanie bezpieczeństwem dostawców.

Zastosowanie w CRAZbieranie SBOM od dostawców i bezpieczeństwo łańcucha dostaw.

Czy certyfikat ISO 27001 liczy się przy ocenie zgodności z CRA?

Czy certyfikat ISO 27001 obejmuje zgodność z CRA?

Kluczowe zrozumienie:

  • Certyfikat ISO 27001 potwierdza dojrzałość organizacji w zakresie bezpieczeństwa
  • Zgodność z CRA to wymaganie regulacyjne dla każdego produktu osobno
  • Posiadanie ISO 27001 nie zwalnia z CRA
  • Audytorzy ISO 27001 nie oceniają zgodności z CRA

Obowiązki sprawozdawcze Artykułu 14 zaczynają obowiązywać 11 września 2026 r. Pełna zgodność jest wymagana do 11 grudnia 2027 r. Niezgodność grozi karami do 15 mln EUR lub 2,5% globalnego rocznego obrotu (Artykuł 64).

Synergie audytowe

Nadzorczy audyt ISO 27001:

  • Coroczna ocena SZBI
  • Może obejmować zakres bezpieczeństwa produktu
  • Dowody nadają się do ponownego użycia w CRA

Ocena zgodności CRA:

  • Ocena właściwa dla produktu
  • Odwołuje się do SZBI w kwestii dowodów procesowych
  • Wymaga dodatkowych dowodów na poziomie produktu

Możliwości synergii:

  • Synchronizacja harmonogramów audytów
  • Ponowne użycie dowodów tam, gdzie to możliwe
  • Podejście zintegrowanego systemu zarządzania
  • Jedno repozytorium dokumentacji

Trzy typowe scenariusze ISO 27001 + CRA

Scenariusz 1 ISO 27001 certyfikowany, start z CRA

Wykorzystaj SZBI jako dowód procesowy. Nie traktuj certyfikatu jako dowodu zgodności produktu.

Wykorzystaj z ISO 27001

Metodykę ryzyka, zarządzanie dostawcami, reakcję na incydenty i nadzór nad bezpiecznym wytwarzaniem.

Dowody właściwe dla CRA

Klasyfikacja produktu, generowanie SBOM, zgłaszanie z Art. 14 i dokumentacja techniczna z Załącznika VII.

Reguła decyzyjna: ponownie używaj kontroli SZBI tylko tam, gdzie tworzą dowody na poziomie produktu.

Scenariusz 2 Brak ISO 27001, podejście do CRA

Nadaj priorytet regulacji ze stałym terminem. Buduj dyscyplinę ISO 27001 wokół tej pracy zamiast opóźniać pracę produktową.

Fakty terminowe

Zgłaszanie z Art. 14 zaczyna się 11 września 2026 r. Pełne stosowanie CRA zaczyna się 11 grudnia 2027 r.

Najpierw CRA

Klasyfikacja, SBOM, dokumentacja techniczna, polityka CVD, publiczny kontakt i proces zgłaszania.

Reguła decyzyjna: zacznij od regulacyjnych obowiązków produktowych, a następnie rozwijaj model operacyjny w kierunku ISO 27001. Zobacz przewodnik CRA dla startupów.

Scenariusz 3 Wiele produktów, centralny SZBI

Centralizuj wspólne kontrole, ale trzymaj dowody zgodności osobno dla każdej rodziny produktów.

Centralizuj

Metodę ryzyka, obsługę podatności, wymagania dla dostawców i standardy wytwarzania.

Utrzymuj per produkt

Dokumentację techniczną, SBOM, ścieżkę zgodności, okres wsparcia i dowody release.

Reguła decyzyjna: jedna wspólna procedura bezpieczeństwa produktu, jeden rejestr dowodów na rodzinę produktów.

Strumienie pracy integracji ISO 27001 z CRA

Zakres i klasyfikacja produktu

Cel

Ustalić, które produkty są objęte CRA i który poziom ma zastosowanie.

Wynik

Rekord klasyfikacji dla każdej rodziny produktów.

Dowód

Uzasadnienie Załącznika III/IV i ścieżka zgodności.

Model ryzyka bezpieczeństwa produktu

Cel

Rozszerzyć metodę ryzyka SZBI na przypadki nadużyć i ryzyko cyklu życia produktu.

Wynik

Ocena ryzyka produktu.

Dowód

Mapowanie wymagań Załącznika I CRA.

SBOM i dowody dostawców

Cel

Zapewnić powtarzalną widoczność komponentów dla każdego wydania produktu.

Wynik

Proces SBOM i wymagania przyjmowania dowodów od dostawców.

Dowód

Załącznik I, Część II(1), Artykuł 13 ust. 5, A.5.19-22 i rekordy SBOM powiązane z wydaniami.

Obsługa i zgłaszanie podatności

Cel

Połączyć zarządzanie podatnościami ISO ze zgłaszaniem produktowym CRA.

Wynik

Polityka CVD, publiczny kontakt i runbook zgłoszeń CSIRT.

Dowód

Załącznik I, Część II(5) i (6), właściciel Art. 14 i terminy zgłoszeń.

Dokumentacja techniczna i ścieżka zgodności

Cel

Przekształcić dojrzałość procesów w dowody zgodności właściwe dla produktu.

Wynik

Dokumentacja techniczna Załącznika VII, deklaracja zgodności UE i decyzja modułowa.

Dowód

Architektura bezpieczeństwa, raporty testów, okres wsparcia i rekord oceny zgodności.

Właścicielstwo i szkolenie

Cel

Uczynić zgodność produktu działaniem operacyjnym, a nie jednorazowym projektem.

Wynik

Wyznaczeni właściciele i szkolenie zespołów.

Dowód

Tabela odpowiedzialności, rejestry szkoleń i kadencja audytu wewnętrznego.

Często zadawane pytania

Czy certyfikat ISO 27001 zwalnia firmę z oceny zgodności CRA?

Nie. Certyfikat ISO 27001 potwierdza dojrzałość organizacji w zakresie bezpieczeństwa informacji, ale nie stanowi oceny zgodności CRA. CRA wymaga dowodów na poziomie produktu: SBOM, pliku technicznego, deklaracji zgodności UE oraz, w stosownych przypadkach, oceny przez jednostkę notyfikowaną. Audytor certyfikujący SZBI nie ocenia zgodności z CRA. Zobacz ścieżki oceny zgodności CRA.

Które kontrole Załącznika A ISO 27001 są najbardziej bezpośrednio powiązane z Załącznikiem I CRA?

Kontrole o najsilniejszym pokrywaniu to A.8.25-28 (bezpieczny cykl wytwarzania), A.8.8 (zarządzanie podatnościami technicznymi) i A.5.19-22 (relacje z dostawcami). Odpowiadają one wymaganiom CRA dotyczącym bezpieczeństwa w fazie projektowania, obowiązku obsługi podatności i przepisom dotyczącym SBOM w łańcuchu dostaw. A.8.8 wymaga rozszerzenia, aby objąć zgłaszanie podatności produktu do krajowego CSIRT przez Single Reporting Platform ENISA (Artykuł 14).

Czy dowody z audytu ISO 27001 mogą być ponownie wykorzystane w pliku technicznym CRA?

Tak, selektywnie. Dowody z SZBI dotyczące bezpiecznego wytwarzania (A.8.25-28), zarządzania podatnościami (A.8.8) i kontroli dostawców (A.5.19-22) mogą być przywołane w pliku technicznym CRA. Plik techniczny wymaga jednak także dowodów na poziomie produktu, w tym architektury bezpieczeństwa, raportów z testów, SBOM i dokumentacji okresu wsparcia, których audyty ISO 27001 nie generują.

Czy ISO 27001:2022 jest lepiej dostosowany do CRA niż ISO 27001:2013?

Tak. ISO 27001:2022 dodaje kontrole bardziej istotne dla CRA, w szczególności A.8.25-28 (bezpieczny cykl wytwarzania, wymagania bezpieczeństwa aplikacji, bezpieczna architektura, bezpieczne kodowanie). Wersja z 2013 r. miała w tych obszarach słabsze pokrycie. Organizacja korzystająca z wersji 2013 powinna przeprowadzić analizę luk względem kontroli z 2022 r. specjalnie pod kątem CRA.

Czy ISO 27001 obejmuje wymaganie CRA dotyczące SBOM?

Częściowo. A.8.26 (wymagania bezpieczeństwa aplikacji) i A.8.28 (bezpieczne kodowanie) obejmują koncepcje świadomości komponentów i śledzenia zależności. ISO 27001 nie wymaga jednak maszynowo czytelnego SBOM obejmującego co najmniej zależności najwyższego poziomu, czego wymaga CRA (Załącznik I, Część II(1)). CRA nie wskazuje konkretnego formatu; CycloneDX i SPDX to praktyczne opcje, a Artykuł 13(24) pozwala Komisji określić format i elementy w późniejszym czasie. Świadomość organizacyjna stanowi podstawę, nie substytut.

Czy prace nad zgodnością z CRA można zintegrować z trwającym programem ISO 27001?

Tak, i jest to zalecane podejście dla firm posiadających certyfikat. Rozszerz zakres SZBI o bezpieczeństwo produktu, dodaj procedury właściwe dla produktu dotyczące SBOM i zgłaszania do CSIRT oraz odwołuj się do dowodów SZBI w plikach technicznych CRA. Kluczem jest uzupełnianie, a nie powielanie: dowody CRA trafiają do plików technicznych, nie do Deklaracji stosowalności SZBI.

Następne kroki

Co zrobić w najbliższym kwartale

  1. Przeprowadzić analizę luk kontroli Załącznika A SZBI względem Załącznika I CRA. Zacząć od A.8.8, A.8.25-28 i A.5.19-22. To one niosą większość ciężaru.
  2. Sklasyfikować każdy produkt zgodnie z Załącznikami III i IV. Ścieżka oceny zgodności zależy od tego, nie od statusu certyfikatu ISO 27001.
  3. Rozszerzyć deklarację zakresu SZBI o bezpieczeństwo produktu. Zaktualizować Deklarację stosowalności tak, aby obowiązki produktowe były widoczne dla audytorów.
  4. Dodać generowanie SBOM (Załącznik I, Część II(1)) do procesu zarządzania zmianami. CycloneDX lub SPDX, maszynowo czytelny, powiązany z każdym wydaniem.
  5. Utworzyć lub zaktualizować procedurę zgłaszania do CSIRT zgodnie z Artykułem 14: wczesne ostrzeżenie w 24 h, powiadomienie wstępne w 72 h, raport końcowy w 14 dni lub 1 miesiąc w zależności od typu incydentu. Zobacz przewodnik po Single Reporting Platform.
  6. Przydzielić właściciela bezpieczeństwa produktu i właściciela polityki CVD (Załącznik I, Część II(5) i (6)). To nie może być ten sam niejasny slot „zespołu bezpieczeństwa".
  7. Zaplanować połączony audyt wewnętrzny obejmujący zarówno nadzór ISO 27001, jak i gotowość pliku technicznego CRA. Ponownie wykorzystać dowody tam, gdzie to możliwe.

Ten artykuł ma charakter wyłącznie informacyjny i nie stanowi porady prawnej. W celu uzyskania szczegółowych wytycznych dotyczących zgodności należy skonsultować się z wykwalifikowanym prawnikiem.

CRA Standardy Bezpieczeństwa Zgodność
Share

Czy CRA dotyczy Twojego produktu?

Odpowiedz na 6 prostych pytań, aby dowiedzieć się, czy Twój produkt podlega pod Cyber Resilience Act UE. Uzyskaj wynik w mniej niż 2 minuty.

Gotowy na osiągnięcie zgodności z CRA?

Zacznij zarządzać swoimi SBOM-ami i dokumentacją zgodności z CRA Evidence.