Dokumentacja Techniczna CRA: Co Zawiera Każda Sekcja (Szczegółowy Przegląd Załącznika VII)

Dokumentacja techniczna jest twoim pakietem dowodów dla zgodności z CRA. Organy nadzoru rynku będą jej żądać. Jednostki Notyfikowane będą ją badać. Bez kompletnej dokumentacji technicznej nie możesz legalnie wprowadzić swojego produktu na rynek UE.

Ten przewodnik rozkłada Załącznik VII sekcja po sekcji, wyjaśniając czego każda wymaga i jak ją przygotować.

Czym jest dokumentacja techniczna CRA?

Dokumentacja techniczna (zwana też "dokumentacją techniczną") jest kompletnym pakietem dowodów demonstrujących zgodność twojego produktu z wymaganiami CRA.

To nie jest:

• Dokumentacja marketingowa
• Tylko instrukcje użytkownika
• Ćwiczenie odhaczania

To jest:

• Kompleksowe dowody techniczne
• Żywa dokumentacja (aktualizowana przez cały cykl życia produktu)
• Twoja obrona w dochodzeniach nadzoru rynku
• Wymagana dla oceny zgodności

Przegląd Struktury Załącznika VII

Załącznik VII CRA określa wymagania dokumentacji technicznej:

STRUKTURA DOKUMENTACJI TECHNICZNEJ (Załącznik VII)

1. OPIS OGÓLNY
   └── Identyfikacja produktu i zamierzony cel

2. PROJEKTOWANIE I ROZWÓJ
   └── Jak wbudowano bezpieczeństwo

3. OCENA RYZYKA CYBERBEZPIECZEŃSTWA
   └── Zidentyfikowane i rozwiązane ryzyka

4. WYMAGANIA ZASADNICZE
   └── Jak spełnione są wymagania Załącznika I

5. ZASTOSOWANE NORMY
   └── Użyte normy i odstępstwa

6. ZESTAWIENIE MATERIAŁÓW OPROGRAMOWANIA
   └── Komponenty i zależności

7. WYNIKI TESTÓW
   └── Dowody weryfikacji

8. DEKLARACJA ZGODNOŚCI UE
   └── Lub jej kopia

9. OBSŁUGA PODATNOŚCI
   └── Procesy bezpieczeństwa post-market

Sekcja 1: Opis Ogólny

Cel: Ustalić czym jest produkt i do czego służy.

Wymagana Zawartość

LISTA KONTROLNA OPISU OGÓLNEGO

Identyfikacja Produktu:
[ ] Nazwa i numer modelu produktu
[ ] Wersja(e) sprzętowa
[ ] Wersja(e) oprogramowania/firmware
[ ] Format lub zakres numerów seryjnych
[ ] Unikalny identyfikator produktu

Zamierzony Cel:
[ ] Opis głównej funkcji
[ ] Docelowi użytkownicy/środowisko
[ ] Zamierzone przypadki użycia
[ ] Niezamierzone zastosowania (wykluczenia)

Kategoria Produktu:
[ ] Klasyfikacja CRA (Domyślna/Ważna/Krytyczna)
[ ] Uzasadnienie klasyfikacji
[ ] Powiązane przepisy produktowe (jeśli są)

Informacje Rynkowe:
[ ] Data pierwszego wprowadzenia na rynek UE
[ ] Docelowe państwa członkowskie
[ ] Kanały dystrybucji

Przykład

OPIS OGÓLNY

Nazwa Produktu: SmartSense Pro Czujnik Przemysłowy
Numer Modelu: SSP-3000
Wersja Sprzętowa: Rev C (PCB v3.2)
Wersja Firmware: 2.4.1

ZAMIERZONY CEL:
SmartSense Pro to przemysłowy czujnik środowiskowy
zaprojektowany do monitorowania obiektów produkcyjnych.
Mierzy temperaturę, wilgotność i jakość powietrza, transmitując
dane przez WiFi do chmury lub lokalnych serwerów.

DOCELOWI UŻYTKOWNICY:
- Kierownicy obiektów
- Integratorzy automatyki przemysłowej
- Oficerowie ds. zgodności środowiskowej

ZAMIERZONE ŚRODOWISKO:
- Wewnętrzne obiekty przemysłowe
- Temperatura pracy: -10°C do +60°C
- Sieć: WiFi 802.11 b/g/n

