CRA Dokumentacja techniczna: przewodnik

Dokumentacja techniczna to pakiet dowodów potwierdzających zgodność z CRA. Organy nadzoru rynku mogą jej zażądać, a jednostka notyfikowana sprawdzi ją wtedy, gdy wybrana ścieżka oceny zgodności ją obejmuje. Bez kompletnej dokumentacji technicznej nie można legalnie wprowadzić produktu na rynek UE.

Niniejszy przewodnik omawia dokumentację techniczną sekcja po sekcji, wyjaśniając, jakich dowodów wymaga każdy obszar i jak je przygotować.

Czym jest dokumentacja techniczna?

Dokumentacja techniczna (nazywana również "teczką techniczną") to kompletny pakiet dowodów potwierdzających, że produkt spełnia zasadnicze wymagania w zakresie cyberbezpieczeństwa.

Czym nie jest:

• Dokumentacją marketingową
• Wyłącznie instrukcją użytkownika
• Odhaczaniem pól na liście kontrolnej

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

Co musi zawierać dokumentacja techniczna

Dokumentacja techniczna jest łatwiejsza do oceny, gdy jest zorganizowana wokół ośmiu obszarów dowodowych:

Sekcja 1: Opis ogólny

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

Wymagana zawartość

Przykład

GENERAL DESCRIPTION

Product Name: SmartSense Pro Industrial Sensor
Model Number: SSP-3000
Hardware Version: Rev C (PCB v3.2)
Firmware Version: 2.4.1

INTENDED PURPOSE:
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.

TARGET USERS:
- Facility managers
- Industrial automation integrators
- Environmental compliance officers

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

NOT INTENDED FOR:
- Medical or life-safety applications
- Outdoor installation
- Explosive atmospheres
- Consumer/residential use

CRA CLASSIFICATION:
Default product. Not classified as important or critical.
Justification: General-purpose sensor without security
functions or critical infrastructure application.

EU MARKET PLACEMENT:
First placed on market: March 15, 2027
Target markets: All EU member states
Distribution: Direct sales and authorized distributors

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

Cel: Udokumentować, w jaki sposób produkt został zaprojektowany i zbudowany, jak obsługiwane są podatności po wydaniu oraz w jaki sposób walidowane są procesy produkcji i monitorowania. Traktuj te elementy jako jeden blok dowodowy: zapisy projektowania i rozwoju, procesy obsługi podatności oraz kontrole produkcji i monitorowania, które pokazują, że wydania są budowane i nadzorowane w sposób spójny.

Projektowanie i rozwój: wymagana zawartość

Jak wygląda dokumentacja "secure by design"

SECURITY ARCHITECTURE OVERVIEW

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

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

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

4. UPDATE MECHANISM
   - 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ść

Dokumentacja obsługi podatności

VULNERABILITY HANDLING PROCEDURES

1. CONTACT METHODS
   Primary: security@company.com
   Web Form: https://company.com/security/report
   security.txt: https://company.com/.well-known/security.txt
   CVD Policy: https://company.com/security/disclosure-policy

2. RESPONSE COMMITMENTS
   Acknowledgment: Within 3 business days
   Initial Assessment: Within 10 business days
   Status Updates: Every 14 days
   Resolution Target: 90 days (critical: 7 days)

3. INTERNAL PROCESS
   [Flowchart or process description]
   See: Process Document PD-VULN-003

4. PATCH DISTRIBUTION
   Mechanism: OTA updates via cloud infrastructure
   Notification: In-app notification + email to registered users
   Verification: Signed updates with rollback capability

5. ZGŁASZANIE DO KOORDYNUJĄCEGO CSIRT I ENISA
   Trigger: Active exploitation detected
   Timeline: 24h early warning, 72h detailed report
   Responsible: Security Team Lead
   Process: See PD-ENISA-001

6. HISTORICAL RECORD
   Vulnerabilities handled (past 24 months): 3
   Average resolution time: 45 days
   ENISA reports filed: 0

