Tilsyn med MDR-leverandører i henhold til NIS2, DORA og GDPR

Kl. 02:13 en mandag morgen opretter MDR-leverandøren en alarm med høj alvorlighed: umulig rejse, mistænkelige postkasseregler og en privilegeret konto anvendt fra et ikke-administreret endpoint. SOC-analytikeren eskalerer via sagsportalen. Den IT-ansvarlige sover. CFO’en modtager en phishing-advarsel fra en bankkontakt, før den interne hændelseskanal vågner. Kl. 07:30 står CISO’en med tre ubehagelige spørgsmål.

Hvem havde bemyndigelse til at erklære en hændelse?

Kan vi dokumentere, at MDR-leverandøren havde de rigtige logfiler, opbevarede dem længe nok og bevarede bevismateriale?

Hvis personoplysninger blev tilgået, kan juridisk afdeling overholde tidsfristerne for GDPR-vurdering af brud på persondatasikkerheden, mens drift forbereder NIS2- eller DORA-rapportering?

En måned senere efterspørger den eksterne revisor det samme revisionsbevis med en anden tone. MDR-leverandørens PDF-rapport er nyttig, men den er ikke tilstrækkelig. Revisoren ønsker rå alarmdata, komplette logfiler, eskaleringssporet, den interne beslutningslog, leverandørgennemgangsregistreringen og dokumentation for, at organisationen uafhængigt kunne verificere, hvad der skete.

Det er udfordringen ved tilsyn med MDR-leverandører i 2026. Organisationer outsourcer detektion og respons, fordi intern SOC-kapacitet er dyr, rekruttering er vanskelig, og trusselsaktiviteten er konstant. Men outsourcet detektion betyder ikke outsourcet ansvarlighed. Under NIS2 er ledelsesorganer fortsat ansvarlige for at godkende og føre tilsyn med foranstaltninger til styring af cybersikkerhedsrisici. Under DORA er finansielle enheder fortsat fuldt ansvarlige for IKT-tredjepartsrisiko, herunder kritiske IKT-tjenester, hændelsesstøtte, revisionsrettigheder, underleverancer og exit. Under GDPR skal dataansvarlige kunne dokumentere passende behandlingssikkerhed, især hvor databehandlere håndterer telemetri, endpoint-data, brugeridentifikatorer, IP-adresser, e-mailindhold, logfiler eller forensiske images.

Det praktiske hul ligger sjældent kun i MDR-kontrakten. Det ligger i beviskæden mellem kontrakten og den aktive tjeneste: alarmrouting, privilegeret adgang, logopbevaring, eskaleringstærskler, hændelsesbevismateriale, gennemsigtighed om underleverandører, databehandlerklausuler, servicegennemgange, tabletop-øvelser og ledelsesrapportering.

Et forsvarligt program for tilsyn med MDR-leverandører kræver én driftsmodel, der kan understøtte flere revisionsdialoger. ISO/IEC 27001:2022 leverer rygraden.

Tilsyn med MDR starter med ansvarlighed, ikke SOC-konsollen

En almindelig fejl er at behandle onboarding af MDR som et teknisk projekt: udrul EDR-agenter, videresend identitetslogfiler, konfigurer alarmer, aftal en Teams- eller Slack-kanal, og sæt løsningen i drift. Det kan forbedre detektionen, men det dokumenterer ikke governance.

NIS2 gør problemstillingen eksplicit. Væsentlige og vigtige enheder skal implementere passende og forholdsmæssige tekniske, operationelle og organisatoriske foranstaltninger til styring af cybersikkerhedsrisici. Article 21 omfatter risikoanalyse, hændelseshåndtering, forretningskontinuitet, sikkerhed i forsyningskæden, cyberhygiejne, adgangsstyring, aktivstyring, kryptografi og multifaktorgodkendelse. Article 20 løfter dette til ledelsesorganets ansvarlighed og kræver godkendelse af og tilsyn med disse foranstaltninger.

MDR-leverandører berører ofte flere NIS2 Article 21-områder samtidig:

• Hændelseshåndtering, fordi leverandøren triagerer, eskalerer og kan anbefale inddæmning.
• Sikkerhed i forsyningskæden, fordi leverandøren er en direkte tjenesteudbyder med indvirkning på den operationelle sikkerhed.
• Adgangsstyring, fordi leverandøren kan tilgå konsoller, logfiler, endpoint-værktøjer eller cloud-tenants.
• Logning og overvågning, fordi detektion afhænger af logdækning, opbevaring og korrelation.
• Cyberhygiejne, fordi MDR-konstateringer ofte afdækker svagheder i patching, identitet eller konfiguration.
• Forretningskontinuitet, fordi forsinket respons kan forstyrre kritiske tjenester.

