Software house pod DORA i KSC.

Do 3 października 2026 r. pozostało około sześciu tygodni. To termin na złożenie wniosku o wpis do Wykazu KSC dla podmiotów, które przesłanki uznania za podmiot kluczowy albo ważny spełniły z dniem wejścia w życie nowelizacji ustawy o krajowym systemie cyberbezpieczeństwa (Dz.U. 2026 poz. 252), czyli 3 kwietnia 2026 r.

Równolegle na rynku funkcjonuje uproszczenie, które w rozmowach z dostawcami IT słyszymy regularnie: „DORA dotyczy Państwa tak samo jak banku”. Cóż, jest tu sporo nadużycia. Prowadzi albo do budowania u siebie ram zarządzania ryzykiem ICT wzorowanych na instytucji finansowych, czego przepisy od dostawcy nie wymagają, albo do rezygnacji z kontraktu w sektorze finansowym. Najczęściej jednak kończy się tym, że firma tak intensywnie zajmuje się cudzym reżimem, że nie zauważa własnego.

Poniżej rozdzielamy trzy warstwy, które w praktyce się zlewają, mianowicie co DORA nakłada na podmiot finansowy, co ta instytucja może przenieść na Państwa umową i w którym momencie ustawa o KSC staje się Państwa samodzielnym obowiązkiem.

Trzy role zamiast jednej etykiety „dostawca IT”

Zanim otworzą Państwo aneks przysłany przez dział prawny banku, warto ustalić, w której roli Państwa firma faktycznie występuje. Zwykle w więcej niż jednej jednocześnie — i to jest źródłem większości nieporozumień.

Rola	Czy są Państwo adresatem DORA?	Czy podlegają Państwo ustawie o KSC?	Wobec kogo odpowiadają Państwo?
Licencja albo wdrożenie oprogramowania bez administracji środowiskiem klienta	Nie. Wymogi wchodzą przez umowę z podmiotem finansowym (art. 28–30).	Zwykle nie, o ile nie świadczą Państwo usług z art. 2 pkt 4i albo 4j. (wyjaśnimy w dalszej części)	Klientowi, w granicach kontraktu.
Dostawca usług ICT: hosting, administracja, utrzymanie 24/7, prace na środowisku produkcyjnym klienta	Nadal nie jako adresat. Bank ujmuje Państwa w rejestrze informacji i negocjuje klauzule z art. 30.	Możliwe. Dostawca usług zarządzanych z załącznika nr 1 — od progu średniego przedsiębiorcy.	Klientowi, a po kwalifikacji KSC także organowi właściwemu i CSIRT.
MSSP: SOC, SIEM, obsługa incydentów, testy bezpieczeństwa, audyty systemów, doradztwo w zakresie ryzyka cyber	Jak wyżej. Częściej usługa wspiera funkcję krytyczną lub istotną klienta, co uruchamia art. 30 ust. 3.	Tak — już od progu małego przedsiębiorcy i od razu w statusie podmiotu kluczowego (art. 5 ust. 1 pkt 3).	Jak wyżej, z pełnym reżimem podmiotu kluczowego.
Kluczowy zewnętrzny dostawca usług ICT (CTPP)	Tak, bezpośrednio: nadzór ESA, art. 31–44.	Odrębna kwalifikacja, jeżeli spełniają Państwo przesłanki ustawowe.	Wiodącemu organowi nadzorczemu (EBA, ESMA albo EIOPA) oraz klientom.

Definicje ustawowe są szersze niż intuicja podpowiadana przez treść umowy. Dostawcą usług zarządzanych (art. 2 pkt 4i ustawy o KSC) jest podmiot świadczący usługi związane z instalacją, eksploatacją lub konserwacją produktów ICT, usług ICT, procesów ICT albo systemów informacyjnych — przez wsparcie lub aktywną administrację, u klienta na miejscu bądź zdalnie. Dostawcą usług zarządzanych w zakresie cyberbezpieczeństwa (art. 2 pkt 4j) jest podmiot realizujący lub wspierający realizację działań związanych z zarządzaniem ryzykiem w cyberbezpieczeństwie, w tym obsługę incydentów, testy bezpieczeństwa, audyty systemów informacyjnych oraz doradztwo.

