Tillsyn av MDR-leverantörer för NIS2, DORA och GDPR

Klockan 02:13 en måndagsmorgon öppnar MDR-leverantören ett larm med hög allvarlighetsgrad: omöjlig resa, misstänkta brevlåderegler och ett privilegierat konto som används från en ohanterad slutpunkt. SOC-analytikern eskalerar via ärendeportalen. Din IT-chef sover. CFO:n får en nätfiskevarning från en bankkontakt innan den interna incidentkanalen har vaknat. Klockan 07:30 står informationssäkerhetschefen inför tre obekväma frågor.

Vem hade mandat att deklarera en incident?

Kan vi visa att MDR-leverantören hade rätt loggar, bevarade dem tillräckligt länge och säkrade bevismaterial?

Om personuppgifter har åtkommits, kan juristfunktionen klara tidsramarna för bedömning av personuppgiftsincident enligt GDPR samtidigt som driften förbereder rapportering enligt NIS2 eller DORA?

En månad senare begär den externa revisorn samma underlag, men med annan ton. MDR-leverantörens PDF-rapport är användbar, men den räcker inte. Revisorn vill se rådata för larmet, fullständiga loggfiler, eskaleringsspåret, den interna beslutsloggen, protokollet från leverantörsgranskningen och bevis för att organisationen självständigt kunde verifiera vad som inträffade.

Detta är tillsynsproblemet för MDR-leverantörer 2026. Organisationer outsourcar detektering och respons eftersom intern SOC-kapacitet är dyr, rekrytering är svår och hotaktiviteten är konstant. Men outsourcad detektering innebär inte outsourcad ansvarsskyldighet. Enligt NIS2 förblir ledningsorgan ansvariga för att godkänna och utöva tillsyn över åtgärder för hantering av cybersäkerhetsrisker. Enligt DORA förblir finansiella entiteter fullt ansvariga för IKT-tredjepartsrisk, inklusive kritiska IKT-tjänster, incidentstöd, revisionsrätt, underleverantörer och exit. Enligt GDPR måste personuppgiftsansvariga kunna visa lämplig säkerhet i behandlingen, särskilt där personuppgiftsbiträden hanterar telemetri, slutpunktsdata, användaridentifierare, IP-adresser, e-postinnehåll, loggar eller forensiska avbildningar.

Den praktiska luckan ligger sällan enbart i MDR-avtalet. Den ligger i beviskedjan mellan avtalet och den faktiska tjänsten: larmdirigering, privilegierad åtkomst, logglagring, eskaleringströsklar, incidentunderlag, transparens kring underleverantörer, biträdesklausuler, tjänstegranskningar, skrivbordsövningar och rapportering till ledningen.

Ett försvarbart program för tillsyn av MDR-leverantörer behöver en gemensam verksamhetsmodell som håller för flera revisionsdialoger. ISO/IEC 27001:2022 ger den ryggraden.

Tillsyn av MDR börjar med ansvarsskyldighet, inte med SOC-konsolen

Ett vanligt misstag är att behandla införandet av MDR som ett tekniskt projekt: driftsätta EDR-agenter, vidarebefordra identitetsloggar, konfigurera larm, komma överens om en Teams- eller Slack-kanal och gå i produktion. Det kan förbättra detekteringen, men det visar inte styrning.

NIS2 gör frågan uttrycklig. Väsentliga och viktiga entiteter ska införa lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder för hantering av cybersäkerhetsrisker. Article 21 omfattar riskanalys, incidenthantering, verksamhetskontinuitet, leveranskedjesäkerhet, cyberhygien, åtkomstkontroll, policy för tillgångshantering, kryptografi och flerfaktorsautentisering. Article 20 lyfter detta till ansvarsskyldighet på ledningsorgansnivå genom krav på godkännande och tillsyn över dessa åtgärder.

MDR-leverantörer berör ofta flera områden i NIS2 Article 21 samtidigt:

• Incidenthantering, eftersom leverantören triagerar, eskalerar och kan rekommendera begränsningsåtgärder.
• Leveranskedjesäkerhet, eftersom leverantören är en direkt tjänsteleverantör med operativ säkerhetspåverkan.
• Åtkomstkontroll, eftersom leverantören kan få åtkomst till konsoler, loggar, slutpunktsverktyg eller molntenanter.
• Loggning och övervakning, eftersom detektering beror på loggtäckning, bevarande och korrelation.
• Cyberhygien, eftersom MDR-iakttagelser ofta blottlägger svagheter i patchning, identitet eller konfiguration.
• Verksamhetskontinuitet, eftersom fördröjd respons kan störa kritiska tjänster.

