Toezicht op MDR-providers onder NIS2, DORA en GDPR

Om 02:13 op maandagochtend opent de MDR-provider een alert met hoge ernst: impossible travel, verdachte mailboxregels en een geprivilegieerd account dat wordt gebruikt vanaf een onbeheerd endpoint. De SOC-analist escaleert via het ticketportaal. Uw IT-manager slaapt. De CFO ontvangt een phishingwaarschuwing van een bankcontact voordat het interne incidentkanaal actief wordt. Om 07:30 krijgt de CISO drie ongemakkelijke vragen.

Wie was bevoegd om een incident af te kondigen?

Kunnen we aantonen dat de MDR-provider over de juiste logboeken beschikte, deze lang genoeg heeft bewaard en bewijsmateriaal heeft veiliggesteld?

Als persoonsgegevens zijn ingezien, kan Juridische Zaken dan de GDPR-termijnen voor de beoordeling van een inbreuk halen terwijl Operations NIS2- of DORA-rapportage voorbereidt?

Een maand later vraagt de externe auditor om hetzelfde bewijsmateriaal, maar op een andere toon. Het PDF-rapport van de MDR-provider is nuttig, maar niet voldoende. De auditor wil ruwe alertgegevens, volledige logbestanden, het escalatiespoor, het interne besluitvormingslogboek, de leveranciersbeoordeling en bewijs dat de organisatie zelfstandig kon verifiëren wat er is gebeurd.

Dat is de kern van toezicht op MDR-providers in 2026. Organisaties besteden detectie en respons uit omdat interne SOC-capaciteit duur is, werving moeilijk is en dreigingsactiviteit onverminderd doorgaat. Maar uitbestede detectie betekent geen uitbestede verantwoordingsplicht. Onder NIS2 blijven managementorganen verantwoordelijk voor het goedkeuren van en toezicht houden op maatregelen voor cyberbeveiligingsrisicobeheer. Onder DORA blijven financiële entiteiten volledig verantwoordelijk voor ICT-risico’s van derde aanbieders, waaronder kritieke ICT-diensten, ondersteuning bij incidenten, auditrechten, onderaanneming en exit. Onder GDPR moeten verwerkingsverantwoordelijken passende beveiliging van de verwerking aantonen, met name wanneer verwerkers telemetrie, endpointgegevens, gebruikersidentificatoren, IP-adressen, e-mailinhoud, logboeken of forensische images verwerken.

De praktische kloof zit zelden alleen in het MDR-contract. Het gaat om de bewijsketen tussen het contract en de live dienstverlening: alertroutering, geprivilegieerde toegang, logretentie, escalatiedrempels, incidentbewijsmateriaal, transparantie over onderaannemers, verwerkersclausules, dienstbeoordelingen, tabletop-oefeningen en managementrapportage.

Een verdedigbaar programma voor toezicht op MDR-providers heeft één operationeel model nodig dat meerdere auditgesprekken ondersteunt. ISO/IEC 27001:2022 biedt daarvoor de ruggengraat.

Toezicht op MDR begint met verantwoordingsplicht, niet met de SOC-console

Een veelgemaakte fout is MDR-onboarding te behandelen als een technisch project: EDR-agents uitrollen, identiteitslogboeken doorsturen, alerts configureren, een Teams- of Slack-kanaal afspreken en live gaan. Dat kan de detectie verbeteren, maar het bewijst geen governance.

NIS2 maakt dit expliciet. Essentiële en belangrijke entiteiten moeten passende en evenredige technische, operationele en organisatorische maatregelen voor cyberbeveiligingsrisicobeheer implementeren. Article 21 omvat risicoanalyse, incidentenafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, cyberhygiëne, toegangscontrole, beheer van bedrijfsmiddelen, cryptografie en multifactorauthenticatie. Article 20 tilt dit naar verantwoordingsplicht van het managementorgaan, met vereiste goedkeuring en toezicht op die maatregelen.

MDR-providers raken vaak meerdere NIS2 Article 21-gebieden tegelijk:

• Incidentenafhandeling, omdat de provider triage uitvoert, escaleert en indamming kan aanbevelen.
• Beveiliging van de toeleveringsketen, omdat de provider een directe dienstverlener is met operationele beveiligingsimpact.
• Toegangscontrole, omdat de provider toegang kan hebben tot consoles, logboeken, endpointtools of cloudtenants.
• Logging en monitoring, omdat detectie afhankelijk is van logdekking, retentie en correlatie.
• Cyberhygiëne, omdat MDR-bevindingen vaak zwaktes in patching, identiteit of configuratie blootleggen.
• Bedrijfscontinuïteit, omdat vertraagde respons kritieke diensten kan verstoren.

