CRA Dokumentacja techniczna: przewodnik po Załączniku VII

Dokumentacja techniczna jest pakietem dowodów potwierdzających zgodność z CRA. Organy nadzoru rynku będą jej żądać. Jednostki notyfikowane będą ją analizować. Bez kompletnej dokumentacji technicznej nie można legalnie wprowadzić produktu na rynek UE.

Niniejszy przewodnik omawia załącznik VII sekcja po sekcji, wyjaśniając, czego każda z nich wymaga i jak ją przygotować. Skupia się na praktycznych decyzjach, które producent musi podjąć przed wprowadzeniem produktu na rynek, oraz na dowodach, których organy nadzoru zwykle żądają w pierwszej kolejności.

Czym jest dokumentacja techniczna?

Dokumentacja techniczna (nazywana też "teczką techniczną") to kompletny pakiet dowodów potwierdzających, że produkt spełnia wymagania CRA.

Czym nie jest:

• Dokumentacją marketingową
• Wyłącznie instrukcją użytkownika
• Ćwiczeniem polegającym na odhaczaniu pól

Czym jest:

• Pełnym dowodem technicznym
• Żywą dokumentacją (aktualizowaną przez cały cykl życia produktu)
• Linią obrony w postępowaniach nadzoru rynku
• Wymogiem dla oceny zgodności

Przegląd struktury załącznika VII

Załącznik VII do CRA określa wymogi dotyczące dokumentacji technicznej:

STRUKTURA DOKUMENTACJI TECHNICZNEJ (załącznik VII)

1. OPIS OGÓLNY
   \-- Identyfikacja produktu i przeznaczenie

2. PROJEKTOWANIE, ROZWÓJ, OBSŁUGA PODATNOŚCI I PRODUKCJA
   \-- Bezpieczeństwo wbudowane, podatności obsłużone, produkcja i monitorowanie zwalidowane

3. OCENA RYZYKA W ZAKRESIE CYBERBEZPIECZEŃSTWA
   \-- Zidentyfikowane i obsłużone ryzyka

4. INFORMACJE O OKRESIE WSPARCIA
   \-- Informacje wykorzystane do ustalenia okresu wsparcia (art. 13 ust. 8)

5. ZASTOSOWANE NORMY
   \-- Wykorzystane normy i odstępstwa

6. WYNIKI TESTÓW
   \-- Dowody weryfikacji

7. DEKLARACJA ZGODNOŚCI UE
   \-- Lub jej kopia

8. WYKAZ KOMPONENTÓW OPROGRAMOWANIA (SBOM)
   \-- Komponenty i zależności (na uzasadnione żądanie)

Sekcja 1: Opis ogólny

Cel: Określenie, czym jest produkt i do czego służy.

Ta sekcja zakotwicza całą resztę dokumentacji technicznej: bez jednoznacznej identyfikacji wersji sprzętu i oprogramowania pozostałe dowody nie mają punktu odniesienia. Numery seryjne, oznaczenia firmware'u oraz przeznaczenie powinny być zgodne z etykietą produktu i instrukcją użytkownika.

Wymagana zawartość

Poniższa lista kontrolna opisu ogólnego pomaga zweryfikować, czy podstawowe informacje o produkcie zostały ujęte w sposób umożliwiający organom nadzoru jednoznaczne zidentyfikowanie egzemplarza.

LISTA KONTROLNA OPISU OGÓLNEGO

Identyfikacja produktu:
[ ] Nazwa produktu i numer modelu
[ ] Wersje sprzętu
[ ] Wersje oprogramowania/firmware'u
[ ] Format lub zakres numerów seryjnych
[ ] Unikalny identyfikator produktu

Przeznaczenie:
[ ] Opis funkcji podstawowej
[ ] Docelowi użytkownicy/środowisko
[ ] Zamierzone przypadki użycia
[ ] Zastosowania niezamierzone (wyłączenia)

Kategoria produktu:
[ ] Klasyfikacja CRA (domyślny/ważny/krytyczny)
[ ] Uzasadnienie klasyfikacji
[ ] Powiązane regulacje produktowe (jeśli dotyczy)

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

Przykład

Poniższy przykład pokazuje minimalny poziom szczegółowości oczekiwany przez organy nadzoru. Wartości produktowe są ilustracyjne i należy je zastąpić rzeczywistymi danymi technicznymi.

OPIS OGÓLNY

Nazwa produktu: SmartSense Pro Industrial Sensor
Numer modelu: SSP-3000
Wersja sprzętu: Rev C (PCB v3.2)
Wersja firmware'u: 2.4.1

PRZEZNACZENIE:
The SmartSense Pro is an industrial environmental sensor
designed for manufacturing facility monitoring. It measures
temperature, humidity, and air quality, transmitting data
via WiFi to cloud or local servers.

DOCELOWI UŻYTKOWNICY:
- Facility managers
- Industrial automation integrators
- Environmental compliance officers

ZAMIERZONE ŚRODOWISKO:
- Indoor industrial facilities
- Operating temperature: -10°C to +60°C
- Network: WiFi 802.11 b/g/n

NIE PRZEZNACZONY DO:
- Medical or life-safety applications
- Outdoor installation
- Explosive atmospheres
- Consumer/residential use

KLASYFIKACJA CRA:
Default product. Not listed in Annex III or IV.
Uzasadnienie: General-purpose sensor without security
ani zastosowania w infrastrukturze krytycznej.

WPROWADZENIE NA RYNEK UE:
Pierwsze wprowadzenie na rynek: March 15, 2027
Rynki docelowe: All EU member states
Dystrybucja: Direct sales and authorized distributors

Sekcja 2: Projektowanie, rozwój i obsługa podatności

Cel: Udokumentować, jak produkt został zaprojektowany i zbudowany, jak obsługiwane są podatności po wprowadzeniu na rynek oraz jak walidowane są procesy produkcji i monitorowania. Załącznik VII §2 traktuje je jako jeden blok: projektowanie i rozwój w §2(a), procesy obsługi podatności w §2(b), procesy produkcji i monitorowania w §2(c).