Konsekwencja praktyczna jest prosta. Software house, który przekazuje kod i kończy zaangażowanie, co do zasady nie jest dostawcą usług zarządzanych. Software house, który utrzymuje dostęp do środowiska produkcyjnego klienta, pełni dyżury, wgrywa poprawki, odpowiada za kopie zapasowe i opiekuje się systemem — jest. Jeżeli dodatkowo mają Państwo w ofercie SOC, testy penetracyjne albo vCISO, wchodzą Państwo w definicję z pkt 4j.

I tu najczęściej pojawia się zaskoczenie. Dostawca usług zarządzanych w zakresie cyberbezpieczeństwa jest podmiotem kluczowym już wtedy, gdy co najmniej spełnia wymogi dla małego przedsiębiorcy w rozumieniu art. 2 ust. 1 załącznika I do rozporządzenia 651/2014/UE (art. 5 ust. 1 pkt 3 ustawy o KSC). Próg jest więc wyraźnie niższy niż ogólna zasada NIS2, która sięga dopiero po średniego przedsiębiorcę. Do tego przy liczeniu wielkości uwzględnia się dane przedsiębiorstw partnerskich i powiązanych (art. 3 i 6 załącznika I do rozporządzenia 651/2014/UE) — dla spółek w grupach kapitałowych bywa game changerem. Warto też pamiętać, że nawet poniżej progów organ właściwy może uznać podmiot za kluczowy albo ważny w drodze decyzji (art. 7l ustawy o KSC).

Samo wymienienie doradztwa w definicji z pkt 4j nie oznacza, że każda usługa doradcza automatycznie przesądza o statusie. Kwalifikacja wymaga oceny, czy doradztwo stanowi realizację albo wsparcie realizacji zarządzania ryzykiem w cyberbezpieczeństwie. Tę ocenę warto przeprowadzić i udokumentować samodzielnie, zanim zrobi to za Państwa organ.

Artykuł 8i nie chroni dostawcy

Częsty skrót myślowy jest, że „nasz klient jest bankiem, bank ma DORA jako lex specialis, więc KSC nas nie dotyczy”.

Art. 8i ustawy o KSC rzeczywiście wyłącza znaczną część obowiązków — w zakresie systemu zarządzania bezpieczeństwem informacji oraz zgłaszania incydentów — ale robi to wobec podmiotów kluczowych i ważnych z sektora bankowości i rynków finansowych. Nie wobec ich łańcucha dostaw. Jeżeli Państwa firma samodzielnie spełnia przesłanki z załącznika nr 1, pozostaje przy pełnym reżimie KSC, niezależnie od tego, ilu klientów z sektora finansowego Państwo obsługują.

Status CTPP to inna skala i inne kryteria

Kluczowy zewnętrzny dostawca usług ICT podlega DORA bezpośrednio, wraz z nadzorem wiodącego organu nadzorczego (art. 31–44). Status ten nadaje jednak Wspólny Komitet Europejskich Urzędów Nadzoru według kryteriów z art. 31: wpływu systemowego, znaczenia obsługiwanych podmiotów finansowych, zależności od funkcji krytycznych oraz substytucyjności. Pierwsza lista, opublikowana 18 listopada 2025 r., objęła 19 dostawców — hiperskalerów chmurowych, operatorów centrów danych, dostawców telekomunikacyjnych i dostawców technologii dla rynku finansowego. Lista dostępna jest tutaj.

Dodatkowo art. 31 ust. 8 DORA wprost wyłącza z mechanizmu wyznaczania między innymi dostawców wewnątrzgrupowych oraz dostawców świadczących usługi ICT wyłącznie w jednym państwie członkowskim na rzecz podmiotów finansowych działających tylko w tym państwie.

Podsumowując, nie ma powodu, aby polski software house planował budżet na opłaty nadzorcze ESA. Nie ma też jednak podstaw, by z nieobecności na liście wyprowadzać wniosek, że DORA nie dotyczy Państwa w ogóle. Dotyczy — przez umowę.

Co bank musi mieć w umowie i czego nie przeniesie