For finansielle enheder skærper DORA driftsmodellen. DORA finder anvendelse fra 17. januar 2025 og kræver styring af IKT-risiko, rapportering af hændelser, robusthedstest, informationsdeling og styring af IKT-tredjepartsrisiko. DORA præciserer også, at DORA fungerer som den sektorspecifikke EU-retsakt for overlappende cybersikkerhedsforpligtelser for finansielle enheder, der også er identificeret under NIS2. En reguleret bank, betalingsinstitution, investeringsvirksomhed, forsikringsvirksomhed eller udbyder af kryptoaktivtjenester kan ikke blot sige: “Det håndterer vores MDR-leverandør.” DORA forventer, at enheden klassificerer IKT-hændelser, styrer og overvåger IKT-tredjepartsudbydere, vedligeholder registre over IKT-tjenesteaftaler, definerer kontraktlige rettigheder, tester robusthed, udfører rodårsagsanalyse og rapporterer større IKT-relaterede hændelser trinvist.

GDPR tilføjer en anden vinkel. Hvis MDR-telemetri omfatter brugeridentifikatorer, IP-adresser, e-mailmetadata, autentifikationsoptegnelser, endpoint-artefakter eller filer med personoplysninger, finder GDPR’s principper om sikkerhed og ansvarlighed anvendelse. Article 5 omfatter integritet, fortrolighed og ansvarlighed. Article 32 om behandlingssikkerhed bliver et praktisk spørgsmål om revisionsbevis: var logfiler beskyttet, var adgang begrænset, blev kryptering anvendt, hvor det var relevant, var databehandlere styret, og kan organisationen dokumentere, hvad der skete?

Budskabet er det samme på tværs af alle tre regelsæt: I kan delegere arbejdet, men I kan ikke delegere ansvaret.

ISO/IEC 27001:2022 gør MDR til en revisionsbar proces

Et velfungerende ISMS baseret på ISO/IEC 27001:2022 gør tilsyn med MDR-leverandører til en evidensbaseret driftsmodel i stedet for et løfte i leverandørstyringen. Klausul 8.1 er særligt vigtig, fordi den kræver, at organisationer styrer eksternt leverede processer, produkter og tjenester, der er relevante for ISMS’et. MDR er netop dette: en eksternt leveret proces, der kan påvirke hændelseshåndtering, databeskyttelse, robusthed, regulatorisk rapportering og forretningskontinuitet.

De vigtigste områder i ISO/IEC 27001:2022 Annex A for tilsyn med MDR omfatter leverandørrelationer, sikkerhedskrav i leverandøraftaler, styring af IKT-forsyningskæderisiko, overvågning af leverandørydelser, hændelsesstyring, håndtering af bevismateriale, logning, overvågning, adgangsstyring, privilegeret adgang, kryptografi og beredskab for forretningskontinuitet.

Clarysecs Zenith Controls: The Cross-Compliance Guide Zenith Controls er referencegrundlaget for dette arbejde på tværs af efterlevelseskrav. Den kortlægger ISO/IEC 27002:2022-kontroller til andre krav, relaterede kontroller, revisionsforventninger og implementeringsbevis. For tilsyn med MDR er tre ISO/IEC 27002:2022-kontroller centrale: 5.19 for leverandørrelationer, 5.22 for overvågning af leverandørydelser og ændringsstyring samt 8.15 for logning. De understøttes af 5.20 leverandøraftaler, 5.21 IKT-sikkerhed i forsyningskæden, 5.24 til 5.28 hændelsesstyring og håndtering af bevismateriale, 5.34 privatliv og personhenførbare oplysninger (PII), 5.36 efterlevelse, 8.16 overvågningsaktiviteter, 8.17 synkronisering af systemtid, 8.18 brug af privilegerede hjælpeprogrammer og 8.8 styring af tekniske sårbarheder.

Det er vigtigt, fordi en revisionskonstatering vedrørende MDR sjældent siger “ingen MDR”. Den siger typisk et af følgende:

• MDR-leverandøren var ikke klassificeret som kritisk.
• Kontraktklausuler omfattede ikke hændelsesunderretning, adgang til bevismateriale eller revisionsrettigheder.
• Logfiler blev ikke opbevaret længe nok til at undersøge en rapporteret hændelse.
• Leverandøradgang var delt, vedvarende eller ikke overvåget.
• Kunden gennemgik ikke MDR-performance i forhold til SLA’er.
• Underleverandører eller underdatabehandlere var ikke godkendt.
• Forpligtelser vedrørende underretning om brud på persondatasikkerheden var ikke tilpasset hændelsesarbejdsgange.
• Bevismateriale blev ikke bevaret på en forensisk anvendelig måde.
• Ledelsen havde ingen metrikker, der viste, om MDR-tjenesten reducerede risiko.

Zenith Controls beskriver forholdet mellem leverandørforventninger og aftaler tydeligt:

“5.19 fastlægger sikkerhedsforventningerne til, hvordan leverandører skal håndtere organisationens oplysninger. 5.20 formaliserer disse forventninger ved at sikre, at kontrakter eller aftaler udtrykkeligt indeholder sikkerhedsklausuler, såsom fortrolighedskrav, overholdelse af sikkerhedspolitikker og procedurer for hændelsesunderretning. Uden 5.20 er kravene identificeret i 5.19 muligvis ikke juridisk bindende.”

For MDR er denne sætning styringslæren. Hvis kontrakten ikke kræver, at leverandøren opbevarer logfiler, leverer bevismateriale, samarbejder ved hændelser, begrænser underleverancer, understøtter revisioner og følger eskaleringsfrister, kan SOC-tjenesten være operationelt nyttig, men revisionsmæssigt svag.

Hvad MDR-kontrakten skal dokumentere før den første alarm

En god MDR-kontrakt er ikke blot en kommerciel ordrebekræftelse. Den er et kontroldokument. DORA Articles 28 to 30 kræver, at IKT-tredjepartsrisiko styres gennem hele livscyklussen, herunder registre over IKT-kontrakter, kritikalitetsklassificering, due diligence før kontraktindgåelse, revisions- og inspektionstilgange, opsigelsesrettigheder, exitstrategier, klare tjenestebeskrivelser, serviceniveauer, lokationer for tjenesten og databehandlingen, databeskyttelsesforpligtelser, hændelsesbistand og samarbejde med myndigheder. NIS2 Article 21 kræver sikkerhed i forsyningskæden for direkte leverandører og tjenesteudbydere. GDPR kræver roller for dataansvarlige og databehandlere, garantier fra databehandlere, databeskyttelsesklausuler og bevis for behandlingssikkerhed.

Clarysecs politikbibliotek omsætter disse forpligtelser til praktiske kontrakt- og driftskrav. I Enterprise Incident Response Policy Incident Response Policy behandles MDR eksplicit som en styret tredjepartskapacitet for hændelser:

“Integration med tredjepartstjenester, herunder Managed Detection and Response (MDR), Security Incident and Event Management (SIEM) og udbydere af forensisk analyse, skal styres af klart definerede serviceniveauaftaler (SLA’er) og bestemmelser om fortrolighed.”

Denne klausul er vigtig, fordi MDR-leverandører ofte modtager meget følsomme oplysninger, før organisationen ved, om en hændelse er rapporteringspligtig. Telemetri kan omfatte brugernavne, filstier, e-mailemner, interne værtsnavne, IP-adresser, netværksdiagrammer og kompromitteringsindikatorer. Fortrolighedsbestemmelser beskytter organisationen under undersøgelsen og understøtter ansvarlighed efter GDPR.

Enterprise Third party and supplier security policy Third party and supplier security policy tilføjer to klausuler, som revisorer forventer at se ved gennemgang af tilsyn med MDR:

“Ret til at revidere, inspicere og anmode om sikkerhedsbevis”

og:

“Brug af underleverandører betinget af forudgående skriftligt samtykke”

For SMV’er skaleres det samme styringsprincip ned, men fjernes ikke. Third-Party and Supplier Security Policy - SME Third-Party and Supplier Security Policy - SME kræver mindst mulige rettigheder:

“Leverandører må kun tildeles adgang til de minimumssystemer og data, der kræves for at udføre deres funktion.”

Den kræver også:

“Begrænsninger for yderligere underleverancer uden godkendelse”