Produkcja i monitorowanie: wymagana zawartość

W przypadku oprogramowania nie istnieje fizyczna linia produkcyjna. Produkcja i monitorowanie oznaczają potok budowy i wydania wytwarzający artefakty gotowe do dystrybucji, walidację potwierdzającą, że procesy te działają zgodnie z założeniem, oraz monitorowanie powdrożeniowe, które wychwytuje regresje i nowe podatności. Każdy z tych obszarów udokumentuj tak, aby audytor mógł prześledzić wydanie aż do zweryfikowanej, odtwarzalnej kompilacji.

Dokumentacja produkcji i monitorowania

PRODUCTION AND MONITORING PROCESSES

Product: Industrial Gateway IG-200
Build platform: GitHub Actions on ubuntu-22.04 runners
Provenance: SLSA Level 3 (signed in-toto attestations)
Signing: Cosign + Sigstore, offline KMS-backed root key

BUILD PIPELINE:
1. Source: github.com/example/ig200-firmware (main branch protected,
   2-of-N review gate, signed commits required)
2. Build: reproducible cross-compile (rustc 1.78, locked Cargo.lock)
3. SAST: cargo-audit + clippy security lints (gate: 0 high+ findings)
4. SCA: trivy scan against built binary (gate: 0 known-exploitable CVEs)
5. Test: regression suite (1247 tests) + essential requirements conformance suite (89 tests)
6. Sign: cosign sign-blob + attest --predicate slsa-provenance.json
7. Release: artifact + SBOM (CycloneDX 1.5) + DoC excerpt published

VALIDATION OF PROCESSES:
- Pipeline definition reviewed quarterly (Security Lead + Release Manager)
- Essential requirements conformance test suite reviewed when standards or risks change
- Annual reproducibility audit (independent rebuild from tagged source)
- Failure mode: any gate fails -> release blocked, incident logged

POST-DEPLOYMENT MONITORING:
- Dependency CVE feed: Trivy + Renovate, daily scan against current SBOM
- Threshold: Critical or High with KEV match -> patch within 7 days
- Threshold: Medium without KEV -> patch in next monthly release
- Customer notification: signed RSS feed + email for advisories
- Internal telemetry: failed update events, signature verification failures
- Review cadence: weekly triage, monthly trend review

Sekcja 3: Ocena ryzyka w zakresie cyberbezpieczeństwa

Cel: Przechowywać zatwierdzoną ocenę ryzyka i pokazywać, gdzie w dokumentacji znajdują się jej dowody.

Sposób przeprowadzenia oceny, mapowanie stosowalności wszystkich 13 wymagań bezpieczeństwa, przykład z życia oraz gotowy do skopiowania szkielet dokumentu znajdują się w dedykowanym przewodniku po ocenie ryzyka cyberbezpieczeństwa. Ta sekcja dokumentacji technicznej przechowuje jej wyniki. Ocena i decyzje o stosowalności to wymóg prawny. Zapisy zatwierdzenia i historia wersji to praktyka pokazująca, że dokument pozostaje aktualny.

Wymagana zawartość

Format oceny ryzyka

Skorzystaj ze szkieletu dokumentu z przewodnika po ocenie ryzyka. Zawiera on format rejestru, zapis stosowalności oraz przykład z życia. Złóż powstały dokument w tym miejscu bez zmian, tak aby wersja widziana przez organy była tą samą wersją, którą utrzymuje zespół.

Sekcja 4: Informacje o okresie wsparcia

Cel: Udokumentować uzasadnienie wybranego okresu wsparcia. Okres wsparcia to czas, w którym producent zobowiązuje się dostarczać aktualizacje bezpieczeństwa. Dokumentacja techniczna musi obejmować informacje, które wpłynęły na tę decyzję.

Wymagana zawartość

Jak wygląda dobra dokumentacja

SUPPORT PERIOD DETERMINATION
Product: Industrial Gateway IG-200
Market placement: 2026-09-01
Declared support period: 2026-09-01 to 2034-09-01 (8 years)

