Webbureau eller softwarehus med driftsaftale: når I også drifter kundens løsning

Et bureau, der har bygget kundens løsning og bagefter står for hosting, opdateringer og overvågning, er ikke kun en udvikler i kundens øjne. Det er også den part, der har adgang til driften. Når en kunde omfattet af NIS2 beder om dokumentation for test, hviler spørgsmålet derfor på to dele af NIS 2-loven: kravet om sikker udvikling og vedligeholdelse og kravet om forsyningskædesikkerhed. Svaret er, at testen skal dække både løsningen og den måde, I drifter den på.

Om I selv kan være omfattet af loven som udbyder af administrerede tjenester, er en vurdering, I skal have foretaget for sig. Teksten er ikke juridisk rådgivning.

To roller i samme aftale

Udviklingsrollen handler om koden, funktionerne og de integrationer, I har bygget. Driftsrollen handler om serveren eller cloudmiljøet, administratoradgangen, opdateringerne, backup og den overvågning, I har påtaget jer. I en klassisk projektaftale er udviklingen afsluttet ved aflevering. Med en driftsaftale fortsætter jeres adgang, så længe aftalen løber.

For kunden er forskellen væsentlig. En fejl i koden kan give en uvedkommende adgang til løsningen. En svag administratoradgang hos jer kan give adgang til hele miljøet, også til de dele, koden aldrig har rørt. Kunden kan derfor have et krav til begge roller, også selv om kontrakten kun nævner den ene.

Rollerne kan også være fordelt på forskellige personer hos jer. Udviklerne kender koden, mens en driftsansvarlig kender serverne og adgangene. Når kundens spørgsmål kommer, skal begge kunne svare, og svaret skal hænge sammen. Saml derfor oplysningerne ét sted, før I sender noget, så kunden ikke får to beskrivelser af den samme leverance.

Hvad definitionen i § 3, nr. 34, siger

NIS 2-loven definerer en udbyder af administrerede tjenester som en enhed, der leverer tjenester i forbindelse med installation, administration, drift eller vedligeholdelse af IKT-produkter, net, infrastruktur, applikationer eller andre net- og informationssystemer, via assistance eller aktiv administration, enten i kundernes lokaler eller på afstand. Udbydere af administrerede tjenester står i lovens bilag 1, pkt. 9.

Ordlyden er bred, og en driftsaftale om en applikation kan ligne beskrivelsen. Men definitionen alene afgør ikke, om et bureau er omfattet. Størrelseskriterierne i lovens §§ 4 og 5 og den samlede vurdering af jeres forretning spiller også ind. Den vurdering hører ikke til testen. Det, testen kan bidrage med, er dokumentation, der holder, uanset hvad vurderingen ender med. → MSP og NIS2

Det kunden kan spørge til

Kundens krav til jer bygger på lovens § 6, stk. 1. Nr. 5 handler om sikkerhed ved erhvervelse, udvikling og vedligeholdelse af net- og informationssystemer, herunder håndtering af sårbarheder. Nr. 4 handler om forsyningskædesikkerhed, herunder forholdet til direkte leverandører og tjenesteudbydere. Et bureau med driftsaftale er begge dele på én gang.

Er kunden selv en digital udbyder, fx en udbyder af onlinemarkedspladser, gælder gennemførelsesforordning (EU) 2024/2690 for kunden. Bilagets punkt 5.1.4 opregner, hvad kontrakter med leverandører og tjenesteudbydere skal angive, hvor det er relevant, bl.a. cybersikkerhedskrav, besked om hændelser, ret til audit eller auditrapporter og håndtering af sårbarheder. Andre NIS2-kunder er ikke bundet af forordningen, men kan bruge den som skabelon. → Krav til sikker udvikling

Spørgsmålene, der kan komme, er fx:

Udvikling · hvordan I finder og retter sårbarheder i løsningen, og hvornår den sidst er testet.
Adgang · hvem hos jer der kan administrere kundens miljø, og hvordan den adgang er beskyttet.
Opdatering · hvordan rettelser kommer i drift, og hvem der godkender dem.
Underleverandører · hvilken hostingpartner eller cloudplatform løsningen kører på.

Testen har to halvdele

En test af applikationen alene svarer på udviklingsspørgsmålet. Den siger lidt om driften, men ikke om, hvem der kan logge ind på serveren, eller om jeres administrationskonti er adskilt fra hverdagskonti. Omvendt siger en test af jeres driftsadgang intet om fejl i løsningens logik.

Del derfor testen op, så hver halvdel kan beskrives for sig:

Løsningen · det, kundens brugere og kundens kunder møder, inklusive login, roller og integrationer.
Driftsadgangen · jeres administratorkonti, fjernadgang, kontrolpanel hos hostingpartneren og den vej, opdateringer går. → Jeres supportadgang til kunden
Grænsen mod platformen · hvad der ligger hos hostingpartneren eller cloududbyderen, og hvad I selv har sat op. → Leverancen kører hos en hostingpartner

Har I flere kunder på samme driftsplatform, kan driftsdelen testes én gang og beskrives for alle, mens løsningsdelen testes pr. kunde. Det kræver, at rapporten holder de to dele adskilt, så hver kunde kun får det, der vedrører den. Ændrer I driftsopsætningen væsentligt, fx ved flytning til en ny platform, er det et naturligt tidspunkt at teste driftsdelen igen. Hvordan softwarehuse generelt svarer på kunders rapportkrav, er beskrevet på pentestrapport.dk.

Et tænkt eksempel

Et mindre bureau har udviklet en bookingløsning til en fødevarevirksomhed og drifter den på en virtuel server hos en hostingpartner. Kunden sender et spørgeskema med henvisning til NIS2 og beder om den seneste pentestrapport. Bureauet har en rapport om bookingløsningen fra sidste år, men den nævner ikke serveren, administratoradgangen eller kontrolpanelet.

Bureauet svarer med rapporten og en kort beskrivelse af, at driftsadgangen ikke var med. Ved næste test kommer driftsdelen med, efter aftale med hostingpartneren. Kunden får et resumé af begge dele og en plan for de fund, der stadig står åbne. Bureauet noterer samtidig, hvilke dele hostingpartneren selv dokumenterer.

Det skal I lade være med

At svare med en applikationstest alene · kundens krav om tjenesteudbydere kan netop sigte på driftsdelen.
At konkludere selv, at I er omfattet eller ikke omfattet · definitionen er bred, og vurderingen kræver mere end ordlyden.
At teste kundens miljø uden kundens tilladelse · selv om I drifter det, ejer kunden det.
At dele administratorkonti mellem udviklere og driftsfolk · det gør det umuligt at vise, hvem der gjorde hvad.
At glemme hostingpartneren · test af platformens dele kræver partnerens accept.

Hvad kan og ikke kan konkluderes

En test, der dækker både løsning og driftsadgang, kan vise, hvad der var muligt i de to roller på testtidspunktet. Den kan ikke afgøre, om I er omfattet af NIS 2-loven, og den dokumenterer ikke jeres rutiner for udvikling og drift mellem testene. Kunden vurderer selv, om dokumentationen dækker kundens krav.