KHALEGI DIGITAL

Valget mellem fastpris og forbrugsbaserede prismodeller er centralt i offentlige cloud-udbud, da det påvirker både økonomisk forudsigelighed og fleksibilitet i driften. Den rigtige model afhænger af den konkrete løsnings kompleksitet, variationen i belastning og organisationens modenhed i forhold til kapacitets- og økonomistyring.

Fastprismodel (Fixed Price):

• Karakteristika:
  Pris og ydelser aftales på forhånd og ændres som udgangspunkt ikke, uanset om forbruget overstiger eller ligger under forventningen.

• Fordele:

  • Økonomisk forudsigelighed og budgetkontrol.

  • Velegnet til stabile driftsmiljøer med kendt belastning.

  • Enkel administration og fakturering.

• Ulemper:

  • Risiko for overbetaling ved lavt eller svingende forbrug.

  • Mindre incitament for leverandøren til optimering af ressourcer.

  • Kan give leverandøren anledning til at prissætte konservativt (risikopåslag).

Forbrugsbaseret prismodel (Pay-as-you-go / Usage-based):

• Karakteristika:
  Prisen afhænger af den faktiske anvendelse af fx CPU, storage, netværk eller antal brugere.

• Fordele:

  • Skalerbarhed og fleksibilitet.

  • Bedre udnyttelse af ressourcer ved svingende eller uforudsigeligt forbrug.

  • Ofte lavere omkostninger ved kortvarige eller variable behov.

• Ulemper:

  • Økonomisk usikkerhed – svært at forudsige præcise udgifter.

  • Kræver modenhed i forhold til løbende monitorering og kapacitetsstyring.

  • Øget administrativ kompleksitet i fakturering og opfølgning.

Overvej hybridmodeller:

Flere leverandører tilbyder i dag kombinerede modeller, hvor der fx er fast pris på basisinfrastruktur og forbrugstaksering af ekstra kapacitet. Det giver både kontrol og fleksibilitet – og gør det muligt at anvende fx budgetlofter, pristrapper og cost caps som risikostyringsmekanismer.

Konklusion:

Fastpris anbefales til løsninger med stabilt forbrug og begrænsede variationer, hvor budgetkontrol vægtes højt. Forbrugsbaseret model er oplagt, hvor fleksibilitet og skalerbarhed er vigtig, og organisationen har værktøjer og governance til løbende opfølgning på ressourceforbrug og økonomi. Uanset model bør prismodellen specificeres klart i udbudsmaterialet og understøttes af krav til fakturatransparens og kapacitetsrapportering.

Økonomisk forudsigelighed i cloudkontrakter er afgørende for at undgå budgetoverskridelser og sikre, at offentlige midler anvendes effektivt. Da mange cloudtjenester prissættes efter forbrug, er det vigtigt, at ordregiver etablerer mekanismer, der både begrænser udsving og giver overblik over fremtidige omkostninger.

Nøglemekanismer til økonomisk forudsigelighed:

1. Cost caps (udgiftslofter):
   Fastlæg en maksimal grænse for månedlige eller årlige omkostninger. Når grænsen nås, skal yderligere forbrug enten stoppes, godkendes særskilt eller faktureres til særbetingelser. Dette fungerer som en økonomisk sikkerhedsventil og kan indgå direkte i kontrakten.

2. Pristrapper:
   Indfør rabatsatser eller differentierede priser, hvor enhedsprisen falder ved højere volumen. Dette sikrer skalafordele og budgetkontrol ved stigende anvendelse og gør økonomien mere forudsigelig ved vækst i brugerantal eller datamængder.

3. Scenarieberegninger:
   Gennemfør økonomiske modeller med forskellige belastningsscenarier (f.eks. lavt, forventet og højt forbrug) som del af kravspecifikation eller kontraktbilag. Dette giver beslutningsgrundlag og øger gennemsigtigheden for både ordregiver og tilbudsgivere.

4. Anvendelse af historiske data:
   Brug eksisterende drifts- og forbrugsdata fra on-premise eller tidligere systemer til at modellere realistisk cloud-forbrug. Det gør det lettere at fastsætte relevante grænser og vælge passende prismodeller.

5. Løbende omkostningsrapportering og opfølgning:
   Kræv månedlig eller kvartalsvis rapportering fra leverandøren med forbrugsopdeling, afvigelser fra budget og fremadrettede estimater. Dette giver mulighed for løbende budgetjustering og tidlig opdagelse af uforudsete omkostninger.

6. Krav til prismodel og fakturatransparens:
   Sørg for, at prismodellen er klart beskrevet i kontrakten – fx timepriser, faste moduler, overforbrugsbetingelser. Kræv, at fakturaer indeholder detaljeret forbrugsoversigt pr. komponent, så I kan validere og følge udviklingen tæt.

Konklusion:

Ved at kombinere tekniske og kontraktuelle mekanismer som cost caps, pristrapper, scenarieberegninger og forbrugsrapportering kan offentlige organisationer opnå en høj grad af økonomisk kontrol og forudsigelighed – også i cloudmiljøer med variabelt forbrug. Det er afgørende, at disse mekanismer integreres i kontraktgrundlaget og governance-strukturen, så de er operationelle og kan håndhæves i praksis.

Skjulte og stigende omkostninger udgør en væsentlig risiko i cloudprojekter – især i offentlige kontrakter, hvor uforudsete udgifter kan udfordre budgetrammer og compliance. Cloudens fleksibilitet og forbrugsbaserede afregning kan føre til merforbrug, hvis ikke styringen er tilstrækkelig. Derfor bør der fra starten indarbejdes tekniske, kontraktuelle og organisatoriske mekanismer til at sikre omkostningskontrol.

1. Krav om gennemsigtighed i prisbilag og fakturering:

• Prismodellen bør være detaljeret og opdelt i konkrete enheder (f.eks. pr. GB lagring, antal API-kald, CPU-tid).

• Kræv, at alle priser fremgår i kontraktens bilag, og at der anvendes en klar metode til beregning af totalomkostninger.

• Inkludér krav om, at alle fakturaer specificeres med forbrugsdetaljer pr. komponent og med angivelse af eventuelle variable tillæg.

2. Anvend forecast-modeller og forbrugsprognoser:

• Udarbejd forbrugsprognoser baseret på forventet drift, tidligere forbrugsmønstre og vækstscenarier.

• Brug disse modeller i udbudsfasen og opfølgningen til at validere leverandørens prissætning og vurdere konsekvenser af kapacitetsændringer.

3. Governance og økonomiopfølgning:

• Etabler governance-strukturer med faste møder og KPI’er for økonomiopfølgning.

• Brug cloud management-værktøjer eller dashboards (fx Azure Cost Management, AWS Budgets) til realtidsovervågning af omkostninger og tendenser.

• Anvend automatiserede alarmer ved overskridelser af definerede tærskelværdier.

4. Budgetloft og variansanalyse:

• Definér månedlige eller kvartalsvise budgetlofter (cost caps) i kontrakten.

• Kræv, at leverandøren leverer variansanalyser med forklaring på eventuelle overskridelser og forslag til afhjælpning.

5. Håndtering af indirekte omkostninger:

• Tag eksplicit højde for omkostninger til:

  • Oplæring af brugere og systemansvarlige.

  • Integration med eksisterende systemer (API’er, sikkerhed, logning).

  • Overvågning og compliance-aktiviteter.

  • Intern support og kapacitetsopbygning.

• Disse udgifter bør medtages i total cost of ownership (TCO) og ikke kun vurderes som eksterne licens- eller driftsomkostninger.

Konklusion:

Gennemsigtighed, teknisk forbrugsstyring og økonomisk governance er de centrale mekanismer til at håndtere skjulte eller stigende cloudomkostninger. Offentlige organisationer bør formulere tydelige krav i både udbud og kontrakt – og følge op med faste styringsprocedurer – for at sikre, at cloudprojekter holder sig inden for de økonomiske rammer og leverer dokumenteret værdi.

Pristrapper er en prismekanisme, hvor enhedsprisen på en ydelse falder i takt med, at forbruget stiger. I cloudanskaffelser anvendes pristrapper strategisk for at sikre, at ordregiver opnår bedre enhedspriser ved stigende volumen, og dermed fremmer økonomisk skalerbarhed og forudsigelighed – særligt i kontrakter med mange brugere eller datatunge løsninger.

Hvordan fungerer pristrapper?

En pristrappe består typisk af et sæt definerede forbrugsintervaller med tilhørende priser, fx:

• 0–1000 GB → 0,60 DKK/GB

• 1001–5000 GB → 0,40 DKK/GB

• 5001+ GB → 0,25 DKK/GB

Prisen pr. enhed reduceres, jo mere kapacitet eller ressource der anvendes, hvilket giver incitament til at samle forbrug og udnytte løsningen effektivt.

Fordele ved pristrapper i cloudkontrakter:

1. Skalerbarhed med økonomisk kontrol:
   Pristrapper sikrer, at udgifterne ikke stiger lineært med forbruget, men at større anvendelse belønnes med lavere marginalomkostning – hvilket er vigtigt i løsninger med potentiale for vækst i brugere eller datamængde.

2. Budgetoptimering og incitament til konsolidering:
   Ved at designe systemer, der samler belastning frem for at sprede den, kan organisationen udnytte trappens volumenfordele. Det kan også skabe incitament til at nedlægge ældre løsninger og flytte trafik til den nye platform.

3. Bedre forhandling af kontraktvilkår:
   Hvis ordregiver tydeligt dokumenterer forventet forbrug, kan pristrappen gøres mere aggressiv fra start. Det skaber en mere konkurrencedygtig prisstruktur og fremmer reel besparelse ved vækst.

4. TCO-optimering og skaleringsscenarier:
   Pristrapper kan med fordel kombineres med scenarieberegninger i udbudsmaterialet, så både minimums- og maksimumsforbrug estimeres og evalueres. Det gør det muligt at sammenligne tilbud ikke kun på nutidig pris, men på totaløkonomi over hele kontraktperioden.

Hvordan integreres pristrapper i udbud og kontrakt?

• Inkludér pristrappen som en del af prisbilag og bed leverandøren udfylde prisintervaller.

• Beskriv trappens mekanisme og hvordan forbruget måles (fx pr. måned, kvartal eller samlet).

• Kræv løbende rapportering af, hvilket trin forbruget befinder sig på – og hvordan det påvirker pris.

Konklusion:

Pristrapper er et centralt redskab i strategisk cloudanskaffelse, da de forener fleksibilitet og økonomisk kontrol. Ved korrekt implementering og gennemsigtig opfølgning skaber de både lavere priser ved vækst og bedre forhandlingsposition for den offentlige myndighed.

ISAE 3000 og ISAE 3402 er internationale revisionsstandarder, som anvendes til at dokumentere og vurdere leverandørers kontroller og procedurer. I offentlige cloududbud spiller disse erklæringer en vigtig rolle som objektiv dokumentation for leverandørens sikkerhedsniveau, databehandlingskontrol og overholdelse af relevante krav.

ISAE 3000 – For overholdelses- og it-sikkerhedsrelaterede kontroller:

• Formål:
  ISAE 3000 (International Standard on Assurance Engagements) anvendes typisk til vurdering af kontroller vedrørende compliance, databeskyttelse (GDPR), informationssikkerhed og bæredygtighed.

• Anvendelse i cloud:
  En ISAE 3000-erklæring kan dokumentere, at leverandøren har implementeret tilstrækkelige foranstaltninger til at beskytte kundens data – både teknisk og organisatorisk – og at kontrollerne er blevet revideret af en uafhængig revisor.

ISAE 3402 – For driftskontrol og serviceorganisationers processer:

• Formål:
  ISAE 3402 bruges til at dokumentere leverandørens interne driftsprocesser og kontroller i forbindelse med levering af tjenester til kunder – især når de har betydning for kundens egne regnskabsaflæggelse eller it-afhængige processer.

• Type I og II:

  • Type I: Vurdering af kontroller på et givent tidspunkt.

  • Type II: Vurdering af kontroller over en periode (typisk 6-12 måneder), inkl. test af deres virkning – og anbefales i de fleste udbudssituationer.

Hvorfor er de relevante i offentlige cloududbud?

1. Objektiv dokumentation for compliance og sikkerhed:
   ISAE-erklæringer giver ordregiver et uafhængigt og struktureret indblik i leverandørens evne til at beskytte data, styre risici og overholde kontraktuelle og lovgivningsmæssige krav (fx GDPR, NIS2, ISO 27001).

2. Styrkelse af tillid og risikoafdækning:
   Ved at kræve årlige ISAE-erklæringer får ordregiver mulighed for at følge op på leverandørens modenhed og sikre, at sikkerheds- og complianceforhold løbende dokumenteres og revideres.

3. Understøtter governance og tilsyn:
   ISAE-erklæringer kan indgå i kontraktens dokumentationskrav og anvendes som grundlag for styring og kontrol – fx i forbindelse med årlige review-møder, databehandleraftaler og risikoevalueringer.

Anbefaling i praksis:

• Kræv mindst én gyldig ISAE 3000 eller ISAE 3402 Type II-erklæring pr. år fra leverandøren.

• Specificér krav til indhold og dækning (fx scope, kontrolområder, testmetode).

• Overvej supplerende erklæringer eller certifikater som ISO 27001, SOC 2 eller NIST 800-53 for yderligere sikkerhed og dokumentation.

Konklusion:

ISAE 3000 og 3402 bør anvendes som minimumskrav i cloududbud, hvor sikkerhed, compliance og driftssikkerhed er forretningskritiske. De giver den offentlige ordregiver en konkret og efterprøvbar sikkerhed for, at leverandøren har styr på sine kontroller – og at dette kan dokumenteres årligt af en uafhængig tredjepart.

Governance og sikkerhedsbilag hænger uløseligt sammen i offentlige IT- og cloudprojekter. Governance udgør det interne styringssystem, der sikrer, at organisationen har processer, kompetencer og ansvar for at definere, følge op på og håndhæve de sikkerhedsmæssige krav, som kontrakten stiller til leverandøren. Hvis governance ikke er på plads internt, risikerer man at indgå aftaler, man hverken kan kontrollere eller efterleve i praksis.

1. Hvad er governance i denne sammenhæng?

Governance dækker her over:

• Ansvarsfordeling (ejerskab for sikkerhed og compliance internt),

• Roller og beslutningskompetencer i relation til leverandøren,

• Procedurer for ændringsstyring, hændelseshåndtering, audits og opfølgning,

• Samt kapacitet til at forstå og administrere kontraktens sikkerhedskrav.

2. Formålet med kontraktuelle sikkerhedsbilag:

Sikkerhedsbilag i cloud- eller IT-kontrakter har til formål at specificere:

• Tekniske og organisatoriske foranstaltninger (f.eks. adgangsstyring, kryptering, logning),

• Dokumentations- og revisionskrav (f.eks. ISAE 3000/3402, ISO-certificeringer),

• Rapportering og håndtering af sikkerhedshændelser,

• Og krav til tilsyn, underleverandører og datalokation.

3. Hvorfor governance er en forudsætning for effektive sikkerhedsbilag:

Hvis en myndighed fx kræver 24/7 hændelsesrapportering, men ikke har en sikkerhedsorganisation, der kan håndtere alarmer uden for normal arbejdstid – eller kræver tekniske sikkerhedsfunktioner, men mangler den interne kompetence til at evaluere leverandørens målinger – undermineres aftalen.

Derfor skal sikkerhedsbilag tilpasses organisationens:

• Informationssikkerhedsniveau (f.eks. baseret på ISO 27001 eller ISMS),

• Ressource- og kompetenceniveau,

• Risikoprofil og datatyper.

4. Best practice:

• Sørg for, at sikkerhedsbilagene bygger på organisationens egne politikker og governance-struktur.

• Involvér både den informationssikkerhedsansvarlige og juridiske kompetencer i udarbejdelsen af bilagene.

• Sæt KPI’er og opfølgningsmekanismer op, så sikkerhed bliver målbart og styrbart.

5. Kontraktuel forankring og opfølgning:

Governance bør ikke kun eksistere som intern praksis, men også afspejles i kontraktens struktur:

• Hvem er ansvarlig for godkendelse af ændringer i sikkerhedsforanstaltninger?

• Hvordan følges op på revisionserklæringer og hændelser?

• Hvad sker der, hvis krav ikke overholdes (fx bod eller eskalation)?

Konklusion:

Sikkerhedsbilag er kun effektive, hvis de understøttes af en robust governance-struktur internt hos ordregiver. Uden governance bliver sikkerhedsaftaler ofte formelle krav uden reel effekt. Derfor bør alle krav i sikkerhedsbilagene kunne forankres organisatorisk, opfølges teknisk og håndhæves kontraktuelt – i praksis, ikke kun på papir.

Når en offentlig myndighed indgår en cloud- eller IT-kontrakt med en leverandør, der opererer med avancerede sikkerhedskontroller og høje krav til samspil og opfølgning – men myndigheden selv mangler governance, kompetencer eller processer til at matche dette niveau – opstår en række alvorlige risici.

1. Risiko for compliance-brud og tilsynssanktioner:

Hvis der ikke følges op på leverandørens sikkerhedserklæringer, hændelsesrapporter eller revisionskrav, kan det føre til overtrædelse af GDPR, NIS2, offentlighedsloven eller interne sikkerhedspolitikker. Tilsynsmyndigheder som Datatilsynet eller Rigsrevisionen vil kunne konstatere, at ordregiver ikke har levet op til sit ansvar som dataansvarlig eller som systemejer.

2. Risiko for uhensigtsmæssig eller ukontrolleret databehandling:

Manglende styring kan betyde, at data behandles, overføres eller opbevares på måder, der strider mod databehandleraftalen eller den tekniske specifikation. Det kan fx omfatte:

• Fejlplacering af data uden for EU,

• Uautoriseret adgang hos underleverandører,

• Manglende sletning eller logning.

3. Risiko for ansvarshuller og konflikter ved driftsbrud eller brud på sikkerheden:

Hvis roller, kontaktpunkter og eskalationsveje ikke er klart defineret og forankret internt, kan det blive uklart, hvem der skal reagere ved fx:

• Et ransomwareangreb,

• En DDoS-hændelse,

• Et brud på persondatasikkerheden.

Dette fører til langsomme reaktionstider, mistet kontrol og potentielt kontraktbrud – både internt og i forhold til borgere og samarbejdspartnere.

4. Svækket dokumentation og auditparathed:

Hvis der ikke er styr på dokumentation, adgangslogning, hændelsesjournaler og governance-protokoller, risikerer organisationen at stå uden den nødvendige dokumentation, når der skal redegøres for sikkerheden ved revision, tilsyn eller klagesager.

5. Manglende evne til at vurdere og håndtere leverandørens erklæringer:

Hvis modtageren af fx en ISAE 3402 Type II-erklæring ikke forstår, hvordan erklæringen skal læses, tolkes og vurderes – og ikke har ressourcer til at handle på eventuelle forbehold – mister dokumentationen værdi.

Konklusion:

Intern governance skal kunne matche leverandørens sikkerhedsniveau – ikke bare på papiret, men organisatorisk, kompetencemæssigt og operationelt. Mismatch mellem governance og leverandørsetup skaber blinde vinkler og uacceptabel risiko. Derfor bør offentlige organisationer altid gennemføre en modenhedsvurdering og sikkerhedsmatch-analyse før kontraktindgåelse – og justere enten governance eller kontraktkrav, så niveauet hænger sammen i praksis.