Wiele zespołów rozdziela te zagadnienia, jednak organy nadzoru oczekują spójnej narracji łączącej wybory projektowe ze sposobem reagowania na podatności po wprowadzeniu produktu na rynek. Spójność między architekturą zabezpieczeń a procedurami CVD jest jednym z najczęściej weryfikowanych elementów.

Projektowanie i rozwój: wymagana zawartość

LISTA KONTROLNA DOKUMENTACJI PROJEKTOWEJ

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

Projekt zabezpieczeń:
[ ] Opis architektury bezpieczeństwa
[ ] Implementacje kryptograficzne
[ ] Mechanizmy uwierzytelniania
[ ] Model autoryzacji
[ ] Bezpieczne protokoły komunikacyjne
[ ] Środki ochrony danych

Proces rozwoju:
[ ] Opis bezpiecznego cyklu rozwoju
[ ] Identyfikowalność wymagań bezpieczeństwa
[ ] Procedury przeglądu kodu
[ ] Testy bezpieczeństwa w trakcie rozwoju
[ ] Zarządzanie konfiguracją

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

Jak wygląda dokumentacja "secure by design"

Poniższy szkic ilustruje granice zaufania, mechanizmy uwierzytelniania, ochronę danych oraz proces aktualizacji firmware'u. Każdy z tych obszarów musi być powiązany z konkretnymi wymaganiami załącznika I oraz z odpowiednimi raportami z testów.

PRZEGLĄD ARCHITEKTURY BEZPIECZEŃSTWA

1. GRANICE ZAUFANIA
   +-----------------------------------------+
   |            Cloud Backend                 |
   |  (Authentication, Data Storage)          |
   \---------------+-------------------------+
                   | TLS 1.3
   +---------------+-------------------------+
   |         Device Firmware                  |
   |  +---------------------------------+    |
   |  |    Application Layer            |    |
   |  +---------------------------------+    |
   |  |    Security Services            |    |
   |  |  (Crypto, Auth, Secure Boot)    |    |
   |  +---------------------------------+    |
   |  |    Hardware Security            |    |
   |  |  (Secure Element, RNG)          |    |
   |  \---------------------------------+    |
   \-----------------------------------------+

2. UWIERZYTELNIANIE
   - Device-to-cloud: Mutual TLS with device certificates
   - User-to-device: Local API requires authentication token
   - Certificate provisioning: Factory-provisioned, unique per device

3. OCHRONA DANYCH
   - Data at rest: AES-256-GCM encryption
   - Data in transit: TLS 1.3 with certificate pinning
   - Sensitive data: Stored in secure element

4. MECHANIZM AKTUALIZACJI
   - Signed firmware updates (ECDSA P-256)
   - Signature verification before installation
   - Rollback protection via version counter
   - Automatic update checks (user-configurable)

Obsługa podatności: wymagana zawartość

LISTA KONTROLNA OBSŁUGI PODATNOŚCI

Przyjmowanie zgłoszeń:
[ ] Udokumentowane metody kontaktu (e-mail, formularz, security.txt)
[ ] Opublikowana polityka CVD
[ ] Procedury komunikacji z badaczami

Proces:
[ ] Procedury triażu
[ ] Metodyka oceny powagi
[ ] Ścieżki eskalacji
[ ] Przepływ pracy nad łatkami
[ ] Procedury testowania łatek

Komunikacja:
[ ] Procedury powiadamiania klientów
[ ] Proces publikacji ogłoszeń bezpieczeństwa
[ ] Integracja zgłoszeń do ENISA (przy aktywnej eksploitacji)

Monitorowanie:
[ ] Monitorowanie podatności w zależnościach
[ ] Monitorowanie bazy CVE
[ ] Źródła wywiadu o zagrożeniach

Dokumentacja obsługi podatności

Procedury obsługi podatności muszą być publicznie dostępne i konsekwentnie stosowane. Dokumentacja powinna pokazywać zarówno publiczny interfejs (security.txt, CVD), jak i wewnętrzny przepływ pracy oraz historyczne dane o czasach reakcji.

PROCEDURY OBSŁUGI PODATNOŚCI

1. METODY KONTAKTU
   Główny: security@company.com
   Formularz web: https://company.com/security/report
   security.txt: https://company.com/.well-known/security.txt
   Polityka CVD: https://company.com/security/disclosure-policy

2. ZOBOWIĄZANIA DOTYCZĄCE REAKCJI
   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. PROCES WEWNĘTRZNY
   [Schemat blokowy lub opis procesu]
   Zobacz: Dokument procesu PD-VULN-003

4. DYSTRYBUCJA ŁATEK
   Mechanizm: aktualizacje OTA przez infrastrukturę chmurową
   Powiadomienie: powiadomienie w aplikacji + e-mail do zarejestrowanych użytkowników
   Weryfikacja: podpisane aktualizacje z możliwością wycofania

5. ZGŁOSZENIA DO ENISA
   Wyzwalacz: wykryto aktywną eksploatację
   Harmonogram: 24h wczesne ostrzeżenie, 72h raport szczegółowy
   Odpowiedzialny: lider zespołu bezpieczeństwa
   Proces: zob. PD-ENISA-001

6. HISTORIA
   Obsłużone podatności (ostatnie 24 miesiące): 3
   Średni czas rozwiązania: 45 dni
   Złożone zgłoszenia do ENISA: 0

Produkcja i monitorowanie: wymagana zawartość

W przypadku oprogramowania nie istnieje fizyczna linia produkcyjna. Załącznik VII pkt 2 lit. c odnosi się do potoku budowy i wydania, który wytwarza artefakty gotowe do dystrybucji, do walidacji potwierdzającej, że procesy te działają zgodnie z założeniem, oraz do monitorowania powdrożeniowego, które wychwytuje regresje i nowe podatności. Każdy z tych obszarów należy udokumentować tak, aby audytor mógł prześledzić wydanie aż do zweryfikowanej, odtwarzalnej kompilacji.

