CRA dla startupów: szczupła zgodność z jednym inżynierem

Mały zespół wypuszcza połączony produkt, a CRA go obejmie. Główne obowiązki wchodzą w życie 11 grudnia 2027 r., zgłaszanie podatności już od 11 września 2026 r., więc to zadanie na teraz, nie na kiedyś. Startupy łapią się na dwóch rzeczach: wieloletni obowiązek wsparcia bezpieczeństwa powstaje w chwili pierwszego wprowadzenia produktu na rynek UE, a wszystko trzeba obsłużyć bez osobnego etatu ds. bezpieczeństwa.

Ten przewodnik jest dla założycieli i pierwszych inżynierów, którzy muszą osiągnąć zgodność z CRA bez przepłacania i bez nadmiarowej pracy. Pokazuje, co można bezpiecznie pominąć, czego pominąć nie wolno, i jak jedna osoba może odpowiadać za całość.

Czy CRA dotyczy Twojego startupu?

Cztery szybkie pytania wystarczą. CRA obejmuje produkty z elementami cyfrowymi, które łączą się z siecią lub innym urządzeniem i są udostępniane na rynku UE w ramach działalności komercyjnej.

Jeśli produkt mieści się w zakresie, kolejne pytanie brzmi, do której kategorii należy. To decyduje, czy wystarczy samoocena, czy potrzebna jest jednostka notyfikowana. Potwierdź to w przewodniku po klasyfikacji produktów, zanim poświęcisz choć dzień na cokolwiek innego.

Największa przewaga strukturalna: samoocena

Największą oszczędnością kosztową dla startupu jest to, że produkt spoza kategorii Important i Critical to produkt domyślny (Default). Dla takich produktów CRA dopuszcza samoocenę: całą pracę nad zgodnością wykonuje producent samodzielnie, podpisuje deklarację zgodności UE i nanosi oznakowanie CE. Bez jednostki zewnętrznej, bez opłaty za każdy produkt. Mechanika poszczególnych ścieżek jest opisana w przewodniku po ocenie zgodności. Sens dla startupu jest prosty: nie płacić za ocenę zewnętrzną, której nie potrzebuje.

Ulgi CRA dla startupów

CRA zawiera środki wsparcia napisane wprost z myślą o mikroprzedsiębiorstwach, małych i średnich przedsiębiorstwach oraz startupach. To, czy ulgi mają zastosowanie, zależy od wielkości firmy według standardowej definicji unijnej: mikroprzedsiębiorstwo zatrudnia mniej niż 10 osób i ma obrót lub sumę bilansową do 2 mln EUR, a małe przedsiębiorstwo zatrudnia mniej niż 50 osób i ma obrót lub sumę bilansową do 10 mln EUR.

Cztery ulgi, z których startup może realnie skorzystać:

• Uproszczona dokumentacja: mikro- i małe przedsiębiorstwa mogą składać dokumentację techniczną w uproszczonym formacie określonym przez Komisję, a jednostki notyfikowane muszą tę formę zaakceptować.
• Obniżone opłaty za ocenę zgodności: tam, gdzie produkt jednak wymaga jednostki notyfikowanej, szczególne potrzeby MŚP, w tym startupów, muszą zostać uwzględnione, a opłaty odpowiednio obniżone.
• Piaskownice regulacyjne: państwa członkowskie mogą tworzyć kontrolowane środowiska do rozwijania i testowania innowacyjnego produktu pod kątem CRA jeszcze przed wprowadzeniem go na rynek, z ułatwionym dostępem dla startupów.
• Bezpośrednie wsparcie: tam, gdzie to zasadne, państwa członkowskie prowadzą działania informacyjne i szkoleniowe oraz osobny kanał doradczy dla mniejszych firm, a Komisja wskazuje dostępne wsparcie finansowe.

Zgodność z jednym inżynierem

Nie potrzeba zespołu bezpieczeństwa. Potrzebna jest jedna odpowiedzialna osoba i krótka lista rzeczy działających automatycznie. Ta osoba utrzymuje dokumentację techniczną, ocenia napływające zgłoszenia podatności i podpisuje deklarację zgodności. Jedna osoba może pełnić tę rolę, ale trzeba uczciwie powiedzieć: bieżąca obsługa podatności, dostarczanie aktualizacji i dokumentacja to realna praca inżynieryjna, nie zajęcie na marginesie. Przewodnik po kosztach zgodności z CRA modeluje nakład pracy i budżet dla małego zespołu, dzięki czemu można sensownie zaplanować obsadę.

