Dostawca na audycie

Od 15 września 2026 r. audyt wewnętrzny pracujący według standardów IIA musi stosować Third-Party Topical Requirement, czyli obowiązkowe wymaganie dotyczące relacji z dostawcami. Łatwo to przeoczyć, bo to „tylko” standard zawodowy audytorów. Skutek jest jednak praktyczny. Pytania o dostawców, które dotąd padały głównie podczas kontroli regulatora, teraz wcześniej zada własny audyt. Zada je z gotową metodyką i z obowiązkiem udokumentowania, co sprawdził.

Czego właściwie wymaga IIA

Wymaganie wydano 15 września 2025 r., a obowiązuje od 15 września 2026 r. Jest nowym, obowiązkowym elementem ram IPPF. Nie wiąże ono organizacji bezpośrednio, tylko funkcję audytu wewnętrznego. Audytor stosuje je przy zadaniach zapewniających w trzech sytuacjach: gdy temat dostawców jest w planie audytu, gdy wyjdzie w trakcie innego zadania albo gdy ktoś zleci taki przegląd poza planem. Musi też zachować dowód, że każdy element wymagania ocenił pod kątem zastosowania. Zakres obejmuje cały cykl relacji: wybór dostawcy, umowę, wdrożenie, bieżący monitoring i zakończenie współpracy. Tam, gdzie ma to znaczenie, obejmuje też dalszych podwykonawców.

Trzech pytających, jedno pytanie

NIS2 w art. 21 każe uwzględnić bezpieczeństwo łańcucha dostaw, w tym praktyki bezpośrednich dostawców. DORA idzie znacznie dalej. W art. 28–30 wymaga rejestru informacji, oceny ryzyka przed zawarciem umowy, analizy koncentracji, konkretnych klauzul umownych i strategii wyjścia dla funkcji krytycznych lub istotnych. IIA merytorycznie niczego tu nie dokłada. Dokłada metodę sprawdzania.

W praktyce regulator, nadzór i audytor chcą wiedzieć to samo: czy potrafią Państwo odtworzyć łańcuch od funkcji biznesowej, przez usługę i dostawcę, aż po kontrolę, właściciela i dowód. Chodzi o to, żeby dało się to zrobić bez sklejania odpowiedzi w noc przed audytem.

Że to nie jest akademicki problem, pokazuje pierwszy raport ESA o poważnych incydentach ICT za 2025 r. Autorzy sami przyznają, że awaria wspólnej infrastruktury potrafi wygenerować dziesiątki powiązanych incydentów w różnych podmiotach. Kiedy zawodzi dostawca, zawodzi wielu naraz. Lista z nazwą firmy, kategorią usługi i mailem do opiekuna nie powie Państwu, co się wtedy stanie u Państwa.

Karta dostawcy krytycznego

Zamiast rozbudowanego rejestru wystarczy jedna karta dla każdego dostawcy, który wspiera funkcję krytyczną. Powinna zawierać:

• usługę i proces biznesowy, który wspiera, wraz z uzasadnieniem poziomu krytyczności,
• ocenę ryzyka sprzed podpisania umowy i datę jej ostatniej aktualizacji,
• decyzję o akceptacji ryzyka, podjętą na właściwym szczeblu, a nie tylko w dziale zakupów,
• kluczowe klauzule: prawo do audytu, wsparcie przy incydencie, podwykonawstwo, wypowiedzenie,
• wyniki monitoringu, w tym odchylenia od SLA i sposób ich obsłużenia,
• istotnych podwykonawców,
• plan wyjścia i odpowiedź na niewygodne pytanie, czy ktoś go kiedykolwiek przećwiczył.

Wypełniony kwestionariusz od dostawcy to dopiero punkt startu. Audytor zapyta, co z niego wynikło.

Podwykonawcy bez rejestru nie do utrzymania

Próba zmapowania wszystkich podwykonawców wszystkich dostawców kończy się rejestrem, który po kwartale nikt już nie aktualizuje. Rozsądniej jest ograniczyć głębokość analizy do dostawców funkcji krytycznych i przenieść obowiązek nadzoru do umowy. Dostawca pierwszego szczebla informuje o kluczowych podwykonawcach i odpowiada za nich. Podmioty objęte DORA mają tu dodatkowo ramy z RTS 2025/532. Dowodem dla audytora jest działający mechanizm, a nie samodzielnie narysowana mapa całego łańcucha.

Od czego zacząć

Proponuję prosty test. Proszę wybrać jedną usługę krytyczną i sprawdzić, czy w ciągu kilku godzin da się zebrać pełny obraz zależności, od procesu po plan wyjścia. Jeśli tak, większa część pracy przed audytem jest już za Państwem. Jeśli nie, mają Państwo gotowy priorytet na najbliższe tygodnie. Lepiej, żeby ta luka wyszła w raporcie audytu wewnętrznego niż w protokole z kontroli.

W Secureside od takiego testu zaczynamy współpracę. Przeglądamy umowy i budujemy kartę dla jednej usługi, bez angażowania całego zespołu po Państwa stronie.

Źródła

• The IIA, Third-Party Topical Requirement: https://www.theiia.org/en/standards/2024-standards/topical-requirements/third-party/
• The IIA, Topical Requirements: https://www.theiia.org/en/standards/2024-standards/topical-requirements/
• Dyrektywa (UE) 2022/2555 (NIS2), art. 21, EUR-Lex
• Rozporządzenie (UE) 2022/2554 (DORA), art. 28–30, EUR-Lex
• Rozporządzenie delegowane (UE) 2025/532 (RTS dot. podwykonawstwa), EUR-Lex
• ESAs, pierwszy raport o poważnych incydentach ICT na podstawie DORA: https://www.esma.europa.eu/press-news/esma-news/esas-publish-first-report-dora-major-ict-related-incidents
• Ustawa o krajowym systemie cyberbezpieczeństwa (t.j. Dz.U. 2026 poz. 20)

Grzegorz Bielecki

vCISO, vCIO i certyfikowany ekspert ds. bezpieczeństwa (CISM, CDPSE, CEH, ISO 27001 Lead Auditor). Od ponad 15 lat wspiera głównie sektor finansowy w budowaniu odporności cyfrowej. Architekt wdrożeń DORA, NIS2\UKSC oraz norm ISO 27001 (SZBI) i ISO 22301 (SZCD). Posiada doświadczenie w projektach zgodności IT przy pozyskiwaniu licencji KIP KNF. Członek ISSA Polska.