Rationale:
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.

Decision approved by: [Product Owner], [Security Lead], [Legal]
Date: 2026-08-15
Review trigger: any material change to component support timelines

Częste pułapki

• Zakotwiczenie w pięcioletnim minimum bez uzasadnienia. Pięć lat z reguły dotyczącej okresu wsparcia 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 zapisu 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 system operacyjny osiągnie EOL wcześniej niż zakładano), zapis decyzji musi zostać zaktualizowany, a zobowiązanie do wsparcia zakomunikowane.

Mapowanie wymagań zasadniczych

Cel: Wykazać, w jaki sposób spełnione jest każde zasadnicze wymaganie w zakresie cyberbezpieczeństwa.

Analiza dla poszczególnych wymagań mieści się w ocenie ryzyka. Jej zapis stosowalności odpowiada, dla każdego z 13 wymagań bezpieczeństwa, czy ma zastosowanie i jak jest wdrożone, wraz z pisemnym uzasadnieniem każdego wyłączenia. Przewodnik po ocenie ryzyka zawiera pełną tabelę mapowania, pytania kontrolne i typowe dowody dla każdego wymagania.

Wymagania części I

Przechowuj w dokumentacji technicznej:

• Aktualny zapis stosowalności z zatwierdzonej oceny ryzyka, jeden wpis na wymaganie.
• Odniesienie do dowodów dla każdego wymagania (raporty z testów, dokumenty projektowe, przeglądy konfiguracji), aby organ mógł przejść od każdej decyzji do jej dowodu.

Wymagania części II

Wymagania dotyczące obsługi podatności spełniają procesy, nie funkcje produktu. Przechowuj w dokumentacji technicznej odniesienia do dokumentów opisujących te procesy: identyfikację podatności i SBOM, usuwanie podatności i dystrybucję aktualizacji, harmonogram testów, praktykę ujawniania, politykę CVD oraz kontakt do zgłoszeń. Przewodnik po obsłudze podatności opisuje, co musi obejmować każdy z tych procesów.

Sekcja 5: Zastosowane normy

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

Wymagana zawartość

Format dokumentacji norm

APPLIED STANDARDS

HARMONIZED STANDARDS (presumption of conformity):
-------------------------------------------------------------
Standard: EN 303 645 (when harmonized for CRA)
Title: Cybersecurity for Consumer IoT
Status: Applied in full
Publication: OJEU [reference when published]
Evidence: Standards Compliance Report SCR-001
-------------------------------------------------------------

