Przez lata rozmowa z audytorem o testach kończyła się na checkliście: jest plan testów, jest regresja, są raporty — odhaczone. DORA i NIS 2 zmieniają samo pytanie. Nie „czy macie testy", tylko „czy wykażecie dowodami, że proces, od którego zależą klienci, przetrwa zakłócenie i wdrożenie". To różnica między dokumentem a dowodem — i większość procesów testowych, które znamy z projektów, nie jest dziś gotowa jej obsłużyć.
Zmiana ciężaru: z checklisty na odporność operacyjną
DORA — unijne rozporządzenie o cyfrowej odporności operacyjnej — jest stosowana od stycznia 2025 i obejmuje sektor finansowy UE: banki, ubezpieczycieli, firmy inwestycyjne, instytucje płatnicze, a pośrednio także ich dostawców usług ICT. NIS 2 rozszerza podobną filozofię na znacznie szerszy krąg sektorów: m.in. energetykę, zdrowie, transport i logistykę, usługi kurierskie czy infrastrukturę cyfrową.
Wspólny mianownik obu regulacji jest jeden: odporność operacyjna zamiast zgodności dokumentowej. Nie wystarczy mieć procedurę testowania — trzeba umieć wykazać, że krytyczne procesy biznesowe są regularnie testowane od końca do końca, że organizacja wie, co się stanie przy awarii komponentu lub dostawcy, i że potrafi to udokumentować na żądanie. Dla zespołów QA to dobra wiadomość, choć niewygodna: testy przestają być kosztem do optymalizacji, a stają się dowodem, którego zarząd potrzebuje. Niewygodna — bo trzeba je umieć pokazać na poziomie procesu, nie repozytorium.
Cztery obszary DORA, które dotykają testów
DORA to setki stron, ale z perspektywy procesu testowego liczą się cztery obszary. Mapujemy je tak samo, jak w naszym przeglądzie sektorów regulowanych — i dla każdego dopisujemy, co oznacza w praktyce.
1. Zarządzanie ryzykiem ICT. Organizacja ma znać swoje krytyczne funkcje i ryzyka z nimi związane. W praktyce testowej: wyniki testów muszą być powiązane z procesami biznesowymi, nie z repozytoriami kodu. „Pokrycie 84% w serwisie X" nie odpowiada na pytanie o ryzyko procesu sprzedaży kredytów. Potrzebny jest ślad: który proces, które testy, kiedy uruchomione, z jakim wynikiem.
2. Testowanie odporności operacyjnej. DORA wprost wymaga programu testowania odporności cyfrowej — a w katalogu dopuszczalnych metod wymienia m.in. testy scenariuszowe i testy end-to-end. To już nie jest „nice to have": scenariusze zakłóceń krytycznych procesów (co się dzieje, gdy komponent w środku ścieżki przestaje odpowiadać?) stają się elementem programu, który trzeba prowadzić regularnie i dokumentować.
3. Zarządzanie incydentami. Regulacja wymaga klasyfikacji i raportowania poważnych incydentów w reżimie czasowym. Testy nie raportują incydentów — ale decydują o tym, ile ich będzie i jak szybko zostaną wykryte. Defekty na stykach aplikacji, wykryte w regresji zamiast na produkcji, to niższy MTTR i mniej zgłoszeń do przygotowania. A gdy incydent już wystąpi, historia wykonań testów jest częścią materiału do analizy przyczyn.
4. Ryzyko stron trzecich. Proces kredytowy nie kończy się na systemach banku: scoring, biura informacji kredytowej, operatorzy płatności, usługi chmurowe. DORA każe zarządzać ryzykiem tych zależności — a najtańszym sposobem zarządzania nim w warstwie funkcjonalnej są testowane kontrakty danych na stykach z dostawcami. Jeśli dostawca zmieni format odpowiedzi, chcesz to wiedzieć z testu kontraktowego, nie z incydentu.
Regulator nie oczekuje, że nic nigdy nie zawiedzie. Oczekuje, że wiesz, co może zawieść, że to regularnie sprawdzasz — i że masz na to dowody z datą i wynikiem.
NIS 2 — szerszy krąg, inna perspektywa
Jeżeli DORA jest precyzyjną regulacją sektorową, NIS 2 jest dyrektywą horyzontalną: obejmuje podmioty kluczowe i ważne w kilkunastu sektorach gospodarki, od energetyki i zdrowia po transport, logistykę i usługi kurierskie. Szczegóły w Polsce doprecyzowuje nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa. Z perspektywy testów dwie rzeczy zmieniają rozmowę:
- Odpowiedzialność zarządu. NIS 2 przypisuje organom zarządzającym obowiązek zatwierdzania środków zarządzania ryzykiem i nadzoru nad ich wdrożeniem — z osobistą odpowiedzialnością włącznie. Pytanie „czy nasze krytyczne procesy są przetestowane?" przestaje być pytaniem technicznym i trafia na poziom zarządu. Zarząd nie przeczyta logów z CI — potrzebuje jednej liczby i trendu.
- Raportowanie incydentów w reżimie czasowym. Wczesne ostrzeżenie w ciągu 24 godzin, pełniejsze zgłoszenie w 72 godziny. Tego rytmu nie da się utrzymać, jeśli wykrywanie problemów na stykach systemów zaczyna się dopiero od zgłoszenia klienta.
Praktyczna konsekwencja: organizacja objęta NIS 2 potrzebuje metryki jakości na poziomie procesu biznesowego — czegoś, co zarząd może zatwierdzić, śledzić i pokazać organowi nadzorczemu. Metryki komponentowe (pokrycie kodu, liczba przypadków testowych) tej roli nie pełnią.
Co konkretnie zmienić w testach — cztery ruchy
E2E krytycznych procesów na realnych stykach, nie na mockach. Mock zwraca założenia autora testu — audytora i regulatora interesuje realne zachowanie. Dla procesu kredytowego oznacza to automatyzację pełnej ścieżki sprzedaż → uruchomienie → spłata → zamknięcie, z wariantami (np. kredyt konsolidacyjny) jako gałęziami tej samej ścieżki, przechodzącą przez rzeczywiste integracje między systemami.
Testy integracji z dostawcami zewnętrznymi. Każdy styk z zewnętrzną usługą to kontrakt danych: format, znaczenie pól, zachowanie w przypadkach brzegowych. Kontrakty powinny być spisane, wersjonowane i testowane automatycznie — tak, żeby dryf po stronie dostawcy wykrywał test, a nie produkcja.
Scenariusze niedostępności komponentów. Co robi proces, gdy system scoringowy nie odpowiada? Degraduje się kontrolowanie, kolejkuje, czy po cichu gubi wnioski? Takich scenariuszy nie trzeba testować wyłączaniem realnych systemów — service virtualization pozwala symulować niedostępność i błędne odpowiedzi w powtarzalny sposób. To dokładnie ta klasa testów scenariuszowych, o którą pyta DORA.
Kompletny ślad audytowy wykonań. Każde wykonanie testu powinno zostawiać zapis: co uruchomiono, kiedy, na jakiej wersji systemów, z jakim wynikiem i którego procesu biznesowego dotyczyło. Jeśli regresję trzeba uruchamiać ręcznie, a wyniki żyją w arkuszach — śladu nie będzie. Regresja musi być uruchamiana automatycznie lub na żądanie, a wyniki archiwizowane w jednym miejscu.
Dowód dla audytora: liczba, raport, wersja
Audyt to w istocie test na jedno pytanie: pokażcie, że wiecie. W praktyce sprawdzają się trzy rodzaje dowodów:
- Metryka pokrycia procesów. Business Journey Coverage (BJC) — odsetek krytycznych procesów biznesowych z aktualną, zieloną automatyzacją E2E przez realne styki. Jedna liczba, którą zarząd może zatwierdzić i raportować, a audytor zweryfikować w dół, aż do pojedynczych wykonań.
- Raporty z kokpitu. W Smart Testing Suite tę rolę pełni Smart.Kokpit: procesy, pokrycie, wyniki ostatnich wykonań i trend w czasie, z możliwością zejścia do konkretnego przebiegu. Uczciwie: kokpit nie zastąpi dokumentacji wymaganej przez regulacje — daje jednak dane źródłowe, bez których ta dokumentacja jest deklaracją.
- Wersjonowane kontrakty danych. Dowód, że styk między systemami — także z dostawcą zewnętrznym — był zdefiniowany, testowany i zmieniany w kontrolowany sposób. To odpowiedź na pytania o ryzyko stron trzecich, na które trudno odpowiedzieć inaczej niż „ufamy im".
Pułapka: pen testing to nie to samo co odporność procesu
Najczęstszy skrót myślowy, jaki spotykamy: „mamy TLPT, więc DORA-testy mamy z głowy". Threat-led penetration testing — testy penetracyjne prowadzone według analizy zagrożeń — to ważny, wprost wymagany przez DORA element dla wybranych podmiotów. Ale to warstwa security: odpowiada na pytanie, czy napastnik przełamie zabezpieczenia.
Testy odporności funkcjonalno-procesowej odpowiadają na inne pytanie: czy proces kredytowy przetrwa awarię komponentu, zmianę u dostawcy i najbliższe wdrożenie. Zaliczony pen test nie dowodzi, że harmonogram spłat wygeneruje się po uruchomieniu kredytu — i odwrotnie. Obie warstwy są potrzebne i żadna nie zastępuje drugiej; my zajmujemy się tą drugą, a z zespołami security te dowody się po prostu uzupełniają.
Plan minimum na kwartał
Nie trzeba zaczynać od programu na całą organizację. Realny plan na jeden kwartał wygląda tak:
- Tygodnie 1–2: inwentaryzacja. Lista procesów krytycznych — tych, których zakłócenie ma skutki dla klientów lub obowiązki raportowe. Wybór jednego, maksymalnie dwóch, na start.
- Tygodnie 3–4: mapa styków. Dla wybranego procesu: które systemy, jakie kontrakty danych między nimi, gdzie dostawcy zewnętrzni. Sama ta mapa zwykle odsłania styki, których nie testuje nikt.
- Miesiąc 2: pierwsze dowody. Automatyzacja E2E głównej ścieżki na realnych stykach, pierwsze testy kontraktowe na najbardziej ryzykownym styku, jeden scenariusz niedostępności kluczowego komponentu.
- Miesiąc 3: pomiar i raport. Uruchomienie śladu audytowego, pomiar BJC jako punktu wyjścia i raport dla zarządu: jedna liczba, lista luk, rekomendacja rozszerzenia.
To celowo zakres zbieżny z naszym pilotażem 90 dni — bo kwartał na jednym procesie to najkrótsza droga, żeby zamiast deklaracji mieć pierwsze dowody. Regulacje nie wymagają, żeby wszystko było gotowe jutro. Wymagają, żeby dało się pokazać, że proces dochodzenia do odporności trwa i jest mierzony.
Chcesz zobaczyć, jak mierzymy pokrycie procesów? Business Journey Coverage → · Jak pracujemy w sektorach regulowanych: Sektory →