secria.eu

Hvilke krav skal der være i kontrakten for softwareudvikling efter NIS2?

En ordregiver, der selv falder under NIS2-forpligtelsen til at træffe foranstaltninger, oversætter denne forpligtelse til kontraktkrav for den software, som du udvikler, og til den måde, hvorpå du udvikler den. Denne artikel præsenterer, hvilke krav det typisk er.

En ordregiver, der er underlagt NIS2-forsigtighedspligten, skal kunne dokumentere, at han kender risiciene i sin egen forsyningskæde. Software, som du udvikler for denne ordregiver, er en del af denne kæde. I praksis oversætter det sig til kontraktkrav, der angriber to ting samtidigt: det produkt, du leverer, og den måde, hvorpå du fremstiller det produkt. Begge optræder i kontraktteksten, ofte som tillæg til indkøbskontrakten.

Kernen er enkel at huske: ordregiveren spørger ikke kun, om softwaren virker, men også om du kan vise, hvordan den forbliver sikker, hvem der kan få adgang til den, og hvad der sker, hvis noget går galt. Dette er et skift i forhold til tidligere, da funktionalitet og leveringstid ofte var de eneste diskussionspunkter.

Krav til det produkt, du leverer

Det mest almindelige kontraktkrav vedrører sammensætningen af selve softwaren. Ordregivere efterspørger i stigende grad et overblik over de anvendte biblioteker og open source-komponenter, en såkaldt softwarestyklisteopgørelse. Årsagen er, at en sårbarhed i en underliggende komponent er lige så stor en risiko som en fejl i din egen kode, og at en ordregiver ønsker at kunne gennemskue disse risici uden selv at læse kildekoden.

Derudover optræder krav om, hvordan sårbarheder i softwaren opdages og udbedres, og inden for hvilken frist. Dette kan vedrøre automatiserede scanninger af kendte svage punkter, en fastsat procedure for patches, eller spørgsmålet om, hvem der må rapportere en sårbarhed og hvor den skal sendes hen. For eksisterende software spørges der nogle gange også til supportperioden: hvor længe forbliver en version forsynet med sikkerhedsopdateringer.

Krav til din egen udviklingslinje

Et andet sæt krav fokuserer ikke på produktet, men på processen, hvorigennem det skabes: udviklingsflyden. Tænk på, hvem der har adgang til kildekoden og det miljø, hvor der bygges og testes, hvordan ændringer kontrolleres, før de går live, og om der er adskillelse mellem et test-, et godkendelses- og et produktionsmiljø. Brugen af flertrinsfaktor-godkendelse for udvikler, der har adgang til kildekode eller buildsystemer, optræder også i kontrakter, ligesom spørgsmålet om, hvem der administrerer nøglerne og legitimationsoplysningerne, der hører til softwareudviklingen.

Nogle ordregivere spørger også om oprindelsen af den software, som du selv anvender til udvikling: compileren, build-værktøjerne, de pakker, der hentes under bygning. Dette tilslutter sig en bredere erkendelse af, at et angreb ikke kun kan komme gennem slutproduktet, men også gennem fabrikken, hvor det fremstilles.

Hvorfor disse krav præcis er formuleret på denne måde

Den forsigtighedspligt, der ligger til grund for alt dette, forpligter en pligtig organisation til at vurdere og kontrollere risici i sin egen forsyningskæde. Hvordan det præcis gennemføres, varierer fra land til land i den nationale lov, der er baseret på EU-direktivet, og fra sektor til sektor, hvor ordregiveren er aktiv. Hvad der er et hårdt krav i én kontrakt, optræder som et frivilligt spørgsmål i en anden kontrakt. Hvis du ønsker at vide, hvordan denne forpligtelse i sin kerne er struktureret, læser du det i forklaringen af hver forpligtelse i vores vidensbank.

Det er vigtigt at huske: det er ordregiveren, der stiller disse krav, fordi han selv er underlagt tilsyn, ikke fordi softwarefirmaer som sådan falder ind under direktivet. Om og hvor strengt det gennemtvinges i dit tilfælde, afhænger af sektoren og størrelsen på denne specifikke ordregiver. For din egen situation er teksten af den nationale lov eller rådgivning fra en jurist det rigtige udgangspunkt, ikke en generel vurdering.

Hvad dette betyder for din forberedelse

De fleste af disse krav kan besvares godt med lidt forarbejde, og det svar, som du udarbejder én gang, kan du genbruge igen og igen hos næste opgavegiver. En liste over anvendte komponenter, en kort beskrivelse af din adgangskontrol og en fast procedure for rettelser er ikke dokumenter, som du skal finde på ny for hver kontrakt.

Vil du først se, om og hvordan det rammer dit firma, så giver checken, som på få spørgsmål fastlægger din position i værdikæden en første retning, uden at du har brug for en konto. For de spørgsmål, som opgavegivere stiller konkret, og måden, vi hjælper på, læser du mere på siden med hyppigt stillede spørgsmål eller ser du hvordan vi underbygger oplysningerne på platformen.

Den gratis videnbase og checken giver dig et første overblik uden forpligtelser. Vil du derefter rent faktisk omforme kontraktbetingelserne til et løbende dossier med bevisstykker og færdiglavede svar på spørgeskemaer, så er det tidspunktet, hvor du skal se, hvad et abonnement tillægger.

Denne artikel er generel information og ikke juridisk rådgivning.