NIE PRZEZNACZONY DO:
- Zastosowań medycznych lub bezpieczeństwa życia
- Instalacji zewnętrznej
- Atmosfer wybuchowych
- Użytku konsumenckiego/domowego

KLASYFIKACJA CRA:
Produkt domyślny. Nie wymieniony w Załączniku III lub IV.
Uzasadnienie: Czujnik ogólnego przeznaczenia bez funkcji
bezpieczeństwa ani zastosowania infrastruktury krytycznej.

WPROWADZENIE NA RYNEK UE:
Pierwsze wprowadzenie na rynek: 15 marca 2027
Rynki docelowe: Wszystkie państwa członkowskie UE
Dystrybucja: Sprzedaż bezpośrednia i autoryzowani dystrybutorzy

Sekcja 2: Projektowanie i Rozwój

Cel: Udokumentować jak bezpieczeństwo zostało wbudowane w projekt produktu.

Wymagana Zawartość

LISTA KONTROLNA DOKUMENTACJI PROJEKTOWEJ

Architektura:
[ ] Diagram architektury systemu
[ ] Diagram interakcji komponentów
[ ] Diagram przepływu danych
[ ] Zidentyfikowane granice zaufania

Projekt Bezpieczeństwa:
[ ] Opis architektury bezpieczeństwa
[ ] Implementacje kryptograficzne
[ ] Mechanizmy uwierzytelniania
[ ] Model autoryzacji
[ ] Protokoły bezpiecznej komunikacji
[ ] Środki ochrony danych

Proces Rozwoju:
[ ] Opis bezpiecznego cyklu rozwoju
[ ] Śledzenie wymagań bezpieczeństwa
[ ] Procedury przeglądu kodu
[ ] Testy bezpieczeństwa w rozwoju
[ ] Zarządzanie konfiguracją

Zarządzanie Zmianami:
[ ] Procedury kontroli wersji
[ ] Ocena wpływu zmian
[ ] Przegląd bezpieczeństwa dla zmian

Sekcja 3: Ocena Ryzyka Cyberbezpieczeństwa

Cel: Udokumentować zidentyfikowane ryzyka i jak są rozwiązywane.

Format Oceny Ryzyka

OCENA RYZYKA CYBERBEZPIECZEŃSTWA

Produkt: SmartSense Pro (SSP-3000)
Wersja: 2.4.1
Data Oceny: Styczeń 2027
Oceniający: [Imię, Zespół Bezpieczeństwa]

METODOLOGIA:
Oparta na ISO 27005 dostosowanej do bezpieczeństwa produktu.
Ryzyko = Prawdopodobieństwo × Wpływ
Skala: Niskie (1-4), Średnie (5-9), Wysokie (10-16), Krytyczne (17-25)

─────────────────────────────────────────────────────────────
ID RYZYKA: R-001
ZAGROŻENIE: Nieautoryzowana modyfikacja firmware
PODATNOŚĆ: Niepodpisany firmware mógłby być zainstalowany
WPŁYW: Wysoki (5) - Kompromitacja urządzenia, wyciek danych
PRAWDOPODOBIEŃSTWO: Średnie (3) - Wymaga dostępu fizycznego
RYZYKO INHERENTNE: 15 (Wysokie)

KONTROLA: Weryfikacja podpisu firmware
IMPLEMENTACJA: Podpis ECDSA P-256 weryfikowany przed instalacją
RYZYKO REZYDUALNE: 3 (Niskie) - Atak kryptograficzny mało prawdopodobny

STATUS: Zmitigowane
─────────────────────────────────────────────────────────────

PODSUMOWANIE RYZYK:
Łącznie zidentyfikowanych ryzyk: 23
Krytyczne: 0
Wysokie: 3 (wszystkie zmitigowane do Niskie/Średnie)
Średnie: 8 (wszystkie zmitigowane do Niskie)
Niskie: 12 (zaakceptowane lub zmitigowane)

AKCEPTACJA RYZYKA REZYDUALNEGO:
Wszystkie ryzyka rezydualne są w akceptowalnej tolerancji.
Podpisano: [Lider Bezpieczeństwa], [Data]

Sekcja 4: Mapowanie Wymagań Zasadniczych

Cel: Wykazać jak każde wymaganie Załącznika I jest spełnione.

Wymagania Załącznika I, Część I

MATRYCA ZGODNOŚCI WYMAGAŃ ZASADNICZYCH

ZAŁĄCZNIK I, CZĘŚĆ I - WYMAGANIA BEZPIECZEŃSTWA
═══════════════════════════════════════════════════════════