LISTA KONTROLNA PRODUKCJI I MONITOROWANIA

Potok budowy i wydania:
[ ] Zidentyfikowane źródło prawdy (repozytorium, ochrona gałęzi)
[ ] Udokumentowana odtwarzalna kompilacja (przypięte wersje toolchaina)
[ ] Zarejestrowana proweniencja kompilacji (poziom SLSA, atestacje in-toto)
[ ] Udokumentowane klucze podpisujące i zarządzanie kluczami
[ ] Integralność artefaktu wydania (podpisane binaria, SBOM przy wydaniu)

Walidacja procesów produkcji:
[ ] Udokumentowane bramki bezpieczeństwa w CI (kryteria zaliczenia SAST, DAST, SCA)
[ ] Pakiet regresji obejmuje wymagania oznaczone jako załącznik I
[ ] Udokumentowany proces zatwierdzania wydania
[ ] Plan wycofania nieudanych wydań
[ ] Częstotliwość audytu odtwarzalności

Monitorowanie powdrożeniowe:
[ ] Częstotliwość monitorowania podatności w zależnościach (codziennie/tygodniowo)
[ ] Proces porównywania SBOM przy każdym wydaniu
[ ] Integracja kanałów CVE (NVD, GHSA, biuletyny dostawców)
[ ] Sprawdzanie bazy KEV pod kątem aktywnej eksploatacji
[ ] Telemetria zdarzeń istotnych dla bezpieczeństwa (nieudane aktualizacje, błędy weryfikacji podpisu)
[ ] Udokumentowane wyzwalacze powiadamiania klientów

Dokumentacja produkcji i monitorowania

PROCESY PRODUKCJI I MONITOROWANIA

Produkt: Industrial Gateway IG-200
Platforma kompilacji: GitHub Actions na runnerach ubuntu-22.04
Proweniencja: SLSA Level 3 (podpisane atestacje in-toto)
Podpisywanie: Cosign + Sigstore, klucz główny offline oparty o KMS

POTOK KOMPILACJI:
1. Źródło: github.com/example/ig200-firmware (gałąź main chroniona,
   bramka przeglądu 2-of-N, wymagane podpisane commity)
2. Kompilacja: odtwarzalna kroskompilacja (rustc 1.78, zablokowany Cargo.lock)
3. SAST: cargo-audit + clippy security lints (bramka: 0 ustaleń high+)
4. SCA: skan Trivy zbudowanego binarium (bramka: 0 znanych CVE możliwych do wykorzystania)
5. Testy: pakiet regresji (1247 testów) + pakiet zgodności z załącznikiem I (89 testów)
6. Podpis: cosign sign-blob + attest --predicate slsa-provenance.json
7. Wydanie: artefakt + SBOM (CycloneDX 1.5) + wyciąg z DoC opublikowany

WALIDACJA PROCESÓW:
- Definicja potoku przeglądana kwartalnie (Security Lead + Release Manager)
- Pakiet zgodności z załącznikiem I przeglądany przy zmianie norm lub ryzyk
- Coroczny audyt odtwarzalności (niezależna rekompilacja z otagowanego źródła)
- Tryb awarii: niezaliczona bramka -> wydanie zablokowane, incydent zarejestrowany

MONITOROWANIE POWDROŻENIOWE:
- Kanał CVE zależności: Trivy + Renovate, codzienny skan względem bieżącego SBOM
- Próg: Critical lub High z dopasowaniem KEV -> łatka w ciągu 7 dni
- Próg: Medium bez KEV -> łatka w kolejnym wydaniu miesięcznym
- Powiadamianie klientów: podpisany kanał RSS + e-mail z biuletynami
- Telemetria wewnętrzna: zdarzenia nieudanych aktualizacji, błędy weryfikacji podpisu
- Częstotliwość przeglądu: cotygodniowy triaż, comiesięczny przegląd trendów

Sekcja 3: Ocena ryzyka w zakresie cyberbezpieczeństwa

Cel: Udokumentowanie zidentyfikowanych ryzyk i sposobu ich obsłużenia.