Disse klausuler er særligt relevante for MDR. Mange leverandører anvender SOC-teams i flere niveauer, platformsleverandører, partnere inden for trusselsintelligens, cloudbaserede analysetjenester eller regionalt supportpersonale. Hvis efterfølgende parter kan tilgå kundelogfiler eller personoplysninger, har kunden behov for gennemsigtighed og godkendelsesmekanismer. I DORA-termer er dette en del af tilsynet med underleverancer og koncentrationsrisiko. I GDPR-termer er det styring af underdatabehandlere. I NIS2-termer er det risikostyring i forsyningskæden.

Den centrale tjekliste for tilsyn med MDR

Et forsvarligt leverandørforhold for MDR skal kunne testes. Følgende tjekliste samler kontraktlige, operationelle og evidensmæssige krav i ét kontrolbillede.

Denne tjekliste bør indarbejdes i indkøb, onboarding, periodisk gennemgang og test af hændelseshåndtering. Hvis et punkt mangler, bør organisationen behandle det som en leverandørrisiko, ikke som et dokumentationsproblem.

Syv evidensdomæner, som revisorer forventer

For at gøre tilsyn med MDR klar til revision anbefaler Clarysec at etablere en MDR-evidensmappe organiseret i syv domæner. Denne mappe bør ligge i ISMS’et, ikke i en indkøbsmappe, som ingen gennemgår.

Denne tabel ændrer dialogen med leverandøren. I stedet for at spørge: “Overvåger I os?” spørger organisationen: “Kan vi hvert kvartal dokumentere, at MDR-tjenesten fortsat er effektiv, efterlever kravene og er tilpasset vores risikovillighed?”

Logning er broen mellem detektion og revisionsbevis for efterlevelse

MDR uden pålidelig logning er outsourcet gætværk. Leverandøren kan detektere nogle trusler, men organisationen kan ikke dokumentere omfang, tidslinje, rodårsag eller konsekvens.

ISO/IEC 27002:2022-kontrol 8.15 dækker logning. Zenith Controls klassificerer logning som en detektiv kontrol, der understøtter fortrolighed, integritet og tilgængelighed, er tilpasset cybersikkerhedskonceptet Detect og kapabiliteten til styring af informationssikkerhedshændelser. Den knytter logning direkte til overvågningsaktiviteter, hændelsesvurdering, hændelseshåndtering, erfaringer, privilegeret adgang, synkronisering af systemtid, adgangsstyring, privatliv, indsamling af bevismateriale, sårbarhedsstyring og overvågning af fysisk sikring.

Derfor er logning central for revisionsbevis efter NIS2, DORA og GDPR Article 32. NIS2 Article 23-rapportering for væsentlige hændelser kræver tidlig varsling inden for 24 timer efter kendskab, underretning inden for 72 timer og en slutrapport senest én måned efter underretningen. DORA-rapportering af større IKT-relaterede hændelser kræver klassificering, eskalering, kommunikation, rodårsagsanalyse og slutrapportering. GDPR’s ansvarlighed kræver, at organisationer dokumenterer, hvad der skete med personoplysninger, og om sikkerhedsforanstaltningerne var passende.

Clarysecs Logging and Monitoring Policy - SME Logging and Monitoring Policy - SME giver en enkel kontraktlig kontrol for mindre organisationer, der anvender eksterne udbydere:

“Kontrakter skal kræve, at udbydere opbevarer logfiler i mindst 12 måneder og giver adgang efter anmodning”

For enterprise-miljøer tilføjer Logging and Monitoring Policy Logging and Monitoring Policy kravet om operationel integration:

“Skal levere logdata efter anmodning eller integrere med organisationens SIEM-/logaggregeringsplatform.”

Disse klausuler løser et tilbagevendende problem i hændelseshåndtering: Under en undersøgelse siger MDR-leverandøren, at hændelsen er ældre end det søgbare opbevaringsvindue, at logfiler kun er tilgængelige via en betalt forensisk eksport, eller at kundens SIEM ikke indeholder leverandørens berigelse og analytikerhandlinger. Hvis adgang til logfiler ikke er defineret på forhånd, bliver hændelsestidslinjen fragmenteret.

En stærk MDR-logningsmodel bør definere obligatoriske logkilder, hændelsestyper, opbevaringsperioder, integritetsbeskyttelse, adgangsgodkendelser, tidssynkronisering, eksportformater og korrelationsregler mellem kundens og leverandørens platforme. Den bør også omfatte leverandørhandlinger, herunder ændringer i detektionsregler, kommandoer til endpoint-isolering, administratoradgang, analytikernoter og eksport af bevismateriale.

