ENISA pisze do producentów. Kancelaria czyta to w trzech rolach naraz.

Cyber Resilience Act (rozporządzenie UE 2024/2847) jest dokumentem, który większość polskich kancelarii już słyszała, ale niewielu jeszcze widziała na biurku w wersji "co z tego wynika dla mojego klienta". Reguluje cyberbezpieczeństwo produktów z elementami cyfrowymi - od inteligentnego termostatu, przez wybrane biblioteki open-source udostępniane komercyjnie, po platformę SaaS używaną w kancelarii. Większość przepisów zacznie obowiązywać w grudniu 2027 - to jakieś dwadzieścia miesięcy od dziś. NIS2 (dyrektywa 2022/2555) jest w polskim porządku transponowana ustawą o krajowym systemie cyberbezpieczeństwa (proces nadrabiania opóźnienia legislacyjnego trwa od 2024 roku). ENISA, agencja UE odpowiedzialna za cyberbezpieczeństwo, w marcu 2026 wydaje dokument, który pokazuje co CRA ma w środku - przetłumaczone z prawa rozporządzenia na praktykę inżynieryjną.

ENISA wydała Security by Design and Default Playbook 19 marca 2026, w wersji 0.9 final draft, na licencji CC-BY 4.0. Tytuł deklaruje adresata jasno: A Practical Guide for SMEs. W praktyce każdy, kto kupuje, zamawia lub doradza w kwestii oprogramowania, znajdzie w playbooku siatkę pojęć, której będzie używał klient, regulator, audytor i druga strona umowy. Polska kancelaria ma trzy różne miejsca w tej siatce.

O czym jest ten materiał

Playbook ma sześć rozdziałów merytorycznych i trzy aneksy. Trzon to osiem zasad Security by Design i osiem zasad Security by Default, każda z nich rozwinięta w jeden lub kilka konkretnych playbooków (sekcja 4 dokumentu zawiera łącznie 22 playbooki). Zasady są zorganizowane w cztery grupy:

• Architectural Foundations - blueprint bezpieczeństwa: trust boundaries i threat modelling, least privilege, strong identity and authentication, attack surface minimisation, defence in depth, open design.
• Operational Integrity - utrzymanie bezpieczeństwa w czasie: lifecycle management, user-centric design, secure coding, logging i monitoring, configuration management, incident response, vulnerability management, supply chain controls.
• Default Hardening - stan fabryczny produktu ma być restrykcyjny: minimisation of default services, restrictive initial access, secure communication by default, unique device identity and secrets by default.
• Guided Protection - interfejs człowiek-system ma utrzymywać bezpieczny baseline: mandatory security onboarding, automated maintenance and updates, transparent security posture, secure recovery and ownership lifecycle.

Sekcja 5 wprowadza koncept Machine-Readable Security Manifest (MSRM) - cyfrowy artefakt w formacie JSON lub YAML, który deklaruje spełnienie konkretnych wymagań bezpieczeństwa w sposób weryfikowalny maszynowo. ENISA wprost zapowiada przejście od deklaracji bezpieczeństwa zapisywanych w statycznych dokumentach (PDF) do generowanych artefaktów wykazujących bezpieczeństwo - wprowadza dla tej zmiany własną terminologię: demonstrability (zdolność systemu do dostarczania obiektywnych, maszynowo czytelnych dowodów), verifiability (zdolność strony niezależnej do programowej walidacji) i reusability (możliwość wielokrotnego użycia istniejących atestacji). Aneks C - dla kancelarii najważniejszy - mapuje każdą zasadę playbooku do konkretnego punktu Annex I rozporządzenia 2024/2847 (Cyber Resilience Act). Tłumaczenie autorskie pojęć.

ENISA pisze inżynierską notatkę. Aneks C robi z niej dokument compliance.

Recenzja właściwa

Trzy role kancelarii wobec ENISA

Playbook nie wspomina kancelarii prawnych ani razu. Adresat formalny to wytwórca produktów z elementami cyfrowymi - producent oprogramowania, urządzenia IoT, platformy SaaS. Z perspektywy polskiej kancelarii dokument działa jednak w trzech rolach, każda z innym ciężarem operacyjnym.

Rola pierwsza: kancelaria-klient. Kancelaria zamawia oprogramowanie biurowe, system DMS, narzędzia AI, dostęp do bazy orzeczniczej, asystenta voice-to-text. Wszystkie te kategorie produktów wchodzą stopniowo pod CRA. Playbook ENISA jest dla kancelarii listą pytań, które ma postawić dostawcy w fazie due diligence. Czy stosujesz threat modelling? Czy używasz unique device identity, czy wszyscy klienci dzielą tę samą parę kluczy? Jakie masz lifecycle management - kiedy przestajesz wydawać patche bezpieczeństwa? Czy masz Machine-Readable Security Manifest, czy tylko PDF z deklaracją prezesa?

