„Korzystanie z usług SaaS wiąże bezpieczeństwo procesów podmiotu finansowego z zabezpieczeniami środowiska dostawcy oraz sposobem konfiguracji i użytkowania usługi” - tak UKNF uzasadnia, dlaczego przegląd powinien objąć nie tylko rozwiązania techniczne, lecz także umowy, podział odpowiedzialności i gotowość do samodzielnego ograniczenia skutków incydentu. Wyjaśniamy, czym jest dokument z 5 października 2026 r., jak łączy się z DORA i co obejmuje każdy z ośmiu obszarów przeglądu. W dalszej części znajdziesz mapę przeglądu, kartę usługi SaaS i scenariusz ćwiczenia.
Nowe rekomendacje Urzędu KNF w sprawie usług SaaS: co opublikowano i dlaczego
Urząd KNF 5 października 2026 r. opublikował rekomendacje dla podmiotów rynku finansowego dotyczące przeglądu bezpieczeństwa usług SaaS i zarządzania ryzykiem dostawców ICT - w związku z atakami na dostawców oprogramowania udostępnianego w modelu usługowym i ujawnionymi naruszeniami bezpieczeństwa przetwarzanych przez nich danych (UKNF, rekomendacje z 5.10.2026, wstęp).
Dokument przygotował Departament Cyberbezpieczeństwa UKNF. Przegląd powinien ustalić, czy zakres powierzonych danych, uprawnienia i sposób integracji są „adekwatne do potrzeb biznesowych i aktualnego poziomu zagrożeń” oraz czy przejęta usługa, konto lub poświadczenia nie pozwolą sięgnąć do kolejnych zasobów, zmienić danych albo zakłócić procesów biznesowych. UKNF rekomenduje objęcie przeglądem ośmiu obszarów:
- identyfikacja usług SaaS i powierzanych danych, także usług kupowanych bezpośrednio przez jednostki biznesowe
- weryfikacja bezpieczeństwa dostawców
- integracje, konta techniczne i administracyjne, uprawnienia aplikacji, tokeny i klucze API
- ochrona poświadczeń i certyfikatów technicznych, uwierzytelnianie wieloskładnikowe
- podwykonawcy, przepływy danych i ryzyko koncentracji
- ograniczenie zakresu i czasu przechowywania danych
- przygotowanie do incydentu i ciągłość działania
- współpraca z CSIRT KNF i informacje o zagrożeniach
Czy rekomendacje KNF są wiążące i kogo dotyczą
Dokument pochodzi od Urzędu KNF i nie powołuje się na uchwałę Komisji; nie wyznacza terminu przeglądu ani obowiązku przekazania jego wyników do KNF - istotne ustalenia przeglądu powinny zostać przedstawione organowi zarządzającemu podmiotu (UKNF, rekomendacje z 5.10.2026, nagłówek dokumentu i zakończenie).
Adresatami są podmioty rynku finansowego, a odwołania do DORA dotyczą tylko podmiotów objętych tym rozporządzeniem. Brak obowiązku przekazania wyników przeglądu nie zmienia innych obowiązków informacyjnych wobec KNF, np. powiadomienia o planowanej umowie na usługi ICT wspierające funkcje krytyczne lub istotne (art. 18zi ust. 1 pkt 2 ustawy o nadzorze nad rynkiem finansowym).
Rekomendacje UKNF nie są przepisem prawa powszechnie obowiązującego - nie były nim także rekomendacje i wytyczne IT Komisji, uchylone w związku z DORA. KNF uzasadniła uchylenie zbieżnością zakresu tych dokumentów z obowiązkami z DORA i aktów wykonawczych oraz tym, że jako tzw. soft law nie są prawem powszechnie obowiązującym (komunikat KNF z 12.12.2024).
Dla podmiotów objętych DORA wiążące są natomiast przepisy DORA i rozporządzeń delegowanych, do których dokument odsyła przy obszarach 1-7 - w zakresie, w jakim mają do nich zastosowanie.
SaaS a DORA: które przepisy wskazuje UKNF
Przy obszarach 1-7 UKNF wskazuje obowiązki z DORA, których realizacji przegląd powinien służyć w podmiotach objętych rozporządzeniem - z uwzględnieniem jego zakresu podmiotowego, wyłączeń i zasady proporcjonalności; korzystanie z usług zewnętrznych nie zwalnia podmiotu finansowego z odpowiedzialności (UKNF, rekomendacje z 5.10.2026, wstęp i zakończenie; w przypisie 2 w szczególności art. 4, art. 6-13 i art. 28-30 DORA).
Przepisy przypisane do poszczególnych obszarów podajemy w mapie przeglądu, a wymagania wobec umów z dostawcami opisujemy na stronie o wymaganiach DORA wobec dostawców ICT.
KNF a chmura: co z komunikatem chmurowym
Komunikat UKNF z 23 stycznia 2020 r. o przetwarzaniu informacji w chmurze obliczeniowej publicznej lub hybrydowej („komunikat chmurowy”) został odwołany z dniem 17 stycznia 2025 r. (komunikat KNF z 16.01.2025). Rekomendacje z 5 października 2026 r. nie przywracają go ani nie odwołują się do niego. Więcej o zmianach w dokumentach KNF: wymagania KNF po DORA.
8 obszarów przeglądu według UKNF
Pytania kontrolne, dowody i przepisy dla każdego z ośmiu obszarów zebraliśmy w mapie poniżej.
Identyfikacja usług i powierzanych danych
„Należy zweryfikować kompletność informacji o wykorzystywanych usługach SaaS, w tym rozwiązaniach nabywanych bezpośrednio przez poszczególne jednostki biznesowe.” Każda usługa powinna mieć właściciela, opis procesów i kategorii danych oraz ocenę skutków naruszenia - dotyczy to także usług księgowych, kadrowych, sprzedażowych i komunikacyjnych. Trzeba też ustalić podział odpowiedzialności z dostawcą: konfiguracja zabezpieczeń, zarządzanie tożsamością, rejestrowanie zdarzeń, odtwarzanie danych. Nasza wskazówka: spis zacznij od faktur i umów, także tych, które działy biznesowe podpisały samodzielnie, i obejmij nim narzędzia AI używane bez wiedzy działu IT (shadow AI).
Weryfikacja bezpieczeństwa dostawców
Posiadanie certyfikatu nie powinno być traktowane jako wystarczające potwierdzenie bezpieczeństwa usługi - ocena dostawcy ma uwzględniać także skuteczność zabezpieczeń, wyniki testów i sposób usuwania nieprawidłowości (UKNF, rekomendacje z 5.10.2026, pkt 2 - UKNF łączy ten obszar m.in. z art. 28 ust. 6 i art. 30 ust. 3 lit. e DORA).
Przy certyfikatach i raportach z audytów sprawdź ich autentyczność, aktualność, zakres i to, czy obejmują „konkretną usługę i środowisko, w którym przetwarzane są dane podmiotu”. W raporcie z testów dostawcy liczy się metoda - pentest, skan podatności czy audyt to różne dowody. Ponowną ocenę powinny uruchamiać istotne zmiany usługi, incydenty bezpieczeństwa i zmiana zakresu certyfikacji.
Integracje, połączenia i uprawnienia
„Zaleca się przegląd kont technicznych, dostępów administracyjnych, uprawnień aplikacji oraz tokenów i kluczy API.” Uprawnienia powinny być ograniczone do niezbędnego zakresu, a nieużywane konta i integracje - wyłączone. Podmiot powinien móc szybko odciąć poszczególne połączenia bez czekania na działania dostawcy, o ile pozwala na to architektura rozwiązania (UKNF, rekomendacje z 5.10.2026, pkt 3). Szczególnej uwagi wymagają integracje pozwalające na masowy odczyt lub eksport danych i zmianę uprawnień. Błędy, których szukamy w testach takich integracji - klucze o zbyt szerokim dostępie, słaba separacja klientów, IDOR - opisujemy na stronie o testach integracji B2B i API partnerskich.
Ochrona poświadczeń i certyfikatów technicznych
Przegląd powinien objąć cały cykl życia haseł, tokenów, kluczy i certyfikatów - od przechowywania po unieważnianie - oraz ich rozdzielenie między integracjami i środowiskami. Odrębne zalecenie dotyczy MFA: „Zaleca się stosowanie uwierzytelniania wieloskładnikowego, w szczególności dla kont administracyjnych, oraz sprawdzenie możliwości unieważnienia aktywnych sesji i poświadczeń w przypadku podejrzenia ich przejęcia”. Poświadczenia techniczne powinny mieć właścicieli i kontrolowane terminy ważności. Według UKNF nie należy też przechowywać ich „w ogólnodostępnej dokumentacji, repozytoriach kodu ani logach”.
Podwykonawcy, przepływy danych i ryzyko koncentracji ICT
UKNF zaleca ustalić, kto uczestniczy w świadczeniu usługi, gdzie są przetwarzane dane i kto ma do nich dostęp, a także ocenić zależności od podwykonawców i ryzyko koncentracji.
Według DORA ryzyko koncentracji w obszarze ICT to ekspozycja na jednego lub kilku powiązanych ze sobą kluczowych zewnętrznych dostawców usług ICT, która tworzy takie uzależnienie, że ich niedostępność, awaria lub inne braki mogą zagrozić zdolności podmiotu finansowego do wypełniania krytycznych lub istotnych funkcji, narazić go na inne negatywne skutki, w tym duże straty, albo zagrozić stabilności finansowej Unii jako całości (art. 3 pkt 29).
Analiza koncentracji powinna obejmować także wspólne zależności pozornie niezależnych usług, np. od tego samego dostawcy chmury lub mechanizmu uwierzytelniania (UKNF, rekomendacje z 5.10.2026, pkt 5 - UKNF łączy ten obszar m.in. z art. 28 ust. 3 i art. 29 ust. 2 DORA). UKNF zaleca też ocenić, czy awaria takiego elementu nie ograniczy jednocześnie kilku procesów oraz dostępu do rozwiązań przewidzianych jako zastępcze. Europejskie Urzędy Nadzoru opublikowały 18 listopada 2025 r. pierwszą listę kluczowych zewnętrznych dostawców usług ICT (19 podmiotów), ale lista nie zastępuje własnej oceny zależności.
Zakres i czas przechowywania danych
UKNF zaleca ocenić, czy zakres przekazywanych danych jest niezbędny, a okresy przechowywania - uzasadnione. Przegląd powinien objąć także archiwa, eksporty, kopie zapasowe i środowiska testowe - z uwzględnieniem obowiązujących wymogów retencji. Po zakończeniu współpracy liczą się zwrot i usunięcie danych oraz „możliwość uzyskania potwierdzenia realizacji tych czynności”. W miarę możliwości dane testowe nie powinny odwzorowywać rzeczywistych danych klientów. Zasady retencji powinny też obejmować dane pozostające u podwykonawców.
Przygotowanie do incydentu i ciągłość działania
Procedury reagowania powinny obejmować odłączenie integracji, unieważnienie zagrożonych poświadczeń, weryfikację integralności danych i analizę operacji wykonanych z przejętych dostępów. UKNF zaleca też sprawdzić możliwość odzyskania danych, uruchomienia rozwiązań zastępczych i zakończenia korzystania z usługi: „Testy powinny uwzględniać zarówno niedostępność dostawcy, jak i sytuację, w której bezpieczeństwo jego środowiska zostało naruszone”. Weryfikacja powinna objąć również dostępność, zakres i okres przechowywania logów oraz możliwość zabezpieczenia dowodów „niezależnie od dostawcy”.
UKNF łączy ten obszar m.in. z programem testowania operacyjnej odporności cyfrowej i z zakończeniem korzystania z usługi: dla usług ICT wspierających krytyczne lub istotne funkcje podmiot wprowadza strategie wyjścia (art. 28 ust. 8). Czym program testowania różni się od TLPT, wyjaśniamy w artykule o testach penetracyjnych i TLPT.
CSIRT KNF i informacje o zagrożeniach
UKNF zaleca uwzględniać publikacje CSIRT KNF w bieżącej ocenie usług SaaS i ryzyka dostawców, a ostrzeżenia oceniać pod kątem używanych usług, danych i integracji. Do analizy ryzyka i scenariuszy testów dokument poleca publikację CSIRT KNF „Krajobraz cyberzagrożeń w polskim sektorze finansowym 2026” - na dzień stanu prawnego artykułu strona tej publikacji na knf.gov.pl jest pusta, a ostatnie dostępne wydanie pochodzi z 2025 r.
Informacja o zagrożeniu dotyczącym dostawcy lub stosowanej technologii powinna uruchamiać weryfikację ekspozycji i decyzję o kontakcie z dostawcą - wskaż osoby odpowiedzialne za taką analizę. UKNF zaleca też przekazywać CSIRT KNF użyteczne informacje o obserwowanych zagrożeniach i incydentach - z zachowaniem wymogów ochrony informacji i właściwych zasad raportowania. „Współpracę operacyjną należy skoordynować z realizacją obowiązków zgłoszeniowych mających zastosowanie do danego podmiotu.”
Mapa przeglądu SaaS: pytania kontrolne i dowody
Pytania i dowody to nasza propozycja. Przepisy podajemy za UKNF; przy obszarach 1-7 dokument poprzedza je słowami „m.in.”.
| Obszar UKNF | Pytania kontrolne | Dowód do dokumentacji | Przepisy wskazane przez UKNF |
|---|---|---|---|
| 1. Identyfikacja usług i danych | Czy spis obejmuje usługi kupione przez działy? Czy każda ma właściciela? | Rejestr usług powiązany z ewidencją umów | art. 8 ust. 1, 4 i 5, art. 28 ust. 1 i 3, art. 30 ust. 2 lit. a, b, e i f DORA |
| 2. Weryfikacja dostawców | Czy certyfikat obejmuje tę usługę i środowisko? | Notatka z oceny dostawcy | art. 28 ust. 6 i art. 30 ust. 3 lit. e DORA; rozporządzenie delegowane 2024/1773 (usługi wspierające funkcje krytyczne lub istotne) |
| 3. Integracje i uprawnienia | Czy integrację da się odciąć bez dostawcy? | Lista integracji i uprawnień; raport z testu API | art. 8 ust. 1, 2, 4 i 5, art. 9 ust. 3 i ust. 4 lit. c DORA; art. 12 ust. 1 i 2 oraz art. 21 rozporządzenia delegowanego 2024/1774 |
| 4. Poświadczenia i certyfikaty | Kto odpowiada za każdy klucz i kiedy ten wygasa? | Rejestr poświadczeń; procedura awaryjnej wymiany kluczy | art. 9 i art. 30 ust. 2 lit. c DORA; art. 7, 20 i 21 rozporządzenia delegowanego 2024/1774 |
| 5. Podwykonawcy i przepływy danych | Które usługi mają wspólne zależności? | Mapa zależności z oceną koncentracji | art. 28 ust. 3, art. 29 ust. 2, art. 30 ust. 2 lit. a i b DORA; rozporządzenie delegowane 2025/532 i art. 9 rozporządzenia delegowanego 2024/1773 (podwykonawstwo usług wspierających funkcje krytyczne lub istotne) |
| 6. Zakres i retencja danych | Czy dostawca potwierdzi usunięcie danych? | Okresy retencji, potwierdzenie usunięcia | art. 9 ust. 3 DORA; art. 2 ust. 1 i art. 11 ust. 2 lit. g rozporządzenia delegowanego 2024/1774 |
| 7. Incydent i ciągłość działania | Czy logi da się zabezpieczyć bez udziału dostawcy? | Protokół ćwiczenia, wynik testu odtworzenia | art. 11, 17, 24 i 25, art. 28 ust. 8, art. 30 ust. 2 lit. f DORA; rozdział IV rozporządzenia delegowanego 2024/1774 |
| 8. CSIRT KNF i zagrożenia | Kto analizuje ostrzeżenia CSIRT KNF? | Rejestr ostrzeżeń z oceną ekspozycji | art. 4 ust. 1 pkt 3b ustawy o nadzorze nad rynkiem finansowym (zadania KNF) |
Karta usługi SaaS: checklista do inwentaryzacji
Kartę wypełnij dla każdej usługi ze spisu. Pola wynikają z obszarów 1-7 rekomendacji - to nasz wzór roboczy, nie formularz UKNF.
- usługa, dostawca, właściciel biznesowy i wspierane procesy,
- czy usługa wspiera funkcję krytyczną lub istotną,
- kategorie danych i skutki naruszenia ich poufności, integralności lub dostępności,
- podział odpowiedzialności z dostawcą: zabezpieczenia, tożsamość, logi, odtwarzanie,
- integracje: systemy, dane i operacje (w tym masowy eksport) oraz sposób ich odcięcia bez dostawcy,
- konta techniczne i administracyjne, uwierzytelnianie wieloskładnikowe, osoby zatwierdzające dostęp,
- tokeny, klucze i certyfikaty: właściciel, ważność, sposób unieważnienia,
- certyfikaty i raporty dostawcy: zakres, data, czy obejmują tę usługę,
- podwykonawcy, miejsca przetwarzania danych i wspólne zależności,
- retencja, eksporty, kopie i środowiska testowe oraz zwrot i usunięcie danych,
- powiadamianie o incydentach, dostęp do logów, rozwiązanie zastępcze i zakończenie korzystania z usługi,
- data ostatniej oceny i przesłanki ponownej oceny.
Ćwiczenie: przejęcie konta administratora usługi SaaS
UKNF wskazuje na ćwiczenie, które ma potwierdzić zdolność do podjęcia decyzji, ograniczenia dostępu, odtworzenia usługi i koordynacji komunikacji; jego scenariusz obejmuje przejęcie konta administracyjnego lub naruszenie środowiska dostawcy (UKNF, rekomendacje z 5.10.2026, pkt 7 - UKNF łączy ten obszar m.in. z art. 11, 24 i 25 DORA).
Poniższy scenariusz przejęcia konta administratora jest ilustracyjny (nasza propozycja, nie wzór UKNF).
-
Sygnał i decyzja
Alert albo komunikat dostawcy. Kto decyduje o ograniczeniu dostępu i jak szybko?
-
Ograniczenie dostępu
Odłączenie integracji, blokada konta, unieważnienie sesji, tokenów i kluczy według karty usługi.
-
Zabezpieczenie dowodów
Eksport logów usługi i własnych systemów niezależnie od dostawcy.
-
Analiza
Jakie operacje wykonano z przejętego konta? Czy nie naruszono integralności danych?
-
Odtworzenie
Przywrócenie danych albo rozwiązanie zastępcze.
-
Komunikacja
Informacja wewnętrzna i zewnętrzna, kontakt z dostawcą i CSIRT KNF, ocena obowiązków zgłoszeniowych.
Sprawdź też, czy zespół zna terminy zgłoszeń. W podmiotach objętych DORA wstępne powiadomienie o poważnym incydencie związanym z ICT przekazuje się w ciągu 4 godzin od sklasyfikowania incydentu jako poważnego, niepóźniej niż 24 godziny od dowiedzenia się o nim (art. 19 ust. 4 DORA i art. 5 rozporządzenia delegowanego (UE) 2025/301). Jeśli incydent jest także naruszeniem ochrony danych osobowych, obowiązuje RODO: administrator zgłasza naruszenie ochrony danych osobowych organowi nadzorczemu bez zbędnej zwłoki - w miarę możliwości w ciągu 72 godzin po jego stwierdzeniu - chyba że jest mało prawdopodobne, by skutkowało ono ryzykiem naruszenia praw lub wolności osób fizycznych; do zgłoszenia przekazanego po 72 godzinach dołącza się wyjaśnienie przyczyn opóźnienia (art. 33 ust. 1 RODO). Dostawca SaaS, który przetwarza dane w Twoim imieniu, też ma obowiązek zgłoszenia: podmiot przetwarzający po stwierdzeniu naruszenia bez zbędnej zwłoki zgłasza je administratorowi (art. 33 ust. 2 RODO).
Od czego zacząć: priorytety i plan naprawczy
UKNF wskazuje: „W pierwszej kolejności należy ograniczać ryzyka związane z szerokim dostępem do danych i systemów, brakiem możliwości szybkiego odłączenia integracji oraz niewystarczającą zdolnością przywrócenia procesów biznesowych”. Jak je sprawdzić:
- szeroki dostęp - przegląd zakresów tokenów i kont; dowód: lista uprawnień przed zmianą i po niej,
- odłączanie integracji - próba odcięcia w oknie serwisowym; dowód: protokół z czasem odcięcia,
- przywracanie procesów - test odtworzenia; dowód: wynik testu.
Wyniki przeglądu powinny zostać udokumentowane i wykorzystane do aktualizacji oceny ryzyka oraz planu działań naprawczych z priorytetami, właścicielami, terminami i sposobem potwierdzenia usunięcia nieprawidłowości; przegląd powinien być ponawiany po istotnych zmianach usług, incydencie albo uzyskaniu informacji wskazujących na zmianę poziomu zagrożenia (UKNF, rekomendacje z 5.10.2026, zakończenie).
UKNF zaleca oceniać skuteczność działań „na podstawie sprawdzalnych rezultatów”, a odpowiedzialność za ten obszar rozłożyć na jednostki biznesowe, bezpieczeństwo, IT, zakupy i funkcje kontrolne.
Co w przeglądzie da się sprawdzić testem
Ustalenia przeglądu dotyczące integracji, uprawnień i poświadczeń warto potwierdzić testem penetracyjnym API i połączeń po stronie Twojej organizacji. Test sprawdza m.in.:
- czy tokeny i klucze API mają tylko potrzebne uprawnienia,
- czy unieważnienie tokenu, klucza lub sesji wydanych przez Twoje systemy (np. dla integracji dostawcy) działa od razu,
- czy webhooki od dostawcy są weryfikowane podpisem i jak Twoje systemy reagują na nieoczekiwane odpowiedzi.
Przygotowania do incydentu test nie potwierdza - służy do tego ćwiczenie opisane wyżej. Środowisko dostawcy SaaS testujemy wyłącznie za jego pisemną zgodą (może nią być prawo do testów zapisane w umowie z dostawcą); bez niej sprawdzamy tylko stronę Twojej organizacji.
Takie testy mogą wejść do programu testowania z DORA: podmioty finansowe inne niż mikroprzedsiębiorstwa ustanawiają oparty na ryzyku program testowania operacyjnej odporności cyfrowej (art. 24 ust. 1-3). Testy penetracyjne są na liście testów z art. 25 ust. 1 - zobacz, jakich testów wymaga DORA. Plan naprawczy powinien wskazywać sposób potwierdzenia usunięcia nieprawidłowości - dla podatności z testu może nim być retest po poprawkach.
Jak możemy pomóc
Wykonujemy testy bezpieczeństwa API i integracji - także połączeń z usługami SaaS po stronie Twojej organizacji. Każde ustalenie potwierdzamy dowodem, a poprawki sprawdzamy w reteście, więc raport możesz wykorzystać w dokumentacji przeglądu, w planie naprawczym i w programie testowania odporności cyfrowej. Szerzej o testach dla podmiotów finansowych piszemy na stronie o DORA.