Dokumentacja techniczna CRA - praktyczny przewodnik

Akt o cyberodporności (CRA) wymaga dokumentacji zgodności dla każdego produktu, który sprzedajesz w UE. Oto, co się w niej znajduje, jak ją uporządkować i co możesz zacząć przygotowywać już dziś.

Czym jest dokumentacja techniczna?

To Twój folder z dowodami: nadrzędny dokument, który potwierdza, że Twój produkt spełnia wymagania cyberbezpieczeństwa CRA. Dokumentację kompletujesz przed wprowadzeniem produktu na rynek UE, przechowujesz przez 10 lat od wprowadzenia produktu do obrotu (lub przez cały okres wsparcia, jeśli jest dłuższy) i przekazujesz organowi nadzoru rynku, jeśli o nią poprosi.

Twierdzisz, że Twój produkt jest bezpieczny. Dokumentacja techniczna jest na to dowodem.

Kto jej potrzebuje?

Każdy producent produktu z elementami cyfrowymi sprzedawanego w UE. Sprzęt, firmware, oprogramowanie, IoT: jeśli produkt łączy się z siecią i sprzedajesz go w Europie, unijne wymagania dotyczące dokumentacji cyberbezpieczeństwa Cię obejmują. Kategoria (domyślna, klasa I, klasa II, krytyczna) decyduje o tym, kto ją sprawdza (Ty czy jednostka notyfikowana), ale sama dokumentacja jest wymagana we wszystkich kategoriach.

Co się w niej znajduje?

Załącznik VII do CRA wymienia 8 wymaganych elementów. Na dzień 4 maja 2026 r. nie ma oficjalnego szablonu. Poniżej wyjaśniamy, co naprawdę oznacza każdy z nich i co musisz przygotować.

1. Opis produktu

Wyjaśnij komuś, kto nigdy nie widział Twojego produktu, czym on jest i co robi.

Uwzględnij:

• Nazwę produktu, model, numery wersji (sprzętu i oprogramowania)
• Do czego służy i dla kogo jest przeznaczony (przewidziane przeznaczenie)
• Zdjęcia lub schematy fizycznego produktu (jeśli to sprzęt)
• Interfejsy sieciowe: Wi-Fi, BLE, Ethernet, sieć komórkowa, USB, port szeregowy (wymień wszystkie)
• Instrukcje dla użytkownika: jak zainstalować, skonfigurować i obsługiwać produkt oraz jak bezpiecznie wycofać go z użytku

Nie komplikuj tego. Przejrzysta karta katalogowa produktu ze schematem architektury sieci pokrywa większość tej sekcji. Jeśli masz już opis produktu dla działu sprzedaży, zacznij od niego.

2. Informacje o projektowaniu i rozwoju

To największa sekcja. Pokazuje, że Twój produkt został zbudowany bezpiecznie nie przypadkiem, tylko dzięki procesowi.

Uwzględnij:

• Diagramy architektury - projekt systemu, interakcje między komponentami, przepływy danych. Gdzie dane wchodzą do systemu? Dokąd trafiają? Gdzie są szyfrowane, a gdzie nie? Ważne: jeśli Twój produkt zależy od backendu w chmurze, który zaprojektowała Twoja firma albo ktoś na Twoje zlecenie, ten backend wchodzi w zakres produktu w rozumieniu CRA. Nazywa się to rozwiązaniem w zakresie zdalnego przetwarzania danych (Remote Data Processing Solution, RDPS) i musi zostać uwzględnione w architekturze, w ocenie ryzyka i w dokumentacji technicznej.
• Opis SDLC - jak Twój zespół tworzy oprogramowanie. Jeśli stosujesz IEC 62443-4-1 lub podobne ramy, powołaj się na nie tutaj. Modelowanie zagrożeń, standardy bezpiecznego kodowania, proces code review, testy bezpieczeństwa przed wydaniem.
• Proces obsługi podatności - jak przyjmujesz, klasyfikujesz, naprawiasz i komunikujesz podatności. Kto za to odpowiada? Jakie jest SLA?
• Polityka skoordynowanego ujawniania podatności - publiczny dokument, który mówi badaczom bezpieczeństwa, jak zgłaszać błędy. Plik `security.txt` (RFC 9116), strona z kontaktem w sprawach bezpieczeństwa, czas reakcji i deklaracja bezpiecznej przystani (safe harbor): „nie pozwiemy Cię za odpowiedzialne zgłoszenie”.
• SBOM - zestawienie komponentów oprogramowania (Software Bill of Materials) w formacie nadającym się do odczytu maszynowego (CycloneDX lub SPDX). Co najmniej: zależności najwyższego poziomu z nazwami, wersjami i dostawcami.
• Bezpieczna dystrybucja aktualizacji - jak dostarczasz aktualizacje firmware’u i oprogramowania. Czy są podpisane? Szyfrowane? Jakim kanałem? Jak urządzenie weryfikuje ich autentyczność?

