⚡ LIMITED TIME Get our FREE €500+ Compliance Starter Kit
Get It Now →

Det svage led: CISO’ens drejebog til opbygning af et program for risikostyring i forsyningskæden i overensstemmelse med NIS2

Igor Petreski
21 min read
Flowdiagram, der viser CISO’ens 15-trins drejebog til opbygning af et program for risikostyring i forsyningskæden i overensstemmelse med NIS2, herunder hele leverandørlivscyklussen fra fastlæggelse af politikker og risikoniveauinddeling til løbende overvågning, hændelseshåndtering og revisionsforberedelse på tværs af flere regelsæt.

Alarmen virkede harmløs – en mindre afvigelse fra en tredjeparts overvågningstjeneste. For Anya, CISO i en mellemstor logistikvirksomhed, var det den tredje notifikation på en måned fra samme leverandør: “Anomali ved login registreret.” Leverandøren, en lille, men kritisk udbyder af flådestyringssoftware, forsikrede hende om, at det ikke var noget. En falsk positiv. Men Anya vidste bedre. Det var ikke bare teknisk støj; det var rystelser, der varslede en dybere ustabilitet i en kritisk del af forsyningskæden. Nu hvor hendes virksomhed var klassificeret som en “vigtig enhed” efter NIS2-direktivet, føltes rystelserne som forvarslet til et jordskælv.

Den gamle måde at styre leverandører på – et håndtryk og en løst formuleret kontrakt – er definitivt forbi. NIS2 gør det klart, at en organisations cybersikkerhed kun er så stærk som det svageste led. Det svage led er ikke længere “derude” – det findes inde i forsyningskæden. Under NIS2 er manglende styring af leverandørrisiko ikke blot en teknisk forsømmelse. Det er en regulatorisk trussel på bestyrelsesniveau med driftsmæssige, omdømmemæssige og finansielle konsekvenser. Anyas problem var ikke kun én ustabil leverandør. Det var en systemisk sårbarhed, indvævet i driften – og revisorerne ville lede efter den. Hun havde brug for mere end en hurtig løsning; hun havde brug for en drejebog.

Denne vejledning leverer den drejebog. Vi gennemgår en struktureret tilgang for CISO’er, complianceansvarlige og revisorer til at opbygge et dokumenterbart program for risikostyring i forsyningskæden på tværs af regelsæt. Ved at anvende en robust ramme som ISO/IEC 27001:2022 og Clarysec’s ekspertværktøjer kan du koble presserende risici i forsyningskæden med praktiske metoder til at opfylde NIS2, DORA, GDPR og beslægtede krav.

Risikomandatet: Sådan redefinerer NIS2 sikkerhed i forsyningskæden

NIS2-direktivet flytter sikkerhed i forsyningskæden fra bedste praksis til en retligt bindende forpligtelse. Det kræver en risikobaseret og løbende tilgang til sikring af IKT- og OT-forsyningskæder, udvider omfanget på tværs af mange sektorer og gør ledelsen direkte ansvarlig for manglende efterlevelse. Det betyder:

  • Udvidet omfang: Alle leverandører, underdatabehandlere, cloududbydere og outsourcingpartnere, der berører dit IKT-miljø, er omfattet.
  • Løbende forbedring: NIS2 kræver en levende proces for risikovurdering, overvågning og tilpasning – ikke en engangsgennemgang. Processen skal drives af både interne hændelser (sikkerhedshændelser, brud) og eksterne ændringer (ny lovgivning, ændringer i leverandørtjenester).
  • Obligatoriske kontroller: Hændelseshåndtering, sårbarhedsstyring, regelmæssig sikkerhedstest og robust kryptering skal nu håndteres på tværs af forsyningskæden – ikke kun inden for egen perimeter.