För finansiella entiteter skärper DORA verksamhetsmodellen. DORA gäller från den 17 januari 2025 och kräver IKT-riskhantering, incidentrapportering, resiliensprovning, informationsdelning och IKT-riskhantering för tredje part. För finansiella entiteter som även omfattas av NIS2 klargör DORA dessutom att den fungerar som sektorsspecifik unionsrättsakt för överlappande cybersäkerhetsskyldigheter. En reglerad bank, ett betalningsinstitut, ett värdepappersföretag, ett försäkringsbolag eller en leverantör av kryptotillgångstjänster kan inte bara säga: ”Vår MDR-leverantör hanterar det.” DORA förväntar sig att entiteten klassificerar IKT-incidenter, hanterar och övervakar IKT-tredjepartsleverantörer, upprätthåller register över IKT-tjänstearrangemang, definierar avtalsrättigheter, testar resiliens, genomför rotorsaksanalys och rapporterar större IKT-relaterade incidenter stegvis.

GDPR tillför ett annat perspektiv. Om MDR-telemetri innehåller användaridentifierare, IP-adresser, e-postmetadata, autentiseringsposter, forensiska artefakter från slutpunkter eller filer som innehåller personuppgifter gäller GDPR:s principer om säkerhet och ansvarsskyldighet. Article 5 omfattar riktighet, konfidentialitet och ansvarsskyldighet. Article 32 säkerhet i behandlingen blir en praktisk fråga om underlag: skyddades loggarna, begränsades åtkomst, användes kryptering där det var lämpligt, styrdes personuppgiftsbiträden och kan organisationen visa vad som hände?

Budskapet är konsekvent i alla tre regelverken: arbetet kan delegeras, men ansvaret kan inte delegeras.

ISO/IEC 27001:2022 gör MDR till en verifierbar process

Ett väl infört ledningssystem för informationssäkerhet baserat på ISO/IEC 27001:2022 förvandlar tillsyn av MDR-leverantörer från ett löfte i leverantörshanteringen till en evidensbaserad verksamhetsmodell. Clause 8.1 är särskilt viktig eftersom den kräver att organisationer styr externt tillhandahållna processer, produkter och tjänster som är relevanta för ISMS. MDR är just detta: en externt tillhandahållen process som kan påverka incidentrespons, integritetsskydd, resiliens, regulatorisk rapportering och verksamhetskontinuitet.

De viktigaste områdena i ISO/IEC 27001:2022 Annex A för tillsyn av MDR omfattar leverantörsrelationer, säkerhetskrav i leverantörsavtal, riskhantering i IKT-leveranskedjan, övervakning av leverantörstjänster, incidenthantering, hantering av bevismaterial, loggning, övervakning, åtkomstkontroll, privilegierad åtkomst, kryptografi och beredskap för verksamhetskontinuitet.

Clarysecs Zenith Controls: The Cross-Compliance Guide Zenith Controls är referensen för tvärgående efterlevnad i detta arbete. Den mappar ISO/IEC 27002:2022-kontroller mot andra krav, relaterade kontroller, revisionsförväntningar och införandeunderlag. För tillsyn av MDR är tre ISO/IEC 27002:2022-kontroller centrala: 5.19 för leverantörsrelationer, 5.22 för övervakning av leverantörstjänster och ändringshantering samt 8.15 för loggning. Dessa stöds av 5.20 leverantörsavtal, 5.21 IKT-leveranskedjesäkerhet, 5.24 till 5.28 incidenthantering och hantering av bevismaterial, 5.34 integritetsskydd och PII, 5.36 regelefterlevnad, 8.16 övervakningsaktiviteter, 8.17 klocksynkronisering, 8.18 användning av privilegierade verktygsprogram och 8.8 hantering av tekniska sårbarheter.

Detta är viktigt eftersom ett revisionsunderkännande av MDR sällan lyder ”ingen MDR”. Det lyder oftast något av följande:

• MDR-leverantören klassificerades inte som kritisk.
• Avtalsklausulerna omfattade inte incidentanmälan, åtkomst till bevismaterial eller revisionsrätt.
• Loggar bevarades inte tillräckligt länge för att utreda en rapporterad händelse.
• Leverantörsåtkomsten var delad, permanent eller inte övervakad.
• Kunden granskade inte MDR-prestanda mot SLA:er.
• Underleverantörer eller underbiträden godkändes inte.
• Skyldigheter att anmäla personuppgiftsincident var inte anpassade till incidentarbetsflöden.
• Bevismaterial bevarades inte på ett forensiskt användbart sätt.
• Ledningen saknade mätetal som visade om MDR-tjänsten minskade risk.

Zenith Controls beskriver relationen mellan leverantörsförväntningar och avtal tydligt:

”5.19 fastställer säkerhetsförväntningarna på hur leverantörer ska hantera organisationens information. 5.20 formaliserar dessa förväntningar genom att säkerställa att kontrakt eller avtal uttryckligen innehåller säkerhetsklausuler, såsom sekretesskrav, efterlevnad av säkerhetspolicyer och rutiner för incidentanmälan. Utan 5.20 kan de krav som identifieras i 5.19 sakna avtalsvillkor som kan göras gällande.”

För MDR är denna mening styrningslärdomen. Om avtalet inte kräver att leverantören bevarar loggar, tillhandahåller bevismaterial, samarbetar vid incidenter, begränsar underleverantörer, stödjer revisioner och följer eskaleringstidsramar kan SOC-tjänsten vara operativt användbar men svag ur revisionssynpunkt.

Vad MDR-avtalet måste kunna visa före första larmet

Ett bra MDR-avtal är inte bara ett kommersiellt beställningsformulär. Det är ett kontrolldokument. DORA Articles 28 to 30 kräver att IKT-tredjepartsrisk hanteras genom hela livscykeln, inklusive register över IKT-avtal, kritikalitetsklassificering, förhandsgranskning före avtal, revisions- och inspektionsmetoder, rätt att säga upp avtalet, exitstrategier, tydliga tjänstebeskrivningar, servicenivåer, platser för tjänst och databehandling, dataskyddsåtaganden, incidentstöd och samarbete med myndigheter. NIS2 Article 21 kräver leveranskedjesäkerhet för direkta leverantörer och tjänsteleverantörer. GDPR kräver roller som personuppgiftsansvarig och personuppgiftsbiträde, garantier från personuppgiftsbiträdet, dataskyddsklausuler och underlag för säkerhet i behandlingen.

Clarysecs policybibliotek översätter dessa skyldigheter till praktiska avtals- och verksamhetskrav. I Enterprise Incident Response Policy Policy för incidenthantering behandlas MDR uttryckligen som en styrd tredjepartsförmåga för incidenter:

”Integration med tredjepartstjänster, inklusive Managed Detection and Response (MDR), Security Incident and Event Management (SIEM) och leverantörer av forensisk analys, ska styras av tydligt definierade servicenivåavtal (SLA) och sekretessbestämmelser.”

Den klausulen är viktig eftersom MDR-leverantörer ofta får mycket känslig information innan organisationen vet om en incident är rapporteringspliktig. Telemetri kan omfatta användarnamn, filsökvägar, ämnesrader i e-post, interna värdnamn, IP-adresser, nätverksdiagram och indikatorer på kompromettering. Sekretessbestämmelser skyddar organisationen under utredningen och stödjer ansvarsskyldighet enligt GDPR.

Enterprise Third party and supplier security policy Policy för leverantörssäkerhet och tredjepartssäkerhet tillför två klausuler som revisorer förväntar sig att se vid granskning av MDR-tillsyn:

”Revisionsrätt, inspektionsrätt och rätt att begära säkerhetsunderlag”

och:

”Användning av underleverantörer kräver föregående skriftligt samtycke”

För små och medelstora företag skalas samma styrningsprincip ned, men tas inte bort. Third-Party and Supplier Security Policy - SME Policy för leverantörssäkerhet och tredjepartssäkerhet – SME kräver principen om minsta privilegium:

”Leverantörer ska endast beviljas åtkomst till de system och data som minst krävs för att utföra sin funktion.”

Den kräver även:

”Begränsningar av vidare underleverantörskap utan godkännande”

