Annonce – sponsoreret indhold.
At vælge en sikker it-leverandør er en af de vigtigste beslutninger, når din virksomhed skal have udviklet software, en app eller et nyt system. En leverandør, der ikke prioriterer sikkerhed i udviklingsprocessen, kan levere kode med sårbarheder, der senere koster dyrt i form af datalæk, driftsstop eller bøder. Med EU-reguleringer som NIS2-direktivet og Cyber Resilience Act (CRA) er sikkerhed i softwareudvikling blevet et konkret forretningsrisiko-emne, som ledelsen ikke kan overlade til tilfældighederne. Denne tjekliste giver dig fem konkrete råd og spørgsmål, du kan stille, før du skriver under på en udviklingsaftale.
Hvorfor sikkerhed i softwareudvikling er blevet et ledelsesansvar
Tidligere blev it-sikkerhed ofte betragtet som et teknisk anliggende, der blev håndteret efter en løsning var udviklet. Den tilgang holder ikke længere. NIS2-direktivet, som gælder for en bred vifte af danske virksomheder, stiller krav om, at ledelsen aktivt forholder sig til cybersikkerhed i hele forsyningskæden — herunder hos softwareleverandører. Cyber Resilience Act skærper kravene yderligere ved at pålægge producenter af digitale produkter at dokumentere sikkerhed gennem hele produktets levetid.
For dig som beslutningstager betyder det, at du ikke bare køber en funktionel løsning. Du køber også den sikkerhedsproces, leverandøren anvender. Du bør derfor kunne kræve dokumentation for leverandørens sikker kodepraksis, før I indgår en aftale. Kan leverandøren ikke redegøre for, hvordan sikkerhed er integreret i deres udviklingsproces, er det et advarselstegn.
Tjekliste: 5 råd til at vælge en sikker it-leverandør
Brug denne tjekliste som udgangspunkt for samtaler med potentielle leverandører. Hvert punkt indeholder konkrete spørgsmål, du kan stille direkte.
-
Spørg ind til sikkerhedskrav tidligt i projektet
En professionel leverandør begynder ikke med at kode, men med at forstå din virksomheds behov og risici. I den indledende fase bør leverandøren hjælpe dig med at afklare:
- Hvilke typer data skal løsningen behandle, og hvor følsomme er de?
- Hvilke lovkrav og branchestandarder gælder for din virksomhed?
- Hvem skal have adgang til systemet, og fra hvilke enheder?
Spørgsmål til leverandøren: “Hvordan arbejder I med at identificere sikkerhedskrav i projektets opstartsfase? Kan I vise eksempler på, hvordan I har gjort det i tidligere projekter?”
Hvis leverandøren springer denne fase over eller virker uinteresseret i at forstå din kontekst, risikerer du at få en løsning, der ikke passer til dine faktiske sikkerhedsbehov.
-
Kræv indsigt i test- og kontrolprocesser
Sikkerhed kan ikke testes ind til sidst — men test er stadig afgørende for at fange sårbarheder, før de når i produktion. En leverandør med en moden sikkerhedsproces anvender flere typer af sikkerhedstest løbende i udviklingen:
- Statisk kodeanalyse (SAST): Automatiseret scanning af kildekoden for kendte sikkerhedsfejl
- Dynamisk test (DAST): Test af den kørende applikation for sårbarheder
- Komponentanalyse: Kontrol af tredjepartsbiblioteker og open source-komponenter for kendte sårbarheder
- Penetrationstest: Simulerede angreb udført af sikkerhedsspecialister
Spørgsmål til leverandøren: “Hvilke sikkerhedstest indgår som standard i jeres udviklingsproces? Hvornår i forløbet udføres de, og hvem gennemgår resultaterne?”
-
Afklar håndtering af sårbarheder efter release
Selv den bedste kode kan indeholde sårbarheder, der først opdages efter lancering — enten i din egen kode eller i de softwarekomponenter, løsningen bygger på. Derfor er det afgørende at vide, hvordan leverandøren håndterer sikkerhedsproblemer efter release.
Spørgsmål til leverandøren:
- “Hvordan overvåger I for nye sårbarheder i de komponenter, I har brugt i løsningen?”
- “Hvad er jeres proces, hvis der opdages en kritisk sårbarhed efter lancering?”
- “Hvilke serviceniveauer tilbyder I for sikkerhedsopdateringer?”
En leverandør uden klare svar på disse spørgsmål efterlader dig med ansvaret for at opdage og løse sikkerhedsproblemer, som du måske slet ikke har kompetencerne til at håndtere.
-
Sikre dokumentation til compliance
Mange virksomheder er underlagt krav om at kunne dokumentere sikkerhedsforanstaltninger over for myndigheder, revisorer eller kunder. Det kan dreje sig om GDPR, NIS2, ISO 27001-certificering eller branchespecifikke standarder. Din leverandør bør kunne levere dokumentation, der understøtter din compliance.
Spørgsmål til leverandøren:
- “Hvilken sikkerhedsdokumentation leverer I som standard ved projektafslutning?”
- “Kan I levere dokumentation for, at løsningen er testet for de mest almindelige sårbarheder?”
- “Hvordan dokumenterer I de sikkerhedsbeslutninger, der er truffet undervejs i projektet?”
Dokumentation handler ikke kun om at have papirerne i orden. Det giver dig også mulighed for at overdrage løsningen til en anden leverandør senere, uden at vigtig viden går tabt.
-
Vurder leverandørens erfaring med sikker udvikling
En leverandør kan påstå at arbejde med sikkerhed, men det afgørende er, om de har reel erfaring og kompetence. Kig efter konkrete tegn:
- Har de medarbejdere med sikkerhedscertificeringer eller specialiseret erfaring?
- Kan de henvise til tidligere projekter, hvor sikkerhed var et centralt krav?
- Har de en dokumenteret proces for sikker udvikling, de kan gennemgå med dig?
- Deltager de i relevante sikkerhedsfællesskaber eller holder de sig opdateret på nye trusler?
Spørgsmål til leverandøren: “Kan I give et eksempel på et projekt, hvor I har hjulpet en kunde med specifikke sikkerhedskrav? Hvad gjorde I konkret?”
Typiske fejl når virksomheder vælger it-leverandør
Selvom du bruger tjeklisten ovenfor, er der faldgruber, du bør være opmærksom på:
- At vælge udelukkende på pris: Den billigste leverandør sparer ofte på sikkerhedsprocesser, som du betaler for senere i form af sårbar kode eller manglende dokumentation.
- At antage at sikkerhed er standard: Mange leverandører fokuserer primært på funktionalitet og deadline. Sikkerhed kræver eksplicitte krav fra din side.
- At vente med sikkerhedsdiskussionen: Hvis sikkerhed først kommer op, når projektet er halvvejs, er det ofte for sent at ændre fundamentale arkitekturvalg.
- At nøjes med mundtlige forsikringer: Bed om skriftlig dokumentation af sikkerhedsprocesser og få dem indskrevet i kontrakten.
- At glemme vedligeholdelsesfasen: En løsning lever længere end udviklingsprojektet. Sørg for at aftale, hvordan sikkerhedsopdateringer håndteres, før I går i luften.
Ved at stille de rigtige spørgsmål tidligt og insistere på dokumentation kan du træffe et mere informeret valg og undgå at stå med en løsning, der skaber flere problemer, end den løser. Sikkerhed er ikke en ekstraudgift — det er en integreret del af en professionel udviklingsproces.
About the Author