Det udvisker grænserne mellem intern sikkerhed og tredjepartsrisiko. Leverandørens cybersikkerhedsbrist bliver din regulatoriske krise. En struktureret ramme som ISO/IEC 27001:2022 bliver uundværlig, fordi den giver de kontroller og processer, der skal til for at opbygge et robust og revisionsbart program, som opfylder NIS2’s krav. Rejsen begynder ikke med teknologi, men med en strategi, der fokuserer på tre centrale kontroller:

  • 5.19 - Informationssikkerhed i leverandørrelationer: Etablering af den strategiske ramme for styring af leverandørrisiko.
  • 5.20 - Håndtering af informationssikkerhed i leverandøraftaler: Omsætning af sikkerhedsforventninger til retligt bindende kontrakter.
  • 5.22 - Overvågning, gennemgang og ændringsstyring af leverandørtjenester: Sikring af løbende tilsyn og tilpasning gennem hele leverandørlivscyklussen.

Behersker du disse tre områder, kan forsyningskæden ændres fra en kilde til bekymring til et velstyret, efterlevende og robust aktiv.

Trin 1: Opbyg styringsgrundlaget med kontrol 5.19

Anyas første erkendelse var, at hun ikke kunne behandle alle leverandører ens. Leverandøren af kontorartikler var ikke det samme som leverandøren af den kritiske flådestyringssoftware. Det første skridt i opbygningen af et program i overensstemmelse med NIS2 er at forstå og klassificere leverandørøkosystemet ud fra risiko.

Kontrol 5.19, Informationssikkerhed i leverandørrelationer, er den strategiske hjørnesten. Den tvinger organisationen til at gå videre end en simpel leverandørliste og etablere et niveauinddelt styringssystem. Processen skal være drevet af en klar politik, der er godkendt af bestyrelsen. Clarysec’s Politik for tredjeparts- og leverandørsikkerhed knytter aktiviteten direkte til organisationens bredere ramme for risikostyring:

P6 – Politik for risikostyring. Vejleder i identifikation, vurdering og afbødning af risici forbundet med tredjepartsrelationer, herunder nedarvede eller systemiske risici fra leverandørøkosystemer.” Fra afsnittet ‘Relaterede politikker og sammenhænge’, politikklausul 10.2.

Denne integration sikrer, at risici fra afhængigheder længere nede i leverandørkæden – eller eksponeringer hos “fjerdeparter” – styres som en del af organisationens eget ISMS. Selve klassificeringsprocessen bør være metodisk. I trin 23 i fasen ‘Revision og forbedring’ guider Zenith Blueprint: En revisors 30-trins køreplan organisationer til at klassificere leverandører ud fra centrale spørgsmål:

  • Håndterer eller behandler leverandøren dine følsomme eller regulerede oplysninger?
  • Leverer leverandøren infrastruktur eller platforme, som dine kritiske driftsaktiviteter afhænger af?
  • Administrerer eller vedligeholder leverandøren systemer på dine vegne?
  • Kan en kompromittering hos leverandøren direkte påvirke dine mål for fortrolighed, integritet eller tilgængelighed?

Anya brugte denne logik til at revurdere sin leverandør af flådestyringssoftware. Leverandøren behandlede lokationsdata i realtid (følsomme), platformen var integreret i den daglige drift (kritisk infrastruktur), og en kompromittering kunne stoppe leverancer (høj påvirkning af tilgængelighed). De blev straks omklassificeret fra en “standardleverandør” til en “kritisk højrisikoleverandør”.

Denne risikobaserede niveauinddeling bestemmer omfanget af due diligence, kontraktuel stringens og løbende overvågning. Som vores Zenith Controls: Vejledningen til efterlevelse på tværs af rammeværker præciserer, er denne tilgang direkte afstemt med forventningerne i centrale regelsæt.

ReguleringKravHvordan kontrol 5.19 adresserer det
NIS2Article 21(2)(d) pålægger risikostyring i forsyningskæden.Giver rammen for at identificere og niveauinddele leverandørrisiko.
DORAArticles 28-30 kræver klassificering af kritiske IT- og finansielle tjenesteleverandører.Etablerer processen for klassificering af IKT-udbydere efter kritikalitet.
GDPRArticle 28 kræver, at dataansvarlige kun anvender databehandlere, der giver garantier.Danner grundlaget for den due diligence, der er nødvendig for at vurdere garantier.

