Usługa SaaS działająca wyłącznie u dostawcy co do zasady nie jest produktem z elementami cyfrowymi, więc CRA jej nie obejmuje. Inaczej jest, gdy udostępniasz aplikację lub urządzenie, które bez zaplecza opracowanego przez Ciebie lub na Twoją odpowiedzialność nie spełnia jednej ze swoich funkcji: wtedy zaplecze jest częścią produktu. Oprogramowanie open source podlega obowiązkom producenta tylko wtedy, gdy jest udostępniane w ramach działalności handlowej. Firma, która wbudowuje otwarte komponenty we własny produkt, odpowiada za cały produkt.
- Produkt z elementami cyfrowymi to oprogramowanie lub sprzęt razem z powiązanym zdalnym przetwarzaniem danych (art. 3 pkt 1 i 2).
- Rozwiązanie w chmurze podlega CRA tylko wtedy, gdy spełnia definicję zdalnego przetwarzania danych. Do usług chmurowych, w tym SaaS, ma zastosowanie dyrektywa NIS2 (motyw 12).
- Open source podlega obowiązkom producenta tylko wtedy, gdy jest udostępniane na rynku, czyli w ramach działalności handlowej (art. 3 pkt 22, motywy 15 i 18).
- Producent dokłada należytej staranności wobec wbudowanych komponentów open source i zgłasza wykryte w nich podatności podmiotowi, który je utrzymuje (art. 13 ust. 5 i 6).
- Opiekun oprogramowania otwartego ma ograniczone obowiązki z art. 24. Administracyjne kary pieniężne go nie obejmują (art. 64 ust. 10 lit. b).
Czy SaaS podlega CRA?
Usługa SaaS, z której użytkownik korzysta wyłącznie przez przeglądarkę, co do zasady nie podlega CRA, bo dostawca świadczy usługę i nie dostarcza użytkownikowi oprogramowania ani sprzętu. Motyw 12 wskazuje, że do usług w chmurze, w tym SaaS, ma zastosowanie dyrektywa NIS2. CRA obejmuje natomiast zaplecze, które spełnia definicję zdalnego przetwarzania danych.
Rozporządzenie nie zawiera przepisu, który wprost wyłącza SaaS. Wniosek wynika z definicji. CRA stosuje się do produktów z elementami cyfrowymi udostępnianych na rynku, których przeznaczenie lub racjonalnie przewidywalne wykorzystanie obejmuje połączenie danych z urządzeniem lub siecią (art. 2 ust. 1), a produkt z elementami cyfrowymi to oprogramowanie lub sprzęt oraz powiązane z nimi rozwiązania w zakresie zdalnego przetwarzania danych (art. 3 pkt 1). Motyw 12 dodaje, że rozwiązania w chmurze są zdalnym przetwarzaniem danych w rozumieniu CRA tylko wtedy, gdy są zgodne z tą definicją.
Ogólne zasady zakresu, wyłączenia i listę kontrolną opisuje artykuł Czy Cyber Resilience Act dotyczy Twojego produktu?. Tutaj zajmujemy się tylko oprogramowaniem działającym w chmurze i oprogramowaniem otwartym.
SaaS a dyrektywa NIS2
Według motywu 12 do usług w chmurze i modeli ich świadczenia, takich jak SaaS, PaaS i IaaS, ma zastosowanie dyrektywa (UE) 2022/2555, czyli NIS2. Dostawcy usług chmurowych są wymienieni w załączniku I do tej dyrektywy, w sektorze infrastruktury cyfrowej. NIS2 obejmuje co do zasady podmioty, które są co najmniej średnimi przedsiębiorstwami (art. 2 ust. 1 dyrektywy), a art. 2 ust. 2 wskazuje przypadki, w których stosuje się ją także do innych podmiotów. To, czy Twoja usługa jest usługą chmurową w rozumieniu NIS2 i czy firma spełnia kryterium wielkości, wymaga osobnego sprawdzenia.
Kiedy zaplecze w chmurze jest częścią produktu?
Zaplecze w chmurze jest częścią produktu, gdy spełnia dwa warunki z art. 3 pkt 2: jego oprogramowanie zaprojektował i opracował producent albo zrobiono to na jego odpowiedzialność, a bez niego produkt nie mógłby wykonywać jednej ze swoich funkcji. Wtedy producent zabezpiecza produkt w całości, razem z tym zapleczem (motyw 11).
Motywy 11 i 12 podają przykłady z obu stron granicy:
- W zakresie CRA: interfejs API lub baza danych, których wymaga aplikacja mobilna i które producent dostarcza w formie usługi (motyw 11).
- W zakresie CRA: funkcje w chmurze zapewniane przez producenta inteligentnych urządzeń domowych, które pozwalają sterować urządzeniem na odległość (motyw 12).
- Poza zakresem CRA: strony internetowe, które nie obsługują funkcjonalności produktu (motyw 12).
- Poza zakresem CRA: usługi w chmurze zaprojektowane i opracowane poza zakresem odpowiedzialności producenta produktu (motyw 12).
Zakres wymagań wobec zaplecza
Zdalne przetwarzanie lub przechowywanie danych wchodzi w zakres CRA tylko w takim zakresie, w jakim jest konieczne, żeby produkt pełnił swoje funkcje (motyw 11). Ten sam motyw zastrzega, że wymagania wobec zdalnego przetwarzania danych nie oznaczają środków technicznych, operacyjnych ani organizacyjnych służących zarządzaniu ryzykiem dla całości sieci i systemów informatycznych producenta. W praktyce trzeba więc wskazać, które usługi zaplecza są niezbędne do działania produktu, i objąć je oceną ryzyka oraz dokumentacją produktu. Systemy firmowe, które nie obsługują funkcji produktu, do niego nie należą.
Firma oferuje system do obiegu faktur dostępny przez przeglądarkę. Do tego udostępnia aplikację mobilną do fotografowania dokumentów oraz program instalowany na serwerze klienta, który przesyła dane z systemu księgowego.
Aplikacja mobilna i program instalowany u klienta są oprogramowaniem dostarczanym użytkownikowi, więc trzeba je ocenić jako produkty z elementami cyfrowymi. Interfejs API, bez którego aplikacja nie prześle dokumentu, jest zdalnym przetwarzaniem danych i częścią produktu. Strona z cennikiem i blog firmy nie obsługują funkcji produktu i pozostają poza zakresem.
Rozporządzenie nie rozstrzyga wprost każdej konfiguracji, na przykład tego, jak traktować kod wykonywany w przeglądarce użytkownika w ramach usługi. Takie przypadki wymagają analizy konkretnego rozwiązania. Art. 26 ust. 2 lit. a przewiduje, że wytyczne Komisji mają obejmować zakres rozporządzenia ze szczególnym uwzględnieniem zdalnego przetwarzania danych oraz wolnego i otwartego oprogramowania. Przed podjęciem decyzji sprawdź ich aktualną treść na stronie Komisji.
Które przypadki SaaS i open source podlegają CRA?
O zastosowaniu CRA decydują trzy rzeczy: czy użytkownik dostaje oprogramowanie lub sprzęt, czy zaplecze jest niezbędne do działania produktu oraz czy udostępnienie następuje w ramach działalności handlowej. Tabela pokazuje siedem typowych sytuacji. Jest orientacyjna, bo o kwalifikacji przesądzają szczegóły konkretnego produktu i modelu biznesowego.
| Przypadek | Czy CRA ma zastosowanie | Podstawa prawna |
|---|---|---|
| Usługa SaaS dostępna wyłącznie przez przeglądarkę, bez oprogramowania przekazywanego użytkownikowi | Co do zasady nie. Do usług chmurowych ma zastosowanie NIS2, jeśli dostawca spełnia jej kryteria | art. 3 pkt 1 i 2, motyw 12 |
| Urządzenie lub aplikacja z zapleczem w chmurze opracowanym przez producenta lub na jego odpowiedzialność, bez którego nie spełnia jednej ze swoich funkcji | Tak. Zaplecze jest częścią produktu jako zdalne przetwarzanie danych | art. 3 pkt 1 i 2, motywy 11 i 12 |
| Oprogramowanie do pobrania i uruchomienia u użytkownika, udostępniane w ramach działalności handlowej, odpłatnie lub nieodpłatnie | Tak, o ile nie działa wyłączenie z art. 2 ust. 2-7 | art. 2 ust. 1, art. 3 pkt 1 i 22 |
| Projekt open source rozwijany i publikowany bez monetyzacji | Nie w zakresie obowiązków producenta. Osoba prawna, która stale wspiera taki projekt, może być opiekunem | art. 3 pkt 14 i 22, motywy 18 i 20 |
| Oprogramowanie open source monetyzowane przez twórcę | Tak, jeśli sposób zarabiania oznacza działalność handlową. Twórca ma wtedy obowiązki producenta | art. 3 pkt 13 i 22, motywy 15 i 18 |
| Firma, która wbudowuje komponenty open source we własny produkt | Tak, w odniesieniu do własnego produktu, razem z wbudowanymi komponentami | art. 13 ust. 5 i 6, motyw 34 |
| Opiekun oprogramowania otwartego | Tak, w ograniczonym zakresie. Bez oznakowania CE i bez administracyjnych kar pieniężnych | art. 3 pkt 14, art. 24, art. 64 ust. 10 lit. b, motyw 19 |
Kiedy oprogramowanie open source podlega CRA?
Oprogramowanie open source podlega obowiązkom producenta tylko wtedy, gdy jest udostępniane na rynku, czyli dostarczane do dystrybucji lub używania w ramach działalności handlowej (art. 3 pkt 22, motyw 18). Dostarczanie oprogramowania, którego producent nie monetyzuje, nie powinno być uznawane za taką działalność. Samo opublikowanie kodu w otwartym repozytorium nie jest udostępnieniem na rynku (motyw 20).
Wolne i otwarte oprogramowanie to według art. 3 pkt 48 oprogramowanie, którego kod źródłowy jest powszechnie dostępny, oferowane bezpłatnie i na otwartej licencji, która daje wszystkim prawo do wolnego dostępu, używania, modyfikowania i redystrybucji. O zakresie nie decyduje jednak licencja, tylko to, czy oprogramowanie jest dostarczane w ramach działalności handlowej. Udostępnienie na rynku może być odpłatne lub nieodpłatne (art. 3 pkt 22), a producentem jest także ten, kto wprowadza produkt do obrotu „na zasadzie monetyzacji lub bezpłatnie” (art. 3 pkt 13).
Przykłady działalności handlowej
Motyw 15 wymienia przykłady dostarczania w ramach działalności handlowej:
- pobieranie zapłaty za produkt,
- pobieranie opłat za usługi wsparcia technicznego, gdy nie służy to wyłącznie odzyskaniu rzeczywistych kosztów,
- działanie z zamiarem monetyzacji, na przykład udostępnianie platformy oprogramowania, za pośrednictwem której producent zarabia na innych usługach,
- wymaganie, jako warunku korzystania, przetwarzania danych osobowych z powodów innych niż tylko poprawa bezpieczeństwa, kompatybilności lub interoperacyjności oprogramowania,
- przyjmowanie darowizn przekraczających koszty zaprojektowania, opracowania i dostarczenia produktu.
Okoliczności, które same nie przesądzają o działalności handlowej
Motywy 15, 18 i 20 wskazują okoliczności, które same nie wystarczają:
- przyjmowanie darowizn bez zamiaru osiągnięcia zysku (motyw 15),
- to, że projekt jest wspierany finansowo przez producentów albo że producenci uczestniczą w jego rozwoju (motyw 18),
- regularne wydawanie nowych wersji (motyw 18),
- okoliczności, w jakich oprogramowanie powstało, i sposób sfinansowania jego opracowania (motyw 18),
- hosting w otwartym repozytorium, w systemie zarządzania pakietami lub na platformie współpracy (motyw 20).
Motyw 18 dodaje trzy wskazówki. Dostarczanie komponentu open source przeznaczonego do wbudowania przez innych producentów w ich produkty powinno być uznawane za udostępnianie na rynku tylko wtedy, gdy pierwotny producent go monetyzuje. Opracowywanie wolnego i otwartego oprogramowania przez organizację nienastawioną na zysk nie powinno być uznawane za działalność handlową, o ile jej forma gwarantuje, że cały zysk po odjęciu kosztów służy celom nienastawionym na zysk. Według tego motywu rozporządzenie nie ma też zastosowania do osób, które tworzą kod źródłowy dla takiego oprogramowania poza zakresem swojej odpowiedzialności.
Open source monetyzowane przez twórcę
Jeśli udostępniasz wolne i otwarte oprogramowanie w ramach działalności handlowej, jesteś jego producentem i masz obowiązki producenta. Rozporządzenie przewiduje jedno ułatwienie w ocenie zgodności. Producenci wolnego i otwartego oprogramowania należącego do kategorii z załącznika III mogą wykazać zgodność za pomocą jednej z procedur wymienionych w art. 32 ust. 1, pod warunkiem że dokumentacja techniczna jest publicznie dostępna w momencie wprowadzania produktu do obrotu (art. 32 ust. 5).
Jakie obowiązki ma firma, która wbudowuje komponenty open source?
Producent, który wbudowuje komponenty open source, odpowiada za cały produkt, razem z tymi komponentami. Art. 13 ust. 5 wymaga należytej staranności przy integrowaniu komponentów stron trzecich, także otwartych, których nikt nie udostępnił na rynku. Art. 13 ust. 6 każe zgłosić wykrytą podatność podmiotowi utrzymującemu komponent i ją usunąć.
Poziom należytej staranności zależy od charakteru i poziomu ryzyka związanego z komponentem. Motyw 34 wymienia działania, z których producent powinien wykonać co najmniej jedno:
- sprawdzenie, w stosownych przypadkach, czy producent komponentu wykazał zgodność z CRA, między innymi czy komponent ma oznakowanie CE,
- sprawdzenie, czy komponent regularnie otrzymuje aktualizacje zabezpieczeń, na przykład na podstawie historii aktualizacji,
- sprawdzenie, czy komponent nie ma podatności zarejestrowanych w europejskiej bazie danych dotyczących podatności lub w innych publicznie dostępnych bazach,
- przeprowadzenie dodatkowych testów bezpieczeństwa.
Komponent open source, którego nikt nie udostępnił na rynku, nie będzie miał oznakowania CE, więc w jego przypadku zostają pozostałe sposoby. Motyw 34 podkreśla też, że obowiązki dotyczące postępowania z podatnościami odnoszą się do produktu w całości, w tym do wszystkich zintegrowanych z nim komponentów.
Zgłaszanie podatności do projektu
Gdy wykryjesz podatność w komponencie, w tym w komponencie otwartego oprogramowania, zgłaszasz ją osobie lub podmiotowi, który komponent produkuje lub utrzymuje, oraz usuwasz ją zgodnie z wymaganiami z załącznika I część II. Jeśli opracujesz poprawkę, udostępniasz odpowiedni kod lub dokumentację temu podmiotowi, w stosownych przypadkach w formacie nadającym się do odczytu maszynowego (art. 13 ust. 6).
Żeby to robić, trzeba wiedzieć, z czego składa się produkt. Służy do tego SBOM, opisany w artykule SBOM w Cyber Resilience Act. Sam proces obsługi podatności opisuje artykuł Zarządzanie podatnościami w CRA: proces krok po kroku.
Dobrowolne poświadczanie bezpieczeństwa
Art. 25 uprawnia Komisję do ustanowienia, w drodze aktów delegowanych, dobrowolnych programów poświadczania bezpieczeństwa wolnego i otwartego oprogramowania. Mają ułatwić producentom wypełnianie obowiązku należytej staranności z art. 13 ust. 5. Według motywu 21 poświadczenie mogliby inicjować lub finansować także producenci wbudowujący dany komponent, użytkownicy i administracja publiczna. W tym artykule nie przesądzamy, czy taki program już ustanowiono. Sprawdź aktualny stan na stronie Komisji.
Kim jest opiekun oprogramowania otwartego i jakie ma obowiązki?
Opiekun oprogramowania otwartego to osoba prawna inna niż producent, której celem jest systematyczne i stałe wspieranie rozwoju konkretnego wolnego i otwartego oprogramowania przeznaczonego do celów komercyjnych (art. 3 pkt 14). Ma ograniczone obowiązki z art. 24: politykę cyberbezpieczeństwa, współpracę z organami nadzoru rynku i część zgłoszeń z art. 14. Administracyjne kary pieniężne go nie obejmują.
Definicja wymaga też, żeby opiekun zapewniał prawidłowe funkcjonowanie tych produktów. Motyw 19 wyjaśnia, że chodzi między innymi o niektóre fundacje oraz podmioty, które opracowują i publikują wolne i otwarte oprogramowanie w kontekście biznesowym, w tym podmioty nienastawione na zysk. Stałe wsparcie obejmuje na przykład hosting platform współpracy i zarządzanie nimi, hosting kodu źródłowego lub oprogramowania, zarządzanie takimi produktami oraz kierowanie ich opracowywaniem. Ten sam motyw wskazuje, że opiekunom nie należy zezwalać na umieszczanie oznakowania CE na produktach, których rozwój wspierają.
Obowiązki opiekuna z art. 24:
- Polityka cyberbezpieczeństwa (ust. 1). Opiekun wprowadza ją i dokumentuje w weryfikowalny sposób. Polityka ma wspierać rozwój bezpiecznego produktu i skuteczne radzenie sobie z podatnościami przez jego twórców, w tym dokumentowanie, rozwiązywanie i eliminowanie podatności, dzielenie się informacjami o nich w społeczności oraz dobrowolne zgłaszanie podatności zgodnie z art. 15.
- Współpraca z organami nadzoru rynku (ust. 2). Na wniosek organu opiekun współpracuje w celu ograniczenia ryzyka, a na uzasadniony wniosek przekazuje dokumentację polityki.
- Zgłoszenia (ust. 3). Obowiązek zgłaszania aktywnie wykorzystywanych podatności (art. 14 ust. 1) dotyczy opiekuna w zakresie, w jakim jest zaangażowany w rozwój produktu. Obowiązki dotyczące poważnych incydentów i informowania użytkowników (art. 14 ust. 3 i 8) dotyczą go w zakresie, w jakim incydent dotyczy sieci i systemów informatycznych, które opiekun dostarcza na potrzeby rozwoju produktu.
Art. 14 stosuje się od 11 września 2026 r., rozdział IV od 11 czerwca 2026 r., a pozostałe przepisy od 11 grudnia 2027 r. (art. 71 ust. 2). Przebieg zgłoszenia opisuje artykuł o zgłaszaniu podatności i incydentów.
Nadzór nad opiekunami sprawują organy nadzoru rynku. Jeśli organ stwierdzi, że opiekun nie spełnia obowiązków z art. 24, wymaga podjęcia odpowiednich działań naprawczych (art. 52 ust. 3). Administracyjne kary pieniężne nie mają zastosowania do naruszeń rozporządzenia przez opiekunów (art. 64 ust. 10 lit. b).
Co powinien zrobić producent?
Producent oprogramowania powinien rozdzielić to, co trafia do użytkownika, od tego, co działa po jego stronie, wskazać zaplecze niezbędne do działania produktu, ocenić, czy otwarte projekty firmy są monetyzowane, oraz uporządkować komponenty open source we własnych produktach. Wynik warto zapisać z uzasadnieniem i podstawą prawną.
- Spisz wszystko, co dostarczasz użytkownikom. Aplikacje mobilne, programy na komputer, agenty, wtyczki, biblioteki i urządzenia potraktuj osobno od usługi dostępnej przez przeglądarkę. Wstępny wynik da bezpłatny skaner CRA.
- Wskaż zaplecze, bez którego produkt nie spełnia funkcji. Dla każdej usługi zaplecza odpowiedz na dwa pytania z art. 3 pkt 2: czy jej oprogramowanie powstało u Ciebie lub na Twoją odpowiedzialność i czy bez niej produkt traci którąś z funkcji.
- Sprawdź osobno dyrektywę NIS2. Jeśli świadczysz usługi chmurowe, ustal, czy firma podlega przepisom wdrażającym NIS2. To inny reżim niż CRA.
- Oceń własne projekty open source i rolę firmy. Dla każdego opublikowanego projektu zapisz, czy i jak na nim zarabiasz, i porównaj to z przykładami z motywów 15 i 18. Na tej podstawie ustal, czy jesteś producentem, opiekunem oprogramowania otwartego czy żadnym z nich. Pozostałe role opisuje artykuł Producent, importer czy dystrybutor.
- Uporządkuj komponenty open source w produktach. Przygotuj SBOM, ustal kryteria należytej staranności przy wyborze komponentów oraz sposób zgłaszania podatności i przekazywania poprawek podmiotom, które je utrzymują.
- Zapisz kwalifikację z uzasadnieniem. Krótka notatka z podstawą prawną przyda się w rozmowie z klientem i z organem nadzoru rynku.