Dohled nad poskytovatelem MDR pro NIS2, DORA a GDPR

V pondělí ve 02:13 ráno poskytovatel MDR otevírá upozornění s vysokou závažností: nemožné cestování, podezřelá pravidla poštovních schránek a privilegovaný účet použitý z nespravovaného koncového bodu. Analytik SOC eskaluje případ prostřednictvím systému pro správu tiketů. Váš IT manažer spí. Finanční ředitel obdrží phishingové varování od kontaktu v bance dříve, než se probudí interní incidentní kanál. V 07:30 stojí CISO před třemi nepříjemnými otázkami.

Kdo měl pravomoc vyhlásit incident?

Dokážeme doložit, že poskytovatel MDR měl správné logy, uchovával je dostatečně dlouho a zajistil uchování důkazů?

Pokud došlo k přístupu k osobním údajům, stihne právní oddělení lhůty pro posouzení porušení zabezpečení osobních údajů podle GDPR, zatímco provoz připravuje hlášení podle NIS2 nebo DORA?

O měsíc později si externí auditor vyžádá stejné důkazy, jen jiným tónem. PDF zpráva poskytovatele MDR je užitečná, ale nestačí. Auditor chce surová data upozornění, úplné soubory logů, eskalační stopu, interní záznam rozhodnutí, záznam o přezkumu dodavatele a důkaz, že organizace mohla nezávisle ověřit, co se stalo.

To je problém dohledu nad poskytovatelem MDR v roce 2026. Organizace outsourcují detekci a reakci, protože interní kapacita SOC je nákladná, nábor je obtížný a aktivita hrozeb neustává. Outsourcovaná detekce však neznamená outsourcovanou odpovědnost. Podle NIS2 zůstávají řídicí orgány odpovědné za schvalování opatření k řízení kyberbezpečnostních rizik a dohled nad nimi. Podle DORA zůstávají finanční subjekty plně odpovědné za rizika ICT třetích stran, včetně kritických ICT služeb, podpory při incidentech, práv na audit, subdodavatelství a ukončení. Podle GDPR musí správci prokázat odpovídající zabezpečení zpracování, zejména pokud zpracovatelé nakládají s telemetrií, daty koncových bodů, identifikátory uživatelů, IP adresami, obsahem e-mailů, logy nebo forenzními obrazy.

Praktická mezera obvykle nespočívá pouze ve smlouvě s poskytovatelem MDR. Je v řetězci důkazů mezi smlouvou a živou službou: směrování upozornění, privilegovaný přístup, uchovávání logů, prahové hodnoty pro eskalaci, důkazy k incidentům, transparentnost subdodavatelů, doložky pro zpracovatele, přezkumy služeb, stolní cvičení a reportování vedení.

Obhajitelný program dohledu nad poskytovatelem MDR potřebuje jeden provozní model, který obstojí v několika auditních konverzacích. ISO/IEC 27001:2022 poskytuje tuto páteř.

Dohled nad MDR začíná odpovědností, ne konzolí SOC

Častou chybou je chápat onboarding MDR jako technický projekt: nasadit agenty EDR, předávat logy identit, nakonfigurovat upozornění, dohodnout kanál v Teams nebo Slacku a spustit službu do produkce. To může zlepšit detekci, ale nedokládá to správu a řízení.

NIS2 tento problém výslovně pojmenovává. Základní a důležité subjekty musí zavést přiměřená a odpovídající technická, provozní a organizační opatření k řízení kyberbezpečnostních rizik. Article 21 zahrnuje analýzu rizik, zvládání incidentů, kontinuitu činností, zabezpečení dodavatelského řetězce, kybernetickou hygienu, řízení přístupu, správu aktiv, kryptografii a vícefaktorovou autentizaci. Article 20 posouvá tuto povinnost na úroveň odpovědnosti řídicího orgánu a vyžaduje schvalování těchto opatření a dohled nad nimi.

Poskytovatelé MDR často zasahují současně do několika oblastí NIS2 Article 21:

• Zvládání incidentů, protože poskytovatel provádí triáž, eskalaci a může doporučovat zamezení šíření.
• Zabezpečení dodavatelského řetězce, protože poskytovatel je přímým poskytovatelem služby s dopadem na provozní bezpečnost.
• Řízení přístupu, protože poskytovatel může přistupovat ke konzolím, logům, nástrojům koncových bodů nebo cloudovým tenantům.
• Protokolování a monitorování, protože detekce závisí na pokrytí logováním, uchovávání a korelaci.
• Kybernetická hygiena, protože zjištění MDR často odhalují slabiny v záplatování, identitách nebo konfiguraci.
• Kontinuita činností, protože opožděná reakce může narušit kritické služby.