Dette grundlæggende trin er ikke kun en intern øvelse; det er fundamentet for hele det dokumenterbare program for sikkerhed i forsyningskæden.

Trin 2: Skab bindende aftaler med kontrol 5.20

Da Anya havde identificeret højrisikoleverandøren, fandt hun kontrakten frem. Det var en standardindkøbsskabelon med en vag fortrolighedsklausul og næsten intet om cybersikkerhed. Den indeholdt ingen specifikke sikkerhedskontroller, ingen underretningsfrist ved brud og ingen revisionsret. Set med en NIS2-revisors øjne var den værdiløs.

Her bliver kontrol 5.20, Håndtering af informationssikkerhed i leverandøraftaler, kritisk. Kontrollen er mekanismen til at omsætte de risici, der identificeres i 5.19, til bindende, retligt forpligtende krav. En kontrakt er ikke kun et kommercielt dokument; den er en primær sikkerhedskontrol.

Politikkerne skal drive denne ændring. Politik for tredjeparts- og leverandørsikkerhed fastlægger dette som et centralt mål:

“Tilpas tredjeparts sikkerhedskontroller til gældende regulatoriske og kontraktlige forpligtelser, herunder GDPR, NIS2, DORA og ISO/IEC 27001-standarder.” Fra afsnittet ‘Mål’, politikklausul 3.6.

Denne klausul ændrer politikken fra en retningslinje til et direkte mandat for indkøbs- og juridiske teams. For Anya betød det, at hun måtte vende tilbage til leverandøren for at genforhandle. Det nye kontrakttillæg omfattede specifikke, ufravigelige klausuler:

  • Underretning ved brud: Leverandøren skal rapportere enhver mistanke om sikkerhedshændelse, der påvirker virksomhedens data eller tjenester, inden for 24 timer – ikke “inden for en rimelig frist”.
  • Revisionsrettigheder: Virksomheden har ret til årligt at gennemføre sikkerhedsvurderinger eller anmode om tredjepartsrevisionsrapporter (f.eks. en SOC 2 Type II).
  • Sikkerhedsstandarder: Leverandøren skal overholde konkrete sikkerhedskontroller, f.eks. multifaktorgodkendelse for al administratoradgang og regelmæssige sårbarhedsscanninger af platformen.
  • Styring af underdatabehandlere: Leverandøren skal oplyse om og indhente forudgående skriftlig godkendelse af egne underleverandører, der skal håndtere virksomhedens data.
  • Exit-strategi: Kontrakten skal definere procedurer for sikker returnering eller destruktion af data ved ophør og sikre en kontrolleret offboarding-proces.

Som Zenith Controls fremhæver, er denne praksis central i flere rammeværker. GDPR’s Article 28(3) kræver detaljerede databehandleraftaler. DORA’s Article 30 foreskriver en omfattende liste over kontraktlige bestemmelser for kritiske IKT-udbydere. Ved at implementere en robust kontrol 5.20 opfyldte Anya ikke blot ISO/IEC 27001:2022; hun opbyggede samtidig en dokumenterbar position til NIS2-, DORA- og GDPR-revisioner.

Trin 3: Vagttårnet – løbende overvågning med kontrol 5.22

Anyas oprindelige problem – de tilbagevendende sikkerhedsalarmer – skyldtes en klassisk fejl: “underskriv og glem”. En stærk kontrakt er uden værdi, hvis den arkiveres og aldrig bruges igen. Den sidste brik i puslespillet er kontrol 5.22, Overvågning, gennemgang og ændringsstyring af leverandørtjenester. Det er den operationelle kontrol, der sikrer, at løfterne i kontrakten efterleves.