1. ZAPROJEKTOWANY BEZ ZNANYCH WYKORZYSTYWALNYCH PODATNOŚCI
   Status: ZGODNY
   Dowody:
   - Raport skanowania podatności (Trivy): 0 krytycznych/wysokich
   - Analiza zależności: Wszystkie komponenty w najnowszych bezpiecznych wersjach
   - Raport testu penetracyjnego: Nie znaleziono wykorzystywalnych podatności
   Odniesienie: Raport Testowy TR-2027-001, strony 15-23

2. BEZPIECZNA KONFIGURACJA DOMYŚLNA
   Status: ZGODNY
   Dowody:
   - Dokument przeglądu konfiguracji domyślnej
   - Brak domyślnych haseł (unikalne poświadczenia wymagane przy setup)
   - Niepotrzebne usługi domyślnie wyłączone
   - Bezpieczne protokoły domyślnie włączone (TLS, nie HTTP)
   Odniesienie: Dokument Projektowy DD-004, Sekcja 3.2

[Kontynuuj dla wszystkich wymagań Załącznika I...]

Sekcja 5: Zastosowane Normy

Cel: Udokumentować jakie normy zostały użyte i jak.

Format Dokumentacji Norm

ZASTOSOWANE NORMY

NORMY ZHARMONIZOWANE (domniemanie zgodności):
─────────────────────────────────────────────────────────────
Norma: EN 303 645 (gdy zharmonizowana dla CRA)
Tytuł: Cyberbezpieczeństwo dla IoT Konsumenckiego
Status: Zastosowana w całości
Publikacja: Dz.U. UE [odniesienie gdy opublikowana]
Dowody: Raport Zgodności z Normami SCR-001
─────────────────────────────────────────────────────────────

INNE ZASTOSOWANE NORMY:
─────────────────────────────────────────────────────────────
Norma: IEC 62443-4-1:2018
Tytuł: Bezpieczeństwo Automatyki Przemysłowej - Bezpieczny Rozwój
Status: Zastosowana (wybrane wymagania)
Zastosowane Klauzule: 5, 6, 7, 8, 10
Dowody: Dokumentacja SDL SLD-001
─────────────────────────────────────────────────────────────

ODSTĘPSTWA:
─────────────────────────────────────────────────────────────
Norma: EN 303 645
Klauzula: 5.3-2 (Unikalne poświadczenia na urządzenie)
Odstępstwo: Poświadczenia unikalne na urządzenie ale nie pre-provisioned
Uzasadnienie: Urządzenie wymaga setup użytkownika; poświadczenia
             tworzone podczas pierwszej konfiguracji
Alternatywny Środek: Wymagania silnego hasła egzekwowane,
                    blokada konta po nieudanych próbach
Ocena Ryzyka: Ryzyko rezydualne akceptowalne (zobacz R-015)
─────────────────────────────────────────────────────────────

Sekcja 6: Zestawienie Materiałów Oprogramowania

Cel: Zapewnić przejrzystość komponentów dla śledzenia podatności.

Dokumentacja SBOM

ZESTAWIENIE MATERIAŁÓW OPROGRAMOWANIA

Produkt: SmartSense Pro (SSP-3000)
Wersja Firmware: 2.4.1
Format SBOM: CycloneDX 1.5
Wygenerowany: 2027-01-15
Narzędzie: Trivy + syft

PLIK SBOM:
sbom-ssp3000-v2.4.1.json (załączony)

PODSUMOWANIE KOMPONENTÓW:
─────────────────────────────────────────────────────────────
Łącznie Komponentów: 127
  Zależności Bezpośrednie: 23
  Zależności Przechodnie: 104

Według Typu:
  Biblioteki: 98
  Frameworki: 12
  System Operacyjny: 1 (FreeRTOS)
  Moduły Firmware: 16

Według Licencji:
  MIT: 45
  Apache 2.0: 38
  BSD: 15
  LGPL: 8
  Własnościowe: 21 (komponenty wewnętrzne)
─────────────────────────────────────────────────────────────

STATUS PODATNOŚCI PRZY OCENIE:
─────────────────────────────────────────────────────────────
Data Skanowania: 2027-01-15
Skaner: Trivy v0.48.0

Krytyczne: 0
Wysokie: 0
Średnie: 2 (zaakceptowane - zobacz poniżej)
Niskie: 5 (zaakceptowane)