Ocena ryzyka musi pokrywać cały zakres produktu, a nie wybrane funkcje. Należy uwzględnić zarówno ryzyka techniczne (kryptografia, uwierzytelnianie, integralność firmware'u), jak i operacyjne (zaopatrzenie, łańcuch dostaw, dostęp serwisowy). Ryzyka rezydualne wymagają wyraźnej decyzji o akceptacji lub dalszym łagodzeniu.

Wymagana zawartość

Metodyka oceny ryzyka powinna być wybrana świadomie i konsekwentnie stosowana w kolejnych wydaniach produktu. Najczęściej wykorzystywane są ramy ISO 27005, IEC 62443 oraz NIST CSF, dostosowane do specyfiki bezpieczeństwa produktu.

LISTA KONTROLNA OCENY RYZYKA

Metodyka:
[ ] Opisana metodyka oceny ryzyka
[ ] Zdefiniowany zakres
[ ] Identyfikacja aktywów
[ ] Podejście do identyfikacji zagrożeń

Analiza ryzyka:
[ ] Wyliczone zagrożenia
[ ] Uwzględnione podatności
[ ] Ocena skutków
[ ] Ocena prawdopodobieństwa
[ ] Oceny ryzyka

Postępowanie z ryzykiem:
[ ] Decyzje dotyczące każdego ryzyka
[ ] Mapowanie zabezpieczeń na ryzyka
[ ] Ocena ryzyka rezydualnego
[ ] Kryteria akceptacji ryzyka

Format oceny ryzyka

Układ tabelaryczny ułatwia śledzenie kolejnych decyzji oraz powiązanie ryzyk z konkretnymi środkami łagodzącymi. Każde ryzyko powinno mieć stabilny identyfikator, dzięki któremu można je przywoływać w pozostałych sekcjach dokumentacji oraz w kolejnych wydaniach produktu.

OCENA RYZYKA W ZAKRESIE CYBERBEZPIECZEŃSTWA

Produkt: SmartSense Pro (SSP-3000)
Wersja: 2.4.1
Data oceny: January 2027
Oceniający: [Name, Security Team]

METODYKA:
Based on ISO 27005 adapted for product security.
Risk = Likelihood × Impact
Scale: Low (1-4), Medium (5-9), High (10-16), Critical (17-25)

-------------------------------------------------------------
ID RYZYKA: R-001
ZAGROŻENIE: Unauthorized firmware modification
PODATNOŚĆ: Unsigned firmware could be installed
SKUTEK: High (5) - Device compromise, data breach
PRAWDOPODOBIEŃSTWO: Medium (3) - Requires physical access
RYZYKO PIERWOTNE: 15 (High)

ZABEZPIECZENIE: Firmware signature verification
WDROŻENIE: ECDSA P-256 signature checked before install
RYZYKO REZYDUALNE: 3 (Low) - Cryptographic attack unlikely

STATUS: zmitygowane
-------------------------------------------------------------
ID RYZYKA: R-002
ZAGROŻENIE: Man-in-the-middle attack on cloud communication
PODATNOŚĆ: Network traffic interception
SKUTEK: High (4) - Data exposure, command injection
PRAWDOPODOBIEŃSTWO: Medium (3) - Public networks possible
RYZYKO PIERWOTNE: 12 (High)

ZABEZPIECZENIE: TLS 1.3 with certificate pinning
WDROŻENIE: Hardcoded CA certificate, no fallback
RYZYKO REZYDUALNE: 2 (Low) - Certificate compromise unlikely

STATUS: zmitygowane
-------------------------------------------------------------
[Kontynuuj dla wszystkich zidentyfikowanych ryzyk...]

PODSUMOWANIE RYZYKA:
Łącznie zidentyfikowanych ryzyk: 23
Krytyczne: 0
Wysokie: 3 (all mitigated to Low/Medium)
Średnie: 8 (all mitigated to Low)
Niskie: 12 (accepted or mitigated)

AKCEPTACJA RYZYKA REZYDUALNEGO:
Wszystkie ryzyka rezydualne mieszczą się w akceptowalnej tolerancji.
Signed: [Security Lead], [Date]

Sekcja 4: Informacje o okresie wsparcia

Cel: Udokumentowanie uzasadnienia wybranego okresu wsparcia, zgodnie z art. 13 ust. 8. Okres wsparcia to czas, w którym producent zobowiązuje się dostarczać aktualizacje bezpieczeństwa. Załącznik VII pkt 4 wymaga, aby dokumentacja techniczna ujmowała informacje, które wpłynęły na tę decyzję.

Wymagana zawartość

Decyzja o okresie wsparcia musi być oparta na konkretnych przesłankach: oczekiwanym czasie użytkowania, harmonogramach wsparcia komponentów oraz oczekiwaniach użytkowników. Sam zapis "5 lat" bez uzasadnienia nie spełnia wymagań art. 13 ust. 8.

ZAPIS DECYZJI O OKRESIE WSPARCIA

Zadeklarowany okres wsparcia: [data początku] do [data końca]
Minimum: 5 lat od wprowadzenia na rynek (lub czas życia produktu, jeśli krótszy)

Uwzględnione przesłanki (art. 13 ust. 8):
[ ] Oczekiwany czas użytkowania produktu
[ ] Oczekiwania użytkowników i klientów
[ ] Charakter i przeznaczenie produktu
[ ] Właściwe prawo Unii (sektorowe wartości minimalne)
[ ] Wytyczne wydane przez Komisję
[ ] Uzasadnione oczekiwania konsumentów i innych użytkowników końcowych

Udokumentowane uzasadnienie:
[ ] Czas życia porównywalnych produktów na rynku
[ ] Harmonogramy wsparcia komponentów (OS, środowiska uruchomieniowe, biblioteki)
[ ] Umowy z klientami lub SLA implikujące okna aktualizacji
[ ] Harmonogramy końca życia sprzętu (jeśli dotyczy)

Jak wygląda dobra dokumentacja

Dobra dokumentacja okresu wsparcia łączy oczekiwany czas eksploatacji produktu z konkretnymi zobowiązaniami dostawców komponentów oraz umowami serwisowymi z klientami. Im więcej źródeł zostanie powołanych w decyzji, tym łatwiej obronić ją przed organem nadzoru.

USTALENIE OKRESU WSPARCIA
Produkt: Industrial Gateway IG-200
Wprowadzenie na rynek: 2026-09-01
Zadeklarowany okres wsparcia: 2026-09-01 to 2034-09-01 (8 years)

Uzasadnienie:
1. Expected operational lifetime: 8-10 years (field deployment data,
   comparable to predecessor IG-150 still active in 2024 at 9 years).
2. Component support: Linux LTS kernel covers 6 years; we backport
   security patches for 2 additional years using vendor commitments.
3. Customer contracts: top 3 customers have 7-year service agreements;
   remainder typically renew on 5-year cycles.
4. Sector guidance: NIS2 covers operators of essential services using
   this gateway; assume update requirements through asset lifetime.
5. End-of-support communication: documented in user manual and EOL
   policy at https://example.com/security/eol.

Decyzję zatwierdzili: [Product Owner], [Security Lead], [Legal]
Data: 2026-08-15
Wyzwalacz przeglądu: any material change to component support timelines

Częste pułapki

• Zakotwiczenie w 5-letnim minimum bez uzasadnienia. Pięć lat z art. 13 ust. 8 to dolna granica, nie wartość domyślna. Produkty o dłuższym oczekiwanym czasie życia wymagają dłuższego okresu.
• Pomijanie zastrzeżenia "lub czas życia produktu, jeśli krótszy". Urządzenie konsumenckie sprzedawane przez 18 miesięcy nadal wymaga wsparcia aktualizacji przez okres, w którym produkt jest racjonalnie używany.
• Brak rejestracji przesłanek. Organy nadzoru mogą zapytać, jak ustalono okres. "Wybraliśmy 5 lat" nie jest odpowiedzią.
• Traktowanie decyzji jako niezmiennej. Jeśli harmonogramy wsparcia komponentów się zmienią (np. nadrzędny OS osiągnie EOL wcześniej niż zakładano), zapis decyzji musi zostać zaktualizowany, a zobowiązanie do wsparcia zakomunikowane.

Mapowanie wymagań zasadniczych (załącznik I)

Cel: Wykazanie, w jaki sposób spełnione jest każde wymaganie z załącznika I.

Mapowanie powinno odsyłać do konkretnych dokumentów, sekcji i wyników testów. Ogólne stwierdzenia w stylu "jesteśmy zgodni" bez powiązania z dowodami są częstym powodem zwrotu dokumentacji do uzupełnienia.

Wymagania z załącznika I, część I

Część I obejmuje wymagania dotyczące właściwości produktu: brak znanych podatności możliwych do wykorzystania, bezpieczna konfiguracja domyślna, ochrona dostępu, poufność i integralność danych oraz minimalizacja danych.

Powiąż każde wymaganie ze swoją implementacją:

MATRYCA ZGODNOŚCI Z WYMAGANIAMI ZASADNICZYMI

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

1. ZAPROJEKTOWANY BEZ ZNANYCH PODATNOŚCI MOŻLIWYCH DO WYKORZYSTANIA
   Status: zgodny
   Dowody:
   - Vulnerability scan report (Trivy): 0 critical/high
   - Dependency analysis: All components at latest secure versions
   - Penetration test report: No exploitable vulnerabilities found
   Odniesienie: Test Report TR-2027-001, pages 15-23

2. KONFIGURACJA BEZPIECZNA DOMYŚLNIE
   Status: zgodny
   Dowody:
   - Default configuration review document
   - No default passwords (unique credentials required at setup)
   - Unnecessary services disabled by default
   - Secure protocols enabled by default (TLS, not HTTP)
   Odniesienie: Design Document DD-004, Section 3.2

3. OCHRONA PRZED NIEUPRAWNIONYM DOSTĘPEM
   Status: zgodny
   Dowody:
   - Authentication architecture document
   - Access control implementation
   - Session management design
   - Failed login lockout mechanism
   Odniesienie: Security Architecture SA-001, Chapter 4

4. POUFNOŚĆ DANYCH
   Status: zgodny
   Dowody:
   - Encryption specifications (AES-256-GCM)
   - Key management procedures
   - Data classification and handling
   Odniesienie: Design Document DD-005

5. INTEGRALNOŚĆ DANYCH I POLECEŃ
   Status: zgodny
   Dowody:
   - Message authentication (HMAC)
   - Command validation logic
   - Input validation procedures
   Odniesienie: Security Architecture SA-001, Chapter 5

6. MINIMALIZACJA DANYCH
   Status: zgodny
   Dowody:
   - Data inventory document
   - Justification for each data type collected
   - Retention policy (automatic purge after 90 days)
   Odniesienie: Privacy Impact Assessment PIA-001

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

Wymagania z załącznika I, część II

Część II reguluje obsługę podatności w cyklu życia produktu: identyfikację, niezwłoczne adresowanie, regularne testowanie oraz przejrzystą komunikację z użytkownikami.

ZAŁĄCZNIK I, CZĘŚĆ II - OBSŁUGA PODATNOŚCI
═══════════════════════════════════════════════════════════

1. IDENTYFIKACJA I DOKUMENTOWANIE PODATNOŚCI
   Status: zgodny
   Dowody:
   - Vulnerability tracking system (JIRA project VULN)
   - CVE monitoring process document
   - SBOM-based dependency tracking
   Odniesienie: Process Document PD-VULN-001

2. NIEZWŁOCZNE ADRESOWANIE PODATNOŚCI
   Status: zgodny
   Dowody:
   - Vulnerability response SLA document
   - Historical response time metrics
   - Patch development process
   Odniesienie: Process Document PD-VULN-002

3. STOSOWANIE SKUTECZNYCH REGULARNYCH TESTÓW
   Status: zgodny
   Dowody:
   - Security testing schedule
   - Automated scan reports (weekly)
   - Annual penetration test reports
   Odniesienie: Test Plan TP-SEC-001

[Kontynuuj dla wszystkich wymagań części II...]

Sekcja 5: Zastosowane normy

Cel: Udokumentowanie, jakie normy zostały zastosowane i w jaki sposób.

Normy zharmonizowane dają domniemanie zgodności tylko w zakresie, w jakim zostały zastosowane. Każde odstępstwo wymaga jawnego uzasadnienia oraz środka kompensującego. Wersje norm muszą być spójne z datą oceny zgodności.

Wymagana zawartość

Lista zastosowanych norm wraz z numerami wersji oraz wskazaniem klauzul zastosowanych w całości lub w części stanowi podstawę domniemania zgodności. Odstępstwa wymagają osobnej tabeli z uzasadnieniem oraz środkiem alternatywnym.

LISTA KONTROLNA STOSOWANIA NORM

Lista norm:
[ ] Wszystkie zastosowane normy z numerami wersji
[ ] Normy zharmonizowane oznaczone osobno
[ ] Odniesienie do publikacji w Dzienniku Urzędowym (jeśli zharmonizowane)

Dowody zastosowania:
[ ] Sposób zastosowania każdej normy
[ ] Zastosowane klauzule/sekcje
[ ] Wszelkie odstępstwa lub zastosowanie częściowe

Obsługa odstępstw:
[ ] Odstępstwa udokumentowane wraz z uzasadnieniem
[ ] Środki alternatywne dla wymagań objętych odstępstwem
[ ] Ocena ryzyka dla odstępstw

Format dokumentacji norm

Format tabelaryczny ułatwia rozróżnienie między normami zharmonizowanymi (dającymi domniemanie zgodności) a normami stosowanymi pomocniczo. Każde odstępstwo musi mieć przypisany środek alternatywny oraz powiązaną decyzję ryzyka.

ZASTOSOWANE NORMY

NORMY ZHARMONIZOWANE (domniemanie zgodności):
-------------------------------------------------------------
Norma: EN 303 645 (when harmonized for CRA)
Tytuł: Cybersecurity for Consumer IoT
Status: zastosowano w całości
Publikacja: OJEU [reference when published]
Dowody: Standards Compliance Report SCR-001
-------------------------------------------------------------

INNE ZASTOSOWANE NORMY:
-------------------------------------------------------------
Norma: IEC 62443-4-1:2018
Tytuł: Security for Industrial Automation - Secure Development
Status: zastosowano (wybrane wymagania)
Zastosowane klauzule: 5, 6, 7, 8, 10
Dowody: SDL Documentation SLD-001
-------------------------------------------------------------
Norma: ISO/IEC 27001:2022
Tytuł: Information Security Management
Status: organizacja certyfikowana (Certyfikat #12345)
Znaczenie: ISMS covers product development processes
-------------------------------------------------------------
Norma: NIST Cybersecurity Framework 2.0
Tytuł: Framework for Improving Critical Infrastructure Cybersecurity
Status: rama referencyjna do oceny ryzyka
Dowody: Risk Assessment methodology document
-------------------------------------------------------------

ODSTĘPSTWA:
-------------------------------------------------------------
Norma: EN 303 645
Klauzula: 5.3-2 (Unique per device credentials)
Odstępstwo: Credentials unique per device but not pre-provisioned
Uzasadnienie: Device requires user setup; credentials created
              during first-time configuration
Środek alternatywny: Strong password requirements enforced,
                    account lockout after failed attempts
Ocena ryzyka: Residual risk acceptable (see R-015)
-------------------------------------------------------------

Sekcja 6: Wyniki testów

Cel: Dostarczenie dowodów, że wymagania są faktycznie spełnione.

Raporty z testów powinny zawierać warunki brzegowe, środowisko, narzędzia i wyniki. Twierdzenia o wykonaniu testów bez załączonych raportów lub bez identyfikowalności względem wymagań są traktowane jak brak dowodu.

Wymagana zawartość

Plan testów powinien obejmować zarówno testy funkcjonalne, jak i testy bezpieczeństwa: skanowanie podatności, testy penetracyjne, fuzzing oraz przegląd konfiguracji. Każdy przypadek testowy musi być powiązany z konkretnym wymaganiem.

LISTA KONTROLNA DOKUMENTACJI TESTÓW

Planowanie testów:
[ ] Plan testów z zakresem i celami
[ ] Przypadki testowe powiązane z wymaganiami
[ ] Opis środowiska testowego
[ ] Kryteria zaliczenia/niezaliczenia

Wykonanie testów:
[ ] Zapisy z wykonania testów
[ ] Podsumowanie wyników testów
[ ] Niezaliczone testy i ich rozwiązanie
[ ] Dowody powtórnych testów

Rodzaje testów:
[ ] Funkcjonalne testy bezpieczeństwa
[ ] Skanowanie podatności
[ ] Testy penetracyjne (jeśli dotyczy)
[ ] Testy fuzzingowe (jeśli dotyczy)
[ ] Przegląd konfiguracji

Format wyników testów

Podsumowanie kampanii testowej powinno wskazywać zakres, narzędzia oraz wszystkie ustalenia, łącznie z tymi, które zostały zaakceptowane jako ryzyko rezydualne. Dla każdego ustalenia warto odnotować decyzję: naprawiono, zaakceptowano lub odroczono.

PODSUMOWANIE WYNIKÓW TESTÓW

Produkt: SmartSense Pro (SSP-3000) v2.4.1
Okres testów: December 2026 - January 2027
Lider testów: [Name]

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

1. FUNKCJONALNE TESTY BEZPIECZEŃSTWA
   Zakres: Authentication, authorization, encryption, secure boot
   Przypadki testowe: 85
   Zaliczone: 85
   Niezaliczone: 0
   Odniesienie: Test Report TR-FUNC-001

2. SKANOWANIE PODATNOŚCI
   Narzędzie: Trivy v0.48.0 + Nessus Professional
   Zakres: Firmware, network services, web interface
   Ustalenia:
     Krytyczne: 0
     Wysokie: 0
     Średnie: 2 (accepted with justification)
     Niskie: 5 (accepted)
   Odniesienie: Scan Report SR-VULN-001

3. TESTY PENETRACYJNE
   Dostawca: [Third-party firm name]
   Zakres: Black-box testing of deployed device
   Czas trwania: 5 days
   Ustalenia:
     Krytyczne: 0
     Wysokie: 0
     Średnie: 1 (remediated before release)
     Niskie: 3 (accepted)
   Odniesienie: Pentest Report PT-2027-001

4. ANALIZA FIRMWARE'U
   Narzędzie: EMBA v1.3
   Zakres: Binary analysis, hardcoded credentials, crypto issues
   Ustalenia:
     Krytyczne: 0
     Wysokie: 0
     Informacyjne: 4
   Odniesienie: Firmware Analysis Report FA-001

5. PRZEGLĄD KONFIGURACJI
   Zakres: Default configuration security
   Ustalenia: Wszystkie ustawienia domyślne spełniają wymagania bezpieczeństwa
   Odniesienie: Configuration Review CR-001

═══════════════════════════════════════════════════════════
OCENA OGÓLNA: zaliczono
Wszystkie ustalenia krytyczne i wysokie naprawione.
Ustalenia średnie/niskie zaakceptowane z udokumentowanym uzasadnieniem.
═══════════════════════════════════════════════════════════

Sekcja 7: Deklaracja zgodności UE

Cel: Dołączenie formalnej deklaracji lub odniesienia do niej.

Deklaracja zgodności wymieniona w sekcji 7 powinna być spójna z resztą dokumentacji: numery wersji, normy oraz przywołane procedury muszą się zgadzać z pozostałymi sekcjami załącznika VII.

Wymagana zawartość

Dokumentacja techniczna musi zawierać kopię deklaracji zgodności UE lub odniesienie do miejsca, w którym można ją uzyskać.

DEKLARACJA ZGODNOŚCI UE

(See separate DoC document or include copy in technical file)

Odniesienie: DoC-SSP3000-2027-001
Data: March 1, 2027
Lokalizacja: dokumentacja techniczna, załącznik A

The EU Declaration of Conformity accompanies every product
and is available for download at:
https://company.com/support/ssp3000/doc

Sekcja 8: Wykaz komponentów oprogramowania (SBOM)

Cel: Zapewnienie przejrzystości komponentów na potrzeby śledzenia podatności. Załącznik VII pkt 8 czyni SBOM częścią dokumentacji technicznej na uzasadnione żądanie organu nadzoru rynku. W praktyce producenci przygotowują i utrzymują go równolegle z resztą dokumentacji.

SBOM bez zależności tranzytowych jest praktycznie bezużyteczny dla analizy podatności. Format powinien być maszynowo czytelny (CycloneDX lub SPDX), a aktualizacje muszą towarzyszyć każdemu wydaniu firmware'u zmieniającemu zestaw komponentów.

Powiązane przewodniki: Produkty sprzętowe wymagają dodatkowo HBOM, a jakość SBOM reguluje BSI TR-03183. Status podatności komponentów SBOM jest komunikowany za pomocą VEX. Zobacz przewodnik po wymaganiach SBOM dla CycloneDX vs SPDX, poziomów jakości BSI TR-03183, zakresu HBOM oraz użycia VEX, a także przewodnik po zgłaszaniu podatności, w jaki sposób VEX wspiera obowiązek "braku znanych podatności możliwych do wykorzystania".

Wymagana zawartość

SBOM musi być maszynowo czytelny, kompletny (zależności bezpośrednie i tranzytowe) oraz aktualizowany przy każdym wydaniu, które zmienia zestaw komponentów. Dane o licencjach i dostawcach są równie istotne jak same wersje komponentów.

LISTA KONTROLNA WYMOGÓW SBOM

Format:
[ ] Format maszynowo czytelny (CycloneDX lub SPDX)
[ ] Streszczenie czytelne dla człowieka

Zawartość:
[ ] Wszystkie komponenty oprogramowania wymienione
[ ] Określone wersje komponentów
[ ] Informacje o dostawcach
[ ] Informacje o licencjach
[ ] Znane podatności w chwili oceny

Zakres:
[ ] Zależności bezpośrednie
[ ] Zależności tranzytowe
[ ] Komponenty systemu operacyjnego (jeśli dotyczy)
[ ] Biblioteki innych dostawców

Dokumentacja SBOM

Komponent w SBOM bez wskazania dostawcy i wersji nie pozwala na korelację z bazami CVE ani z wytycznymi BSI TR-03183. Dla każdego komponentu należy zachować ścieżkę aktualizacji oraz status podatności w momencie oceny.

WYKAZ KOMPONENTÓW OPROGRAMOWANIA

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

PLIK SBOM:
sbom-ssp3000-v2.4.1.json (attached)

PODSUMOWANIE KOMPONENTÓW:
-------------------------------------------------------------
Łącznie komponentów: 127
  Zależności bezpośrednie: 23
  Zależności tranzytowe: 104

Według typu:
  Biblioteki: 98
  Frameworki: 12
  System operacyjny: 1 (FreeRTOS)
  Moduły firmware'u: 16

Według licencji:
  MIT: 45
  Apache 2.0: 38
  BSD: 15
  LGPL: 8
  Własnościowe: 21 (internal components)
-------------------------------------------------------------

STATUS PODATNOŚCI W CHWILI OCENY:
-------------------------------------------------------------
Data skanu: 2027-01-15
Skaner: Trivy v0.48.0

Krytyczne: 0
Wysokie: 0
Średnie: 2 (accepted - see below)
Niskie: 5 (accepted)

ZAAKCEPTOWANE PODATNOŚCI:
CVE-2026-XXXXX (Medium): Component xyz v1.2.3
  Status: niemożliwe do wykorzystania w naszej konfiguracji
  Uzasadnienie: Feature not enabled, code path not reachable
  Data przeglądu: 2027-04-15

CVE-2026-YYYYY (Medium): Component abc v2.0.1
  Status: złagodzone przez kontrole sieciowe
  Uzasadnienie: Requires local access, device is network-isolated
  Data przeglądu: 2027-04-15
-------------------------------------------------------------

ZOBOWIĄZANIE DO AKTUALIZACJI SBOM:
SBOM will be updated with each firmware release and made
available to customers upon request.

Kiedy należy aktualizować dokumentację techniczną?

Dokumentacja techniczna nie jest dokumentem jednorazowym. Każda zmiana komponentu, łatka bezpieczeństwa oraz wydanie firmware'u wymagają odpowiedniej aktualizacji w sekcjach 2, 3, 6 i 8.

Żywa dokumentacja

Dokumentacja techniczna jest dokumentem żywym, który ewoluuje wraz z produktem. Każda wersja firmware'u, każda zmiana komponentu i każda istotna decyzja projektowa muszą znaleźć odzwierciedlenie w odpowiedniej sekcji.

Dokumentacja techniczna nie jest statyczna:

WYZWALACZE AKTUALIZACJI DOKUMENTACJI TECHNICZNEJ

AKTUALIZACJE OBOWIĄZKOWE:
- Nowa wersja firmware'u/oprogramowania
- Wydanie łatki bezpieczeństwa
- Wykryta i obsłużona podatność
- Zmiana projektu wpływająca na bezpieczeństwo
- Aktualizacja norm (jeśli zmieniają się stosowane normy)
- Zmiany w SBOM (nowe/zaktualizowane komponenty)

PRZEGLĄDY OKRESOWE:
- Kwartalnie: SBOM i status podatności
- Rocznie: pełny przegląd dokumentacji technicznej
- Przed końcem okresu wsparcia: ostateczne zamrożenie dokumentacji

KONTROLA WERSJI:
- Wszystkie dokumenty pod kontrolą wersji
- Utrzymywana historia zmian
- Wcześniejsze wersje archiwizowane

Wymogi przechowywania

Przechowywanie dotyczy całej dokumentacji technicznej, łącznie z wcześniejszymi wersjami SBOM, raportami z testów i decyzjami dotyczącymi ryzyka. Plan przechowywania powinien przewidywać dostęp w ciągu 48 godzin od żądania organu oraz ochronę integralności przez cały okres retencji.

PRZECHOWYWANIE DOKUMENTACJI

Okres przechowywania: co najmniej 10 lat od wprowadzenia na rynek lub okres wsparcia, w zależności od tego, który jest dłuższy (art. 13 ust. 13)

Przykładowy harmonogram:
- Produkt po raz pierwszy wprowadzony na rynek: marzec 2027
- Ostatnia sztuka wprowadzona na rynek: grudzień 2030
- Przechowywanie dokumentacji do: grudnia 2040

Wymogi składowania:
- Bezpieczne, dostępne miejsce składowania
- Procedury kopii zapasowych
- Ochrona integralności
- Dostępność w ciągu [48 godzin] od żądania organu

Częste błędy

Poniżej najczęstsze błędy obserwowane w dokumentacji składanej organom nadzoru rynku. Każdy z nich można uniknąć dzięki konsekwentnej kontroli wersji, identyfikowalności wymagań oraz powiązaniu dowodów z konkretnymi sekcjami załącznika VII.

Niekompletna ocena ryzyka

Problem: Ocena ryzyka, która nie obejmuje wszystkich zagrożeń lub nie zawiera szczegółów postępowania.

Rozwiązanie: Stosuj uporządkowaną metodykę. Powiąż każde zidentyfikowane ryzyko z zabezpieczeniem lub decyzją o akceptacji.

Brak SBOM

Problem: Brak SBOM lub SBOM nieobejmujący zależności tranzytowych.

Rozwiązanie: Generuj SBOM przy użyciu właściwych narzędzi. Uwzględnij pełne drzewo zależności.

Nieaktualna dokumentacja

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

Rozwiązanie: Aktualizuj dokumentację z każdym wydaniem. Wyraźnie śledź wersje.

Brak identyfikowalności wymagań

Problem: Deklaracja zgodności bez wykazania, jak spełniono każde wymaganie.

Rozwiązanie: Stwórz jawne mapowanie każdego wymagania z załącznika I do dowodów.

Testy bez dowodów

Problem: Deklaracja przeprowadzenia testów bez dostępnych raportów.

Rozwiązanie: Zachowuj wszystkie raporty z testów. Włącz je do dokumentacji technicznej lub wyraźnie do nich odnieś.

Lista kontrolna dokumentacji technicznej

Poniższa lista pomaga zweryfikować kompletność dokumentacji przed zgłoszeniem produktu do oceny zgodności. Każda pozycja powinna mieć powiązany dowód: dokument, raport lub wyraźne odniesienie do zewnętrznego artefaktu.

LISTA KONTROLNA KOMPLETNOŚCI DOKUMENTACJI TECHNICZNEJ

SEKCJA 1 - OPIS OGÓLNY:
[ ] Identyfikacja produktu kompletna
[ ] Przeznaczenie udokumentowane
[ ] Klasyfikacja CRA podana z uzasadnieniem
[ ] Informacje o wprowadzeniu na rynek

SEKCJA 2 - PROJEKTOWANIE, ROZWÓJ I OBSŁUGA PODATNOŚCI:
[ ] Diagramy architektury
[ ] Dokumentacja projektu zabezpieczeń
[ ] Opis procesu rozwoju
[ ] Procedury zarządzania zmianami
[ ] Udokumentowane metody kontaktu w sprawie podatności
[ ] Opublikowana polityka CVD
[ ] Udokumentowany proces obsługi podatności
[ ] Wdrożone procedury zgłaszania do ENISA

SEKCJA 3 - OCENA RYZYKA:
[ ] Udokumentowana metodyka
[ ] Zidentyfikowane wszystkie ryzyka
[ ] Decyzje dotyczące postępowania z każdym ryzykiem
[ ] Ocena ryzyka rezydualnego

SEKCJA 4 - INFORMACJE O OKRESIE WSPARCIA:
[ ] Zadeklarowany okres wsparcia (daty początku i końca)
[ ] Udokumentowane przesłanki z art. 13 ust. 8 (czas użytkowania, oczekiwania użytkowników, prawo sektorowe)
[ ] Zarejestrowane uzasadnienie (harmonogramy wsparcia komponentów, umowy z klientami, EOL sprzętu)
[ ] Zatwierdzenie decyzji (produkt, bezpieczeństwo, dział prawny)

MAPOWANIE ZAŁĄCZNIKA I (wspiera sekcje 5-7):
[ ] Mapowanie załącznika I część I kompletne
[ ] Mapowanie załącznika I część II kompletne
[ ] Dowody przypisane do każdego wymagania

SEKCJA 5 - NORMY:
[ ] Wszystkie zastosowane normy wymienione
[ ] Dostarczone dowody zastosowania
[ ] Odstępstwa udokumentowane i uzasadnione

SEKCJA 6 - WYNIKI TESTÓW:
[ ] Plan testów udokumentowany
[ ] Załączone raporty z testów
[ ] Wszystkie ustalenia zaadresowane

SEKCJA 7 - DEKLARACJA ZGODNOŚCI:
[ ] Deklaracja zgodności włączona/przywołana

SEKCJA 8 - SBOM (na uzasadnione żądanie):
[ ] Przygotowany maszynowo czytelny SBOM (CycloneDX lub SPDX)
[ ] Wszystkie komponenty włączone (bezpośrednie + tranzytowe)
[ ] Udokumentowany status podatności
[ ] Dostępny dla organu nadzoru na żądanie

UTRZYMANIE:
[ ] Ustanowiona kontrola wersji
[ ] Udokumentowane procedury aktualizacji
[ ] Wdrożony plan przechowywania