...
Artikler om NIS2 og penetrationstest
Kravet fra kunden: når NIS2 sendes ned gennem kæden
Kravet om en test kommer ikke nødvendigvis fra loven, men fra en kunde, der selv er omfattet af NIS2 og skal kunne vise, at risikoen ved leverandørerne er vurderet. Det kan stå i et brev, et kravbilag, en klausul om revision eller et spørgeskema.
→ Temaside: Kravet fra kunden: når NIS2 sendes ned gennem kæden
- Hvorfor kræver kunden en penetrationstest med henvisning til NIS2?
- Er vi selv omfattet af NIS2, eller er det kun kunden?
- Kundens brev om NIS2: sådan deler I kravene op
- Krav om årlig penetrationstest i leverandøraftalen: hvad forpligter I jer til?
- Kunden kræver test af en uafhængig tredjepart: hvad betyder uafhængig i aftalen?
- Kunden vil selv teste jeres løsning: hvad skal I aftale først?
- Ret til revision i aftalen: hvad det kan betyde for test af jeres systemer
- Krav, I skal sende videre til jeres egne underleverandører
- Flere NIS2-kunder med forskellige krav: én test eller flere?
- Kravet kommer i andet eller tredje led: hvem stiller det egentlig?
- Kunden henviser til både ISO 27001 og NIS2: hvilket testbevis passer til hvad?
- Testspørgsmålet i kundens sikkerhedsspørgeskema: et præcist svar
- Kunden kræver test, før samarbejdet starter
- Hvad en NIS2-kunde ikke kan forvente af en leverandør
- Forholdsmæssige krav: hvorfor en lille leverandør ikke skal testes som en stor
- Kunden har klassificeret jer som kritisk leverandør: hvad betyder det for testen?
- Kundens leverandørregister: hvorfor I bliver spurgt om systemer og adgange
- Kundens krav til testeren: når NIS2-kunden vil godkende, hvem der tester
- Når kravet er uklart: send kunden en plan for testen
- Kunden kræver ny test efter væsentlige ændringer: hvad tæller som væsentligt?
- Krav om sikker udvikling i kontrakten: hvor test hører til
- Kunden vil se jeres testpolitik: hvad en politik for sikkerhedstest indeholder
- Forordningens kontraktpunkter læst af leverandøren: de otte punkter i NIS2-aftalen
- Fra kundens NIS2-brev til afleveret dokumentation: guide i syv trin
Reglerne bag kravet: direktiv, lov og myndigheder
Bag kundens krav står direktivet, den danske NIS 2-lov, en gennemførelsesforordning for de digitale udbydere og vejledning fra myndighederne. Teksterne pålægger den omfattede kunde at vurdere sine leverandører, men de fastsætter ikke en bestemt testtype eller et fast interval for leverandøren.
→ Temaside: Reglerne bag kravet: direktiv, lov og myndigheder
- NIS2-direktivets artikel 21 læst af en leverandør
- Forsyningskædesikkerhed: hvad kunden skal tage stilling til om jer
- Artikel 21, stk. 3: hvorfor kunden spørger til jeres udvikling og produktkvalitet
- NIS 2-loven i Danmark: hvad leverandører skal vide om den
- NIS 2-lovens § 6: de ti foranstaltninger, og hvor test hører hjemme
- Hvem fører tilsyn med jeres kunde? De kompetente myndigheder i Danmark
- Styrelsen for Samfundssikkerhed og NIS2 set fra en leverandør
- SAMSIK’s vejledning om tekniske test: hvad der står om penetrationstest
- Gennemførelsesforordning 2024/2690: hvem den gælder for, og hvorfor leverandører møder den
- Bilag 1 og 2: kundens sektor afgør, hvilke regler kravet bygger på
- Væsentlige og vigtige enheder: hvad forskellen betyder for kundens krav til jer
- Tilsynets audits og sikkerhedsscanninger hos kunden: hvad det betyder for leverandøren
- Energi, tele og finans: når kunden er undtaget fra NIS 2-loven
- ENISA’s tekniske vejledning: hvad den siger om sikkerhedstest
- Ledelsens godkendelse hos kunden: hvorfor kravet til jer kan komme fra direktionen
- Certificering og NIS2: kan kunden kræve, at I er certificeret?
- Koordineret offentliggørelse af sårbarheder: hvad NIS2 siger, og hvad det betyder for jer
- Det, NIS2 ikke siger om penetrationstest
- Direktiv, lov og forordning: hvilken tekst gælder for jeres kunde?
- NIS2-ordene i kundens krav: en ordliste for leverandører
- NIS2 kort fortalt for leverandører: reglerne, der når jer gennem kunden
Effektivitet og test: hvad kunden forventer
Den omfattede kunde skal have procedurer til at vurdere, om sikkerhedsforanstaltningerne er effektive. En test af jeres leverance er én måde at give kunden et svar på, men ikke den eneste.
→ Temaside: Effektivitet og test: hvad kunden forventer
- Effektivitet af foranstaltninger: hvad kunden mener, når I skal dokumentere det
- Fra effektivitetskrav til testplan: kobl testen til en bestemt foranstaltning
- Sårbarhedsscanning eller penetrationstest: hvad kunden kan mene med teknisk test
- Testfrekvens efter risiko: hvorfor NIS2 ikke giver et fast interval
- Dokumenteret testmetode: hvad forordningen kræver af testens grundlag
- Type, omfang, tidspunkt og resultat: fire oplysninger, kunden kan forvente dokumenteret
- Kritiske fund skal afhjælpes: hvad forordningen siger, og hvad kunden spørger om
- Multifaktorlogin som NIS2-foranstaltning: hvad en test kan vise kunden
- Adgangskontrol og privilegerede konti: hvordan test belyser foranstaltningen
- Driftskontinuitet hos leverandøren: hvorfor kunden spørger, og hvor testen ikke er svaret
- Adskillelse i netværket som NIS2-foranstaltning: når kunden vil have den afprøvet
- Opdager I et angreb? Hvad en test kan sige om logning og overvågning
- Kryptering: hvad kunden kan bede jer dokumentere
- Cyberhygiejne og test: hvorfor de grundlæggende forhold fylder i kundens spørgsmål
- Test ved opsætning og idriftsættelse af en ny leverance til en NIS2-kunde
- Uafhængig gennemgang og teknisk test: to forskellige krav i forordningen
- Red teaming som svar på et NIS2-krav: hvornår det er mere, end kunden beder om
- Produktionsudstyr og OT: når kunden vil have test, men driften ikke tåler scanning
- Kundens risikovurdering som grundlag for jeres test
- Når en test ikke er det rigtige svar på et effektivitetskrav
- Et testprogram over flere år, som kunden kan følge
- Mellem to penetrationstest: hvad kunden kan forvente af løbende kontroller
- Kunden vil teste jeres medarbejdere: phishing og social engineering under NIS2
Testens omfang: det, kunden er afhængig af
Kunden interesserer sig ikke nødvendigvis for hele jeres virksomhed, men for de steder, hvor leverancen kan påvirke kundens drift eller data: supportadgangen, portalen, integrationerne og de værktøjer, I administrerer kunden med.
→ Temaside: Testens omfang: det, kunden er afhængig af
- Hvilke systemer forventer NIS2-kunden testet? Leverancen som udgangspunkt
- Jeres supportadgang til kunden: sådan lader I den teste
- Kundeportalen, som NIS2-kundens medarbejdere logger ind på
- Integrationer og dataudveksling med kundens systemer
- Delte konti og fælles adgange mellem jer og kunden
- Administrationsværktøjer: når værktøjet til drift af kunden er det kritiske
- Hele virksomheden eller kun leverancen? Når kunden spørger bredt
- Udstyr og software, I leverer ind i kundens net
- Afgrænsning mod kundens eget miljø: hvad I må teste, og hvad kunden skal godkende
- Leverancen kører hos en hostingpartner: tilladelse og afgrænsning
- Cloudtjenester i leverancen: jeres del og platformens del over for kunden
- Kundespecifik opsætning eller fælles platform: hvilken version skal testes?
- Mail og filudveksling med kunden som del af testen
- Serviceteknikere og arbejde på stedet: når adgangen er fysisk
- Fjernovervågning af anlæg: leverandørens forbindelse ind til driften
- API’et, kunden kalder: hvad der skal med, når kunden er afhængig af det
- Opdateringer fra jer til kunden: leveringsvejen som testområde
- Fælles login mellem jer og kunden
- Hvor meget skal kunden vide om omfanget? Fortrolighed om jeres systemer
- Lille leverandør med få systemer: hvad er et rimeligt omfang?
- Når kunden vil have testet noget, I ikke ejer
- Kundens brugere hos jer: roller og rettigheder i testen
- Test af fysisk adgang hos leverandøren: serverrum, kontor og udstyr
Dokumentation og aflevering til kunden
Kunden skal kunne bruge resultatet i sin egen leverandørvurdering og i sidste ende forklare det for sin myndighed. Det kræver ikke nødvendigvis hele rapporten, men et dokument, der viser testens type, omfang, tidspunkt og resultat.
→ Temaside: Dokumentation og aflevering til kunden
- Hvad skal kunden have? Dokumentationen efter en NIS2-begrundet test
- Resumé, erklæring eller hel rapport, når kunden er under tilsyn
- Kunden skal kunne vise tilsynet jeres testresultat: hvad det kræver af dokumentet
- Sikker aflevering af testresultater til kunden
- Rapportens modtager hos kunden: indkøb, sikkerhed eller ledelse?
- Kundens opbevaring af jeres rapport: vilkår I kan aftale
- Status på rettelser: sådan dokumenterer I opfølgningen over for kunden
- Retest som dokumentation over for kunden
- Åbne fund på afleveringstidspunktet: hvad I skriver til kunden
- Et fund, I ikke retter: sådan begrunder I det over for kunden
- Samme rapport til flere kunder: afgrænsning og versioner
- Kundens løbende opfølgning på leverandører: hvad I skal kunne vise hvert år
- Hvad I skal bede testleverandøren om, når kunden skal have dokumentationen
- Dokumentation, som en sagkyndig tredjepart kan forstå
- Oplysninger om testleverandøren i dokumentationen: hvad kunden kan spørge om
- Kunden vil deltage i afslutningsmødet
- Når kunden afviser jeres dokumentation
- Testresultater og koncernens øvrige selskaber
- Kundens skabelon: når I skal aflevere testresultatet i kundens eget format
- Hvad testdokumentationen ikke kan bevise over for kunden
- Ingen fund i rapporten: sådan forklarer I resultatet til kunden
- Dokumentationen på et fast tidspunkt hvert år: hvad der kan genbruges
- Kunden beder om en NIS2-erklæring fra revisor: hvad penetrationstesten kan bidrage med
Fund, sårbarheder og hændelser i kunderelationen
Finder testen noget, der berører kunden, afgør aftalen, hvornår og hvordan kunden skal have besked. Lovens frister for hændelsesunderretning gælder den omfattede kunde, men kunden kan kun nå dem, hvis leverandøren melder hurtigt.
→ Temaside: Fund, sårbarheder og hændelser i kunderelationen
- Kritisk fund, der berører kunden: hvornår og hvordan kunden skal have besked
- Pligt til at håndtere sårbarheder i leverandøraftalen
- Fund i tredjepartskomponenter i jeres leverance: hvem fortæller kunden hvad?
- Kundens frister for rettelser: når fristen står i aftalen
- Fund, der også rammer andre kunder
- Kundens 24 timer: hvorfor kunden kan have brug for jer hurtigt ved en hændelse
- Hændelse eller testfund: hvornår et fund skal behandles som en hændelse
- Leverandørens pligt til at give kunden besked om hændelser
- Væsentlig hændelse: hvad begrebet betyder, og hvorfor det angår leverandøren
- Test efter en hændelse hos jer: hvad kunden kan forvente
- Kundens egen test finder fejl i jeres løsning
- Kunden vurderer et fund som mere alvorligt, end I gør
- Midlertidige tiltag, når en rettelse tager tid
- CVSS i kundens krav: når kunden måler jer på alvorlighed
- Kunden får en advarsel om jeres produkt fra en anden kilde
- Sårbarheder, som andre melder til jer: forbindelsen til testen
- Når en fejl hos jer kan ramme kundens egne modtagere
- Årsagen bag fundet: hvad kunden vil vide ud over rettelsen
MSP, hosting og cloud i kæden
En driftsleverandør kan selv være omfattet af NIS2 og samtidig få krav fra kunder, der hver har deres egen tolkning. Fjernadministration, delte platforme og privilegerede konti går på tværs af kunderne.
→ Temaside: MSP, hosting og cloud i kæden
- MSP og NIS2: når driftsleverandøren selv er omfattet
- Udbyder af administrerede sikkerhedstjenester: hvad definitionen betyder for testen
- Digitaliseringsstyrelsen som tilsyn for MSP, hosting og cloud
- Forordningens krav om sikkerhedstest gælder MSP’en direkte
- Registrering som digital udbyder: hvorfor kunder spørger til den
- MSP’ens kunder kræver hver deres test: en fælles plan
- Test af MSP’ens fjernadministration af mange kunder
- MSP’en som mellemled: når kravet skal videre til platforme og licenser
- Datacenteret i kæden: hvad det kan dokumentere, og hvad det ikke kan
- Cloududbyderens dokumentation og jeres egen test
- Når kunden vil teste MSP’ens systemer: hensyn til de andre kunder
- Overvågning og SOC som tjeneste: hvad en test kan vise kunden om tjenesten
- Backup som tjeneste: kundens spørgsmål til leverandøren
- Delte platforme hos MSP’en: én svaghed, mange kunder
- Webbureau eller softwarehus med driftsaftale: når I også drifter kundens løsning
- Testvindue hos MSP’en: når mange kunders drift påvirkes samtidig
- Privilegerede konti hos MSP’en på tværs af kunder
- Hændelse hos MSP’en: hvad mange kunder skal have at vide
- Test i serviceaftalen: punkterne om test i MSP-kontrakten
- Datacenter, cloud og MSP: hvem tester hvad i en lagdelt leverance?
Sektorerne set fra leverandøren
Kunder i forskellige sektorer er underlagt forskellige regler, og nogle sektorer hører under særlige regler. Derfor kan samme leverandør få vidt forskellige krav fra kunder i sundhed, produktion, energi, tele og finans.
→ Temaside: Sektorerne set fra leverandøren
- Sektorernes forskelle: hvorfor samme leverandør får forskellige krav
- Leverandør til hospitaler, klinikker og sundhed
- Leverandør til fremstillingsvirksomheder: maskiner, elektronik og køretøjer
- Leverandør til energisektoren: når kunden er omfattet af energiberedskabsloven
- Leverandør til drikkevand og spildevand
- Leverandør til transport: luft, jernbane, vej og søfart
- Leverandør til havne og havnefaciliteter
- Leverandør til kommuner: når en kommune stiller NIS2-krav
- Leverandør til statslige myndigheder
- Leverandør til fødevareproduktion og engroshandel med fødevarer
- Leverandør til producenter af medicinsk udstyr
- Leverandør til kemikalievirksomheder
- Leverandør til affaldshåndtering
- Leverandør til post og kurertjenester
- Leverandør til forskningsinstitutioner: hvem stiller kravet, og på hvilket grundlag?
- Leverandør til finanssektoren: DORA og ikke NIS 2-loven
- Leverandør til teleselskaber: krav efter telesektorens egen lov
- Leverandør til onlinemarkedspladser, søgemaskiner og sociale platforme
- Kunder i flere EU-lande: når kravene bygger på forskellige nationale love
- Leverandør til rumsektoren: når kunden driver jordbaseret infrastruktur
- Leverandør til forsvaret og forsvarsindustrien: hvornår NIS2 gælder, og hvornår andre regler gør
Har en kunde stillet NIS2‑krav?
Fortæl kort, hvad kunden har bedt om, og hvornår kunden skal have svar. Så vender jeg tilbage.