Understøttende ISO-standarder forstærker denne tilgang. ISO/IEC 27035-1:2023 og ISO/IEC 27035-2:2023 forbinder logning med hændelsesdetektion, triage og centraliseret analyse. ISO/IEC 27701:2021 tilføjer privatlivsspecifik logning af behandlingsaktiviteter for personhenførbare oplysninger. ISO/IEC 27017:2021 og ISO/IEC 27018:2020 tilføjer forventninger til cloud- og cloud-PII-logning, især hvor udbydere behandler kundedata i offentlige cloudmiljøer. ISO/IEC 27005:2024 rammesætter utilstrækkelig logning som et spørgsmål om risikobehandling, ikke blot et hul i værktøjerne.

Hændelseshåndtering: MDR kan eskalere, men ledelsen skal beslutte

MDR-leverandører detekterer og rådgiver. Den ansvarlige organisation erklærer hændelser, vurderer regulatorisk påvirkning, kommunikerer med myndigheder og beslutter, om underretning om brud på persondatasikkerheden er påkrævet.

Denne sondring er vigtig, fordi MDR-alvorlighed ikke automatisk er det samme som en væsentlig NIS2-hændelse, en større IKT-relateret DORA-hændelse eller et brud på persondatasikkerheden efter GDPR. Leverandøren kan mærke en alarm som “høj alvorlighed”, men organisationen skal beslutte, om kritiske tjenester blev påvirket, om personoplysninger blev kompromitteret, om kunder skal underrettes, om tilsynsmyndigheder skal informeres, og om ledelsen skal godkende en inddæmningshandling med operationel påvirkning.

Clarysecs Incident Response Policy - SME Incident Response Policy - SME er direkte:

“Tredjeparter skal handle i overensstemmelse med underskrevne aftaler, som skal indeholde klausuler om underretning ved brud på persondatasikkerheden og samarbejdsforpligtelser ved respons.”

Denne klausul er dér, hvor revisionsbevis efter GDPR Article 32 møder operationel hændelseshåndtering. Hvis MDR-leverandøren observerer mistanke om dataeksfiltrering fra et endpoint, der indeholder personoplysninger, skal leverandøren vide, hvor hurtigt der skal underrettes, hvem der skal underrettes, hvilket bevismateriale der skal bevares, og hvordan den dataansvarliges vurdering skal understøttes.

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint giver testmetoden. I fasen Controls in Action, Step 19, instruerer Zenith Blueprint teams i at validere logning og overvågning operationelt:

“Vælg en nylig hændelse eller event, og vis, hvordan I sporede den ved hjælp af jeres logfiler. Hvis funktioner til logfilers integritet (f.eks. hashverifikation) anvendes, skal det også dokumenteres. Bekræft, at alarmering fungerer (f.eks. at mislykkede loginforsøg eller eskalering af rettigheder udløser alarmer).”

Det samme trin behandler identitet og privilegeret adgang:

“For privilegerede konti skal det verificeres, at MFA håndhæves, at administratorroller er adskilt (konti af typen admin_john anvendes kun til administratoropgaver), og at der findes en aktuel liste over privilegerede brugere.”

I MDR-konteksten skal listen over privilegerede brugere omfatte leverandørkonti, ikke kun medarbejdere. Hvis MDR-leverandøren har konsoladgang, rettigheder til endpoint-isolering, EDR-administratorrettigheder eller læseadgang til følsomme logfiler, hører disse konti hjemme i gennemgangen.

Step 23 i Zenith Blueprint giver derefter teststrukturen for hændelser og leverandører:

“Vælg en nylig hændelse, eller gennemfør en tabletop-øvelse for at validere jeres plan. Indsaml og log alle beslutninger, roller og kommunikationer (5.26), og opdater planen med læring (5.27). Bekræft, at der findes procedurer til bevarelse af forensisk bevismateriale (5.28), herunder logsnapshots, sikkerhedskopier og sikker isolering af påvirkede systemer.”

En realistisk tabletop-øvelse bør omfatte MDR-leverandøren. Brug et scenarie som kompromitteret privilegeret konto, endpoint-isolering, mistanke om adgang til postkasse, mulig eksponering af løndata og alarmeskalering uden for normal arbejdstid. Testen bør verificere, om MDR-leverandørens ur starter ved detektion, kundeunderretning eller kundens bekræftelse. Denne sondring er vigtig, når regulatoriske frister afhænger af kendskab og beslutningstidspunkter.