Sikkerhed og compliance i cloudprojekter bør ikke reduceres til et isoleret bilag i kontrakten. De skal være gennemgående elementer i hele cloudrejsen – fra strategisk planlægning og arkitekturvalg til implementering, drift og exit. Når sikkerhed tænkes ind som en integreret dimension i cloud-livscyklussen, reduceres risici, og myndigheden opnår styrket kontrol og compliance.

1. Strategisk forankring og arkitekturvalg:

• Sikkerhed skal være en strategisk parameter allerede ved valg af cloudmodel (offentlig, privat, hybrid) og serviceform (IaaS, PaaS, SaaS).

• Valg af arkitektur bør inkludere vurdering af:

  • Datalokalitet og jurisdiktion,

  • Isolation af kundedata (single vs. multi-tenant),

  • Adgangsstyring, logning og overvågning.

2. Kravformulering i udbudsmaterialet:

• Sikkerheds- og compliancekrav bør fremgå tydeligt i både kravspecifikation, tildelingskriterier og kontraktvilkår.

• Undgå at placere alle krav i et bilag uden kobling til de funktionelle og tekniske beskrivelser – sikkerhed skal være evaluerbar og aktivt knyttet til løsningen.

3. Teknisk dokumentation og leverandørdialog:

• Kræv, at leverandøren fremlægger detaljeret dokumentation for sikkerhedsarkitektur, hændelseshåndtering, backupstrategier og opdateringsrutiner.

• Inddrag sikkerhed i markedsdialog og forhandlingsfaser for at sikre, at tilbudsgivere forstår niveauet og kan levere i praksis.

4. Governance og intern forankring:

• Etabler governance-strukturer med ansvar for sikkerhed på både teknisk og ledelsesmæssigt niveau (fx via sikkerhedsstyregruppe eller CISO-involvering).

• Skab processer for løbende opfølgning, ændringshåndtering, hændelsesrapportering og revision.

• Integrér sikkerhed i den interne projektgovernance – ikke som en passiv kontrolfunktion, men som en aktiv del af projektledelsen.

5. Drift, compliance og opfølgning:

• Implementér løbende sikkerhedsovervågning og review af logfiler, adgangskontroller og ændringer.

• Kræv regelmæssige sikkerhedsredegørelser, revisionsrapporter (ISAE 3000/3402, ISO 27001), og audit-muligheder for ordregiver.

• Følg op på databehandleraftaler, tredjepartsadgang og evt. underleverandører som en del af den daglige driftsovervågning.

6. Exit og reversibilitet:

• Sikkerhed og compliance skal også tænkes ind i exit-strategien: Hvordan håndteres datamigrering, sletning, dokumentation og ansvarsoverdragelse ved kontraktophør?

• Krav til logudtræk, dataformater og adgang til revisionsspor bør defineres klart i kontrakten.

Konklusion:

Sikkerhed i cloud er ikke en fase eller et bilag – det er en tværgående disciplin, der skal være til stede i hele cloudrejsen. Når sikkerhed og compliance integreres fra arkitektur til exit, skaber det både juridisk robusthed, teknisk sikkerhed og organisatorisk modenhed. Offentlige myndigheder bør derfor arbejde systematisk med sikkerhed som en del af digital governance – ikke som eftertanke.

En Service Level Agreement (SLA) er et centralt styringsværktøj i enhver cloudkontrakt – særligt i offentlige sammenhænge, hvor dokumentation, gennemsigtighed og kontraktopfølgning er afgørende. En god SLA definerer klart, hvad der leveres, hvordan det måles, og hvilke konsekvenser der er ved afvigelser. SLA’en skal være målbar, realistisk og afspejle løsningens forretningskritikalitet.

1. Oppetidsgarantier (Availability):

• Angiv f.eks. “99,9 % månedlig oppetid” for driftstunge løsninger.

• Uddyb hvordan oppetid måles (24/7, kun hverdage?) og hvilke undtagelser der gælder (force majeure, planlagt vedligehold).

• Brug klare definitioner for tilgængelighed – fx hvad udgør nedetid, og hvordan opgøres det?

2. Responstider på henvendelser og fejlindberetninger:

• Specificér maksimale svartider for forskellige typer henvendelser – fx:

  • Kritisk fejl: < 1 time

  • Alvorlig fejl: < 4 timer

  • Almindelig support: < 1 arbejdsdag

3. Fejlretningstider (Recovery Time Objectives, RTO):

• Fastlæg, hvor hurtigt en fejl skal være udbedret afhængigt af fejlkategori.

• Fx “kritisk nedbrud skal være afhjulpet inden for 4 timer”.

4. Performance-KPI’er:

• Mål for hastighed, svartider, svartid for API-kald, responstid i brugergrænsefladen mv.

• KPI’er skal være relevante for slutbrugernes oplevelse og kunne måles uafhængigt af leverandøren, hvis muligt.

5. Fejlkategorier og prioriteringsmodeller:

• SLA’en bør indeholde en skematisk opdeling af fejlkategorier – fx Kritisk, Høj, Mellem, Lav – og hvad der hører under hver kategori.

• Kategoriseringen skal afspejle løsningens anvendelse og betydning for forretningen.

6. Overvågning og rapportering:

• Krav om, at leverandøren aktivt overvåger systemets tilstand og tilgængelighed.

• Leverandøren skal levere periodiske rapporter (fx månedligt) med data om:

  • Oppetid

  • Fejltyper og reaktionstid

  • Afgivne svar og løsningshastighed

  • Antal sager pr. kategori

7. Sanktioner og bonusmodeller (valgfrit):

• Bod ved manglende overholdelse af SLA (f.eks. procentvis reduktion af månedlig betaling).

• Bonusordning ved systematisk overlevering af ydelser ud over krav.

8. Governance og opfølgning:

• SLA’en bør forankres i den overordnede governance-model:

  • Hvordan følges SLA’en op?

  • Hvem har ansvar internt og hos leverandøren?

  • Hvordan håndteres gentagne brud?

Konklusion:

En effektiv SLA er en operationel kontraktmekanisme, ikke bare en bilagstekst. Den skal afspejle løsningens kritikalitet, være målelig og koblet til både tekniske, juridiske og forretningsmæssige mekanismer. I offentlige cloudkontrakter er SLA’en samtidig et vigtigt redskab til at sikre gennemsigtighed, dokumentation og mulighed for sanktion, hvis leverandøren ikke lever op til sit ansvar.

For at en SLA (Service Level Agreement) skal fungere som et effektivt kontraktligt styringsværktøj, skal den ikke kun være velbeskrevet – den skal også være praktisk anvendelig. I offentlige cloud- og IT-udbud betyder det, at kravene i SLA’en skal kunne måles, følges op og danne grundlag for konsekvenser og forbedring. En SLA uden konkret måling er reelt værdiløs.

1. Anvend konkrete, tidsbaserede målepunkter:

• Brug præcise enheder som minutter, timer og procent.
  Eksempler:

  • “Svartid på supportanmodning må ikke overstige 1 time ved kritisk fejl.”

  • “Systemet skal være tilgængeligt 99,9 % af tiden målt pr. kalendermåned.”

• Undgå vage formuleringer som “hurtig behandling” eller “god performance”, medmindre det defineres kvantitativt.

2. Definér fejlkategorier og prioriteringsniveauer:

• Inddel fejl i kategorier (fx Kritisk, Alvorlig, Mellem, Lav) baseret på konsekvenser for driften eller brugerne.

• Tilknyt til hver kategori:

  • Maksimal responstid (hvor hurtigt skal leverandøren reagere?)

  • Maksimal afhjælpningstid (hvor hurtigt skal fejlen være løst?)

  • Sanktioner ved brud (f.eks. bod pr. overskreden time).

3. Brug RTO og RPO (Recovery Time / Point Objectives):

• RTO (Recovery Time Objective): Angiver den maksimale tid, systemet må være nede.

• RPO (Recovery Point Objective): Angiver hvor meget data, man maksimalt må miste ved gendannelse.

• Disse mål gør det muligt at måle leverandørens evne til at håndtere driftsbrud og datagendannelse konkret.

4. Kræv løbende måling og dokumenteret rapportering:

• SLA’en skal forpligte leverandøren til at levere periodiske rapporter (fx månedligt/kvartalsvis) med:

  • Målepunkter og faktiske resultater

  • Afvigelser og årsager

  • Forslag til forbedringer (ved gentagne brud)

• Krav om realtids- eller dashboardsbaseret adgang til visse SLA-parametre kan også overvejes i kritiske løsninger.

5. Fastlæg mekanismer for opfølgning og sanktionsmuligheder:

• Angiv i kontrakten, hvordan SLA-resultater gennemgås (fx i kvartalsvise governance-møder).

• Fastlæg konsekvenser for gentagne eller grove overtrædelser:

  • Bodsmodeller (f.eks. fradrag i faktura baseret på afvigelse fra krav)

  • Eskalationsprocedurer

  • Mulighed for bonus ved systematisk overopfyldelse (valgfrit)

Konklusion:

SLA’er er kun nyttige, hvis de kan efterleves og følges op på i praksis. Ved at formulere målepunkter konkret, baseret på tid og kategorier, og ved at kræve regelmæssig dokumentation og aktiv opfølgning, skabes et effektivt grundlag for styring, samarbejde og ansvar i offentlige cloudkontrakter. En håndterbar SLA er både en teknisk måleenhed og en organisatorisk tryghed.

En velfungerende SLA (Service Level Agreement) bør ikke alene fastlægge krav og målepunkter – den skal også angive, hvad der sker, hvis kravene ikke opfyldes, og hvilke fordele der kan tildeles ved konsekvent god performance. Sanktioner og incitamenter er centrale redskaber til at sikre, at leverandøren har et reelt økonomisk og driftsmæssigt incitament til at overholde og gerne overopfylde de aftalte serviceniveauer.

1. Sanktioner (bodsmodeller)
   a) Bod ved brud på oppetid
   – Eksempel: “Ved overskridelse af oppetidskravet på 99,9 % i en måned reduceres månedlig betaling med 5 % pr. påbegyndt 0,1 % afvigelse.”
   – Bør afspejle løsningens kritikalitet: Jo mere kritisk, jo højere bod.

   b) Bod ved overskridelse af responstider eller fejlretningstider
   – Fastsæt fradrag i faktura eller tillægsbetalinger for overskridelse af SLA-krav i f.eks. kategori 1 (kritiske fejl).
   – Brug f.eks. 500–5.000 kr. pr. påbegyndt time for alvorlige afvigelser afhængigt af systemets forretningsværdi.

   c) Kumulativ bodsgrænse
   – Det anbefales at fastlægge et loft (bodscap), f.eks. maks. 20 % af månedlig betaling, for at gøre modellen juridisk proportionel og forudsigelig.
   – Mulighed for ophævelse af kontrakten ved gentagne grove overtrædelser bør defineres separat i misligholdelsesklausulen.

2. Incitamenter (bonusmodeller)
   a) Bonus ved overopfyldelse
   – Tildel bonus, hvis leverandøren konsekvent leverer over niveau i definerede perioder.
   – Eksempel: “Hvis oppetiden overstiger 99,99 % i 6 på hinanden følgende måneder, udbetales engangsbonus på 10.000 kr.”

   b) Trinvise incitamenter
   – Lav en progressiv incitamentsmodel, hvor leverandøren fx opnår højere fakturering eller fraskriver sig bod ved præstationsforbedring over tid.
   – Brug af performance-index (vægtet gennemsnit) kan understøtte helhedsbillede i stedet for fokus på enkeltmålepunkter.

   c) Forlængelsesincitamenter
   – Giv mulighed for automatisk kontraktforlængelse eller højere point i kommende miniudbud ved dokumenteret høj performance.

3. Hvad skal man være opmærksom på?
   – Sanktioner og incitamenter skal være målbare, objektive og juridisk proportionelle.
   – De bør bygge på faste målepunkter fra SLA’ens øvrige parametre (f.eks. oppetid, RTO, svartid).
   – De skal kunne dokumenteres løbende via rapportering og ikke afhænge af subjektiv vurdering.

Konklusion:
Et effektivt sanktions- og incitamentssystem i SLA’en understøtter både kontraktstyring og partnerskab. Sanktioner sikrer, at leverandøren prioriterer opfyldelse af basiskrav, mens incitamenter fremmer ambition og forbedring. Den rette balance mellem de to dele afhænger af løsningens kritikalitet, leverandørens modenhed og ordregivers strategiske mål med kontrakten.

Når en leverandør fremlægger en SLA (Service Level Agreement) som en del af et tilbud i et offentligt udbud, er det afgørende at vurdere, om aftalen reelt beskytter ordregiverens interesser og matcher løsningens kritikalitet. En SLA er kun tilstrækkelig, hvis den afspejler løsningens betydning, er operationel, og kan håndhæves gennem dokumenterbare målinger og sanktioner.

1. Matcher SLA’en løsningens forretningsmæssige kritikalitet?

• Start med at identificere, hvilke funktioner i løsningen der er kritiske for driften eller borgerbetjeningen.
• Eksempel: Hvis løsningen understøtter en selvbetjeningsplatform for borgere eller kritiske myndighedsprocesser, skal SLA’en stille høje krav til oppetid, fejlretning og hændelseshåndtering.
• Jo mere forretningskritisk en løsning er, desto højere skal kravene til tilgængelighed, svartid og konsekvenser ved brud være.

2. Er målepunkterne præcise, realistiske og kontrollerbare?

• Undersøg om SLA’en anvender tidsbaserede og kvantificerbare målepunkter (f.eks. svartid i minutter, tilgængelighed i procent).
• Kravene skal være realistiske i forhold til leverandørens teknologi og organisation – men også ambitiøse nok til at sikre en stabil leverance.
• Der skal være klare procedurer for, hvordan data opsamles og dokumenteres (logfiler, overvågningsværktøjer, månedlige rapporter).

3. Er der defineret passende konsekvenser ved brud?

• En SLA uden sanktionsmekanisme mister sin styringseffekt.
• Tjek om leverandøren tilbyder:
  • Bodssystem (fx fradrag i faktura ved overskridelse af svartid)
  • Eskaleringsprocedurer (f.eks. krav om ledelsesinvolvering ved gentagne fejl)
  • Opsigelsesadgang eller ophævelse ved alvorlig eller gentagen misligholdelse.
• Sanktioner skal være proportionale men mærkbare nok til at give incitament til overholdelse.

4. Understøtter SLA’en governance og opfølgning?

• En tilstrækkelig SLA skal spille sammen med kontraktens governance-setup:
  • Er der aftalt faste møder for gennemgang af SLA-resultater?
  • Er roller og ansvar klart fordelt mellem ordregiver og leverandør?
  • Hvordan behandles uenigheder og afvigelser?

5. Er SLA’en tilpasset cloudmodellen?

• I cloudprojekter er det vigtigt, at SLA’en tager højde for:
  • Eventuelle underleverandører (f.eks. datacenter eller platform)
  • Skalerbarhed og dynamiske ressourcer
  • Delvis ansvar mellem leverandør og kunde (især i PaaS/IaaS)

Konklusion:

En tilstrækkelig SLA er én, der:

• Afstemmes med løsningens forretningsværdi og risikoprofil,
• Indeholder tydelige, målbare og dokumenterbare parametre,
• Har indbyggede konsekvenser ved brud,
• Og kan indgå i en struktureret governance- og opfølgningsproces.

Hvis en leverandørs SLA mangler disse elementer – eller foreslår upræcise, uforpligtende serviceniveauer – bør ordregiver enten stille krav om forbedring i forhandlingsfasen eller betragte det som en negativ faktor i evalueringen.

Når offentlige myndigheder skal vurdere en cloudleverandørs egnethed, er det afgørende at se ud over den tekniske løsning og fokusere på, om leverandøren organisatorisk er i stand til at levere og drive en kompleks og sikker cloudtjeneste i overensstemmelse med kravene i kontrakten. Organisatorisk modenhed afspejles i både governance, sikkerhed, leverancekapacitet og evnen til at indgå i et langvarigt, tillidsbaseret samarbejde.

1. Certificeringer og dokumenteret sikkerheds- og compliance-niveau:

• Vurder, om leverandøren har relevante tredjepartsvaliderede certificeringer:

  • ISO 27001: Informationssikkerhedsledelse.

  • ISAE 3402 / ISAE 3000: Revisionsudtalelser om kontrolmiljø og compliance.

  • SOC 2: Kontroller relateret til sikkerhed, tilgængelighed, integritet m.v.

• Kræv, at certifikaterne er opdaterede og dækker de relevante områder og geografiske lokationer.

2. Dokumenterede erfaringer fra tilsvarende udbud og sektorer:

• Undersøg, om leverandøren har arbejdet med lignende organisationer, både i størrelse, kompleksitet og regulatoriske krav.

• Se på:

  • Projekternes omfang og varighed.

  • Leverandørens rolle (hoved- eller underleverandør).

  • Om løsningen inkluderede compliance, datamigrering, integrationer eller drift.

• Gennemgå evalueringsrapporter og resultater fra tidligere opgaver, hvis muligt.

3. Analyse af organisatorisk setup og governance-model:

• Bed om indblik i leverandørens interne struktur:

  • Har de dedikerede sikkerhedsteams, DPO, CISO-funktion, driftscenter (NOC/SOC)?

  • Hvordan er deres projektgovernance organiseret (styregrupper, roller, QA)?

  • Hvilke processer har de for ændringsstyring, hændelseshåndtering og opfølgning?

• Dette er afgørende for at vurdere, om de kan samarbejde effektivt med offentlige governance-krav.

4. Interview med nøglepersoner og organisationens kerneaktører:

• Interview projektledere, sikkerhedsansvarlige og evt. underleverandører for at:

  • Validere modenhed, processer og ressourcer.

  • Få indblik i kultur, kommunikation og erfaring med offentlige krav.

  • Vurdere sproglige, tekniske og samarbejdsmæssige evner.

5. Indhentning og vurdering af referencer:

• Kræv mindst 2–3 dokumenterede referencer på tilsvarende projekter.

• Gennemfør strukturerede referenceinterviews med tidligere kunder:

  • Overholdt leverandøren tidsplan og budget?

  • Hvordan var kvaliteten og supporten?

  • Hvordan håndterede de ændringer og uforudsete problemer?

• Brug svarene aktivt i kvalifikationsvurdering og tildeling, jf. udbudslovens § 153–154.

Konklusion:

En leverandørs organisatoriske modenhed og referencer er afgørende for succes i cloudprojekter. Gennem certificeringer, dokumenterede erfaringer, grundig analyse af organisation og governance samt direkte referencetjek kan ordregiver opnå indsigt i, om leverandøren reelt har kapaciteten til at gennemføre og drifte en løsning med høj sikkerhed, compliance og forretningsværdi – og dermed reducere risikoen for projektfejl, konflikter og leverandørsvigt.

Valg af cloudleverandør i offentlige it-projekter er forbundet med en række strategiske og operationelle risici, som bør afdækkes tidligt i processen. Udbud, hvor leverandøren vælges primært ud fra pris eller teknisk funktionalitet, uden fokus på governance, dokumentation og afhængighed, fører ofte til uhensigtsmæssige bindinger, skjulte omkostninger eller kontraktuelle konflikter.

