En IT-serviceaftale skal gøre det tydeligt, hvem der gør hvad, hvornår hjælpen kommer, og hvad virksomheden betaler for. Uden klare vilkår kan selv en billig aftale blive dyr, når en kritisk systemfejl opstår.
For små og mellemstore virksomheder handler aftalen ikke kun om support. Den skal også dække sikkerhed, backup, dokumentation, databehandling, ændringer og afslutning af samarbejdet. Her får du en praktisk gennemgang af de punkter, der bør stå i kontrakten.
Key Takeaways
- Aftalens scope skal beskrive brugere, systemer, enheder og opgaver præcist.
- Et SLA skal skelne mellem svartid, løsningstid og supportens åbningstid.
- Backup, sikkerhedshændelser og databehandleransvar skal stå skriftligt.
- Priser, ekstraarbejde, opsigelse og hjælp ved leverandørskifte må ikke være uklare.
- Gode aftaler kan testes med konkrete fejlscenarier, før de bliver underskrevet.
Beskriv præcist, hvad IT-serviceaftalen dækker
Den første del af en IT-serviceaftale bør afgrænse leverancen. Skriv ikke kun, at leverandøren leverer “IT-support efter behov”. Den formulering giver for meget plads til fortolkning, når en opgave falder uden for den forventede service.
Aftalen bør som minimum beskrive:
- Antal brugere, lokationer og enheder
- De systemer, netværk og tjenester, der er omfattet
- Support via telefon, e-mail, portal eller fjernforbindelse
- Vedligeholdelse, overvågning og sikkerhedsopdateringer
- Håndtering af nye medarbejdere, fratrædelser og udstyr
- Om onsite-besøg, projekter og installationer er inkluderet
En virksomhed med 35 medarbejdere kan for eksempel have behov for support til arbejdsstationer, netværk, printere, mail, fildeling og adgangsstyring. Hvis serverdrift eller hjemmearbejdspladser ikke er med i aftalen, skal det stå tydeligt.
Aftal også, hvem der må oprette sager, og hvordan leverandøren prioriterer dem. En medarbejders spørgsmål om en printer bør ikke behandles på samme måde som et nedbrud, der rammer hele virksomheden.
Supportens åbningstid kræver samme præcision. “24/7-support” kan betyde døgnåben telefon, overvågning uden for normal arbejdstid eller blot mulighed for at oprette en sag. Bed om en klar formulering, for eksempel:
“Support er bemandet mandag til fredag kl. 8.00-16.00. Kritiske hændelser kan anmeldes døgnet rundt. Uden for bemandet tid gælder en maksimal svartid på 60 minutter.”
Aftalen bør også indeholde en opdateret oversigt over virksomhedens IT-miljø. Den kan ligge som bilag og beskrive netværk, licenser, kontaktpersoner, backup, domæner og kritiske systemer. Når dokumentationen er en del af leverancen, bliver virksomheden mindre afhængig af enkeltpersoner.
SLA-niveauer skal kunne måles i praksis
Et SLA, altså en aftale om serviceniveau, omsætter forventninger til målbare krav. Det bør ikke kun nævne “hurtig respons”. Brug i stedet konkrete tidsfrister, prioriteringer og målemetoder.
SLA’et skal skelne mellem svartid og løsningstid. Svartid er, hvor lang tid der må gå, før en medarbejder hos leverandøren tager sagen op. Løsningstid er, hvor lang tid der går, før problemet er løst eller har fået en accepteret midlertidig løsning.
Et eksempel på niveauer kan se sådan ud:
| Prioritet |
Eksempel |
Første respons |
Midlertidig løsning |
| Kritisk |
Hele virksomheden kan ikke arbejde |
30 minutter |
4 timer |
| Høj |
En vigtig funktion er utilgængelig for flere brugere |
1 time |
8 timer |
| Normal |
En enkelt bruger har et begrænset problem |
4 arbejdstimer |
2 arbejdsdage |
| Lav |
Spørgsmål, bestilling eller mindre ændring |
1 arbejdsdag |
Efter aftale |
Tallene er eksempler, ikke faste standarder. Det afgørende er, at virksomheden vælger niveauer efter driftsbehov. En produktionsvirksomhed kan have brug for døgnberedskab ved netværksfejl, mens et mindre kontor måske kan acceptere løsning næste arbejdsdag.
Skriv også, hvem der vurderer prioriteten. Hvis leverandøren alene kan nedgradere alle sager, mister SLA’et sin værdi. En bedre formulering er:
“Kunden kan markere en sag som kritisk. Leverandøren kan ændre prioriteten efter dialog med kunden og skal begrunde ændringen i sagen.”
Bed om månedlig rapportering på svartider, åbne sager, gentagne fejl og brud på SLA. Aftalen skal forklare, om tiden måles fra oprettelse eller fra det tidspunkt, hvor leverandøren har modtaget alle nødvendige oplysninger.
Der bør også stå noget om konsekvenserne ved gentagne brud. Det kan være et møde med en handlingsplan, servicekreditter eller mulighed for opsigelse efter en aftalt periode. En servicekredit bør dog ikke erstatte reel dialog, hvis virksomheden gentagne gange oplever driftsproblemer.
Sikkerhed, backup og persondata skal være en del af aftalen
En IT-serviceaftale uden sikkerhedsvilkår efterlader de vigtigste spørgsmål ubesvarede. Hvem overvåger mistænkelig aktivitet? Hvem lukker en kompromitteret konto? Hvor hurtigt får virksomheden besked om et muligt databrud?
Aftalen bør beskrive en fast proces for sikkerhedshændelser. Den kan for eksempel fastslå, at leverandøren skal kontakte virksomhedens udpegede ansvarlige inden for 30 minutter ved en hændelse med høj risiko. Den bør også angive, hvem der må isolere udstyr, nulstille adgang eller kontakte relevante myndigheder.
Persondata kræver en separat vurdering. Hvis leverandøren behandler personoplysninger på virksomhedens vegne, skal parterne normalt have en databehandleraftale. Datatilsynets vejledning om databehandleraftaler beskriver blandt andet krav til instrukser, sikkerhed og underleverandører. Derudover kan GDPR-forordningen på EUR-Lex bruges som den juridiske reference.
Backup skal beskrives med mere end ordet “daglig”. Aftalen bør angive:
- Hvilke data der sikkerhedskopieres
- Hvor ofte backup køres
- Hvor længe kopierne gemmes
- Hvor adskilt backupmiljøet er fra produktionen
- Hvor hurtigt data kan gendannes
- Hvor ofte gendannelse testes og dokumenteres
To begreber er særligt nyttige. RPO angiver, hvor meget data virksomheden højst må miste målt i tid. Et RPO på fire timer betyder, at man accepterer at miste op til fire timers ændringer. RTO angiver, hvor lang tid det må tage at få en tjeneste tilbage.
En backup, der aldrig er blevet testet, er en antagelse. Derfor kan aftalen indeholde formuleringen: “Leverandøren gennemfører mindst én dokumenteret gendannelsestest hvert halve år og rapporterer resultatet til kunden.”
Hvis virksomheden er omfattet af NIS2, skal kontrakten også understøtte de relevante krav til risikostyring, hændelser og leverandørforhold. Erhvervsstyrelsens information om NIS2 er et relevant sted at begynde afklaringen.
Pris, ekstraarbejde og ændringer skal stå klart
Den månedlige pris fortæller ikke hele historien. En aftale kan virke enkel, men blive dyr, hvis oprettelse af brugere, onsite-tid, projektarbejde eller akut hjælp faktureres separat.
Bed leverandøren opdele prisen i faste og variable ydelser. Den faste pris kan dække løbende support, overvågning og standardændringer. Variable ydelser kan være større installationer, flytning af kontor, gendannelse efter en hændelse eller arbejde uden for normal åbningstid.
Skriv også, hvad der kræver en godkendelse. En praktisk formulering kan være:
“Arbejde uden for aftalens scope må først påbegyndes, når kunden har godkendt et skriftligt estimat. Akutte sikkerhedshandlinger må udføres uden forhåndsgodkendelse, hvis forsinkelse kan øge skaden.”
På den måde kan leverandøren handle hurtigt under et angreb, uden at virksomheden mister kontrollen over økonomien.
Prisregulering skal have en tydelig mekanisme. Aftalen bør oplyse, hvor ofte prisen kan ændres, hvilket indeks der bruges, og hvor lang varslet er. Nye licenser eller ændringer i leverandørens egne omkostninger bør ikke give adgang til ubegrænsede prisstigninger.
Opsigelsesvilkårene fortjener samme opmærksomhed. Se efter bindingsperiode, opsigelsesvarsel og regler ved væsentlig misligholdelse. En lang bindingsperiode kan være rimelig ved større etableringsarbejde, men virksomheden skal vide, hvad den betaler for at komme ud af aftalen.
Planlæg leverandørskifte, før du får brug for det
En god aftale beskriver også, hvordan samarbejdet slutter. Det kan føles unødvendigt ved kontraktstart, men manglende exit-vilkår kan gøre et leverandørskifte langsomt og risikabelt.
Ved opsigelse bør leverandøren udlevere dokumentation, konfigurationer, administratoradgange, backupdata, licensoversigter og en liste over åbne sager. Aftalen skal angive format, tidsfrist og eventuel pris for denne hjælp.
Vær opmærksom på formuleringer som “rimelig assistance ved overgang”. Hvad der er rimeligt, kan hurtigt blive omstridt. Skriv i stedet, hvor mange timer der er inkluderet, hvilken timepris der gælder, og hvilke oplysninger leverandøren skal levere.
Virksomheden bør selv eje eller kontrollere sine domæner, administratoradgange og vigtigste abonnementer. Leverandøren kan administrere dem, men bør ikke være den eneste part med adgang. Brug navngivne kontaktpersoner og en sikker proces til opbevaring af nødadgange.
Inden underskrift kan du teste aftalen med tre konkrete scenarier: et totalt netværksnedbrud, en kompromitteret brugerkonto og en medarbejders fratrædelse. Bed leverandøren vise, hvilke punkter i kontrakten der regulerer hvert scenarie. Hvis svaret kræver lange forklaringer uden for aftalen, mangler teksten sandsynligvis præcision.
En klar aftale giver ro i den daglige drift
En IT-serviceaftale skal være et arbejdsredskab, ikke kun et juridisk bilag. Den skal gøre det nemt at finde svar på, hvad der er inkluderet, hvor hurtigt hjælpen kommer, og hvem der har ansvaret under en hændelse.
Få scope, SLA, sikkerhed, backup, pris og exit-vilkår skrevet med konkrete ord og målbare frister. Når en fejl rammer, er det den præcision, der afgør, om virksomheden bruger tiden på drift eller på at diskutere kontrakten.