U finančních subjektů DORA provozní model dále zpřísňuje. DORA se použije od 17. ledna 2025 a vyžaduje řízení rizik v oblasti ICT, hlášení incidentů, testování odolnosti, sdílení informací a řízení rizik ICT třetích stran. Zároveň upřesňuje, že u finančních subjektů, které jsou rovněž identifikovány podle NIS2, působí DORA jako odvětvový právní akt Unie pro překrývající se kyberbezpečnostní povinnosti. Regulovaná banka, platební instituce, investiční podnik, pojišťovna nebo poskytovatel služeb souvisejících s kryptoaktivy nemůže jednoduše říci: „To řeší náš poskytovatel MDR.“ DORA očekává, že subjekt bude klasifikovat ICT incidenty, řídit a monitorovat poskytovatele ICT třetích stran, udržovat registry ujednání o ICT službách, definovat smluvní práva, testovat odolnost, provádět analýzu kořenové příčiny a hlásit významné incidenty související s ICT ve fázích.

GDPR přidává jiný pohled. Pokud telemetrie MDR zahrnuje identifikátory uživatelů, IP adresy, metadata e-mailů, autentizační záznamy, artefakty koncových bodů nebo soubory obsahující osobní údaje, uplatní se bezpečnostní zásady a zásady odpovědnosti podle GDPR. Article 5 zahrnuje integritu, důvěrnost a odpovědnost. Article 32 týkající se zabezpečení zpracování se mění v praktickou otázku důkazů: byly logy chráněny, byl přístup omezen, bylo použito šifrování tam, kde to bylo vhodné, byli zpracovatelé řízeni a může organizace doložit, co se stalo?

Sdělení je ve všech třech režimech shodné: práci můžete delegovat, odpovědnost nikoli.

ISO/IEC 27001:2022 mění MDR v auditovatelný proces

Dobře zavedený ISMS založený na ISO/IEC 27001:2022 mění dohled nad poskytovatelem MDR ze slibu v rámci řízení dodavatelů na provozní model založený na důkazech. Zvlášť důležitá je kapitola 8.1, protože vyžaduje, aby organizace řídily externě poskytované procesy, produkty a služby relevantní pro ISMS. MDR je přesně takový případ: externě poskytovaný proces, který může ovlivnit reakci na incidenty, soukromí, odolnost, regulační hlášení a kontinuitu činností.

Mezi nejdůležitější oblasti přílohy A ISO/IEC 27001:2022 pro dohled nad MDR patří vztahy s dodavateli, bezpečnostní požadavky ve smlouvách s dodavateli, řízení rizik v dodavatelském řetězci ICT, monitorování služeb dodavatelů, řízení incidentů, nakládání s důkazy, protokolování, monitorování, řízení přístupu, privilegovaný přístup, kryptografie a připravenost kontinuity činností.

Clarysec Zenith Controls: The Cross-Compliance Guide Zenith Controls je referencí pro tuto práci napříč požadavky souladu. Mapuje opatření ISO/IEC 27002:2022 na další požadavky, související opatření, auditní očekávání a implementační důkazy. Pro dohled nad MDR jsou klíčová tři opatření ISO/IEC 27002:2022: 5.19 pro vztahy s dodavateli, 5.22 pro monitorování služeb dodavatelů a řízení změn a 8.15 pro protokolování. Podporují je 5.20 smlouvy s dodavateli, 5.21 zabezpečení dodavatelského řetězce ICT, 5.24 až 5.28 řízení incidentů a nakládání s důkazy, 5.34 ochrana soukromí a osobně identifikovatelné údaje (PII), 5.36 soulad, 8.16 monitorovací činnosti, 8.17 synchronizace času, 8.18 používání privilegovaných obslužných programů a 8.8 řízení technických zranitelností.

Je to důležité, protože selhání auditu MDR málokdy zní „žádné MDR“. Obvykle zní některým z těchto způsobů:

• Poskytovatel MDR nebyl klasifikován jako kritický.
• Smluvní doložky neobsahovaly oznamování incidentů, přístup k důkazům nebo práva na audit.
• Logy nebyly uchovávány dostatečně dlouho pro vyšetření hlášené události.
• Přístup poskytovatele byl sdílený, trvalý nebo nemonitorovaný.
• Zákazník nepřezkoumával výkonnost MDR vůči SLA.
• Subdodavatelé nebo dílčí zpracovatelé nebyli schváleni.
• Povinnosti oznamování porušení zabezpečení osobních údajů nebyly sladěny s pracovními postupy pro incidenty.
• Důkazy nebyly uchovány způsobem použitelným pro forenzní šetření.
• Vedení nemělo metriky ukazující, zda služba MDR snížila riziko.

Zenith Controls jasně popisuje vztah mezi očekáváními vůči dodavatelům a smlouvami:

„5.19 stanovuje bezpečnostní očekávání, jak mají dodavatelé nakládat s informacemi organizace. 5.20 tato očekávání formalizuje tím, že zajišťuje, aby smlouvy nebo dohody výslovně obsahovaly bezpečnostní doložky, například požadavky na důvěrnost, soulad s bezpečnostními politikami a postupy oznamování incidentů. Bez 5.20 nemusí být požadavky identifikované v 5.19 právně vymahatelné.“

Pro MDR je tato věta lekcí ze správy a řízení. Pokud smlouva nevyžaduje, aby poskytovatel uchovával logy, poskytoval důkazy, spolupracoval při incidentech, omezoval subdodavatelství, podporoval audity a dodržoval eskalační lhůty, může být služba SOC provozně užitečná, ale auditně slabá.

Co musí smlouva s MDR prokázat před prvním upozorněním

Dobrá smlouva s poskytovatelem MDR není jen obchodní objednávka. Je to kontrolní dokument. DORA Articles 28 to 30 vyžadují, aby bylo riziko ICT třetích stran řízeno v celém životním cyklu, včetně registrů smluv o ICT službách, klasifikace kritičnosti, náležité péče před uzavřením smlouvy, přístupů k auditu a inspekci, práv na ukončení, exit strategií, jasných popisů služeb, úrovní služeb, míst poskytování služby a zpracování dat, závazků ochrany dat, asistence při incidentech a spolupráce s orgány. NIS2 Article 21 vyžaduje zabezpečení dodavatelského řetězce pro přímé dodavatele a poskytovatele služeb. GDPR vyžaduje role správce a zpracovatele, záruky zpracovatele, doložky o ochraně údajů a důkazy o zabezpečení zpracování.

Knihovna politik Clarysec převádí tyto povinnosti do praktických smluvních a provozních požadavků. V Podnikové politice reakce na incidenty Politika reakce na incidenty je MDR výslovně chápáno jako řízená schopnost reakce na incidenty poskytovaná třetí stranou:

„Integrace se službami třetích stran, včetně Managed Detection and Response (MDR), Security Incident and Event Management (SIEM) a poskytovatelů forenzní analýzy, musí být řízena jasně definovanými dohodami o úrovni služeb (SLA) a ustanoveními o mlčenlivosti.“

Tato doložka je důležitá, protože poskytovatelé MDR často obdrží vysoce citlivé informace dříve, než organizace ví, zda je incident oznamovatelný. Telemetrie může zahrnovat uživatelská jména, cesty k souborům, předměty e-mailů, interní názvy hostitelů, IP adresy, síťové diagramy a indikátory kompromitace. Ustanovení o mlčenlivosti chrání organizaci během vyšetřování a podporují odpovědnost podle GDPR.

Podniková bezpečnostní politika třetích stran a dodavatelů Bezpečnostní politika třetích stran a dodavatelů doplňuje dvě doložky, které auditoři při přezkumu dohledu nad MDR očekávají:

„Práva na audit, inspekci a vyžádání bezpečnostních důkazů“

a:

„Využití subdodavatelů podléhající předchozímu písemnému souhlasu“

U malých a středních podniků se stejný princip správy a řízení škáluje, nikoli ruší. Bezpečnostní politika třetích stran a dodavatelů – SME Bezpečnostní politika třetích stran a dodavatelů – SME vyžaduje zásadu minimálních oprávnění:

„Dodavatelům musí být udělen přístup pouze k minimálním systémům a datům nezbytným k plnění jejich funkce.“

Zároveň vyžaduje:

„Omezení dalšího subdodavatelství bez schválení“

Tyto doložky jsou pro MDR zvlášť relevantní. Mnozí poskytovatelé používají víceúrovňové týmy SOC, dodavatele platforem, partnery pro informace o hrozbách, cloudové analytické služby nebo regionální pracovníky podpory. Pokud mohou navazující strany přistupovat k zákaznickým logům nebo osobním údajům, zákazník potřebuje mechanismy viditelnosti a schvalování. V terminologii DORA jde o součást dohledu nad subdodavatelstvím a rizikem koncentrace. V terminologii GDPR jde o řízení dílčích zpracovatelů. V terminologii NIS2 jde o řízení rizik dodavatelského řetězce.