Dessa klausuler är särskilt relevanta för MDR. Många leverantörer använder nivåindelade SOC-team, plattformsleverantörer, partner för hotinformation, molnbaserade analystjänster eller regional supportpersonal. Om nedströmsparter kan få åtkomst till kundloggar eller personuppgifter behöver kunden insyns- och godkännandemekanismer. I DORA-termer är detta en del av tillsynen över underleverantörer och koncentrationsrisk. I GDPR-termer är det styrning av underbiträden. I NIS2-termer är det riskhantering i leveranskedjan.

Den grundläggande checklistan för MDR-tillsyn

En försvarbar relation med en MDR-leverantör ska kunna testas. Följande checklista kombinerar avtalsmässiga, operativa och evidensrelaterade krav i en samlad kontrollvy.

Denna checklista bör byggas in i upphandling, onboarding, periodisk granskning och incidenttestning. Om någon punkt saknas ska organisationen behandla det som en leverantörsrisk, inte som ett dokumentationsproblem.

Sju underlagsdomäner som revisorer förväntar sig

För att göra MDR-tillsyn revisionsklar rekommenderar Clarysec att en MDR-underlagsfil byggs upp i sju domäner. Filen ska ligga i ISMS, inte i en upphandlingsmapp som ingen granskar.

Tabellen förändrar dialogen med leverantören. I stället för att fråga ”övervakar ni oss?” frågar organisationen: ”Kan vi varje kvartal visa att MDR-tjänsten fortsatt är effektiv, uppfyller krav och är anpassad till vår riskaptit?”

Loggning är bryggan mellan detektering och efterlevnadsunderlag

MDR utan tillförlitlig loggning är outsourcad gissning. Leverantören kan upptäcka vissa hot, men organisationen kan inte visa omfattning, tidslinje, rotorsak eller konsekvens.

ISO/IEC 27002:2022 control 8.15 behandlar loggning. Zenith Controls klassificerar loggning som en detekterande kontroll som stödjer konfidentialitet, riktighet och tillgänglighet, i linje med cybersäkerhetskonceptet Detect och förmågan för hantering av informationssäkerhetshändelser. Den kopplar loggning direkt till övervakningsaktiviteter, händelsebedömning, incidentrespons, erfarenhetsåterföring, privilegierad åtkomst, klocksynkronisering, åtkomstkontroll, integritetsskydd, insamling av bevismaterial, hantering av sårbarheter och övervakning av fysisk säkerhet.

Därför är loggning central för underlag enligt NIS2, DORA och GDPR Article 32. NIS2 Article 23-rapportering för betydande incidenter kräver tidig varning inom 24 timmar från medvetenhet, avisering inom 72 timmar och en slutrapport senast en månad efter aviseringen. DORA-rapportering av större IKT-relaterade incidenter kräver klassificering, eskalering, kommunikation, rotorsaksanalys och slutrapportering. GDPR:s ansvarsskyldighet kräver att organisationer visar vad som inträffade med personuppgifter och om säkerhetsåtgärderna var lämpliga.

Clarysecs Logging and Monitoring Policy - SME Loggnings- och övervakningspolicy – SME ger en enkel avtalsmässig kontroll för mindre organisationer som använder externa leverantörer:

”Avtal ska kräva att leverantörer bevarar loggar i minst 12 månader och tillhandahåller åtkomst på begäran”

För verksamhetsmiljöer på enterprise-nivå lägger Logging and Monitoring Policy Loggnings- och övervakningspolicy till kravet på operativ integration:

”Ska tillhandahålla loggdata på begäran eller integrera med organisationens SIEM-/loggaggregeringsplattform.”

Dessa klausuler löser ett återkommande problem inom incidentrespons: under en utredning säger MDR-leverantören att händelsen är äldre än det sökbara bevarandefönstret, att loggar endast är tillgängliga via en betald forensisk export eller att kundens SIEM saknar leverantörens enrichments och analytikeråtgärder. Om loggåtkomst inte definieras i förväg blir incidentens tidslinje fragmenterad.

En stark MDR-loggningsmodell ska definiera obligatoriska loggkällor, händelsetyper, bevarandeperioder, integritetsskydd, åtkomstgodkännanden, tidssynkronisering, exportformat och korrelationsregler mellan kundens och leverantörens plattformar. Den ska även omfatta leverantörsåtgärder, inklusive ändringar av detekteringsregler, kommandon för isolering av slutpunkter, administrationsåtkomst, analytikeranteckningar och export av bevismaterial.