Jeśli stosujesz IEC 62443-4-1, większość tej sekcji powstaje niemal sama. 8 praktyk tej normy daje dokładnie te artefakty. Jeśli nie stosujesz formalnych ram, nadal potrzebujesz tych artefaktów, tyle że własny proces musisz udokumentować samodzielnie.

3. Ocena ryzyka

Ocena ryzyka cyberbezpieczeństwa Twojego konkretnego produktu. Nie Twojej firmy ani sieci biurowej, tylko samego produktu.

Co obejmuje:

• Zasoby - co warto chronić? Firmware, dane użytkownika, dane uwierzytelniające, kanały komunikacji, fizyczną integralność urządzenia.
• Powierzchnia ataku - każdy interfejs i punkt wejścia. Wi-Fi, BLE, UART, JTAG, porty debugowania, API w chmurze, kanał OTA, dostęp fizyczny. Dla każdego z nich: kto może do niego dotrzeć i czy jest dostępny w wersji produkcyjnej?
• Zagrożenia - co atakujący może zrobić przez dany interfejs? Dobrze sprawdza się tu STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege).
• Prawdopodobieństwo i skutki - na ile prawdopodobne jest każde zagrożenie? Jakie szkody może wyrządzić? Wystarczy prosta macierz niskie/średnie/wysokie.
• Środki zaradcze - co jest wdrożone, aby przeciwdziałać każdemu zagrożeniu? TLS, podpisane aktualizacje, uwierzytelnianie każdego urządzenia, wyłączone porty debugowania itd.
• Ryzyko szczątkowe - co zostaje po wdrożeniu środków zaradczych? Czy jest akceptowalne?
• Mapowanie na załącznik I - przypisz każde zasadnicze wymaganie CRA do swoich środków zaradczych. To pomost między „oceniliśmy ryzyko” a „spełniamy wymagania rozporządzenia”.

Ocena ryzyka to proces ciągły: trzeba ją aktualizować przez cały okres wsparcia, gdy wykryte zostaną nowe podatności, gdy produkt zostanie zaktualizowany, gdy pojawią się nowe zagrożenia albo w regularnych odstępach czasu. Przygotuj ją w formacie, który Twój zespół faktycznie będzie utrzymywał przez lata: arkusz kalkulacyjny, dokument Markdown, wynik z narzędzia do modelowania zagrożeń. Kluczowa jest identyfikowalność: każde wymaganie z załącznika I powinno wskazywać na środek zaradczy, a każdy środek zaradczy na dowód.

Nie zapominaj o przewidywalnym użyciu: CRA wymaga oceny ryzyka nie tylko dla przewidzianego przeznaczenia, ale też dla „racjonalnie przewidywalnego użycia”, czyli takich sposobów korzystania z Twojego produktu, które da się przewidzieć, choć produkt nie był z myślą o nich projektowany. Monitor baterii podłączony do sieci z dostępem do internetu. Narzędzie diagnostyczne podłączone do laptopa ze zdalnym pulpitem. Jeśli da się to przewidzieć, wchodzi to w zakres.

Dzielenie ryzyka z dostawcami i użytkownikami: nie musisz samodzielnie ograniczać każdego ryzyka. Jeśli Twój produkt korzysta z modułu innego producenta (modem komórkowy, układ Wi-Fi), możesz podzielić ryzyko z dostawcą, ale tylko wtedy, gdy jest do tego zobowiązany prawnie (sam podlega CRA i spełnia jego wymagania) albo umownie zobowiązał się do obsługi swojej części. Możesz też dzielić ryzyko z użytkownikami, dając im jasne wskazówki, ale tylko w granicach ich rozsądnych oczekiwań. „Skonfiguruj zaporę samodzielnie” jest do przyjęcia w przypadku profesjonalnego integratora, ale nie konsumenta.