1. Uklar ansvarsfordeling:

• En af de mest almindelige faldgruber er, at hverken kontrakt eller governance tydeligt afgrænser ansvaret mellem leverandør og ordregiver.

• Dette kan føre til tvivl om, hvem der håndterer hændelser, ændringer, databehandling og opfølgning.

• Det er særligt kritisk i cloud, hvor ansvar ofte er delt (shared responsibility model), og leverandøren fx kan være ansvarlig for infrastrukturen, mens ordregiver selv skal sikre datakonfiguration og adgangsstyring.

2. Overafhængighed af én leverandør (vendor lock-in):

• Hvis løsningen ikke er baseret på åbne standarder, veldokumenterede API’er og dataformater, kan det blive teknisk og kontraktuelt vanskeligt at skifte leverandør.

• Samtidig vil en kontrakt uden exit-strategi, krav til datamigrering eller mulighed for tredjepartsvedligehold hurtigt føre til afhængighed.

• Dette forstærkes, hvis leverandøren står for både udvikling, drift og support – uden klare adskillelses- og overdragelsesmekanismer.

3. Urealistiske løfter og utilstrækkelig due diligence:

• I mange udbud sælger leverandører visionære fremstillinger af fleksibilitet, skalerbarhed og “intuitiv brugeroplevelse” – uden konkret dokumentation for, hvordan dette opnås.

• Hvis ordregiver ikke stiller krav om test, demonstrationer, referencer og evaluerbare kriterier, risikerer man at tildele til den “bedst formulerede PowerPoint”, ikke den bedste løsning.

• Vurder i stedet konkrete use cases, funktionelle leverancebeskrivelser og dokumenteret erfaring.

4. Manglende dokumentation og sporbarhed:

• Uden krav om løbende dokumentation – fx tekniske konfigurationer, procesbeskrivelser, sikkerhedsprocedurer og leverancestatus – mister ordregiver overblik og kontrol.

• Det gør det svært at føre tilsyn, evaluere driften eller revidere compliance – og efterlader organisationen sårbar ved konflikter eller leverandørskift.

• Kontrakten bør derfor inkludere krav om dokumentation i standardformater, adgang til konfigurationsdata og versionsstyring.

5. Fravær af governance og aktiv opfølgning:

• En leverandør, selv med høj modenhed, kan ikke drive governance for kunden. Uden faste møder, roller, opfølgningsrutiner og målepunkter bliver driften reaktiv frem for strategisk.

• Mange problemer opstår, fordi ordregiver først opdager mangler, når bruddet har forretningsmæssige konsekvenser.

• Governance skal derfor etableres ved kontraktstart og forankres i organisationens drift – ikke blot som punkt i bilag.

Konklusion:

Ved valg af cloudleverandør bør offentlige organisationer være særligt opmærksomme på ansvarsfordeling, afhængighed, dokumentation og governance. Det handler ikke kun om funktionalitet og pris – men om evnen til at samarbejde, styre og udvikle løsningen over kontraktens levetid. De nævnte faldgruber kan i høj grad forebygges gennem en moden kravspecifikation, grundig markedsdialog og konsekvent kontraktstyring.

Ved overgangen til en cloudløsning ændres både teknologi, arbejdsgange og ansvar – og det kan skabe usikkerhed og modstand blandt medarbejdere. En succesfuld cloud-transition kræver derfor ikke kun teknisk implementering, men også målrettet forandringsledelse med fokus på brugeradoption, kommunikation og træning. Erfaring viser, at selv de bedste løsninger fejler, hvis brugerne ikke forstår dem, accepterer dem – eller oplever dem som en forringelse.

1. Involver brugerne tidligt i processen

• Inkludér slutbrugere i behovsafdækning, test og brugerrejser.

• Opret en brugergruppe eller pilotteam, der kan afprøve løsningen tidligt og give feedback.

• Brug feedback til at justere funktionalitet, brugerflade og terminologi.

2. Udarbejd en målrettet kommunikationsstrategi

• Informér tidligt og løbende om formål, tidsplan og forventede ændringer.

• Kommunikér ikke kun “hvad og hvornår” – men også “hvorfor og hvordan”.

• Differentier budskaber til ledelse, it-funktion, slutbrugere og eventuelle faglige superbrugere.

• Brug flere kanaler: infomøder, intranet, e-mails, visualiseringer, korte videoer.

3. Gør fordelene konkrete og relevante

• Vis, hvordan den nye løsning forbedrer arbejdsgange, reducerer dobbeltarbejde, eller understøtter borgerkontakt bedre.

• Eksempler:

  • “Nu kan du tilgå systemet hjemmefra uden VPN.”

  • “Du behøver ikke længere ringe til IT for at nulstille adgangskoder.”

• Tilpas kommunikation til forskellige brugergrupper og funktioner.

4. Tilbyd skræddersyet oplæring og support

• Tilbyd både grundlæggende og avanceret oplæring målrettet brugerens rolle.

• Gennemfør træning tæt på go-live – og gentag efter behov.

• Stil guides og e-læringsmaterialer til rådighed, og udpeg superbrugere eller ambassadører, der kan støtte kollegerne i praksis.

• Sørg for hurtig og synlig hjælp i de første uger efter idriftsættelse.

5. Monitorér og følg op på brugeradoption

• Opsæt målepunkter for adoption, fx antal aktive brugere, gennemførte kurser eller supporthenvendelser.

• Gennemfør korte brugerundersøgelser og opsaml feedback.

• Justér indsatsen undervejs – fx ved at identificere faggrupper eller enheder med lav adoption.

6. Ledelsesforankring og opbakning

• Ledelsen skal kommunikere, støtte og forpligte sig til skiftet.

• Vis, at cloud er en strategisk prioritet – ikke blot et teknologisk projekt.

• Inkludér ændringen i MUS-samtaler, performance-mål og afdelingens egne handlingsplaner.

Konklusion:

Brugeradoption i cloudprojekter handler ikke kun om teknologi – det handler om mennesker, vaner og motivation. Ved at kombinere tidlig inddragelse, målrettet kommunikation, relevant oplæring og aktiv opfølgning kan offentlige organisationer sikre, at cloud-løsningen ikke blot bliver implementeret – men faktisk anvendes og skaber værdi.

Læs mere her.

En klar og gennemarbejdet exit-strategi er en afgørende del af enhver cloudkontrakt – særligt i det offentlige, hvor dataansvar, dokumentation og driftskontinuitet skal være sikret uanset leverandørforholdets ophør. Formålet er at sikre en kontrolleret, dokumenteret og sikker overgang til en ny løsning eller leverandør – uden tab af data, viden eller forretningskritiske funktioner.

1. Krav til dataudlevering og format

• Kontrakten bør fastlægge, at alle data – inkl. konfigurationer, brugerkonti, metadata og transaktionslogs – skal udleveres ved kontraktens ophør.

• Udlevering skal ske i læsbart og struktureret format (fx CSV, XML, JSON, SQL-dump) – og være dokumenteret med datastruktur og fortolkning.

• Der bør også stilles krav til eksport af dokumentation, scripts og konfigurationsfiler for evt. infrastruktur og integrationer.

2. Ret til teknisk bistand og videnoverdragelse

• Leverandøren skal bistå med overdragelse til ny leverandør eller intern drift i en defineret overgangsperiode – fx 3 til 6 måneder.

• Bistanden kan omfatte teknisk support, adgang til miljøer, deltagelse i møder, og overførsel af viden til ny part.

• Det skal fremgå, hvordan viden og dokumentation udveksles, herunder testdata og migreringsplaner.

3. Definition af overgangsperiode og roller

• Exit-strategien skal inkludere:

  • Starttidspunkt og varighed af overgangsfasen,

  • Roller og ansvar (både hos leverandør og ordregiver),

  • Milepæle og godkendelsespunkter for, hvornår exit betragtes som afsluttet.

4. Sletning og destruktion af data

• Kræv, at leverandøren dokumenterer fuld sletning af data efter overgangens afslutning, i henhold til GDPR og god it-skik.

• Indsæt krav om leverance af sletterapporter, logs og evt. tredjepartsbekræftelse (revisor eller DPO-audit).

5. Kontraktuel sikkerhed for ydelser under ophør

• Exit-leverancer skal være kontraktligt bindende og ikke afhænge af god vilje.

• Det skal også være muligt at kræve forlængelse af leverancer mod betaling, hvis overdragelsen trækker ud pga. fx ny leverandørs forsinkelse.

6. Licenser og rettigheder

• Sørg for, at ordregiver ved exit bevarer brugsrettigheder til data, dokumentation og eventuelle konfigurationer udviklet under kontrakten.

• Undgå afhængighed af proprietære formater eller kode, som ikke kan anvendes uden leverandørens medvirken.

7. Afregning og økonomi

• Beskriv, hvordan exit-arbejdet afregnes:

  • Er det inkluderet i abonnementsprisen?

  • Eller afregnes særskilt efter timepris eller fast aftale?

• Definér hvad der betragtes som “almindelig bistand” og hvad der udløser særbetaling.

Konklusion:

En veldefineret exit-strategi i en cloudkontrakt sikrer, at ordregiveren bevarer kontrol over data, reducerer afhængighed af leverandøren og kan gennemføre en sikker og dokumenteret overgang til en ny løsning. Exit bør ikke betragtes som en eventualitet, men som en uundgåelig fase i kontraktens livscyklus – og planlægges fra dag ét.

Reversibilitet handler om ordregiverens evne til at forlade en leverandør uden at miste adgang til egne data, funktioner og systemforståelse – teknisk, organisatorisk og juridisk. Det er et centralt princip i offentlige cloudanskaffelser, hvor afhængighed af én leverandør kan føre til fastlåsning, høje udgifter eller brud på databeskyttelsespligt ved kontraktophør.

For at sikre reversibilitet skal man kombinere tekniske krav med kontraktuel regulering, så der både foreligger værktøjer, data og rettigheder til at fortsætte driften med en ny leverandør eller internt setup.

1. Krav til datatilgængelighed i åbne og standardiserede formater

• Sørg for, at alle data, herunder metadata, logfiler, brugerdata og systemtilstand, kan eksporteres i åbne, dokumenterede formater (fx CSV, JSON, XML, SQL, ODF).

• Undgå proprietære formater eller funktioner, der kun kan anvendes med den aktuelle leverandørs værktøjer.

• Stil krav om, at datamodellen og eksportvejledninger skal dokumenteres og ajourføres løbende.

2. Ejerskab og adgang til konfiguration og opsætning

• Kontrakten bør fastslå, at ordregiver ejer alle konfigurationsdata, scripts og automatiseringer, der er udviklet under kontrakten.

• Det gælder fx adgangsroller, workflows, sikkerhedsopsætninger og integrationslogik.

• Sørg for, at disse data leveres ved ophør – i forståeligt format og med vejledning.

3. Dokumentation og vidensoverdragelse

• Kræv løbende teknisk og organisatorisk dokumentation (systemoversigter, konfigurationsbeskrivelser, datalandskaber).

• Ved ophør skal der gennemføres en struktureret vidensoverdragelse – med udgangspunkt i dokumentation, interviews og fælles tekniske workshops.

4. Kontraktuel forankring af reversibilitet

• Reversibilitet skal reguleres eksplicit i kontrakten – ikke kun som hensigt, men som forpligtende exit-leverance.

• Det skal inkludere:

  • Tidsplan og metode for overdragelse

  • Leverandørens bistand og afregningsform

  • Ret til forlænget adgang i overgangsperiode

  • Sletning og dokumentation heraf

5. Roller og ansvar ved ophør

• Exit-processen bør beskrive, hvem der har ansvar for:

  • Dataudtræk og validering

  • Teknisk afkobling og sikkerhedslukning

  • Godkendelse af overdragelse og afslutning

• Etabler evt. en fælles exit-styregruppe for kontrol og koordinering.

6. Juridisk sikring af datasuverænitet og ophavsret

• Kontrakten bør fastslå, at:

  • Ordregiver ejer egne data uden geografisk eller teknologisk binding.

  • Leverandøren ikke må tilbageholde data som pant.

  • Alle data kan gøres tilgængelige for tredjepartsleverandører i forbindelse med migrering eller revision.

Konklusion:

Teknisk og juridisk reversibilitet kræver, at ordregiver tænker fremad og forankrer både retten og evnen til at forlade leverandøren – uden at miste data, overblik eller funktionalitet. Det bør ske gennem krav om dokumentation, åbne dataformater, ejerskab over konfigurationer og klar rollefordeling. Når reversibilitet er tænkt ind fra starten, står myndigheden stærkt – både kontraktuelt og operationelt – hvis samarbejdet skal afsluttes.

Effektiv vidensoverdragelse er afgørende ved leverandørskifte i IT-projekter – både for at sikre kontinuitet i drift og for at undgå videnstab, som kan føre til forsinkelser, fejl og øgede omkostninger. Overdragelse af viden bør derfor planlægges og kontraktligt fastlægges allerede ved udbuddets udformning og indgåelse af kontrakt.

En god praksis er at stille eksplicitte krav til:

• Løbende dokumentation under kontraktens løbetid, fx systemarkitektur, konfiguration, datamodeller og processer.

• En formaliseret overgangsperiode med parallel involvering af ny og tidligere leverandør.

• Gennemførelse af faciliterede overdragelsesworkshops med både tekniske og forretningsmæssige nøglepersoner.

• Udarbejdelse og aflevering af overdragelsesbilag, der dokumenterer alle væsentlige forhold for systemets videre drift og udvikling.

Disse krav bør suppleres med en detaljeret overgangsplan, der beskriver ansvar, milepæle, acceptkriterier og opfølgning. Det er desuden vigtigt, at ordregiver allokerer interne ressourcer, der aktivt deltager i både modtagelse og verificering af den viden, der overføres.

Digitaliseringsstyrelsen fremhæver i deres metodekatalog om risikostyring og transitionsledelse, at en velstruktureret exit- og vidensoverdragelsesproces er blandt de væsentligste faktorer for succes ved leverandørskifte i offentlige IT-projekter (Digitaliseringsstyrelsen, 2022). Ligeledes fremgår det af Konkurrence- og Forbrugerstyrelsens vejledning “Dialog før og under udbudsprocessen” (2021), at tidlig dialog og forventningsafstemning med leverandørerne om transitionsaktiviteter kan være med til at sikre en mere effektiv overdragelse (kfst.dk).

Ved at integrere disse tilgange skabes et bedre grundlag for en gnidningsfri overgang, der ikke alene bevarer teknisk viden, men også understøtter forretningsmæssig sammenhæng og stabilitet.

En vellykket leverandørtransition ved kontraktudløb kræver planlægning, klar rollefordeling og dokumenteret videnoverdragelse for at undgå driftsforstyrrelser og informationsbrist. Best practice starter allerede i udbudsfasen, hvor der bør stilles eksplicitte krav til transition og exit i både kravspecifikation og kontraktbilag.

Et effektivt transitionsforløb bør inkludere:

• En detaljeret exit-plan, som fastlægger indhold, tidslinjer og ansvarsplacering for de leverancer og aktiviteter, der skal gennemføres i forbindelse med kontraktens ophør.

• Parallel drift, hvor ny og gammel leverandør samarbejder i en afgrænset periode, fx om test, adgangsoprettelse, datamigrering og overdragelse af opgaver.

• Struktureret vidensoverdragelse, fx via workshopforløb og dokumentation af arkitektur, governance, fejlhistorik og forretningsregler.

• Løbende dokumentation i hele kontraktens levetid, så exit ikke bliver en engangsindsats, men bygger på løbende videnopsamling og revisionsspor.

Udbudslovens § 160 stiller krav om, at tildelingskriterier og kontraktvilkår skal være klart formuleret og kunne danne grundlag for efterprøvning. Derfor er det vigtigt, at exit-planen og kravene til overdragelse ikke kun fremgår af leverandørens tilbud, men også kontraktens bilag – og at der fastsættes målbare acceptkriterier for overgangens gennemførelse.

Digitaliseringsstyrelsen anbefaler i sine retningslinjer for transitionsledelse, at man arbejder med konkrete målepunkter, milepæle og governance-strukturer for leverandørskift, og at organisationen allokerer interne nøglepersoner til både styring og modtagelse af transitionen. Dette sikrer, at både teknisk, organisatorisk og operationel viden videreføres på et validt og kontrolleret grundlag.

En eksisterende leverandør, der tidligere har leveret utilfredsstillende, må ikke automatisk udelukkes fra et nyt udbud. I stedet bør organisationen fokusere på at designe et gennemsigtigt og objektivt udbud, hvor tidligere erfaringer håndteres inden for rammerne af udbudsloven – og uden at gå på kompromis med principperne om ligebehandling og fair konkurrence.

For at håndtere en utilfredsstillende incumbent professionelt og lovligt, bør følgende tilgange anvendes:

• Fastlæg klare og målbare krav i kravspecifikationen og evalueringsmodellen, så det fremgår entydigt, hvordan tilbuddene vil blive vurderet – uanset leverandør.

• Inkludér dokumenterbare erfaringer fra tidligere samarbejde i udvælgelses- eller tildelingskriterierne – fx som mindstekrav til erfaring, dokumenteret efterlevelse af SLA’er eller positivt samarbejde. Dette skal ske proportionalt og objektivt.

• Undgå subjektive vurderinger og uformelle barrierer, som ikke er dokumenteret i udbudsmaterialet. Det er afgørende for at undgå risiko for klage og udbuddets annullation.

• Afhold teknisk dialog med markedet inden udbuddet for at præcisere forventninger og sikre, at kravene ikke bliver skævvredet af tidligere dårlige erfaringer.

Udbudslovens § 2 og § 3 pålægger ordregivere at sikre gennemsigtighed og ligebehandling af alle aktører. Hvis en leverandør ønskes udelukket, skal det ske efter § 137, stk. 1, nr. 5, hvor det kræves, at leverandøren har begået alvorlige forsømmelser i forbindelse med udøvelsen af erhvervet – og at ordregiver kan dokumentere dette. I praksis betyder det, at tidligere utilfredsstillende ydelser skal være veldokumenterede, væsentlige og relevante for den aktuelle opgave.

Denne tilgang anbefales også i Konkurrence- og Forbrugerstyrelsens vejledning om anvendelse af tidligere erfaringer og egnethedsvurdering i offentlige udbud. Ved at sikre objektive vilkår og klare evalueringskriterier skabes der en robust og klagefast udbudsproces – også når tidligere erfaringer skal indgå i vurderingen.

En hyppig fejl i evalueringen af leverandørers erfaring og referencer er manglende præcision i sammenhængen mellem de krævede referencer og de specifikke krav i udbuddet. Dette kan føre til, at evalueringen bliver irrelevant og upræcis, hvilket underminerer formålet med at sikre, at den valgte leverandør har den nødvendige erfaring til at løse den konkrete opgave.

For at undgå denne fejl bør udbudsmaterialet klart definere:

• Hvilke typer af referencer der er relevante: Det bør specificeres, hvilke tidligere projekter eller opgaver der anses for relevante i forhold til det udbudte arbejde.

• Hvorfor disse referencer er relevante: Det skal forklares, hvordan de krævede referencer demonstrerer leverandørens evne til at opfylde de specifikke krav i udbuddet.