Byg en MDR-tilsynspakke for én alarm på 90 minutter

En hurtig måde at afdække huller på er at vælge én nylig MDR-alarm med høj alvorlighed og bygge et ensides evidensspor. Denne praktiske øvelse fungerer godt før revisioner, bestyrelsesgennemgange og kontraktfornyelser.

1. Start med alarmsagen. Registrér tidsstempel, detektionsregel, påvirket aktiv, bruger, alvorlighed, MDR-analytikerens noter og eskaleringsvej.
2. Find kontraktklausulen eller SLA’en, der viser forventet responstid for denne alvorlighed.
3. Hent listen over logkilder, der dokumenterer, hvilke systemer der indgik i alarmen, f.eks. EDR, identitetsudbyder, firewall, e-mail-sikkerhedsgateway og cloud-revisionslogfiler.
4. Bekræft, at logfiler opbevares i overensstemmelse med politikken, og at den historiske hændelse stadig kan hentes.
5. Verificér, om MDR-analytikeren tilgik et kundemiljø. Hvis ja, registrér den navngivne konto, MFA-revisionsbevis, sessionslogfiler og godkendelse.
6. Dokumentér kundens beslutning: event lukket, hændelse erklæret, juridisk vurdering udløst, inddæmning udført eller risiko accepteret.
7. Hvis personoplysninger kan være involveret, registrér GDPR-rolleanalysen, ejeren af brudvurderingen, og om databehandlerens underretningsforpligtelser blev udløst.
8. Afslut med læring: tuning, ny detektion, adgangsændring, playbook-opdatering eller leverandørens SLA-problem.

Dette evidensspor for én alarm er stærkt, fordi det forbinder kontrakt, logning, adgang, hændelseshåndtering, privatliv og ledelsestilsyn i én beviskæde. Hvis I ikke kan bygge det for en nylig alarm, kan I sandsynligvis heller ikke bygge det under regulatorisk pres.

Leverandørovervågning er dér, de fleste MDR-programmer svækkes

Mange organisationer udfører due diligence, før de underskriver en MDR-kontrakt, og stopper derefter. Det er ikke nok for ISO/IEC 27001:2022, NIS2, DORA eller GDPR. MDR-tjenester ændrer sig løbende: nye detektionsregler, nye analytikerteams, nye underdatabehandlere, nye dataregioner, nye EDR-kapabiliteter, nye integrationer, nye feeds med trusselsintelligens og nye supportmodeller.

ISO/IEC 27002:2022-kontrol 5.22 omhandler overvågning, gennemgang og ændringsstyring af leverandørydelser. Zenith Controls forklarer, at 5.22 bygger på kontroller for leverandørrelationer og leverandøraftaler ved at sikre løbende overvågning og styring efter serviceopstart. Den knytter sig til sikkerhed under afbrydelser, sårbarhedsstyring, efterlevelse, adgangsstyring og sikker udvikling.

DORA Articles 28 to 30 gør dette særligt vigtigt for finansielle enheder. De kræver løbende overvågning, registre over IKT-tredjepartsaftaler, skelnen efter kritikalitet, due diligence, revisions- og inspektionsrettigheder, opsigelsesrettigheder, exitstrategier, serviceniveauer, hændelsesbistand, samarbejde med myndigheder og, for kritiske eller vigtige funktioner, servicemål, beredskabstest og samarbejde om trusselsstyret penetrationstest, hvor det er relevant.

Zenith Blueprint, fasen Controls in Action, Step 23, giver strukturen for leverandørlivscyklussen:

“Udarbejd en fuldstændig liste over nuværende leverandører og tjenesteudbydere (5.19), og klassificér dem baseret på adgang til systemer, data eller operationel kontrol.”

Den fortsætter:

“For hver kritisk leverandør skal det identificeres, om de anvender underleverandører (underdatabehandlere), som kan tilgå jeres data eller systemer.”

En praktisk gennemgang af MDR-tjenesten bør afholdes kvartalsvist for kritiske miljøer og mindst årligt for lavrisikomiljøer. Dagsordenen bør omfatte SLA-efterlevelse efter alvorlighed, eskalerede alarmer, ægte positive, falske positive, oversete eskaleringer, logkilders sundhedstilstand, ændringer i privilegeret adgang, nye integrationer, nye regioner, underleverandører, underdatabehandlere, ændringer i detektionsregler, performance for hændelsesstøtte, anmodninger om bevismateriale, åbne risici, korrigerende handlinger og exitberedskab.