Stödjande ISO-standarder förstärker detta angreppssätt. ISO/IEC 27035-1:2023 och ISO/IEC 27035-2:2023 kopplar loggning till incidentdetektering, triagering och centraliserad analys. ISO/IEC 27701:2021 tillför integritetsspecifik loggning av behandlingsaktiviteter för PII. ISO/IEC 27017:2021 och ISO/IEC 27018:2020 tillför förväntningar på loggning i moln och av PII i moln, särskilt där leverantörer behandlar kunddata i publika molnmiljöer. ISO/IEC 27005:2024 behandlar otillräcklig loggning som en fråga om riskbehandling, inte enbart som en verktygslucka.

Incidentrespons: MDR kan eskalera, men ledningen måste besluta

MDR-leverantörer detekterar och ger råd. Den ansvariga organisationen deklarerar incidenter, bedömer regulatorisk påverkan, kommunicerar med myndigheter och beslutar om anmälan av personuppgiftsincident krävs.

Denna distinktion är viktig eftersom MDR-allvarlighetsgrad inte automatiskt motsvarar en betydande NIS2-incident, en större IKT-relaterad incident enligt DORA eller en personuppgiftsincident enligt GDPR. Leverantören kan märka ett larm som ”hög allvarlighetsgrad”, men organisationen måste besluta om kritiska tjänster påverkades, om personuppgifter komprometterades, om kunder måste underrättas, om tillsynsmyndigheter måste informeras och om ledningen måste godkänna en begränsningsåtgärd med operativ påverkan.

Clarysecs Incident Response Policy - SME Policy för incidenthantering – SME är tydlig:

”Tredje parter ska agera i enlighet med undertecknade avtal, som ska innehålla klausuler om anmälan av personuppgiftsincident och samarbetsförpliktelser vid respons.”

Denna klausul är där underlag enligt GDPR Article 32 möter operativ incidentrespons. Om MDR-leverantören observerar misstänkt dataexfiltration från en slutpunkt som innehåller personuppgifter måste leverantören veta hur snabbt underrättelse ska ske, vem som ska underrättas, vilket bevismaterial som ska bevaras och hur den personuppgiftsansvariges bedömning ska stödjas.

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint ger testmetoden. I fasen Controls in Action, Step 19, instruerar Zenith Blueprint team att validera loggning och övervakning operativt:

”Välj en nylig incident eller händelse och visa hur ni spårade den med hjälp av era loggar. Om funktioner för loggintegritet används (t.ex. hashverifiering), dokumentera även detta. Bekräfta att larmning fungerar (t.ex. att misslyckade inloggningar eller privilegiehöjningar utlöser larm).”

Samma steg behandlar identitet och privilegierad åtkomst:

”För privilegierade konton, verifiera att MFA tillämpas, att administratörsroller är separerade (konton i stil med admin_john används endast för administrativa uppgifter) och att det finns en aktuell lista över privilegierade användare.”

I MDR-sammanhang måste listan över privilegierade användare omfatta leverantörskonton, inte bara anställda. Om MDR-leverantören har konsolåtkomst, rätt att isolera slutpunkter, EDR-administrationsrättigheter eller läsåtkomst till känsliga loggar hör dessa konton hemma i granskningen.

Step 23 i Zenith Blueprint ger därefter teststrukturen för incident och leverantör:

”Välj en nylig händelse eller genomför en skrivbordsövning för att validera er plan. Fånga och logga alla beslut, roller och kommunikationer (5.26), och uppdatera planen med erfarenhetsåterföring (5.27). Bekräfta att rutiner finns för att bevara forensisk bevisning (5.28), inklusive ögonblicksbilder av loggar, säkerhetskopior och säker isolering av påverkade system.”

En realistisk skrivbordsövning bör omfatta MDR-leverantören. Använd ett scenario såsom komprometterat privilegierat konto, isolering av slutpunkt, misstänkt åtkomst till brevlåda, möjlig exponering av löneuppgifter och larmeskalering utanför kontorstid. Testet bör verifiera om MDR-leverantörens klocka börjar gå vid detektering, kundavisering eller kundens bekräftelse. Den distinktionen är viktig när regulatoriska tidsramar beror på medvetenhet och beslutspunkter.

Bygg ett MDR-tillsynspaket för ett larm på 90 minuter

