Når virksomheden køber et forretningssystem, en bookingløsning eller en onlinetjeneste, køber den også leverandørens sikkerhedsarbejde, uanset om nogen har spurgt til det. Ledelsen kan ikke selv afprøve produktet, men den kan spørge, hvordan leverandøren har gjort det. De bedste anledninger er valget af et nyt system og fornyelsen af en aftale om et eksisterende, fordi det er dér, virksomheden kan stille betingelser. Spørgsmålene drejer sig om fire ting: hvordan produktet testes, hvem der har testet det udefra, hvordan fejl håndteres, og hvad kunderne får at vide. Svarene viser, om sikkerheden er en del af leverandørens praksis eller kun en del af salgsmaterialet.
Hvordan softwarehuse selv forbereder rapporten og svarer på kundernes spørgeskemaer, beskriver pentestrapport.dk. Her handler det om køberens ledelse.
Hvorfor det er et ledelsesspørgsmål
Et system, som virksomheden ikke kan undvære, gør leverandørens svagheder til virksomhedens risiko. Hvis kundedata, ordrer eller produktion afhænger af ét produkt, bør ledelsen vide, hvordan produktet er beskyttet, på samme måde som den vil vide, om leverandøren er økonomisk solid.
Spørgsmålet kan ikke overlades helt til IT, fordi valget af system kan blive truffet ud fra funktioner, pris og brugervenlighed. Sikkerheden kommer ikke nødvendigvis med på listen, medmindre nogen i ledelsen sætter den der. → Kronjuvelerne
En ramme, der kan låne ord
Det britiske ministerium for videnskab, innovation og teknologi har i samarbejde med NCSC udgivet en Software Security Code of Practice, en frivillig kodeks for softwareleverandører. Den gælder ikke i Danmark, men den er skrevet sådan, at kunder kan bruge den. Kodeksen siger direkte, at virksomheder, der køber software, kan bruge principperne i forhandlinger med leverandører og i aftaler og kontrakter.
Fire af principperne er særlig nyttige for en ledelse, der skal stille spørgsmål:
- Test før udgivelse · leverandøren bør have en klar proces for at teste software og opdateringer, før de sendes ud.
- En åben dør for fejlmeldinger · leverandøren bør have og offentliggøre en proces for at modtage oplysninger om sårbarheder.
- Oplysning om support · kunden bør få at vide, hvilket niveau af support og vedligeholdelse der følger med.
- Oplysning om hændelser · leverandøren bør gøre oplysninger om væsentlige hændelser tilgængelige for kunder, der kan blive påvirket.
Ledelsen behøver ikke henvise til kodeksen. Den kan bruge den som tjekliste for, hvad et seriøst svar bør dække.
Spørgsmål om leverandørens egen test
- Hvordan tester I nye versioner, før de udgives? · et svar bør beskrive en fast praksis, ikke en enkelt indsats.
- Er produktet testet af en uafhængig part? · og hvornår?
- Hvilken version og hvilke dele var med? · en test af et ældre produkt eller et andet modul siger mindre om det, I bruger.
- Kan vi se et resumé eller en erklæring? · den fulde rapport deles ikke altid, men et resumé er rimeligt at bede om.
- Hvad blev fundet, og er det rettet? · en leverandør, der kan svare på det, har styr på sin opfølgning.
Svarene skal ikke vurderes teknisk af ledelsen. Det er nok at se, om de er konkrete. “Vi tager sikkerhed alvorligt” er ikke et svar. “Produktet blev testet af en ekstern part i foråret, og her er resuméet” er. → Spørgsmål til IT-leverandøren
Spørgsmål om fejl og hændelser
Intet produkt er uden fejl. Det afgørende er, hvad der sker, når en fejl bliver fundet.
- Hvordan kan andre melde en fejl til jer? · har I en offentlig fremgangsmåde for det?
- Hvordan får vi besked om sikkerhedsopdateringer? · og hvor hurtigt?
- Hvad fortæller I kunderne, hvis I selv bliver ramt? · og hvem hos os får besked?
- Hvor længe understøttes den version, vi køber? · et system uden opdateringer bliver en risiko med tiden.
Det sidste spørgsmål overses let. Et system kan være sikkert i dag og blive en svaghed, når leverandøren holder op med at vedligeholde det. → Hvad står stille, hvis systemerne er nede?
Når I selv vil teste
Nogle virksomheder ønsker at teste et købt system selv, fx fordi det rummer følsomme data eller er tilpasset meget. Det kan kræve leverandørens accept, og vilkårene bør aftales, før kontrakten underskrives. Spørg, om leverandøren tillader kundernes egne test, på hvilke betingelser, og om leverandøren vil rette det, I finder. → Leverandøren skal rette: hvilke svar ledelsen kan kræve
Når leverandøren ikke vil svare
Nogle leverandører svarer kort eller henviser til en generel side om sikkerhed. Det er ikke nødvendigvis et dårligt tegn. Mindre softwarehuse har ikke altid et færdigt materiale, og store leverandører kan have faste svar, der ikke kan tilpasses den enkelte kunde.
Ledelsen kan gøre to ting. Den kan bede om et møde, hvor de vigtigste spørgsmål besvares mundtligt og bagefter bekræftes skriftligt. Og den kan vurdere, hvor meget svaret betyder: for et system med følsomme data eller afgørende drift bør manglende svar veje tungt i valget, mens det for et mindre vigtigt værktøj kan være acceptabelt. Vælger ledelsen at gå videre uden svar, bør det ske bevidst og stå i beslutningsgrundlaget, så det kan tages op igen ved næste fornyelse.
Et tænkt eksempel
En fragtvirksomhed skal vælge nyt system til ruteplanlægning og kundeportal. To leverandører står tilbage. Den administrerende direktør beder begge svare skriftligt på de samme spørgsmål om test, fejlmeldinger, opdateringer og hændelser.
Den ene leverandør sender et resumé af en ekstern test fra i år, en beskrivelse af, hvordan opdateringer testes, og en side om, hvordan fejl meldes. Den anden svarer, at produktet er sikkert og bruges af mange kunder. Begge systemer opfylder de funktionelle krav. Direktøren vælger det første og får skrevet ind i aftalen, at fragtvirksomheden får besked om væsentlige hændelser, og at den selv må lade kundeportalen teste efter aftale.
Det skal I lade være med
- At vælge system alene ud fra funktioner og pris · sikkerheden hører med i vurderingen.
- At tage et certifikat som svar på alt · spørg, hvad det dækker. → Certifikatet beviser ikke, at vi er sikre
- At kræve hele rapporten som betingelse · et resumé eller en erklæring kan være mere realistisk.
- At glemme supportperioden · et system uden opdateringer bliver en svaghed.
- At vente til fornyelsen er overstået · betingelser stilles før underskriften.
Hvad kan og ikke kan konkluderes
Leverandørens svar viser, om sikkerhedstest og fejlhåndtering er en del af praksis, og om leverandøren vil dele det, kunderne har brug for at vide. Svarene kan ikke vise, at produktet er uden svagheder, og de siger intet om, hvordan systemet er sat op hos jer. Den del er virksomhedens eget ansvar. Svarene er derfor ét led i vurderingen af et system, ikke en godkendelse af det. Hvis systemet bliver centralt for forretningen, kan det senere være værd at lade det indgå i virksomhedens egen test.
Kilder
- UK Department for Science, Innovation and Technology og NCSC: Software Security Code of Practice: principperne 1.3 (test før udgivelse), 3.2 (proces for fejlmeldinger), 4.1 (oplysning om support) og 4.3 (oplysning om væsentlige hændelser); kunder kan bruge kodeksen i forhandlinger og kontrakter.
Senest gennemgået: oktober 2026.
Næste skridt
- Leverandørrisiko: når virksomhedens sikkerhed ligger i andres hænder
- Leverandøren skal rette: hvilke svar ledelsen kan kræve
Del af: Artikler til ledelsen
Læs også: Spørgsmål til IT-leverandøren · Kundekrav eller egne behov
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
