Nadzór nad dostawcą MDR na potrzeby NIS2, DORA i GDPR

O 02:13 w poniedziałek rano dostawca MDR otwiera alert o wysokiej krytyczności: niemożliwa podróż, podejrzane reguły skrzynki pocztowej oraz konto uprzywilejowane użyte z niezarządzanego punktu końcowego. Analityk SOC eskaluje sprawę przez portal zgłoszeniowy. Menedżer IT śpi. CFO otrzymuje ostrzeżenie phishingowe od kontaktu w banku, zanim wewnętrzny kanał incydentowy zacznie działać. O 07:30 CISO mierzy się z trzema niewygodnymi pytaniami.

Kto miał uprawnienia do ogłoszenia incydentu?

Czy możemy wykazać, że dostawca MDR dysponował właściwymi logami, przechowywał je wystarczająco długo i zabezpieczył materiał dowodowy?

Jeżeli doszło do dostępu do danych osobowych, czy dział prawny zdąży przeprowadzić ocenę naruszenia w terminach GDPR, podczas gdy operacje przygotowują zgłoszenie na potrzeby NIS2 lub DORA?

Miesiąc później audytor zewnętrzny prosi o te same dowody, tylko innym tonem. Raport PDF dostawcy MDR jest przydatny, ale niewystarczający. Audytor oczekuje nieprzetworzonych danych alertu, kompletnych plików logów, ścieżki eskalacji, wewnętrznego dziennika decyzji, zapisu przeglądu dostawcy oraz dowodu, że organizacja mogła niezależnie zweryfikować, co się wydarzyło.

To jest problem nadzoru nad dostawcą MDR w 2026 r. Organizacje zlecają wykrywanie i reagowanie na zewnątrz, ponieważ wewnętrzna zdolność SOC jest kosztowna, rekrutacja trudna, a aktywność zagrożeń nieustanna. Jednak outsourcing wykrywania nie oznacza outsourcingu rozliczalności. Zgodnie z NIS2 organy zarządzające pozostają odpowiedzialne za zatwierdzanie i nadzorowanie środków zarządzania ryzykiem cyberbezpieczeństwa. Zgodnie z DORA podmioty finansowe pozostają w pełni odpowiedzialne za ryzyko stron trzecich ICT, w tym krytyczne usługi ICT, wsparcie incydentowe, prawa do audytu, podwykonawstwo i wyjście z usługi. Zgodnie z GDPR administratorzy muszą wykazać odpowiednie bezpieczeństwo przetwarzania, zwłaszcza gdy podmioty przetwarzające obsługują telemetrię, dane punktów końcowych, identyfikatory użytkowników, adresy IP, treść wiadomości e-mail, logi lub obrazy kryminalistyczne.

Praktyczna luka rzadko dotyczy samej umowy MDR. Dotyczy łańcucha dowodowego między umową a usługą produkcyjną: kierowania alertów, dostępu uprzywilejowanego, retencji logów, progów eskalacji, materiału dowodowego incydentu, przejrzystości podwykonawców, klauzul dotyczących podmiotów przetwarzających, przeglądów usług, ćwiczeń sztabowych i raportowania dla kierownictwa.

Możliwy do obrony program nadzoru nad dostawcą MDR wymaga jednego modelu operacyjnego, który obsłuży wiele rozmów audytowych. ISO/IEC 27001:2022 zapewnia ten kręgosłup.

Nadzór nad MDR zaczyna się od rozliczalności, nie od konsoli SOC

Częstym błędem jest traktowanie wdrożenia usługi MDR jako projektu technicznego: wdrożyć agentów EDR, przekazać logi tożsamości, skonfigurować alerty, uzgodnić kanał Teams lub Slack i uruchomić usługę produkcyjnie. Może to poprawić wykrywanie, ale nie dowodzi ładu zarządczego.

NIS2 ujmuje ten problem wprost. Podmioty kluczowe i ważne muszą wdrożyć odpowiednie i proporcjonalne techniczne, operacyjne i organizacyjne środki zarządzania ryzykiem cyberbezpieczeństwa. Article 21 obejmuje analizę ryzyka, obsługę incydentów, ciągłość działania, bezpieczeństwo łańcucha dostaw, cyberhigienę, kontrolę dostępu, zarządzanie aktywami, kryptografię i uwierzytelnianie wieloskładnikowe. Article 20 podnosi ten wymóg do poziomu rozliczalności organu zarządzającego, wymagając zatwierdzania i nadzoru nad tymi środkami.

Dostawcy MDR często obejmują jednocześnie kilka obszarów NIS2 Article 21:

• Obsługa incydentów, ponieważ dostawca prowadzi wstępną kwalifikację, eskaluje sprawy i może rekomendować powstrzymywanie.
• Bezpieczeństwo łańcucha dostaw, ponieważ dostawca jest bezpośrednim dostawcą usług mającym wpływ na bezpieczeństwo operacyjne.
• Kontrola dostępu, ponieważ dostawca może uzyskiwać dostęp do konsol, logów, narzędzi punktów końcowych lub dzierżaw chmurowych.
• Rejestrowanie i monitorowanie, ponieważ wykrywanie zależy od pokrycia logowaniem, retencji i korelacji.
• Cyberhigiena, ponieważ ustalenia MDR często ujawniają słabości w poprawkach, tożsamości lub konfiguracji.
• Ciągłość działania, ponieważ opóźniona reakcja może zakłócić usługi krytyczne.

W przypadku podmiotów finansowych DORA zaostrza model operacyjny. DORA ma zastosowanie od 17 stycznia 2025 r. i wymaga zarządzania ryzykiem ICT, zgłaszania incydentów, testowania odporności, wymiany informacji oraz zarządzania ryzykiem stron trzecich ICT. Wyjaśnia również, że wobec podmiotów finansowych zidentyfikowanych także na podstawie NIS2 DORA działa jako sektorowy akt prawny Unii dla pokrywających się obowiązków cyberbezpieczeństwa. Regulowany bank, instytucja płatnicza, firma inwestycyjna, ubezpieczyciel lub dostawca usług w zakresie kryptoaktywów nie może po prostu stwierdzić: „Tym zajmuje się nasz dostawca MDR”. DORA oczekuje, że podmiot będzie klasyfikował incydenty ICT, zarządzał zewnętrznymi dostawcami usług ICT i monitorował ich, utrzymywał rejestry uzgodnień dotyczących usług ICT, definiował prawa umowne, testował odporność, przeprowadzał analizę przyczyny źródłowej oraz etapowo zgłaszał poważne incydenty związane z ICT.

GDPR dodaje inną perspektywę. Jeżeli telemetria MDR obejmuje identyfikatory użytkowników, adresy IP, metadane poczty elektronicznej, zapisy uwierzytelniania, artefakty punktów końcowych lub pliki zawierające dane osobowe, zastosowanie mają zasady bezpieczeństwa i rozliczalności GDPR. Article 5 obejmuje integralność, poufność i rozliczalność. Article 32 dotyczący bezpieczeństwa przetwarzania staje się praktycznym pytaniem o dowody: czy logi były chronione, czy dostęp był ograniczony, czy zastosowano szyfrowanie tam, gdzie było to właściwe, czy podmioty przetwarzające były nadzorowane i czy organizacja może wykazać, co się wydarzyło?

Przekaz jest spójny we wszystkich trzech reżimach: można delegować wykonanie pracy, ale nie można delegować odpowiedzialności.

ISO/IEC 27001:2022 przekształca MDR w proces możliwy do audytu

Dobrze wdrożony SZBI oparty na ISO/IEC 27001:2022 przekształca nadzór nad dostawcą MDR z deklaracji zarządzania dostawcą w model operacyjny oparty na dowodach. Clause 8.1 jest szczególnie ważna, ponieważ wymaga od organizacji kontrolowania procesów, produktów i usług dostarczanych z zewnątrz, które są istotne dla SZBI. MDR jest dokładnie takim przypadkiem: procesem dostarczanym z zewnątrz, który może wpływać na reagowanie na incydenty, prywatność, odporność, raportowanie regulacyjne i ciągłość działania.

Najważniejsze obszary Annex A ISO/IEC 27001:2022 dla nadzoru nad MDR obejmują relacje z dostawcami, wymagania bezpieczeństwa w umowach z dostawcami, zarządzanie ryzykiem łańcucha dostaw ICT, monitorowanie usług dostawców, zarządzanie incydentami, postępowanie z materiałem dowodowym, rejestrowanie, monitorowanie, kontrolę dostępu, dostęp uprzywilejowany, kryptografię i gotowość do zapewnienia ciągłości działania.

Zenith Controls: The Cross-Compliance Guide Clarysec Zenith Controls jest punktem odniesienia dla zgodności wieloreżimowej w tej pracy. Mapuje środki kontrolne ISO/IEC 27002:2022 na inne wymagania, powiązane środki kontrolne, oczekiwania audytowe i dowody wdrożenia. Dla nadzoru nad MDR kluczowe są trzy środki kontrolne ISO/IEC 27002:2022: 5.19 dla relacji z dostawcami, 5.22 dla monitorowania usług dostawców i zarządzania zmianami oraz 8.15 dla rejestrowania. Wspierają je 5.20 umowy z dostawcami, 5.21 bezpieczeństwo łańcucha dostaw ICT, 5.24 do 5.28 zarządzanie incydentami i postępowanie z materiałem dowodowym, 5.34 prywatność i PII, 5.36 zgodność, 8.16 działania monitorujące, 8.17 synchronizacja czasu, 8.18 użycie uprzywilejowanych programów narzędziowych oraz 8.8 zarządzanie podatnościami technicznymi.

Ma to znaczenie, ponieważ niepowodzenie audytu MDR rzadko brzmi „brak MDR”. Zwykle brzmi jak jedna z poniższych sytuacji:

• Dostawca MDR nie został sklasyfikowany jako krytyczny.
• Klauzule umowne nie obejmowały powiadamiania o incydentach, dostępu do materiału dowodowego ani praw do audytu.
• Logi nie były przechowywane wystarczająco długo, aby zbadać zgłoszone zdarzenie.
• Dostęp dostawcy był współdzielony, stały lub niemonitorowany.
• Klient nie dokonywał przeglądu wyników MDR względem SLA.
• Podwykonawcy lub dalsze podmioty przetwarzające nie byli zatwierdzani.
• Obowiązki zgłaszania naruszeń ochrony danych osobowych nie były dostosowane do przepływów pracy incydentowej.
• Materiał dowodowy nie został zabezpieczony w sposób przydatny kryminalistycznie.
• Kierownictwo nie miało metryk pokazujących, czy usługa MDR ograniczała ryzyko.

Zenith Controls jasno opisuje relację między oczekiwaniami wobec dostawców a umowami:

„5.19 określa oczekiwania bezpieczeństwa dotyczące tego, jak dostawcy powinni postępować z informacjami organizacji. 5.20 formalizuje te oczekiwania, zapewniając, że umowy wyraźnie obejmują klauzule bezpieczeństwa, takie jak wymagania poufności, zgodność z politykami bezpieczeństwa oraz procedury powiadamiania o incydentach. Bez 5.20 wymagania zidentyfikowane w 5.19 mogą nie być prawnie egzekwowalne.”

Dla MDR to jest lekcja ładu zarządczego. Jeżeli umowa nie wymaga od dostawcy przechowywania logów, przekazywania materiału dowodowego, współpracy przy incydentach, ograniczenia podwykonawstwa, wspierania audytów i przestrzegania terminów eskalacji, usługa SOC może być operacyjnie przydatna, ale będzie słaba audytowo.

Co umowa MDR musi potwierdzać przed pierwszym alertem

Dobra umowa MDR nie jest wyłącznie komercyjnym formularzem zamówienia. Jest dokumentem kontrolnym. DORA Articles 28 to 30 wymagają zarządzania ryzykiem stron trzecich ICT w całym cyklu życia, w tym rejestrów umów ICT, klasyfikacji krytyczności, należytej staranności przed zawarciem umowy, podejścia do audytu i inspekcji, praw wypowiedzenia, strategii wyjścia, jasnych opisów usług, poziomów usług, lokalizacji świadczenia usług i przetwarzania danych, zobowiązań dotyczących ochrony danych, wsparcia incydentowego oraz współpracy z organami. NIS2 Article 21 wymaga bezpieczeństwa łańcucha dostaw dla bezpośrednich dostawców i usługodawców. GDPR wymaga określenia ról administratora i podmiotu przetwarzającego, gwarancji podmiotu przetwarzającego, klauzul ochrony danych oraz dowodów bezpieczeństwa przetwarzania.

Biblioteka polityk Clarysec przekłada te obowiązki na praktyczne wymagania umowne i operacyjne. W Enterprise Incident Response Policy Incident Response Policy MDR jest wprost traktowany jako nadzorowana zdolność incydentowa strony trzeciej:

„Integracja z usługami stron trzecich, w tym Managed Detection and Response (MDR), Security Incident and Event Management (SIEM) oraz dostawcami analiz kryminalistycznych, musi być regulowana jasno określonymi umowami o poziomie usług (SLA) i postanowieniami o zachowaniu poufności.”

Ta klauzula ma znaczenie, ponieważ dostawcy MDR często otrzymują wysoce wrażliwe informacje, zanim organizacja wie, czy incydent podlega zgłoszeniu. Telemetria może obejmować nazwy użytkowników, ścieżki plików, tematy wiadomości e-mail, wewnętrzne nazwy hostów, adresy IP, diagramy sieci i wskaźniki naruszenia. Postanowienia o zachowaniu poufności chronią organizację podczas dochodzenia i wspierają rozliczalność na gruncie GDPR.

Enterprise Third party and supplier security policy Third party and supplier security policy dodaje dwie klauzule, których audytorzy oczekują przy przeglądzie nadzoru nad MDR:

„Prawo do audytu, inspekcji i żądania dowodów bezpieczeństwa”

oraz:

„Korzystanie z podwykonawców uzależnione od uprzedniej pisemnej zgody”

Dla MŚP ta sama zasada ładu zarządczego jest skalowana w dół, ale nie znika. Third-Party and Supplier Security Policy - SME Third-Party and Supplier Security Policy - SME wymaga zasady najmniejszych uprawnień:

„Dostawcom należy przyznawać dostęp wyłącznie do minimalnego zakresu systemów i danych wymaganego do wykonania ich funkcji.”

Wymaga również:

„Ograniczeń dalszego podwykonawstwa bez zatwierdzenia”

