Hvorfor NIS2 ikke handler om flere spørgeskemaer (men bedre beslutninger)

Den klassiske NIS2-fejl: 80 spørgsmål, 0 bedre beslutninger

Jeg har selv været med til det. Man får at vide, at NIS2 skærper kravene, især omkring leverandører. Panikken breder sig en smule. Og så sker det samme i rigtig mange virksomheder: Nogen finder et standard “NIS2 supplier questionnaire” på 12 sider, tilføjer lidt ekstra for en sikkerheds skyld, og så ryger det ud til alle leverandører.

Et par uger senere har man en mappe fyldt med udfyldte Excel-ark, PDF’er og svar i mails. Ingen har tid til at læse det. Ingen ved, hvad der er vigtigt. Og IT, indkøb og jura kigger lidt opgivende på hinanden og tænker: “Hvad gør vi nu?”

Jeg har været den person, der sad med 40 spørgeskemaer og et meget tomt beslutningsgrundlag. Det er ret effektivt til at kurere ens begejstring for store leverandørundersøgelser.

Pointen er: NIS2 leverandørkrav handler ikke om at samle så meget data ind som muligt. Det handler om at kunne træffe begrundede beslutninger om tredjepartsrisiko i cybersikkerhed – uden at drukne.

I denne artikel går jeg igennem en ret jordnær “audit-light” tilgang, som kan bruges af virksomheder, der ikke har en stor sikkerhedsafdeling. Du får:

• En enkel model med 3 risikoklasser for leverandører
• Minimumskrav pr. klasse, du kan bygge videre på
• Et fokuseret spørgeskema, der er bundet direkte til beslutninger
• Forslag til evidens, kontraktpunkter og opfølgning
• Et eksempel på et leverandørscorecard med klare valg

Jeg skriver ikke som sikkerhedschef, men som hende inde i virksomheden, der gerne vil have, at NIS2 faktisk hjælper os med at blive mindre sårbare – ikke bare mere trætte.

1. Hvorfor leverandørstyring er den svære del af NIS2

NIS2 stiller skærpede krav til sikkerhed og risikostyring, og leverandørleddet er en af de mest følsomme dele. For mange virksomheder er det her, kæden hopper af. Ikke fordi kravene er urimelige, men fordi processen bliver uoverskuelig.

Hvor det typisk går galt

Jeg ser især tre klassiske problemer:

• Alle leverandører behandles ens. Den lille nicheleverandør til kantinens bookingsystem får samme spørgeskema som den hostingpartner, der driver jeres kerneplatform. Det er ineffektivt og irriterer alle.
• Spørgsmålene er ikke koblet til beslutninger. Man spørger om alt muligt, “fordi det står i skabelonen”, men har ikke defineret, hvad man vil gøre ved svaret. Resultat: meget støj, lidt signal.
• Ingen ved, hvad “godt nok” betyder. Hverken indkøb, forretningen eller leverandøren ved, hvad minimumskravet er. Så alt ender i gråzoner og ad hoc-afgørelser.

Hvis du kan genkende bare én af de tre, er der meget at hente på at få en enkel, risikobaseret tilgang til NIS2 leverandørkrav.

Hvis du vil have et mere overordnet billede af NIS2-arbejdet, kan du evt. kombinere denne tilgang med den mere generelle guide i artiklen om NIS2 uden panik.

2. En enkel risk-tiering: 3 klasser der faktisk kan bruges

Før du spørger leverandører om noget som helst, skal du vide, hvor vigtige de er for din drift og dit risikobillede. Her giver det mening at bruge en simpel inddeling i tre risikoklasser:

1. Kritisk
2. Vigtig
3. Standard

Målet er ikke at ramme 100 % præcist, men at have et praktisk styringsredskab, som kan forklares til både indkøb, IT og forretningen.

Kritisk leverandør

En leverandør er kritisk, hvis ét eller flere af disse gælder:

• De driver eller understøtter systemer, hvor længere nedetid stopper væsentlig drift (timer/dage)
• De håndterer særligt følsomme data (fx sundhedsdata, store mængder persondata, finansielle transaktioner)
• De har teknisk adgang til dine mest centrale systemer eller infrastruktur (fx privilegeret fjernadgang)
• De er svære og dyre at skifte ud (lock-in, komplekse migreringer osv.)

Vigtig leverandør

En leverandør er vigtig, hvis:

• De understøtter centrale arbejdsprocesser, men hvor nedetid i kortere perioder kan håndteres manuelt
• De behandler forretningskritiske, men ikke særligt følsomme data
• De har adgang til jeres netværk eller systemer, men ikke med høje rettigheder

Standard leverandør

En leverandør er standard, hvis:

• En fejl eller nedetid primært skaber irritation, ikke reel driftsafbrydelse
• De ikke har særlig adgang til jeres systemer
• De ikke behandler data, som skaber væsentlig risiko for jer eller jeres kunder

Her hører typisk almindelige kontorleverandører, mindre marketingtjenester, kursusudbydere osv. til.

Sådan får du klassifikationen til at fungere i praksis

Min erfaring er, at modellen kun fungerer, hvis den kommer tidligt ind i processen. Et par praktiske greb:

• Lad indkøb og IT definere klassifikationen sammen på 1 side
• Lav et enkelt skema i jeres procesværktøj eller et ark, hvor hver ny leverandør får en risikoklasse
• Brug samme klassifikation på eksisterende leverandører over tid, fx i forbindelse med kontraktfornyelse

Det her er også et oplagt sted at koble til mere overordnede overvejelser om organisering og governance, så ejerskab og roller omkring leverandørstyring er tydelige.

3. Minimumskrav pr. klasse: hvad er “godt nok”?

Når leverandøren er klassificeret, kan du sætte realistiske, men skærpede NIS2 leverandørkrav. Her giver det mening at definere nogle få kerneområder, som går igen:

• Adgangsstyring
• Backup og gendannelse
• Logning og overvågning
• Håndtering af sikkerhedshændelser
• Patch- og ændringsstyring

Og så lade kravniveauet stige med risikoklassen.

Kritiske leverandører: højeste krav

Eksempler på minimumskrav:

• Adgangsstyring: Multi-faktor login, princip om mindst mulige rettigheder, formelle processer for oprettelse og nedlæggelse af brugere.
• Backup: Dokumenteret backupstrategi, testet gendannelse, geografisk adskilt backup for centrale systemer.
• Logning: Logning af væsentlige systemer, overvågning af mistænkelig aktivitet, opbevaring af logs i en aftalt periode.
• Incident management: Formaliseret proces, tidsfrister for notifikation ved brud, aftalt kommunikationsvej.
• Patch styring: Regelmæssige opdateringer, hurtige sikkerhedsopdateringer ved kritiske sårbarheder.

Vigtige leverandører: solide, men mere pragmatiske krav

Her kan kravene fx være:

• Struktureret adgangsstyring og brug af stærk autentifikation, hvor det er relevant
• Regelmæssig backup og dokumenteret gendannelsesprocedure
• Grundlæggende logning og mulighed for at undersøge mistænkelig aktivitet
• En defineret proces for sikkerhedshændelser, også hvis den ikke er lige så formel
• Plan for opdatering af systemer og komponenter

Standard leverandører: let, men ikke helt frit spil

Her vil du ofte kunne nøjes med:

• At sikre, at de følger almindelig god praksis for IT-sikkerhed
• At de ikke får unødvendig adgang til jeres systemer eller data
• At persondata og fortrolig information håndteres forsvarligt, hvis relevant

Pointen er: Ikke alle skal op på samme niveau. Men ingen bør være helt uden grundlæggende krav.

4. Et spørgeskema der faktisk giver signal

