IT-leverandøraftale efter NIS2: sikkerhedsklausuler, SLA og hændelsesrapportering

En IT-leverandøraftale efter NIS2 bør ikke begrænses til en overordnet complianceerklæring, en generel sikkerhedsklausul og et månedligt mål for oppetid. Den skal omsætte risikoen ved den konkrete tjeneste til en entydig ansvarsfordeling, målbare serviceniveauer, hurtig informationsudveksling om hændelser, adgang til dokumentation og en gennemførlig exitplan. Udgangspunktet er tjenestens kritikalitet og den faktiske fordeling af kontrol mellem parterne. Først derefter kan organisationen fastlægge, hvilke sikkerhedsforanstaltninger, frister, verifikationsrettigheder og rapporteringsforpligtelser kontrakten skal indeholde.

Aftalen som mekanisme til risikostyring

En kontraktgennemgang bør ikke begynde med en standardskabelon til en sikkerhedsklausul, men med et overblik over organisationens leverandørafhængigheder. For hver leverandør skal de understøttede tjenester, processer, systemer, data og lokationer identificeres, hvorefter konsekvenserne af utilgængelighed eller et sikkerhedsbrud vurderes. Først analyseres de afhængigheder, hvor en afbrydelse kan standse driften, begrænse opfyldelsen af forpligtelser eller vanskeliggøre håndteringen af en hændelse. Derfor kræver ikke alle IT-tjenester samme kontraktuelle sikkerhedsniveau.

Leverandørens kritikalitet bør klassificeres på grundlag af en forretningskonsekvensanalyse og en risikovurdering – ikke alene efter kontraktens værdi. Tjenester kræver særlig opmærksomhed, når virksomheden er ansvarlig for kontinuitet og hændelseshåndtering, mens leverandøren kontrollerer de tekniske oplysninger, hændelseslogfiler, sikkerhedskopier eller miljøer, der er nødvendige for at genetablere tjenesten. Organisationen skal desuden udpege en ejer af den leverandørrelaterede risiko. Uden et tydeligt ejerskab bliver ansvaret spredt mellem indkøb, IT, informationssikkerhed og procesejeren.

Aftalen bør udformes med udgangspunkt i relevante afbrydelsesscenarier: driftsfejl, cyberangreb, tab eller beskadigelse af data, manglende adgang til leverandørens personale, brud i underleverandørkæden og ophør af samarbejdet. For hvert scenarie skal parternes handlinger, ansvar, informationsflow og betingelser for genetablering fastlægges. Heraf følger kravene til tilgængelighed, reaktions- og genetableringstider, nødvendig dokumentation samt rettigheder til kontrol og verifikation.

Et løfte om høj tilgængelighed afklarer ikke, hvor længe et produktionsstyringssystem må være utilgængeligt, hvornår nedetiden begynder at blive målt, eller hvem der skal levere de oplysninger, som er nødvendige for at vurdere hændelsen. Det sikrer heller ikke adgang til kopier af hændelseslogfiler, oplysninger om underleverandører eller data, der muliggør en sikker flytning af tjenesten. Disse mangler bliver typisk synlige under en driftsforstyrrelse, hvor ansvarsfordelingen ikke længere kan være underforstået.

En henvisning til NIS2 eller relevante KSC-krav bør afslutte analysen af risiko og ansvar – ikke erstatte kontraktens operationelle indhold. Den bredere ledelsesmæssige sammenhæng beskrives i materialet NIS2 for produktionsvirksomheder: hvem er omfattet, hvilke forpligtelser indføres, og hvordan forberedes organisationen uden at reducere emnet til IT. Omfanget af kontraktændringer skal i hvert enkelt tilfælde tilpasses organisationens rolle, tjenestens kritikalitet og den reelle fordeling af kontrol mellem parterne.

Tjenestens omfang og ansvarsfordeling

Ansvarsfordelingen bør beskrives i et teknisk bilag frem for at blive efterladt i en generel definition af kontraktens genstand. Bilaget bør angive de omfattede aktiver og miljøer, datatyper, behandlings- og leveringssteder, grænseflader, supporttider og undtagelser. Uden disse oplysninger kan det ikke fastslås entydigt, hvor leverandørens ansvar ophører, hvilken hændelse der starter SLA-målingen, eller hvem der sikrer komponenterne i grænsefladen mellem systemerne.

