Cyber Resilience Act · 2026/2027
Dokumentacja techniczna CRA: zbuduj ją wokół produktu i jego wersji
Materiał informacyjny. Nie zastępuje indywidualnej porady prawnej ani oceny zgodności.
Dokumentacja techniczna CRA nie jest dokumentem tworzonym raz na potrzeby audytu. Zgodnie z art. 31 powinna powstać przed wprowadzeniem produktu z elementami cyfrowymi na rynek i być odpowiednio aktualizowana co najmniej przez okres wsparcia.
Jeżeli trzeba odtwarzać architekturę, decyzje i wyniki testów z poczty, ticketów i pamięci zespołu, problemem nie jest brak szablonu. Problemem jest brak utrzymywanego modelu produktu i dowodów.
Co obejmuje załącznik VII CRA
Zakres zależy od produktu, ale załącznik VII wskazuje co najmniej następujące grupy informacji:
1. Ogólny opis produktu
W tym m.in. przeznaczenie produktu, wersje oprogramowania wpływające na zgodność z wymaganiami cyberbezpieczeństwa oraz informacje i instrukcje dla użytkownika.
2. Projekt, rozwój, produkcja i obsługa podatności
Dokumentacja powinna zawierać informacje potrzebne do zrozumienia projektu i architektury, relacji między komponentami oraz procesów obsługi podatności.
CRA wskazuje tu m.in. SBOM, politykę coordinated vulnerability disclosure, dowód zapewnienia adresu kontaktowego do zgłaszania podatności oraz opis bezpiecznej dystrybucji aktualizacji.
3. Ocena ryzyka cyberbezpieczeństwa
Ocena ma pokazywać, wobec jakich ryzyk produkt został zaprojektowany, rozwinięty, wyprodukowany, dostarczony i utrzymywany oraz jak odnoszą się do niego zasadnicze wymagania z załącznika I.
4. Podstawa określenia okresu wsparcia
Nie tylko data końca. Trzeba utrzymać informacje, które producent brał pod uwagę przy jej ustalaniu.
5. Zastosowane standardy i rozwiązania techniczne
Jeżeli stosowane są normy zharmonizowane, wspólne specyfikacje lub odpowiednie systemy certyfikacji — dokumentacja identyfikuje, co zastosowano. Jeżeli nie, trzeba opisać rozwiązania przyjęte do spełnienia odpowiednich wymagań.
6. Raporty z testów
Dowody testów produktu i procesów obsługi podatności w zakresie właściwych wymagań.
7. Deklaracja zgodności UE
Kopia deklaracji zgodności właściwej dla produktu.
8. SBOM — gdy jest wymagany do kontroli przez organ
Załącznik VII przewiduje udostępnienie SBOM właściwemu organowi nadzoru rynku na uzasadnione żądanie, gdy jest to potrzebne do sprawdzenia zgodności.
Struktura praktyczna: indeks zamiast jednego wielkiego PDF-a
Najbardziej użyteczny model to indeks dokumentacji powiązany z konkretną wersją produktu.
Przykład:
| Obszar | Obiekt źródłowy | Właściciel | Wersja / data | Dowód przeglądu |
|---|---|---|---|---|
| przeznaczenie produktu | karta produktu | Product Owner | v3.4 | zatwierdzenie |
| architektura | diagram + opis | Engineering | v3.4 | review |
| risk assessment | rejestr ryzyk | Security/Product | v3.4 | decyzje |
| SBOM | artefakt build/release | Engineering | release 3.4.2 | hash / log |
| testy | raporty | QA/Security | release 3.4.2 | wynik |
| CVD | polityka | Security | rev. 5 | approval |
| support period | decyzja | Product/Management | 2026-09 | podstawa |
Dokumentacja może składać się z wielu artefaktów. Ważne, aby było wiadomo, który artefakt dotyczy której wersji i kto potwierdził jego aktualność.
Cztery błędy, które generują koszt
„Mamy politykę, więc temat jest zamknięty”
Polityka opisuje sposób pracy. Nie dowodzi, że konkretna wersja produktu została oceniona i przetestowana.
„Architektura jest w repo, każdy wie gdzie”
Po zmianie zespołu albo po 18 miesiącach „każdy” przestaje być źródłem danych.
„SBOM jest w pipeline”
To dobrze, ale dokumentacja nadal musi wiązać wynik z produktem, wersją i procesem podatności.
„Zrobimy eksport przed audytem”
Jeżeli źródła są niespójne, eksport tylko szybciej pokaże niespójność.
Jak Pulsar GRC może uporządkować dokumentację
Pulsar ma potwierdzone obszary dokumentów, dowodów, ryzyk, kontroli, raportów i historii analiz. Dzięki temu dokumentacja może działać jako sieć powiązań zamiast folderu z finalnymi plikami.
Docelowy zapis powinien odpowiadać na pytania:
- którego produktu i wersji dotyczy artefakt;
- z jakim wymaganiem lub ryzykiem jest związany;
- kto go utworzył i zatwierdził;
- kiedy był aktualny;
- jakie działanie lub decyzję potwierdza;
- co zmieniło się od poprzedniego przeglądu.
Pulsar nie dostarcza treści chronionych norm ani nie zastępuje dokumentacji technicznej tworzonej przez producenta. Pomaga utrzymać jej strukturę i ślad operacyjny.
Zobacz pracę z dokumentami i dowodami w Pulsarze
Powiązane materiały
Źródła
- Rozporządzenie (UE) 2024/2847 — art. 31 i załącznik VII
- Komisja Europejska — wytyczne CRA z 27 lipca 2026 r.
Stan źródeł: 12 września 2026 r.