4. Uzasadnienie okresu wsparcia

Musisz zadeklarować, jak długo będziesz dostarczać aktualizacje zabezpieczeń. CRA mówi: co najmniej 5 lat lub przewidywany okres użytkowania produktu, w zależności od tego, który jest krótszy.

Uwzględnij:

• Zadeklarowany okres wsparcia i datę jego zakończenia
• Jak ustalono przewidywany okres użytkowania produktu (dane branżowe, żywotność komponentów, umowy z klientami)
• Jak będziesz dostarczać aktualizacje zabezpieczeń przez cały ten czas (OTA, ręczne pobieranie, powiadomienie dystrybutora)
• Gdzie te informacje są opublikowane (strona produktu, karta katalogowa, punkt sprzedaży)

Okres wsparcia i okres przechowywania dokumentacji to dwie różne rzeczy. Okres wsparcia (co najmniej 5 lat) to czas, przez który dostarczasz aktualizacje zabezpieczeń. Okres przechowywania dokumentacji (10 lat od wprowadzenia do obrotu lub cały okres wsparcia, jeśli jest dłuższy) to czas, przez który przechowujesz dokumentację techniczną. Produkt z 7-letnim okresem wsparcia oznacza 10 lat przechowywania dokumentacji.

W przypadku produktów przemysłowych - czujnik w hali fabrycznej może działać 15 lat i dłużej. Nie musisz wspierać go przez 15 lat, ale musisz uzasadnić, dlaczego zadeklarowany przez Ciebie okres jest odpowiedni. „Nasze komponenty mają przewidywaną żywotność 7 lat, dlatego zobowiązujemy się do 7 lat aktualizacji zabezpieczeń” to stanowisko, którego da się bronić.

5. Zastosowane normy

Które normy zastosowano i czy mają moc prawną?

Jeśli stosujesz normy zharmonizowane (na dzień 4 maja 2026 r. wciąż są w opracowaniu):

• Podaj numer normy, wersję i odniesienie do publikacji w Dzienniku Urzędowym UE
• Daje Ci to domniemanie zgodności, czyli prawny skrót: „stosowanie tej normy oznacza, że spełniasz wymagania CRA, które ona obejmuje”

Jeśli normy zharmonizowane nie są jeszcze dostępne (a tak jest obecnie: trwają prace nad 41 normami przeznaczonymi dla CRA):

• Wymień normy, które mimo to stosujesz (IEC 62443, EN 303 645, ISO 27001 itd.)
• Powołaj się na wspólne specyfikacje publikowane przez Komisję Europejską (ten mechanizm nie został jeszcze uruchomiony)
• Powołaj się na europejskie certyfikaty cyberbezpieczeństwa, takie jak EUCC (unijny program certyfikacji oparty na Common Criteria), w przypadku kategorii krytycznej
• Udokumentuj, jak te normy odpowiadają wymaganiom z załącznika I do CRA. Punktem odniesienia jest tu dokument ENISA/JRC „CRA Requirements Standards Mapping”

Praktyczna rzeczywistość na dziś: nikt nie ma jeszcze pełnego domniemania zgodności, bo normy zharmonizowane nie zostały opublikowane. Udokumentuj, co stosujesz, przypisz to do wymagań CRA i zaktualizuj tę sekcję, gdy normy zostaną oficjalnie wpisane na listę. Nikt nie ukarze Cię za stosowanie najlepszych dostępnych norm, zanim pojawią się oficjalne.

6. Raporty z testów

Dowody, że produkt spełnia zasadnicze wymagania cyberbezpieczeństwa. Nie deklaracje, tylko dowody.

Co się liczy:

• Raporty z analizy statycznej - wyniki z Coverity, Cppcheck, SonarQube lub CodeChecker pokazujące, że kod został przeskanowany, a znalezione problemy usunięte
• Wyniki skanowania zależności i podatności - wyniki Trivy, Grype lub OSV-Scanner dla Twojego SBOM, pokazujące brak znanych krytycznych CVE w momencie wydania
• Funkcjonalne testy bezpieczeństwa - „Sprawdziliśmy, że uwierzytelnianie działa, niepodpisany firmware jest odrzucany, nie ma haseł domyślnych, a porty debugowania są wyłączone”
• Wyniki testów penetracyjnych - niezależne testy interfejsów Twojego produktu. Znalezione problemy i dowody ich usunięcia
• Testy fuzzingowe - testy parserów danych wejściowych z metrykami pokrycia
• Kluczowa jest identyfikowalność. Tabela, która łączy każde wymaganie z załącznika I z konkretnym testem:

Wymaganie z załącznika I	ID testu	Metoda	Wynik	Dowód
Brak haseł domyślnych	FT-001	Test funkcjonalny	Pozytywny	test-reports/FT-001.pdf
Bezpieczny mechanizm aktualizacji	PT-003	Test penetracyjny	Pozytywny (po poprawce)	test-reports/PT-003.pdf
Szyfrowanie danych w transmisji	NET-007	Analiza przechwyconego ruchu	Pozytywny	test-reports/NET-007.pdf
Zminimalizowana powierzchnia ataku	CFG-002	Skan portów + przegląd konfiguracji	Pozytywny	test-reports/CFG-002.pdf

„Zaprojektowaliśmy to bezpiecznie” to deklaracja. Ta tabela wraz z załączonymi raportami to dowód.

7. Deklaracja zgodności UE

Formalny dokument, w którym Ty jako producent oświadczasz, że Twój produkt spełnia wymagania CRA. Format deklaracji określa załącznik V i to jedna z niewielu rzeczy, które CRA faktycznie narzuca.

Wymagane pola:

• Nazwa produktu, typ i niepowtarzalna identyfikacja (numer modelu, zakres numerów seryjnych itp.)
• Nazwa i adres Twojej firmy (lub Twojego upoważnionego przedstawiciela w UE)
• Oświadczenie: „Niniejszą deklarację zgodności wydaje się na wyłączną odpowiedzialność producenta”
• Identyfikacja produktu umożliwiająca jego identyfikowalność (może obejmować zdjęcie)
• Odniesienia do zastosowanych norm zharmonizowanych lub specyfikacji
• Jeśli ocenę przeprowadziła strona trzecia: nazwa i numer jednostki notyfikowanej oraz identyfikator certyfikatu
• Data, miejsce i podpis osoby odpowiedzialnej

Jedna strona. Podpisz ją, dołącz do dokumentacji technicznej i zachowaj kopię razem z dokumentacją produktu. Jeśli sprzedajesz kilka produktów, każdy dostaje własną deklarację. Jedna deklaracja może obejmować kilka unijnych regulacji, jeśli produkt podlega więcej niż jednej (np. CRA + dyrektywa w sprawie urządzeń radiowych).

Uwaga o samoocenie: nawet gdy ocenę zgodności przeprowadzasz samodzielnie (kategoria domyślna i klasa I z normami zharmonizowanymi), osoba, która ją przeprowadza, powinna być bezstronna, najlepiej nie ten sam programista, który zbudował daną funkcję. Członek wewnętrznego zespołu bezpieczeństwa, inżynier QA albo zewnętrzny konsultant. Chodzi o rzetelną ocenę, a nie o przybicie pieczątki.

8. SBOM (dla organów)

SBOM pojawia się w dokumentacji dwa razy. Raz w sekcji 2 (jako część dokumentacji projektowej) i drugi raz tutaj, specjalnie dla organów nadzoru rynku, które mogą o niego poprosić.

Wymagania:

• Format nadający się do odczytu maszynowego: CycloneDX v1.6+ lub SPDX v3.0.1+ (zalecenie BSI TR-03183-2)
• Co najmniej: zależności najwyższego poziomu, czyli nazwa komponentu, wersja, dostawca
• Generowany przy każdym buildzie, a nie jednorazowo
• Aktualizowany przy każdym wydaniu

Nie musisz publikować SBOM publicznie. Musi być dostępny dla organów nadzoru rynku na żądanie. Ale generowanie go przy każdym buildzie i skanowanie pod kątem CVE to Twoja własna operacyjna konieczność: właśnie w ten sposób spełniasz obowiązek ciągłego monitorowania podatności.

Struktura folderów

Nie ma oficjalnego formatu, ale przejrzysta struktura pomaga, zwłaszcza gdy organ poprosi o dokumentację.