OTHER STANDARDS APPLIED:
-------------------------------------------------------------
Standard: IEC 62443-4-1:2018
Title: Security for Industrial Automation - Secure Development
Status: Applied (selected requirements)
Clauses Applied: 5, 6, 7, 8, 10
Evidence: SDL Documentation SLD-001
-------------------------------------------------------------
Standard: ISO/IEC 27001:2022
Title: Information Security Management
Status: Organization certified (Certificate #12345)
Relevance: ISMS covers product development processes
-------------------------------------------------------------
Standard: NIST Cybersecurity Framework 2.0
Title: Framework for Improving Critical Infrastructure Cybersecurity
Status: Reference framework for risk assessment
Evidence: Risk Assessment methodology document
-------------------------------------------------------------

DEVIATIONS:
-------------------------------------------------------------
Standard: EN 303 645
Clause: 5.3-2 (Unique per device credentials)
Deviation: Credentials unique per device but not pre-provisioned
Justification: Device requires user setup; credentials created
              during first-time configuration
Alternative Measure: Strong password requirements enforced,
                    account lockout after failed attempts
Risk Assessment: Residual risk acceptable (see R-015)
-------------------------------------------------------------

Sekcja 6: Wyniki testów

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

Wymagana zawartość

Format wyników testów

TEST RESULTS SUMMARY

Product: SmartSense Pro (SSP-3000) v2.4.1
Test Period: December 2026 - January 2027
Test Lead: [Name]

═══════════════════════════════════════════════════════════
TEST CAMPAIGN: TC-2027-001
═══════════════════════════════════════════════════════════

1. SECURITY FUNCTIONAL TESTING
   Scope: Authentication, authorization, encryption, secure boot
   Test Cases: 85
   Passed: 85
   Failed: 0
   Reference: Test Report TR-FUNC-001

2. VULNERABILITY SCANNING
   Tool: Trivy v0.48.0 + Nessus Professional
   Scope: Firmware, network services, web interface
   Findings:
     Critical: 0
     High: 0
     Medium: 2 (accepted with justification)
     Low: 5 (accepted)
   Reference: Scan Report SR-VULN-001

3. PENETRATION TESTING
   Provider: [Third-party firm name]
   Scope: Black-box testing of deployed device
   Duration: 5 days
   Findings:
     Critical: 0
     High: 0
     Medium: 1 (remediated before release)
     Low: 3 (accepted)
   Reference: Pentest Report PT-2027-001

4. FIRMWARE ANALYSIS
   Tool: EMBA v1.3
   Scope: Binary analysis, hardcoded credentials, crypto issues
   Findings:
     Critical: 0
     High: 0
     Informational: 4
   Reference: Firmware Analysis Report FA-001

5. CONFIGURATION REVIEW
   Scope: Default configuration security
   Findings: All defaults meet security requirements
   Reference: Configuration Review CR-001

═══════════════════════════════════════════════════════════
OVERALL ASSESSMENT: PASS
All critical and high findings remediated.
Medium/Low findings accepted with documented justification.
═══════════════════════════════════════════════════════════

Sekcja 7: Deklaracja zgodności UE

Cel: Dołączyć formalną deklarację lub odniesienie do niej.

Wymagana zawartość

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

Sekcja 8: Wykaz komponentów oprogramowania

Cel: Zapewnić przejrzystość komponentów na potrzeby śledzenia podatności. SBOM stanowi część dokumentacji technicznej, jest przechowywany przez producenta i udostępniany organowi nadzoru rynku na uzasadnione żądanie. W praktyce producenci przygotowują go i utrzymują równolegle z resztą dokumentacji.

Powiązane przewodniki: W przypadku produktów sprzętowych zachowuj dowody dotyczące komponentów fizycznych tam, gdzie wspierają one ocenę ryzyka, informacje dla użytkownika lub analizę podatności. BSI TR-03183 może pomóc w jakości SBOM, a VEX może komunikować status podatności komponentów. Zobacz przewodnik po wymaganiach SBOM dla wyboru formatu, poziomów jakości BSI TR-03183, zakresu HBOM i użycia VEX oraz przewodnik po zgłaszaniu podatności opisujący, jak VEX wspiera obowiązek "braku znanych podatności możliwych do wykorzystania".

Wymagana zawartość

Dokumentacja SBOM

Kiedy należy aktualizować dokumentację techniczną?

Żywa dokumentacja

Dokumentacja techniczna nie jest dokumentem statycznym:

Wymogi przechowywania

DOCUMENTATION RETENTION

Retention Period: at least 10 years from market placement, or the support period, whichever is longer

Example Timeline:
- Product first placed on market: March 2027
- Last unit placed on market: December 2030
- Documentation retention until: December 2040

Storage Requirements:
- Secure, accessible storage
- Backup procedures
- Integrity protection
- Available within [48 hours] of authority request

Częste błędy

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 wymaganych zależności najwyższego poziomu.

Rozwiązanie: Generuj SBOM przy użyciu właściwych narzędzi, obejmując co najmniej zależności najwyższego poziomu wymagane przez CRA (Załącznik I Część II(1)). Rozszerzenie na pełne drzewo zależności jest lepszą praktyką na potrzeby dopasowywania podatności, a nie minimalnym wymogiem prawnym.

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 zasadniczego wymagania na dowody.

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 odsyłaj.

Lista kontrolna dokumentacji technicznej