Ett snabbt sätt att synliggöra luckor är att välja ett nyligt MDR-larm med hög allvarlighetsgrad och bygga ett ensidigt revisionsspår för underlaget. Denna praktiska övning fungerar väl före revisioner, styrelsegranskningar och avtalsförnyelser.

1. Börja med larmärendet. Fånga tidsstämpel, detekteringsregel, påverkad tillgång, användare, allvarlighetsgrad, MDR-analytikerns anteckningar och eskaleringsväg.
2. Ta fram avtalsklausulen eller SLA:t som visar förväntad svarstid för den allvarlighetsgraden.
3. Hämta listan över loggkällor som visar vilka system som matade larmet, till exempel EDR, identitetsleverantör, brandvägg, e-postsäkerhetsgateway och molnbaserade revisionsloggar.
4. Bekräfta att loggar bevaras enligt policy och att den historiska händelsen fortfarande kan hämtas.
5. Verifiera om MDR-analytikern fick åtkomst till någon kundmiljö. Om ja, fånga det namngivna kontot, MFA-underlag, sessionsloggar och godkännande.
6. Dokumentera kundens beslut: händelse stängd, incident deklarerad, juridisk bedömning initierad, begränsning genomförd eller risk accepterad.
7. Om personuppgifter kan vara berörda, registrera GDPR-rollanalysen, ägaren till incidentbedömningen och om personuppgiftsbiträdets underrättelseskyldigheter utlöstes.
8. Avsluta med erfarenhetsåterföring: justering, ny detektering, åtkomständring, uppdatering av åtgärdsplan eller SLA-fråga gentemot leverantören.

Detta spår för ett enda larm är kraftfullt eftersom det kopplar samman avtal, loggning, åtkomst, incidentrespons, integritetsskydd och ledningstillsyn i en och samma beviskedja. Om ni inte kan bygga det för ett nyligt larm kan ni sannolikt inte bygga det under regulatorisk press.

Leverantörsövervakning är där de flesta MDR-program försvagas

Många organisationer genomför leverantörsgranskning innan de skriver under ett MDR-avtal och stannar sedan där. Det räcker inte för ISO/IEC 27001:2022, NIS2, DORA eller GDPR. MDR-tjänster förändras kontinuerligt: nya detekteringsregler, nya analytikerteam, nya underbiträden, nya dataregioner, nya EDR-förmågor, nya integrationer, nya flöden för hotinformation och nya supportmodeller.

ISO/IEC 27002:2022 control 5.22 behandlar övervakning, granskning och ändringshantering av leverantörstjänster. Zenith Controls förklarar att 5.22 bygger vidare på kontroller för leverantörsrelationer och avtal genom att säkerställa kontinuerlig övervakning och hantering efter att tjänsten inletts. Den kopplar till säkerhet under störningar, hantering av sårbarheter, regelefterlevnad, åtkomstkontroll och säker utveckling.

DORA Articles 28 to 30 gör detta särskilt viktigt för finansiella entiteter. De kräver löpande övervakning, register över IKT-tredjepartsarrangemang, kritikalitetsdistinktioner, leverantörsgranskning, revisions- och inspektionsrätt, rätt att säga upp avtalet, exitstrategier, servicenivåer, incidentstöd, samarbete med myndigheter och, för kritiska eller viktiga funktioner, tjänstemål, beredskapstestning och samarbete vid hotstyrd penetrationstestning där det är relevant.

Zenith Blueprint, fasen Controls in Action, Step 23, ger strukturen för leverantörslivscykeln:

”Sammanställ en fullständig lista över nuvarande leverantörer och tjänsteleverantörer (5.19), och klassificera dem baserat på åtkomst till system, data eller operativ kontroll.”

Den fortsätter:

”För varje kritisk leverantör, identifiera om de använder underleverantörer (underbiträden) som kan få åtkomst till era data eller system.”

En praktisk granskning av MDR-tjänsten bör hållas kvartalsvis för kritiska miljöer och minst årligen för miljöer med lägre risk. Agendan bör omfatta SLA-efterlevnad per allvarlighetsgrad, eskalerade larm, sanna positiva, falska positiva, missade eskaleringar, status för loggkällor, ändringar i privilegierad åtkomst, nya integrationer, nya regioner, underleverantörer, underbiträden, ändringar av detekteringsregler, incidentstödsförmåga, begäranden om underlag, öppna risker, korrigerande åtgärder och exitberedskap.

