Compliance CE dla producentów Software i SaaS
Software sterujący urządzeniem przestał być kwestią umowy wdrożeniowej i RODO. Stał się przedmiotem homologacji produktowej – tak samo jak telewizor, pralka lub laptop.
Prawodawca unijny zbudował wokół oprogramowania trzeci, odrębny reżim – reżim produktowy, w którym sprawnie pomagamy się Państwu odnaleźć:
✓ Mapa regulacyjna produktu: które z pięciu reżimów (RED, CRA, Data Act, maszynowe, PLD) znajdują zastosowanie i w jakiej roli
✓ Wymogi już stosowane: ocena firmware’u i aplikacji towarzyszącej według norm serii EN 18031 (RED) oraz architektura dostępu do danych zgodna z Data Act
✓ Przygotowanie do wymagań kontrahentów hardware’owych: dokumentacja techniczna, SBOM, procedura zgłoszeń 24/72h, klauzule odpowiedzialności w umowach B2B
WSPARCIE BRANŻOWE
Sektory, w których pomagamy
Z naszych usług skorzystali już przedstawiciele następujących branż:
- Software house’y embedded / firmware
- Dostawcy aplikacji mobilnych do urządzeń IoT
- Integratorzy automatyki i systemów sterowania
- Producenci SaaS z komponentem AI
Dlaczego warto nam zaufać
Znamy dokumentację zgodności od strony producenta urządzeń. Dlatego precyzyjnie określamy, czego kontrahent hardware’owy będzie od Ciebie wymagał.
W zespole GuardCE pracują inżynierowie oraz radca prawny z wieloletnią praktyką compliance w firmach hardware i software.
Pracowaliśmy po stronie producentów urządzeń – podmiotów, które obecnie kierują do software house’ów aneksy umowne dotyczące SBOM, obsługi podatności i okresu wsparcia.
Architektura Twojego produktu, wykaz zależności i ustalenia audytu są objęte tajemnicą zawodową radcy prawnego.
Kalendarium Software House’u
4terminy wyznaczające obowiązki dostawców oprogramowania
NASZA OFERTA
Standardowe rodzaje wsparcia
Każdy pakiet odpowiada na jedno z najczęstszych wyzwań producentów i importerów – z góry określonym zakresem, efektem i końcowym rezultatem. Stała wycena oznacza, że ryzyko czasu pracy spoczywa po naszej stronie, nie po Twojej.
Najczęściej wybierane
Cyber Compliance Audit (RED + CRA) od 5.500 PLN netto
Analiza luk wobec aktualnie obowiązujących wymagań, oraz wymogów, niezbędnych do spełnienia przed grudniem 2027 roku.
Ustalenie roli: producent, dostawca komponentu, oprogramowanie open source czy usługa poza zakresem
Zgodność z EN 18031 dla urządzeń radiowych - wymóg bieżący, warunek deklaracji zgodności klienta
Klasyfikacja produktu pod CRA (domyślna / ważna klasa I–II / krytyczna) i wynikająca z niej ścieżka oceny
Analiza luk: bezpieczne ustawienia domyślne, kontrola dostępu, szyfrowanie, aktualizacje, logowanie
Ocena procesu obsługi podatności i gotowości do zgłoszeń 24h/72h (start: 11.09.2026)
Harmonogram wdrożenia pełnej zgodności do grudnia 2027 r.
Deadline - 12/2027
Technical File for Software (CRA) od 3.500 PLN netto
Dokumentacja techniczna w formie spełniającej wymogi zarówno klienta hardware'owego, jak również jednostki notyfikowanej
Opis produktu, architektura, zamierzone przeznaczenie i środowisko
Analiza ryzyka cyberbezpieczeństwa wg CRA
SBOM: zakres, format (SPDX/CycloneDX), proces aktualizacji
Polityka ujawniania podatności i informacja o okresie wsparcia dla użytkownika
Deklaracja zgodności UE z weryfikacją prawną (dla produktów samodzielnych)
Stała opieka
Compliance Watchguard od 1.250 PLN netto/miesiąc
Aktywny monitoring regulacji cyfrowych wraz z hotline
Monitoring CRA (akty wykonawcze, normy zharmonizowane), AI Act, Data Act, PLD
Kwartalne podsumowanie zmian z listą produktów i umów, których dotyczą
Alerty krytyczne: nowa norma, wytyczne Komisji, decyzja organu w Twojej kategorii
E-mail hotline (3h w miesiącu)
NASZA WSPÓŁPRACA
DFU lub DWU – Twój wybór
Wiemy, że masz różne zasoby wewnętrzne. Dlatego oferujemy dwa modele współpracy zamiast jednego wymuszonego standardu.
DFU – Done For You
“Zrób to za mnie”
Przygotowujemy dokumentację, analizę ryzyka, SBOM i klauzule umowne dla wskazanego produktu. Otrzymujesz kompletny pakiet gotowy do przedłożenia kontrahentowi lub jednostce notyfikowanej.
Wybierz jeśli:
- prowadzisz jeden lub dwa produkty, a kontrahent oczekuje dokumentacji w określonym terminie
- nie zatrudniasz osoby odpowiedzialnej za compliance
- potrzebujesz pakietu zamykającego wymagania konkretnej umowy
DWU – Done With You
“Zróbmy-to-wspólnie”
Wdrażamy wymagania regulacyjne w Twój proces wytwórczy: zasady secure-by-design w backlogu, generowanie SBOM w pipeline CI/CD, szablon dokumentacji technicznej dla każdego projektu, procedurę obsługi i zgłaszania podatności. Po zakończeniu projektu każdy nowy produkt powstaje zgodny z wymaganiami.
Wybierz jeśli:
- realizujesz projekty dla wielu producentów urządzeń, którzy formułują zbieżne wymagania
- dysponujesz tech leadem lub security ownerem gotowym przejąć proces
- zamierzasz oferować udokumentowaną zgodność regulacyjną jako element przewagi w postępowaniach ofertowych
FAQ
Odpowiedzi na najczęściej zadawane nam przez producentów pytania
Piszemy firmware na zlecenie producenta urządzenia. Czy CRA dotyczy nas, czy jego?
Rozstrzyga to rola w łańcuchu wprowadzania do obrotu oraz treść umowy. Jeżeli zamawiający wprowadza urządzenie do obrotu pod własną marką, to on jest producentem w rozumieniu CRA i ponosi odpowiedzialność za produkt jako całość, włącznie z dostarczonym oprogramowaniem.
Ciąży na nim jednak obowiązek zachowania należytej staranności przy integracji komponentów pochodzących od podmiotów trzecich - w praktyce oznacza to, że zażąda od dostawcy oprogramowania SBOM, informacji o zidentyfikowanych podatnościach oraz wsparcia przez cały cykl życia produktu.
Obowiązek publicznoprawny spoczywa na producencie; zakres świadczeń po stronie software house'u i ich wynagrodzenie określa umowa - dlatego warto ukształtować te postanowienia świadomie, zanim staną się przedmiotem aneksu narzuconego przez kontrahenta.
Ciąży na nim jednak obowiązek zachowania należytej staranności przy integracji komponentów pochodzących od podmiotów trzecich - w praktyce oznacza to, że zażąda od dostawcy oprogramowania SBOM, informacji o zidentyfikowanych podatnościach oraz wsparcia przez cały cykl życia produktu.
Obowiązek publicznoprawny spoczywa na producencie; zakres świadczeń po stronie software house'u i ich wynagrodzenie określa umowa - dlatego warto ukształtować te postanowienia świadomie, zanim staną się przedmiotem aneksu narzuconego przez kontrahenta.
Świadczymy usługi SaaS. Czy CRA znajduje do nas zastosowanie?
Usługa zdalnego przetwarzania danych co do zasady pozostaje poza zakresem CRA - z istotnym wyjątkiem.
Jeżeli rozwiązanie chmurowe jest niezbędne do wykonywania funkcji produktu z elementami cyfrowymi (przykładowo: backend warunkujący działanie kamery IP lub urządzenia wearable), wchodzi w zakres rozporządzenia jako „zdalne przetwarzanie danych" tego produktu i podlega ocenie łącznie z nim.
Granica przebiega na poziomie architektury rozwiązania, nie modelu biznesowego - jej ustalenie stanowi pierwszy etap audytu.
Jeżeli rozwiązanie chmurowe jest niezbędne do wykonywania funkcji produktu z elementami cyfrowymi (przykładowo: backend warunkujący działanie kamery IP lub urządzenia wearable), wchodzi w zakres rozporządzenia jako „zdalne przetwarzanie danych" tego produktu i podlega ocenie łącznie z nim.
Granica przebiega na poziomie architektury rozwiązania, nie modelu biznesowego - jej ustalenie stanowi pierwszy etap audytu.
Wykorzystujemy biblioteki open source. Czy podlegają one dokumentowaniu?
Tak - w SBOM oraz w analizie podatności. Komponenty open source włączone do produktu komercyjnego podlegają odpowiedzialności producenta na równi z komponentami własnymi. Oprogramowanie open source rozwijane poza działalnością komercyjną pozostaje poza zakresem CRA, jednak produkt, który je zawiera, podlega rozporządzeniu w całości.
Aktualny SBOM jest przy tym jedynym dowodem pozwalającym wykazać, że produkt nie zawiera komponentu z opublikowaną podatnością.
Aktualny SBOM jest przy tym jedynym dowodem pozwalającym wykazać, że produkt nie zawiera komponentu z opublikowaną podatnością.
Co zmienia się w zakresie odpowiedzialności za wady oprogramowania?
Dyrektywa Parlamentu Europejskiego i Rady (UE) 2024/2853 w sprawie odpowiedzialności za produkty wadliwe obejmuje oprogramowanie, w tym systemy AI, wprost zakresem pojęcia produktu.
Od 09.12.2026 wada produktu może polegać również na niedostarczeniu aktualizacji bezpieczeństwa niezbędnych do zachowania bezpieczeństwa produktu. Dyrektywa wprowadza ponadto ułatwienia dowodowe dla poszkodowanego, w tym obowiązek ujawnienia dowodów i domniemania wadliwości w określonych sytuacjach.
Postanowienia umowne typu „as-is" w relacjach B2B nie wyłączają odpowiedzialności wobec poszkodowanego konsumenta - zarządzanie tym ryzykiem wymaga odpowiedniego ukształtowania łańcucha umów i regresu.
Od 09.12.2026 wada produktu może polegać również na niedostarczeniu aktualizacji bezpieczeństwa niezbędnych do zachowania bezpieczeństwa produktu. Dyrektywa wprowadza ponadto ułatwienia dowodowe dla poszkodowanego, w tym obowiązek ujawnienia dowodów i domniemania wadliwości w określonych sytuacjach.
Postanowienia umowne typu „as-is" w relacjach B2B nie wyłączają odpowiedzialności wobec poszkodowanego konsumenta - zarządzanie tym ryzykiem wymaga odpowiedniego ukształtowania łańcucha umów i regresu.
Nasz produkt zawiera moduł AI. Czy AI Act znajduje do nas zastosowanie?
Zależnie od funkcji modułu. System AI stanowiący element bezpieczeństwa produktu objętego unijnym prawodawstwem harmonizacyjnym (maszyny, zabawki, wyroby medyczne) albo objęty załącznikiem III (m.in. rekrutacja, ocena zdolności kredytowej, identyfikacja biometryczna) kwalifikowany jest jako system wysokiego ryzyka - z obowiązkami obejmującymi system zarządzania ryzykiem, zarządzanie danymi, dokumentację techniczną i nadzór człowieka.
Dla większości modułów AI w produktach konsumenckich zastosowanie znajdą wyłącznie obowiązki przejrzystości. Terminy stosowania przepisów o systemach wysokiego ryzyka pozostają przedmiotem prac legislacyjnych - stan prawny ustalamy na dzień audytu.
Dla większości modułów AI w produktach konsumenckich zastosowanie znajdą wyłącznie obowiązki przejrzystości. Terminy stosowania przepisów o systemach wysokiego ryzyka pozostają przedmiotem prac legislacyjnych - stan prawny ustalamy na dzień audytu.
Jaki jest czas i koszt przygotowania produktu - poza honorarium doradczym?
Audyt jednego produktu: 5–10 dni roboczych. Pełne dostosowanie produktu klasy domyślnej: zwykle 2–4 miesiące pracy zespołu, zależnie od dojrzałości istniejących procesów.
Koszty zewnętrzne: dla klasy domyślnej ocena zgodności przeprowadzana jest w trybie kontroli wewnętrznej, bez udziału jednostki notyfikowanej; dla klas ważnych - ocena z udziałem jednostki notyfikowanej albo zastosowanie normy zharmonizowanej, szacunkowo 20–80 tys. PLN zależnie od produktu; testy penetracyjne: 10–40 tys. PLN. Narzędzia do generowania SBOM i skanowania podatności są w przeważającej mierze dostępne w modelu open source.
Koszty zewnętrzne: dla klasy domyślnej ocena zgodności przeprowadzana jest w trybie kontroli wewnętrznej, bez udziału jednostki notyfikowanej; dla klas ważnych - ocena z udziałem jednostki notyfikowanej albo zastosowanie normy zharmonizowanej, szacunkowo 20–80 tys. PLN zależnie od produktu; testy penetracyjne: 10–40 tys. PLN. Narzędzia do generowania SBOM i skanowania podatności są w przeważającej mierze dostępne w modelu open source.