ZAAKCEPTOWANE PODATNOŚCI:
CVE-2026-XXXXX (Średnie): Komponent xyz v1.2.3
  Status: Nie wykorzystywalne w naszej konfiguracji
  Uzasadnienie: Funkcjonalność nie włączona, ścieżka kodu nieosiągalna
  Data Przeglądu: 2027-04-15
─────────────────────────────────────────────────────────────

ZOBOWIĄZANIE AKTUALIZACJI SBOM:
SBOM będzie aktualizowany z każdym wydaniem firmware i udostępniany
klientom na żądanie.

Sekcja 7: Wyniki Testów

Cel: Zapewnić dowody że wymagania są faktycznie spełnione.

Format Wyników Testów

PODSUMOWANIE WYNIKÓW TESTÓW

Produkt: SmartSense Pro (SSP-3000) v2.4.1
Okres Testów: Grudzień 2026 - Styczeń 2027
Lider Testów: [Imię]

═══════════════════════════════════════════════════════════
KAMPANIA TESTOWA: TC-2027-001
═══════════════════════════════════════════════════════════

1. TESTY FUNKCJONALNE BEZPIECZEŃSTWA
   Zakres: Uwierzytelnianie, autoryzacja, szyfrowanie, bezpieczny rozruch
   Przypadki Testowe: 85
   Zaliczone: 85
   Niezaliczone: 0
   Odniesienie: Raport Testowy TR-FUNC-001

2. SKANOWANIE PODATNOŚCI
   Narzędzie: Trivy v0.48.0 + Nessus Professional
   Zakres: Firmware, usługi sieciowe, interfejs webowy
   Wyniki:
     Krytyczne: 0
     Wysokie: 0
     Średnie: 2 (zaakceptowane z uzasadnieniem)
     Niskie: 5 (zaakceptowane)
   Odniesienie: Raport Skanowania SR-VULN-001

3. TESTY PENETRACYJNE
   Dostawca: [Nazwa firmy zewnętrznej]
   Zakres: Test black-box wdrożonego urządzenia
   Czas trwania: 5 dni
   Wyniki:
     Krytyczne: 0
     Wysokie: 0
     Średnie: 1 (naprawione przed wydaniem)
     Niskie: 3 (zaakceptowane)
   Odniesienie: Raport Pentest PT-2027-001

═══════════════════════════════════════════════════════════
OGÓLNA OCENA: ZALICZONE
Wszystkie wyniki krytyczne i wysokie naprawione.
Wyniki Średnie/Niskie zaakceptowane z udokumentowanym uzasadnieniem.
═══════════════════════════════════════════════════════════

Sekcja 9: Procedury Obsługi Podatności

Cel: Udokumentować procesy bezpieczeństwa post-market.

Dokumentacja Obsługi Podatności

PROCEDURY OBSŁUGI PODATNOŚCI

1. METODY KONTAKTU
   Główny: security@firma.com
   Formularz Web: https://firma.com/bezpieczenstwo/zglos
   security.txt: https://firma.com/.well-known/security.txt
   Polityka CVD: https://firma.com/bezpieczenstwo/polityka-ujawniania

2. ZOBOWIĄZANIA CZASOWE
   Potwierdzenie: W ciągu 3 dni roboczych
   Wstępna Ocena: W ciągu 10 dni roboczych
   Aktualizacje Statusu: Co 14 dni
   Cel Rozwiązania: 90 dni (krytyczne: 7 dni)

3. RAPORTOWANIE ENISA
   Wyzwalacz: Wykryto aktywne wykorzystanie
   Ramy czasowe: Wczesne ostrzeżenie 24h, szczegółowy raport 72h
   Odpowiedzialny: Lider Zespołu Bezpieczeństwa
   Proces: Zobacz PD-ENISA-001

4. HISTORIA
   Obsłużone podatności (ostatnie 24 miesiące): 3
   Średni czas rozwiązania: 45 dni
   Raporty ENISA złożone: 0

Częste Błędy

Niekompletna Ocena Ryzyka

Problem: Ocena ryzyka która nie obejmuje wszystkich zagrożeń lub brakuje szczegółów leczenia.

Naprawa: Użyj strukturyzowanej metodologii. Mapuj każde zidentyfikowane ryzyko do kontroli lub decyzji akceptacji.

Brakujący SBOM

Problem: Brak SBOM lub SBOM który nie zawiera zależności przechodnich.

Naprawa: Generuj SBOM używając odpowiednich narzędzi. Włącz pełne drzewo zależności.