Trzy rzeczy warto zautomatyzować najpierw. Każda ma gotowe rozwiązanie w darmowych narzędziach, a razem pokrywają najbardziej widoczne wczesne obowiązki. To punkt wyjścia, nie cały obraz.

• Generuj SBOM w CI: CRA wymaga zestawienia komponentów oprogramowania obejmującego co najmniej zależności najwyższego poziomu, a narzędzia open source, takie jak Syft i Trivy, tworzą je przy każdym buildzie. Pełny zestaw narzędzi w przewodniku po generowaniu SBOM.
• Monitoruj podatności: skanuj zależności przy każdym buildzie i reaguj na wyniki na podstawie ryzyka, zanim dotrą do klientów. Dla zgodności z CRA liczy się to, czy producent ocenia i usuwa podatności, nie to, jakiego skanera używa.
• Opublikuj kontakt bezpieczeństwa: plik security.txt i działający adres bezpieczeństwa dają badaczom sposób na zgłoszenie problemu. Przewodnik po konfiguracji security.txt zawiera gotowy szablon.

Te trzy elementy to wczesne, szybkie zwycięstwa automatyzacji, nie cała praca. Obok nich stoją bezpieczne projektowanie, ocena ryzyka, dostarczanie aktualizacji i kontrole produktu. Dokumentacja techniczna rośnie razem z produktem, zamiast powstawać w pośpiechu tuż przed premierą, więc notatki architektoniczne i dotyczące bezpieczeństwa warto prowadzić na bieżąco. Wymaganą zawartość opisuje przewodnik po dokumentacji technicznej.

Proces obsługi podatności musi działać, zanim wejdą w życie obowiązki zgłoszeniowe 11 września 2026 r. Od tej daty aktywnie wykorzystywana podatność lub poważny incydent uruchamiają krótki zegar przez jednolitą platformę zgłoszeniową ENISA: wczesne ostrzeżenie w ciągu 24 godzin, potem pełniejsze powiadomienie w ciągu 72 godzin. Raport końcowy różni się w zależności od ścieżki. Dla aktywnie wykorzystywanej podatności termin to 14 dni od udostępnienia środka naprawczego lub łagodzącego. Dla poważnego incydentu termin to jeden miesiąc od powiadomienia w ciągu 72 godzin. Trzeba też poinformować dotkniętych użytkowników. Mechanika jest opisana w przewodniku po zgłaszaniu podatności.

Szybkie tempo wydań bez ponownej certyfikacji

Szybkie iterowanie nie oznacza ponownej oceny zgodności przy każdym sprincie. Do oceny zgodności trzeba wrócić dopiero po istotnej modyfikacji, czyli zmianie wprowadzonej po premierze, która wpływa na spełnianie wymagań zasadniczych albo zmienia przeznaczenie, dla którego produkt był oceniany. Aktualizacja bezpieczeństwa, która tylko zmniejsza ryzyko cyberbezpieczeństwa i nie zmienia przeznaczenia, generalnie nie jest istotną modyfikacją, podobnie jak drobna zmiana, na przykład dodanie języka interfejsu. Aktualizacja funkcjonalna, która poszerza powierzchnię ataku albo zmienia działanie produktu, już może nią być. Rutynowe poprawki i drobne aktualizacje trafiają więc do klientów bez ponownej oceny, a ponowna ocena jest potrzebna, gdy zmiana faktycznie zmienia to, czym produkt jest, albo jego profil ryzyka.

Obowiązki dla firm budujących na open source lub nim zarządzających

Dla startupu liczą się dwa fakty dotyczące open source. Po pierwsze, darmowe i otwarte oprogramowanie wchodzi w zakres CRA tylko wtedy, gdy jest dostarczane w ramach działalności komercyjnej. Oprogramowanie, którego opiekunowie nie monetyzują, zwykle nie jest działalnością komercyjną, ale monetyzacja obejmuje więcej niż samo pobieranie opłat za kod, więc płatne wsparcie i podobne ustalenia trzeba wziąć pod uwagę. Wniesienie kodu źródłowego do projektu, za który dana firma nie odpowiada, samo w sobie nie sprawia, że CRA zaczyna ją obejmować. Monetyzacja open source albo umieszczenie go w sprzedawanym produkcie wprowadza ten produkt w zakres na zwykłych zasadach.