Základní kontrolní seznam dohledu nad MDR

Obhajitelný vztah s poskytovatelem MDR musí být testovatelný. Následující kontrolní seznam spojuje smluvní, provozní a důkazní požadavky do jednoho pohledu na opatření.

Tento kontrolní seznam má být začleněn do pořizování, onboardingu, pravidelného přezkumu a testování incidentů. Pokud některá položka chybí, organizace ji má považovat za dodavatelské riziko, nikoli za administrativní nedostatek.

Sedm důkazních domén, které auditoři očekávají

Aby byl dohled nad MDR připravený na audit, Clarysec doporučuje vytvořit důkazní složku MDR uspořádanou do sedmi domén. Tato složka má být součástí ISMS, nikoli nákupní složky, kterou nikdo nepřezkoumává.

Tato tabulka mění konverzaci s poskytovatelem. Místo otázky „Monitorujete nás?“ se organizace ptá: „Dokážeme každé čtvrtletí prokázat, že služba MDR zůstává účinná, v souladu a sladěná s naší ochotou podstupovat riziko?“

Protokolování je mostem mezi detekcí a důkazy o souladu

MDR bez spolehlivého protokolování je outsourcovaný odhad. Poskytovatel může některé hrozby detekovat, ale organizace nedokáže prokázat rozsah, časovou osu, kořenovou příčinu ani dopad.

Opatření ISO/IEC 27002:2022 8.15 se týká protokolování. Zenith Controls klasifikuje protokolování jako detekční opatření podporující důvěrnost, integritu a dostupnost, sladěné s kyberbezpečnostním konceptem Detect a schopností řízení událostí informační bezpečnosti. Propojuje protokolování přímo s monitorovacími činnostmi, hodnocením událostí, reakcí na incidenty, získanými poznatky, privilegovaným přístupem, synchronizací času, řízením přístupu, ochranou soukromí, sběrem důkazů, řízením zranitelností a monitorováním fyzické bezpečnosti.

Proto je protokolování klíčové pro důkazy k NIS2, DORA a GDPR Article 32. Hlášení významných incidentů podle NIS2 Article 23 vyžaduje včasné varování do 24 hodin od zjištění, oznámení do 72 hodin a závěrečnou zprávu nejpozději jeden měsíc po oznámení. Hlášení významných incidentů souvisejících s ICT podle DORA vyžaduje klasifikaci, eskalaci, komunikaci, analýzu kořenové příčiny a závěrečné hlášení. Odpovědnost podle GDPR vyžaduje, aby organizace prokázaly, co se stalo s osobními údaji a zda byla bezpečnostní opatření přiměřená.

Clarysec Politika protokolování a monitorování – SME Politika protokolování a monitorování – SME poskytuje jednoduché smluvní opatření pro menší organizace využívající externí poskytovatele:

„Smlouvy musí vyžadovat, aby poskytovatelé uchovávali logy alespoň 12 měsíců a poskytli k nim přístup na vyžádání.“

Pro podniková prostředí přidává Politika protokolování a monitorování Politika protokolování a monitorování požadavek na provozní integraci:

„Musí poskytovat data logů na vyžádání nebo se integrovat s platformou SIEM/agregace logů organizace.“

Tyto doložky řeší opakovaný problém reakce na incidenty: během vyšetřování poskytovatel MDR uvede, že událost je starší než prohledatelné retenční okno, logy jsou dostupné pouze prostřednictvím placeného forenzního exportu nebo zákaznický SIEM neobsahuje obohacení poskytovatele a kroky analytika. Pokud není přístup k logům definován předem, časová osa incidentu se rozpadá.

Silný model protokolování MDR musí definovat povinné zdroje logů, typy událostí, doby uchovávání, ochranu integrity, schvalování přístupů, synchronizaci času, exportní formáty a korelační pravidla mezi platformami zákazníka a poskytovatele. Musí zahrnovat také kroky poskytovatele, včetně změn detekčních pravidel, příkazů k izolaci koncových bodů, administrátorského přístupu, poznámek analytiků a exportů důkazů.