• Hvordan referencerne vil blive evalueret: Der bør opstilles klare kriterier for, hvordan referencerne vil blive vurderet, herunder hvilke aspekter der vil blive tillagt vægt.

Ved at sikre en klar sammenhæng mellem de krævede referencer og udbuddets specifikke krav, kan ordregiver opnå en mere præcis og relevant evaluering af leverandørernes erfaring. Dette bidrager til at identificere den leverandør, der bedst matcher opgavens behov og kompleksitet.

For yderligere vejledning om udformning af krav til referencer og evaluering af leverandørers erfaring kan det være nyttigt at konsultere Konkurrence- og Forbrugerstyrelsens vejledninger og anbefalinger, som giver praktiske råd om udformning af udbudsmateriale og evaluering af tilbud.

En objektiv og gennemsigtig evaluering af tilbud i offentlige IT-udbud kræver en struktureret tilgang, hvor alle tilbudsgivere vurderes ensartet og på baggrund af klart definerede kriterier. Dette er afgørende for at opretholde tilliden til udbudsprocessen og sikre, at den mest egnede leverandør vælges.

For at opnå dette bør følgende elementer indgå i evalueringen:

1. Klart definerede evalueringskriterier og underkriterier: Udbudsmaterialet skal indeholde præcise beskrivelser af, hvilke kriterier der lægges vægt på, og hvordan disse vil blive vurderet. Dette omfatter også en vægtning af de enkelte kriterier, så tilbudsgiverne forstår, hvad der er vigtigt i vurderingen.

2. Detaljerede vurderingsvejledninger: Udarbejdelse af interne vejledninger for evalueringsteamet sikrer, at alle vurderinger foretages på et ensartet grundlag. Disse vejledninger bør indeholde eksempler på, hvad der udløser bestemte point eller vurderinger.

3. Brug af uafhængige eksperter og evalueringspaneler: Involvering af fagpersoner med relevant ekspertise kan bidrage til en mere kvalificeret og objektiv vurdering af tilbuddene. Det er vigtigt, at disse eksperter er uafhængige og ikke har interessekonflikter i forhold til de tilbudsgivere, der evalueres.

4. Konsekvent anvendelse af standarder og metoder: Alle medlemmer af evalueringsteamet skal anvende de samme metoder og standarder i vurderingen af tilbuddene. Dette kan understøttes af fælles træning og kalibreringsøvelser før evalueringen påbegyndes.

Disse tiltag er i overensstemmelse med udbudslovens principper om gennemsigtighed og ligebehandling, som er fundamentale for en retfærdig udbudsproces. Ved at sikre en objektiv evaluering minimeres risikoen for klager og sikres, at den valgte leverandør bedst opfylder de opstillede krav og behov.

For at sikre en ensartet og objektiv vurdering af tilbud i evalueringsfasen af offentlige IT-udbud er det afgørende at etablere en struktureret og gennemsigtig evalueringsproces. Dette indebærer, at alle tilbud vurderes på baggrund af klart definerede kriterier og metoder, hvilket understøtter principperne om ligebehandling og gennemsigtighed i udbudsloven (§§ 2 og 160).

Centrale elementer i en ensartet evalueringsproces:

1. Klart definerede evalueringskriterier og underkriterier:

   • Udbudsmaterialet bør indeholde præcise beskrivelser af, hvilke kriterier der lægges vægt på, samt hvordan disse vil blive vurderet.

   • Hver underkriterium bør have en tydelig vægtning og en beskrivelse af, hvad der forventes for at opnå en høj vurdering.

2. Standardiserede vurderingsskabeloner:

   • Anvendelse af skabeloner sikrer, at alle evalueringer dokumenteres ensartet og systematisk.

   • Dette letter sammenligningen af tilbud og reducerer risikoen for subjektive vurderinger.

3. Ensartet briefing af evalueringsteamet:

   • Før evalueringen påbegyndes, bør alle medlemmer af evalueringsteamet modtage en grundig briefing om evalueringskriterierne og -metoderne.

   • Dette sikrer, at alle har en fælles forståelse og tilgang til vurderingen af tilbuddene.

4. Periodiske kalibreringsmøder:

   • Under evalueringen bør der afholdes kalibreringsmøder, hvor evalueringsteamet diskuterer og justerer deres vurderinger for at sikre konsistens.

   • Disse møder hjælper med at identificere og korrigere eventuelle afvigelser i vurderingerne.

5. Anvendelse af evalueringssoftware:

   • Brug af specialiseret software kan understøtte en struktureret og ensartet evaluering ved at automatisere dele af processen og sikre, at alle vurderinger registreres korrekt.

Ved at implementere disse tiltag kan ordregivere sikre, at evalueringen af tilbud foregår på en objektiv og ensartet måde, hvilket er afgørende for at opretholde tilliden til udbudsprocessen og for at sikre, at den mest egnede leverandør vælges.

Funktionskrav er særligt fordelagtige i offentlige IT-udbud, når målet er at fremme innovation, fleksibilitet og udnytte leverandørernes tekniske ekspertise. I stedet for at specificere præcise teknologiske løsninger, fokuserer funktionskrav på de ønskede resultater og den effekt, som ydelsen skal opnå. Det giver leverandørerne frihed til at foreslå den mest hensigtsmæssige tilgang og teknologi – hvilket ofte fører til mere effektive, konkurrencedygtige og moderne løsninger.

Fordele ved funktionskrav:

• Fremmer innovation: Ved at undgå detaljerede tekniske specifikationer åbnes der op for nye løsningsmuligheder, som ordregiver måske ikke selv havde overvejet.

• Øget fleksibilitet: Funktionskrav tillader forskellige teknologiske tilgange og leverandørernes egne metoder, hvilket er vigtigt i et hurtigt skiftende IT-landskab.

• Styrket konkurrence: Flere leverandører kan byde ind, da de ikke begrænses af specifikke teknologiske præferencer, hvilket ofte fører til bedre pris og kvalitet.

Juridisk ramme:

Ifølge udbudslovens § 41, stk. 1, kan tekniske specifikationer udformes som krav til funktion eller ydelse, forudsat at kravene er tilstrækkeligt præcise til, at tilbudsgiverne kan forstå kontraktens genstand. Denne bestemmelse giver ordregivere mulighed for at fokusere på formål og ønskede effekter frem for på løsningen i sig selv – hvilket især er relevant i projekter, hvor løsningerne ikke kan fastlægges entydigt på forhånd.

Anvendelse i praksis:

Funktionskrav er særligt relevante i komplekse IT-projekter såsom platformsmigreringer, cloud-løsninger og digitaliseringsinitiativer, hvor teknologiske løsninger kan variere betydeligt. For at sikre, at funktionskrav kan evalueres fair og effektivt, er det vigtigt, at ordregiver samtidig fastlægger:

• Klare succeskriterier,

• Evalueringsmodeller med gennemskuelige tildelingskriterier,

• Og krav til dokumentation, som giver mulighed for efterprøvning af opfyldelse.

Ved at anvende funktionskrav skabes der bedre rum for løsningsforslag, der matcher markedets bedste praksis, og som i højere grad understøtter værdiskabelse og teknologisk fremdrift i den offentlige sektor.

Ved anskaffelse af standardiserede cloud- eller SaaS-løsninger kan det være hensigtsmæssigt for offentlige ordregivere at acceptere leverandørens standardvilkår, især når disse løsninger er designet til at opfylde generelle markedsbehov, og tilpasninger vil medføre betydelige omkostninger eller kompleksitet.

Anbefalet tilgang:

1. Fokus på centrale juridiske risici: I stedet for at forsøge at tilpasse alle vilkår, bør ordregiver fokusere på nøgleområder som databeskyttelse, overholdelse af lovgivning og klare exit-betingelser. Dette sikrer, at de mest kritiske aspekter af kontrakten er adresseret, uden at pålægge unødvendige ændringer.

2. Proportionalitetsprincippet: Udbudslovens § 2 understreger, at krav og betingelser i udbud skal være proportionale i forhold til kontraktens genstand. Ved at acceptere standardvilkår, hvor det er passende, overholder ordregiver dette princip og undgår unødvendige forhindringer for konkurrencen.

3. Pragmatisk tilgang: En pragmatisk tilgang indebærer at vurdere, om de potentielle fordele ved at ændre standardvilkårene opvejer de ekstra omkostninger og den kompleksitet, som tilpasningerne medfører. Hvis ikke, kan det være mere fordelagtigt at acceptere vilkårene som de er.

Ved at følge denne tilgang kan offentlige ordregivere sikre en effektiv og lovmedholdelig anskaffelsesproces, der balancerer behovet for juridisk sikkerhed med praktiske overvejelser om omkostninger og kompleksitet.

En typisk faldgrube i kontraktbilag om serviceniveauer (SLA) i offentlige IT- og cloudkontrakter er, at kravene ofte er uklare, overkomplekse eller uprioriterede. Dette kan føre til fortolkningskonflikter, uforudsigelige leveranceforventninger og manglende mulighed for effektiv opfølgning. I værste fald svækkes hele kontraktens styring og retskraft.

Særlige udfordringer opstår, når:

• Målepunkterne ikke præcist definerer, hvad der måles og hvordan (fx om “oppetid” gælder netværk, platform eller slutbrugeroplevelse).

• Der mangler sammenhæng mellem det, der måles, og den faktiske oplevede kvalitet. Der kan fx måles på svartid i millisekunder, selvom brugerne oplever lav performance pga. dårlig design eller integration.

• Der opstilles 40–50 serviceniveauer, hvoraf mange har lav forretningsværdi, men høj administrativ byrde og kompleksitet for både ordregiver og leverandør.

Retlige og kontraktuelle risici:

Udbudslovens § 160 forpligter ordregivere til at fastsætte klare og målbare kontraktvilkår. Hvis SLA’er er formuleret uklart eller uden entydige konsekvenser ved brud, bliver det vanskeligt at gennemføre effektiv kontraktstyring og sanktionere manglende leverance. Endvidere risikerer man, at tilbudsgivere ikke kan afgive sammenlignelige og valide tilbud, hvilket svækker gennemsigtighed og ligebehandling.

Uklarhed i serviceniveauer kan i praksis føre til:

• Manglende mulighed for bod eller erstatning ved brud.

• Tvivl om roller og ansvar i drifts- og supporthændelser.

• Svækket tillid mellem leverandør og ordregiver, hvis forventninger ikke er klart afstemt.

Best practice:

1. Udvælg få og relevante målepunkter:

   • Oppetid (fx 99,9 % pr. måned).

   • Maksimal fejlretningstid for kritiske fejl (fx ≤ 4 timer).

   • Responstid for brugerhandlinger (fx ≤ 1 sekund i 90 % af tilfælde).

2. Brug entydige tekniske enheder:

   • Tidsenheder (minutter, timer), procenttal og dokumenterbare datapunkter.

3. Integrér krav til dokumentation og opfølgning:

   • Månedlig rapportering fra leverandøren.

   • Klar procedure for godkendelse og afvigelseshåndtering.

4. Tilknyt sanktioner og incitamenter:

   • Bodsmodeller for manglende opfyldelse.

   • Eskalationsmekanismer ved gentagne fejl.

   • Bonusordninger ved konsekvent overopfyldelse (valgfrit).

Konklusion:

SLA’er skal være et effektivt kontraktstyringsværktøj – ikke et administrativt eller juridisk minefelt. Ved at sikre enkelhed, målbarhed og relevans i serviceniveauerne kan ordregivere både styrke deres forhandlingsposition og fremme et professionelt og tillidsfuldt samarbejde med leverandøren. En god SLA er ikke en lang liste – men en præcis aftale om det vigtigste.

For offentlige ordregivere, der ønsker at kombinere fleksibilitet med økonomisk forudsigelighed i IT-udbud, er en rammeaftale med mulighed for miniudbud ofte en velegnet kontraktform. Denne struktur gør det muligt at tilpasse ydelserne løbende efter behov, samtidig med at der opretholdes kontrol over omkostningerne.

Anbefalede elementer i kontraktformen:

1. Rammeaftale med miniudbud: Ved at etablere en rammeaftale med flere leverandører og mulighed for miniudbud kan ordregiver konkurrere specifikke opgaver eller projekter inden for rammeaftalen. Dette sikrer både fleksibilitet og konkurrence, hvilket kan føre til bedre priser og ydelser.

2. Time-and-materials med budgetloft: For opgaver, hvor det er vanskeligt at fastlægge det præcise omfang på forhånd, kan en time-and-materials-kontrakt med et fastsat budgetloft være hensigtsmæssig. Dette giver leverandøren fleksibilitet til at tilpasse ressourcerne efter behov, samtidig med at ordregiver har kontrol over de samlede omkostninger.

3. Veldefinerede exit-muligheder: Kontrakten bør indeholde klare bestemmelser om opsigelse og overdragelse, herunder procedurer for vidensoverdragelse og datahåndtering. Dette sikrer en smidig overgang ved kontraktophør og reducerer risikoen for leverandørafhængighed.

Det er vigtigt, at rammeaftaler er præcist definerede med hensyn til ydelsesændringer og omfang. Uklarheder kan føre til tvister og usikkerhed om rettigheder og forpligtelser. Derfor bør ordregivere sikre, at alle væsentlige elementer i aftalen er klart beskrevet, herunder procedurer for ændringer og tildelinger inden for rammeaftalen.

Ved at kombinere disse elementer i kontraktformen kan offentlige ordregivere opnå en balance mellem fleksibilitet og økonomisk forudsigelighed, hvilket er afgørende for succesfulde IT-projekter.

Risikoen for tvister i offentlige IT- og cloudkontrakter reduceres bedst gennem klare og entydige aftaler om governance-strukturer, præcise ydelsesbeskrivelser og etablerede procedurer for eskalation og håndtering af uenigheder. En gennemarbejdet kontrakt med fokus på samarbejde, dokumentation og regelmæssig opfølgning er afgørende for at forebygge misforståelser og konflikter.

Følgende elementer er særligt vigtige:

1. Governance-struktur:
   Etabler en fælles governance-model med klart definerede roller, mødestrukturer og beslutningskompetencer. Det bør fremgå:

   • Hvem træffer beslutninger om ændringer?

   • Hvordan rapporteres status og afvigelser?

   • Hvornår og hvordan gennemføres styrings- og statusmøder?

2. Præcise ydelsesbeskrivelser:
   Leverancebeskrivelser bør være entydige og uden fortolkningsrum. Anvend konkrete og målbare specifikationer – både for funktionalitet, performance og support.

3. Eskalationsprocedurer:
   Aftal en trappemodel for konfliktløsning, hvor teknisk personale først forsøger løsning, herefter ledelsesinvolvering og eventuelt ekstern mægling, inden juridiske skridt overvejes. Dette dæmper konfliktniveauet og giver plads til samarbejde.

4. Dokumentation og sporbarhed:
   Dokumentér alle ændringer, beslutninger og leverancer løbende. Brug versionering, beslutningsreferater og digitale styringsværktøjer. Det øger kontraktens gennemsigtighed og forenkler eftervisning ved tvivl eller konflikt.

5. Incitaments- og sanktionsmodeller:
   En balanceret kombination af bod og bonus skaber incitament for overholdelse uden at skabe et ensidigt fokus på fejl. Forudsigelighed i konsekvenser mindsker uenigheder om forventninger.

6. Proaktiv opfølgning:
   Løbende opfølgning på både tekniske, kommercielle og samarbejdsmæssige forhold gør det muligt at fange uenigheder og risikoemner tidligt – før de udvikler sig til formelle tvister.

Juridisk ramme:

Udbudslovens § 160 stiller krav til, at kontraktvilkår og tildelingskriterier skal være klare og gennemskuelige. Dette gælder også i leverancefasen, hvor uklarheder i krav, snitflader eller sanktioner kan føre til uoverensstemmelser. En kontrakt, der tydeligt definerer ydelse, ansvar og opfølgning, reducerer både tvister og risiko for klager.

Konklusion:

Tvister forebygges ikke alene ved jura, men ved struktur, samarbejde og konsekvent governance. En moden kontrakt kræver mere end tekst – den kræver praksis. Når begge parter har fælles forståelse for roller, ansvar og processer – og løbende arbejder aktivt med opfølgning – skabes et professionelt rum, hvor uenigheder håndteres før de eskalerer.

En af de mest udbredte fejl ved overgang til cloud-baserede løsninger i offentlige IT-udbud er, at der fokuseres for snævert på den tekniske leverance og for lidt på den organisatoriske transformation, der følger med. Mange organisationer undervurderer, hvor grundlæggende ændringen fra on-premise til cloud er – ikke kun i arkitektur, men også i processer, governance og ansvar.

De typiske fejl består i:

• Manglende organisatorisk forankring: Overgangen til cloud kræver ændringer i roller, beslutningsveje, kompetencer og ejerskab. Hvis dette ikke er afklaret og implementeret tidligt, opstår modstand, utydelig styring og interne flaskehalse.

• Utilstrækkelig governance: Cloud kræver en løbende governance-struktur, hvor sikkerhed, økonomi, forbrug og ændringer overvåges og styres aktivt. Uden dette risikerer man driftsforstyrrelser, kontraktbrud og manglende overblik.

• Undervurdering af compliance-krav: Hvis der ikke er tilstrækkelig opmærksomhed på datalokation, rollefordeling i forhold til GDPR og krav til audit, dokumentation og databehandleraftaler, kan det føre til alvorlige overtrædelser af gældende lovgivning.

• Manglende tilpasning af kravspecifikation: Ofte videreføres tekniske krav fra on-premise løsninger uden at tage højde for cloudmodellens karakteristika. Det resulterer i upræcise, uegnede eller uforståelige krav, som hverken giver leverandøren reelt råderum eller beskytter ordregiveren.

Juridisk ramme:

Udbudslovens § 40 forpligter ordregivere til at beskrive kontraktens genstand klart og præcist. Dette gælder i særlig grad ved overgang til cloud, hvor drift, support og kontrol ofte fordeles mellem flere parter – og hvor teknologivalget får direkte konsekvenser for governance, sikkerhed og compliance.

Konklusion:

Overgang til cloud kræver, at der tænkes i transformation – ikke blot i drift. En succesfuld udbudsproces bør derfor bygge på:

• Tydelig organisatorisk og teknisk kravspecifikation,

• Governance og compliance som bærende elementer i udbuddet,

• Og en forståelse for, at cloud er en ændring i driftsmodel, ikke blot i teknologi.

Ved at adressere disse forhold tidligt i udbudsmaterialet og forankre dem i både kontrakt og intern styring reduceres risikoen for fejl, forsinkelser og uforudsete omkostninger betydeligt.

Ved overgang fra on-premise til cloud skal persondata behandles med mindst samme sikkerhed og kontrol som tidligere – og ofte mere, da data ofte vil blive placeret uden for organisationens egen infrastruktur og i nogle tilfælde uden for EU/EØS. En systematisk og risikobaseret tilgang til databeskyttelse er afgørende for at sikre compliance med GDPR i hele kontrakt- og driftsperioden.

Centrale elementer i en GDPR-kompatibel cloudovergang:

1. Dataklassificering og risikovurdering:

   • Start med at identificere, hvilke typer data (fx almindelige, følsomme, CPR-numre) der behandles, og hvor højt beskyttelsesniveau der kræves.

   • Brug standarder eller interne retningslinjer (fx fra Digitaliseringsstyrelsen eller CFCS) til at kategorisere data og fastlægge sikkerhedsniveauer.