Detta är inte detaljstyrning. Det är säkerhetssäkringsloopen som visar att organisationen aktivt styr en kritisk säkerhetsleverantör.

Tvärgående efterlevnadsmappning: en MDR-kontrolluppsättning, fem revisionsdialoger

Värdet med ISO/IEC 27001:2022 är att den ger organisationer en sammanhängande ISMS-cykel för flera efterlevnadsdialoger. Samma MDR-tillsynspaket med underlag kan mappas mot NIS2, DORA, GDPR, NIST CSF 2.0 och COBIT 2019.

NIST CSF 2.0 är användbart för kommunikation. Funktionen GOVERN kräver att rättsliga, regulatoriska, avtalsmässiga och integritetsrelaterade skyldigheter förstås och hanteras, att roller och befogenheter definieras, att cybersäkerhetsrisk integreras i organisationens riskhantering och att leverantörsrisker kommuniceras och övervakas.

COBIT 2019 är användbart för ledning och kontrollsäkring. COBIT-inriktade revisorer fokuserar ofta mindre på en enskild kontroll och mer på om styrningsmål, tjänstehantering, riskägarskap och prestationsövervakning fungerar som ett system.

Hur revisorer testar tillsyn av MDR-leverantörer

Olika revisorer använder olika perspektiv, men alla vill se underlag som visar att organisationen styr relationen.

En ISO/IEC 27001:2022-revisor börjar med omfattning, intressenter, riskbedömning, Statement of Applicability, riskbehandlingsplan och operativt underlag. Om MDR ingår i omfattningen förväntar sig revisorn att externt tillhandahållna processer styrs inom ISMS. Revisorn kan ta stickprov på leverantörsrelationer, leverantörsavtal, övervakning av leverantörstjänster, loggning, övervakning, incidentrespons, hantering av bevismaterial och åtkomstkontroll.

En DORA-tillsynsmyndighet fokuserar på operativ resiliens och systemrisk. Den kan granska kritikalitetsbedömningen, IKT-tjänsteregistret, analysen av koncentrationsrisk, exitstrategin, incidentklassificeringen, revisionsrätt och underlag som visar att MDR-leverantören kan stödja regulatorisk rapportering.

En GDPR-revisor eller integritetsgranskare fokuserar på styrning mellan personuppgiftsansvarig och personuppgiftsbiträde. De begär personuppgiftsbiträdesavtalet, leverantörsgranskning av personuppgiftsbiträdet, kontroller för underbiträden, skyddsåtgärder för loggar som innehåller personuppgifter, kontroller för bevarande, poster från bedömning av personuppgiftsincident och underlag som stödjer Article 32.

En COBIT- eller ISACA-revisor granskar styrningsunderlag: ägarskap för leverantörsrisk, upphandlingsarbetsflöde, protokoll från tjänstegranskningar, uppföljning av SLA-problem, korrigerande åtgärder, kvalitet på underlag och om ledningen får meningsfulla mätetal.

Den mest avslöjande revisionsbegäran är enkel: ”Visa mig ett MDR-larm från detektering till stängning.” Om ni kan visa avtalsförväntan, loggkälla, larm, eskalering, beslut, bevarande av bevismaterial, integritetsbedömning, åtgärdande och ledningsrapportering är er MDR-tillsyn mogen. Om ni bara kan visa ett leverantörsärende har ni övervakning men svag styrning.

Ledningsrapportering: styrelsen behöver inte paketfångster

Både NIS2 och DORA placerar ansvaret på ledningsorgansnivå. Styrelser och ledande befattningshavare behöver inte rå telemetri. De behöver riskrelevanta mätetal för MDR-tillsyn.

En användbar kvartalsvis MDR-panel omfattar:

• Kritiska loggkällor som har anslutits jämfört med förväntat.
• Andel kritiska tillgångar som omfattas av MDR.
• Larm med hög allvarlighetsgrad per kategori och verksamhetstjänst.
• Genomsnittlig tid från detektering till kundavisering.
• Genomsnittlig tid från kundens bekräftelse till beslut.
• SLA-överträdelser och olösta leverantörsåtgärder.
• Status för granskning av privilegierade leverantörskonton.
• Ändringar av underleverantörer eller underbiträden.
• Incidenter som kräver juridisk, regulatorisk eller kundrelaterad underrättelsebedömning.
• Genomförd erfarenhetsåterföring.