Po drugie, CRA tworzy lżejszą rolę: opiekuna oprogramowania open source (open-source software steward), czyli organizacji innej niż producent, która utrzymuje rozwój oprogramowania open source przeznaczonego do użytku komercyjnego. Obowiązki opiekuna koncentrują się na udokumentowanej polityce cyberbezpieczeństwa i współpracy z organami. Zgłaszanie podatności dotyczy go w zakresie, w jakim jest zaangażowany w rozwój produktu, a zgłaszanie poważnych incydentów i powiadamianie użytkowników mają zastosowanie, gdy incydent dotyka systemów, które opiekun udostępnia na potrzeby tego rozwoju. Te obowiązki są lżejsze niż pełny zestaw obowiązków producenta. Jeśli startup jednocześnie opiekuje się projektem i sprzedaje produkt, warto jasno rozdzielić, którą rolę pełni w danej sytuacji, bo obowiązki się różnią.

Pięcioletni obowiązek wsparcia to problem modelu biznesowego

To część CRA, z której startup nie wyautomatyzuje się narzędziami. Okres wsparcia musi wynosić co najmniej pięć lat, a jeśli produkt ma być używany krócej niż pięć lat, okres wsparcia odpowiada temu krótszemu, oczekiwanemu czasowi użytkowania. W tym czasie trzeba obsługiwać podatności na podstawie ryzyka, usuwać je bez zbędnej zwłoki i dostarczać aktualizacje klientom.

Dla firmy na wczesnym etapie to realne zobowiązanie, nie formalność do odhaczenia:

• Obowiązek jest przypisany do produktu: powstaje w chwili pierwszego wprowadzenia produktu na rynek UE, a późniejszy pivot nie znosi go dla egzemplarzy już wprowadzonych na rynek.
• Trzeba go wycenić: jeśli marża nie pokrywa kosztu okresu wsparcia, cena jest źle ustawiona. Koszt wsparcia warto uwzględnić w ekonomice jednostkowej przed premierą, licząc się z tym, że będzie maleć w miarę stabilizowania się bazy kodu.
• Planuj na dziesięć lat, nie pięć: każda wydana aktualizacja bezpieczeństwa musi pozostać dostępna przez co najmniej 10 lat od wydania albo do końca okresu wsparcia, w zależności od tego, który termin jest dłuższy.
• Publikuj datę zakończenia: datę końca okresu wsparcia, przynajmniej miesiąc i rok, trzeba pokazać już w momencie zakupu. Warto ustalić ją świadomie, bo klienci i kupujący ją czytają.

Zobowiązanie da się uczynić bardziej znośnym, ale trzeba pamiętać, co faktycznie z niego zwalnia:

• Wybieraj stabilne zależności: każda szybko zmieniająca się biblioteka to lata utrzymania, na które firma się zapisuje. Warto stawiać na nudne, dobrze wspierane komponenty.
• Wersjonuj świadomie: definiuj generacje produktu i zaplanuj, jak wsparcie przechodzi między nimi, żeby nie utrzymywać nieograniczonego zbioru żywych wersji.
• Działania łagodzące nie zwalniają z obowiązku: pisemne przeniesienie wsparcia na nabywcę, depozyt kodu źródłowego (escrow) albo udostępnienie komponentów krytycznych dla bezpieczeństwa jako open source mogą utrzymać przepływ poprawek, ale żadne z tych działań samo w sobie nie znosi obowiązku.

Jeśli firma kończy działalność i nie może dłużej spełniać obowiązku, musi poinformować organy nadzoru rynku oraz, w miarę możliwości, swoich użytkowników, zanim zaprzestanie działalności. To, co dzieje się z pozostałym obowiązkiem po zniknięciu firmy z rynku, nie jest jednoznacznie uregulowane i zależy od jurysdykcji. Plan wygaszania działalności warto przygotować już teraz, póki jest to możliwe, i udokumentować go w dokumentacji technicznej.