Sikkerhedsforanstaltninger bør beskrives gennem det ønskede resultat, den ansvarlige part og den dokumentation, der beviser gennemførelsen. Teknologiske detaljer kan placeres i styret teknisk dokumentation, så aftalen ikke hurtigt bliver forældet. Leverandørens standardkatalog over kontroller bør først accepteres, når det er sammenholdt med risikoen ved den konkrete tjeneste, og identificerede mangler er håndteret. En ansvarsmatrice bør skelne mellem ejeren af kontrollen, den udførende part og den part, der kan godkende afvigelser.

Hvis leverandøren administrerer miljøet, bør aftalen også regulere privilegeret adgang: funktionsadskillelse, autentifikationsmetode, registrering af administrative handlinger og omgående tilbagekaldelse af rettigheder ved rolleændringer eller samarbejdets ophør. En erklæring om, at der udføres backup, er ikke tilstrækkelig, hvis kunden ikke ved, hvem der krypterer kopierne, hvor de opbevares, hvem der kan genetablere dem, og hvilken dokumentation der bekræfter resultatet af en genetableringstest.

Leverandøren bør føre en ajourført oversigt over underleverandører, der påvirker tjenesten, med beskrivelse af deres roller og behandlingssteder. Leverandøren skal samtidig pålægge dem krav, der ikke er mindre strenge end dem, som er aftalt med kunden. Aftalen skal præcisere, hvilke ændringer der kræver forudgående godkendelse, og hvilke der alene kræver underretning og en fornyet risikovurdering. Et ledelsessystemcertifikat kan understøtte vurderingen, men det erstatter ikke et klart ansvar for den konkrete tjeneste. Sammenhængen uddybes i materialet NIS2 og DS/EN ISO 27001: Hvad dokumenterer et certifikat, og hvad mangler fortsat i forhold til KSC.

Sikkerhedsklausuler, der kan verificeres

En sikkerhedsklausul bliver først styrbar og efterprøvbar, når den angiver det forventede resultat, anvendelsesområdet, aktivitetens hyppighed, dokumentationsformen og processen for håndtering af afvigelser. Formuleringer som »i overensstemmelse med bedste praksis« eller »med fornøden omhu« kan supplere kravene, men gør det ikke muligt at afgøre, om leverandøren har opfyldt sin forpligtelse. For hver kontrol bør der udpeges en kravansvarlig, en opbevaringsperiode for dokumentation og en part med mandat til at godkende undtagelser.

Kravene bør som minimum omfatte styring af sårbarheder og opdateringer, sikker konfiguration, kryptering, beskyttelse og opbevaring af hændelseslogfiler, backup, test af genetablering, ændringsstyring og adgangskontrol. Hyppigheden af adgangsgennemgange, genetableringstest og rapportering samt fristerne for afhjælpning af sårbarheder skal fastsættes ud fra tjenestens risikovurdering. De bør ikke være ens for alle leverandører.

Enhver afvigelse bør registreres med begrundelse, frist for afhjælpning, risikoejer og kompenserende kontroller. Godkendelsen kræver en vurdering af, om de kompenserende kontroller reelt reducerer risikoen til det niveau, organisationen har accepteret.

Et krav om regelmæssig backup er ufuldstændigt, hvis det ikke angiver, hvilke data og systemer der er omfattet, opbevaringsperioden, beskyttelsen mod ændring eller sletning, adgangsreglerne og hyppigheden af genetableringstest. Kravet bør også beskrive, hvordan leverandøren rapporterer en mislykket backup eller test, hvem der godkender de korrigerende handlinger, og hvilken rapport der dokumenterer deres afslutning. Tilsvarende kræver et krav om afhjælpning af sårbarheder en aftalt klassifikationsmetode, risikobaserede reaktionsfrister, regler for udsættelse af opdateringer og dokumentation af midlertidige kontroller.

Dokumentationen bør opdeles i materiale, der leveres periodisk, og materiale, der stilles til rådighed efter anmodning. Den første kategori kan omfatte sårbarhedsoversigter, opdateringsrapporter, resultater af genetableringstest og dokumentation for adgangsgennemgange. Efter en hændelse, en væsentlig ændring eller en konstateret afvigelse kan der være behov for detaljerede testresultater, hændelseslogfiler, ændringshistorik, undtagelsesregister og plan for korrigerende handlinger. Omfang, ejerskab og opbevaringsperioder bør kobles til principperne i NIS2- og KSC-dokumentation før kontrol: Hvilke politikker, registre og beviser er reelt nødvendige.