Voor financiële entiteiten maakt DORA het operationele model zwaarder. DORA is van toepassing vanaf 17 januari 2025 en vereist ICT-risicomanagement, incidentmelding, weerbaarheidstesten, informatiedeling en beheer van ICT-risico’s van derde aanbieders. DORA verduidelijkt ook dat voor financiële entiteiten die ook onder NIS2 zijn geïdentificeerd, DORA fungeert als de sectorspecifieke rechtshandeling van de Unie voor overlappende cyberbeveiligingsverplichtingen. Een gereguleerde bank, betalingsinstelling, beleggingsonderneming, verzekeraar of aanbieder van cryptoactivadiensten kan niet simpelweg zeggen: “Onze MDR-provider regelt dat.” DORA verwacht dat de entiteit ICT-incidenten classificeert, externe ICT-dienstverleners beheert en monitort, registers van ICT-dienstverleningsafspraken bijhoudt, contractuele rechten definieert, weerbaarheid test, oorzaakanalyse uitvoert en majeure ICT-gerelateerde incidenten gefaseerd rapporteert.

GDPR voegt een ander perspectief toe. Als MDR-telemetrie gebruikersidentificatoren, IP-adressen, e-mailmetadata, authenticatieregistraties, endpointartefacten of bestanden met persoonsgegevens bevat, zijn de GDPR-beginselen voor beveiliging en verantwoordingsplicht van toepassing. Article 5 omvat integriteit, vertrouwelijkheid en verantwoordingsplicht. Article 32 beveiliging van de verwerking wordt dan een praktische bewijsvraag: waren logboeken beschermd, was toegang beperkt, werd encryptie toegepast waar passend, werden verwerkers aangestuurd en kan de organisatie aantonen wat er is gebeurd?

De boodschap is in alle drie regimes consistent: u kunt het werk delegeren, maar niet de verantwoordelijkheid.

ISO/IEC 27001:2022 maakt van MDR een auditeerbaar proces

Een goed geïmplementeerd ISMS op basis van ISO/IEC 27001:2022 verandert toezicht op MDR-providers van een belofte in leveranciersmanagement in een operationeel model op basis van bewijsmateriaal. Clause 8.1 is bijzonder belangrijk, omdat die vereist dat organisaties extern geleverde processen, producten en diensten beheersen die relevant zijn voor het ISMS. MDR is precies dat: een extern geleverd proces dat invloed kan hebben op incidentrespons, privacy, weerbaarheid, regelgevende rapportage en bedrijfscontinuïteit.

De belangrijkste gebieden uit ISO/IEC 27001:2022 Annex A voor MDR-toezicht zijn leveranciersrelaties, beveiligingsvereisten in leveranciersovereenkomsten, ICT-risicomanagement in de toeleveringsketen, monitoring van leveranciersdiensten, incidentmanagement, bewijsbehandeling, logging, monitoring, toegangscontrole, geprivilegieerde toegang, cryptografie en paraatheid voor bedrijfscontinuïteit.

Clarysec’s Zenith Controls: The Cross-Compliance Guide Zenith Controls is de cross-compliance-referentie voor dit werk. De gids brengt ISO/IEC 27002:2022-beheersmaatregelen in kaart op andere vereisten, gerelateerde beheersmaatregelen, auditverwachtingen en implementatiebewijsmateriaal. Voor MDR-toezicht staan drie ISO/IEC 27002:2022-beheersmaatregelen centraal: 5.19 voor leveranciersrelaties, 5.22 voor monitoring van leveranciersdiensten en wijzigingsbeheer, en 8.15 voor logging. Deze worden ondersteund door 5.20 leveranciersovereenkomsten, 5.21 ICT-beveiliging van de toeleveringsketen, 5.24 tot en met 5.28 incidentmanagement en bewijsbehandeling, 5.34 privacy en persoonlijk identificeerbare informatie (PII), 5.36 naleving, 8.16 monitoringactiviteiten, 8.17 kloksynchronisatie, 8.18 gebruik van geprivilegieerde hulpprogramma’s en 8.8 beheer van technische kwetsbaarheden.

Dit is relevant omdat een auditbevinding rond MDR zelden “geen MDR” zegt. Meestal zegt die een van de volgende dingen:

• De MDR-provider was niet als kritiek geclassificeerd.
• Contractuele bepalingen bevatten geen incidentmelding, toegang tot bewijsmateriaal of auditrechten.
• Logboeken werden niet lang genoeg bewaard om een gemelde gebeurtenis te onderzoeken.
• Providertoegang was gedeeld, permanent of niet gemonitord.
• De klant heeft de MDR-prestaties niet beoordeeld aan de hand van SLA’s.
• Onderaannemers of subverwerkers waren niet goedgekeurd.
• Meldingsverplichtingen voor inbreuken in verband met persoonsgegevens waren niet afgestemd op incidentworkflows.
• Bewijsmateriaal werd niet op een forensisch bruikbare manier veiliggesteld.
• Het management had geen metrieken die lieten zien of de MDR-dienst het risico verlaagde.

Zenith Controls beschrijft de relatie tussen leveranciersverwachtingen en overeenkomsten helder:

“5.19 stelt de beveiligingsverwachtingen vast voor hoe leveranciers met informatie van de organisatie moeten omgaan. 5.20 formaliseert die verwachtingen door te waarborgen dat contracten of overeenkomsten expliciet beveiligingsclausules bevatten, zoals vertrouwelijkheidsvereisten, naleving van beveiligingsbeleid en procedures voor incidentmelding. Zonder 5.20 zijn de in 5.19 vastgestelde vereisten mogelijk juridisch niet afdwingbaar.”

Voor MDR is die zin de governanceles. Als het contract niet vereist dat de provider logboeken bewaart, bewijsmateriaal verstrekt, meewerkt aan incidenten, onderaanneming beperkt, audits ondersteunt en escalatietermijnen volgt, kan de SOC-dienst operationeel nuttig zijn, maar auditmatig zwak.

Wat het MDR-contract moet aantonen vóór de eerste alert

Een goed MDR-contract is niet alleen een commerciële orderbevestiging. Het is een beheersdocument. DORA Articles 28 tot 30 vereisen dat ICT-risico’s van derde aanbieders gedurende de hele levenscyclus worden beheerd, inclusief registers van ICT-contracten, criticaliteitsclassificatie, due diligence vóór contractsluiting, audit- en inspectieaanpak, beëindigingsrechten, exitstrategieën, duidelijke dienstbeschrijvingen, serviceniveaus, locaties van dienstverlening en gegevensverwerking, toezeggingen inzake gegevensbescherming, incidentondersteuning en samenwerking met autoriteiten. NIS2 Article 21 vereist beveiliging van de toeleveringsketen voor directe leveranciers en dienstverleners. GDPR vereist rollen van verwerkingsverantwoordelijke en verwerker, waarborgen van de verwerker, gegevensbeschermingsclausules en bewijsmateriaal voor beveiliging van de verwerking.

De beleidsbibliotheek van Clarysec vertaalt die verplichtingen naar praktische contractuele en operationele vereisten. In het Enterprise Incident Response Policy Incidentresponsbeleid wordt MDR expliciet behandeld als een aangestuurde incidentcapaciteit van een derde partij:

“Integratie met diensten van derden, waaronder Managed Detection and Response (MDR), Security Incident and Event Management (SIEM) en leveranciers van forensische analyse, moet worden beheerst door duidelijk gedefinieerde Service Level Agreements (SLA’s) en geheimhoudingsbepalingen.”

Die clausule is belangrijk omdat MDR-providers vaak zeer gevoelige informatie ontvangen voordat de organisatie weet of een incident meldingsplichtig is. Telemetrie kan gebruikersnamen, bestandspaden, e-mailonderwerpen, interne hostnamen, IP-adressen, netwerkdiagrammen en indicatoren van compromittering bevatten. Geheimhoudingsbepalingen beschermen de organisatie tijdens het onderzoek en ondersteunen GDPR-verantwoordingsplicht.

Het Enterprise Third party and supplier security policy Beleid inzake beveiliging van derden en leveranciers voegt twee clausules toe die auditors verwachten te zien bij de beoordeling van MDR-toezicht:

“Rechten om te auditen, te inspecteren en beveiligingsbewijsmateriaal op te vragen”

en:

“Het gebruik van onderaannemers alleen na voorafgaande schriftelijke toestemming”

Voor mkb-organisaties wordt hetzelfde governanceprincipe afgeschaald, maar niet verwijderd. Het Third-Party and Supplier Security Policy - SME Beleid inzake beveiliging van derden en leveranciers - mkb vereist het principe van minimale privileges:

“Leveranciers mogen alleen toegang krijgen tot de minimale systemen en gegevens die nodig zijn om hun functie uit te voeren.”

Het vereist ook:

“Beperkingen op verdere onderaanneming zonder goedkeuring”