2. Databehandleraftaler (DBA):

   • Indgå en skriftlig aftale iht. GDPR art. 28, som præciserer:

     • formål, varighed og karakter af behandlingen,

     • behandlingskategorier,

     • leverandørens forpligtelser til sikkerhed, underdatabehandlere, og sletning.

   • Brug evt. Datatilsynets DBA-skabelon som grundlag.

3. Aftaler om datalokation og overførsler:

   • Kræv, at alle persondata opbevares og behandles i EU/EØS, medmindre overførslen kan ske på lovligt grundlag (fx EU-Kommissionens standardkontraktbestemmelser (SCC)).

   • Efter Schrems II-dommen (C-311/18) må overførsler til usikre tredjelande (fx USA) kun ske, hvis der implementeres supplerende tekniske foranstaltninger, såsom:

     • end-to-end-kryptering, hvor leverandøren ikke har adgang til nøglerne,

     • segmentering og pseudonymisering,

     • dokumenteret vurdering af modtagerlandets retsbeskyttelse.

4. Løbende compliance og audit:

   • Kræv, at leverandøren stiller dokumentation til rådighed for sikkerhedsforanstaltninger, fx ISAE 3000/3402, ISO 27001.

   • Inkludér ret til løbende audit, herunder teknisk revision, kontrolbesøg og adgang til underdatabehandlerlister.

   • Opsæt governance-struktur med faste drøftelser om compliance, opdateringer i regulering og databrudshåndtering.

5. Incident response og databrud:

   • Beskriv i kontrakten, hvordan sikkerhedshændelser og databrud skal håndteres:

     • Varslingsfrister (fx maks. 4 timer fra konstatering),

     • Kommunikationspligt over for Datatilsynet og registrerede,

     • Roller og ansvar for hændelsesstyring.

Juridisk grundlag og vejledninger:

• Udbudslovens § 160 kræver klar og præcis angivelse af juridiske og tekniske forhold i kontrakten – dette inkluderer databehandlingsaftaler og krav om GDPR-overholdelse.

• EU-domstolens dom i Schrems II (C-311/18) fastslår, at overførsler til tredjelande uden tilstrækkeligt beskyttelsesniveau kræver konkrete supplerende foranstaltninger (ECLI:EU:C:2020:559).

• Datatilsynet og EDPB anbefaler brug af risikovurderinger, datalokationspolitikker og konsekvensanalyser (DPIA), især ved skift til cloud.

Konklusion:

GDPR ved cloudovergang håndteres bedst gennem grundig forberedelse, klare kontraktuelle krav og løbende kontrol. Det handler ikke kun om én databehandleraftale, men om en samlet struktur for datasuverænitet, teknisk sikkerhed og dokumenterbar compliance. Ved at integrere kravene i både udbud, kontrakt og governance skabes et solidt grundlag for både beskyttelse af borgernes data og ansvarlig offentlig it-drift.

Karteldannelse i offentlige udbud underminerer fair konkurrence og kan føre til højere priser og ringere kvalitet. For at beskytte mod dette er det afgørende, at ordregivere proaktivt overvåger og analyserer udbudsprocesser for at identificere mistænkelige mønstre.

1. Overvågning og analyse af tilbud:

• Sammenlign tilbud for at identificere ensartede priser eller formuleringer, der kan indikere koordinering mellem tilbudsgivere.

• Vær opmærksom på gentagne mønstre, hvor forskellige leverandører skiftevis vinder udbud, hvilket kan tyde på markedsdeling.

2. Markedsundersøgelser og dialog:

• Gennemfør markedsanalyser for at forstå det normale prisniveau og identificere unormale afvigelser.

• Engager i dialog med leverandører for at få indsigt i markedets struktur og potentielle konkurrenceproblemer.

3. Rapportering og samarbejde med myndigheder:

• Hvis der er mistanke om karteldannelse, bør dette straks rapporteres til Konkurrence- og Forbrugerstyrelsen, som har ekspertise i at undersøge og håndtere sådanne sager.

4. Juridiske rammer:

• Udbudslovens § 2 fastsætter principper om ligebehandling og gennemsigtighed, hvilket forpligter ordregivere til at sikre en fair og åben proces.

• Udbudslovens §§ 160–163 giver mulighed for at identificere og undersøge unormalt lave tilbud, hvilket kan være en indikator for usund konkurrence.

Ved at implementere disse tiltag kan ordregivere styrke integriteten af udbudsprocessen og beskytte mod konkurrenceforvridende adfærd.

For at tiltrække et bredt felt af kvalificerede tilbudsgivere i offentlige IT-udbud er det afgørende at tilrettelægge udbudsprocessen, så den er gennemsigtig, realistisk og i overensstemmelse med markedets kapacitet. Dette kan opnås gennem følgende tiltag:

1. Tidlig og struktureret markedsdialog: Inden udbuddet offentliggøres, bør ordregiver engagere sig i dialog med potentielle leverandører for at forstå markedets muligheder og begrænsninger. Dette hjælper med at udforme udbudsmaterialet, så det afspejler realistiske krav og fremmer konkurrence. Udbudslovens § 39 tillader sådanne markedsundersøgelser, forudsat at principperne om ligebehandling og gennemsigtighed overholdes.

2. Realistiske og proportionale krav: Udbudsmaterialet bør indeholde krav, der står i rimeligt forhold til opgavens karakter og markedets kapacitet. Overdrevne eller unødvendigt komplekse krav kan afskrække potentielle tilbudsgivere og begrænse konkurrencen.

3. Klar og gennemsigtig kommunikation: Alle oplysninger om udbuddet, herunder evalueringskriterier og kontraktvilkår, bør formidles klart og tilgængeligt. Dette sikrer, at alle potentielle tilbudsgivere har samme forståelse af udbuddets betingelser og kan afgive konkurrencedygtige tilbud.

4. Tilstrækkelige svartider og fleksibilitet: Ordregiver bør fastsætte rimelige tidsfrister for spørgsmål og tilbudsafgivelse, så leverandørerne har tilstrækkelig tid til at forberede kvalificerede tilbud. Hvis der foretages ændringer i udbudsmaterialet, bør tidsfristerne justeres tilsvarende for at opretholde fair konkurrence.

Ved at implementere disse tiltag kan ordregivere fremme en sund konkurrence og tiltrække et bredt spektrum af kvalificerede tilbudsgivere, hvilket øger chancerne for at opnå den bedst mulige løsning til den offentlige opgave.

NIS2-direktivet (artikel 23) fastlægger klare krav til underretning og samarbejde med nationale CSIRTs (Computer Security Incident Response Teams) vedrørende sikkerhedshændelser. Disse krav gælder for både væsentlige og vigtige enheder og omfatter følgende:

• Tidlig varsling: Inden for 24 timer efter at være blevet opmærksom på en væsentlig hændelse skal en tidlig varsling sendes til CSIRT eller den relevante kompetente myndighed. Denne varsling skal, hvor det er relevant, indikere, om hændelsen mistænkes for at være forårsaget af ulovlige eller ondsindede handlinger eller kan have en grænseoverskridende indvirkning.

• Hændelsesmeddelelse: Inden for 72 timer efter at være blevet opmærksom på hændelsen skal en hændelsesmeddelelse sendes, der opdaterer oplysningerne fra den tidlige varsling og indeholder en indledende vurdering af hændelsen, herunder dens alvor og indvirkning samt, hvor tilgængeligt, indikatorer på kompromittering.

• Slutrapport: Senest en måned efter indsendelsen af hændelsesmeddelelsen skal en slutrapport indsendes, der giver en detaljeret beskrivelse af hændelsen, herunder dens alvor og indvirkning, typen af trussel eller rodårsag, anvendte og igangværende afbødende foranstaltninger og, hvor det er relevant, den grænseoverskridende indvirkning af hændelsen.

Det er vigtigt, at kontrakter med leverandører klart angiver deres forpligtelse til at bistå ordregiveren med denne rapportering, herunder ved leverandørens egne interne hændelser, hvis de kan påvirke leverancen.

Yderligere information og detaljerede krav kan findes i NIS2-direktivets artikel 23:
NIS 2 Directive, Article 23: Reporting obligations

NIS2-direktivets artikel 20 fastslår, at ledelsen i væsentlige og vigtige enheder har det overordnede ansvar for cybersikkerhed. Det indebærer, at ledelsen skal godkende og føre tilsyn med implementeringen af cybersikkerhedsforanstaltninger og kan holdes ansvarlig for overtrædelser af disse forpligtelser.

Derudover kræver direktivet, at medlemmer af ledelsesorganer gennemfører regelmæssig træning i cybersikkerhed for at sikre tilstrækkelig viden og kompetencer til at identificere risici og vurdere cybersikkerhedsforanstaltninger.

For at sikre efterlevelse bør offentlige ordregivere stille krav om ledelsesforankring i udbudsmaterialet. Dette kan inkludere krav om:

• Beskrivelse af CISO’s rolle og ansvar

• Rapporteringsstruktur for cybersikkerhed til ledelsen

• Bestyrelsens involvering i risikostyring

• Gennemførelse af interne compliance-audits

• Dokumentation for ledelsens godkendelse af sikkerhedsforanstaltninger

ENISA understreger, at manglende ledelsesengagement er en væsentlig årsag til mislykkede cybersikkerhedsinitiativer.

Konklusion:
Ledelsesforankring er afgørende for effektiv cybersikkerhed og compliance under NIS2. Offentlige ordregivere bør derfor sikre, at krav til ledelsens ansvar og involvering er tydeligt defineret og evaluerbare i udbud og kontrakter.

NIS2-direktivet forpligter væsentlige og vigtige enheder til at sikre, at deres underleverandører opretholder et tilsvarende niveau af cybersikkerhed. Dette krav er fastlagt i artikel 21, stk. 2, litra d, som pålægger enhederne at implementere foranstaltninger til styring af cybersikkerhedsrisici, herunder sikkerhedsrelaterede aspekter vedrørende forholdet mellem enheden og dens direkte leverandører eller tjenesteydere.

Desuden kræver artikel 21, stk. 3, at enhederne tager hensyn til sårbarheder, der er specifikke for hver direkte leverandør og tjenesteyder, samt den overordnede kvalitet af deres produkter og cybersikkerhedspraksis, herunder deres sikre udviklingsprocedurer.

For at sikre overholdelse af disse krav anbefales det, at offentlige ordregivere:

• Inkluderer flow-down klausuler i kontrakter, der forpligter hovedleverandører til at sikre, at underleverandører overholder de samme sikkerhedskrav.

• Fastlægger audit-ret for ordregiveren til at inspicere og vurdere underleverandørers sikkerhedsforanstaltninger.

• Kræver dokumentation for underleverandørers sikkerhedsniveau, f.eks. gennem certificeringer eller sikkerhedsrapporter.

Manglende overholdelse af disse forpligtelser kan føre til påbud eller bøder fra tilsynsmyndigheder som Center for Cybersikkerhed (CFCS) i Danmark.

Konklusion:

NIS2-direktivet understreger vigtigheden af en holistisk tilgang til cybersikkerhed, hvor både hovedleverandører og underleverandører er forpligtet til at opretholde høje sikkerhedsstandarder. Offentlige ordregivere bør derfor sikre, at deres kontrakter og udbudsmateriale klart definerer kravene til underleverandørers sikkerhedsniveau og indeholder mekanismer til at overvåge og håndhæve disse krav.

NIS2-direktivet stiller krav om, at væsentlige og vigtige enheder implementerer passende tekniske, operationelle og organisatoriske foranstaltninger for at håndtere risici forbundet med sikkerheden i net- og informationssystemer. Disse krav er specificeret i artikel 21, stk. 2, og omfatter blandt andet risikostyring, hændelseshåndtering, beredskabsplaner og ledelsens involvering.

For at dokumentere overholdelse af disse krav kan tilbudsgivere fremlægge følgende:

• Sikkerhedspolitikker og procedurer: Dokumenterede politikker, der beskriver tilgange til risikostyring, hændelseshåndtering og beredskabsplaner.

• Revisionsrapporter: Resultater fra interne eller eksterne audits, der vurderer effektiviteten af implementerede sikkerhedsforanstaltninger.

• Hændelseshåndteringslogs: Registreringer af tidligere sikkerhedshændelser og de trufne foranstaltninger for at afbøde dem.

• Samarbejdsaftaler med CSIRTs: Dokumentation for etablerede samarbejder med nationale CSIRTs, såsom CFCS i Danmark, herunder procedurer for rapportering af hændelser.

Det er vigtigt, at disse dokumentationer er tilpasset den specifikke kontekst og risikoprofil for den pågældende enhed. Center for Cybersikkerhed (CFCS) og Det Europæiske Agentur for Cybersikkerhed (ENISA) har udgivet vejledninger, der kan hjælpe med implementeringen af NIS2-kravene .

Ved udarbejdelse af udbudsmateriale bør ordregivere derfor specificere kravene til dokumentation af NIS2-overholdelse, så tilbudsgivere klart forstår, hvilke oplysninger og beviser der forventes fremlagt.

Patch management er en central del af den løbende sikkerhedsdrift og er eksplicit reguleret i NIS2-direktivets artikel 21, stk. 2, litra f, som kræver, at væsentlige og vigtige enheder implementerer passende tekniske og organisatoriske foranstaltninger til håndtering af cybersikkerhedsrisici, herunder sårbarhedshåndtering og opdatering af it-systemer.

For at sikre effektiv patch management bør udbudsmaterialet indeholde følgende krav:

• Tidsfrister for patching: Definér maksimale deadlines for udbedring af sårbarheder baseret på deres kritikalitet. For eksempel kan kritiske sårbarheder kræve patching inden for 24-48 timer efter identifikation.

• Dokumentation og audit trail: Krav om, at leverandøren fører detaljeret dokumentation over patching-processer, herunder tidsstempler, anvendte metoder og testresultater, for at muliggøre efterfølgende revision og compliance-kontrol.

• Prioritering baseret på CVSS-score: Anvendelse af Common Vulnerability Scoring System (CVSS) til at vurdere og prioritere sårbarheder. For eksempel kan sårbarheder med en CVSS-score på 9.0-10.0 klassificeres som kritiske og kræve hurtig handling.

• Hændelsesopfølgning og rapportering: Etablering af procedurer for opfølgning på sikkerhedshændelser relateret til sårbarheder samt krav om rapportering til ordregiver og relevante myndigheder, såsom Center for Cybersikkerhed (CFCS), i overensstemmelse med NIS2-direktivets artikel 23.

• Kontrolmekanismer og sanktioner: Inkludér bestemmelser om kontrolmekanismer for at overvåge overholdelsen af patch management-kravene samt sanktioner, såsom bodsbestemmelser, ved manglende overholdelse.

Disse krav bør tilpasses den specifikke kontekst og risikoprofil for den pågældende løsning og organisation. Det er vigtigt, at kravene er klare, målbare og juridisk proportionale for at sikre effektiv implementering og overholdelse.

Ja, en ordregiver kan stille krav om realtidsovervågning og central logning i et offentligt it-udbud, forudsat at kravene er sagligt begrundede og proportionale i forhold til kontraktens genstand og formål.

NIS2-direktivet (Direktiv (EU) 2022/2555) fastlægger i artikel 21, stk. 2, litra f, at væsentlige og vigtige enheder skal implementere passende tekniske og organisatoriske foranstaltninger, herunder logning og overvågning, for at håndtere cybersikkerhedsrisici. Dette indebærer, at realtidsovervågning og central logning kan være nødvendige for at sikre hurtig identifikation og håndtering af sikkerhedshændelser.

Databeskyttelsesforordningen (GDPR) tillader behandling af personoplysninger, herunder logning af IP-adresser og brugeraktiviteter, når det er nødvendigt for at opfylde en retlig forpligtelse eller for at forfølge en legitim interesse, forudsat at den registreredes rettigheder og frihedsrettigheder ikke tilsidesættes (artikel 6, stk. 1, litra c og f). Det er vigtigt, at logning sker på en måde, der sikrer dataminimering, formålsbegrænsning og passende sikkerhedsforanstaltninger, såsom adgangskontrol og kryptering.

Eksempel på kravformulering i udbudsmateriale:

• Leverandøren skal etablere en central logningsinfrastruktur, der indsamler og opbevarer logdata fra alle relevante systemer i realtid.

• Systemet skal understøtte realtidsalarmering ved identificering af sikkerhedshændelser og muliggøre hurtig respons.

• Logdata skal opbevares i overensstemmelse med gældende databeskyttelseslovgivning og være tilgængelige for revision og tilsyn.

Det anbefales, at ordregivere klart definerer kravene til realtidsovervågning og central logning i udbudsmaterialet, herunder formål, omfang, tekniske specifikationer og krav til databeskyttelse, for at sikre gennemsigtighed og overholdelse af gældende lovgivning.

Hvis it-sikkerhedskrav i kravspecifikationen er uklare eller åbne for fortolkning, udgør det en alvorlig risiko for udbuddets lovlighed. Det strider mod gennemsigtighedsprincippet i udbudslovens § 2, som forpligter ordregivere til at sikre, at alle tilbudsgivere har samme forståelse af kravene og dermed lige adgang til at afgive et konkurrencedygtigt tilbud.

For krav til fx kryptering, hændelseshåndtering, logning og adgangskontrol gælder det, at de skal være konkretiserede og teknisk dokumenterede. Hvis der fx blot står “datatrafik skal beskyttes”, uden at det angives om dette indebærer TLS 1.3, VPN eller noget andet, skabes der et fortolkningsrum, som kan føre til klager eller usammenlignelige tilbud. Samtidig kan det svække kontraktens håndhævelseskraft.

Selvom der ikke er en kendelse fra Klagenævnet, som kan dokumenteres med direkte link i dette tilfælde, har Digitaliseringsstyrelsen, CFCS og ENISA i flere vejledninger understreget nødvendigheden af præcise kravbeskrivelser og henvisninger til gældende standarder, herunder ISO/IEC 27001 og 27002 samt NIST SP 800-53 og SP 800-160.

Anbefalinger for praksis:

• Brug tekniske referencestandarder (ISO 27002, NIST) som underbilag i kravspecifikationen.

• Beskriv, hvordan krav opfyldes: fx “TLS 1.3 med forward secrecy skal anvendes til alle forbindelser uden for lokal netværksperimeter.”

• Angiv miniminiveauer og målbare parametre – fx logning skal ske med timestamp, bruger-ID, IP og hændelsestype.

• Foretag intern krav-review og gennemfør markedsdialog i henhold til udbudslovens § 33 for at teste forståelighed og realiserbarhed.

Konklusion:
Tvister om uklare krav kan undgås ved at anvende standardiserede og målbare kravbeskrivelser, tekniske referencer og strukturerede bilag. En professionelt udarbejdet kravspecifikation sikrer retsgyldighed, sammenlignelighed og reel konkurrence – og reducerer risikoen for både klager og svigtende leverancer.

For at sikre effektiv håndtering af cybersikkerhedshændelser i overensstemmelse med NIS2-direktivet og anbefalinger fra Center for Cybersikkerhed (CFCS), bør kontrakten indeholde følgende elementer:

1. Responstider og hændelsesklassificering

• Kritiske hændelser: Maksimal responstid på 1 time.

• Højprioriterede hændelser: Responstid inden for 4 timer.