Te klauzule są szczególnie istotne dla MDR. Wielu dostawców korzysta z wielopoziomowych zespołów SOC, dostawców platform, partnerów w zakresie informacji o zagrożeniach, usług analityki chmurowej lub regionalnego personelu wsparcia. Jeżeli dalsze podmioty mogą uzyskiwać dostęp do logów klienta lub danych osobowych, klient potrzebuje mechanizmów widoczności i zatwierdzania. W ujęciu DORA jest to element nadzoru nad podwykonawstwem i ryzykiem koncentracji. W ujęciu GDPR jest to nadzór nad dalszym podmiotem przetwarzającym. W ujęciu NIS2 jest to zarządzanie ryzykiem łańcucha dostaw.

Kluczowa lista kontrolna nadzoru nad MDR

Możliwa do obrony relacja z dostawcą MDR powinna być testowalna. Poniższa lista kontrolna łączy wymagania umowne, operacyjne i dowodowe w jeden widok kontroli.

Tę listę kontrolną należy włączyć do zakupów, wdrożenia usługi, okresowego przeglądu i testowania incydentów. Jeżeli brakuje któregokolwiek elementu, organizacja powinna traktować to jako ryzyko dostawcy, a nie problem dokumentacyjny.

Siedem domen dowodowych oczekiwanych przez audytorów

Aby nadzór nad MDR był gotowy do audytu, Clarysec zaleca zbudowanie pliku dowodowego MDR zorganizowanego w siedmiu domenach. Plik ten powinien znajdować się w SZBI, a nie w folderze zakupowym, którego nikt nie przegląda.

Ta tabela zmienia rozmowę z dostawcą. Zamiast pytać: „Czy nas monitorujecie?”, organizacja pyta: „Czy co kwartał możemy wykazać, że usługa MDR pozostaje skuteczna, zgodna i dostosowana do naszego apetytu na ryzyko?”

Rejestrowanie jest pomostem między wykrywaniem a dowodami zgodności

MDR bez wiarygodnego rejestrowania to outsourcing domysłów. Dostawca może wykrywać część zagrożeń, ale organizacja nie może udowodnić zakresu, osi czasu, przyczyny źródłowej ani wpływu.

Środek kontrolny ISO/IEC 27002:2022 8.15 obejmuje rejestrowanie. Zenith Controls klasyfikuje rejestrowanie jako kontrolę detekcyjną wspierającą poufność, integralność i dostępność, dostosowaną do koncepcji cyberbezpieczeństwa Detect oraz zdolności zarządzania zdarzeniami bezpieczeństwa informacji. Łączy rejestrowanie bezpośrednio z działaniami monitorującymi, oceną zdarzeń, reagowaniem na incydenty, wnioskami z doświadczeń, dostępem uprzywilejowanym, synchronizacją czasu, kontrolą dostępu, prywatnością, zabezpieczaniem materiału dowodowego, zarządzaniem podatnościami i monitorowaniem bezpieczeństwa fizycznego.

Dlatego rejestrowanie jest kluczowe dla dowodów NIS2, DORA i GDPR Article 32. Zgłaszanie znaczących incydentów zgodnie z NIS2 Article 23 wymaga wczesnego ostrzeżenia w ciągu 24 godzin od uzyskania świadomości, powiadomienia w ciągu 72 godzin oraz raportu końcowego nie później niż miesiąc po powiadomieniu. Zgłaszanie poważnych incydentów związanych z ICT zgodnie z DORA wymaga klasyfikacji, eskalacji, komunikacji, analizy przyczyny źródłowej i raportowania końcowego. Rozliczalność GDPR wymaga od organizacji wykazania, co stało się z danymi osobowymi i czy środki bezpieczeństwa były odpowiednie.

Logging and Monitoring Policy - SME Clarysec Logging and Monitoring Policy - SME zapewnia prostą kontrolę umowną dla mniejszych organizacji korzystających z zewnętrznych dostawców:

„Umowy muszą wymagać od dostawców przechowywania logów przez co najmniej 12 miesięcy oraz zapewnienia dostępu na żądanie”

W środowiskach korporacyjnych Logging and Monitoring Policy Logging and Monitoring Policy dodaje wymaganie integracji operacyjnej:

„Należy przekazywać dane logów na żądanie albo zintegrować się z platformą SIEM/agregacji logów organizacji.”

Te klauzule rozwiązują powtarzający się problem reagowania na incydenty: podczas dochodzenia dostawca MDR stwierdza, że zdarzenie jest starsze niż okno przeszukiwalnej retencji, logi są dostępne tylko przez płatny eksport kryminalistyczny albo SIEM klienta nie zawiera wzbogacenia dostawcy i działań analityków. Jeżeli dostęp do logów nie jest zdefiniowany z wyprzedzeniem, oś czasu incydentu staje się fragmentaryczna.

Silny model rejestrowania MDR powinien definiować obowiązkowe źródła logów, typy zdarzeń, okresy retencji, ochronę integralności, zatwierdzanie dostępu, synchronizację czasu, formaty eksportu i reguły korelacji między platformami klienta i dostawcy. Powinien także obejmować działania dostawcy, w tym zmiany reguł wykrywania, polecenia izolacji punktów końcowych, dostęp administracyjny, notatki analityków i eksporty materiału dowodowego.