Deze clausules zijn bijzonder relevant voor MDR. Veel providers gebruiken gelaagde SOC-teams, platformleveranciers, partners voor dreigingsinformatie, cloudanalysediensten of regionale supportmedewerkers. Als downstream partijen toegang kunnen krijgen tot klantlogboeken of persoonsgegevens, heeft de klant zichtbaarheid en goedkeuringsmechanismen nodig. In DORA-termen is dit onderdeel van toezicht op onderaanneming en concentratierisico. In GDPR-termen is dit governance van subverwerkers. In NIS2-termen is dit risicomanagement in de toeleveringsketen.

De essentiële checklist voor MDR-toezicht

Een verdedigbare relatie met een MDR-provider moet toetsbaar zijn. De volgende checklist combineert contractuele, operationele en bewijsvereisten in één beheersingsbeeld.

Deze checklist moet worden ingebed in inkoop, onboarding, periodieke beoordeling en incidenttesten. Als een onderdeel ontbreekt, moet de organisatie dit behandelen als een leveranciersrisico, niet als een administratief probleem.

Zeven bewijsdomeinen die auditors verwachten

Om MDR-toezicht auditgereed te maken, adviseert Clarysec een MDR-bewijsdossier op te bouwen dat is georganiseerd in zeven domeinen. Dit dossier hoort in het ISMS thuis, niet in een inkoopmap die niemand beoordeelt.

Deze tabel verandert het gesprek met de provider. In plaats van te vragen: “Monitoren jullie ons?” vraagt de organisatie: “Kunnen we elk kwartaal aantonen dat de MDR-dienst effectief blijft, voldoet aan de vereisten en is afgestemd op onze risicobereidheid?”

Logging is de brug tussen detectie en nalevingsbewijsmateriaal

MDR zonder betrouwbare logging is uitbesteed giswerk. De provider kan sommige dreigingen detecteren, maar de organisatie kan scope, tijdlijn, oorzaak of impact niet aantonen.

ISO/IEC 27002:2022-beheersmaatregel 8.15 behandelt logging. Zenith Controls classificeert logging als een detectieve beheersmaatregel die vertrouwelijkheid, integriteit en beschikbaarheid ondersteunt, afgestemd op het Detect-cyberbeveiligingsconcept en de capaciteit voor beheer van informatiebeveiligingsgebeurtenissen. De gids koppelt logging rechtstreeks aan monitoringactiviteiten, beoordeling van gebeurtenissen, incidentrespons, geleerde lessen, geprivilegieerde toegang, kloksynchronisatie, toegangscontrole, privacy, bewijsverzameling, kwetsbaarhedenbeheer en monitoring van fysieke beveiliging.

Daarom staat logging centraal in bewijsmateriaal voor NIS2, DORA en GDPR Article 32. NIS2 Article 23-rapportage voor significante incidenten vereist een vroegtijdige waarschuwing binnen 24 uur na kennisname, een melding binnen 72 uur en een eindrapport uiterlijk één maand na de melding. DORA-rapportage over majeure ICT-gerelateerde incidenten vereist classificatie, escalatie, communicatie, oorzaakanalyse en eindrapportage. GDPR-verantwoordingsplicht vereist dat organisaties aantonen wat er met persoonsgegevens is gebeurd en of de beveiligingsmaatregelen passend waren.

Clarysec’s Logging and Monitoring Policy - SME Beleid voor logging en monitoring - mkb biedt een eenvoudige contractuele beheersmaatregel voor kleinere organisaties die externe providers gebruiken:

“Contracten moeten providers verplichten logboeken ten minste 12 maanden te bewaren en op verzoek toegang te verstrekken”

Voor enterprise-omgevingen voegt het Logging and Monitoring Policy Beleid voor logging en monitoring de operationele integratievereiste toe:

“Moet op verzoek loggegevens verstrekken of integreren met het SIEM-/logaggregatieplatform van de organisatie.”

Deze clausules lossen een terugkerend probleem bij incidentrespons op: tijdens een onderzoek zegt de MDR-provider dat de gebeurtenis ouder is dan het doorzoekbare retentievenster, dat logboeken alleen beschikbaar zijn via een betaalde forensische export, of dat het SIEM van de klant de verrijking en analistenacties van de provider niet bevat. Als toegang tot logboeken niet vooraf is gedefinieerd, raakt de incidenttijdlijn gefragmenteerd.

Een sterk MDR-loggingmodel moet verplichte logbronnen, gebeurtenistypen, retentieperioden, integriteitsbescherming, toegangsgoedkeuringen, tijdsynchronisatie, exportformaten en correlatieregels tussen klant- en providerplatforms definiëren. Het moet ook provideracties omvatten, waaronder wijzigingen in detectieregels, opdrachten voor endpointisolatie, administratieve toegang, analistnotities en exporten van bewijsmateriaal.