Retten til verifikation bør være trindelt og praktisk gennemførlig, også når leverandøren er en cloududbyder. Første niveau kan bestå af dokumentgennemgang og et afklarende møde. Næste niveau kan omfatte uafhængige rapporter eller aftalte test, mens audit på stedet kan forbeholdes forhøjet risiko, en væsentlig hændelse eller manglende troværdig dokumentation. Aftalen bør regulere varsler, fortrolighed, teknisk omfang og lukning af auditfund uden at give kunden rettigheder, der ikke kan udøves i et delt miljø.

SLA for robusthed – ikke kun oppetid

SLA’en bør baseres på en analyse af forretningspåvirkningen og ikke på leverandørens standardkatalog. Procesejeren fastlægger først den tolerable afbrydelsestid, det acceptable datatab og konsekvenserne for produktion, kundeservice, afregning og retlige forpligtelser. Herfra udledes mål for genetableringstid, krav til alternativ drift og nødprocedurer samt prioritering af henvendelser. Et månedligt tilgængelighedstal besvarer ikke spørgsmålet om, hvorvidt én enkelt fejl på et kritisk tidspunkt kan standse processen længere, end organisationen kan acceptere.

Ud over tilgængelighed bør aftalen fastsætte tiden til kvittering for en henvendelse, påbegyndelse af diagnose, genetablering af funktion og fjernelse af årsagen. Den bør også beskrive kommunikationshyppighed, eskalationsniveauer og håndtering uden for normal arbejdstid. Reaktionstid er ikke det samme som genetableringstid, og aktivering af en midlertidig løsning betyder ikke, at problemet er endeligt løst. Den tydelige adskillelse gør det muligt for driften at vide, hvornår arbejdet kan genoptages, og for tjenesteejeren at vide, hvornår leverandøren skal have afsluttet årsagsanalysen og implementeret en varig korrigerende handling.

For et system, der styrer en produktionsproces, kan en kritisk hændelse kræve øjeblikkelig eskalation og løbende kommunikation, indtil nødproceduren er aktiveret. Den samme fejl i et uddannelsesmiljø kan få lavere prioritet. Klassifikationen skal derfor bygge på forretningspåvirkningen og ikke alene på den tekniske fejlbeskrivelse. Hvis organisationen har pålidelige historiske data, bør tærsklerne fastsættes under hensyntagen til faktiske reaktions- og genetableringstider, tilgængelighedsresultater og antallet af gentagne driftsfejl.

Målemetoden bør angive datakilden, tidszonen, tidspunktet for start og stop af målingen, de aftalte servicetider, vedligeholdelsesvinduer og reglerne for omklassificering af en hændelse. Undtagelser fra målingen skal fremgå af en afgrænset og verificerbar liste. De må ikke omfatte hændelser, der ligger inden for leverandørens ansvarsområde. Sammenhængen mellem disse krav og den faktiske operationelle parathed kan vurderes gennem NIS2-audit i en produktionsvirksomhed – sådan vurderes organisationens parathed til de nye forpligtelser.

Servicekreditter og symbolske kompensationer genetablerer ikke processen og reducerer ikke følgerne af et driftsstop. Større operationel værdi har et krav om en afhjælpningsplan, ledelsesmæssig eskalation, yderligere robusthedstest og ret til at opsige aftalen ved vedvarende eller gentagen manglende opfyldelse af de aftalte niveauer. En økonomisk sanktion kan understøtte ansvarligheden, men kan ikke erstatte mekanismerne til genetablering, årsagsafhjælpning og forebyggelse af gentagelser.

Hændelser og rapporteringsforpligtelser

Aftalen bør forpligte leverandøren til uden unødigt ophold at rapportere enhver hændelse, der kan påvirke tjenesten, data, driftskontinuiteten eller kundens sikkerhed. Den første underretning må ikke afhænge af en fuldstændig bekræftelse af årsagen, skadens omfang eller hændelsens retlige klassifikation. Den kontraktuelle frist bør indeholde tilstrækkelig buffer til, at kunden kan foretage sin egen vurdering og overholde eventuelle eksterne frister. Fristen skal baseres på tjenestens kritikalitet og tilgængeligheden af et døgnbemandet kontaktpunkt – ikke på parternes administrative bekvemmelighed.

Informationsflowet bør opdeles i en indledende advarsel, løbende statusopdateringer, en afsluttende hændelsesrapport og en analyse af den grundlæggende årsag. For hvert trin skal aftalen fastlægge oplysningernes omfang, godkendt kanal, modtagere, opdateringshyppighed og eskalationsregler ved manglende kontakt. Den første meddelelse bør som minimum indeholde tidspunktet for opdagelse, berørte aktiver og tjenester, forventet påvirkning, iværksatte handlinger, tilgængelige tekniske indikatorer, vurdering af risikoen for yderligere spredning og tidspunktet for næste opdatering. Kontaktlisten skal omfatte stedfortrædere og testes regelmæssigt, også uden for normal arbejdstid.