Art. 28 DORA pozostawia odpowiedzialność po stronie podmiotu finansowego. Outsourcing nie przenosi nadzoru. Bank musi mieć strategię dotyczącą ryzyka ze strony zewnętrznych dostawców usług ICT zatwierdzoną przez organ zarządzający, ocenę poprzedzającą zawarcie umowy, rejestr informacji obejmujący wszystkie ustalenia umowne dotyczące usług ICT — w tym wewnątrzgrupowe — oraz strategie wyjścia dla usług wspierających funkcje krytyczne lub istotne.

Rejestr informacji jest obowiązkiem banku wobec KNF, nie Państwa obowiązkiem wobec KNF. Po Państwa stronie leży dostarczenie danych, bez których bank tego rejestru nie złoży.

Art. 30 ust. 2 DORA wyznacza minimum dla każdej umowy o świadczenie usług ICT — także takiej, która funkcji krytycznych nie wspiera:

• opis funkcji i usług, w tym warunki podwykonawstwa,
• miejsca świadczenia usług oraz przetwarzania i przechowywania danych, wraz z warunkami zmiany tych lokalizacji,
• postanowienia o dostępności, autentyczności, integralności i poufności danych, w tym danych osobowych,
• pomoc w przypadku incydentu związanego z ICT — bez dodatkowej opłaty albo za cenę ustaloną z góry,
• pełną współpracę z organami właściwymi oraz organem ds. restrukturyzacji i uporządkowanej likwidacji,
• prawa wypowiedzenia i minimalne okresy wypowiedzenia,
• udział w programach szkoleniowych klienta z zakresu bezpieczeństwa ICT, o ile ma to zastosowanie.

Art. 30 ust. 3 dokłada do tego zestaw wymagany wtedy, gdy usługa wspiera funkcję krytyczną lub istotną:

• pełne opisy poziomów usług z mierzalnymi celami ilościowymi i jakościowymi,
• obowiązek zgłaszania zdarzeń mogących istotnie wpłynąć na zdolność świadczenia usługi,
• wdrożone i testowane plany awaryjne oraz środki, narzędzia i polityki bezpieczeństwa ICT,
• udział i pełną współpracę w testach penetracyjnych pod kątem wyszukiwania zagrożeń (TLPT), jeżeli Państwa systemy są w zakresie testu,
• nieograniczone prawa dostępu, kontroli i audytu po stronie klienta, wyznaczonego audytora albo organu, wraz z prawem sporządzania kopii dokumentacji,
• strategię wyjścia: okres przejściowy, dalsze świadczenie usługi, migrację albo przeniesienie do struktur wewnętrznych klienta.

Z naszej praktyki negocjacyjnej wynika, że napięcie koncentruje się w trzech miejscach: zakresie prawa do audytu, dostępie do infrastruktury dostawcy i wykonalności strategii wyjścia. Klauzula „audyt po uprzednim uzgodnieniu terminu i zakresu” bywa czytana przez nadzór jako osłabienie obowiązku ustawowego. Argument „u nas możliwy jest wyłącznie audyt zdalny, bo świadczymy usługę w modelu SaaS” również nie zamyka tematu — wymaga uzasadnienia i zwykle uzupełnienia o inne mechanizmy zapewnienia.

Osobnym obszarem są podwykonawcy. Hosting u dostawcy chmury, zespoły realizujące prace poza Polską, zewnętrzna usługa zarządzania tożsamością — bank musi to widzieć. Przy usługach wspierających funkcje krytyczne lub istotne zmiana istotnego podwykonawcy wymaga wcześniejszego powiadomienia, a często zgody. Państwa własne umowy z podwykonawcami muszą przenosić prawa z art. 30 w dół łańcucha. W przeciwnym razie zobowiązują się Państwo wobec banku do czegoś, czego sami nie mają zagwarantowanego.

Są natomiast obowiązki, których bank nie przeniesie żadnym aneksem:

• zgłoszenie poważnego incydentu związanego z ICT do KNF (art. 19 DORA) — to jego zgłoszenie, jego klasyfikacja i jego terminy,
• prowadzenie rejestru informacji i przekazanie go organowi nadzoru,
• odpowiedzialność organu zarządzającego banku za ramy zarządzania ryzykiem ICT,
• decyzja o tym, czy dana funkcja jest krytyczna lub istotna — to klasyfikacja po stronie klienta, którą jednak muszą Państwo znać, bo od niej zależy, czy w grę wchodzi art. 30 ust. 3.

