Ud over spørgeskemaet: CISO’ens definitive guide til revision af højrisikoleverandører for NIS2 og DORA

Rapporten landede på CISO Maria Valens skrivebord med et afdæmpet bump, der føltes mere som en sirene. Det var den indledende vurdering forud for deres kommende DORA-compliancegennemgang, og én linje var markeret med skarp rød farve: “Utilstrækkelig sikkerhed hos kritisk tredjepartsleverandør, CloudSphere.”
CloudSphere var ikke bare endnu en leverandør. De var rygraden i virksomhedens nye digitale bankplatform og behandlede millioner af transaktioner dagligt. Maria havde deres ISO/IEC 27001:2022-certifikat i arkivet. Hun havde også deres udfyldte sikkerhedsspørgeskema, et omfattende dokument med 200 spørgsmål. Men de indledende revisorer signalerede, at checkbox-compliance ikke længere var tilstrækkelig for en kritisk højrisikoleverandør. Spillereglerne havde ændret sig.
Med både NIS2-direktivet og forordningen om digital operationel modstandsdygtighed (DORA) i fuld kraft ser tilsynsmyndighederne nu længere end papirsporet. De kræver håndgribelig dokumentation for due diligence, løbende overvågning og robust styring af hele forsyningskæden. Marias udfordring er den samme, som CISO’er står med overalt: Hvordan går man ud over spørgeskemaet og reviderer og sikrer sine mest kritiske leverandører reelt? Det kræver et strategisk skifte fra passiv validering til aktiv, evidensbaseret sikkerhed.
Svagheden ved det statiske spørgeskema i en dynamisk verden
I årevis har sikkerhedsspørgeskemaet været hjørnestenen i tredjepartsrisikostyring. Men det er et statisk øjebliksbillede i et dynamisk trusselslandskab. En leverandørs risikoprofil er ikke fast; den ændrer sig med hver ny trussel, systemændring eller underleverandør, der onboardes. At basere sig udelukkende på selverklæring for en kritisk leverandør som CloudSphere svarer til at navigere gennem en storm med sidste års vejrkort.
NIS2-direktivet kræver eksplicit en risikobaseret tilgang, hvor sikkerhedsforanstaltninger skal stå i forhold til de faktiske risici. Det betyder, at et ensartet spørgeskema til alle leverandører grundlæggende ikke matcher moderne regulatoriske forventninger. Tiden, hvor et certifikat eller en udfyldt tjekliste kunne erstatte dokumentation, er forbi. Den reelle risiko ligger uden for papirsporet.
Her bliver en struktureret, livscyklusbaseret tilgang nødvendig. Det handler ikke om at opgive spørgeskemaer, men om at supplere dem med dybere og mere indgribende verificering for de leverandører, der virkelig betyder noget. Det er kerneprincippet i Clarysecs Politik for tredjeparts- og leverandørsikkerhed. Et af politikkens grundlæggende mål er at:
“Kræve formel due diligence og dokumenterede risikovurderinger, før der indgås aftaler med nye leverandører, eller serviceaftaler med høj risiko fornyes.”
- Fra afsnittet ‘Mål’, politikklausul 3.3
Denne klausul flytter tankegangen fra en simpel kontrol til en formel undersøgelse. Det er et afgørende første skridt i at opbygge et dokumenterbart program, der kan modstå tilsynsmæssig granskning.
Leverandørrisiko under NIS2 og DORA: De nye forventninger
Både NIS2 og DORA kræver, at organisationer systematisk identificerer, vurderer og løbende overvåger risici på tværs af leverandørlandskabet. De ændrer leverandørstyring fra en indkøbsfunktion til en central søjle i operationel modstandsdygtighed og informationssikkerhed.
Det nye regulatoriske klima kræver klare rammer, der er tæt kortlagt til etablerede standarder som ISO/IEC 27001:2022. Her er en overordnet oversigt over, hvad disse rammer forventer af jeres program for leverandørstyring:
| Krav | NIS2 | DORA | ISO/IEC 27001:2022-kontroller |
|---|---|---|---|
| Leverandørrisikovurdering | Article 21(2)(d) | Articles 28–30 | 5.19, 5.21 |
| Kontraktlige sikkerhedsklausuler | Article 21(3), Article 22 | Article 30 | 5.20 |
| Løbende overvågning | Article 21, Article 22 | Articles 30, 31 | 5.22 |
| Sårbarhedsstyring og hændelseshåndtering | Article 23 | Article 9, 11 | 5.29, 8.8 |
Et robust program for leverandørrevision behøver ikke opfindes fra bunden. ISO/IEC 27001:2022-rammen, særligt kontrollerne i Annex A, giver en stærk model. Hos Clarysec hjælper vi kunder med at opbygge programmet omkring tre forbundne kontroller, der tilsammen udgør en komplet livscyklus for leverandørstyring.
Opbygning af en dokumenterbar revisionsramme: ISO 27001:2022-livscyklussen
For at opbygge et program, der opfylder tilsynsmyndighedernes krav, skal I have en struktureret tilgang baseret på en globalt anerkendt standard. Leverandørsikkerhedskontrollerne i ISO/IEC 27001:2022 giver en livscyklus for håndtering af tredjepartsrisiko fra etablering til ophør. Lad os se på, hvordan Maria kan bruge denne livscyklus til at udarbejde en dokumenterbar revisionsplan for CloudSphere.
Trin 1: Fundamentet – Informationssikkerhed i leverandørrelationer (5.19)
Kontrol 5.19 er det strategiske udgangspunkt. Den kræver, at I etablerer formelle processer til at identificere, vurdere og styre de informationssikkerhedsrisici, der er forbundet med hele jeres leverandørøkosystem. Det er her, I definerer, hvad høj risiko betyder for organisationen, og fastsætter spillereglerne.
Clarysecs Zenith Controls: The Cross-Compliance Guide giver en detaljeret gennemgang af 5.19 og viser kontrollens rolle som et centralt omdrejningspunkt for leverandørstyring. Kontrollen er tæt knyttet til relaterede kontroller, f.eks. 5.21 (Informationssikkerhed i IKT-forsyningskæden), som dækker hardware- og softwarekomponenter, og 5.14 (Informationsoverførsel), som styrer sikker dataudveksling. En leverandørrelation kan ikke styres effektivt uden samtidig at kontrollere den teknologi, leverandøren leverer, og de data, I deler.
For Maria betyder det, at revisionen af CloudSphere skal gå længere end leverandørens generelle virksomhedssikkerhed og undersøge sikkerheden i den faktiske platform, de leverer. Zenith Controls-guiden fremhæver, at en stærk implementering af 5.19 direkte understøtter efterlevelse af væsentlige reguleringer:
- NIS2 (Article 21(2)(d)): Forpligter organisationer til at styre forsyningskæderisiko som en central del af deres sikkerhedsramme.
- DORA (Articles 28–30): Kræver en robust ramme for styring af IKT-tredjepartsrisiko, herunder klassificering efter kritikalitet og prækontraktuel due diligence.
- GDPR (Article 28): Kræver, at dataansvarlige kun anvender databehandlere, der giver tilstrækkelige garantier for databeskyttelse.
Denne kontrol kræver risikoklassificering af leverandører, løbende overvågning og rettidig tilbagekaldelse af adgang. Formålet er at sikre, at sikkerhed indarbejdes i leverandørens livscyklus og ikke blot tilføjes bagefter.
Trin 2: Håndhævelsen – Håndtering af informationssikkerhed i leverandøraftaler (5.20)
Et sikkerhedskrav, der ikke fremgår af kontrakten, er kun en anbefaling. Kontrol 5.20 er dér, hvor styring bliver juridisk bindende. For en højrisikoleverandør er kontrakten jeres stærkeste revisionsværktøj.
Som Zenith Controls understreger, skal disse aftaler være eksplicitte. Uklare løfter om sikkerhed efter branchens bedste praksis har begrænset værdi. For en leverandør som CloudSphere skal Maria verificere, at kontrakten indeholder specifikke, målbare klausuler, der giver hendes organisation konkret tilsyn:
- Revisionsret: En klausul, der eksplicit giver hendes organisation ret til at gennemføre tekniske vurderinger, gennemgå dokumentation eller engagere en tredjepart til at revidere på organisationens vegne.
- Frister for underretning om sikkerhedsbrud: Specifikke og stramme frister, f.eks. inden for 24 timer efter opdagelse, for at underrette hendes virksomhed om en sikkerhedshændelse – ikke blot en uklar formulering om “uden unødig forsinkelse”.
- Styring af underleverandører og fjerdeparter: En klausul, der kræver, at leverandøren håndhæver de samme sikkerhedsstandarder over for egne kritiske underleverandører og underretter hende om ændringer. Det er afgørende for at styre nedstrømsrisiko.
- Sikker exitstrategi: Klare forpligtelser for returnering eller certificeret destruktion af data ved kontraktophør.
DORA er særligt præskriptiv her. Article 30 oplister obligatoriske kontraktbestemmelser, herunder uhindret adgang for revisorer og tilsynsmyndigheder, specifikke oplysninger om tjenestelokationer og omfattende exitstrategier. Revisorer vil udtage stikprøver af kontrakter med højrisikoleverandører og kontrollere disse klausuler direkte.
Trin 3: Den løbende kontrolsløjfe – Overvågning, gennemgang og ændringsstyring af leverandørtjenester (5.22)
Det sidste element i livscyklussen er kontrol 5.22, som ændrer leverandørtilsyn fra et øjebliksbillede til en løbende proces. En revision bør ikke være en overraskelse, men et valideringspunkt i et løbende, transparent samarbejde.
Her kommer mange organisationer til kort. De får kontrakten underskrevet og arkiverer den. Men for højrisikoleverandører begynder det reelle arbejde efter onboarding. Zenith Controls-guiden kobler 5.22 til kritiske driftsprocesser som 8.8 (Styring af tekniske sårbarheder) og 5.29 (Informationssikkerhed under afbrydelse). Det betyder, at effektiv overvågning omfatter langt mere end et årligt gennemgangsmøde. Den omfatter:
- Gennemgang af tredjepartsdokumentation: Aktiv indhentning og analyse af leverandørens SOC 2 Type II-rapporter, resultater fra ISO 27001-overvågningsrevisioner eller resuméer af penetrationstest. Det afgørende er at gennemgå undtagelserne og følge afhjælpningen.
- Overvågning af hændelser: Opfølgning på offentligt kendte sikkerhedsbrud eller sikkerhedshændelser, der involverer leverandøren, og formel vurdering af den potentielle konsekvens for jeres organisation.
- Håndtering af ændringer: Implementering af en proces, hvor enhver væsentlig ændring i leverandørens tjeneste, f.eks. en ny datacenterlokation eller en ny kritisk underleverandør, automatisk udløser en fornyet risikovurdering.
Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap giver praktisk vejledning om dette, særligt i trin 24, som dækker underleverandørrisiko. Guiden anbefaler:
“For hver kritisk leverandør skal det identificeres, om leverandøren anvender underleverandører eller underdatabehandlere, der kan få adgang til jeres data eller systemer. Dokumentér, hvordan jeres informationssikkerhedskrav videreføres til disse parter… Hvor det er praktisk muligt, skal I anmode om en liste over nøgleunderleverandører og sikre, at jeres revisionsret eller mulighed for at opnå sikkerhed også gælder for dem.”
Dette er et afgørende punkt for Maria. Bruger CloudSphere en tredjepartsvirksomhed til dataanalyse? Er deres infrastruktur hostet i en større public cloud? Disse nedstrømsafhængigheder udgør en væsentlig og ofte usynlig risiko, som hendes revision skal synliggøre.
Fra teori til handling: Marias praktiske revisionsplan for CloudSphere
Med denne ISO 27001:2022-livscyklus udarbejder Marias team en ny revisionsplan for CloudSphere, der går langt ud over spørgeskemaet og dokumenterer den modne, risikobaserede styring, som tilsynsmyndighederne kræver.
Kontraktgennemgang: De starter med at kortlægge den eksisterende CloudSphere-kontrakt mod DORA Article 30 og bedste praksis for kontrol 5.20. De udarbejder en gap-analyserapport, der skal informere den næste fornyelsescyklus og prioritere områder i den aktuelle revision.
Målrettet anmodning om dokumentation: I stedet for et generisk spørgeskema sender de en formel anmodning om specifik dokumentation, herunder:
- Den seneste SOC 2 Type II-rapport og et resumé af, hvordan alle noterede undtagelser er blevet afhjulpet.
- Ledelsesresuméet fra deres seneste eksterne penetrationstest.
- En fuldstændig liste over alle underleverandører og fjerdeparter, der vil behandle eller få adgang til deres data.
- Dokumentation for, at sikkerhedskrav kontraktligt er videreført til disse underleverandører.
- Logfiler eller rapporter, der dokumenterer rettidig patching af kritiske sårbarheder, f.eks. Log4j og MOVEit, i de seneste seks måneder.
Teknisk validering: De anvender klausulen om revisionsret til at planlægge en særskilt teknisk gennemgang med CloudSpheres sikkerhedsteam. Dagsordenen fokuserer på deres playbooks for hændelseshåndtering, værktøjer til styring af cloud-sikkerhedstilstand og kontroller til forebyggelse af datalækage.
Formel undtagelsesstyring: Hvis CloudSphere afviser at levere bestemt dokumentation, er Maria forberedt. Hendes organisations styringsproces, som er defineret i Politik for tredjeparts- og leverandørsikkerhed, er klar:
“Højrisikoundtagelser, f.eks. leverandører, der håndterer regulerede data eller understøtter kritiske systemer, skal godkendes af CISO, Jura og indkøbsledelsen og registreres i ISMS-undtagelsesregisteret.”
- Fra afsnittet ‘Risikobehandling og undtagelser’, politikklausul 7.3
Det sikrer, at enhver afvisning af at levere dokumentation ikke blot ignoreres, men formelt risikoaccepteres på organisationens øverste niveauer – en proces, som revisorer anerkender.
Revisorens perspektiv: Hvad forskellige revisorer vil kræve
For at opbygge et reelt robust program skal I tænke som en revisor. Forskellige revisionsrammer har forskellige fokusområder, og det er afgørende at forudse deres spørgsmål. Her er et samlet overblik over, hvad forskellige revisorer vil kræve, når de gennemgår jeres program for leverandørstyring:
| Revisortype | Primært fokusområde og kontroller | Dokumentation, de vil kræve |
|---|---|---|
| ISO/IEC 27001:2022-revisor | 5.19, 5.20, 5.22 | Leverandørfortegnelse med risikoklassificeringer; stikprøveudtagne kontrakter for højrisikoleverandører til verificering af sikkerhedsklausuler; registreringer af due diligence og løbende gennemgangsmøder. |
| COBIT 2019-revisor | APO10 (Manage Suppliers), DSS04 (Manage Continuity) | Dokumentation for løbende performanceovervågning mod SLA’er; dokumentation for, hvordan leverandørrelaterede hændelser håndteres; registreringer af leverandørrisikogennemgange og ændringsstyring. |
| DORA / finansiel tilsynsmyndighed | Articles 28-30 | Kontrakten med den kritiske IKT-udbyder, kortlagt mod DORA’s obligatoriske klausuler; vurderingen af koncentrationsrisiko; dokumentation for test eller gennemgang af exitstrategi. |
| NIST SP 800-53-revisor | SA-9 (External System Services), SR Family (Supply Chain) | Dokumentation for plan for risikostyring af forsyningskæden; registreringer af leverandørens compliance-dokumentation, f.eks. FedRAMP og SOC 2; dokumentation for synlighed i fjerdepartsrisici. |
| ISACA / IT-revisor | ITAF Performance Standard 2402 | Logfiler, der dokumenterer, at adgang for fratrådt leverandørpersonale blev tilbagekaldt rettidigt; dokumentation for unikke, MFA-beskyttede konti til tredjepartsadgang; registreringer vedrørende hændelseshåndtering. |
Dette flerperspektiv viser, at et robust program ikke handler om at tilfredsstille én standard, men om at opbygge en helhedsorienteret styringsramme, der genererer den dokumentation, der skal til for at opfylde dem alle.
Kritiske faldgruber: Hvor leverandørrevisioner fejler
Mange programmer for leverandørtilsyn kommer til kort på grund af almindelige fejl, der kan undgås. Vær særligt opmærksom på disse kritiske faldgruber:
- Revision som enkeltstående begivenhed: At basere sig på enkeltstående revisioner under onboarding eller fornyelse i stedet for at implementere løbende overvågning.
- Certificeringsmæssig selvtilfredshed: At acceptere et ISO- eller SOC 2-certifikat for pålydende uden at gennemgå rapportens detaljer, omfang og undtagelser.
- Uklare kontrakter: Manglende eksplicitte, bindende klausuler om revisionsrettigheder, underretning om sikkerhedsbrud og datahåndtering.
- Mangelfuld leverandørfortegnelse: Manglende evne til at fremlægge en fuldstændig, risikoklassificeret fortegnelse over alle leverandører og de data, de har adgang til.
- Ignorering af nedstrømsrisiko: Manglende identifikation og styring af de risici, der følger af en leverandørs egne kritiske underleverandører, dvs. fjerdepartsrisiko.
- Uverificeret sårbarhedsstyring: Tillid til, at en leverandør patcher kritiske sårbarheder, uden at anmode om dokumentation.
Praktisk tjekliste for revision af højrisikoleverandører
Brug denne tjekliste, tilpasset fra Zenith Blueprint, til at sikre, at revisionsprocessen for hver højrisikoleverandør er grundig og dokumenterbar.
| Trin | Handling | Dokumentation, der skal indsamles og opbevares |
|---|---|---|
| Due diligence | Udfør og dokumentér en formel risikovurdering før onboarding eller fornyelse. | Udfyldt leverandørrisikoark; klassificeringsregistrering; due diligence-rapport. |
| Kontraktgennemgang | Verificér, at sikkerheds-, privatlivs- og revisionsklausuler er til stede og bindende. | Underskrevet kontrakt med fremhævede klausuler; juridisk godkendelse af gennemgang; databehandleraftale. |
| Løbende overvågning | Planlæg og gennemfør kvartalsvise eller årlige gennemgange baseret på risikoniveau. | Mødereferater; gennemgåede SOC 2- / ISO 27001-rapporter; resuméer af sårbarhedsscanninger. |
| Tilsyn med underleverandører | Identificér og dokumentér alle kritiske nedstrømsleverandører, dvs. fjerdeparter. | Liste over underdatabehandlere leveret af leverandøren; dokumentation for klausuler om videreførelse af sikkerhedskrav. |
| Sårbarhedsstyring | Kræv dokumentation for et modent sårbarhedsstyringsprogram. | Ledelsesresumé fra nylig penetrationstest; eksempler på sårbarhedsscanningsrapporter; tidslinjer for patching. |
| Hændelsesrapportering | Test og validér leverandørens proces for hændelsesunderretning. | Registreringer af tidligere hændelsesunderretninger; dokumenterede SLA’er for underretning om sikkerhedsbrud. |
| Ændringsstyring | Gennemgå alle væsentlige tekniske eller organisatoriske ændringer hos leverandøren. | Leverandørens ændringslogfiler; rapporter om fornyet risikovurdering udløst af ændringer. |
| Regulatorisk kortlægning | Kortlæg de implementerede kontroller direkte til kravene i NIS2, DORA og GDPR. | Intern compliance-kortlægningstabel; evidenslog til tilsynsmyndigheder. |
Konklusion: Opbygning af en robust og dokumenterbar forsyningskæde
Tiden med checkbox-compliance for kritiske leverandører er forbi. Den intense granskning fra reguleringer som NIS2 og DORA kræver et grundlæggende skifte mod en model med løbende, evidensbaseret sikkerhed. CISO’er som Maria skal gå forrest i arbejdet med at flytte organisationen ud over det statiske spørgeskema.
Ved at opbygge et program på den dokumenterede livscyklus i ISO/IEC 27001:2022-kontroller skaber I en ramme, der ikke kun er i overensstemmelse med kravene, men også reelt effektiv til at reducere risiko. Det indebærer, at leverandørsikkerhed behandles som en strategisk disciplin, at bindende krav indarbejdes i kontrakter, og at der opretholdes skærpet tilsyn gennem hele relationen.
Organisationens sikkerhed er kun så stærk som det svageste led, og i dagens forbundne økosystem ligger dette led ofte hos en tredjepart. Det er tid til at tage kontrollen tilbage.
Klar til at gå ud over spørgeskemaet?
Clarysecs integrerede værktøjssæt giver det fundament, I skal bruge for at opbygge et leverandørrisikostyringsprogram i topklasse, der kan modstå enhver revision.
- Download vores politikskabeloner: Implementér en robust styringsramme med vores virksomhedsmodne Politik for tredjeparts- og leverandørsikkerhed og den tilsvarende version til SMV’er.
- Følg Zenith Blueprint: Brug vores Zenith Blueprint: An Auditor’s 30-Step Roadmap til at implementere og revidere et compliant ISMS med særskilte trin til at mestre leverandørrisiko.
- Udnyt Zenith Controls: Anmod om en demo af vores Zenith Controls: The Cross-Compliance Guide for at kortlægge leverandørkontroller til NIS2, DORA, GDPR, NIST og mere, så jeres revisionsplan bliver dækkende og dokumenterbar.
Frequently Asked Questions
About the Author

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


