NIS2-leverandørkontrakter med ISO 27001-bevismateriale

Klokken er 07:40 en mandag morgen. CISO’en for en cloudbaseret logistikplatform åbner en e-mail fra en leverandør af Managed Detection and Response (MDR). Beskeden er kort, forsigtig og ubehagelig: Leverandøren har konstateret mistænkelig adgang til et supportmiljø, som anvendes af flere kunder. Detaljerne er begrænsede. Leverandøren lover en opdatering “så hurtigt som praktisk muligt”.

Klokken 08:15 spørger den compliance-ansvarlige, om dette kan udløse NIS2-rapportering. Klokken 08:40 leder indkøb efter kontrakten. Klokken 09:10 ønsker bestyrelsessekretæren en briefing om ledelsesansvar. Klokken 10:00 spørger juridisk afdeling, om kontrakten indeholder 24-timers underretning, revisionsrettigheder, kontroller for underleverandører, adgang til bevismateriale, forpligtelser vedrørende forretningskontinuitet, tilbagelevering af data og bestemmelser om sletning.

Ingen ønsker under en igangværende hændelse at opdage, at en kritisk leverandøraftale kun omtaler “rimelige sikkerhedsforanstaltninger”.

Det er her, NIS2-klausuler i leverandørkontrakter ophører med at være juridisk standardtekst og bliver til operationelle kontroller. For væsentlige og vigtige enheder er leverandørstyring nu en del af bestyrelsesansvar, tilsynsdokumentation, hændelsesberedskab, assurance over for kunder, efterlevelse af databeskyttelseskrav og robusthedsplanlægning. En underskrevet kontrakt er ikke tilstrækkelig. Organisationen skal kunne dokumentere, at leverandørrisici er identificeret, godkendt, behandlet, overvåget og dokumenteret.

Clarysecs tilgang bygger på et enkelt princip: Hvis leverandørklausulen ikke kan overvåges, dokumenteres og testes, er den ikke en kontrol.

Zenith Blueprint: En revisors 30-trins køreplan placerer leverandørrelationer i fasen Kontroller i praksis, trin 23, hvor aftaler, overvågning, onboarding, revurdering og revisionsbevismateriale omsættes til praktisk ISMS-arbejde. Zenith Controls: Vejledning til kortlægning på tværs af efterlevelseskrav kortlægger derefter ISO/IEC 27002:2022-leverandørkontroller til NIS2, DORA, GDPR, NIST, COBIT 2019, understøttende ISO-standarder og revisionsmetodikker.

Resultatet er en model for leverandørstyring, som indkøb, juridisk afdeling, sikkerhed, databeskyttelse og bestyrelsen alle kan anvende.

Hvorfor NIS2 gør leverandørkontrakter til registreringer med bevismateriale

NIS2 Article 20 kræver, at ledelsesorganer i væsentlige og vigtige enheder godkender foranstaltninger til styring af cybersikkerhedsrisici, fører tilsyn med implementeringen og kan holdes ansvarlige for overtrædelser. Article 21 kræver passende og forholdsmæssige tekniske, operationelle og organisatoriske foranstaltninger, herunder risikoanalyse, håndtering af hændelser, forretningskontinuitet, forsyningskædesikkerhed, sikker anskaffelse og vedligeholdelse, vurdering af effektivitet, cyberhygiejne, kryptografi, personalesikkerhed, adgangsstyring, styring af aktiver og MFA, hvor det er relevant.

Article 21(3) gør leverandør-due diligence eksplicit. Organisationer skal tage højde for sårbarheder, der er specifikke for direkte leverandører og tjenesteudbydere, den samlede kvalitet af produkter og cybersikkerhedspraksis samt procedurer for sikker udvikling.