Ondersteunende ISO-normen versterken deze aanpak. ISO/IEC 27035-1:2023 en ISO/IEC 27035-2:2023 verbinden logging met incidentdetectie, triage en centrale analyse. ISO/IEC 27701:2021 voegt privacy-specifieke logging van verwerkingsactiviteiten met persoonlijk identificeerbare informatie (PII) toe. ISO/IEC 27017:2021 en ISO/IEC 27018:2020 voegen verwachtingen toe voor cloud- en cloud-PII-logging, vooral wanneer providers klantgegevens in publieke cloudomgevingen verwerken. ISO/IEC 27005:2024 kadert onvoldoende logging als een kwestie van risicobehandeling, niet slechts als een toolinghiaat.

Incidentrespons: MDR kan escaleren, maar het management moet beslissen

MDR-providers detecteren en adviseren. De verantwoordingsplichtige organisatie verklaart incidenten, beoordeelt de regelgevende impact, communiceert met autoriteiten en beslist of melding van een inbreuk in verband met persoonsgegevens vereist is.

Dit onderscheid is belangrijk omdat MDR-ernst niet automatisch gelijkstaat aan een NIS2 significant incident, een DORA majeur ICT-gerelateerd incident of een GDPR-inbreuk in verband met persoonsgegevens. De provider kan een alert als “hoge ernst” labelen, maar de organisatie moet beslissen of kritieke diensten zijn geraakt, of persoonsgegevens zijn gecompromitteerd, of klanten moeten worden geïnformeerd, of toezichthouders moeten worden geïnformeerd en of het management een indammingsactie met operationele impact moet goedkeuren.

Clarysec’s Incident Response Policy - SME Incidentresponsbeleid - mkb is direct:

“Derde partijen moeten handelen in overeenstemming met ondertekende overeenkomsten, die clausules voor melding van inbreuken in verband met persoonsgegevens en verplichtingen tot samenwerking bij respons moeten bevatten.”

Deze clausule is waar GDPR Article 32-bewijsmateriaal samenkomt met operationele incidentrespons. Als de MDR-provider vermoedelijke data-exfiltratie waarneemt vanaf een endpoint met persoonsgegevens, moet de provider weten hoe snel moet worden gemeld, aan wie moet worden gemeld, welk bewijsmateriaal moet worden veiliggesteld en hoe de beoordeling door de verwerkingsverantwoordelijke moet worden ondersteund.

Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint geeft de testmethode. In de fase Controls in Action, Step 19, draagt de Zenith Blueprint teams op logging en monitoring operationeel te valideren:

“Kies een recent incident of een recente gebeurtenis en laat zien hoe u die met behulp van uw logboeken hebt getraceerd. Als functies voor logintegriteit worden gebruikt (bijv. hashverificatie), documenteer dat dan ook. Bevestig dat alertering functioneert (bijv. mislukte aanmeldingen of privilege-escalaties triggeren alerts).”

Dezelfde stap behandelt identiteit en geprivilegieerde toegang:

“Controleer voor geprivilegieerde accounts dat MFA wordt afgedwongen, beheerdersrollen zijn gescheiden (accounts in de stijl admin_john alleen voor beheertaken worden gebruikt) en er een actuele lijst van geprivilegieerde gebruikers bestaat.”

In de MDR-context moet de lijst met geprivilegieerde gebruikers ook provideraccounts bevatten, niet alleen medewerkers. Als de MDR-provider consoletoegang, rechten voor endpointisolatie, EDR-beheerdersrechten of leestoegang tot gevoelige logboeken heeft, horen die accounts in de beoordeling thuis.

Step 23 van de Zenith Blueprint geeft vervolgens de teststructuur voor incidenten en leveranciers:

“Selecteer een recente gebeurtenis of voer een tabletop-oefening uit om uw plan te valideren. Leg alle besluiten, rollen en communicatie vast en log deze (5.26), en werk het plan bij met geleerde lessen (5.27). Bevestig dat procedures aanwezig zijn om forensisch bewijsmateriaal veilig te stellen (5.28), waaronder logmomentopnamen, back-ups en veilige isolatie van getroffen systemen.”

Een realistische tabletop-oefening moet de MDR-provider omvatten. Gebruik een scenario zoals een gecompromitteerd geprivilegieerd account, endpointisolatie, vermoedelijke toegang tot mailboxen, mogelijke blootstelling van salarisgegevens en alertescalatie buiten kantooruren. De test moet verifiëren of de klok van de MDR-provider start bij detectie, klantmelding of klantbevestiging. Dat onderscheid is belangrijk wanneer regelgevende termijnen afhangen van kennisname en beslismomenten.

Bouw in 90 minuten een MDR-toezichtpakket voor één alert

