Cyber Resilience Act · 2026/2027

CRA dla SaaS: najpierw ustal, co dokładnie jest produktem

Autor: Piotr AdamskiPrzegląd operacyjny i bezpieczeństwa: Brillnet C-Team

Materiał informacyjny. Nie zastępuje indywidualnej porady prawnej ani oceny zgodności.

Na pytanie „czy SaaS podlega CRA?” nie ma bezpiecznej odpowiedzi opartej wyłącznie na modelu subskrypcyjnym. CRA reguluje produkty z elementami cyfrowymi, natomiast typowe usługi cloud computing — w tym SaaS — są także przedmiotem NIS2. Kluczowe jest to, co jest produktem, jakie oprogramowanie trafia na rynek i czy zdalna usługa jest niezbędnym elementem funkcji tego produktu.

Dlatego kwalifikację zaczynamy od architektury i modelu dostarczenia, a nie od etykiety marketingowej.

Dwa różne pytania, które łatwo pomylić

Czy sam serwis chmurowy jest produktem z elementami cyfrowymi w rozumieniu CRA?

Nie zakładaj tego automatycznie tylko dlatego, że użytkownik korzysta z oprogramowania przez przeglądarkę.

Czy usługa zdalna jest częścią innego produktu z elementami cyfrowymi?

Może być. CRA definiuje „remote data processing solution” jako przetwarzanie na odległość, dla którego oprogramowanie jest zaprojektowane i rozwijane przez producenta lub na jego odpowiedzialność, a jego brak uniemożliwiłby produktowi wykonywanie jednej z funkcji.

Przykład z motywów CRA: jeżeli aplikacja mobilna wymaga API lub bazy danych dostarczanej przez producenta do realizacji funkcji produktu, taka usługa może być częścią produktu jako rozwiązanie zdalnego przetwarzania danych.

Mapa, którą warto narysować przed kwalifikacją

Dla oferty SaaS opisz osobno:

  1. kod dostarczany klientowi — agent, aplikacja desktop/mobile, appliance, plugin, biblioteka;
  2. frontend webowy — interfejs, którego użytkownik używa w przeglądarce;
  3. backend / API — funkcje wykonywane zdalnie;
  4. bazy i przetwarzanie — które elementy są niezbędne do funkcji produktu;
  5. integracje stron trzecich — co jest pod kontrolą producenta, a co nie;
  6. model udostępniania — kto i pod czyją marką oferuje rozwiązanie na rynku;
  7. aktualizacje — które elementy zmienia producent i jak wpływają na bezpieczeństwo;
  8. wsparcie — jak długo poszczególne elementy są utrzymywane.

Taka mapa daje materiał do oceny zakresu i jednocześnie jest początkiem dokumentacji technicznej.

Trzy przykładowe sytuacje

A. Czysta usługa webowa

Użytkownik loguje się do usługi w przeglądarce, bez osobnego komponentu software/hardware dostarczanego jako produkt. Nie zakładaj z automatu, że „SaaS = CRA”. Sprawdź definicje CRA, aktualne wytyczne Komisji i równolegle obowiązki z NIS2, jeśli dotyczą organizacji.

B. Produkt software + backend producenta

Klient otrzymuje aplikację lub komponent, którego ważna funkcja nie działa bez backendu zaprojektowanego przez producenta. Zdalne przetwarzanie może być częścią produktu w rozumieniu CRA.

C. Produkt korzysta z niezależnej usługi cloud

Jeżeli usługa została zaprojektowana i rozwinięta poza odpowiedzialnością producenta produktu, relacja może być inna niż w przypadku własnego backendu. Nie wyciągaj wniosku tylko z faktu, że „dane są w chmurze”.

To przykłady orientacyjne, nie kwalifikacja prawna konkretnej architektury.

Dlaczego kwalifikacja ma znaczenie operacyjne już teraz

Art. 14 CRA jest stosowany od 11 września 2026 r. i obejmuje również produkty wprowadzone na rynek przed 11 grudnia 2027 r., jeżeli produkty te mieszczą się w zakresie CRA.

Jeżeli oferta składa się z aplikacji, komponentu i backendu, zespół musi wiedzieć, dla którego produktu i której wersji:

  • przyjmuje zgłoszenia podatności;
  • wykonuje triage;
  • ocenia wpływ;
  • wdraża poprawki;
  • prowadzi komunikację;
  • ewentualnie uruchamia raportowanie CRA.

Bez jasnej granicy produktu nie da się dobrze zdefiniować T0, właściciela ani zakresu zgłoszenia.

Co zapisać w decyzji zakresowej dla SaaS

  • diagram granicy produktu;
  • elementy dostarczane lokalnie;
  • elementy wykonywane zdalnie;
  • funkcję, którą realizuje każdy element;
  • informację, czy brak części zdalnej uniemożliwia określoną funkcję produktu;
  • odpowiedzialność za rozwój części zdalnej;
  • model dystrybucji i markę;
  • rolę organizacji;
  • podstawę prawną i wytyczne użyte przy kwalifikacji;
  • osobę zatwierdzającą wynik;
  • datę ponownego przeglądu.

Jak Pulsar może pomóc

Pulsar może przechowywać ocenę zakresu i jej załączniki, a potem powiązać wynik z ryzykami, dokumentami, działaniami, dostawcami i dowodami. Jeżeli architektura zmienia się w kolejnej wersji, decyzja może wrócić do przeglądu zamiast pozostawać zapomnianym PDF-em.

Pulsar nie powinien samodzielnie odpowiadać „CRA dotyczy / nie dotyczy” bez możliwości zweryfikowania podstawy i zatwierdzenia przez człowieka.

Zobacz Pulsar GRC na przykładzie jednej oceny

Powiązane materiały

Źródła

Stan źródeł: 12 września 2026 r.