• Mindre hændelser: Responstid inden for 24 timer.

• Kategorisering: Hændelser skal klassificeres baseret på deres indvirkning og omfang, som defineret i NIS2 artikel 23

2. Rapportering til myndigheder

• Tidlig advarsel: Inden for 24 timer efter opdagelse af en betydelig hændelse.

• Detaljeret rapport: Inden for 72 timer, inklusive en foreløbig vurdering af hændelsens alvor og indvirkning.

• Slutrapport: Senest én måned efter hændelsen, med en detaljeret beskrivelse af hændelsen, dens årsag, afhjælpende foranstaltninger og eventuelle grænseoverskridende virkninger.

Disse krav er fastlagt i NIS2-direktivet artikel 23.

3. Anvendelse af CSIRT/SOC

• Dedikeret CSIRT/SOC: Leverandøren skal have adgang til eller samarbejde med et Computer Security Incident Response Team (CSIRT) eller Security Operations Center (SOC) for at sikre effektiv hændelseshåndtering.

• Samarbejde med CFCS: Leverandøren skal samarbejde med CFCS og andre relevante myndigheder i tilfælde af betydelige hændelser.

4. Dokumentation og kommunikation

• Logning: Alle hændelser og tilhørende aktiviteter skal dokumenteres detaljeret.

• Kommunikation: Der skal etableres klare kommunikationskanaler mellem leverandøren, ordregiveren og relevante myndigheder.

• Informationsdeling: Leverandøren skal dele relevante oplysninger om hændelser med ordregiveren og, hvor det er relevant, med CFCS.

5. Sanktioner ved manglende efterlevelse

• Bod: Kontrakten bør indeholde bestemmelser om bod ved manglende overholdelse af de fastsatte responstider og rapporteringskrav.

• Opsigelse: Gentagne eller alvorlige overtrædelser kan føre til ophævelse af kontrakten.

6. Test og øvelser

• Regelmæssige øvelser: Leverandøren skal gennemføre regelmæssige øvelser for at teste beredskabsplaner og hændelseshåndteringsprocedurer.

• Evaluering: Resultaterne af disse øvelser skal evalueres og bruges til at forbedre eksisterende processer.

CFCS anbefaler løbende test af beredskabsplaner som en del af en effektiv cyberforsvarsstrategi. Styrelsen for Samfundssikkerhed

Konklusion:

Ved at inkludere klare og detaljerede krav til hændelseshåndtering i kontrakten sikres det, at leverandøren er forpligtet til at reagere hurtigt og effektivt på cybersikkerhedshændelser, i overensstemmelse med gældende lovgivning og bedste praksis. Dette beskytter både ordregiveren og slutbrugerne mod potentielle trusler og sikrer kontinuiteten i kritiske tjenester.

Ja, en tilbudsgiver kan udelukkes fra en udbudsprocedure på grund af tidligere sikkerhedsbrud, men dette skal ske med omhu og i overensstemmelse med gældende lovgivning.

Juridisk grundlag: Udbudslovens § 137, stk. 1, nr. 5

Ifølge Udbudslovens § 137, stk. 1, nr. 5, kan en ordregiver udelukke en ansøger eller tilbudsgiver, hvis denne har begået alvorlige forsømmelser i forbindelse med udøvelsen af sit erhverv. Dette kan inkludere alvorlige sikkerhedsbrud, der sår tvivl om virksomhedens integritet eller pålidelighed.

Self-cleaning: Tilbudsgivers mulighed for at dokumentere pålidelighed

Før en udelukkelse kan finde sted, skal ordregiveren give tilbudsgiveren mulighed for at dokumentere, at der er truffet tilstrækkelige foranstaltninger til at afhjælpe den tidligere forseelse, en proces kendt som “self-cleaning”. Dette indebærer, at tilbudsgiveren skal fremlægge beviser for:

• Erstatning for eventuelle skader forårsaget af forseelsen.

• Samarbejde med relevante myndigheder for at klarlægge forholdene.

• Implementering af passende tekniske, organisatoriske og personalemæssige foranstaltninger for at forhindre fremtidige overtrædelser.

EU-Domstolen har i sag C-124/17, Vossloh Laeis GmbH mod Stadtwerke München GmbH, understreget vigtigheden af self-cleaning og fastslået, at ordregiveren skal vurdere, om de trufne foranstaltninger er tilstrækkelige til at genoprette tilbudsgiverens pålidelighed.

Objektiv dokumentation: Brug af CFCS og ENISA’s vurderinger

For at vurdere alvoren af et tidligere sikkerhedsbrud kan ordregiveren støtte sig til vurderinger fra relevante myndigheder som Center for Cybersikkerhed (CFCS) og European Union Agency for Cybersecurity (ENISA). Disse vurderinger kan fungere som objektiv dokumentation for bruddets alvor og omfang.

Konklusion

En tilbudsgiver kan udelukkes fra en udbudsprocedure på grund af tidligere sikkerhedsbrud, hvis ordregiveren kan dokumentere, at bruddet udgør en alvorlig forsømmelse i erhvervsudøvelsen. Tilbudsgiveren skal dog have mulighed for at dokumentere, at der er truffet tilstrækkelige foranstaltninger til at genoprette pålideligheden. Ordregiveren bør basere sin vurdering på objektiv dokumentation og sikre, at beslutningen er proportional og i overensstemmelse med gældende lovgivning.

Ifølge Udbudslovens § 138 skal en tilbudsgiver, der er omfattet af en udelukkelsesgrund, kunne dokumentere, at der er truffet tilstrækkelige foranstaltninger til at genoprette tilliden til virksomheden. Dette gælder også ved alvorlige sikkerhedsbrud. Dokumentationen skal være konkret og vise, at virksomheden har adresseret de forhold, der førte til bruddet, og har implementeret effektive tiltag for at forhindre gentagelser

Krav til dokumentation for self-cleaning

For at opfylde kravene til self-cleaning bør følgende elementer inkluderes i dokumentationen:

1. Interne undersøgelser og root cause-analyser
   En detaljeret redegørelse for de interne undersøgelser, der er foretaget for at identificere årsagen til sikkerhedsbruddet, herunder en root cause-analyse, der belyser de underliggende problemer.

2. Implementering af nye sikkerhedskontroller
   Beskrivelse af de tekniske og organisatoriske foranstaltninger, der er implementeret for at styrke sikkerheden, såsom indførelse af Zero Trust-arkitektur, forbedret adgangskontrol og opdaterede sikkerhedspolitikker.

3. Intern omstrukturering
   Oplysninger om eventuelle ændringer i organisationens struktur, herunder udskiftning eller ansættelse af nøglepersoner som en ny Chief Information Security Officer (CISO) eller etablering af et dedikeret sikkerhedsteam.

4. Tredjepartsrevideret rapport
   Fremlæggelse af uafhængige revisionsrapporter, såsom ISAE 3402-erklæringer eller resultater fra penetrationstest, der dokumenterer effektiviteten af de implementerede sikkerhedsforanstaltninger.

Eksempel på kontraktuel forankring

I en rammeaftale fra SKI er det anført, at leverandøren på anmodning skal fremsende redegørelser og dokumentation for de tiltag, der er iværksat for at begrænse risikoen for gentagelse af handlinger omfattet af udbudslovens udelukkelsesgrunde. Dette inkluderer forpligtelse til løbende at underrette om nye udviklinger og samarbejde med relevante myndigheder.

Anbefalinger fra ENISA og CFCS

Både ENISA og Center for Cybersikkerhed (CFCS) anbefaler, at organisationer dokumenterer læring fra tidligere hændelser som en del af en moden cybersikkerhedspraksis. Dette indebærer regelmæssig evaluering og opdatering af sikkerhedsforanstaltninger samt integration af erfaringer fra hændelser i risikostyringsprocesser.

Konklusion:

For at en it-leverandør kan dokumentere effektiv self-cleaning efter et alvorligt sikkerhedsbrud, skal der fremlægges omfattende og konkret dokumentation for de trufne foranstaltninger. Dette inkluderer interne analyser, implementering af forbedrede sikkerhedskontroller, organisatoriske ændringer og uafhængige revisioner. Sådanne tiltag viser en proaktiv tilgang til cybersikkerhed og kan genoprette tilliden hos ordregivere i offentlige udbud.

EU-Domstolens Schrems II-dom (C-311/18) fra juli 2020 erklærede EU-U.S. Privacy Shield-ordningen ugyldig og understregede, at overførsel af personoplysninger til tredjelande kun er lovlig, hvis beskyttelsesniveauet er “væsentligt ækvivalent” med EU’s standarder. Dette har direkte konsekvenser for offentlige it-udbud, især ved anvendelse af cloud- og hostingtjenester.

Centrale krav til leverandører

For at sikre overholdelse af Schrems II-dommen bør offentlige ordregivere stille følgende krav til leverandører:

1. Databehandling inden for EU/EØS
   Foretræk leverandører, der behandler og opbevarer data inden for EU/EØS, for at undgå overførsel til usikre tredjelande.

2. Supplerende tekniske foranstaltninger
   Hvis data overføres til tredjelande, skal leverandøren implementere tekniske foranstaltninger som end-to-end-kryptering, hvor kun dataeksportøren har adgang til krypteringsnøglerne. Dette sikrer, at data ikke er tilgængelige for uvedkommende, selv i tilfælde af adgang fra tredjelandsmyndigheder.

3. Standard Contractual Clauses (SCC’er)
   Inkluder SCC’er i databehandleraftalerne for at etablere juridiske garantier for databeskyttelse ved overførsel til tredjelande. Det er vigtigt at vurdere, om modtagerlandet reelt kan overholde disse klausuler.

4. Risikovurdering af modtagerlandets lovgivning
   Leverandøren bør fremlægge en vurdering af modtagerlandets lovgivning og praksis, især med hensyn til adgang for offentlige myndigheder til personoplysninger. Dette er nødvendigt for at afgøre, om yderligere foranstaltninger er påkrævet.

5. Supplerende organisatoriske foranstaltninger
   Implementer organisatoriske foranstaltninger som pseudonymisering og dataminimering for at reducere risikoen ved dataoverførsel. Disse tiltag kan fungere som et supplement til tekniske foranstaltninger.

Anbefalinger fra tilsynsmyndigheder

Datatilsynet og Det Europæiske Databeskyttelsesråd (EDPB) har udarbejdet anbefalinger for at sikre overholdelse af Schrems II-dommen:

• Datatilsynet anbefaler, at dataansvarlige foretager en grundig vurdering af overførselsgrundlaget og implementerer nødvendige supplerende foranstaltninger.

• EDPB har udgivet “Recommendations 01/2020” og “Recommendations 02/2020″, som giver vejledning om supplerende foranstaltninger og europæiske essentielle garantier ved dataoverførsel til tredjelande.

Konklusion

For at sikre compliance med Schrems II-dommen i it-sikkerhedsudbud bør offentlige ordregivere:

• Foretrække leverandører, der behandler data inden for EU/EØS.

• Kravstille implementering af tekniske og organisatoriske foranstaltninger ved overførsel til tredjelande.

• Inkludere SCC’er i databehandleraftaler og vurdere modtagerlandets evne til at overholde disse.

• Følge anbefalinger fra Datatilsynet og EDPB for at sikre et tilstrækkeligt beskyttelsesniveau for personoplysninger.

Ved at integrere disse krav i udbudsmaterialet kan ordregivere sikre, at leverandører lever op til de nødvendige databeskyttelsesstandarder og dermed overholder Schrems II-dommen.

For at sikre, at cybersikkerhedsniveauet opretholdes gennem hele kontraktens løbetid, kræves en kombination af governance, audits og fleksible kontraktmekanismer. Langvarige kontrakter bør struktureres, så kravene ikke er statiske, men løbende kan tilpasses teknologiske og trusselsmæssige ændringer.

1. Periodiske audits og dokumenteret kontrol

• Der bør fastsættes krav om tekniske og organisatoriske audits hver 6. eller 12. måned.

• Audits bør kunne gennemføres af ordregiver selv eller af uafhængig tredjepart.

• Leverandøren skal udarbejde og udlevere:

  • Compliance-rapporter

  • Testrapporter

  • Dokumentation for opfyldelse af minimumssikkerhed

2. Opdatering af trusselsbillede og foranstaltninger

• Kontrakten bør forpligte parterne til årlig gennemgang af det aktuelle trusselsbillede.

• CFCS’ nationale trusselsvurdering bør anvendes som grundlag for vurdering.

• Konkrete opdateringer til sikkerhedskrav, teknologier eller governance skal kunne implementeres gennem ændringshåndtering.

3. Mulighed for justering (change management)

• Der skal være en kontraktuel mekanisme for at:

  • Indføre nye sikkerhedskrav ved nye trusler

  • Tilpasse eksisterende krav i takt med markedsudvikling

• Ændringer bør baseres på objektiv dokumentation og gennemgå formel godkendelse i governance-forum.

4. Faste samarbejdsfora om cybersikkerhed

• CFCS og Digitaliseringsstyrelsen anbefaler etablering af faste samarbejdsfora.

• Forummet bør have en klar struktur med:

  • Mødefrekvens (f.eks. kvartalsvis)

  • Dagsorden (review af hændelser, rapporter, forbedringer)

  • Deltagelse fra leverandørens sikkerhedsansvarlige og ordregivers DPO/ISO

5. Teknisk due diligence

• Ordregiveren bør kunne gennemføre tekniske evalueringer, herunder:

  • Penetrationstests

  • Kildekodegennemgang (hvis relevant)

  • Vurdering af logs, kontrolspor og hændelsesberedskab

• Dette kan ske årligt eller ved mistanke om afvigelser fra kontrakten

Konklusion:
Ved at indarbejde klare mekanismer for løbende opfølgning, kontrol og tilpasning sikrer kontrakten, at cybersikkerhedsniveauet ikke forringes over tid. Dette reducerer risikoen for angreb, sikrer overholdelse af lovgivning og styrker samarbejdet mellem parterne.

Ja. Hvis en ordregiver ikke baserer sine it-sikkerhedskrav på en konkret vurdering af det aktuelle trusselsbillede, kan det udgøre en tilsidesættelse af principperne om gennemsigtighed og saglighed, jf. udbudslovens § 2 og forarbejderne hertil. Tekniske krav skal være sagligt begrundede og dokumenterede. En mangelfuld eller fraværende trusselsvurdering kan derfor udgøre en klageberettiget mangel, især hvis kravene virker uforholdsmæssige eller konkurrencebegrænsende.

1. Udbudslovens krav til saglighed og gennemsigtighed

• Udbudslovens § 2 fastslår, at ordregivere skal overholde principperne om gennemsigtighed og saglighed i udbudsprocessen.

• Dette indebærer, at alle krav, herunder it-sikkerhedskrav, skal være klart definerede og baseret på objektive kriterier.

2. Betydningen af trusselsvurdering

• En konkret trusselsvurdering er afgørende for at fastlægge relevante og proportionale it-sikkerhedskrav.

• Uden en sådan vurdering risikerer ordregiveren at stille krav, der enten er for lempelige eller unødigt restriktive, hvilket kan påvirke konkurrencen og leverandørernes mulighed for at afgive konditionsmæssige tilbud.

3. Konsekvenser af manglende trusselsvurdering

• Hvis it-sikkerhedskravene ikke er underbygget af en trusselsvurdering, kan det føre til klager fra leverandører, der mener, at kravene er urimelige eller diskriminerende.

• Klagenævnet for Udbud har i tidligere sager understreget vigtigheden af, at tekniske krav er sagligt begrundede og dokumenterede.

4. Anbefalinger for ordregivere

• Gennemfør en grundig trusselsvurdering som grundlag for fastsættelse af it-sikkerhedskrav i udbudsmaterialet.

• Dokumentér vurderingen og de afledte krav for at sikre gennemsigtighed og mulighed for efterprøvelse.

• Sørg for, at kravene er proportionale i forhold til de identificerede risici og ikke unødigt begrænser konkurrencen.

Konklusion:
En manglende eller utilstrækkelig trusselsvurdering kan føre til retlige klager og udbudsretlige fejl. For at sikre, at it-sikkerhedskravene er legitime, proportionale og retligt holdbare, bør ordregivere altid kunne dokumentere, hvordan kravene er blevet til, og hvilke trusler de adresserer. Dette er ikke kun et spørgsmål om compliance – det er også afgørende for en robust og ansvarlig udbudsproces.

Før et offentligt it-udbud er det afgørende at gennemføre en struktureret risikovurdering, der danner grundlag for relevante og proportionale sikkerhedskrav. Dette sikrer, at udbuddet adresserer de faktiske trusler og sårbarheder, som den pågældende løsning kan blive udsat for.

1. Identifikation af kritiske aktiver og data

• Kortlæg de systemer, data og processer, der er omfattet af udbuddet.

• Vurder kritikaliteten af disse aktiver i forhold til forretningsmæssige mål og lovgivningsmæssige krav.

2. Analyse af trusselsbilledet

• Inddrag relevante trusselsvurderinger, såsom CFCS’ årlige vurdering af cybertruslen mod Danmark, for at forstå det aktuelle trusselsbillede.

• Overvej sektorspecifikke trusler, hvis udbuddet vedrører kritisk infrastruktur eller særligt følsomme områder.

3. Vurdering af potentielle konsekvenser

• Analyser de mulige konsekvenser ved kompromittering af de identificerede aktiver, herunder:

  • Tab af fortrolighed, integritet eller tilgængelighed.

  • Overtrædelse af lovgivning, såsom databeskyttelsesforordningen.

  • Forretningsmæssige tab eller omdømmemæssige skader.

4. Anvendelse af standardiserede risikovurderingsmetoder

• Benyt anerkendte metoder som NIST SP 800-30, der tilbyder en systematisk tilgang til risikovurdering, herunder identifikation af trusler, sårbarheder og vurdering af sandsynlighed og konsekvens.

• Alternativt kan STRIDE-modellen anvendes til at identificere specifikke trusler mod systemets sikkerhedsegenskaber.

5. Dokumentation og integration i udbudsmaterialet

• Dokumenter risikovurderingens resultater klart og præcist.

• Inkluder relevante dele af risikovurderingen som bilag i udbudsmaterialet for at sikre gennemsigtighed og give tilbudsgivere mulighed for at forstå baggrunden for de stillede sikkerhedskrav.

Konklusion:

En grundig og dokumenteret risikovurdering før et it-udbud er essentiel for at sikre, at de stillede sikkerhedskrav er relevante, proportionale og baseret på det aktuelle trusselsbillede. Ved at anvende standardiserede metoder og inddrage relevante trusselsvurderinger kan ordregivere udforme udbudsmateriale, der både beskytter organisationens interesser og sikrer en fair og gennemsigtig udbudsproces.

Læs mere her:

Transportminsteriets strategi

Erhvervsstyrelsens strategi

For at sikre lovligheden af forlængelsesklausuler i it-kontrakter er det afgørende, at disse er klart og præcist formuleret i både udbudsmaterialet og den endelige kontrakt. Dette omfatter specifikation af varighed, antal mulige forlængelser og betingelser for udnyttelse.

1. Klare og præcise forlængelsesklausuler

• Forlængelsesklausuler skal indeholde:

  • Den oprindelige kontraktperiode.

  • Antal og varighed af mulige forlængelser.

  • Betingelser og procedurer for aktivering af forlængelser.