Denne formulering skaber en praktisk forpligtelse: Leverandørrelationer skal være risikobaserede, kontraktligt håndhævelige og kunne gennemgås. Et leverandørspørgeskema gemt i en mappe er ikke nok. En generisk kontrakt uden hændelsesfrist, uden dokumentationsrettigheder og uden synlighed over underleverandører er ikke nok. En leverandørcertificering, som ingen har gennemgået, er ikke nok.

ISO/IEC 27001:2022 giver driftsmodellen. Punkt 4.1 til 4.4 kræver, at organisationen forstår kontekst, interessenter, retlige og kontraktlige forpligtelser, ISMS-omfang og afhængigheder. Punkt 5.1 til 5.3 kræver lederskab, politik, roller og rapportering. Punkt 6.1.1 til 6.1.3 kræver risikovurdering, risikobehandling og anvendelighedserklæring. Punkt 8.1 til 8.3 kræver operationel styring, gentagne risikovurderinger og dokumenterede resultater.

For leverandørstyring omfatter de vigtigste ISO/IEC 27002:2022 Annex A-kontroller:

• A.5.19 Informationssikkerhed i leverandørrelationer
• A.5.20 Håndtering af informationssikkerhed i leverandøraftaler
• A.5.21 Styring af informationssikkerhed i IKT-forsyningskæden
• A.5.22 Overvågning, gennemgang og ændringsstyring af leverandørtjenester
• A.5.24 Planlægning og forberedelse af hændelsesstyring
• A.5.25 Vurdering og beslutning om informationssikkerhedshændelser
• A.5.26 Respons på informationssikkerhedshændelser
• A.5.27 Læring fra informationssikkerhedshændelser
• A.5.28 Indsamling af bevismateriale
• A.5.29 Informationssikkerhed under driftsafbrydelser
• A.5.30 IKT-parathed til forretningskontinuitet
• A.5.31 Retlige, lovbestemte, regulatoriske og kontraktlige krav
• A.5.34 Databeskyttelse og beskyttelse af PII
• A.8.8 Styring af tekniske sårbarheder
• A.8.13 Sikkerhedskopiering af information
• A.8.15 Logning
• A.8.16 Overvågningsaktiviteter
• A.8.24 Brug af kryptografi
• A.8.32 Ændringsstyring

Nøglen er ejerskab. En klausul har begrænset værdi, medmindre nogen ejer risikoen, nogen gennemgår bevismaterialet, nogen følger op på undtagelser, og nogen eskalerer manglende efterlevelse.

Enterprise-udgaven af Politik for tredjeparts- og leverandørsikkerhed gør dette eksplicit:

“Rettigheder til at revidere, inspicere og anmode om sikkerhedsdokumentation”

Fra afsnittet “Styringskrav”, politikklausul 5.3.4.

For SMV’er fastsætter Politik for tredjeparts- og leverandørsikkerhed for SMV’er samme praktiske forventning:

“Revisionsrettigheder eller adgang til dokumentation for efterlevelse”

Fra afsnittet “Styringskrav”, politikklausul 5.3.4.

Denne sondring er vigtig. En mindre organisation kan muligvis ikke revidere alle større cloududbydere på stedet, men den kan kræve adgang til assurance-dokumentation, såsom ISO/IEC 27001:2022-certificeringsomfang, SOC-rapporter, sammenfatninger af penetrationstest, attester for afhjælpning af sårbarheder, hændelsessammenfatninger, testrapporter for forretningskontinuitet og bekræftelser på sletning af data.

Den struktur med tre kontroller, der bærer NIS2-leverandørassurance

I Clarysecs model for kortlægning på tværs af efterlevelseskrav udgør tre ISO/IEC 27002:2022-kontroller den bærende struktur for NIS2-leverandørstyring: 5.19, 5.20 og 5.22.

A.5.19 identificerer leverandørrisikoen

Kontrol A.5.19, Informationssikkerhed i leverandørrelationer, er fundamentet. Den kræver, at organisationer beskytter information og aktiver, som leverandører tilgår, behandler, opbevarer eller administrerer.