Denne kontrol ændrer leverandørstyring fra en statisk onboarding-aktivitet til en dynamisk og løbende proces. Ifølge Zenith Controls omfatter det flere indbyrdes forbundne aktiviteter:

  • Gennemgang af performance: Regelmæssigt planlagte møder (f.eks. kvartalsvis for højrisikoleverandører) for at drøfte performance op imod sikkerheds-SLA’er, gennemgå hændelsesrapporter og planlægge kommende ændringer.
  • Gennemgang af revisionsartefakter: Proaktiv indhentning og analyse af leverandørens revisionsrapporter, certificeringer og resultater fra penetrationstest. En revisor vil kontrollere, om rapporterne ikke kun indsamles, men også om eventuelle undtagelser i dem aktivt spores og håndteres.
  • Ændringsstyring: Når en leverandør ændrer sin tjeneste – f.eks. ved at migrere til en ny cloududbyder eller indføre en ny API – skal det udløse en sikkerhedsgennemgang hos dig. Det forhindrer, at leverandører uforvarende introducerer nye risici i dit miljø.
  • Løbende overvågning: Anvendelse af værktøjer og feeds med trusselsintelligens til at holde sig informeret om leverandørens eksterne sikkerhedstilstand. Et pludseligt fald i en sikkerhedsvurdering eller nyheder om et brud bør udløse en øjeblikkelig respons.

Denne løbende sløjfe af overvågning, gennemgang og tilpasning er kernen i den “løbende risikostyringsproces”, som NIS2 kræver. Den sikrer, at tillid aldrig antages; den verificeres løbende.

Et handlingsrettet eksempel: Tjekliste for leverandørgennemgang

For at gøre dette praktisk udarbejdede Anyas team en tjekliste til de nye kvartalsvise gennemgange med leverandøren af flådestyring baseret på de revisionsmetoder, der er beskrevet i Zenith Controls.

GennemgangsområdeBevismateriale, der skal indsamles og drøftesØnsket resultat
SLA og performanceOppetidsrapporter, hændelseslogfiler, svartider for løsning af supportsager.Verificér efterlevelse af kontraktlige forpligtelser om tilgængelighed og support.
SikkerhedshændelserDetaljeret rapport om alle sikkerhedsalarmer (herunder “falske positiver”), rodårsagsanalyse og afhjælpende foranstaltninger.Bekræft transparent rapportering og effektiv håndtering af hændelser.
Efterlevelse og revisionerSeneste SOC 2-rapport eller sammenfatning af penetrationstest.Gennemgå konstateringer og følg leverandørens afhjælpningsplan for identificerede sårbarheder.
SårbarhedsstyringRapporter om patchkadence for kritiske systemer.Sikr, at leverandøren opfylder sin forpligtelse til rettidig patchning af kritiske sårbarheder.
Kommende ændringerDrøftelse af leverandørens produktkøreplan, ændringer i infrastruktur eller nye underdatabehandlere.Vurdér proaktivt sikkerhedsmæssige konsekvenser af fremtidige ændringer, før de implementeres.

Dette enkle værktøj ændrede dialogen fra et generisk statusmøde til et fokuseret, evidensbaseret møde om sikkerhedsstyring og skabte et revisionsbart grundlag for løbende tilsyn.

Fastlæg grænsen: Risikoaccept i en NIS2-verden

Den indledende hændelse med leverandøren tvang Anya til at forholde sig til et grundlæggende spørgsmål: Hvilket risikoniveau er acceptabelt? Selv med de bedste kontrakter og den bedste overvågning vil der altid være en vis restrisiko. Derfor er en klar, ledelsesgodkendt definition af risikoacceptkriterier ufravigelig.

I trin 10 i fasen ‘Risiko og implementering’ giver Zenith Blueprint vigtig vejledning om dette punkt. Det er ikke nok at sige “vi accepterer lave risici”. Det skal defineres, hvad det betyder i sammenhæng med retlige og regulatoriske forpligtelser.