Normy wspierające ISO wzmacniają to podejście. ISO/IEC 27035-1:2023 i ISO/IEC 27035-2:2023 łączą rejestrowanie z wykrywaniem incydentów, wstępną kwalifikacją i scentralizowaną analizą. ISO/IEC 27701:2021 dodaje specyficzne dla prywatności rejestrowanie czynności przetwarzania PII. ISO/IEC 27017:2021 i ISO/IEC 27018:2020 dodają oczekiwania dotyczące rejestrowania w chmurze i rejestrowania PII w chmurze, zwłaszcza gdy dostawcy przetwarzają dane klientów w publicznych środowiskach chmurowych. ISO/IEC 27005:2024 ujmuje niewystarczające rejestrowanie jako problem postępowania z ryzykiem, a nie tylko lukę narzędziową.

Reagowanie na incydenty: MDR może eskalować, ale kierownictwo musi decydować

Dostawcy MDR wykrywają i doradzają. Rozliczalna organizacja ogłasza incydenty, ocenia wpływ regulacyjny, komunikuje się z organami i decyduje, czy wymagane jest zgłoszenie naruszenia ochrony danych osobowych.

To rozróżnienie ma znaczenie, ponieważ krytyczność MDR nie oznacza automatycznie znaczącego incydentu NIS2, poważnego incydentu związanego z ICT w DORA ani naruszenia ochrony danych osobowych w GDPR. Dostawca może oznaczyć alert jako „wysoka krytyczność”, ale to organizacja musi zdecydować, czy usługi krytyczne zostały dotknięte, czy dane osobowe zostały naruszone, czy należy powiadomić klientów, czy trzeba poinformować organy regulacyjne oraz czy kierownictwo musi zatwierdzić działanie powstrzymujące mające wpływ operacyjny.

Incident Response Policy - SME Clarysec Incident Response Policy - SME jest bezpośrednia:

„Strony trzecie muszą działać zgodnie z podpisanymi umowami, które muszą obejmować klauzule powiadamiania o naruszeniu ochrony danych osobowych oraz obowiązki współpracy przy reagowaniu.”

Ta klauzula jest miejscem, w którym dowody GDPR Article 32 spotykają się z operacyjnym reagowaniem na incydenty. Jeżeli dostawca MDR zaobserwuje podejrzenie eksfiltracji danych z punktu końcowego zawierającego dane osobowe, musi wiedzieć, jak szybko powiadomić, kogo powiadomić, jaki materiał dowodowy zabezpieczyć i jak wesprzeć ocenę administratora.

Zenith Blueprint: An Auditor’s 30-Step Roadmap Clarysec Zenith Blueprint podaje metodę testowania. W fazie „Kontrole w praktyce”, w kroku 19, Zenith Blueprint instruuje zespoły, aby operacyjnie zweryfikowały rejestrowanie i monitorowanie:

„Wybierz ostatni incydent lub zdarzenie i pokaż, jak prześledzono je przy użyciu logów. Jeżeli stosowane są funkcje integralności logów (np. weryfikacja skrótu), również to udokumentuj. Potwierdź, że alertowanie działa (np. nieudane logowania lub eskalacje uprawnień wyzwalają alerty).”

Ten sam krok dotyczy tożsamości i dostępu uprzywilejowanego:

„W przypadku kont uprzywilejowanych zweryfikuj, że MFA jest wymuszane, role administratorów są odseparowane (konta w stylu admin_john używane wyłącznie do zadań administracyjnych), a aktualna lista użytkowników uprzywilejowanych istnieje.”

W kontekście MDR lista użytkowników uprzywilejowanych musi obejmować konta dostawcy, nie tylko pracowników. Jeżeli dostawca MDR ma dostęp do konsoli, uprawnienia izolowania punktów końcowych, uprawnienia administracyjne EDR lub dostęp tylko do odczytu do wrażliwych logów, konta te należą do zakresu przeglądu.

Krok 23 Zenith Blueprint podaje następnie strukturę testu incydentowego i dostawcy:

„Wybierz ostatnie zdarzenie albo przeprowadź ćwiczenie sztabowe, aby zweryfikować swój plan. Zarejestruj wszystkie decyzje, role i komunikację (5.26) oraz zaktualizuj plan o wnioski z doświadczeń (5.27). Potwierdź, że istnieją procedury zabezpieczania dowodów kryminalistycznych (5.28), w tym migawki logów, kopie zapasowe i bezpieczna izolacja dotkniętych systemów.”

Realistyczne ćwiczenie sztabowe powinno obejmować dostawcę MDR. Użyj scenariusza takiego jak naruszone konto uprzywilejowane, izolacja punktu końcowego, podejrzenie dostępu do skrzynki pocztowej, możliwe ujawnienie danych płacowych i eskalacja alertu poza godzinami pracy. Test powinien zweryfikować, czy zegar dostawcy MDR startuje w momencie wykrycia, powiadomienia klienta czy potwierdzenia odbioru przez klienta. To rozróżnienie ma znaczenie, gdy terminy regulacyjne zależą od świadomości i punktów decyzyjnych.

