Hvordan velge riktig SOC/MDR-leverandør: 10 spørsmål dere bør stille 

En SOC/MDR-avtale handler ikke først og fremst om dashboard, teknologi eller antall alarmer. Den handler om hvem som ser hva, hvem som gjør hva – og hvor raskt dere får hjelp når noe faktisk skjer. 

Markedet for SOC/MDR- og sikkerhetsovervåkingstjenester (ofte omtalt som MSSP, Managed Security Service Provider) er fullt av sterke påstander: 24/7, kunstig intelligens, rask respons og full oversikt. Men like tjenester på papiret kan gi svært ulik kontroll i praksis. Før dere velger leverandør, bør dere derfor undersøke mer enn pris, plattform og sertifiseringer. Disse ti spørsmålene avdekker hva dere faktisk kjøper. 

Start med behovet dere har, ikke styr etter leverandørens verktøy 

En SOC/MDR skal redusere risiko for virksomheten deres. Da må dere først vite hvilke verdier, systemer og hendelser som betyr mest. En avansert plattform gir liten verdi hvis kritiske miljøer ikke er koblet til, loggene mangler kontekst eller ingen har fullmakt til å reagere. 

NSM understreker at virksomhetens ansvar for sikkerheten ikke forsvinner når tjenester settes ut. Dere må fortsatt ha bestillerkompetanse, gjennomføre risikovurderinger, stille verifiserbare krav og følge opp leveransen gjennom hele livsløpet. Det gjør valg av SOC/MDR-leverandør til et spørsmål om styring – ikke bare teknologi. 

1. Hva skal SOC/MDR-teamet beskytte, og hva er utenfor avtalen? 

Kunden må definere hva som skal beskyttes, hvilke virksomhetskritiske tjenester og verdier som omfattes, og hvilke krav som gjelder til risiko, respons og tilgjengelighet. 

MSSP-en bør deretter beskrive hvordan dette behovet kan dekkes gjennom SOC/MDR-tjenesten, hvilke datakilder og sikkerhetskapabiliteter som er nødvendige, og hvilke begrensninger eller avhengigheter som finnes. 

Som en del av dette bør MSSP-en også bidra med sikkerhetsfaglig rådgivning, blant annet ved å utfordre kundens scope, identifisere mangler og anbefale områder som bør inkluderes eller prioriteres. 

Oppsummert: Kunden definerer hva som må beskyttes og hvorfor. MSSP-en beskriver hvordan dette kan dekkes, og utfordrer samtidig scope der sikkerhetsisikoen tilsier det. 

2. Hvem har ansvar for hva? 

En SOC/MDR overtar oppgaver, ikke virksomhetens ansvar for risiko. Avklar derfor grensesnittet mellom SOC-teamet, intern IT og sikkerhet, systemeiere, ledelsen og eventuelle andre leverandører. 

Spør hvem som er ansvarlig for blant annet loggkvalitet, onboarding av nye systemer, lukking av sårbarheter, endring av sikkerhetsregler, oppfølging av anbefalte tiltak og godkjenning av respons. Hvis svaret er «det kommer an på», bør avtalen forklare nøyaktig hva det kommer an på. 

3. Får dere en operativ sikkerhetsfunksjon, eller bare flere varsler? 

En reell SOC/MDR kombinerer mennesker, prosesser og teknologi. Be leverandøren vise hvordan alarmer prioriteres, hvordan analytikerne tilfører kontekst, og hva som skjer fra et signal oppstår til saken er undersøkt, adressert og lukket. 

Undersøk om tjenesten omfatter aktiv trusseljakt, korrelasjon på tvers av loggkilder, analyse av identiteter og sky, og løpende forbedring av deteksjonsregler. Det avgjørende er ikke hvor mange varsler dere mottar, men om de viktigste hendelsene oppdages og håndteres i tide. 

4. Hva betyr 24/7 i praksis? 

24/7 kan bety alt fra fullt bemannede analytikere til en vaktordning som aktiveres av automatiske alarmer. Spør hvem som faktisk følger med om natten, i helger og ferier, hvor teamet befinner seg, hvilke språk de arbeider på, og hvordan alvorlige hendelser eskaleres. 

Be om dokumenterte responstider for ulike alvorlighetsgrader. Avklar også forskjellen mellom tiden det tar å oppdage, bekrefte, varsle og iverksette tiltak. Ett samlet gjennomsnittstall sier ofte lite om hendelsene som betyr mest. 

5. Hvilke tiltak kan SOC/MDR-teamet gjennomføre? 

Rask deteksjon hjelper lite hvis ingen kan reagere. Avklar om SOC/MDR -teamet kan sperre en konto, isolere en enhet, blokkere trafikk eller endre en sikkerhetsregel – og hvilke tiltak som krever godkjenning fra dere. 

Fullmaktene bør tilpasses risiko og drift. I noen miljøer er automatisk isolering riktig. I andre kan et feil tiltak stanse kritisk produksjon. Det viktigste er at beslutningen er tatt på forhånd, dokumentert og øvd på. 

6. Hva skjer når hendelsen er større enn SOC/MDR -teamet? 

En SOC/MDR oppdager og håndterer løpende sikkerhetshendelser. Et alvorlig dataangrep kan kreve en mer omfattende hendelseshåndteringsprosess med kartlegging av angrepsforløp, bevissikring, begrensning, gjenoppretting og rapportering. 