Een snelle manier om hiaten bloot te leggen is één recente MDR-alert met hoge ernst te kiezen en een bewijsspoor van één pagina op te bouwen. Deze praktische oefening werkt goed voorafgaand aan audits, bestuursbeoordelingen en contractverlengingen.

1. Begin met het alertticket. Leg tijdstempel, detectieregel, getroffen bedrijfsmiddel, gebruiker, ernst, notities van de MDR-analist en escalatiepad vast.
2. Haal de contractclausule of SLA op die de verwachte responstijd voor die ernst toont.
3. Haal de lijst met logbronnen op die aantoont welke systemen de alert voedden, zoals EDR, identiteitsprovider, firewall, e-mailbeveiligingsgateway en cloudauditlogboeken.
4. Bevestig dat logboeken volgens beleid worden bewaard en dat de historische gebeurtenis nog steeds kan worden opgehaald.
5. Controleer of de MDR-analist toegang heeft gehad tot een klantomgeving. Zo ja, leg het account op naam, MFA-bewijsmateriaal, sessielogboeken en goedkeuring vast.
6. Documenteer het besluit aan klantzijde: gebeurtenis gesloten, incident afgekondigd, juridische beoordeling gestart, indamming uitgevoerd of risico geaccepteerd.
7. Als persoonsgegevens betrokken kunnen zijn, leg dan de GDPR-rolanalyse vast, de eigenaar van de inbreukbeoordeling en of verwerkersmeldingsverplichtingen zijn geactiveerd.
8. Sluit af met geleerde lessen: tuning, nieuwe detectie, toegangsaanpassing, update van het draaiboek of een SLA-kwestie met de leverancier.

Dit bewijsspoor voor één alert is krachtig omdat het contract, logging, toegang, incidentrespons, privacy en managementtoezicht in één bewijsketen verbindt. Als u dit niet kunt opbouwen voor een recente alert, kunt u het waarschijnlijk ook niet opbouwen onder regelgevende druk.

Leveranciersmonitoring is waar de meeste MDR-programma’s verzwakken

Veel organisaties voeren due diligence uit voordat ze een MDR-contract ondertekenen en stoppen daarna. Dat is niet genoeg voor ISO/IEC 27001:2022, NIS2, DORA of GDPR. MDR-diensten veranderen continu: nieuwe detectieregels, nieuwe analistenteams, nieuwe subverwerkers, nieuwe gegevensregio’s, nieuwe EDR-capaciteiten, nieuwe integraties, nieuwe feeds voor dreigingsinformatie en nieuwe supportmodellen.

ISO/IEC 27002:2022-beheersmaatregel 5.22 behandelt monitoring, beoordeling en wijzigingsbeheer van leveranciersdiensten. Zenith Controls legt uit dat 5.22 voortbouwt op beheersmaatregelen voor leveranciersrelaties en overeenkomsten door continue monitoring en beheer na de start van de dienstverlening te waarborgen. De maatregel sluit aan op beveiliging tijdens verstoringen, kwetsbaarhedenbeheer, naleving, toegangscontrole en veilige engineering.

DORA Articles 28 tot 30 maken dit vooral belangrijk voor financiële entiteiten. Ze vereisen doorlopende monitoring, registers van ICT-afspraken met derden, onderscheid naar criticaliteit, due diligence, audit- en inspectierechten, beëindigingsrechten, exitstrategieën, serviceniveaus, incidentondersteuning, samenwerking met autoriteiten en, voor kritieke of belangrijke functies, servicedoelstellingen, tests van noodmaatregelen en waar relevant samenwerking bij dreigingsgestuurde penetratietesten.

De Zenith Blueprint, fase Controls in Action, Step 23, biedt de structuur voor de leverancierslevenscyclus:

“Stel een volledige lijst samen van huidige leveranciers en dienstverleners (5.19), en classificeer deze op basis van toegang tot systemen, gegevens of operationele controle.”

De gids vervolgt:

“Bepaal voor elke kritieke leverancier of zij onderaannemers (subverwerkers) gebruiken die toegang kunnen hebben tot uw gegevens of systemen.”

Een praktische MDR-dienstbeoordeling moet voor kritieke omgevingen elk kwartaal plaatsvinden en voor omgevingen met een lager risico ten minste jaarlijks. De agenda moet SLA-naleving per ernstniveau omvatten, geëscaleerde alerts, true positives, false positives, gemiste escalaties, gezondheid van logbronnen, wijzigingen in geprivilegieerde toegang, nieuwe integraties, nieuwe regio’s, onderaannemers, subverwerkers, wijzigingen in detectieregels, prestaties bij incidentondersteuning, verzoeken om bewijsmateriaal, open risico’s, corrigerende maatregelen en gereedheid voor exit.