Zbuduj pakiet nadzoru MDR dla jednego alertu w 90 minut

Szybkim sposobem ujawnienia luk jest wybranie jednego niedawnego alertu MDR o wysokiej krytyczności i zbudowanie jednostronicowej ścieżki dowodowej. To praktyczne ćwiczenie dobrze sprawdza się przed audytami, przeglądami zarządu i odnowieniami umów.

1. Zacznij od zgłoszenia alertu. Zarejestruj znacznik czasu, regułę wykrywania, dotknięty aktyw, użytkownika, krytyczność, notatki analityka MDR i ścieżkę eskalacji.
2. Pobierz klauzulę umowną lub SLA pokazujące oczekiwany czas reakcji dla tej krytyczności.
3. Pobierz wykaz źródeł logów dowodzący, które systemy zasiliły alert, takie jak EDR, dostawca tożsamości, zapora sieciowa, brama bezpieczeństwa poczty elektronicznej i logi audytowe chmury.
4. Potwierdź, że logi są przechowywane zgodnie z polityką i że historyczne zdarzenie nadal można pobrać.
5. Zweryfikuj, czy analityk MDR uzyskał dostęp do jakiegokolwiek środowiska klienta. Jeśli tak, zarejestruj imienne konto, dowody MFA, logi sesji i zatwierdzenie.
6. Udokumentuj decyzję po stronie klienta: zdarzenie zamknięte, incydent ogłoszony, uruchomiona ocena prawna, wykonane powstrzymanie lub zaakceptowane ryzyko.
7. Jeżeli mogą być zaangażowane dane osobowe, zapisz analizę ról GDPR, właściciela oceny naruszenia oraz to, czy uruchomiono obowiązki powiadamiania przez podmiot przetwarzający.
8. Zamknij wnioskami z doświadczeń: dostrajanie, nowe wykrywanie, zmiana dostępu, aktualizacja podręcznika postępowania lub problem SLA dostawcy.

Ta ścieżka jednego alertu jest silna, ponieważ łączy umowę, rejestrowanie, dostęp, reagowanie na incydenty, prywatność i nadzór kierownictwa w jeden łańcuch dowodowy. Jeżeli nie możesz jej zbudować dla niedawnego alertu, prawdopodobnie nie zbudujesz jej pod presją regulacyjną.

Monitorowanie dostawcy to miejsce, w którym większość programów MDR słabnie

Wiele organizacji przeprowadza due diligence przed podpisaniem umowy MDR, a potem na tym poprzestaje. To nie wystarcza dla ISO/IEC 27001:2022, NIS2, DORA ani GDPR. Usługi MDR zmieniają się nieustannie: nowe reguły wykrywania, nowe zespoły analityków, nowe dalsze podmioty przetwarzające, nowe regiony danych, nowe możliwości EDR, nowe integracje, nowe strumienie informacji o zagrożeniach i nowe modele wsparcia.

Środek kontrolny ISO/IEC 27002:2022 5.22 dotyczy monitorowania, przeglądu i zarządzania zmianami usług dostawców. Zenith Controls wyjaśnia, że 5.22 opiera się na kontrolach relacji i umów z dostawcami, zapewniając ciągłe monitorowanie i zarządzanie po uruchomieniu usługi. Łączy się z bezpieczeństwem podczas zakłóceń, zarządzaniem podatnościami, zgodnością, kontrolą dostępu i bezpieczną inżynierią.

DORA Articles 28 to 30 czynią to szczególnie ważnym dla podmiotów finansowych. Wymagają bieżącego monitorowania, rejestrów uzgodnień z podmiotami trzecimi ICT, rozróżnienia krytyczności, due diligence, praw do audytu i inspekcji, praw wypowiedzenia, strategii wyjścia, poziomów usług, wsparcia incydentowego, współpracy z organami oraz — dla funkcji krytycznych lub ważnych — celów usługowych, testowania awaryjnego i współpracy przy testach penetracyjnych prowadzonych w oparciu o zagrożenia tam, gdzie ma to zastosowanie.

Zenith Blueprint, faza „Kontrole w praktyce”, krok 23, zapewnia strukturę cyklu życia dostawcy:

„Skompiluj pełną listę obecnych dostawców i usługodawców (5.19) oraz sklasyfikuj ich na podstawie dostępu do systemów, danych lub kontroli operacyjnej.”

Następnie:

„Dla każdego krytycznego dostawcy ustal, czy korzysta z podwykonawców (dalszych podmiotów przetwarzających), którzy mogą uzyskiwać dostęp do Twoich danych lub systemów.”