technical-file
├── 01-product-description
│   ├── product-brief.pdf
│   ├── network-architecture.pdf
│   └── user-instructions.pdf
├── 02-design-and-development
│   ├── architecture-diagrams
│   ├── sdlc-process.pdf
│   ├── vulnerability-handling-policy.pdf
│   ├── vulnerability-disclosure-policy.pdf
│   ├── update-distribution.pdf
│   └── sbom/
│       └── product-v1.2.3.cdx.json
├── 03-risk-assessment
│   ├── risk-assessment.pdf
│   └── annex-i-traceability-matrix.pdf
├── 04-support-period
│   └── support-period-justification.pdf
├── 05-standards-applied
│   └── standards-mapping.pdf
├── 06-test-reports
│   ├── static-analysis
│   ├── dependency-scan
│   ├── functional-security-tests
│   ├── penetration-test
│   └── traceability-matrix.pdf
├── 07-declaration-of-conformity
│   └── eu-declaration-of-conformity.pdf
└── 08-sbom
     └── product-v1.2.3.cdx.json

Wersjonuj wszystko. Gdy wydajesz nową wersję produktu, dokumentacja techniczna też dostaje nową wersję. Zachowuj stare wersje: zasady przechowywania dotyczą każdej z nich.

Uwaga o terminach zgłoszeń. Dokumentacja techniczna powinna zawierać Twoje procedury zgłaszania, a warto wiedzieć, że terminy się różnią:

Aktywnie wykorzystywane podatności: wczesne ostrzeżenie w ciągu 24 h, szczegółowe zgłoszenie w ciągu 72 h, 14 dni na raport końcowy.

Poważne incydenty: wczesne ostrzeżenie w ciągu 24 h, szczegółowe zgłoszenie w ciągu 72 h, 1 miesiąc na raport końcowy.

Oba rodzaje zgłoszeń trafiają do Twojego CSIRT i do ENISA za pośrednictwem jednolitej platformy zgłoszeń. Ten obowiązek zaczyna obowiązywać we wrześniu 2026 r., czyli przed terminem pełnej zgodności z CRA.

Co możesz zacząć już dziś

Nie musisz czekać na normy zharmonizowane ani oficjalne szablony. Większość tej dokumentacji powstaje z artefaktów, które Twój zespół inżynierski powinien już tworzyć albo może zacząć tworzyć od teraz.

Szybkie wygrane (dni, nie tygodnie):

• Napisz plik `security.txt` i umieść go na swojej stronie
• Wygeneruj SBOM w swoim systemie buildów (Syft, CycloneDX CLI)
• Przeskanuj na jego podstawie zależności (Trivy, Grype)
• Udokumentuj swoje zobowiązanie dotyczące okresu wsparcia

Średni nakład pracy (tygodnie):

• Przeprowadź ocenę ryzyka produktu metodą STRIDE
• Skonfiguruj analizę statyczną w CI (Cppcheck, CodeChecker)
• Udokumentuj swój SDLC: prawdopodobnie masz już proces, tylko nikt go jeszcze nie spisał

Większy nakład pracy (miesiące):

• Wdróż podpisywanie i weryfikację firmware’u, jeśli ich jeszcze nie masz
• Wprowadź tożsamość dla każdego urządzenia i zarządzanie danymi uwierzytelniającymi
• Zleć test penetracyjny
• Zbuduj kompletną macierz identyfikowalności

Zacznij od szybkich wygranych. Każda z nich wypełnia jedną sekcję dokumentacji technicznej. Zanim dojdziesz do większych zadań, połowa dokumentacji będzie gotowa.

Najważniejsze

Dokumentacja techniczna CRA brzmi groźnie. Wcale taka nie jest. To uporządkowany zbiór rzeczy, które Twoja firma powinna już mieć: dokumentacji architektury, wyników testów, SBOM, polityki bezpieczeństwa. CRA mówi po prostu: zbierz je w jednym miejscu, przechowuj przez 10 lat i miej je gotowe do pokazania.

Najtrudniejsza nie jest dokumentacja. Najtrudniej jest mieć coś, co warto udokumentować. Jeśli Twój produkt jest bezpieczny już na etapie projektowania, dokumentacja techniczna powstaje niemal sama. Jeśli nie jest, dokumentacja to najmniejszy z Twoich problemów.

Dalsza lektura

• Jakich wymagań CRA nie obejmuje żadna norma?
• Co trzeba zrobić, aby spełnić wymagania CRA
• Jak określić kategorię produktu w CRA?