Det er ikke detailstyring. Det er den sikringssløjfe, der dokumenterer, at organisationen aktivt styrer en kritisk sikkerhedsleverandør.

Kortlægning på tværs af efterlevelseskrav: ét MDR-kontrolsæt, fem revisionsdialoger

Værdien af ISO/IEC 27001:2022 er, at den giver organisationer én sammenhængende ISMS-cyklus for flere efterlevelsesdialoger. Den samme MDR-tilsynspakke med revisionsbevis kan kortlægges på tværs af NIS2, DORA, GDPR, NIST CSF 2.0 og COBIT 2019.

NIST CSF 2.0 er nyttig til kommunikation. GOVERN-funktionen kræver, at juridiske, regulatoriske, kontraktlige og privatlivsrelaterede forpligtelser forstås og styres, at roller og beføjelser defineres, at cybersikkerhedsrisiko integreres i enterprise risk management, og at leverandørrisici kommunikeres og overvåges.

COBIT 2019 er nyttig til ledelse og assurance. COBIT-orienterede revisorer fokuserer ofte mindre på en enkelt kontrol og mere på, om styringsmål, servicestyring, risikoejerskab og performanceovervågning fungerer som et system.

Sådan tester revisorer tilsyn med MDR-leverandører

Forskellige revisorer bruger forskellige vinkler, men de ønsker alle revisionsbevis for, at organisationen styrer relationen.

En ISO/IEC 27001:2022-revisor vil starte med omfang, interessenter, risikovurdering, anvendelighedserklæring, risikobehandlingsplan og operationelt bevis. Hvis MDR er omfattet, forventer revisoren, at eksternt leverede processer styres under ISMS’et. Revisoren kan udtage stikprøver af leverandørrelationer, leverandøraftaler, overvågning af leverandørydelser, logning, overvågning, hændelseshåndtering, håndtering af bevismateriale og adgangsstyring.

En DORA-tilsynsmyndighed vil fokusere på operationel robusthed og systemisk risiko. Den kan undersøge kritikalitetsvurderingen, IKT-tjenesteregisteret, analyse af koncentrationsrisiko, exitstrategi, hændelsesklassificering, revisionsrettigheder og bevis for, at MDR-leverandøren kan understøtte regulatorisk rapportering.

En GDPR-revisor eller privatlivsgennemgang vil fokusere på styring mellem dataansvarlig og databehandler. De vil efterspørge DPA’en, databehandlerens due diligence, kontroller for underdatabehandlere, sikkerhedsforanstaltninger for logfiler, der indeholder personoplysninger, opbevaringskontroller, registreringer af brudvurdering og bevis, der understøtter Article 32.

En COBIT- eller ISACA-revisor vil inspicere governance-bevis: ejerskab til leverandørrisiko, indkøbsarbejdsgang, referater fra servicegennemgange, sporing af SLA-problemer, korrigerende handling, kvaliteten af bevismateriale og om ledelsen modtager meningsfulde metrikker.

Den mest afslørende revisionsanmodning er enkel: “Vis mig én MDR-alarm fra detektion til lukning.” Hvis I kan vise kontraktforventning, logkilde, alarm, eskalering, beslutning, bevarelse af bevismateriale, privatlivsvurdering, afhjælpning og ledelsesrapportering, er jeres tilsyn med MDR modent. Hvis I kun kan vise en leverandørsag, har I overvågning, men svag governance.

Ledelsesrapportering: bestyrelsen har ikke brug for packet captures

NIS2 og DORA placerer begge ansvar på ledelsesorganniveau. Bestyrelser og direktioner har ikke brug for rå telemetri. De har brug for risikorelevante metrikker for tilsyn med MDR.

Et nyttigt kvartalsvist MDR-dashboard omfatter:

• Kritiske logkilder onboardet i forhold til forventet.
• Procentdel af kritiske aktiver dækket af MDR.
• Alarmer med høj alvorlighed fordelt på kategori og forretningstjeneste.
• Gennemsnitlig tid fra detektion til kundeunderretning.
• Gennemsnitlig tid fra kundens bekræftelse til beslutning.
• SLA-brud og uafsluttede leverandørhandlinger.
• Status for gennemgang af privilegerede leverandørkonti.
• Ændringer hos underleverandører eller underdatabehandlere.
• Hændelser, der kræver juridisk, regulatorisk eller kundevendt underretningsvurdering.
• Implementerede erfaringer.

