Kryptering: hvad kunden kan bede jer dokumentere

Et spørgsmål om kryptering i en NIS2-kundes leverandørvurdering lyder enkelt, men det dækker både en politik, en praksis for nøgler og den konkrete opsætning af jeres forbindelser og lagre. Grundlaget er NIS 2-lovens § 6, stk. 1, nr. 8, om politikker og procedurer for brug af kryptografi og, hvor det er relevant, kryptering.

Kort sagt kan I dokumentere kryptering på tre måder: med jeres politik, med en beskrivelse af, hvor og hvordan data er krypteret, og med en kontrol af opsætningen. Kun den sidste del kan en sikkerhedstest bidrage til. Politikken og nøglehåndteringen må dokumenteres på anden vis.

Hvad reglerne siger

§ 6, stk. 1, nr. 8, svarer til artikel 21, stk. 2, litra h, i NIS2-direktivet. Lovbemærkningerne, som de er gengivet i Styrelsen for Samfundssikkerheds vejledning om foranstaltninger fra juni 2025, afsnit 8, siger, at politik og procedurer skal være passende i forhold til det aktuelle teknologiske stade. Vejledningen nævner som eksempler på indhold, hvilke protokoller og algoritmer der må bruges, nøglelængder og tilgangen til nøglehåndtering.

For de digitale udbydere, som gennemførelsesforordning 2024/2690 gælder for, fx cloud, datacentre og udbydere af administrerede tjenester, er kravet mere detaljeret. Bilagets punkt 9.2 siger, at politikken skal fastlægge typen, styrken og kvaliteten af kryptografien, herunder for data i hvile og data under overførsel, de protokoller og algoritmer, der må bruges, og tilgangen til nøgleforvaltning. Punkt 9.3 kræver gennemgang med planlagte mellemrum. → NIS 2-lovens § 6

Hvorfor kunden spørger jer

Kundens data bevæger sig mellem kunden og jer, og de ligger hos jer. Kunden kan ikke beskrive sin egen beskyttelse af data uden at vide, hvordan de er beskyttet på jeres side. Spørgsmålet kan også komme fra kundens egen risikovurdering af leverancen, hvor data hos jer er vurderet som følsomme. Jo mere følsomme data, jo mere præcist et svar kan kunden ønske. Mulige steder er:

Forbindelsen til jeres løsning · når kundens medarbejdere logger ind i en portal eller et system, I driver.
Integrationer · data, der sendes automatisk mellem kundens systemer og jeres. → Integrationer med kundens systemer
Filudveksling og mail · udtræk, rapporter og filer, der sendes frem og tilbage. → Mail og filudveksling med kunden
Lagring · databaser, filer og backup med kundens data, også hos en hostingpartner eller i en cloudtjeneste.
Administration · de forbindelser, jeres medarbejdere bruger til at drifte løsningen. Forordningens punkt 11.4.2, litra c, nævner beskyttelse af adgangen til administrationssystemer gennem autentificering og kryptering.

Det, en test kan kontrollere

En sikkerhedstest kan kontrollere den del af krypteringen, der kan ses udefra eller fra de adgange, testen får. Det kan være:

Om forbindelserne er krypteret · til portaler, API’er og andre tjenester, kunden bruger.
Om opsætningen svarer til politikken · om forældede protokolversioner eller svage indstillinger stadig accepteres, når politikken siger andet.
Om certifikaterne er i orden · gyldige, udstedt til de rigtige navne og ikke udløbet.
Om følsomme data ligger ubeskyttet · fx i filer eller meddelelser, som testen kan nå med de konti, den har.

Resultatet er en kontrol af opsætning på et bestemt tidspunkt. Det er værdifuldt, fordi det viser, om praksis følger politikken. Bed testeren beskrive fundene om kryptering for sig, så de kan sendes til kunden uden resten af rapporten.

Det, testen ikke viser

En test siger ikke noget om, hvordan nøgler bliver lavet, opbevaret, skiftet og tilbagekaldt. Den viser heller ikke, om data er krypteret på diske og i backup, som testen ikke har adgang til, eller hos en hostingpartner, der ikke var med i omfanget. Den del dokumenteres med jeres politik, med beskrivelser af opsætningen og med de oplysninger, jeres platformsleverandører stiller til rådighed. → Cloudtjenester i leverancen

ENISA’s tekniske vejledning fra juni 2025, som ikke er bindende, foreslår til punkt 9.3, at ændringer af de kryptografiske foranstaltninger testes, før de tages i brug. Det er en test af ændringen, ikke en sikkerhedstest af hele løsningen, men det er en oplysning, kunden kan spørge til.

Når kunden har sin egen politik

Nogle kunder sender ikke et spørgsmål, men et krav. Kundens egen politik for kryptografi kan fx fastlægge, hvilke protokolversioner der må bruges på forbindelser til kundens systemer, og kunden beder jer bekræfte, at jeres løsning følger den. Det er kundens politik, ikke loven, der sætter niveauet, og kravet hører derfor hjemme i aftalen med jer.

Før I bekræfter, bør I sammenholde kundens krav med jeres faktiske opsætning, også på de forbindelser, der er sat op for længe siden. En test kan bruges til at kontrollere netop det. Kan I ikke følge kravet overalt, er det bedre at skrive, hvor I afviger, og hvornår det ændres, end at bekræfte noget, en senere test vil modsige. Afvigelsen kan så indgå i kundens egen vurdering af risikoen.

Et tænkt eksempel

En leverandør af et system til ruteplanlægning for en affaldsvirksomhed bliver bedt om at dokumentere kryptering af data under overførsel og i hvile. Leverandøren sender sin politik, en kort oversigt over de forbindelser og lagre, der indeholder kundens data, og et uddrag af den seneste test. Uddraget viser, at portalen og API’et kun accepterer de protokolversioner, politikken tillader, og at en ældre filoverførsel fra en tidligere integration stadig var åben. Rettelsen og datoen for den står i svaret. Om krypteringen af databasen henviser leverandøren til hostingpartnerens dokumentation. Affaldsvirksomheden kan dermed se, hvad der er kontrolleret, og hvad der bygger på oplysninger fra andre.

Det skal I lade være med

At svare med et ja uden at beskrive, hvor kryptering bruges · kunden kan ikke vurdere et ja.
At lade testen stå alene som dokumentation for kryptering · den dækker ikke nøglehåndtering.
At glemme gamle forbindelser · integrationer og filoverførsler, der ikke længere bruges, kan stadig være åbne.
At love, at alle data er krypteret · skriv, hvilke data og hvor.
At udelade hostingpartnerens del · lagringen kan ligge uden for jeres egen kontrol.

Hvad kan og ikke kan konkluderes

En test kan vise, om de forbindelser og data, den nåede, var beskyttet som beskrevet. Den kan ikke vise, at jeres politik er passende, eller at nøglerne bliver håndteret rigtigt. Teksten er ikke juridisk rådgivning. Hvordan dokumentationen samles til kunden, står her: → Dokumentationen til NIS2-kunden