Dette sikrer gennemsigtighed og forudsigelighed for alle parter og overholder udbudslovens krav.

2. EU-Domstolens praksis

EU-Domstolen har i sag C-454/06 (Pressetext) fastslået, at ændringer af en kontrakt, herunder forlængelser, kan udgøre væsentlige ændringer, hvis de:

• Indfører betingelser, der kunne have tiltrukket andre tilbudsgivere.

• Ændrer kontraktens økonomiske balance til fordel for leverandøren.

• Udvider kontraktens anvendelsesområde væsentligt.

Sådanne ændringer kræver som udgangspunkt et nyt udbud.

3. Anbefalinger for kontraktudformning

• Indarbejd klare ændringsklausuler, der præcist angiver betingelserne for forlængelser.

• Sørg for, at alle potentielle forlængelser er forudset og beskrevet i udbudsmaterialet.

• Undgå formuleringer, der giver ordregiver et ubegrænset skøn til at forlænge kontrakten.

Konklusion:

For at sikre, at forlængelsesklausuler i it-kontrakter er lovlige og ikke udgør væsentlige ændringer, skal de være klart definerede og forudsete i både udbudsmaterialet og kontrakten. Dette overholder udbudslovens krav og EU-Domstolens praksis og sikrer gennemsigtighed og retssikkerhed for alle parter.

Prisforhandling er tilladt under særlige udbudsprocedurer, og det er afgørende, at forhandlingen sker inden for rammerne af udbudsloven og med fuld gennemsigtighed. I praksis er det primært relevant i forbindelse med udbud af komplekse it-ydelser, hvor tekniske løsninger og krav ofte udvikles i dialog.

1. Tilladte procedurer for forhandling

Forhandling må kun ske i følgende procedurer:

• Udbud med forhandling (udbudslovens § 61): Her har ordregiver hjemmel til at forhandle med en eller flere tilbudsgivere efter afgivelse af indledende tilbud.

• Konkurrencepræget dialog (§ 67): Her anvendes dialogen aktivt til at definere og afklare krav, som ikke kan beskrives tilstrækkeligt ved procedurens begyndelse.

Det skal fremgå allerede af udbudsbekendtgørelsen, hvilken procedure der anvendes, og at forhandling vil finde sted.

2. Udbudsmaterialets krav ved forhandling

Når en procedure med forhandling anvendes, skal følgende være præcist angivet i udbudsmaterialet:

• Hvilke dele af tilbuddet der må forhandles – fx pris, leveringstid, funktionalitet, SLA-vilkår eller datalokation.

• Hvordan forhandlingsforløbet vil foregå – herunder antal runder, tidsplan, og i hvilket format dialogen foregår.

• Hvilke grænser der gælder – f.eks. må mindstekrav ikke fraviges eller forhandles.

Eksempel: Ved udbud af en cloudbaseret platform som PaaS, kan ordregiver tillade forhandling om dataplacering, performance-krav, og transitionsplan, men fastholde ufravigelige krav til ISO 27001-certificering og oppetid.

3. It-udbud og anbefalinger ved komplekse løsninger

I komplekse it-projekter, hvor tekniske løsninger skal tilpasses og krav kan være dynamiske, anbefales:

• At anvende procedurer med forhandling, så leverandørens kompetencer kan inddrages i kravmodningen.

• At definere klart hvilke forhold der forhandles om, og sikre ensartet information til alle tilbudsgivere.

• At anvende en detaljeret forhandlingskalender og skabeloner til dokumentation af dialog og justeringer.

Konklusion:

Forhandling er kun lovlig, når den er baseret på en procedure, der udtrykkeligt tillader det. Ordregiver skal derfor vælge korrekt udbudsform, udforme klare regler for forhandlingen og dokumentere hele forhandlingsforløbet. For it-udbud, hvor behov og løsninger ofte er komplekse, er forhandling et vigtigt redskab – men det kræver en gennemtænkt og lovmedholdelig rammesætning.

Forbehold i tilbud på it-kontrakter vurderes ud fra deres indvirkning på udbudsmaterialets grundlæggende elementer. Ifølge udbudslovens § 159, stk. 1, nr. 2, skal ordregiver afvise tilbud, der ikke er konditionsmæssige, herunder tilbud med forbehold, der ændrer det udbudte grundlag væsentligt.

1. Typer af forbehold og deres konsekvenser

• Materielle forbehold: Ændringer i centrale kontraktvilkår, såsom prisregulering, ansvar, eller leveringsbetingelser, kan gøre et tilbud ukonditionsmæssigt og føre til afvisning.

• Formelle forbehold: Manglende underskrifter, ufuldstændige oplysninger eller afvigelser fra formkrav kan også medføre afvisning, selvom de ikke ændrer substansen af tilbuddet.

2. Vurdering af forbeholds betydning

Ordregiver skal foretage en konkret vurdering af hvert forbehold for at afgøre, om det påvirker udbudsmaterialets grundlæggende elementer. Hvis et forbehold ændrer væsentlige dele af kontrakten, skal tilbuddet afvises. Hvis forbeholdet er mindre væsentligt, kan ordregiver vælge at prissætte det, forudsat at dette er muligt og ikke strider mod udbudsreglerne.

3. Anbefalinger for håndtering af forbehold

• Klarhed i udbudsmaterialet: Angiv tydeligt, hvilke dele af kontrakten der er ufravigelige, og hvilke der kan forhandles.

• Standardvilkår: Ved brug af standardvilkår bør det præciseres, hvilke bestemmelser der anses for grundlæggende.

• Evalueringsstruktur: Adskil vurderingen af forbehold fra den øvrige evaluering for at sikre objektivitet og gennemsigtighed.

Konklusion:

Forbehold i tilbud på it-kontrakter skal vurderes nøje for at sikre overholdelse af udbudslovens krav. Ordregivere bør udarbejde klare udbudsmaterialer, der specificerer, hvilke vilkår der er ufravigelige, og etablere en evalueringsstruktur, der håndterer forbehold effektivt. Dette sikrer en fair og gennemsigtig udbudsproces.

Dokumentationskrav i offentlige it-udbud skal være proportionale i forhold til kontraktens genstand og risici. Dette princip er forankret i udbudslovens § 152, stk. 1, som fastslår, at ordregiver kun må stille krav, der er nødvendige og relevante for at sikre, at tilbudsgiveren har den fornødne økonomiske og tekniske kapacitet til at opfylde kontrakten.

1. Proportionalitetsprincippet i praksis

• Økonomisk og finansiel kapacitet: Krav om eksempelvis en bestemt årlig omsætning eller soliditetsgrad skal stå i rimeligt forhold til kontraktens størrelse og kompleksitet. For mindre it-kontrakter bør kravene være tilsvarende lavere end for store, komplekse projekter.

• Teknisk og faglig kapacitet: Krav om specifikke certificeringer eller tidligere erfaringer skal være relevante for den konkrete kontrakt. For eksempel bør krav om erfaring med lignende it-projekter være klart defineret og nødvendige for kontraktens gennemførelse.

2. EU-Domstolens praksis

EU-Domstolen har i sag C-27/15 (Pippo Pizzo mod CRGT Srl) understreget, at dokumentationskrav skal være nødvendige og proportionale i forhold til kontraktens genstand. Domstolen fastslog, at krav, der går ud over, hvad der er nødvendigt for at sikre kontraktens korrekte gennemførelse, kan være i strid med proportionalitetsprincippet.

3. Anbefalinger for it-udbud

• Skræddersyede krav: Tilpas dokumentationskravene til den specifikke it-kontrakt. For eksempel bør kravene til en kontrakt om vedligeholdelse af eksisterende software være mindre omfattende end for en kontrakt om udvikling af et nyt system.

• Klarhed i udbudsmaterialet: Angiv tydeligt, hvilke dokumenter og oplysninger der kræves, og hvordan de vil blive vurderet. Dette sikrer gennemsigtighed og forudsigelighed for tilbudsgiverne.

• Brug af ESPD: Anvend det fælleseuropæiske udbudsdokument (ESPD) til at indhente oplysninger om tilbudsgivernes egnethed, hvilket kan reducere den administrative byrde for både ordregiver og tilbudsgivere.

Konklusion

Proportionalitet i dokumentationskrav er afgørende for at sikre en fair og effektiv udbudsproces. Ved at tilpasse kravene til kontraktens karakter og kompleksitet, og ved at sikre klarhed og gennemsigtighed i udbudsmaterialet, kan ordregivere fremme konkurrence og sikre, at de modtager konditionsmæssige og relevante tilbud.

Kravspecificeringen i komplekse it-kontrakter skal være så præcis og udtømmende, at tilbudsgiverne kan afgive sammenlignelige og valide tilbud. Ifølge udbudslovens § 40 skal tekniske specifikationer udformes på en måde, der sikrer ligebehandling og gennemsigtighed.

1. Klar og entydig kravspecificering

• Funktionelle og ikke-funktionelle krav: Kravene bør omfatte både funktionelle aspekter (hvad systemet skal gøre) og ikke-funktionelle aspekter (ydelsesevne, sikkerhed, vedligeholdelse).

• Performance og integration: Beskriv systemets forventede ydeevne og dets evne til at integrere med eksisterende systemer.

• Datamodeller og vedligeholdelse: Angiv krav til datamodellering og plan for vedligeholdelse.

2. Anvendelse af standarder og skabeloner

• Standarder: Henvis til relevante standarder, såsom ISO/IEC 25010, for at sikre kvalitet og konsistens i kravene.

• Skabeloner med versionsstyring: Brug kravskabeloner med versionskontrol for at holde styr på ændringer og sikre konsistens.

3. Identifikation af mindstekrav og evalueringskriterier

• Mindstekrav: Angiv klart, hvilke krav der er ufravigelige, og som skal opfyldes for at tilbuddet er konditionsmæssigt.

• Evalueringskriterier: Beskriv, hvordan de øvrige krav vil blive vurderet i evalueringen af tilbuddene.

4. Fleksibilitet ved agile eller iterative projekter

• Fleksibel kravspecificering: Ved projekter med agile eller iterative metoder skal kravene formuleres, så de tillader tilpasning undervejs, uden at give uforholdsmæssig skønsmargin.

Konklusion

En grundig og klar kravspecificering er afgørende for at sikre, at tilbudsgivere kan afgive sammenlignelige og valide tilbud, hvilket understøtter en fair og gennemsigtig udbudsproces. Ved at følge ovenstående retningslinjer kan specialister bidrage til en effektiv og lovmedholdelig kravspecificering i komplekse it-kontrakter.

Ved tvivl om kontraktens værdi i forbindelse med tærskelværdien skal specialister sikre, at beregningen er realistisk, dokumenterbar og i overensstemmelse med udbudslovens bestemmelser.

1. Beregning af kontraktens samlede værdi

Ifølge udbudslovens § 30, stk. 1, skal kontraktens værdi anslås på baggrund af det samlede beløb, som ordregiveren forventer at betale til leverandøren. Dette inkluderer:

• Eventuelle optioner og forlængelser af kontrakten

• Præmier eller betalinger til ansøgere eller tilbudsgivere, som fastsættes i udbudsmaterialet

• Alle andre former for betalinger til leverandøren

Værdien skal opgøres eksklusive moms.

2. Tidspunkt for værdiansættelsen

Kontraktens værdi skal fastsættes på tidspunktet for afsendelsen af udbudsbekendtgørelsen. Hvis der ikke udsendes en udbudsbekendtgørelse, skal værdien beregnes på det tidspunkt, hvor ordregiveren indleder udbudsproceduren .

3. Forbud mod kunstig opdeling

Udbudslovens § 30, stk. 2, forbyder ordregivere at opdele kontrakter med det formål at undgå anvendelsen af udbudslovens bestemmelser. Metoden til beregning af den anslåede værdi må ikke fastlægges med henblik på at udelukke udbuddet fra lovens anvendelsesområde.

4. Dokumentation og skøn

Ordregiveren skal foretage et sagligt skøn over kontraktens værdi og dokumentere grundlaget for dette skøn. Dette kan omfatte:

• Markedsundersøgelser

• Historiske data fra tidligere udbud

• Rådgivning fra eksperter med branchekendskab

Det er vigtigt, at dette skøn er baseret på et tilstrækkeligt grundlag, da det kan blive efterprøvet i tilfælde af en klage.

5. Anbefalinger for specialister

• Inkluder alle relevante omkostninger i beregningen af kontraktens værdi

• Undgå opdeling af kontrakter uden objektiv begrundelse

• Dokumenter grundlaget for værdiansættelsen grundigt

• Foretag markedsundersøgelser for at understøtte skønnet

• Vær opmærksom på, at selv usandsynlige optioner skal medregnes i kontraktens værdi

Konklusion:

En korrekt beregning af kontraktens værdi er afgørende for at sikre, at tærskelværdien vurderes i overensstemmelse med udbudslovens § 30. Specialister skal foretage et samlet og dokumenterbart skøn over den forventede værdi, inklusive alle optioner og forlængelser. Det er ikke tilladt at opdele kontrakter kunstigt for at undgå EU-udbud. Ved at anvende markedsdata, tidligere kontraktpriser og kvalificerede estimater – og sikre, at skønnet er realistisk og sagligt underbygget – styrkes både lovmedholdeligheden og tilliden til udbudsprocessen. Beregningsgrundlaget bør arkiveres og kunne fremlægges i tilfælde af tilsyn eller klage.

Effektiv kontraktstyring i komplekse it-kontrakter forudsætter en struktureret tilgang, der kombinerer klare governance-strukturer, løbende opfølgning og dokumentation. Dette sikrer, at leverandøren leverer i overensstemmelse med kontraktens krav og at eventuelle afvigelser håndteres rettidigt.

1. Etablering af governance-strukturer

• Styregrupper og statusmøder: Oprettelse af styregrupper med repræsentanter fra både ordregiver og leverandør sikrer strategisk overblik. Regelmæssige statusmøder, f.eks. månedlige, muliggør løbende opfølgning på projektets fremdrift og håndtering af udfordringer.

• Eskalationsveje: Definerede procedurer for eskalation af problemer sikrer, at kritiske issues behandles på passende niveau og inden for rimelig tid.

2. Leverancestyring og præstationsopfølgning

• Milepælsaflevering: Fastlæggelse af klare milepæle med tilhørende leverancer og godkendelseskriterier muliggør struktureret opfølgning og sikrer, at projektet forløber som planlagt.

• Sanktioner ved afvigelser: Kontrakten bør indeholde bestemmelser om sanktioner ved manglende overholdelse af aftalte leverancer eller kvalitetskrav, f.eks. bod eller mulighed for ophævelse.

3. Integration af projektstyringsværktøjer

• Anvendelse af anerkendte metoder: Implementering af projektstyringsmetoder som PRINCE2, ITIL eller SCRUM kan bidrage til en struktureret og effektiv projektgennemførelse.

4. Dokumentation og kontrolspor

• Ændringshåndtering: Etablering af procedurer for håndtering af ændringer i projektets omfang, tidsplan eller budget sikrer, at alle ændringer dokumenteres og godkendes af relevante parter.

• Audit-trail: Opretholdelse af et detaljeret kontrolspor over beslutninger, ændringer og kommunikation er afgørende for at kunne dokumentere kontraktens efterlevelse og håndtere eventuelle tvister.

Konklusion

Effektiv kontraktstyring af komplekse it-kontrakter kræver en kombination af klare governance-strukturer, løbende opfølgning på leverancer og præstationer, integration af anerkendte projektstyringsmetoder samt grundig dokumentation. Ved at implementere disse elementer kan ordregiver sikre, at kontrakten gennemføres som planlagt og at eventuelle udfordringer håndteres proaktivt.

Sociale klausuler kan lovligt integreres i it-udbud, forudsat at de er klart formulerede, relevante for kontraktens genstand og ikke-diskriminerende. Dette er fastlagt i udbudslovens § 176, stk. 1, som tillader ordregivere at fastsætte særlige betingelser for kontraktens gennemførelse, herunder sociale og beskæftigelsesrelaterede hensyn, forudsat at disse betingelser er forbundet med kontraktens genstand og anføres i udbudsbekendtgørelsen eller det øvrige udbudsmateriale,

1. Lovgrundlag og EU-praksis

• Udbudslovens § 176, stk. 1, giver ordregivere mulighed for at fastsætte særlige betingelser for kontraktens gennemførelse, herunder sociale hensyn, forudsat at disse er forbundet med kontraktens genstand og anføres i udbudsmaterialet.

• EU-Domstolen har i sag C-368/10 (Max Havelaar) fastslået, at sociale hensyn kan indgå som kontraktvilkår, så længe de er objektive, gennemsigtige og ikke-diskriminerende.

2. Praktisk anvendelse i it-udbud

I it-udbud anvendes sociale klausuler typisk til at fremme:

• Lærlingepladser: Krav om, at leverandøren beskæftiger personer under oplæring, såsom lærlinge eller praktikanter, i forbindelse med kontraktens gennemførelse.

• Mangfoldighed: Foranstaltninger, der fremmer beskæftigelse af personer fra underrepræsenterede grupper.

• Ordentlige arbejdsvilkår: Sikring af, at leverandøren overholder gældende arbejdsretlige forpligtelser, herunder løn- og arbejdsvilkår.

3. Implementering og kontrol

• KPI’er og måling: Det anbefales at angive konkrete målepunkter (Key Performance Indicators) for leverandørens efterlevelse af sociale klausuler.

• Sanktioner: Kontrakten bør indeholde bestemmelser om konsekvenser ved misligholdelse af sociale klausuler, såsom bod eller mulighed for ophævelse.

• Auditplan: Udarbejdelse af en plan for kontrol og opfølgning på overholdelsen af sociale klausuler er afgørende for at sikre effektiv håndhævelse.

4. Konklusion

Specialister bør sikre, at sociale klausuler i it-kontrakter er klart formulerede, relevante for kontraktens genstand og ikke-diskriminerende. Det er vigtigt at fastsætte konkrete målepunkter og sanktioner samt at udarbejde en auditplan for at sikre effektiv implementering og kontrol. Ved at følge disse retningslinjer kan sociale klausuler bidrage til at fremme sociale hensyn i offentlige it-udbud.

Ved modtagelse af tilbud, der fremstår unormalt lave, skal ordregiver aktivt undersøge årsagen, jf. udbudslovens § 169. EU-Domstolen har i sag C-599/10 (SAG ELV Slovensko) fastslået, at ordregiver ikke må afvise et unormalt lavt tilbud uden først at give tilbudsgiver mulighed for at forklare forholdet.

1. Identifikation af unormalt lave tilbud

• Der findes ikke en fast definition på, hvornår et tilbud er unormalt lavt. Det er op til ordregiver at vurdere, om et tilbud fremstår unormalt lavt i forhold til den udbudte ydelse. Denne vurdering kan baseres på en sammenligning med andre tilbud eller med ordregivers egne estimater.

2. Undersøgelsespligt og dialog med tilbudsgiver

• Hvis et tilbud fremstår unormalt lavt, skal ordregiver skriftligt anmode tilbudsgiveren om en redegørelse for tilbuddet. Denne redegørelse kan omfatte oplysninger om:

  • Besparelser i forbindelse med produktionsmetoder eller tjenesteydelser

  • Tekniske løsninger eller usædvanligt gunstige betingelser

  • Originaliteten af de tilbudte ydelser

  • Overholdelse af arbejdsretlige forpligtelser

  • Eventuel statsstøtte