Można natomiast — i warto — uzgodnić poziom usług dla notyfikacji, format danych do rejestru, okna audytowe, zasady udziału w TLPT oraz cenę wsparcia przy incydencie.

Kiedy KSC staje się Państwa własnym reżimem

Ustawa o KSC nie pyta o status klienta. Pyta, czy Państwa firma świadczy usługę wskazaną w załączniku i czy przekracza próg wielkościowy.

Poniżej 5 sytuacji, które w praktyce najczęściej prowadzą do błędnej samooceny:

1. „Tylko piszemy kod” — podczas gdy umowa obejmuje administrację środowiskiem produkcyjnym, dyżury, wgrywanie poprawek, kopie zapasowe i dostęp do systemu zarządzania tożsamością. To dostawca usług zarządzanych.
2. „Jesteśmy za mali na NIS2” — podczas gdy w ofercie jest SOC albo vCISO. MSSP jest podmiotem kluczowym już od progu małego przedsiębiorcy.
3. „Bank ma DORA, więc KSC nas nie dotyczy” — art. 8i działa wobec sektora bankowości i instytucji z sektora finansowego, nie wobec ich dostawców.
4. „Jedna spółka w grupie zajmie się wpisem” — obowiązek jest przypisany do podmiotu. Spółka świadcząca usługi IT na rzecz grupy może samodzielnie spełniać przesłanki.
5. „Doradztwo to nie usługa zarządzana” — definicja z art. 2 pkt 4j wymienia doradztwo wprost, z zastrzeżeniem oceny opisanej wyżej.

Jeżeli kwalifikacja wypada pozytywnie, Państwa ścieżka jest niezależna od aneksu podpisanego z bankiem czyli wniosek o wpis do Wykazu KSC (dla podmiotów spełniających przesłanki 3 kwietnia 2026 r. — do 3 października 2026 r.). Później wdrożenie systemu zarządzania bezpieczeństwem informacji oraz pozostałych obowiązków i podłączenie do systemu S46 do 3 kwietnia 2027 r., a dla podmiotów kluczowych pierwszy audyt bezpieczeństwa do 3 kwietnia 2028 r.

Warto też znać skalę odpowiedzialności. Dla podmiotu kluczowego maksymalna kara pieniężna sięga 10 mln euro albo 2% przychodu, dla podmiotu ważnego — 7 mln euro albo 1,4% przychodu. Nie przywołujemy tych liczb po to, żeby straszyć. Przywołujemy je, bo pomagają ustawić priorytet tego zadania wobec wszystkich innych, które konkurują o czas zespołu.

Jeden incydent, kilka zegarów

To miejsce, w którym najłatwiej się pogubić, jeżeli czytało się tylko jedno opracowanie.

Po stronie DORA klasyfikacji dokonuje podmiot finansowy i to on zgłasza incydent do KNF. Terminy określa rozporządzenie delegowane (UE) 2025/301. Wstępne powiadomienie w ciągu 4 godzin od zaklasyfikowania incydentu jako poważny, lecz nie później niż 24 godziny od powzięcia o nim wiedzy. Dalej sprawozdanie śródokresowe w ciągu 72 godzin i sprawozdanie końcowe w ciągu miesiąca. Cztery godziny to bardzo mało, jeżeli informacja o awarii dociera do klienta z opóźnieniem. Umowa powinna więc rozstrzygać kto eskaluje, jakim kanałem, w jakim czasie i z jakim minimalnym zestawem faktów — usługa, zakres, dane, czy zdarzenie trwa, czy istnieje rozwiązanie zastępcze.

Po stronie KSC, jeżeli Państwa firma sama jest podmiotem kluczowym albo ważnym, zgłaszają Państwo swój poważny incydent do właściwego CSIRT. Tutaj wczesne ostrzeżenie w 24 godziny, zgłoszenie incydentu w 72 godziny, sprawozdanie końcowe w ciągu miesiąca (art. 11 ustawy o KSC). Ta ścieżka nie zastępuje notyfikacji klienta — i odwrotnie, wiadomość do banku nie zwalnia z obowiązku wobec CSIRT.

Jeżeli zdarzenie obejmuje dane osobowe, dochodzi trzeci zegar: 72 godziny na zgłoszenie naruszenia Prezesowi UODO.