“Medtag også retlige/regulatoriske krav i acceptkriterierne. Nogle risici kan være uacceptable uanset sandsynlighed på grund af lovgivning … På samme måde pålægger NIS2 og DORA visse grundlæggende sikkerhedskrav – manglende opfyldelse af dem (selv hvis sandsynligheden for en hændelse er lav) kan udgøre en uacceptabel efterlevelsesrisiko. Indarbejd disse perspektiver, f.eks.: “Enhver risiko, der kan føre til manglende efterlevelse af gældende lovgivning (GDPR osv.), er ikke acceptabel og skal afbødes.””

Det ændrede spillereglerne for Anya. Hun samarbejdede med juridisk afdeling og indkøb om at opdatere deres politik for risikostyring. De nye kriterier fastslog eksplicit, at enhver kritisk leverandør, der ikke opfylder de grundlæggende sikkerhedskrav fastsat i NIS2, udgør en uacceptabel risiko og udløser en øjeblikkelig risikobehandlingsplan. Det fjernede uklarhed fra beslutningstagningen og skabte en klar styringsudløser. Som angivet i Politik for tredjeparts- og leverandørsikkerhed:

“Højrisikoundtagelser (f.eks. leverandører, der håndterer regulerede data eller understøtter kritiske systemer) skal godkendes af CISO, juridisk afdeling og indkøbsledelsen og registreres i ISMS-undtagelsesregisteret.” Fra afsnittet ‘Risikobehandling og undtagelser’, politikklausul 7.3.

Revisoren er ankommet: Håndtering af kontrol fra flere perspektiver

Seks måneder senere, da de interne revisorer ankom for at gennemføre en vurdering af NIS2-parathed, var Anya forberedt. Hun vidste, at de ville se hendes program for forsyningskæden gennem flere perspektiver.

  • ISO/IEC 27001:2022-revisoren: Denne revisor fokuserede på proces og bevismateriale. De bad om leverandørfortegnelsen, verificerede risikokategoriseringen, udtog stikprøver af kontrakter for konkrete sikkerhedsklausuler og gennemgik referater fra kvartalsvise gennemgangsmøder. Hendes strukturerede tilgang, bygget på kontrollerne 5.19, 5.20 og 5.22, gav et klart revisionsspor.

  • COBIT 2019-revisoren: Med et styringsperspektiv ønskede denne revisor at se koblingen til forretningsmålene. De spurgte, hvordan leverandørrisiko blev rapporteret til direktionens risikokomité. Anya fremlagde sit risikoregister, der viste, hvordan leverandørens risikovurdering var fastlagt, og hvordan den blev afstemt med virksomhedens samlede risikovillighed.

  • NIS2-assessoren: Denne person havde skarpt fokus på systemisk risiko for væsentlige tjenester. Det handlede ikke kun om kontrakten; de ville vide, hvad der ville ske, hvis leverandøren gik helt offline. Anya gennemgik sin Business Continuity Plan (BCP), som nu indeholdt et afsnit om svigt hos kritiske leverandører, udviklet i overensstemmelse med principperne i ISO/IEC 22301:2019.

  • GDPR-revisoren: Da leverandøren behandlede lokationsdata, fokuserede denne revisor straks på databeskyttelse. De anmodede om databehandleraftalen (DPA) og bevismateriale for hendes due diligence med henblik på at sikre, at leverandøren gav “tilstrækkelige garantier”, som krævet i Article 28. Fordi processen havde integreret databeskyttelse fra starten, var DPA’en robust.

Dette revisionsperspektiv fra flere vinkler viser, at et velimplementeret ISMS baseret på ISO/IEC 27001:2022 ikke kun opfylder én standard. Det skaber en robust og dokumenterbar position på tværs af hele det regulatoriske landskab. Tabellen nedenfor opsummerer, hvordan disse trin skaber revisionsbevismateriale til enhver kontrol.