Hvis leverandøren opdager usædvanlig trafik i et miljø, der driver en kritisk applikation, bør kunden advares, før leverandøren endeligt har fastslået, om der er sket et brud. Kunden aktiverer sin egen hændelseshåndteringsproces, udpeger den beslutningsansvarlige, involverer beredskabsteamet og – hvor det er relevant – forsikringsselskabet samt fastlægger, hvem der godkender ekstern rapportering og kommunikation til kunder. Leverandøren sikrer de aftalte logfiler og tekniske spor og understøtter analyse, begrænsning af konsekvenser og afgrænsning af hændelsen, men overtager ikke kundens regulatoriske ansvar.

Klausulerne bør også beskrive, hvordan dokumentation bevares og stilles til rådighed, hvordan dens integritet beskyttes, hvordan beslutninger registreres, og hvordan oplysninger til eksterne indberetninger og den efterfølgende årsagsanalyse udarbejdes. Frister, modtagere og indhold i eksterne indberetninger skal i hvert tilfælde verificeres efter gældende ret, organisationens status og hændelsens karakter. Registre over underretninger, beslutninger, eskalationer og handlinger bør kobles til materialet NIS2- og KSC-dokumentation før kontrol: Hvilke politikker, registre og beviser er reelt nødvendige, mens tilpasningsplanen kan sammenholdes med Implementering af NIS2 efter registrering i KSC-fortegnelsen – handlingsplan frem til 3. april 2027.

Implementering, leverandøropfølgning og sikker exit

Underskrivelsen af et kontrakttillæg afslutter ikke leverandørstyringen. Kontraktejeren bør regelmæssigt gennemgå SLA-resultater, hændelser, afvigelser, korrigerende handlinger, ændringer blandt underleverandører og aktualiteten af den dokumentation, der bekræfter kravopfyldelsen. Grundlaget for opfølgningen er et kontraktregister, som mindst indeholder fornyelsesdato, ejer, tjenestens kritikalitet og status for de aftalte sikkerhedsforanstaltninger. En complianceerklæring erstatter ikke rapporter, testresultater eller registreringer, der dokumenterer den faktiske opfyldelse af forpligtelserne.

Før en kontrakt fornyes, eller tjenesten ændres væsentligt, bør dens kritikalitet, tekniske og procesmæssige afhængigheder, koncentrationen af tjenester hos én leverandør, kontrollernes praktiske gennemførlighed og muligheden for at skifte til en alternativ løsning vurderes på ny. Gennemgangen gør det muligt at afgøre, om et kontrakttillæg er tilstrækkeligt, eller om der kræves en ny indkøbsproces. Hvis en strategisk leverandør afviser audit eller ændrede vilkår, bør organisationen dokumentere manglen og vælge mellem en kompenserende kontrol, formel accept af restrisikoen eller leverandørskifte.

Exitplanen skal være praktisk gennemførlig, allerede før aftalen opsiges. Den bør omfatte tilbagelevering og overførsel af data i et anvendeligt format, migrationsbistand, kontinuitet i overgangsperioden, tilbagekaldelse af adgang, sletning af kopier samt dokumentation for, at disse aktiviteter er gennemført. Samtidig skal de registreringer, der kræves til retlige, bevismæssige og auditmæssige formål, bevares. En praktisk test kan bestå i at genetablere data hos en anden leverandør og kontrollere fuldstændighed, migrationstid og muligheden for at deaktivere de eksisterende konti.

Moderniseringen af kontraktporteføljen bør begynde med de tjenester, der har størst betydning for driften, mens identificerede mangler prioriteres efter konsekvens og hastende karakter. Effektiviteten af de aftalte mekanismer bør testes gennem en hændelsesøvelse og audit af en stikprøve af dokumentationen. Resultaterne fra gennemgang af SLA, hændelser, afvigelser, korrigerende handlinger og exittest viser, om kravene fungerer i praksis, eller kun eksisterer som kontrakttekst.

Vurderingens omfang kan kobles til materialet NIS2-audit i en produktionsvirksomhed – sådan vurderes organisationens parathed til de nye forpligtelser. Organisationens konkrete forpligtelser skal samtidig fastlægges under hensyntagen til dens status, som behandles i NIS2-direktivet – hvem er omfattet, og hvilke virksomheder skal opfylde de nye krav?