Dette dashboard bør indgå i ISMS-ledelsens gennemgang, opdateringer af risikobehandling og leverandørgennemgang. Under ISO/IEC 27001:2022 skal ledelsen sikre, at ISMS’et er i overensstemmelse med den strategiske retning, at ressourcer er tilgængelige, at ansvar er tildelt, at kommunikation fungerer, og at løbende forbedring finder sted. MDR-metrikker er en praktisk måde at vise, at outsourcede sikkerhedsoperationer styres af ledelsen og ikke overlades til værktøjsadministratorer.

Almindelige faldgruber i MDR-tilsyn, der bør lukkes før 2026-revisioner

De mest almindelige huller er ordinære styringssvigt.

For det første glemmer organisationer, at MDR-leverandører kan behandle personoplysninger. Sikkerhedslogfiler behandles undertiden som “tekniske data”, men de kan indeholde personoplysninger og lejlighedsvis følsomt indhold. GDPR-rolleanalyse og databehandlerklausuler bør være afsluttet før onboarding, ikke under et brud.

For det andet antages logopbevaring i stedet for at blive kontraktligt fastlagt. Hvis regulatoriske, forensiske eller kundemæssige forpligtelser kræver bevismateriale i måneder, skal MDR- og SIEM-opbevaringsmodellen understøtte dette. SMV-politikkens krav om 12 måneders logopbevaring hos udbyderen er en praktisk baseline for mange miljøer.

For det tredje er tredjepartsadgang for vidtgående. Leverandørkonti bør være navngivne, MFA-beskyttede, overvågede, gennemgåede og tidsbegrænsede, hvor det er muligt. Delte konti og ikke-administrerede administrative sessioner skaber revisions- og hændelseshåndteringsrisiko.

For det fjerde er hændelsestærskler uklare. MDR-alvorlighed er ikke automatisk lig med en juridisk hændelse, en større IKT-relateret DORA-hændelse, en væsentlig NIS2-hændelse eller et brud på persondatasikkerheden efter GDPR. Playbooken skal definere, hvem der træffer hver beslutning.

For det femte er underleverandører usynlige. Hvis MDR-leverandøren ændrer analyseplatforme, supportregioner eller downstream-databehandlere, ændrer kundens risikobillede sig. Forudgående skriftligt samtykke og periodisk gennemgang er afgørende.

For det sjette fokuserer servicegennemgange kun på sagsvolumen. Modne gennemgange undersøger oversete alarmer, tuningændringer, logkilders sundhedstilstand, udlevering af bevismateriale, leverandøradgang, hændelsessamarbejde og kontraktlige forpligtelser.

Næste skridt: gør din MDR-leverandør klar til revision med Clarysec

Hvis din MDR-leverandør allerede er i drift, skal du ikke vente på, at en tilsynsmyndighed, kunderevisor eller hændelse afdækker, at dit bevismateriale er ufuldstændigt. Start med én nylig alarm, og opbyg sporet. Klassificér derefter leverandøren, gennemgå kontrakten, validér logning, test eskalering, bekræft databehandlerklausuler, gennemgå adgang og planlæg leverandørovervågning.

Clarysec kan hjælpe dig med at operationalisere dette hurtigt ved hjælp af:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint til trinvis implementering, herunder Step 19 for validering af logning, overvågning og adgang samt Step 23 for kontroller vedrørende leverandører og hændelsesstyring.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls til at kortlægge ISO/IEC 27002:2022-kontrollerne 5.19, 5.22 og 8.15 til revisionsforventninger under NIS2, DORA, GDPR, NIST og COBIT.
• Clarysec-politikskabeloner, herunder Incident Response Policy, Third party and supplier security policy, Logging and Monitoring Policy, Incident Response Policy - SME, Third-Party and Supplier Security Policy - SME, Logging and Monitoring Policy - SME og Data Protection and Privacy Policy - SME.

MDR er en af de mest værdifulde sikkerhedsinvesteringer, en organisation kan foretage. I 2026 skal denne værdi dokumenteres gennem governance, revisionsbevis og ansvarligt tilsyn. Hvis du ønsker en praktisk MDR-tilsynspakke kortlagt til ISO/IEC 27001:2022, NIS2, DORA og GDPR Article 32, kan Clarysec hjælpe dig med at bygge den, før den næste alarm bliver til den næste revisionskonstatering.