Podpůrné normy ISO tento přístup posilují. ISO/IEC 27035-1:2023 a ISO/IEC 27035-2:2023 propojují protokolování s detekcí incidentů, triáží a centralizovanou analýzou. ISO/IEC 27701:2021 doplňuje protokolování činností zpracování osobně identifikovatelných údajů specifické pro soukromí. ISO/IEC 27017:2021 a ISO/IEC 27018:2020 doplňují očekávání pro cloudové protokolování a protokolování PII v cloudu, zejména tam, kde poskytovatelé zpracovávají zákaznická data ve veřejných cloudových prostředích. ISO/IEC 27005:2024 rámuje nedostatečné protokolování jako otázku ošetření rizik, nikoli jen jako mezeru v nástrojích.

Reakce na incidenty: MDR může eskalovat, ale rozhodovat musí vedení

Poskytovatelé MDR detekují a radí. Odpovědná organizace vyhlašuje incidenty, posuzuje regulační dopad, komunikuje s orgány a rozhoduje, zda je vyžadováno oznámení porušení zabezpečení osobních údajů.

Toto rozlišení je důležité, protože závažnost MDR se automaticky nerovná významnému incidentu podle NIS2, významnému incidentu souvisejícímu s ICT podle DORA ani porušení zabezpečení osobních údajů podle GDPR. Poskytovatel může označit upozornění jako „vysoká závažnost“, ale organizace musí rozhodnout, zda byly dotčeny kritické služby, zda byly kompromitovány osobní údaje, zda musí být informováni zákazníci, zda musí být informovány regulační orgány a zda vedení musí schválit opatření zamezení šíření s provozním dopadem.

Clarysec Politika reakce na incidenty – SME Politika reakce na incidenty – SME je přímočará:

„Třetí strany musí jednat v souladu s podepsanými smlouvami, které musí obsahovat doložky o oznamování porušení zabezpečení osobních údajů a povinnosti součinnosti při reakci.“

Tato doložka je místem, kde se důkazy k GDPR Article 32 setkávají s provozní reakcí na incidenty. Pokud poskytovatel MDR zaznamená podezření na exfiltraci dat z koncového bodu obsahujícího osobní údaje, musí vědět, jak rychle informovat, koho informovat, jaké důkazy uchovat a jak podpořit posouzení správce.

Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint poskytuje testovací metodu. Ve fázi Controls in Action, Step 19, Zenith Blueprint ukládá týmům provozně ověřit protokolování a monitorování:

„Vyberte nedávný incident nebo událost a předveďte, jak jste je trasovali pomocí svých logů. Pokud se používají funkce integrity logů (např. ověření hash hodnoty), zdokumentujte i to. Potvrďte, že upozorňování funguje (např. neúspěšná přihlášení nebo eskalace oprávnění spouštějí upozornění).“

Stejný krok se věnuje identitě a privilegovanému přístupu:

„U privilegovaných účtů ověřte, že je vynucena MFA, administrátorské role jsou oddělené (účty ve stylu admin_john používané pouze pro administrátorské úkoly) a existuje aktuální seznam privilegovaných uživatelů.“

V kontextu MDR musí seznam privilegovaných uživatelů zahrnovat účty poskytovatele, nejen zaměstnance. Pokud má poskytovatel MDR přístup ke konzoli, práva izolovat koncové body, práva správy EDR nebo čtecí přístup k citlivým logům, tyto účty patří do přezkumu.

Step 23 dokumentu Zenith Blueprint následně poskytuje strukturu testování incidentů a dodavatelů:

„Vyberte nedávnou událost nebo proveďte tabletop cvičení k ověření svého plánu. Zachyťte a zaprotokolujte všechna rozhodnutí, role a komunikaci (5.26) a aktualizujte plán o získané poznatky (5.27). Potvrďte, že jsou zavedeny postupy pro uchování forenzních důkazů (5.28), včetně snapshotů logů, záloh a bezpečné izolace dotčených systémů.“

Realistické stolní cvičení má zahrnovat poskytovatele MDR. Použijte scénář, například kompromitovaný privilegovaný účet, izolace koncového bodu, podezření na přístup k poštovní schránce, možná expozice mzdových dat a eskalace upozornění mimo pracovní dobu. Test má ověřit, zda se čas poskytovatele MDR počítá od detekce, oznámení zákazníkovi nebo potvrzení zákazníkem. Toto rozlišení je důležité, když regulační lhůty závisí na okamžiku zjištění a rozhodovacích bodech.

Vytvořte balíček dohledu nad MDR pro jedno upozornění za 90 minut