Spør om leverandøren har et eget hendelseshåndteringsteam, hvordan det aktiveres, hvilke kostnader som gjelder og om dere får hjelp selv om hendelsen rammer systemer som ikke var koblet til SOC/MDR -tjenesten. Hvis leverandøren viser til NSM, kontroller hvilken konkret tjeneste vurderingen gjelder. NSMs kvalitetsordning vurderer hendelseshåndtering – ikke SOC/MDR -tjenesten. 

7. Hvilken innsikt får IT, ledelsen og styret? 

En operativ rapport skal hjelpe IT- og sikkerhetsteamet med å forbedre miljøet. En lederrapport skal vise risiko, utvikling og beslutningsbehov. Den samme rapporten fungerer sjelden godt for begge målgrupper. 

Be om eksempler på rapporter og møtearenaer. Undersøk om dere får innsikt i loggdekning, gjentakende hendelser, responstider, åpne forbedringstiltak og utvikling over tid – ikke bare antall alarmer. Avklar hvem som eier oppfølgingen når SOC/MDR -teamet anbefaler et tiltak. 

8. Hvor behandles dataene – og hvem har tilgang? 

En SOC/MDR behandler ofte sikkerhetslogger som kan inneholde personopplysninger, identitetsdata, tekniske detaljer og informasjon om virksomhetens mest kritiske systemer. Dere bør vite hvor data lagres og behandles, hvem som kan få tilgang, hvilke underleverandører som brukes, og hvilke land eller jurisdiksjoner som kan være involvert. 

«Data lagres i Norden» er ikke alltid et fullstendig svar. Spør også hvor support og administrasjon utføres fra, hvordan tilganger styres og logges, hvor lenge data beholdes, og hva som skjer med dataene ved avslutning. Vurderingene må ta utgangspunkt i deres data, risiko og regulatoriske krav. 

9. Hvordan dokumenterer leverandøren sikkerhet og kvalitet? 

Sertifiseringer som ISO 27001 kan være relevante, men de forteller ikke alene hvor god SOC/MDR -leveransen er for deres miljø. Be om innsyn i styringssystem, sikkerhetsarkitektur, revisjonsresultater, beredskapsplaner, kompetansemodell og rutiner for underleverandører. 

Spør også hvordan leverandøren måler egen kvalitet: deteksjonsdekning, responstider, feilalarmer, læring etter hendelser og forbedring av deteksjoner. For virksomheter med særskilte krav kan digitalsikkerhetsloven, NIS2, DORA eller bransjekrav påvirke hva avtalen og rapporteringen må dekke. Digitalsikkerhetsloven trådte i kraft 1. oktober 2025 og gjennomfører foreløpig det opprinnelige NIS1-regelverket; en oppdatering i tråd med EUs NIS2-direktiv er ventet i løpet av 2026, men er ikke formelt innlemmet i norsk rett per i dag – sjekk nsm.no for gjeldende status. For finanssektoren gjelder DORA allerede fullt ut i Norge, med DORA-loven i kraft fra 1. juli 2025. Leverandøren kan støtte etterlevelsen – men ansvaret blir hos virksomheten. 

10. Hvordan kommer dere dere ut av avtalen? 

Exit bør planlegges før kontrakten signeres. Avklar hvordan logger, saker, deteksjonsregler, dokumentasjon og historikk kan overføres til dere eller en ny leverandør. Hvilken bistand får dere i overgangsperioden, og hvor lang tid tar den? 

Kontrakten bør også beskrive sletting, bekreftelse på sletting, avslutning av tilganger og håndtering av pågående hendelser. En god exit-plan reduserer leverandørlåsing og risikoen for tap av overvåking akkurat når tjenesten flyttes. 

Be om faktiske bevis  

Gode leverandører tåler konkrete spørsmål. Be om eksempler, demonstrasjoner og dokumentasjon: en anonymisert hendelsesrapport, en eskaleringsflyt, en månedlig lederrapport og et realistisk scenario fra alarm til tiltak. 

Det viktigste spørsmålet er enkelt: Hvis et kritisk varsel kommer klokken 02.30, hvem gjør hva – og hvor lang tid tar det før risikoen faktisk er redusert? 

En SOC/MDR -avtale skal gi mer kontroll over tid 

Riktig SOC/MDR -leverandør gir dere ikke bare flere øyne på miljøet. Leverandøren hjelper dere med å se det viktigste, reagere raskere og forbedre sikkerhetsnivået over tid. Det krever tydelig omfang, avklarte fullmakter, relevant rapportering og et samarbeid som fungerer både i hverdagen og under press. 

Gikk du glipp av de andre artiklene i NSM-serien?

NSM grunnprinsipper for IKT sikkerhet

SOC/MDR gir bedre kontroll

Hva betyr det at en leverandør er evaluert av NSM?

Slik forbereder du bedriften på en hendelse

Kilder og redaksjonelle merknader 

• NSM: Ivareta sikkerhet i anskaffelses- og utviklingsprosesser – primærkilde om virksomhetens ansvar ved tjenesteutsetting og vurdering av leverandørens sikkerhet, underleverandører, rapportering og exit. 

• NSM: Oversikt og kontroll på hele livsløpet – primærkilde om forberedelse, anskaffelse, forvaltning og opphør. 

• NSM: Kvalitetsordning for leverandører som håndterer IKT-hendelser – avgrensning mellom vurdert hendelseshåndtering og SOC. 

• DORA – Regulation (EU) 2022/2554 – offisiell kilde om blant annet styring av IKT-tredjepartsrisiko og exit-strategier for finansielle virksomheter. 

• NetNordic: SOC, MDR eller XDR – hva er forskjellen?

Forfatter