CRACompliance
22 PLAYBOOKS • IMPLEMENTATION

CRA Secure by Design – od kontroli do ownera i evidence

Nie kolejny artykuł o zasadach. To operacyjna checklista 22 obszarów: control → owner → implementation → evidence → CRA requirement, oparta na technicznym playbooku ENISA i mapowaniu do Annex I.

Zweryfikowano w źródłach: 28 sierpnia 2026
FREE TOOL • BEZ KONTA

Secure by Design Implementation Checklist

Nadaj status każdej z 22 kontroli. Checklistę możesz wykorzystać do planowania backlogu i evidence mappingu; dane nie opuszczają tej karty przeglądarki.

WDROŻONE LUB ZWERYFIKOWANE0 / 22
  • 22 nie rozpoczęto
  • 0 zaplanowano
  • 0 wdrożono
  • 0 zweryfikowano
01

Trust boundaries i threat modelling

OWNER
Product Security / Architect
IMPLEMENTATION
Zdefiniuj aktywa, granice zaufania, przepływy danych, abuse cases i założenia bezpieczeństwa przed zamrożeniem architektury.
EVIDENCE
diagram przepływów i trust boundaries • threat model z właścicielami mitigations
CRA REQUIREMENT
Annex I Part I 12(d–f)2(j)
02

Least privilege

OWNER
IAM Owner / Engineering
IMPLEMENTATION
Nadaj komponentom, administratorom i użytkownikom minimalny zakres uprawnień oraz okresowo go weryfikuj.
EVIDENCE
macierz ról i uprawnień • testy negatywne autoryzacji
CRA REQUIREMENT
Annex I Part I 2(d)2(f–g)
03

Silna tożsamość i uwierzytelnianie

OWNER
IAM Owner / Architect
IMPLEMENTATION
Projektuj jednoznaczną identyfikację, bezpieczne uwierzytelnianie i kontrolę cyklu życia poświadczeń.
EVIDENCE
model tożsamości • wyniki testów MFA i recovery
CRA REQUIREMENT
Annex I Part I 2(d)2(l)
04

Minimalizacja powierzchni ataku

OWNER
Product Architect
IMPLEMENTATION
Usuń zbędne endpointy, protokoły, porty i funkcje oraz uzasadnij każdy pozostawiony interfejs.
EVIDENCE
inventory interfejsów • baseline usług i portów
CRA REQUIREMENT
Annex I Part I 2(b)2(j)
05

Defence in depth

OWNER
Security Architect
IMPLEMENTATION
Łącz niezależne warstwy prewencji, detekcji, izolacji i odzyskiwania bez opierania bezpieczeństwa na pojedynczej kontroli.
EVIDENCE
diagram warstw zabezpieczeń • scenariusze awarii kontroli
CRA REQUIREMENT
Annex I Part I 2(h)2(k)
06

Open design

OWNER
Security Architect
IMPLEMENTATION
Nie uzależniaj bezpieczeństwa od tajności projektu; chroń sekrety i klucze, ale dokumentuj mechanizmy i założenia.
EVIDENCE
architecture decision records • rejestr sekretów i rotacji
CRA REQUIREMENT
Annex I Part II 34
07

Lifecycle management

OWNER
Product Owner
IMPLEMENTATION
Zaplanuj wspierane wersje, okres wsparcia, aktualizacje, EOL i bezpieczne wycofanie produktu.
EVIDENCE
lifecycle policy • support-period decision record
CRA REQUIREMENT
Annex I Part I 2(c)2(m)Part II 2, 7
08

User-centric security

OWNER
UX / Product
IMPLEMENTATION
Projektuj bezpieczne ścieżki domyślne i komunikaty, które pozwalają użytkownikowi podejmować świadome decyzje.
EVIDENCE
security UX test • instrukcja bezpiecznej konfiguracji
CRA REQUIREMENT
Annex I Part I 2(b)
09

Secure coding

OWNER
Engineering Lead
IMPLEMENTATION
Wprowadź standard kodowania, code review, SAST, SCA, secret scanning i kryteria naprawy przed release.
EVIDENCE
pipeline i policy gates • raporty review oraz testów
CRA REQUIREMENT
Annex I Part I 2(a)Part II 1, 3
10

Logging, monitoring i alerting