• Ordregiver skal vurdere de modtagne oplysninger og afgøre, om tilbuddet er seriøst og bæredygtigt. Hvis ordregiver vurderer, at redegørelsen ikke er tilstrækkelig, kan tilbuddet afvises som unormalt lavt.

3. Praktiske anbefalinger for it-udbud

• Udarbejd interne retningslinjer for identifikation og håndtering af unormalt lave tilbud.

• Sørg for, at udbudsmaterialet indeholder klare kriterier for vurdering af tilbuddenes økonomiske realisme.

• Dokumenter alle trin i processen, herunder korrespondance med tilbudsgiveren og vurderingen af dennes redegørelse.

Konklusion

Korrekt håndtering af unormalt lave tilbud er afgørende for at sikre en fair og gennemsigtig udbudsproces. Ved at følge de fastsatte procedurer og sikre en grundig vurdering af tilbuddenes realisme kan ordregiver minimere risikoen for at indgå kontrakter, der ikke kan opfyldes tilfredsstillende.

Håndtering af underleverandører i komplekse it-kontrakter kræver nøje opmærksomhed på både udbudsretlige krav og kontraktuelle bestemmelser. Dette sikrer gennemsigtighed, ansvarlighed og overholdelse af gældende lovgivning.

1. Identifikation og dokumentation af underleverandører

   • Hvis en tilbudsgiver baserer sig på andre enheders økonomiske, finansielle, tekniske eller faglige formåen, skal dette fremgå ved tilbudsafgivelsen. Tilbudsgiveren skal fremlægge dokumentation, såsom støtteerklæringer, der bekræfter, at de pågældende enheder er juridisk forpligtet til at stille deres ressourcer til rådighed (udbudslovens § 144).

   • Ordregiveren skal verificere, at de enheder, som tilbudsgiveren baserer sig på, opfylder relevante minimumskrav til egnethed og ikke er omfattet af udelukkelsesgrundene.

2. Kontraktuelle bestemmelser vedrørende underleverandører

   • Kontrakten bør klart angive, at hovedleverandøren er fuldt ansvarlig for underleverandørers ydelser.

   • Der bør fastsættes procedurer for udskiftning af underleverandører, herunder krav om forudgående godkendelse fra ordregiveren.

   • Det bør fremgå, om ordregiveren har ret til direkte at kontakte underleverandører i forbindelse med kontraktens gennemførelse.

3. Anbefalinger for effektiv håndtering

   • Udbudsmaterialet bør indeholde klare retningslinjer for anvendelse af underleverandører, herunder krav til dokumentation og godkendelsesprocedurer.

   • Etabler procedurer for løbende overvågning af underleverandørers ydelser og overholdelse af kontraktuelle forpligtelser.

   • Fastlæg sanktioner for tilfælde, hvor underleverandører ikke lever op til kravene, herunder mulighed for bod eller ophævelse af kontrakten.

Konklusion:
Korrekt håndtering af underleverandører i komplekse it-kontrakter indebærer en kombination af præcise udbudsbetingelser og klare kontraktuelle bestemmelser. Ved at sikre gennemsigtighed, ansvarlighed og overholdelse af lovgivningen kan ordregivere minimere risici og sikre en effektiv kontraktgennemførelse.

Proportionalitet i bodsbestemmelser er afgørende for at sikre, at bestemmelserne understøtter effektiv kontraktstyring uden at virke sanktionerende i strid med aftaleretlige principper. Bod må ikke fungere som straf, men skal afspejle kontraktens risici og være forbundet med leverandørens faktiske misligholdelse.

1. Formål med bod

   • Bod skal have til hensigt at kompensere for den værdi eller det tab, ordregiver risikerer ved leverandørens manglende opfyldelse.

   • Det kan fx være manglende overholdelse af milepæle, overskridelse af svartider eller brud på serviceniveauer fastsat i SLA.

2. Forankring i kontraktens risikoprofil

   • Bod bør tilpasses løsningens forretningskritikalitet: jo mere kritisk leverancen er, desto højere bodsniveau kan forsvares.

   • Eksempel: Manglende oppetid i en driftstjeneste til borgerselvbetjening kan have større konsekvenser end i en testapplikation.

3. Graduering og objektive målepunkter

   • Brug graduering: forskellig bod afhængig af misligholdelsens omfang og varighed.

   • Anvend kvantificerbare parametre: fx procentuel oppetid, fejl pr. måned, overskredne deadlines i antal dage.

   • Sikrer forudsigelighed for begge parter og minimerer tvist om opgørelsen.

4. Bodsloft og samlet eksponering

   • Etabler et loft over den samlede bod – fx 10–20 % af kontraktens årlige værdi – for at sikre proportionalitet og undgå overeksponering af leverandøren.

   • Ved gentagne misligholdelser bør kombinationen af bod og øvrige misligholdelsesbeføjelser (fx ophævelse) aktiveres i stedet.

5. Forholdet til øvrige misligholdelsesbestemmelser

   • Bod bør indgå som én af flere mekanismer, og kontrakten bør tydeliggøre, om betaling af bod udelukker øvrige misligholdelseskrav.

   • For større kontrakter anbefales det at adskille standardbrud (bod) og væsentlig misligholdelse (ophævelse, erstatning).

Konklusion:
En korrekt udformet bodsbestemmelse er balanceret, målbar og afspejler løsningens betydning. Den skal kunne håndhæves uden at være uproportional og bør ledsages af klare kontrol- og rapporteringsmekanismer. Et veldesignet bodsregime skaber incitament for leverandøren til at overholde forpligtelserne – uden at udgøre en urimelig økonomisk risiko.

Misligholdelse i it-kontrakter kan have betydelige konsekvenser, hvorfor kontrakten bør indeholde tydelige bestemmelser om ansvar, frister og misligholdelsesbeføjelser, herunder mulighed for ophævelse. Det anbefales at operere med en trinvis misligholdelsesmodel, hvor leverandøren først gives mulighed for afhjælpning, efterfulgt af bod, og i sidste ende ophævelse. Bestemmelser bør også tage højde for dataoverdragelse og ret til fortsættelse af drift i overgangsperiode.

1. Kontraktuelle bestemmelser om misligholdelse

   • Kontrakten bør indeholde klare bestemmelser om, hvad der udgør misligholdelse, herunder forsinkelser, manglende opfyldelse af kravspecifikationer eller brud på serviceniveauaftaler (SLA).

   • Det er vigtigt at definere procedurer for håndtering af misligholdelse, herunder varsling, afhjælpningsfrister og konsekvenser ved fortsat misligholdelse.

2. Trinvis misligholdelsesmodel

   • En effektiv tilgang er at implementere en trinvis model:

     • Afhjælpning: Leverandøren får mulighed for at rette op på misligholdelsen inden for en fastsat frist.

     • Bod: Hvis misligholdelsen fortsætter, kan der pålægges bod i overensstemmelse med kontraktens bestemmelser.

     • Ophævelse: Ved væsentlig eller gentagen misligholdelse kan kontrakten ophæves.

3. Dataoverdragelse og overgangsperiode

   • Kontrakten bør indeholde bestemmelser om dataoverdragelse ved ophør, herunder format, tidsramme og ansvar for overdragelsen.

   • Det er også vigtigt at sikre, at der er en plan for fortsat drift i en overgangsperiode, indtil en ny leverandør er på plads.

4. Dokumentation og kommunikation

   • Alle tilfælde af misligholdelse og de trufne foranstaltninger bør dokumenteres grundigt.

   • En klar kommunikationslinje mellem ordregiver og leverandør er afgørende for at håndtere misligholdelse effektivt.

Konklusion
Effektiv håndtering af misligholdelse i komplekse it-kontrakter kræver klare kontraktuelle bestemmelser, en struktureret tilgang til afhjælpning og sanktioner samt fokus på dataoverdragelse og overgangsperioder. Ved at implementere en trinvis misligholdelsesmodel og sikre grundig dokumentation kan ordregivere minimere risici og sikre kontinuitet i it-leverancer.

Effektiv tvistløsning i komplekse it-kontrakter kræver en systematisk tilgang, der fremmer tidlig afklaring og minimerer risikoen for eskalering. Dette indebærer klare kontraktuelle bestemmelser og en struktureret tvistløsningsproces.

1. Kontraktuelle bestemmelser om tvistløsning

   • Kontrakten bør indeholde en klar tvistløsningsklausul, der fastlægger procedurer for håndtering af uenigheder.

   • Det anbefales at inkludere en trinvis proces:

     • Teknisk dialog: Parterne forsøger at løse tekniske uenigheder gennem faglig dialog.

     • Ledelsesforhandling: Hvis teknisk dialog ikke fører til en løsning, eskaleres sagen til ledelsesniveau for forhandling.

     • Mediation: En neutral tredjepart faciliterer en løsning mellem parterne.

     • Voldgift eller domstolsprøvelse: Hvis tidligere trin ikke fører til en løsning, kan sagen afgøres ved voldgift eller domstolene.

2. Sanktionsfrie mekanismer

   • For at undgå eskalering anbefales det at etablere sanktionsfrie mekanismer, såsom:

     • Neutral third party review: En uafhængig ekspert vurderer tvisten og giver en ikke-bindende udtalelse.

     • Expert determination: En udpeget ekspert træffer en bindende afgørelse om en specifik teknisk tvist.

3. Offentlige kontrakter og klageadgang

   • For offentlige kontrakter bør kontrakten indeholde bestemmelser om klageadgang i henhold til Klagenævnsloven, herunder fastlæggelse af værneting og gældende ret.

   • Det er vigtigt at være opmærksom på klagefrister og procedurer for indgivelse af klager til Klagenævnet for Udbud.

Konklusion
En effektiv tvistløsningsproces i komplekse it-kontrakter kræver klare kontraktuelle bestemmelser, en struktureret tilgang til konfliktløsning og etablering af mekanismer, der fremmer tidlig afklaring. Ved at implementere en trinvis tvistløsningsmodel og sanktionsfrie mekanismer kan parterne minimere risikoen for eskalering og sikre en effektiv håndtering af uenigheder.

For at sikre overholdelse af GDPR i komplekse it-kontrakter er det afgørende, at databeskyttelseskrav integreres systematisk i kontraktens struktur og indhold, særligt når leverandøren behandler personoplysninger på vegne af den dataansvarlige.

1. Databehandleraftale i henhold til GDPR artikel 28
   Når en leverandør behandler personoplysninger på vegne af en dataansvarlig, skal der indgås en skriftlig databehandleraftale, som specificerer:

   • Behandlingens genstand og varighed

   • Behandlingens karakter og formål

   • Typen af personoplysninger og kategorier af registrerede

   • Den dataansvarliges og databehandlerens forpligtelser og rettigheder

   Aftalen skal også indeholde bestemmelser om, at databehandleren:

   • Kun må behandle personoplysninger efter dokumenteret instruks fra den dataansvarlige

   • Sikrer, at personer autoriseret til at behandle oplysningerne har forpligtet sig til fortrolighed

   • Gennemfører passende tekniske og organisatoriske foranstaltninger i overensstemmelse med artikel 32

   • Bistår den dataansvarlige med at sikre overholdelse af forpligtelserne i henhold til artiklerne 32 til 36

   • Efter afslutning af behandlingen, sletter eller returnerer alle personoplysninger til den dataansvarlige

   • Stiller alle oplysninger til rådighed for den dataansvarlige, der er nødvendige for at påvise overholdelse af kravene i artikel 28, og tillader og bidrager til revisioner, herunder inspektioner

   Disse krav er fastlagt i GDPR artikel 28, stk. 3 .

2. Brug af standardkontraktbestemmelser
   Datatilsynet har offentliggjort en standard-databehandleraftale, som kan anvendes til at opfylde kravene i artikel 28. Denne skabelon er særligt relevant for kontrakter, hvor både den dataansvarlige og databehandleren er etableret i Danmark. For grænseoverskridende behandlinger kan EU-Kommissionens standardkontraktbestemmelser være mere passende.

3. Auditadgang og dokumentation
   Kontrakten bør indeholde bestemmelser, der giver den dataansvarlige ret til at gennemføre audits og inspektioner hos databehandleren for at verificere overholdelse af databeskyttelseskravene. Databehandleren skal stille alle nødvendige oplysninger til rådighed og bidrage til disse audits .

4. Håndtering af underdatabehandlere
   Databehandleren må ikke engagere en anden databehandler uden forudgående specifik eller generel skriftlig godkendelse fra den dataansvarlige. Hvis der gives generel godkendelse, skal databehandleren informere den dataansvarlige om eventuelle planlagte ændringer, hvilket giver den dataansvarlige mulighed for at gøre indsigelse .

5. Sikkerhedsforanstaltninger og incident response
   Databehandleren skal implementere passende tekniske og organisatoriske foranstaltninger for at sikre et sikkerhedsniveau, der passer til risiciene ved behandlingen. Dette inkluderer evnen til at sikre fortrolighed, integritet, tilgængelighed og robusthed af behandlingssystemer samt evnen til rettidigt at genoprette tilgængeligheden af og adgangen til personoplysninger i tilfælde af en fysisk eller teknisk hændelse .

6. Koordination med databeskyttelsesrådgiver (DPO)
   Det anbefales, at den dataansvarliges databeskyttelsesrådgiver (DPO) inddrages i udarbejdelsen og gennemgangen af databehandleraftalen for at sikre, at alle databeskyttelseskrav er korrekt adresseret.

Konklusion
For at sikre compliance med GDPR i komplekse it-kontrakter er det essentielt at integrere databeskyttelseskrav i kontraktens opbygning og indhold. Dette omfatter indgåelse af en skriftlig databehandleraftale i overensstemmelse med artikel 28, anvendelse af passende standardkontraktbestemmelser, etablering af auditadgang, klar håndtering af underdatabehandlere, implementering af passende sikkerhedsforanstaltninger og inddragelse af DPO’en i processen. Ved at følge disse retningslinjer kan organisationer sikre, at deres it-kontrakter overholder GDPR og beskytter de registreredes rettigheder.

Ændringer i leverandørens ejerstruktur under kontraktperioden kan have udbudsretlige konsekvenser, særligt hvis de påvirker leverandørens identitet eller kapacitet i et omfang, der ændrer kontraktens grundlæggende karakter. Derfor bør ordregiver håndtere sådanne ændringer med høj grad af opmærksomhed og kontraktuel forankring.

1. Vurdering af ændringens betydning
   Ændringer i ejerstrukturen er i sig selv ikke forbudt, men kan blive udbudsretligt problematiske, hvis de medfører, at kontrakten ikke længere svarer til den, der oprindeligt blev udbudt. Dette gælder fx, hvis:

• den juridiske enhed, som oprindeligt blev tildelt kontrakten, erstattes af en anden (fusion, opkøb),

• nye ejere medfører ændringer i økonomisk eller teknisk kapacitet, som var afgørende i tildelingen,

• væsentlige underleverandører udskiftes, hvis deres teknologi eller kompetencer udgjorde en central del af tilbuddet.

Dette blev understreget af EU-Domstolen i sag C-91/08 (Wall AG), hvor ordregiver tillod, at den oprindeligt angivne underleverandør (Wall AG) blev udskiftet efter kontraktindgåelse. Domstolen fastslog, at Wall AG’s teknologi var væsentlig for tildelingsbeslutningen, og at udskiftningen derfor udgjorde en væsentlig ændring af kontrakten, hvilket krævede et nyt udbud. Det gjaldt, uanset at kontrakten teknisk set tillod udskiftning af underleverandører med samtykke.

2. Kontraktuelle bestemmelser om ændringer
   For at sikre transparens og kontrol bør kontrakten indeholde eksplicitte bestemmelser om håndtering af ejerstrukturændringer, herunder:

• krav om skriftlig meddelelse til ordregiver før ændringen gennemføres,

• dokumentation for, at den nye ejerstruktur ikke forringer leverandørens evne til at opfylde kontrakten,

• ordregivers ret til at godkende eller afvise ændringen på baggrund af en konkret vurdering.

3. Due diligence og vurdering af konsekvenser
   Ved væsentlige ændringer i ejerstruktur anbefales det, at ordregiver foretager en konkret vurdering – fx via due diligence – for at klarlægge:

• om leverandørens økonomiske og tekniske kapacitet er ændret,

• om ændringen rejser nye risici eller interessekonflikter,

• om ændringen påvirker compliance med fx sikkerhedskrav, GDPR eller andre regulatoriske forhold.

4. Mulighed for genudbud
   Hvis vurderingen viser, at ændringen har karakter af en væsentlig ændring, der påvirker grundlaget for tildelingen, bør ordregiver overveje, om kontrakten skal genudbydes for at sikre ligebehandling og overholdelse af udbudsreglerne.

Konklusion
Ejerstrukturændringer hos en leverandør er ikke nødvendigvis i strid med udbudsreglerne, men kan være det, hvis de ændrer kontraktens karakter væsentligt. I tråd med EU-Domstolens praksis (C-91/08) bør ordregiver sikre, at sådanne ændringer altid håndteres gennem klare kontraktbestemmelser, dokumentation og konkret vurdering af deres betydning. Ved tvivl bør der søges juridisk rådgivning, og genudbud kan være nødvendigt for at sikre lovligheden.

For at undgå, at kontraktændringer under en igangværende it-kontrakt bliver betragtet som ulovlige direkte tildelinger, er det afgørende at forstå og anvende de relevante juridiske rammer og principper.

1. Juridisk ramme og principper
   Udbudslovens § 178 fastlægger, at væsentlige ændringer af en offentlig kontrakt kræver en ny udbudsprocedure. EU-Domstolen har i sag C-454/06 (Pressetext) præciseret, at ændringer, der ændrer kontraktens grundlæggende karakteristika, betragtes som nye kontrakter og derfor skal udbydes på ny. Dette gælder især, hvis ændringen:

   • introducerer betingelser, der ville have tilladt andre deltagere at deltage i udbudsproceduren,

   • ændrer kontraktens økonomiske balance til fordel for leverandøren, eller

   • udvider kontraktens anvendelsesområde betydeligt.

2. Praktiske tiltag for at sikre compliance
   For at sikre, at kontraktændringer ikke udgør ulovlige direkte tildelinger, bør følgende tiltag implementeres:

   • Ændringsklausuler: Inkluder klare og præcise ændringsklausuler i kontrakten, der specificerer betingelserne for eventuelle ændringer.

   • Juridisk vurdering: Foretag en juridisk vurdering af alle foreslåede ændringer for at afgøre, om de er væsentlige.

   • Dokumentation: Dokumenter alle ændringer og de overvejelser, der ligger til grund for dem, for at sikre gennemsigtighed og sporbarhed.

   • Godkendelsesproces: Etabler en intern godkendelsesproces, hvor ændringer gennemgås og godkendes af relevante interessenter.

   • Revision af bilag: Opdater kontraktens bilag for at afspejle ændringer i pris, ydelsesindhold eller leverancetidspunkt.

3. Konklusion
   Ved at forstå og anvende de juridiske rammer og principper for kontraktændringer, samt implementere robuste interne processer, kan eksperter sikre, at ændringer i it-kontrakter ikke fører til ulovlige direkte tildelinger. Dette bidrager til at opretholde lovligheden og integriteten af offentlige indkøb.