Rola druga: kancelaria-vendor. Część kancelarii już dziś wytwarza własne narzędzia cyfrowe oddawane klientom - automatyzacje przepływów dokumentów, dashboardy compliance, generatory pism, agenty AI doradzające pracownikom klienta. Pytanie, na które ENISA pomaga odpowiedzieć, brzmi: czy te narzędzia podpadają pod CRA? Odpowiedź: zależy. Definicja produktu z elementami cyfrowymi w art. 3 CRA jest szeroka. Kancelarie, które oddają klientowi software jako część usługi, powinny wykonać własną analizę zakresu - i playbook ENISA jest dobrą siatką pojęć do tego procesu.

Rola trzecia: kancelaria-doradca. Klient kancelarii - software house, producent IoT, fintech - ma od grudnia 2027 obowiązek pokazać zgodność z CRA. Playbook ENISA jest mapą operacyjną, dzięki której kancelaria nie zaczyna pracy nad compliance klienta od zera. Aneks C jest gotową siatką: każdy wymóg Annex I CRA ma odpowiadającą sobie zasadę playbooku, każda zasada ma odpowiedni playbook, każdy playbook ma zestaw konkretnych pytań do zadania zespołowi inżynierskiemu klienta.

Architectural Foundations: trzy zasady, które trafiają do umowy IT

Z grupy Architectural Foundations trzy zasady mają najbezpośrednie przełożenie na klauzule umów IT, w których kancelaria reprezentuje klienta-nabywcę.

Trust boundaries i threat modelling. ENISA argumentuje, że bezpieczne architektury czynią zaufanie jawnym, a nie zakładanym (tłumaczenie autorskie z opisu zasady w sekcji 3.1). W kontraktowej praktyce oznacza to klauzulę żądającą od dostawcy dokumentu threat model dla kupowanego produktu - identyfikującego, gdzie dane użytkownika kancelarii (a więc też dane klientów kancelarii, w tym objęte tajemnicą zawodową) przekraczają granice zaufania. Chmura dostawcy - granica. Subprocesor dostawcy - granica. API integracji - granica. Każda powinna mieć przypisane controls.

Least privilege. Zasada banalna w retoryce, kosztowna w praktyce. Klient kancelarii zamawiający platformę SaaS powinien wymagać, by konfiguracja domyślna była najbardziej restrykcyjną z możliwych - role administracyjne dostępne tylko po explicit grant, MFA wymagane od pierwszego logowania, sesje wygaszane po krótkim czasie. Klauzula umowna: "Dostawca ustawia konfigurację domyślną zgodnie z zasadą least privilege; rozluźnienie konfiguracji wymaga pisemnej zgody Klienta i jest dokumentowane w logach systemowych."

Supply chain controls. Tu Playbook robi rzecz, której kancelarie powinny się nauczyć szybko. Wymaga, by dostawca utrzymywał inwentarz komponentów (Software Bill of Materials), monitorował podatności w łańcuchu dostaw, dokumentował cryptographic provenance buildów. W praktyce to klauzula SBOM w umowie - dostawca dostarcza SBOM w czytelnym formacie (CycloneDX, SPDX), aktualizuje go przy każdej wersji, raportuje znane CVE w komponentach łańcucha. Bez tego CRA z 2027 roku zostawi kancelarię i klienta bez argumentu w razie incydentu.

Default Hardening: stan fabryczny ma być bezpieczny, nie wygodny

Z grupy Default Hardening jedna zasada potrafi w praktyce blokować zakup całego produktu. Restrictive Initial Access - w tłumaczeniu autorskim z sekcji 3.2.1 - oznacza eliminację uniwersalnych poświadczeń typu admin/admin oraz wymuszenie unikalnych haseł i obowiązkowej zmiany hasła przy pierwszym uruchomieniu. W postępowaniu due diligence klauzula umowna brzmi: "Dostawca dostarcza produkt w konfiguracji wymagającej ustawienia unikalnego hasła administratora przy pierwszym uruchomieniu; brak konfiguracji domyślnej w postaci stałego hasła lub konta serwisowego z hasłem fabrycznym."

Kancelaria, która tego nie wymusi w umowie, w incydencie nie ma na czym budować argumentu o niedbalstwie dostawcy. Po grudniu 2027 ten argument jest wbudowany w CRA. Do tego momentu trzeba go negocjować ręcznie.

Machine-Readable Security Manifest: kierunek, który zmienia rolę kancelarii

Sekcja 5 playbooku jest cicha, ale ważniejsza niż się wydaje. ENISA opisuje przejście od deklaracji bezpieczeństwa w PDF - statycznej, podpisanej raz, leżącej w folderze - do machine-readable security manifest. To artefakt cyfrowy generowany przez pipeline produkcyjny dostawcy, podpisany kryptograficznie, weryfikowalny automatycznie przez klienta lub regulatora.