OWNER
Security Operations
IMPLEMENTATION
Rejestruj istotne zdarzenia bez nadmiarowych danych, chroń integralność logów i kieruj alerty do obsadzonego procesu.
EVIDENCE
logging standard • test alertu i retencji
CRA REQUIREMENT
Annex I Part I 2(d)2(l)
11

Configuration i change management

OWNER
Platform / Release Manager
IMPLEMENTATION
Kontroluj konfigurację bazową, zmiany, wyjątki i rollback; wykrywaj nieautoryzowany drift.
EVIDENCE
configuration baseline • change i rollback records
CRA REQUIREMENT
Annex I Part I 2(d)2(f)
12

Incident response i recovery

OWNER
Incident Response Owner
IMPLEMENTATION
Przygotuj wykrywanie, eskalację, izolację, odzyskanie oraz połączenie z triage i reportingiem CRA.
EVIDENCE
incident playbook • wyniki tabletop i recovery test
CRA REQUIREMENT
Annex I Part I 2(h)2(k)
13

Vulnerability i patch management

OWNER
PSIRT / Product Security
IMPLEMENTATION
Utrzymuj intake, triage, remediation, CVD, aktualizacje i monitoring komponentów przez support period.
EVIDENCE
vulnerability handling policy • SLA, ticket i release evidence
CRA REQUIREMENT
Annex I Part II 1–24–8
14

Software supply chain

OWNER
Engineering / Procurement
IMPLEMENTATION
Prowadź inventory komponentów, oceniaj dostawców, integralność artefaktów i wpływ podatności zależności.
EVIDENCE
SBOM dla release • supplier due-diligence record
CRA REQUIREMENT
Annex I Part I 2(a)Part II 1, 7
15

Minimum usług domyślnych

OWNER
Product Owner / Platform
IMPLEMENTATION
Domyślnie wyłącz usługi, funkcje i dostęp, które nie są potrzebne do zamierzonego użycia.
EVIDENCE
default configuration test • lista wyłączonych funkcji
CRA REQUIREMENT
Annex I Part I 2(b)2(i–j)
16

Restrictive initial access

OWNER
IAM Owner
IMPLEMENTATION
Pierwsze uruchomienie nie może pozostawiać otwartego dostępu; wymuś ustanowienie unikalnej kontroli dostępu.
EVIDENCE
factory-default test • onboarding acceptance criteria
CRA REQUIREMENT
Annex I Part I 2(b)2(d)
17

Bezpieczna komunikacja domyślna

OWNER
Platform Security
IMPLEMENTATION
Wymuś uwierzytelnione i szyfrowane kanały dla danych i komend; odrzuć niebezpieczny downgrade.
EVIDENCE
TLS/protocol baseline • testy downgrade i certificate validation
CRA REQUIREMENT
Annex I Part I 2(b)2(e–f)
18

Unikalna tożsamość i sekrety urządzenia

OWNER
Device Security / Manufacturing
IMPLEMENTATION
Nie używaj wspólnych domyślnych haseł lub kluczy; bezpiecznie provisionuj, przechowuj i rotuj sekrety.
EVIDENCE
provisioning specification • test unikalności i rotacji
CRA REQUIREMENT
Annex I Part I 2(b)2(d–e)
19

Obowiązkowy security onboarding

OWNER
Product / UX
IMPLEMENTATION
Przed rozpoczęciem pracy przeprowadź użytkownika przez krytyczne ustawienia, poświadczenia i komunikację support period.
EVIDENCE
onboarding flow • test pominięcia krytycznych kroków
CRA REQUIREMENT
Annex I Part I 2(b)2(d)
20

Automatyczna konserwacja i aktualizacje

OWNER
Release Engineering
IMPLEMENTATION
Zapewnij bezpieczne, terminowe i weryfikowalne aktualizacje, jasne ustawienia automatyzacji oraz obsługę błędu aktualizacji.
EVIDENCE
signed update test • rollout i rollback evidence
CRA REQUIREMENT
Annex I Part I 2(b–c)Part II 2, 7
21

Transparentna security posture

OWNER
Product Security / Communications
IMPLEMENTATION
Udostępnij użytkownikowi stan bezpieczeństwa, wspierane wersje i istotne ustawienia bez ujawniania danych ułatwiających atak.
EVIDENCE
security status design • support i advisory pages
CRA REQUIREMENT
Annex I Part I 2(b)2(l)
22