Trzy ścieżki, jedna procedura, imiennie wskazane osoby odpowiedzialne. Bez tego dyżurny o trzeciej w nocy podejmuje decyzję, której nie powinien podejmować sam.

Warto również zapisać jedną granicę. Ocena, czy incydent jest po stronie banku „poważny”, nie należy do Państwa. Do Państwa należy ocena, czy zdarzenie u Państwa przekracza próg z ustawy o KSC oraz czy klient otrzymał dość faktów, aby zdążyć z własną klasyfikacją. Obie te oceny warto dokumentować na bieżąco, a nie odtwarzać po fakcie.

Co warto zrobić w najbliższych tygodniach

Kolejność ma znaczenie, ponieważ pierwsze dwa kroki przesądzają o zakresie pozostałych.

1. Inwentaryzacja usług, nie umów. Przy każdej usłudze proszę rozstrzygnąć trzy rzeczy: czy występuje aktywna administracja, czy występuje element cyberbezpieczeństwa, czy jest to wyłącznie licencja albo wdrożenie. Wynik warto przedstawić organowi zarządzającemu do akceptacji.
2. Kwalifikacja KSC. Sektor, wielkość liczona z uwzględnieniem przedsiębiorstw partnerskich i powiązanych, status podmiotu, tryb wpisu do wykazu.
3. Mapa klientów z sektora finansowego. Które umowy wspierają funkcję krytyczną lub istotną i kto potwierdził to na piśmie.
4. Pakiet danych do rejestru informacji. opis usług, lokalizacje przetwarzania, lista podwykonawców, certyfikaty, wyniki testów ciągłości działania — jeden aktualizowany dokument zamiast korespondencji przy każdym zapytaniu.
5. Własny wzór aneksu DORA. Zamiast przyjmować wzory od każdego klienta osobno, warto raz przygotować własny zestaw postanowień odpowiadających art. 30 ust. 2 i 3, uwzględniając prawo do audytu, ceną pomocy przy incydencie i warunkami wyjścia z usługi.
6. Lustrzane zapisy w umowach z podwykonawcami, inaczej zobowiązania z art. 30 ust. 3 pozostaną deklaracją bez pokrycia.
7. Procedura obsługi incydentu z kanałem całodobowym, czasem eskalacji do klienta z sektora finansowego, odrębną ścieżką do CSIRT i ścieżką wynikającą z RODO.
8. Wycena zobowiązań. Audyt u Państwa, udział w TLPT, okres przejściowy przy wyjściu — to realne koszty. Jeżeli nie zostaną nazwane w umowie, sfinansuje je marża na utrzymaniu.

Podsumowanie

DORA jest dla Państwa warunkiem wejścia i utrzymania się na rynku finansowym — realizowanym przez umowę, a nie przez bezpośrednie obowiązki wobec KNF. Ustawa o KSC może natomiast być Państwa własnym reżimem, jeżeli administrują Państwo cudzymi systemami albo je chronią. Bank przeniesie klauzule. Nie przeniesie swojej odpowiedzialności wobec organu nadzoru i nie zajmie się za Państwa wpisem do Wykazu KSC.

Rozdzielenie tych dwóch porządków to zwykle kwestia kilku dni rzetelnej analizy, a nie kilku miesięcy programu wdrożeniowego. Warto ją wykonać przed 3 października, a nie po.

Jak możemy pomóc

W Secureside układamy te warstwy w jedną mapę. Kwalifikację jako dostawcy usług zarządzanych albo MSSP wraz z uzasadnieniem gotowym do przedstawienia organowi, pakiet danych do rejestru informacji DORA, własny wzór aneksu w zakresie art. 30 oraz procedurę obsługi incydentu uwzględniającą wszystkie obowiązujące terminy.

Pracujemy tak, aby zaangażowanie Państwa zespołu było możliwie najmniejsze. Analizę prowadzimy na dokumentach i krótkich rozmowach warsztatowych, a Państwo otrzymują decyzje do zatwierdzenia, nie zadania do wykonania. Przez cały czas trwania współpracy mają Państwo jedną dedykowaną osobę kontaktową.

Jeżeli obsługują Państwo sektor finansowy i chcą mieć pewność, że nie płacą za cudzy reżim ani nie przeoczą własnego — zapraszamy do rozmowy.