Denna panel bör mata ledningens genomgång av ISMS, uppdateringar av riskbehandling och leverantörsgranskning. Enligt ISO/IEC 27001:2022 ska ledningen säkerställa att ISMS är anpassat till strategisk inriktning, att resurser finns tillgängliga, att ansvar tilldelas, att kommunikation fungerar och att ständig förbättring sker. MDR-mätetal är ett praktiskt sätt att visa att outsourcad säkerhetsdrift styrs av ledningen och inte lämnas åt verktygsadministratörer.

Vanliga brister i MDR-tillsyn att åtgärda före revisionerna 2026

De vanligaste luckorna är vanliga styrningsbrister.

För det första glömmer organisationer att MDR-leverantörer kan behandla personuppgifter. Säkerhetsloggar behandlas ibland som ”tekniska data”, men de kan innehålla personuppgifter och ibland känsligt innehåll. GDPR-rollanalys och biträdesklausuler ska vara klara före onboarding, inte under en incident.

För det andra antas logglagring i stället för att avtalas. Om regulatoriska, forensiska eller kundrelaterade skyldigheter kräver bevismaterial i månader måste modellen för bevarande i MDR och SIEM stödja detta. SME-policykravet på 12 månaders logglagring hos leverantör är en praktisk baslinje för många miljöer.

För det tredje är tredjepartsåtkomst för generös. Leverantörskonton ska vara namngivna, MFA-skyddade, övervakade, granskade och tidsbegränsade där det är möjligt. Delade konton och ohanterade administrativa sessioner skapar revisions- och incidentresponsrisk.

För det fjärde är incidenttrösklar otydliga. MDR-allvarlighetsgrad motsvarar inte automatiskt en juridisk incident, en större IKT-relaterad incident enligt DORA, en betydande NIS2-incident eller en personuppgiftsincident enligt GDPR. Åtgärdsplanen måste definiera vem som fattar varje beslut.

För det femte är underleverantörer osynliga. Om MDR-leverantören byter analysplattformar, supportregioner eller nedströmsbiträden förändras kundens riskbild. Föregående skriftligt samtycke och periodisk granskning är nödvändiga.

För det sjätte fokuserar tjänstegranskningar bara på ärendevolym. Mogna granskningar undersöker missade larm, justeringsändringar, status för loggkällor, hämtning av bevismaterial, leverantörsåtkomst, incidentsamarbete och avtalsförpliktelser.

Nästa steg: gör din MDR-leverantör redo för revision med Clarysec

Om din MDR-leverantör redan är i drift, vänta inte på att en tillsynsmyndighet, kundrevisor eller incident ska upptäcka att ert underlag är ofullständigt. Börja med ett nyligt larm och bygg spåret. Klassificera därefter leverantören, granska avtalet, validera loggning, testa eskalering, bekräfta biträdesklausuler, granska åtkomst och schemalägg leverantörsövervakning.

Clarysec kan hjälpa er att operationalisera detta snabbt med:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint för stegvis införande, inklusive Step 19 för validering av loggning, övervakning och åtkomst, samt Step 23 för kontroller inom leverantörs- och incidenthantering.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls för att mappa ISO/IEC 27002:2022-kontrollerna 5.19, 5.22 och 8.15 mot revisionsförväntningar i NIS2, DORA, GDPR, NIST och COBIT.
• Clarysecs policymallar, inklusive Policy för incidenthantering, Policy för leverantörssäkerhet och tredjepartssäkerhet, Loggnings- och övervakningspolicy, Policy för incidenthantering – SME, Policy för leverantörssäkerhet och tredjepartssäkerhet – SME, Loggnings- och övervakningspolicy – SME och Policy för dataskydd och integritet – SME.

MDR är en av de mest värdefulla säkerhetsinvesteringar en organisation kan göra. År 2026 måste det värdet bevisas genom styrning, underlag och ansvarstagande tillsyn. Om ni vill ha ett praktiskt MDR-tillsynspaket mappat mot ISO/IEC 27001:2022, NIS2, DORA och GDPR Article 32 kan Clarysec hjälpa er att bygga det innan nästa larm blir nästa revisionsiakttagelse.