Praktyczny przegląd usługi MDR powinien odbywać się kwartalnie dla środowisk krytycznych oraz co najmniej raz w roku dla środowisk niższego ryzyka. Agenda powinna obejmować zgodność z SLA według krytyczności, eskalowane alerty, prawdziwe alarmy, fałszywe alarmy, pominięte eskalacje, stan źródeł logów, zmiany dostępu uprzywilejowanego, nowe integracje, nowe regiony, podwykonawców, dalsze podmioty przetwarzające, zmiany reguł wykrywania, skuteczność wsparcia incydentowego, żądania materiału dowodowego, otwarte ryzyka, działania korygujące i gotowość wyjścia.

To nie jest mikrozarządzanie. To pętla zapewnienia, która dowodzi, że organizacja aktywnie nadzoruje krytycznego dostawcę bezpieczeństwa.

Mapowanie zgodności wieloreżimowej: jeden zestaw kontroli MDR, pięć rozmów audytowych

Wartość ISO/IEC 27001:2022 polega na tym, że daje organizacjom jeden spójny cykl SZBI dla wielu rozmów o zgodności. Ten sam pakiet dowodowy nadzoru MDR można mapować na NIS2, DORA, GDPR, NIST CSF 2.0 i COBIT 2019.

NIST CSF 2.0 jest przydatny do komunikacji. Jego funkcja GOVERN wymaga, aby obowiązki prawne, regulacyjne, umowne i dotyczące prywatności były rozumiane i zarządzane, role i uprawnienia zdefiniowane, ryzyko cyberbezpieczeństwa zintegrowane z zarządzaniem ryzykiem przedsiębiorstwa, a ryzyka dostawców komunikowane i monitorowane.

COBIT 2019 jest przydatny dla zarządzania i zapewnienia. Audytorzy pracujący w podejściu COBIT często koncentrują się mniej na pojedynczej kontroli, a bardziej na tym, czy cele ładu zarządczego, zarządzanie usługami, własność ryzyka i monitorowanie wyników działają jako system.

Jak audytorzy będą testować nadzór nad dostawcą MDR

Różni audytorzy stosują różne perspektywy, ale wszyscy oczekują dowodów, że organizacja kontroluje relację.

Audytor ISO/IEC 27001:2022 zacznie od zakresu, stron zainteresowanych, oceny ryzyka, Deklaracji stosowania, planu postępowania z ryzykiem i dowodów operacyjnych. Jeżeli MDR jest w zakresie, audytor będzie oczekiwał, że procesy dostarczane z zewnątrz są kontrolowane w ramach SZBI. Może próbkująco sprawdzić relacje z dostawcami, umowy z dostawcami, monitorowanie usług dostawców, rejestrowanie, monitorowanie, reagowanie na incydenty, postępowanie z materiałem dowodowym i kontrolę dostępu.

Organ nadzorczy DORA skupi się na odporności operacyjnej i ryzyku systemowym. Może szczegółowo analizować ocenę krytyczności, rejestr usług ICT, analizę ryzyka koncentracji, strategię wyjścia, klasyfikację incydentów, prawa do audytu oraz dowody, że dostawca MDR może wspierać raportowanie regulacyjne.

Audytor GDPR lub osoba dokonująca przeglądu prywatności skupi się na nadzorze administrator–podmiot przetwarzający. Poprosi o DPA, due diligence podmiotu przetwarzającego, kontrole dalszych podmiotów przetwarzających, zabezpieczenia dla logów zawierających dane osobowe, kontrole retencji, zapisy oceny naruszenia i dowody wspierające Article 32.

Audytor COBIT lub ISACA sprawdzi dowody ładu zarządczego: własność ryzyka dostawcy, przepływ zakupowy, protokoły przeglądów usług, śledzenie problemów SLA, działania korygujące, jakość dowodów oraz to, czy kierownictwo otrzymuje znaczące metryki.

Najbardziej ujawniające żądanie audytowe jest proste: „Pokażcie jeden alert MDR od wykrycia do zamknięcia”. Jeżeli możesz pokazać oczekiwanie umowne, źródło logów, alert, eskalację, decyzję, zabezpieczenie materiału dowodowego, ocenę prywatności, działania naprawcze i raportowanie dla kierownictwa, nadzór nad MDR jest dojrzały. Jeżeli możesz pokazać tylko zgłoszenie dostawcy, masz monitorowanie, ale słaby ład zarządczy.

Raportowanie dla kierownictwa: zarząd nie potrzebuje przechwyconych pakietów

NIS2 i DORA nakładają odpowiedzialność na poziomie organu zarządzającego. Zarządy i kadra kierownicza nie potrzebują nieprzetworzonej telemetrii. Potrzebują metryk nadzoru MDR istotnych z perspektywy ryzyka.

Przydatny kwartalny pulpit MDR obejmuje:

• Krytyczne źródła logów wdrożone względem oczekiwanych.
• Procent aktywów krytycznych objętych MDR.
• Alerty o wysokiej krytyczności według kategorii i usługi biznesowej.
• Średni czas od wykrycia do powiadomienia klienta.
• Średni czas od potwierdzenia przez klienta do decyzji.
• Naruszenia SLA i nierozwiązane działania dostawcy.
• Status przeglądu kont uprzywilejowanych dostawcy.
• Zmiany podwykonawców lub dalszych podmiotów przetwarzających.
• Incydenty wymagające oceny powiadomienia prawnego, regulacyjnego lub klienta.
• Wdrożone wnioski z doświadczeń.