Dit is geen micromanagement. Het is de assurancecyclus die aantoont dat de organisatie een kritieke beveiligingsleverancier actief aanstuurt.

Cross-compliance mapping: één MDR-beheersset, vijf auditgesprekken

De waarde van ISO/IEC 27001:2022 is dat het organisaties één coherente ISMS-cyclus geeft voor meerdere nalevingsgesprekken. Hetzelfde MDR-toezichtdossier kan worden gemapt op NIS2, DORA, GDPR, NIST CSF 2.0 en COBIT 2019.

NIST CSF 2.0 is nuttig voor communicatie. De GOVERN-functie vereist dat wettelijke, regelgevende, contractuele en privacyverplichtingen worden begrepen en beheerd, rollen en bevoegdheden worden gedefinieerd, cyberbeveiligingsrisico wordt geïntegreerd in enterprise risk management en leveranciersrisico’s worden gecommuniceerd en gemonitord.

COBIT 2019 is nuttig voor management en assurance. COBIT-georiënteerde auditors richten zich vaak minder op één afzonderlijke beheersmaatregel en meer op de vraag of governancedoelstellingen, servicemanagement, risico-eigenaarschap en prestatiemonitoring als systeem werken.

Hoe auditors toezicht op MDR-providers zullen testen

Verschillende auditors gebruiken verschillende invalshoeken, maar zij willen allemaal bewijsmateriaal dat de organisatie de relatie beheerst.

Een ISO/IEC 27001:2022-auditor begint met reikwijdte, belanghebbenden, risicobeoordeling, Verklaring van Toepasselijkheid, risicobehandelingsplan en operationeel bewijsmateriaal. Als MDR binnen de reikwijdte valt, verwacht de auditor dat extern geleverde processen onder het ISMS worden beheerst. De auditor kan steekproeven nemen op leveranciersrelaties, leveranciersovereenkomsten, monitoring van leveranciersdiensten, logging, monitoring, incidentrespons, bewijsbehandeling en toegangscontrole.

Een DORA-toezichthouder richt zich op operationele weerbaarheid en systeemrisico. Die kan de criticaliteitsbeoordeling, het ICT-dienstenregister, de analyse van concentratierisico, de exitstrategie, incidentclassificatie, auditrechten en bewijsmateriaal dat de MDR-provider regelgevende rapportage kan ondersteunen, kritisch beoordelen.

Een GDPR-auditor of privacybeoordelaar richt zich op governance tussen verwerkingsverantwoordelijke en verwerker. Die zal vragen om de verwerkersovereenkomst, due diligence op de verwerker, beheersmaatregelen voor subverwerkers, waarborgen voor logboeken met persoonsgegevens, retentiebeheersmaatregelen, registraties van inbreukbeoordelingen en bewijsmateriaal ter ondersteuning van Article 32.

Een COBIT- of ISACA-auditor onderzoekt governancebewijsmateriaal: eigenaarschap van leveranciersrisico, inkoopworkflow, notulen van dienstbeoordelingen, opvolging van SLA-issues, corrigerende maatregelen, kwaliteit van bewijsmateriaal en of het management betekenisvolle metrieken ontvangt.

Het meest onthullende auditverzoek is eenvoudig: “Laat me één MDR-alert zien van detectie tot sluiting.” Als u contractverwachting, logbron, alert, escalatie, besluit, bewaring van bewijsmateriaal, privacybeoordeling, herstelmaatregel en managementrapportage kunt tonen, is uw MDR-toezicht volwassen. Als u alleen een vendorticket kunt tonen, heeft u monitoring maar zwakke governance.

Managementrapportage: de raad van bestuur heeft geen packet captures nodig

NIS2 en DORA leggen beide verantwoordelijkheid op het niveau van het managementorgaan. Raden van bestuur en leidinggevenden hebben geen ruwe telemetrie nodig. Zij hebben risicorelevante metrieken voor MDR-toezicht nodig.

Een bruikbaar kwartaaldashboard voor MDR bevat:

• Kritieke logbronnen onboarded versus verwacht.
• Percentage kritieke assets dat door MDR wordt gedekt.
• Alerts met hoge ernst per categorie en bedrijfsdienst.
• Gemiddelde tijd van detectie tot klantmelding.
• Gemiddelde tijd van klantbevestiging tot besluit.
• SLA-overtredingen en niet-afgehandelde provideracties.
• Beoordelingsstatus van geprivilegieerde provideraccounts.
• Wijzigingen in onderaannemers of subverwerkers.
• Incidenten waarvoor juridische, regelgevende of klantmeldingsbeoordeling vereist is.
• Geïmplementeerde geleerde lessen.

