Penetrationstest og standarder: hvad ISO 27001, PCI DSS og NIS2 siger

Henvisninger til ISO 27001, PCI DSS eller NIS2 kan få en penetrationstest til at ligne et entydigt krav, selv om teksterne har forskellige formål. Svaret skal bygge på den konkrete ordlyd, virksomhedens anvendelse af den og det scope, testen faktisk dokumenterer.

En penetrationstest kan indgå som evidens i en større styringsproces. Den kan ikke alene bevise, at en organisation opfylder en hel standard, et regelsæt eller alle kundekrav. Derfor bør bestillingen skelne mellem selve testopgaven og den dokumentationspakke, som revisoren, kunden eller den ansvarlige funktion skal bruge.

Artiklen er en købervejledning og ikke en overensstemmelsesvurdering. Den gengiver udvalgte punkter fra de officielle kilder. Den fulde tekst, organisationens anvendelighedserklæring, kontrakter og eventuelle sektorkrav skal vurderes særskilt.

Kontrollér altid den udgave og den juridiske tekst, som faktisk gælder for organisationen.

De tre tekster har forskellige roller

ISO/IEC 27001 beskriver krav til et ledelsessystem for informationssikkerhed. Den handler dermed om organisationens styring af risici og valgte kontroller, ikke om én fast testpakke for alle virksomheder. Hvilke kontroller der er relevante, afhænger af organisationens egen behandling af risici og dens dokumenterede valg.

PCI DSS er et branchespecifikt sikkerhedskrav for miljøer, der er omfattet af betalingskortområdet. Her nævner krav 11.4 penetrationstest direkte og beskriver elementer i en testmetode. Den præcise anvendelse skal holdes op mod den gældende tekst og det relevante kortdatamiljø.

NIS2 er et EU-direktiv, som medlemsstaterne gennemfører i national ret. Artikel 21 opstiller cybersikkerhedsforanstaltninger for de omfattede enheder. Penetrationstest nævnes ikke som et universelt enkeltkrav i den bestemmelse. NIS2 behandles mere udfoldet på nis2-pentest.dk.

Forskellen har praktisk betydning for bestillingen. En ISO-henvisning bør føres tilbage til organisationens valgte kontrol og risikobehandling. En PCI DSS-henvisning bør forbindes med det relevante kortdatamiljø og kravets metode. En NIS2-henvisning bør placeres i virksomhedens bredere vurdering af foranstaltningers effektivitet. Det er tre forskellige begrundelser, selv når den samme rapport indgår som materiale.

Lav derfor et kort kravkort før indkøbet. Skriv kilden, den interne ejer, det system spørgsmålet vedrører og den dokumentation, modtageren forventer. Forslaget er en arbejdsform, ikke et officielt krav fra de tre tekster.

ISO/IEC 27001 A.8.8 handler om sårbarheder

Kontrol A.8.8 i ISO/IEC 27001:2022 har overskriften håndtering af tekniske sårbarheder. Den retter opmærksomheden mod at indhente oplysninger om tekniske sårbarheder, vurdere eksponering og træffe passende foranstaltninger. Kontrollen bruger ikke ordet penetrationstest i sin titel eller som et udtrykkeligt generelt krav.

En penetrationstest kan alligevel være en af flere informationskilder i virksomhedens håndtering. Det er en anvendelsesbeslutning, som bør kunne føres tilbage til risikovurderingen, systemernes betydning og den valgte kontrolstruktur. Andre kilder og processer kan samtidig være nødvendige.

Skriv derfor ikke ISO kræver penetrationstest i bestillingen, medmindre en kvalificeret vurdering af virksomhedens konkrete grundlag kan underbygge den formulering. Skriv i stedet det kontrolformål, testen skal støtte, og den dokumentation virksomheden vil gemme.

For et kontornet kan kontrolformålet eksempelvis være at få vurderet et bestemt teknisk område, som organisationens egen risikobehandling har udpeget. For kundeportalen kan et andet spørgsmål være relevant. Testtypen følger altså ikke automatisk af kontrolnummeret. Det er organisationens begrundede anvendelse, som forbinder kontrollen med opgaven.

Hvis en revisor eller kunde har efterspurgt dokumentation, så få forventningen på skrift. Spørg om rapportens resumé er tilstrækkeligt, om scope skal fremgå særskilt, og hvordan begrænsninger skal vises. Det mindsker risikoen for, at en gennemført test senere viser sig at levere den forkerte form for evidens.

ISO-dokumentation kræver mere end en rapport

En test af kundeportalen kan dokumentere den aftalte undersøgelse på et bestemt tidspunkt. I en ISO-sammenhæng kan rapporten eksempelvis indgå som evidens for en valgt aktivitet. Organisationen skal fortsat kunne forklare, hvorfor aktiviteten er valgt, hvordan fund behandles, og hvem der følger op.