Zenith Controls kategoriserer dette som en forebyggende kontrol, der dækker fortrolighed, integritet og tilgængelighed, med cybersikkerhedskonceptet “Identificér” og den operationelle kapacitet “Sikkerhed i leverandørrelationer”. Den forbinder A.5.19 med A.5.20, A.5.21, A.5.14, A.5.36 og A.5.10. I praksis identificerer organisationen leverandørrisici, definerer sikkerhedsforventninger, styrer eksponering i IKT-forsyningskæden, beskytter informationsoverførsel, overvåger efterlevelse og udvider forpligtelser om acceptabel brug til eksterne parter.

For NIS2 kortlægges dette direkte til Article 21(2)(d) om forsyningskædesikkerhed og Article 21(3) om leverandør-due diligence. For GDPR understøtter det kravet om at anvende databehandlere, der giver tilstrækkelige garantier. For DORA understøtter det styring af IKT-tredjepartsrisici, due diligence før kontraktindgåelse, kritikalitetsgennemgang, koncentrationsrisiko og livscyklustilsyn.

A.5.20 gør kravet håndhæveligt

Kontrol A.5.20, Håndtering af informationssikkerhed i leverandøraftaler, omsætter sikkerhedsforventninger til kontraktlige forpligtelser. Zenith Controls forklarer tydeligt forholdet mellem A.5.19 og A.5.20:

“5.20 fungerer som den kontraktlige formalisering af de sikkerhedsbehov og risici, der er identificeret under 5.19. Hvor 5.19 omfatter vurdering af tredjepartsrisici og definition af sikkerhedsforventninger, sikrer 5.20, at disse forventninger bliver juridisk bindende gennem kontrakter eller service level agreements (SLA’er). Uden 5.20 ville de sikkerhedsforanstaltninger, der er identificeret i 5.19, mangle håndhævelighed.”

Det er her, NIS2-risikobeslutninger bliver til klausuler: underretning ved brud, revisions- og dokumentationsrettigheder, kryptering, adgangsstyring, sårbarhedsstyring, godkendelse af underleverandører, sikker overførsel, kontinuitet, regulatorisk samarbejde, exitbistand og sletning af data.

A.5.22 dokumenterer, at kontrakten lever

Kontrol A.5.22, Overvågning, gennemgang og ændringsstyring af leverandørtjenester, forhindrer, at leverandørassurance bliver en engangsøvelse ved onboarding. Zenith Controls knytter A.5.22 til A.5.19 og A.5.20, men også til A.5.29 om informationssikkerhed under driftsafbrydelser, A.8.8 om styring af tekniske sårbarheder, A.5.36 om efterlevelse af politikker, regler og standarder for informationssikkerhed, A.5.15 adgangsstyring og A.8.27 principper for sikker systemarkitektur og engineering.

Det er vigtigt, fordi leverandørtjenester ændrer sig. Datalokationer ændrer sig. Underdatabehandlere ændrer sig. Sårbarheder opstår. Certificeringer udløber. Hændelsesmønstre viser sig. En leverandør, der var acceptabel sidste år, kan være for risikabel i dag.

Hvad NIS2-klausuler i leverandørkontrakter bør omfatte

Zenith Blueprint, fasen Kontroller i praksis, trin 23, giver et praktisk sæt områder for leverandøraftaler:

“Nøgleområder, der typisk behandles i leverandøraftaler, omfatter:

✓ Fortrolighedsforpligtelser, herunder omfang, varighed og begrænsninger for videregivelse til tredjeparter; ✓ Ansvar for adgangsstyring, herunder hvem der kan tilgå dine data, hvordan legitimationsoplysninger administreres, og hvilken overvågning der er etableret; ✓ Tekniske og organisatoriske foranstaltninger til databeskyttelse, kryptering, sikker transmission, backup og forpligtelser vedrørende tilgængelighed; ✓ Tidsfrister og protokoller for hændelsesrapportering, ofte med definerede frister (f.eks. “underret inden for 24 timer”); ✓ Revisionsret, herunder frekvens, omfang og adgang til relevant bevismateriale (f.eks. rapporter fra penetrationstest, SoA, certificeringer); ✓ Kontroller for underleverandører, der kræver, at leverandøren viderefører tilsvarende sikkerhedsforpligtelser til sine downstream-partnere; ✓ Bestemmelser ved kontraktophør, såsom tilbagelevering eller destruktion af data, genopretning af aktiver og deaktivering af konti.”

Fra fasen Kontroller i praksis, trin 23: organisatoriske kontroller.

En stærk NIS2-leverandørklausul er specifik nok til at kunne testes. “Leverandøren skal opretholde passende sikkerhed” er svagt. “Leverandøren skal underrette kundens sikkerhedskontakt inden for 24 timer om bekræftede eller mistænkte hændelser, der påvirker kundesystemer, kundedata, tjenestens tilgængelighed eller regulatoriske rapporteringsforpligtelser” er revisionsklart.

Hændelsesklausuler skal matche NIS2-fristen for rapportering

NIS2 Article 23 etablerer en trinvis rapporteringsmodel for væsentlige hændelser: en tidlig varsling inden for 24 timer fra tidspunktet for kendskab, en hændelsesunderretning inden for 72 timer, mellemliggende rapporter, hvor det anmodes, og en endelig rapport inden for én måned efter hændelsesunderretningen. En væsentlig hændelse er en hændelse, der har forårsaget eller kan forårsage alvorlig driftsforstyrrelse, økonomisk tab eller betydelig materiel eller immateriel skade for andre.

Leverandørkontrakter skal understøtte denne tidslinje. Hvis en kritisk udbyder af administrerede tjenester bruger fire dage på at bekræfte, om kundemiljøer er påvirket, kan kunden overskride sit eget regulatoriske vindue.

Enterprise-udgaven af Politik for tredjeparts- og leverandørsikkerhed kræver:

“Frister for underretning ved brud (f.eks. inden for 24 eller 72 timer, afhængigt af kritikalitet og regulatoriske krav)”

Fra afsnittet “Styringskrav”, politikklausul 5.3.3.

SMV-politikken Politik for tredjeparts- og leverandørsikkerhed for SMV’er kræver også definerede frister for underretning ved brud fra afsnittet “Styringskrav”, politikklausul 5.3.3.

For PII-hændelser forbinder Enterprise-udgaven af Politik for håndtering af PII-hændelser og brud cybersikkerheds-, finanssektor-, kunde- og tjenestemodtagerrapportering:

“[Betinget] Den databeskyttelsesansvarlige / PIMS-ansvarlige SKAL koordinere enhver påkrævet sektor-, cybersikkerheds-, finanssektor-, kunde- eller tjenestemodtagerrelateret hændelsesrapportering, når en PII-hændelse med højt konsekvensniveau opfylder en relevant rapporteringstærskel, og SKAL registrere myndighed, modtager, tidslinje, indsendelse og bekræftelsesdokumentation i REG01 og REG10.”

Fra afsnittet “Underretning og kommunikation”, politikklausul 4.4.6.

Dette er modent NIS2-bevismateriale: ikke blot en underretningsmail, men en registrering af myndighed, modtager, tidslinje, indsendelse, bekræftelse, konsekvens, rodårsag og opfølgningshandlinger.

Tilpasning til databeskyttelse og DORA uden dobbelte leverandørprogrammer

Mange NIS2-leverandører behandler også personoplysninger. GDPR Article 28 kræver, at dataansvarlige anvender databehandlere, der giver tilstrækkelige garantier, og at databehandlerforpligtelser fastsættes i en skriftlig kontrakt. GDPR Article 5 kræver ansvarlighed for sikker og lovlig behandling. GDPR-forpligtelser ved brud kræver også hurtigt samarbejde, når leverandørhændelser påvirker personoplysninger.