Nieaktualna Dokumentacja

Problem: Dokumentacja techniczna opisuje wersję 1.0 ale produkt jest w wersji 2.3.

Naprawa: Aktualizuj dokumentację z każdym wydaniem. Śledź wersje explicite.

Brak Śledzenia Wymagań

Problem: Twierdzi zgodność ale nie pokazuje jak każde wymaganie jest spełnione.

Naprawa: Stwórz jawne mapowanie od każdego wymagania Załącznika I do dowodów.

Najczęściej zadawane pytania

Jakie dokumenty są obowiązkowe w dokumentacji technicznej CRA zgodnie z Załącznikiem VII?

Załącznik VII wymaga ośmiu sekcji: (1) ogólnego opisu produktu, obejmującego przeznaczenie, wersje oprogramowania wpływające na zgodność, fotografie dla produktów sprzętowych oraz informacje dla użytkownika; (2) opisu projektowania, rozwoju i produkcji produktu wraz z procedurami obsługi podatności; (3) oceny ryzyka cyberbezpieczeństwa zgodnie z art. 13; (4) informacji wykorzystanych do ustalenia okresu wsparcia zgodnie z art. 13 ust. 8; (5) wykazu norm zharmonizowanych zastosowanych w całości lub w części; (6) sprawozdań z badań przeprowadzonych w celu weryfikacji zgodności; (7) kopii Deklaracji zgodności UE; oraz (8) w stosownych przypadkach, Zestawienia Materiałów Oprogramowania (SBOM), udostępnianego na uzasadniony wniosek organu nadzoru rynku.

Czy każda wersja firmware wymaga osobnej dokumentacji technicznej?

Dokumentacja techniczna musi odzwierciedlać aktualną wersję produktu. Każde wydanie firmware zmieniające zachowanie istotne z punktu widzenia bezpieczeństwa wymaga aktualizacji dokumentacji, przynajmniej w zakresie SBOM, oceny ryzyka i wyników testów. Nie trzeba tworzyć dokumentacji od zera, ale musi ona pozostać dokładna i odnosić się do konkretnej wersji.

Jak długo należy przechowywać dokumentację techniczną po wycofaniu produktu?

CRA wymaga przechowywania przez 10 lat od daty wprowadzenia ostatniej jednostki na rynek. Jeśli produkty są sprzedawane do 2030 roku, cała dokumentacja musi być dostępna do 2040 roku.

Czy dokumentację techniczną należy składać organom z własnej inicjatywy?

Nie. Producent przechowuje dokumentację techniczną i udostępnia ją na żądanie organów nadzoru rynku. Organy mogą zażądać wglądu w dowolnym momencie, ale nie ma obowiązku składania dokumentacji przy wprowadzaniu produktu na rynek.

Czy dokumentacja techniczna może zawierać odniesienia do zewnętrznych dokumentów?

Tak, zewnętrzne odniesienia są dopuszczalne pod warunkiem, że dokumenty są dostępne i możliwe do zidentyfikowania. Plik może wskazywać raporty z testów, dokumentację projektową lub certyfikaty norm przechowywane osobno, o ile odniesienia są precyzyjne, a dokumenty dostępne na żądanie.

Jaka jest różnica między dokumentacją techniczną a Deklaracją zgodności?

Deklaracja zgodności to krótki, publiczny dokument stwierdzający, że produkt spełnia wymagania CRA. Dokumentacja techniczna to kompletny pakiet dowodów potwierdzających tę deklarację, zawierający całą dokumentację, wyniki testów i oceny. Deklaracja zgodności odwołuje się do dokumentacji technicznej, która stanowi merytoryczną podstawę tego oświadczenia.

Następne kroki

Zarządzasz zgodnością CRA dla wielu produktów? CRA Evidence śledzi dowody w dokumentacji technicznej, aktualizacje SBOM i mapowanie wymagań Załącznika I dla każdej wersji produktu.

Po ukończeniu oceny ryzyka i dokumentacji projektowej, uzupełnij Sekcję 6 za pomocą naszego przewodnika po wymaganiach SBOM. Sprawdź przewodnik po ocenie zgodności, aby potwierdzić, który moduł ma zastosowanie przed finalizacją Deklaracji zgodności.

Ten artykuł służy wyłącznie celom informacyjnym i nie stanowi porady prawnej. W celu uzyskania konkretnych wskazówek dotyczących zgodności, skonsultuj się z wykwalifikowanym prawnikiem.