Dla kancelarii to nie jest abstrakcja. Trzy konsekwencje praktyczne. Pierwsza: klauzule umowne przesuwają się ze "Dostawca dostarcza Politykę Bezpieczeństwa" w stronę "Dostawca udostępnia Klientowi machine-readable manifest w formacie wskazanym przez ENISA, aktualizowany przy każdym release". Druga: due diligence kancelarii klienta przy zakupie SaaS przestaje być dokumentem PDF audytora - staje się weryfikacją kryptograficznego śladu manifestu. Trzecia: spór sądowy o naruszenie security klauzuli w umowie wymaga dowodu z artefaktu cyfrowego, nie z papierowego raportu.

To wymaga od kancelarii kompetencji, która jeszcze niedawno była zarezerwowana dla działu IT klienta - umiejętności czytania YAMLa i JSON jako materiału dowodowego. W ciągu dwóch lat ta kompetencja przesunie się z gadżetu do podstawy.

CRA Annex I: aneks, który robi z dokumentu narzędzie compliance

Aneks C playbooku jest dwustronicową tabelą mapującą każdą z 16 zasad bezpieczeństwa na konkretne wymagania Annex I rozporządzenia 2024/2847 (CRA). To jest dokładnie to, czego klient-producent, doradzany przez kancelarię, potrzebuje, żeby zorganizować swój własny compliance roadmap. Bez Aneksu C interpretacja Annex I CRA wymaga inżynierskiej imaginacji - sformułowanie z Annex I, sekcja 1, mówiące o "an appropriate level of cybersecurity based on the risks", w pustce nic nie znaczy operacyjnie. Z Aneksem C interpretacja jest mapą: zasada A → wymóg X1 → playbook Px → konkretne pytania kontrolne.

Krytyczny detal dla kancelarii: Aneks C nie ma mocy wiążącej - to dokument ENISA, nie akt delegowany Komisji. Klient nie może powołać się na zgodność z Aneksem C jako automatyczną zgodność z CRA. Może natomiast użyć go jako wewnętrznej mapy compliance, którą kancelaria pomaga uporządkować w dokument formalny.

Czego ENISA nie pokrywa

Playbook unika pewnych obszarów. Po pierwsze - nie pisze o AI Act. Cyber Resilience Act i AI Act są różnymi rozporządzeniami, regulującymi inne aspekty produktu. Klient, który wytwarza system AI wysokiego ryzyka w sensie AI Act, dostaje od ENISA wskazówki dotyczące jego cyberbezpieczeństwa, ale nie jego transparentności, biasu, human oversight - tych zagadnień playbook świadomie nie podejmuje. Kancelaria doradzająca producentowi LLM dla sektora medycznego musi czytać ENISA i osobno przewodniki AI Act.

Po drugie - nie pisze o NIS2. Polska transpozycja dyrektywy 2022/2555 dotyczy operatorów usług istotnych i ważnych, a nie producentów produktów. ENISA zostawia tę warstwę poza zakresem playbooku, choć wiele klauzul kontraktowych w praktyce kancelaryjnej miesza wymagania CRA i NIS2. To zostaje na kancelarię.

Po trzecie - nie pisze o RODO. Choć security by design jest oryginalnie konceptem z artykułu 25 RODO, ENISA w marcowym playbooku traktuje ochronę danych osobowych jako sąsiednią dziedzinę, nie zintegrowaną. Klauzule przetwarzania danych osobowych pisane w 2026 roku potrzebują obu warstw, łączonych ręcznie.

Co z tego wynika

ENISA Security by Design and Default Playbook jest dla polskiej kancelarii dokumentem o wysokim wskaźniku użyteczności do wagi: 68 stron, dwadzieścia dwie konkretne praktyki, kilka stron mapowania do CRA Annex I. Nie zastępuje wiedzy specjalistycznej z cyberbezpieczeństwa, ale - i to jest jego zaleta - sprawia, że kancelaria wymieniająca uprzejmości z CISO klienta nie pracuje na niedopowiedzeniach.

Dla kogo ten materiał. Dla radcy prawnego negocjującego umowę o wdrożenie systemu informatycznego. Dla compliance officera kancelarii układającego klauzule SBOM i incident response w umowach z dostawcami SaaS. Dla doradcy klienta wytwarzającego oprogramowanie - producenta software, IoT, platformy fintech - który ma w grudniu 2027 pokazać zgodność z CRA. Dla każdego, kto za pół roku usłyszy od klienta pytanie "musimy mieć ten manifest, czy nie".

Dla kogo nie. Dla kancelarii, która w cyberbezpieczeństwie chce jednorazowo "zaktualizować politykę bezpieczeństwa". Playbook ENISA jest dokumentem, którego sens leży w iteracyjnym wdrażaniu - zasada po zasadzie, kontrakt po kontrakcie, klient po kliencie. Zaczyna się trudno, ale z każdym tygodniem rośnie zwrot z czasu zainwestowanego.