Enterprise-udgaven af Politik for styring af databehandlere, underdatabehandlere og tredjeparter vedrørende databeskyttelse fastsætter godkendelseskontrollen:

“[Begge] Leverandør-/indkøbsansvarlig SKAL sikre, at kontrakter med databehandlere og underdatabehandlere omfatter bistand vedrørende databeskyttelse, sikkerhedsassurance, hændelsesgrænseflade gennem PII15, tilbagelevering eller sletning gennem PII10, kobling til overførsel gennem PII13 samt revisions- eller assurance-samarbejde før godkendelse.”

Fra afsnittet “Kontroller for kontrakt og dokumenteret instruks”, politikklausul 4.3.6.

Den kræver også gennemgang af bevismateriale før godkendelse:

“[Alle] Informationssikkerhedsansvarlig SKAL gennemgå dokumentation for sikkerhedsassurance for hver databehandler-, underdatabehandler- eller tredjepartsrelation med PII-adgang eller hosting før godkendelse og SKAL registrere resultatet i REG08 eller REG12.”

Fra afsnittet “Due diligence og risikovurdering”, politikklausul 4.2.2.

DORA tilføjer endnu et lag, når leverandøren betjener en finansiel enhed. DORA Articles 28 to 30 kræver styring af IKT-tredjeparter, registre over kontrakter om IKT-tjenester, risikobaseret due diligence, kritikalitetsvurdering, analyse af koncentrationsrisiko, revisions- og inspektionsrettigheder, ophørsrettigheder, exitstrategier og obligatoriske kontraktbestemmelser. Article 30 er særligt relevant, fordi den kræver kontraktindhold, der dækker tjenestebeskrivelser, lokationer, databeskyttelse, adgang og genopretning, serviceniveauer, bistand ved hændelser, samarbejde med myndigheder, revisionsrettigheder, underleverandører, beredskabsforanstaltninger og overgangsbistand.

Det praktiske svar er ikke tre separate leverandørprogrammer for NIS2, GDPR og DORA. Det er én harmoniseret leverandørmodel for bevismateriale, kortlagt på tværs af rammeværker.

NIST CSF 2.0 er nyttig, fordi GOVERN-funktionen kræver forståelse af afhængigheder, retlige forpligtelser, kontraktlige forpligtelser, risikovillighed, politikker, ansvarlighed og tilsyn. Kategorien for forsyningskæde, GV.SC, dækker leverandørroller, kritikalitet, kontraktkrav, due diligence, overvågning, inddragelse i hændelser, livscyklusovervågning og bestemmelser ved relationens ophør.

En Clarysec-arbejdsgang til onboarding af en kritisk leverandør

Antag, at I onboarder en udbyder af managed security services (MSSP), som skal overvåge endpoint-telemetri, modtage alarmer med brugeridentifikatorer og understøtte hændelsestriage for en organisation omfattet af NIS2.

Trin 1: Klassificér leverandøren

Registrér leverandøren i leverandørregisteret med tjenestebeskrivelse, systemer og data, der tilgås, PII-involvering, understøttelse af væsentlige eller vigtige tjenester, privilegeret adgang, lande for levering af tjenesten, underleverandører, fjerdepartsafhængigheder, kritikalitetsvurdering, risikoejer, indkøbsansvarlig og informationssikkerhedsgennemgår.

Dette implementerer ISO/IEC 27001:2022 punkt 4.2, 4.3, 6.1.2 og 8.1 ved at forbinde interessentkrav, afhængigheder, risikoejerskab og operationel styring.

Trin 2: Kortlæg risikoen til SoA

I Zenith Blueprint, fasen Risikostyring, trin 13, anbefaler Clarysec at krydshenvise regulering i risikoregisteret eller SoA:

“Krydshenvis regulering: Hvis bestemte kontroller implementeres specifikt for at efterleve GDPR, NIS2 eller DORA, kan du anføre det enten i risikoregisteret (som del af begrundelsen for risikokonsekvens) eller i SoA-noterne.”

Fra fasen Risikostyring, trin 13: planlægning af risikobehandling og anvendelighedserklæring.

For MSSP’en skal mindst A.5.19, A.5.20, A.5.21, A.5.22, A.5.24 til A.5.28, A.5.29, A.5.30, A.5.31, A.5.34, A.8.8, A.8.15, A.8.16 og A.8.24 medtages.

Trin 3: Kræv håndhævelige klausuler

Anvend et sikkerhedsaddendum til leverandøren, der kræver indledende hændelsesunderretning inden for 24 timer, detaljeret opdatering inden for 72 timer, endelig hændelsesrapportering, MFA for privilegeret adgang, navngivne brugerkonti, kontroller for underleverandører, sikker overførsel, kryptering, assurance-dokumentation, regulatorisk samarbejde, BCP- og DR-dokumentation, exitbistand, tilbagelevering eller sletning af data samt tilbagekaldelse af adgang.

Enterprise-udgaven af Politik for risikostyring af leverandørafhængigheder fastsætter kontinuitetskravet:

“Hvor det er relevant, et krav om, at leverandøren opretholder sine egne Business Continuity Plans (BCP/DRP) og hændelsesstyringsplaner, tester dem og på anmodning giver os sammenfatninger eller testrapporter.”

Fra afsnittet “Implementeringskrav”, politikklausul 6.8.4.

Trin 4: Opbyg bevispakken til assurance

Før godkendelse skal der anmodes om den underskrevne aftale, SLA, sikkerhedsaddendum, ISO/IEC 27001:2022-certificeringsomfang eller tilsvarende assurance, SOC-rapport hvor tilgængelig, ledelsessammenfatning af penetrationstest, sammenfatning af sårbarhedsstyring, sammenfatning af procedure for hændelseshåndtering, BCP- eller DR-testsammenfatning, attest for adgangsstyring og MFA, liste over underleverandører, procedure for sletning af data og exit samt DPA, hvor PII behandles.

SMV-politikken Politik for tredjeparts- og leverandørsikkerhed for SMV’er gør grundlæggende kontraktligt bevismateriale målbart:

“Underskrevne aftaler og SLA’er”

Fra afsnittet “Håndhævelse og efterlevelse”, politikklausul 8.3.2.1.

Den identificerer også tilbagevendende leverandørdokumentation:

“Gyldige sikkerhedscertificeringer eller opdateret bevismateriale for kontroller”

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.3.1.2.

For bredere leverandør-due diligence anfører Politik for revision og overvågning af efterlevelse:

“Leverandør-due diligence skal omfatte gennemgang af certificeringer (f.eks. ISO 27001, SOC 2), sikkerhedsspørgeskemaer og hændelsesregistreringer.”

Trin 5: Overvåg baseret på kritikalitet

Enterprise-udgaven af Politik for styring af databehandlere, underdatabehandlere og tredjeparter vedrørende databeskyttelse kræver kvartalsvis overvågning for PII-relationer med høj risiko:

“[Alle] Leverandør-/indkøbsansvarlig SKAL overvåge aktive højrisiko-databehandler- og underdatabehandlerrelationer kvartalsvist og andre aktive PII-databehandler- og underdatabehandlerrelationer årligt i forhold til due diligence-betingelser, kontraktstatus, assurance-status, åbne forhold og gennemgangsdatoer i REG08.”

Fra afsnittet “Løbende overvågning, bistand, grænseflade for videregivelse og exit”, politikklausul 4.5.1.

Sådan bliver A.5.22 reel. Gennemgangen bør afgøre, om leverandøren fortsat ligger inden for risikovilligheden, om bevismaterialet er aktuelt, om der findes åbne forhold, om der er indtruffet hændelser, og om tjenesteændringer kræver revurdering.