Så til det følsomme punkt: NIS2 supplier questionnaire. Hvordan undgår du, at det bliver endnu en tung øvelse, der ender i en mappe?

Et enkelt trick har hjulpet mig meget: Hvert spørgsmål skal have en tydelig konsekvens. Altså: Hvad gør vi, hvis svaret er nej, eller kvaliteten er lav?

15 spørgsmål der peger på handling

Her er et forslag til en “audit-light” spørgeramme for kritiske og vigtige leverandører. Du kan variere dybden, men strukturen er den samme:

1. Er der en dedikeret ansvarlig for informationssikkerhed? (Konsekvens: Hvis nej, kræv kontaktpunkt og beskrevne roller.)
2. Har I en skriftlig politik for informationssikkerhed? (Konsekvens: Hvis nej, vurder om de kan være kritisk leverandør.)
3. Anvender I multi-faktor godkendelse til administrative adgange? (Konsekvens: Hvis nej, krav om plan og tidsfrist.)
4. Hvordan styres brugeradgange til vores data/systemer? (Konsekvens: Afklar, om princip om mindst mulige rettigheder efterleves.)
5. Beskriv jeres backup-løsning for de systemer, vi bruger hos jer. (Konsekvens: Match med jeres egne krav til RTO/RPO.)
6. Hvornår er gendannelse sidst testet? (Konsekvens: Hvis >12 måneder, drøft krav om test.)
7. Logger I adgang og ændringer i de systemer, der understøtter os? (Konsekvens: Hvis nej, risikovurdering og evt. kompenserende kontroller.)
8. Har I en formaliseret proces for håndtering af sikkerhedshændelser? (Konsekvens: Kræv minimum en simpel incident-procedure.)
9. Hvilke tidsfrister kan I acceptere for at informere os om sikkerhedshændelser? (Konsekvens: Ind i kontrakt/SLA.)
10. Anvender I kryptering til data i hvile og i transit for vores løsninger? (Konsekvens: Hvis nej, konkret vurdering og krav.)
11. Har I gennemført en ekstern sikkerhedsvurdering eller revision de seneste 24 måneder? (Konsekvens: Brug som evidens, ellers afklar alternativer.)
12. Bruger I underleverandører til driften af vores løsning? (Konsekvens: Kræv overblik og relevante krav videreført.)
13. Har I en defineret exit-strategi eller data-udleveringsproces, hvis samarbejdet stopper? (Konsekvens: Hvis nej, kræv beskrivelse.)
14. Er der kendte større sikkerhedsprojekter eller -gæld, som kan påvirke vores løsning? (Konsekvens: Dialog om tidsplan og risikohåndtering.)
15. Er I underlagt særlige standarder eller regulering (ISO 27001, SOC-rapporter mv.)? (Konsekvens: Vurder om det kan genbruges som evidens.)

Det her kan stadig være overvældende for små leverandører. Men strukturen gør det lettere at tilpasse. Til standard leverandører kan du bruge en stærkt forkortet version.

5. Hvilken evidens bør du kræve – og hvornår bliver det overkill?

NIS2 leverandørkrav handler ikke om at samle på beviser. Det handler om at have tilstrækkelig dokumentation til, at du med ro i maven kan sige: “Vi har gjort vores, og vi har valgt på et oplyst grundlag”.

Typiske former for evidens

For kritiske og vigtige leverandører kan du konkret bede om:

• Kort politik for informationssikkerhed eller uddrag, der viser struktur
• Resultater fra seneste eksterne revision (fx ISO 27001, ISAE/SOC-rapporter)
• Beskrivelse af backup- og gendannelsesprocedurer
• Uddrag af incident-procedure og kommunikationsflow
• Overordnet arkitekturbeskrivelse med fokus på dataflows og adgangsniveauer

Hvornår er det nok?

Et par tommelfingerregler fra min egen praksis:

• Kritisk leverandør: Kræv tydelig, skriftlig evidens og gerne tredjepartsrevision på de vigtigste områder.
• Vigtig leverandør: Kræv dokumentation på nøgleområder, men accepter mere pragmatisk form (fx kort beskrivelse i en mail).
• Standard leverandør: Nøjes ofte med kontraktmæssige forpligtelser og mundtlig/simpel skriftlig bekræftelse.

Hvis du er i tvivl, så spørg dig selv: “Hvis noget går galt, vil vi så kunne forklare vores valg for ledelse eller tilsyn?”. Hvis svaret er ja, er du et godt stykke ad vejen.

6. Kontrakt- og SLA-punkter: hvad procurement bør have med

Leverandørstyring stopper ikke ved spørgeskemaet. Hvis svarene og evidensen ikke omsættes til kontrakt og SLA, ender meget som gode intentioner.

Centrale kontraktpunkter ved NIS2 leverandørkrav

Nogle af de punkter, jeg ofte vil have med, især for kritiske og vigtige leverandører:

• Sikkerhedsniveau: Generel forpligtelse til at opretholde passende informationssikkerhed, fx refereret til anerkendte standarder.
• Adgangsstyring: Klare krav til, hvordan leverandøren må tilgå jeres systemer og data.
• Incident-notifikation: Tidsfrister, indholdskrav og kontaktpunkter ved sikkerhedshændelser.
• Underleverandører: Krav om godkendelse eller information ved skift og videreførelse af sikkerhedskrav.
• Audit-ret: Mulighed for at få indsigt i relevante sikkerhedstiltag (ofte på et rimeligt og proportionalt niveau).
• Exit og datahåndtering: Hvordan data retur, sletning og evt. overgang understøttes, så I ikke hænger fast i usikre løsninger.

Her er det oplagt at trække på jura og indkøb og gerne folk, der har arbejdet med it kontraktpraksis. Pointen er ikke at gøre alle kontrakter 50 sider længere, men at få de rigtige 3-7 sikkerhedspunkter ind, hvor det betyder noget.

7. Løbende opfølgning: hvornår giver det mening at “røre ved” klassifikationen igen?

NIS2 lægger op til løbende risikostyring. Det gælder også på leverandørsiden. Heldigvis behøver det ikke at betyde, at du gennemfører årlige mini-revisioner af alle samarbejdspartnere.

En enkel kadence

En praktisk rytme kunne være:

• Kritiske leverandører: Årlig opdatering af spørgeskema eller dialog, inkl. gennemgang af større ændringer.
• Vigtige leverandører: Opfølgning hvert 2.-3. år, eller ved større ændringer.
• Standard leverandører: Opdatering kun ved væsentlige ændringer eller incident.

Triggers for re-assessment

Nogle hændelser bør altid få dig til at genoverveje både risikoklasse og krav:

• Større sikkerhedshændelse hos leverandøren
• Væsentlig udvidelse af deres adgang til jeres systemer/data
• Teknisk eller forretningsmæssig afhængighed øges markant
• Skift til nye underleverandører i deres drift

Her er det ofte gavnligt at have en intern proces, hvor IT, indkøb og forretningen hurtigt kan tage en fælles status. Det er klassisk cyber- og informationssikkerhed koblet sammen med helt almindelig forretningsdrift.

8. Exit-plan: det mest oversete element

En af de mere oversete dele af leverandørrisiko er, hvad der sker, hvis I vil eller skal væk. Mange har fokus på opstart, få har en reel plan for afslutning.

Hvad en enkel exit-plan kan indeholde

Du behøver ikke en roman. Et par klare punkter kan gøre forskellen:

• Hvordan får vi vores data retur, i hvilket format og inden for hvilke frister?
• Hvordan og hvornår sletter leverandøren vores data hos sig?
• Har vi en overgangsperiode, hvor begge løsninger kører parallelt?
• Hvem hos leverandøren er ansvarlig for exit-processen?