Rychlým způsobem, jak odhalit mezery, je vybrat jedno nedávné upozornění MDR s vysokou závažností a vytvořit jednostránkovou důkazní stopu. Toto praktické cvičení dobře funguje před audity, přezkumy správní radou a obnovami smluv.

1. Začněte tiketem upozornění. Zachyťte časové razítko, detekční pravidlo, dotčené aktivum, uživatele, závažnost, poznámky analytika MDR a eskalační cestu.
2. Vyhledejte smluvní doložku nebo SLA ukazující očekávanou reakční dobu pro tuto závažnost.
3. Získejte seznam zdrojů logů dokládající, které systémy upozornění napájely, například EDR, poskytovatel identit, firewall, brána zabezpečení e-mailu a cloudové auditní logy.
4. Potvrďte, že logy jsou uchovávány podle politiky a že historickou událost lze stále získat.
5. Ověřte, zda analytik MDR přistoupil k jakémukoli prostředí zákazníka. Pokud ano, zachyťte pojmenovaný účet, důkaz MFA, logy relace a schválení.
6. Zdokumentujte rozhodnutí na straně zákazníka: událost uzavřena, incident vyhlášen, právní posouzení spuštěno, provedeno zamezení šíření nebo přijato riziko.
7. Pokud mohou být dotčeny osobní údaje, zaznamenejte analýzu rolí podle GDPR, vlastníka posouzení porušení a zda byly spuštěny oznamovací povinnosti zpracovatele.
8. Uzavřete získanými poznatky: ladění, nová detekce, změna přístupu, aktualizace playbooku nebo problém SLA dodavatele.

Tato stopa jednoho upozornění je silná, protože propojuje smlouvu, protokolování, přístup, reakci na incidenty, soukromí a dohled vedení do jednoho řetězce důkazů. Pokud ji nedokážete vytvořit pro nedávné upozornění, pravděpodobně ji nedokážete vytvořit ani pod regulačním tlakem.

Monitorování dodavatelů je místo, kde většina programů MDR slábne

Mnoho organizací provede náležitou péči před podpisem smlouvy s poskytovatelem MDR a poté přestane. To pro ISO/IEC 27001:2022, NIS2, DORA ani GDPR nestačí. Služby MDR se neustále mění: nová detekční pravidla, nové analytické týmy, noví dílčí zpracovatelé, nové datové regiony, nové schopnosti EDR, nové integrace, nové zdroje informací o hrozbách a nové modely podpory.

Opatření ISO/IEC 27002:2022 5.22 řeší monitorování, přezkum a řízení změn služeb dodavatelů. Zenith Controls vysvětluje, že 5.22 navazuje na opatření pro vztahy s dodavateli a smlouvy s dodavateli tím, že zajišťuje průběžné monitorování a řízení po zahájení služby. Propojuje se s bezpečností při narušení, řízením zranitelností, souladem, řízením přístupu a bezpečným inženýrstvím.

DORA Articles 28 to 30 činí tuto oblast zvlášť důležitou pro finanční subjekty. Vyžadují průběžné monitorování, registry ujednání s ICT třetími stranami, rozlišení kritičnosti, náležitou péči, práva na audit a inspekci, práva na ukončení, exit strategie, úrovně služeb, asistenci při incidentech, spolupráci s orgány a u kritických nebo důležitých funkcí cíle služeb, testování mimořádných situací a případně spolupráci při penetračním testování na základě hrozeb.

Zenith Blueprint, fáze Controls in Action, Step 23, poskytuje strukturu životního cyklu dodavatelů:

„Sestavte úplný seznam současných dodavatelů a poskytovatelů služeb (5.19) a klasifikujte je podle přístupu k systémům, datům nebo provoznímu řízení.“

Pokračuje:

„U každého kritického dodavatele zjistěte, zda využívá subdodavatele (dílčí zpracovatele), kteří mohou mít přístup k vašim datům nebo systémům.“

Praktický přezkum služby MDR má být u kritických prostředí prováděn čtvrtletně a u prostředí s nižším rizikem alespoň ročně. Agenda má zahrnovat plnění SLA podle závažnosti, eskalovaná upozornění, skutečně pozitivní nálezy, falešně pozitivní nálezy, zmeškané eskalace, stav zdrojů logů, změny privilegovaných přístupů, nové integrace, nové regiony, subdodavatele, dílčí zpracovatele, změny detekčních pravidel, výkonnost podpory incidentů, požadavky na důkazy, otevřená rizika, nápravná opatření a připravenost na exit.