Hvordan revisorer tester NIS2-leverandørklausuler

Revisorer starter sjældent med at læse politikken isoleret. De udtager leverandører som stikprøver og følger beviskæden.

En ISO/IEC 27001:2022-revisor vil bede om leverandørfortegnelsen, risikoklassificering, leverandørkriterier, due diligence-registreringer, kontrakter, bevismateriale, SoA-kortlægning og overvågningshistorik. For Annex A 5.20 vil revisoren inspicere, om de udtagne kontrakter indeholder håndhævelige klausuler. For Annex A 5.22 vil revisoren teste, om rapporter er gennemgået, undtagelser er logget, og handlinger er fulgt op.

En NIS2-kompetent myndighed kan fokusere på, om leverandørers cybersikkerhedspraksis og procedurer for sikker udvikling er vurderet efter Article 21(3). En DORA-orienteret kontrollant kan bede om poster i IKT-kontraktregisteret, exitstrategier, analyse af koncentrationsrisiko og obligatoriske bestemmelser efter Article 30. En databeskyttelsesrevisor kan teste databehandlerkontrakter, videreførelse af krav til underdatabehandlere, grænseflader ved brud og dokumentation for tilstrækkelige garantier.

Enterprise-udgaven af Politik for PII-sikkerhed og adgangsstyring viser, hvordan adgangsstyring, sårbarheder, konfiguration, overvågning og kryptografi kobles tilbage til ISO/IEC 27001:2022:

“ISO/IEC 27001:2022 — punkt 6.1.3; punkt 8.1; Annex A-kontroller 8.1, 8.2, 8.3, 8.5, 8.8, 8.9, 8.15, 8.16, 8.20, 8.24. Behandlet af klausulerne [4.1.1; 4.1.2; 4.2.1; 4.2.3; 4.3.2; 4.4.1; 4.4.2; 4.5.1; 4.5.2; 4.6.1; 4.6.3; 4.7.1; 4.7.4; 4.7.5; 4.8.1; 4.8.2; 7.1.1; 7.1.2].”

Fra afsnittet “Referencestandarder og rammeværker”, politikklausul 13.9.

Når en leverandør har adgang til PII, privilegerede systemer eller overvågningsdata, er bevismateriale for adgangsstyring ikke adskilt fra leverandørassurance. Det er en del af samme revisionsspor.

Indkøbsfælden: underskrevne kontrakter uden assurance i driften

Den mest almindelige fejl i NIS2-leverandørstyring er ikke fraværet af kontrakter. Det er afstanden mellem kontraktteksten og den daglige drift.

En kontrakt kan kræve årlige sammenfatninger af penetrationstest, uden at nogen ansvarlig anmoder om dem. Den kan kræve hændelsesunderretning inden for 24 timer, mens leverandøren kun har en generisk supportadresse. Den kan kræve godkendelse af underleverandører, uden at indkøb nogensinde modtager ændringsunderretninger. Den kan indeholde revisionsrettigheder, uden at organisationen har en proces til at vurdere undtagelser i SOC-rapporter. Den kan kræve sletning af data ved exit, uden at IT nogensinde validerer deaktivering af konti.

Zenith Blueprint, fasen Kontroller i praksis, trin 23, forklarer, hvordan leverandørkontroller bliver levende:

“I praksis bliver denne kontrol virkelig gennem:

✓ Leverandørrisikovurderinger, ✓ Due diligence-spørgeskemaer før engagement, ✓ Kontraktskabeloner med indbyggede sikkerhedsvilkår, ✓ Tjeklister for leverandøronboarding, der omfatter adgangstildeling og opsætning af overvågning, ✓ Løbende revurderinger, især når leverandørens omfang ændrer sig, hændelser opstår, eller fornyelser nærmer sig.

Og denne kontrol stopper ikke ved leverandører i første led. Din leverandør kan outsource til sine egne udbydere, og du kan stadig bære risikoen.”