Dit dashboard moet input leveren voor de ISMS-managementbeoordeling, updates van risicobehandeling en leveranciersbeoordeling. Onder ISO/IEC 27001:2022 moet leiderschap waarborgen dat het ISMS is afgestemd op de strategische richting, middelen beschikbaar zijn, verantwoordelijkheden zijn toegewezen, communicatie werkt en voortdurende verbetering plaatsvindt. MDR-metrieken zijn een praktische manier om te laten zien dat uitbestede beveiligingsoperaties door het management worden bestuurd en niet aan toolbeheerders worden overgelaten.

Veelvoorkomende valkuilen in MDR-toezicht die vóór audits in 2026 moeten worden opgelost

De meest voorkomende hiaten zijn gewone governancefouten.

Ten eerste vergeten organisaties dat MDR-providers persoonsgegevens kunnen verwerken. Beveiligingslogboeken worden soms behandeld als “technische gegevens”, maar ze kunnen persoonsgegevens en soms gevoelige inhoud bevatten. GDPR-rolanalyse en verwerkersclausules moeten vóór onboarding worden afgerond, niet tijdens een inbreuk.

Ten tweede wordt logretentie verondersteld in plaats van contractueel vastgelegd. Als regelgevende, forensische of klantverplichtingen maandenlang bewijsmateriaal vereisen, moet het retentiemodel van MDR en SIEM dat ondersteunen. De mkb-beleidsvereiste voor 12 maanden logretentie door providers is voor veel omgevingen een praktische baseline.

Ten derde is toegang van derden te ruim. Provideraccounts moeten op naam staan, met MFA worden beschermd, gemonitord, beoordeeld en waar haalbaar tijdgebonden zijn. Gedeelde accounts en onbeheerde administratieve sessies creëren audit- en incidentresponsrisico.

Ten vierde zijn incidentdrempels ambigu. MDR-ernst is niet automatisch gelijk aan een juridisch incident, een DORA majeur ICT-gerelateerd incident, een NIS2 significant incident of een GDPR-inbreuk in verband met persoonsgegevens. Het draaiboek moet definiëren wie elk besluit neemt.

Ten vijfde zijn onderaannemers onzichtbaar. Als de MDR-provider analyseplatforms, supportregio’s of downstream verwerkers wijzigt, verandert het risicobeeld van de klant. Voorafgaande schriftelijke toestemming en periodieke beoordeling zijn essentieel.

Ten zesde richten dienstbeoordelingen zich alleen op ticketvolume. Volwassen beoordelingen onderzoeken gemiste alerts, tuningwijzigingen, gezondheid van logbronnen, opvraagbaarheid van bewijsmateriaal, providertoegang, samenwerking bij incidenten en contractuele verplichtingen.

Volgende stappen: maak uw MDR-provider auditgereed met Clarysec

Als uw MDR-provider al live is, wacht dan niet tot een toezichthouder, klantauditor of incident ontdekt dat uw bewijsmateriaal onvolledig is. Begin met één recente alert en bouw het bewijsspoor op. Classificeer vervolgens de provider, beoordeel het contract, valideer logging, test escalatie, bevestig verwerkersclausules, beoordeel toegang en plan leveranciersmonitoring.

Clarysec kan u helpen dit snel te operationaliseren met:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint voor gefaseerde implementatie, inclusief Step 19 voor logging, monitoring en toegangsvalidatie, en Step 23 voor beheersmaatregelen voor leveranciers- en incidentmanagement.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls om ISO/IEC 27002:2022-beheersmaatregelen 5.19, 5.22 en 8.15 in kaart te brengen op auditverwachtingen voor NIS2, DORA, GDPR, NIST en COBIT.
• Clarysec-beleidssjablonen, waaronder Incidentresponsbeleid, Beleid inzake beveiliging van derden en leveranciers, Beleid voor logging en monitoring, Incidentresponsbeleid - mkb, Beleid inzake beveiliging van derden en leveranciers - mkb, Beleid voor logging en monitoring - mkb en Beleid inzake gegevensbescherming en privacy - mkb.

MDR is een van de meest waardevolle beveiligingsinvesteringen die een organisatie kan doen. In 2026 moet die waarde worden aangetoond met governance, bewijsmateriaal en verantwoord toezicht. Als u een praktisch MDR-toezichtpakket wilt dat is gemapt op ISO/IEC 27001:2022, NIS2, DORA en GDPR Article 32, kan Clarysec u helpen dit op te bouwen voordat de volgende alert de volgende auditbevinding wordt.