Nejde o mikromanagement. Jde o smyčku ujištění, která prokazuje, že organizace aktivně řídí kritického bezpečnostního dodavatele.

Mapování napříč požadavky souladu: jedna sada opatření MDR, pět auditních konverzací

Hodnota ISO/IEC 27001:2022 spočívá v tom, že organizacím poskytuje jeden soudržný cyklus ISMS pro více konverzací o souladu. Stejný důkazní balíček dohledu nad MDR lze mapovat na NIS2, DORA, GDPR, NIST CSF 2.0 a COBIT 2019.

NIST CSF 2.0 je užitečný pro komunikaci. Jeho funkce GOVERN vyžaduje, aby právní, regulační, smluvní povinnosti a povinnosti v oblasti soukromí byly pochopeny a řízeny, role a pravomoci byly definovány, kyberbezpečnostní riziko bylo začleněno do řízení podnikových rizik a dodavatelská rizika byla komunikována a monitorována.

COBIT 2019 je užitečný pro řízení a ujištění. Auditoři orientovaní na COBIT se často méně zaměřují na jedno opatření a více na to, zda cíle správy a řízení, řízení služeb, vlastnictví rizik a monitorování výkonnosti fungují jako systém.

Jak budou auditoři testovat dohled nad poskytovatelem MDR

Různí auditoři používají různé pohledy, ale všichni chtějí důkazy, že organizace vztah řídí.

Auditor ISO/IEC 27001:2022 začne rozsahem, zainteresovanými stranami, posouzením rizik, Prohlášením o použitelnosti, plánem ošetření rizik a provozními důkazy. Pokud je MDR v rozsahu, auditor bude očekávat, že externě poskytované procesy jsou řízeny v rámci ISMS. Může vzorkovat vztahy s dodavateli, smlouvy s dodavateli, monitorování služeb dodavatelů, protokolování, monitorování, reakci na incidenty, nakládání s důkazy a řízení přístupu.

Orgán dohledu podle DORA se zaměří na provozní odolnost a systémové riziko. Může podrobně zkoumat posouzení kritičnosti, registr ICT služeb, analýzu rizika koncentrace, exit strategii, klasifikaci incidentů, práva na audit a důkazy, že poskytovatel MDR dokáže podpořit regulační oznámení.

Auditor GDPR nebo přezkoumávající osoba v oblasti soukromí se zaměří na správu vztahu správce–zpracovatel. Vyžádá si DPA, náležitou péči o zpracovatele, opatření pro dílčí zpracovatele, ochranná opatření pro logy obsahující osobní údaje, kontroly uchovávání, záznamy o posouzení porušení a důkazy podporující GDPR Article 32.

Auditor COBIT nebo ISACA bude kontrolovat důkazy správy a řízení: vlastnictví dodavatelského rizika, pracovní postup pořizování, zápisy z přezkumů služeb, sledování problémů SLA, nápravná opatření, kvalitu důkazů a to, zda vedení dostává smysluplné metriky.

Nejvýmluvnější auditní požadavek je jednoduchý: „Ukažte mi jedno upozornění MDR od detekce po uzavření.“ Pokud dokážete ukázat smluvní očekávání, zdroj logů, upozornění, eskalaci, rozhodnutí, uchování důkazů, posouzení soukromí, nápravu a reportování vedení, je váš dohled nad MDR vyspělý. Pokud dokážete ukázat pouze tiket dodavatele, máte monitorování, ale slabou správu a řízení.

Reportování vedení: správní rada nepotřebuje paketové záznamy

NIS2 i DORA kladou odpovědnost na úroveň řídicího orgánu. Správní rady a vrcholové vedení nepotřebují surovou telemetrii. Potřebují metriky dohledu nad MDR relevantní pro riziko.

Užitečný čtvrtletní řídicí panel MDR zahrnuje:

• Kritické zdroje logů zařazené oproti očekávaným.
• Procento kritických aktiv pokrytých MDR.
• Upozornění s vysokou závažností podle kategorie a podnikové služby.
• Průměrnou dobu od detekce po oznámení zákazníkovi.
• Průměrnou dobu od potvrzení zákazníkem po rozhodnutí.
• Porušení SLA a nevyřešené kroky poskytovatele.
• Stav přezkumu privilegovaných účtů poskytovatele.
• Změny subdodavatelů nebo dílčích zpracovatelů.
• Incidenty vyžadující právní, regulační nebo zákaznické posouzení oznámení.
• Implementované získané poznatky.