For kritiske løsninger kan du med fordel drøfte realistiske scenarier: Hvad hvis leverandøren får en alvorlig sikkerhedshændelse? Hvornår går I fra “vi hjælper med at rette op” til “vi planlægger udfasning”?

9. Eksempel: Et simpelt leverandørscorecard

Lad os samle det i et konkret eksempel. Forestil dig en cloud-baseret platform, der understøtter jeres kernetjeneste. I har klassificeret leverandøren som kritisk.

Trin 1: Klassifikation

Vurdering:

• Nedetid stopper væsentlig drift: Ja
• Behandler følsomme data: Ja
• Svære at skifte hurtigt: Ja

Konklusion: Kritisk leverandør.

Trin 2: Spørgeskema og svar (uddrag)

Nogle centrale svar kunne være:

• Har I en skriftlig politik for informationssikkerhed? Ja, ISO 27001-certificeret.
• Anvender I multi-faktor autentifikation til administrative adgange? Delvist, fuld udrulning planlagt inden for 6 måneder.
• Hvornår er gendannelse sidst testet? For 4 måneder siden, dokumentation kan fremsendes.
• Har I gennemført ekstern sikkerhedsrevision de seneste 24 måneder? Ja, SOC 2 Type II rapport tilgængelig.
• Bruger I underleverandører? Ja, navngivne datacentre i EU, liste vedlagt.

Trin 3: Scorecard

I kan fx samle det i en enkel struktur med 3 farver: grøn, gul, rød.

• Adgangsstyring: Gul (MFA delvist, men planlagt) – kræver opfølgning
• Backup/gendannelse: Grøn (dokumenteret og testet)
• Logning/overvågning: Grøn (omfattet af SOC-rapporten)
• Incident-håndtering: Grøn (formaliseret proces, definerede notifikationsfrister)
• Underleverandører: Gul (afhængig af tydelig kontraktstyring)

Trin 4: Beslutning

Ud fra scorecardet kan I lander en af tre konklusioner:

• Godkend: Krav opfyldt, normale opfølgningsintervaller.
• Mitigér: Nogle svagheder, men med konkrete afhjælpende tiltag og tidsplan (fx krav om fuld MFA inden for 6 måneder).
• Udskift: Niveauet er så lavt, eller risikobilledet så kritisk, at I aktivt bør planlægge at forlade leverandøren.

I eksemplet ovenfor er det oplagt at vælge “Mitigér”: Leverandøren kan fortsætte, men kun hvis planen for fuld MFA og håndtering af underleverandører bliver en del af kontrakt og opfølgning.

Her kan en simpel beslutningsskabelon hjælpe, så I dokumenterer, hvorfor I landede på netop den beslutning.

10. Hvad kan du tage med til dit næste møde?

Hvis du står midt i NIS2-forberedelserne og kan mærke, at leverandørsporet er ved at blive tungt, kan du starte med tre helt konkrete spørgsmål til dit næste møde med IT og indkøb:

• Hvilke 10 leverandører er mest kritiske for vores drift og data?
• Har vi en enkel inddeling i kritisk/vigtig/standard, alle kan forstå?
• Hvad er de 10-15 spørgsmål, vi faktisk vil bruge til at træffe beslutninger?

Når de tre ting er på plads, er resten et spørgsmål om at bygge lag på, ikke om at opfinde alt på én gang. Og så bliver NIS2 leverandørkrav pludselig noget, der hjælper jer med at styre risiko – ikke bare et ekstra arkiv med spørgeskemaer.

Hvis du arbejder i en virksomhed, hvor ændringer hurtigt bliver til “endnu et projekt”, kan det også være en hjælp at tænke NIS2-leverandørsporet som et forandringsforløb i miniature. Der er meget inspiration at hente i artiklerne om forandringsledelse, hvis du vil have flere greb til at få kollegerne med på rejsen.