Knyt rapportens fund til virksomhedens egne opgaver og risikobeslutninger. Hvis et fund accepteres, bør beslutning og forudsætninger være synlige. Hvis det rettes, bør virksomheden kunne følge ændringen og en eventuel efterprøvning. Det er redaktionelle forslag til sporbarhed, ikke gengivelse af en obligatorisk ISO-skabelon.

Undgå at gøre testerens rapport til organisationens anvendelighedserklæring eller revisionskonklusion. Testeren svarer på den aftalte tekniske opgave. Virksomhedens ledelsessystem binder denne oplysning sammen med øvrige kontroller og beslutninger. → Retest efter penetrationstest

Opbevar sammenhængen, ikke kun pdf-filen. En senere læser bør kunne finde bestillingen, den godkendte afgrænsning og den interne behandling af fundene. Hvis ledelsen vælger en anden løsning end rapportens anbefaling, bør beslutningen forklares i virksomhedens eget materiale. Det er ikke testerens opgave at omskrive virksomhedens risikovalg.

Kontrollér også om rapporten stadig svarer til det system, der bliver vurderet. En større ændring i ERP-systemet kan betyde, at ældre evidens ikke belyser de nye funktioner. Standarden giver ikke rapporten en automatisk holdbarhed uafhængigt af ændringer.

PCI DSS krav 11.4 nævner penetrationstest

PCI DSS krav 11.4 handler udtrykkeligt om penetrationstest. Microsofts gengivelse af krav 11 beskriver blandt andet, at en dokumenteret testmetode skal definere tilgang, dækning, lag, validering af segmentering og håndtering af de risici, testen finder. Gengivelsen bør læses sammen med den officielle PCI DSS-tekst, som organisationen er underlagt.

Kravfamilien er mere konkret end ISO-kontrollen på dette punkt. Det betyder stadig ikke, at en vilkårlig penetrationstest opfylder formålet. Testens scope skal passe til det relevante miljø, og den valgte metode skal kunne dokumenteres i forhold til ordlyden.

Krav 11.4.4 omtaler rettelse af udnyttelige sårbarheder og gentagelse af test for at verificere rettelserne. Det gør sporbarheden mellem fund, ændring og efterprøvning vigtig.

Bestilleren bør få den relevante kravversion og vurderingsramme bekræftet af den ansvarlige PCI DSS-funktion. Et tilbud kan derefter spejle den krævede metode uden at bruge standardnavnet som en løs salgsetiket. Hvis en del af miljøet er undtaget på grund af segmentering, skal dokumentationen passe til kravets behandling af netop denne afgrænsning.

Bed også om at få leverancerne navngivet. En teknisk rapport, et resumé og dokumentation for en senere retest kan have forskellige modtagere. Aftalen bør vise, hvilke dele der leveres, og hvordan de forbindes med de krav, virksomheden vil dokumentere.

NIS2 artikel 21 fokuserer på effektivitet

NIS2 artikel 21, stk. 2, litra f, nævner politikker og procedurer til vurdering af effektiviteten af foranstaltninger til styring af cybersikkerhedsrisici. Bestemmelsen foreskriver ikke i den formulering én bestemt penetrationstest eller en fast testpakke.

En penetrationstest kan være en aktivitet, der bidrager med oplysninger til en sådan vurdering, hvis opgaven passer til de foranstaltninger, organisationen vil undersøge. Den kan ikke alene vise, at alle krav i artikel 21 eller den nationale gennemførelse er opfyldt.

Hold derfor NIS2-henvisningen kort i testbestillingen. Beskriv hellere det system, den kontrol og den beslutning, som rapporten skal støtte. Den juridiske vurdering af, om virksomheden er omfattet, og hvordan dansk ret finder anvendelse, ligger uden for denne artikel.

Effektivitet kan ikke reduceres til antallet af fund. Et resultat med få fund kan skyldes den valgte afgrænsning, de undersøgte foranstaltninger eller systemets tilstand. Et resultat med flere fund er tilsvarende ikke alene et mål for organisationens samlede modenhed. Brug rapporten som ét input og fasthold dens forudsætninger.

Virksomheden bør beslutte, hvem der samler dette input med andre vurderinger. Det kan være en sikkerhedsansvarlig, en risikofunktion eller en anden udpeget ejer.

Oversæt kravet til et kontrollerbart spørgsmål

Start med kildeteksten og den ansvarlige funktions fortolkning. Skriv derefter et spørgsmål, som testen kan besvare. Hvis organisationen vil have vurderet adskillelsen mellem gæstenet og kontornet, bør nettene og den forventede adskillelse stå i scope. Standardens navn gør ikke denne afgrænsning overflødig.

For webshoppen kan et kundekrav handle om bestemte funktioner eller dele af miljøet. Sørg for, at kravet og testens mål bruger samme betegnelser. Hvis kontrakten taler om hele løsningen, mens tilbuddet kun omfatter den offentlige del, skal forskellen afklares før arbejdet begynder.

Angiv også hvem der vurderer, om leverancen opfylder dokumentationsbehovet. Testeren kan forklare rapportens indhold, men virksomhedens revisor, kunde eller ansvarlige funktion må tage stilling til anvendelsen. → Scope i en penetrationstest