Tento řídicí panel má vstupovat do přezkoumání ISMS vedením, aktualizací ošetření rizik a přezkumu dodavatele. Podle ISO/IEC 27001:2022 musí vedení zajistit, že ISMS je sladěn se strategickým směrem, jsou dostupné zdroje, odpovědnosti jsou přiřazeny, komunikace funguje a dochází k neustálému zlepšování. Metriky MDR jsou praktickým způsobem, jak ukázat, že outsourcovaný bezpečnostní provoz je řízen vedením a není ponechán správcům nástrojů.

Běžné nedostatky dohledu nad MDR, které je nutné odstranit před audity v roce 2026

Nejběžnější mezery jsou běžná selhání správy a řízení.

Za prvé, organizace zapomínají, že poskytovatelé MDR mohou zpracovávat osobní údaje. Bezpečnostní logy jsou někdy považovány za „technická data“, ale mohou obsahovat osobní údaje a občas i citlivý obsah. Analýza rolí podle GDPR a doložky pro zpracovatele mají být dokončeny před onboardingem, nikoli během porušení.

Za druhé, uchovávání logů se předpokládá, nikoli sjednává. Pokud regulační, forenzní nebo zákaznické povinnosti vyžadují důkazy po dobu měsíců, musí to retenční model MDR a SIEM podporovat. Požadavek politiky SME na 12měsíční uchovávání logů poskytovatelem je pro mnoho prostředí praktickým výchozím stavem.

Za třetí, přístup třetích stran je příliš široký. Účty poskytovatele mají být pojmenované, chráněné MFA, monitorované, přezkoumávané a tam, kde je to proveditelné, časově omezené. Sdílené účty a nespravované administrátorské relace vytvářejí auditní riziko i riziko pro reakci na incidenty.

Za čtvrté, prahové hodnoty incidentů jsou nejednoznačné. Závažnost MDR se automaticky nerovná právnímu incidentu, významnému incidentu souvisejícímu s ICT podle DORA, významnému incidentu podle NIS2 ani porušení zabezpečení osobních údajů podle GDPR. Playbook musí definovat, kdo činí každé rozhodnutí.

Za páté, subdodavatelé nejsou viditelní. Pokud poskytovatel MDR změní analytické platformy, regiony podpory nebo navazující zpracovatele, mění se rizikový obraz zákazníka. Předchozí písemný souhlas a pravidelný přezkum jsou nezbytné.

Za šesté, přezkumy služeb se zaměřují pouze na objem tiketů. Vyspělé přezkumy zkoumají zmeškaná upozornění, změny ladění, stav zdrojů logů, získávání důkazů, přístup poskytovatele, spolupráci při incidentech a smluvní povinnosti.

Další kroky: připravte svého poskytovatele MDR na audit s Clarysec

Pokud je váš poskytovatel MDR již v provozu, nečekejte na regulační orgán, zákaznického auditora nebo incident, aby odhalil, že vaše důkazy jsou neúplné. Začněte jedním nedávným upozorněním a vytvořte stopu. Poté klasifikujte poskytovatele, přezkoumejte smlouvu, ověřte protokolování, otestujte eskalaci, potvrďte doložky pro zpracovatele, přezkoumejte přístup a naplánujte monitorování dodavatele.

Clarysec vám může pomoci toto rychle převést do provozu pomocí:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint pro fázovanou implementaci, včetně Step 19 pro protokolování, monitorování a ověření přístupu a Step 23 pro opatření řízení dodavatelů a incidentů.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls pro mapování opatření ISO/IEC 27002:2022 5.19, 5.22 a 8.15 na auditní očekávání NIS2, DORA, GDPR, NIST a COBIT.
• Šablony politik Clarysec, včetně Politika reakce na incidenty, Bezpečnostní politika třetích stran a dodavatelů, Politika protokolování a monitorování, Politika reakce na incidenty – SME, Bezpečnostní politika třetích stran a dodavatelů – SME, Politika protokolování a monitorování – SME a Politika ochrany dat a soukromí – SME.

MDR je jednou z nejhodnotnějších bezpečnostních investic, které může organizace uskutečnit. V roce 2026 musí být tato hodnota prokázána správou a řízením, důkazy a odpovědným dohledem. Pokud chcete praktický balíček dohledu nad MDR mapovaný na ISO/IEC 27001:2022, NIS2, DORA a GDPR Article 32, Clarysec vám jej pomůže vybudovat dříve, než se další upozornění stane dalším zjištěním auditu.