TrinPolitik-/kontrolreferenceNIS2-kortlægningGDPR-kortlægningDORA-kortlægningHandlingsbevis
Niveauinddel leverandører5.19, Blueprint S10/S23Article 21Article 28Art. 28-30Risikoniveauinddelt leverandørfortegnelse i ISMS.
Sikkerhedsklausuler i kontrakter5.20, ISO/IEC 27036-2Article 22Article 28(3)Art. 30Eksempelkontrakter med sikkerhedstillæg, SLA’er.
Løbende gennemgang5.22, ISO/IEC 22301Article 21Article 32Art. 31Mødereferater, performancedashboards, revisionslogfiler.
Vilkår om databeskyttelse5.20, ISO/IEC 27701Betragtning 54Arts. 28, 32Art. 30Underskrevne databehandleraftaler (DPA’er).
Underretning om hændelser5.22, ISO/IEC 27036-2Article 23Arts. 33, 34Art. 31Leverandørens hændelseslogfiler, kommunikationsregistreringer.
Exit/ophør5.20, ISO/IEC 27001:2022 A.5.11Relevant for robusthedArticle 28(3)Art. 30Destruktionscertifikater for data, offboarding-tjeklister.

Din drejebog til handling

Anyas historie er ikke unik. CISO’er og complianceansvarlige i hele EU står over for den samme udfordring. Truslen om regulatoriske bøder og det personlige ansvar, som NIS2 pålægger, gør forsyningskæderisiko til et forretningskritisk anliggende. Den gode nyhed er, at vejen frem er klar. Ved at anvende den strukturerede, risikobaserede tilgang i ISO/IEC 27001:2022 kan du opbygge et program, der både efterlever kravene og reelt styrker robustheden.

Vent ikke på, at en hændelse tvinger dig til handling. Begynd at opbygge din styringsramme for forsyningskæden i overensstemmelse med NIS2 i dag:

  1. Etablér styring: Brug Clarysec’s Politik for tredjeparts- og leverandørsikkerhed - SMV eller virksomhedsskabeloner til at definere jeres regler for samarbejde.
  2. Kend dit økosystem: Anvend klassificeringskriterierne fra Zenith Blueprint til at identificere og niveauinddele dine kritiske højrisikoleverandører.
  3. Styrk dine kontrakter: Revider eksisterende leverandøraftaler op imod kravene i ISO/IEC 27001:2022 kontrol 5.20, og brug vejledningen om efterlevelse på tværs af rammeværker i Zenith Controls til at opfylde forventningerne i NIS2, DORA og GDPR.
  4. Implementér løbende overvågning: Planlæg den første kvartalsvise sikkerhedsgennemgang med din mest kritiske leverandør, og brug vores tjekliste som vejledning. Dokumentér alle konstateringer i dit ISMS.
  5. Forbered revisionsbevismateriale: Saml eksempelkontrakter, referater fra gennemgange, hændelseslogfiler og risikovurderinger, der er kortlagt til de centrale kontroller for hver kritisk leverandør.

Din forsyningskæde behøver ikke være dit svageste led. Med den rette ramme, de rette processer og de rette værktøjer kan du gøre den til en styrke og en hjørnesten i din cybersikkerhedsstrategi.

Klar til at opbygge en forsyningskæde, der tilfredsstiller både tilsynsmyndigheder og bestyrelsen? Download Clarysec Zenith Blueprint, og fremskynd rejsen mod efterlevelse og robusthed i dag.

Frequently Asked Questions

About the Author

Igor Petreski

Igor Petreski

Compliance Systems Architect, Clarysec LLC

Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council

Share this article

Related Articles

Fra efterlevelse til robusthed: Sådan lukker informationssikkerhedschefer styringskløften

Fra efterlevelse til robusthed: Sådan lukker informationssikkerhedschefer styringskløften

Tjeklister for efterlevelse forhindrer ikke sikkerhedsbrud; aktiv styring gør. Vi gennemgår informationssikkerhedschefens største styringsmyter med udgangspunkt i en virkelig hændelse og giver en køreplan for at opbygge reel organisatorisk robusthed med konkrete trin, eksempler på politikformuleringer og kortlægninger på tværs af ISO 27001:2022, NIS2, DORA og flere andre rammeværker.