Det er NIS2-budskabet på bestyrelsesniveau: Outsourcing af tjenestelevering er ikke outsourcing af ansvarlighed.

Tjekliste til afhjælpning af NIS2-leverandørkontrakter

Start med de 20 mest kritiske leverandører, og gennemfør en fokuseret afhjælpningsøvelse:

• Identificér leverandører, der understøtter væsentlige eller vigtige tjenester.
• Bekræft, om hver leverandør behandler PII, understøtter regulerede tjenester eller har privilegeret adgang.
• Tildel en forretningsansvarlig, en indkøbsansvarlig og en sikkerhedsgennemgår.
• Verificér, at leverandørrisikovurderingen er aktuel og afstemt med det faktiske tjenesteomfang.
• Bekræft, at kontrakten indeholder grundlæggende sikkerhedskrav, hændelsesunderretning, revisions- eller dokumentationsrettigheder, kontroller for underleverandører, kontinuitet, sikker overførsel, adgangsstyring, samarbejde om sårbarheder og exitklausuler.
• Bekræft, at frister for brud understøtter behov for eskalering inden for 24 og 72 timer, hvor det er relevant.
• Anmod om opdateret assurance-dokumentation, herunder certificeringer, SOC-rapporter, sammenfatninger af penetrationstest, BCP- eller DR-tests og hændelseshistorik.
• Gennemgå bevismaterialet; opbevar det ikke blot.
• Log undtagelser, og tildel ansvarlige for afhjælpning.
• Opdater SoA og risikoregisteret, hvor leverandørkontroller understøtter NIS2, GDPR, DORA eller kundeforpligtelser.
• Planlæg overvågningsfrekvens baseret på leverandørens kritikalitet.
• Test én eskalationsvej for leverandørhændelser.
• Test én ophørsvej for en leverandør, herunder tilbagelevering af data, sletning, genopretning af aktiver og tilbagekaldelse af adgang.

Hvis disse punkter ikke kan dokumenteres for en kritisk leverandør, er kontrakten endnu ikke revisionsklar.

Gør leverandørklausuler til tilsynsdokumentation

NIS2-leverandørstyring er nu en levende operationel disciplin. Tilsynsmyndigheder, kunder, certificeringsrevisorer, databeskyttelsesteams, partnere i den finansielle sektor og bestyrelser vil ikke kun spørge, om leverandørklausuler findes. De vil spørge, om klausulerne er risikobaserede, håndhævelige, overvågede, dokumenterede og forbundet med hændelsesrapportering, kontinuitet, adgangsstyring, sårbarhedsstyring, videreførelse af krav til underleverandører og exit.

Clarysec hjælper organisationer med at lukke dette hul med Zenith Blueprint, der omsætter leverandørkontroller til ISMS-faser, risikobehandling, SoA-poster, onboardingrutiner og revisionsbevismateriale. Zenith Controls kortlægger ISO/IEC 27002:2022-leverandørkontrollerne A.5.19, A.5.20 og A.5.22 til NIS2, DORA, GDPR, NIST, COBIT 2019, understøttende ISO-standarder og revisionsmetodikker. Clarysecs leverandør- og databeskyttelsespolitikker leverer klausulstrukturen, forventningerne til bevismateriale og overvågningsrutinerne, der gør leverandørassurance forsvarlig.

Din næste handling er enkel: Vælg fem kritiske leverandører, udtag deres kontrakter som stikprøver, kortlæg hver klausul til ISO/IEC 27001:2022-risikobehandling og Annex A-kontroller, anmod om opdateret assurance-dokumentation, og gennemfør en tabletop-øvelse om hændelsesunderretning inden for 24 timer. Hvis beviskæden bryder sammen, giver Clarysecs værktøjssæt dig strukturen til at reparere den, før en hændelse, kundegennemgang eller tilsynsanmodning gør det for dig.