Gør dokumentationskæden synlig

En anvendelig kæde kan begynde med kravet eller kontrolmålet, fortsætte til den godkendte opgave og slutte med rapport, handlingsplan og opfølgning. Det er et forslag til organisering. Den præcise dokumentation afhænger af standarden, aftalen og virksomhedens egne processer.

Giv hvert led en ansvarlig ejer. Den person, der formulerer kontrolmålet, behøver ikke være den samme, som driver testen eller retter fundene. En tydelig overdragelse mindsker risikoen for, at rapporten bliver arkiveret uden en beslutning, eller at en rettelse mister forbindelsen til det krav, som udløste arbejdet.

Registrér også uenighed om fortolkning. Hvis kunden og virksomheden læser et kontraktkrav forskelligt, bør det afklares før testen. Testeren kan ellers levere et korrekt svar på virksomhedens spørgsmål, som kunden ikke anser for tilstrækkeligt. Det er en aftalemæssig afklaring og ikke noget, den tekniske rapport bagefter kan løse.

Rapporten bør identificere miljø, systemer, roller, begrænsninger og dato for undersøgelsen. Et fund bør kunne forbindes med den interne ejer og en beslutning. Hvis noget var uden for scope, skal det være muligt at se, at området ikke blev vurderet.

Et ledelsesresumé kan hjælpe en kunde eller revisor med at forstå hovedresultatet, men den detaljerede rapport kan indeholde følsomme oplysninger. Aftal modtagere og en passende deling. Rapportens opbygning behandles i → Sådan læser I en pentestrapport, og dens anvendelse uddybes på pentestrapport.dk.

Når dokumentationen deles, bør uddrag ikke fjerne de begrænsninger, som konklusionen afhænger af. Et kort resumé kan godt være den rigtige leverance til en kunde, men det skal stadig vise hvilket system og hvilket scope resultatet vedrører. Det er en redaktionel anbefaling om præcision, ikke et bestemt krav til rapportformat.

Det skal I lade være med

At skrive compliant på grund af én test · Rapporten dækker en afgrænset opgave, ikke hele standarden eller lovgrundlaget.
At gengive kundens krav fra hukommelsen · Brug den konkrete tekst og få uenigheder om betydningen afklaret.
At lade standardnavnet erstatte scope · Webshop, roller, miljø og undtagelser skal stadig fremgå.
At skjule testens begrænsninger i bilag · Den, der bruger dokumentationen, skal kunne se dem.
At lade testeren træffe virksomhedens risikobeslutning · Ejeren må beslutte håndtering og acceptere eventuelle rester.
At dele hele rapporten automatisk · Vælg modtagere ud fra formål og materialets følsomhed.

Kompetencekrav i et kundekrav bør også begrundes konkret. → Krav til penetrationstesteren

Hvad kan og ikke kan konkluderes

En penetrationstest kan dokumentere, hvad der blev undersøgt, hvilke fund der blev vurderet, og hvilke begrænsninger der gjaldt. Den kan dermed indgå som evidens for en bestemt kontrolaktivitet eller et bestemt kontraktkrav, når scope passer.

Rapporten kan ikke alene dokumentere, at organisationens samlede ledelsessystem opfylder ISO/IEC 27001. Den kan heller ikke på egen hånd fastslå PCI DSS-overensstemmelse eller juridisk efterlevelse af NIS2. Sådanne konklusioner kræver det bredere vurderingsgrundlag, som den relevante ordning eller lovgivning bruger.

Selv inden for testens scope er resultatet knyttet til de beskrevne forudsætninger. Ændringer i ERP-systemet eller dets integrationer kan skabe et nyt spørgsmål. Frekvens og gentagelse skal derfor begrundes i ændringer, risici og dokumentationsbehov. → Hvor ofte skal I teste?

Tjekliste til standardbaseret bestilling

☐ Har I den præcise kilde og ordlyd, som dokumentationen skal støtte?
☐ Er virksomhedens fortolkning godkendt af den ansvarlige funktion?
☐ Er kravet omsat til et konkret spørgsmål om et navngivet system?
☐ Passer scope, miljø og roller til det område, der skal dokumenteres?
☐ Fremgår testmetode og begrænsninger i den ønskede levering?
☐ Kan fund følges til ejer, beslutning, ændring og eventuel retest?
☐ Er det aftalt, hvem der vurderer materialet over for revisor eller kunde?
☐ Undgår konklusionen at love mere end testens faktiske dækning?

Kilder

ISO/IEC 27001:2022: officiel standardside om krav til ledelsessystemer for informationssikkerhed.
PCI DSS krav 11: gengivelse af krav om regelmæssig test og penetrationstest i krav 11.4.
NIS2-direktivet, artikel 21, stk. 2, litra f: politikker og procedurer til vurdering af sikkerhedsforanstaltningers effektivitet.

Senest gennemgået: oktober 2026.