Secure recovery i transfer ownership

OWNER
Product Owner / Engineering
IMPLEMENTATION
Zaprojektuj bezpieczny reset, odzyskanie i przekazanie własności z usunięciem poprzednich poświadczeń i danych.
EVIDENCE
recovery test • ownership-transfer test
CRA REQUIREMENT
Annex I Part I 2(b)2(d)2(m)

Statusy są przechowywane tylko w pamięci tej karty przeglądarki i znikną po odświeżeniu. Checklistę traktuj jako plan implementacji, nie dowód wykonania kontroli.

IMPLEMENTATION SYSTEM

Kontrola bez ownera i dowodu nie jest zamknięta

Każdy wiersz checklisty łączy intencję bezpieczeństwa z odpowiedzialnością operacyjną, sposobem wdrożenia i artefaktem, który pozwala wykazać wykonanie. Mapowanie do Annex I pomaga zbudować traceability, ale zakres powinien wynikać z risk assessment konkretnego produktu.

CONTROL→OWNER→IMPLEMENTATION→EVIDENCE→CRA REQUIREMENT

Jak używać checklisty w delivery?

  1. Scope: przypisz kontrolę do produktu, wersji, modułu i granicy systemu.
  2. Owner: wskaż jedną rolę odpowiedzialną za wynik, nawet jeżeli wykonawców jest wielu.
  3. Implementation: zamień opis na wymaganie, kryterium akceptacji lub zadanie.
  4. Evidence: zdefiniuj dowód przed implementacją i zachowaj go per release.
  5. Verification: dopiero test lub review zmienia „wdrożono” na „zweryfikowano”.

Granice aktualnego materiału ENISA

Playbook ENISA jest obecnie opisany jako Version 0.9 final draft. Stanowi techniczną pomoc dla producentów i zespołów produktowych, ale nie jest guidance prawnie wiążącym ani normą zharmonizowaną. Dlatego checklista nie przyznaje „pass/fail” dla CRA i nie tworzy domniemania zgodności.

FAQ

Najczęstsze pytania

Czy playbook ENISA jest prawnie wiążący?

Nie. Wykorzystany dokument ENISA to techniczny Version 0.9 final draft, a nie akt prawny, norma zharmonizowana ani formalne potwierdzenie zgodności. Wiążące wymagania wynikają z CRA.

Czy wdrożenie 22 kontroli oznacza zgodność z CRA?

Nie. Checklistę trzeba osadzić w risk assessment konkretnego produktu, jego przeznaczeniu, architekturze i support period. Status wdrożenia nie zastępuje testów ani evidence.

Co oznacza status „zweryfikowano”?

Powinien oznaczać istnienie dowodu niezależnego od samej deklaracji wdrożenia: wynik testu, review, zapis pipeline, zatwierdzony artefakt lub ćwiczenie procesu.

Czy checklistę można zapisać?

Obecna bezpłatna wersja działa lokalnie w pamięci karty i nie wysyła statusów na serwer. Do trwałego śledzenia przenieś wybrane kontrole, ownerów i dowody do własnego systemu lub CRA Workspace.

PRIMARY SOURCES

Oficjalne źródła

Reguły narzędzia opierają się na źródłach pierwotnych. Materiały guidance są niewiążące i nie zastępują oceny konkretnego przypadku ani aktualnego tekstu prawa.

RegulationRozporządzenie (UE) 2024/2847 – Cyber Resilience ActEUR-Lex · 23 października 2024Otwórz oficjalne źródło DraftSecurity by Design and Default Playbook – Version 0.9 final draftENISA · 30 lipca 2026Otwórz oficjalne źródło
SELF-SERVICE • ARTICLE 14

Sprawdź operacyjną gotowość procesu reportingowego

Płatny assessment prowadzi przez ownership, intake, triage, terminy 24h i 72h, final report, evidence oraz recordkeeping. Wynik powstaje automatycznie — bez rozmowy sprzedażowej.

ARTICLE 14 SELF-ASSESSMENTProdukt cyfrowyZobacz zakres i rozpocznij Cena i podatki są pokazane na stronie produktu • bez konsultanta