Zgodność jako argument sprzedażowy i źródło finansowania

Dla startupu praca nad CRA może spełniać podwójną funkcję: otwiera dostęp do rynku UE i daje materiał dowodowy do pokazania klientowi korporacyjnemu albo inwestorowi.

Zbuduj pakiet due diligence raz. Zespoły zakupowe w UE mogą podczas wdrażania dostawcy zażądać aktualnego SBOM, podpisanej deklaracji zgodności UE oraz udokumentowanego procesu zgłaszania podatności z określonym czasem reakcji. To mocny dowód, nie potwierdzenie pełnej zgodności, bo gotowość ostatecznie zależy od spełnienia każdego wymagania zasadniczego. Mając te dokumenty zebrane w jednym miejscu, firma nie musi ich zbierać w pośpiechu później, a to ten sam pakiet, o który może zapytać dział technicznego due diligence inwestora.

Inwestorów interesuje, czy firma może legalnie sprzedawać. Naruszenie wymagań zasadniczych lub podstawowych obowiązków producenta wiąże się z karą administracyjną do 15 mln EUR lub 2,5% całkowitego rocznego obrotu na świecie, w zależności od tego, która wartość jest wyższa. Praktyczniej rzecz ujmując: produkt wprowadzony na rynek UE od 11 grudnia 2027 r. musi spełniać CRA, żeby mógł być tam sprzedawany. Przedstawienie zgodności jako dostępu do rynku i ograniczenia ryzyka wejścia na rynek UE trafia do zarządu lepiej niż przedstawienie jej jako kosztu.

Programy publiczne mogą sfinansować część tej pracy. Unijne instrumenty, takie jak Horyzont Europa, program Cyfrowa Europa i EIC Accelerator, wspierają cyberbezpieczeństwo i rozwój bezpiecznych produktów, a programy krajowe dokładają kolejne możliwości. Kwoty i kryteria kwalifikowalności różnią się, więc warto sprawdzić w krajowym hubie innowacji cyfrowych, co jest aktualnie dostępne. Wniosek warto oprzeć na budowaniu godnych zaufania, bezpiecznych produktów cyfrowych, a nie na odhaczeniu wymogu regulacyjnego.

Jeśli w rozmowach sprzedażowych pojawiają się certyfikaty bezpieczeństwa, warto wiedzieć, jak CRA ma się do nich. Pokrywanie się z systemem zarządzania bezpieczeństwem informacji (ISMS) opisuje przewodnik CRA a ISO 27001, a zespoły zajmujące się konsumenckim IoT powinny przeczytać przewodnik po EN 303 645.

Częste błędy startupów

• „Bezpieczeństwem zajmiemy się po rundzie finansowania”: przy ograniczonym runway dorabianie bezpieczeństwa po czasie pożera gotówkę, którą właśnie pozyskano. Podstawy warto wbudować od pierwszego sprintu.
• „Wyceniliśmy produkt bez obowiązku wsparcia”: wieloletnie utrzymanie bezpieczeństwa musi mieścić się w ekonomice jednostkowej. Jeśli się nie mieści, cena jest źle ustawiona.
• „Osoba odpowiedzialna za zgodność odeszła i nikt tego nie przejął”: jeśli dokumentację techniczną i proces zgłoszeniowy trzyma jedna osoba, jej odejście to luka w zgodności. Warto spisać, kto za co odpowiada.
• „Nabywca po prostu przejmie obowiązek”: umowa może przypisać pracę nad wsparciem komuś innemu, ale sama z siebie nie zdejmuje z firmy ustawowego obowiązku. Trzeba to jasno uregulować w warunkach transakcji i niczego nie zakładać z góry.
• „CRA doczepimy, jak wejdziemy na rynek UE”: jeśli użytkownicy z UE już mają dostęp do produktu, produkt już jest dostarczany na rynek UE, a dorabianie zgodności później oznacza przebudowę. Obowiązki na 2027 rok warto projektować od początku.
• „Jesteśmy za wcześnie w rozwoju, żeby to nas dotyczyło”: bycie startupem daje prawo do ulg, nie zwolnienie z obowiązku. Obowiązek powstaje przy pierwszym wprowadzeniu na rynek, niezależnie od etapu rozwoju firmy.