Ten pulpit powinien zasilać przegląd zarządzania SZBI, aktualizacje planów postępowania z ryzykiem i przegląd dostawcy. Zgodnie z ISO/IEC 27001:2022 najwyższe kierownictwo musi zapewnić, że SZBI jest zgodny z kierunkiem strategicznym, zasoby są dostępne, odpowiedzialności są przypisane, komunikacja działa i następuje ciągłe doskonalenie. Metryki MDR są praktycznym sposobem wykazania, że outsourcingowe operacje bezpieczeństwa są zarządzane przez kierownictwo, a nie pozostawione administratorom narzędzi.

Typowe pułapki nadzoru MDR do usunięcia przed audytami w 2026 r.

Najczęstsze luki to zwykłe niepowodzenia ładu zarządczego.

Po pierwsze, organizacje zapominają, że dostawcy MDR mogą przetwarzać dane osobowe. Logi bezpieczeństwa są czasem traktowane jako „dane techniczne”, ale mogą zawierać dane osobowe, a niekiedy treści wrażliwe. Analiza ról GDPR i klauzule dla podmiotu przetwarzającego powinny być zakończone przed wdrożeniem usługi, a nie podczas naruszenia.

Po drugie, retencja logów jest zakładana, a nie kontraktowana. Jeżeli obowiązki regulacyjne, kryminalistyczne lub klienckie wymagają materiału dowodowego przez miesiące, model retencji MDR i SIEM musi to wspierać. Wymóg polityki dla MŚP dotyczący 12-miesięcznego przechowywania logów przez dostawcę jest praktyczną bazą dla wielu środowisk.

Po trzecie, dostęp stron trzecich jest nadmiernie liberalny. Konta dostawców powinny być imienne, chronione MFA, monitorowane, przeglądane i ograniczone czasowo tam, gdzie to wykonalne. Konta współdzielone i niezarządzane sesje administracyjne tworzą ryzyko audytowe i incydentowe.

Po czwarte, progi incydentowe są niejednoznaczne. Krytyczność MDR nie oznacza automatycznie incydentu prawnego, poważnego incydentu związanego z ICT w DORA, znaczącego incydentu NIS2 ani naruszenia ochrony danych osobowych w GDPR. Podręcznik postępowania musi definiować, kto podejmuje każdą decyzję.

Po piąte, podwykonawcy są niewidoczni. Jeżeli dostawca MDR zmienia platformy analityczne, regiony wsparcia lub dalsze podmioty przetwarzające, zmienia się obraz ryzyka klienta. Uprzednia pisemna zgoda i okresowy przegląd są niezbędne.

Po szóste, przeglądy usług koncentrują się wyłącznie na liczbie zgłoszeń. Dojrzałe przeglądy analizują pominięte alerty, zmiany dostrajania, stan źródeł logów, pozyskiwanie materiału dowodowego, dostęp dostawcy, współpracę przy incydentach i obowiązki umowne.

Następne kroki: przygotuj dostawcę MDR do audytu z Clarysec

Jeżeli Twój dostawca MDR już działa produkcyjnie, nie czekaj, aż organ regulacyjny, audytor klienta lub incydent ujawni niekompletność dowodów. Zacznij od jednego niedawnego alertu i zbuduj ścieżkę. Następnie sklasyfikuj dostawcę, przejrzyj umowę, zweryfikuj rejestrowanie, przetestuj eskalację, potwierdź klauzule dla podmiotu przetwarzającego, przejrzyj dostęp i zaplanuj monitorowanie dostawcy.

Clarysec może pomóc szybko wdrożyć to operacyjnie z wykorzystaniem:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint do etapowego wdrożenia, w tym kroku 19 dla walidacji rejestrowania, monitorowania i dostępu oraz kroku 23 dla kontroli zarządzania dostawcami i incydentami.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls do mapowania środków kontrolnych ISO/IEC 27002:2022 5.19, 5.22 i 8.15 na oczekiwania audytowe NIS2, DORA, GDPR, NIST i COBIT.
• Szablonów polityk Clarysec, w tym Incident Response Policy, Third party and supplier security policy, Logging and Monitoring Policy, Incident Response Policy - SME, Third-Party and Supplier Security Policy - SME, Logging and Monitoring Policy - SME oraz Data Protection and Privacy Policy - SME.

MDR jest jedną z najbardziej wartościowych inwestycji w bezpieczeństwo, jakie organizacja może podjąć. W 2026 r. tę wartość trzeba wykazać przez ład zarządczy, dowody i rozliczalny nadzór. Jeżeli potrzebujesz praktycznego pakietu nadzoru MDR mapowanego na ISO/IEC 27001:2022, NIS2, DORA i GDPR Article 32, Clarysec może pomóc zbudować go, zanim kolejny alert stanie się kolejnym ustaleniem z audytu.