Indhold i en IT serviceaftale: Tjekliste til drift og support

Hvis jeres IT virker, lægger man ikke mærke til det. Men når mailen går ned, en bruger låses ude, eller en opdatering vælter et system, bliver det pludselig tydeligt, hvor meget forretningen hænger på, at nogen har styr på driften.

En IT serviceaftale er i praksis en forventningsaftale. Den handler om, hvad I får hjælp til, hvor hurtigt I får den, hvem der gør hvad, og hvad det koster, når noget ikke er “standard”.

Her får I en konkret tjekliste til drift og support, som I kan bruge før I skriver under, eller når aftalen skal fornyes. Målet er simpelt: færre misforståelser, mindre nedetid og færre diskussioner om regninger bagefter.

Hvad skal en IT serviceaftale dække, så drift og support ikke bliver uklart?

Mange aftaler fejler ikke på teknikken, men på sproget. Drift bliver blandet sammen med support, og pludselig er det uklart, om leverandøren “holder systemerne kørende” eller “hjælper, når noget er gået galt”.

• er det forebyggende arbejde: overvågning, opdateringer, vedligehold, kapacitetsstyring og dokumentation.

• er hjælpen her og nu: brugerhenvendelser, fejlretning, gendannelse og vejledning.

En god aftale beskriver begge dele tydeligt. Brug den her mini tjekliste som en hurtig temperaturmåling:

• Står der en (hvad er omfattet)?

• Er fordelt mellem jer og leverandøren?

• Er der en med prioritering og mål for tider?

• Er beskrevet med test og ansvar?

• Er (MFA, adgang, patching, hændelser) med som faste punkter?

• Er skrevet så en ikke-teknisk kan forstå det?

Når de punkter er klare, er resten meget lettere at få på plads.

Parter, omfang og systemliste, hvad er med, og hvad er ikke med?

Start med det kedelige, fordi det er her mange aftaler glider. Der skal stå, hvem aftalen er mellem, og hvem man kontakter.

Det bør som minimum være:

• Virksomhedsnavn og for begge parter

• Daglige kontaktpersoner (fx IT-ansvarlig hos jer og kundeansvarlig hos leverandøren)

• (hvem ringer man til, hvis sagen kører fast, eller er kritisk?)

Dernæst kommer det vigtigste: scope, altså hvad aftalen dækker.

En systemliste behøver ikke være lang, men den skal være konkret. Typiske områder for SMB er:

• Pc’er og evt. firmatelefoner

• Servere (hvis I har dem) og/eller cloud-platforme

• Netværk, firewall, WiFi og switch

• Microsoft 365, mail, identitet og adgang (fx MFA)

• Backup-løsning og gendannelse

• Endpoint protection (antivirus eller EDR)

• Printere (hvis de er forretningskritiske)

Lige så vigtigt er “ikke med”-listen. Den virker hård, men den sparer jer for konflikter. Afklar fx:

• Tredjepartsleverandører (økonomisystem, produktion, brancheløsninger)

• Specialsystemer der kræver certificerede konsulenter

• Hjemmeudstyr og private routere

• Private telefoner (BYOD), hvis I ikke vil supportere dem

• Nyudvikling og større ændringer (ofte projekter, ikke drift)

Tænk på scope som stregen på et fodboldmål. Når den står tydeligt, bliver der færre diskussioner om, hvor bolden var inde.

Roller og ansvar, hvem gør hvad i hverdagen og ved fejl?

Uklart ansvar giver to klassiske problemer: langsommere løsning og flere timer på fakturaen.

Det hjælper at tænke som en enkel ansvarsmatrix, uden at gøre det tungt.

Leverandørens typiske ansvar kan være:

• Overvågning af kritiske systemer og alarmer

• Patching af operativsystem og udvalgte apps

• Backup-kontrol (at jobs kører, og alarmer bliver håndteret)

• Standard brugeradministration (nye brugere, adgang, grupper)

• Dokumentation af opsætning og ændringer

Jeres typiske ansvar bør også stå:

• Sikre adgang til udstyr og systemer (nøgler, admin-adgang, godkendelser)

• Godkende større ændringer (fx opgraderinger, nye sikkerhedskrav)

• Betale og eje licenser, hvis modellen kræver det

• Udpege superbrugere og interne kontaktveje

• Melde ændringer i god tid (nye medarbejdere, flytning, ny lokation)

Skriv også, hvad der sker, når ansvaret overlapper. Fx: Hvis Microsoft 365 har driftproblemer, hvem kommunikerer til medarbejderne, og hvem følger op over for Microsoft? Det lyder som en detalje, men det er her, friktionen opstår.

SLA og supportvilkår: Sådan sikrer du hurtig hjælp og målbar kvalitet

En SLA gør aftalen målbar. Uden mål er “hurtigt” bare en følelse.

De fleste SLA’er kan forklares i hverdagsdansk:

• : Hvornår kan I få hjælp (åbningstid, vagtordning)?

• : Hvor hurtigt nogen reagerer og tager ejerskab på sagen.

• : Hvornår problemet forventes løst, eller der er en plan og en midlertidig løsning.

I januar 2026 ser mange SMB-aftaler også mere fokus på sikkerhed og cloud-drift, og flere leverandører bruger automatisering og AI-baseret overvågning til at opdage trusler tidligere. Det ændrer ikke jeres behov: I skal stadig kunne se, hvad I får, og hvad der måles på.

Svartider, løsningstider og prioritering, hvad er realistisk for din forretning?

Prioritering er hjertet i en SLA. Hvis alt er kritisk, er intet kritisk.

Her er en enkel model, som mange SMB kan spejle sig i. Brug den som udgangspunkt og få den tilpasset jeres drift.

To detaljer bliver ofte glemt, men de afgør om SLA’en virker i praksis:

1. Det bør ske i et ticketsystem med tidsstempler (oprettet, påbegyndt, løst).

2. Hvis I ikke kan give adgang, eller brugeren ikke kan teste, bør det fremgå, om sagen sættes på pause.

Det er ikke for at “vinde” en diskussion, men for at undgå, at begge parter føler sig snydt.

Supportkanaler, åbningstider og eskalation, hvad gør du kl. 10 og kl. 22?

I en travl hverdag skal det være nemt at få hjælp. Derfor bør aftalen beskrive, hvordan man kontakter support, og hvad der tæller som akut.

Typiske kanaler:

• Telefon til akutte sager

• Mail til mindre presserende sager

• Ticket-portal til struktur, historik og rapporter

Skriv også, hvad der gælder uden for kontortid. Nogle virksomheder har ikke brug for vagtordning, andre har, især hvis de sælger online, kører produktion, eller arbejder på tværs af tidszoner.

Afklar i samme omgang:

• Hvornår support er åben, og hvornår der er vagt

• Hvordan “akut” defineres (fx driftstop, sikkerhedshændelse)

• Hvornår onsite kan forventes, og hvad det koster

• Eskalation (1st line, 2nd line, 3rd line), og hvornår en sag sendes videre til specialist eller tredjepart

Det er som at have et brandnummer. Man håber ikke at bruge det, men man vil ikke stå og lede efter det i en krise.

Drift, sikkerhed og compliance: De punkter der forebygger nedbrud og dyre hændelser

Drift er de små ting, der bliver gjort i tide, så de store ting ikke sker. Sikkerhed er det samme, bare med endnu højere konsekvens, hvis man springer over.

I januar 2026 fylder sikkerhed typisk mere i serviceaftaler end for få år siden. Det skyldes både flere angreb, mere cloud-brug og større krav til dokumentation. Mange SMB’er vil også have klarhed over, om leverandøren kan hjælpe ved hændelser og rapportering.

Derudover bør aftalen forholde sig overordnet til compliance:

• : Er leverandøren databehandler? Er der en databehandleraftale (DPA)? Hvordan håndteres brud og dokumentation?

• : Hvis I har krav til opbevaring af bilag, mail eller dokumenter, kan det påvirke backup, retention og adgangsstyring. Det er ikke jura, men noget der bør afklares i praksis.

Backup og gendannelse: RPO, RTO, test og ansvar ved datatab

Backup lyder simpelt, indtil man står og mangler data. Derfor bør aftalen bruge to begreber, forklaret i almindelige ord:

• (hvor meget data må I miste?): Hvis I kan leve med at miste 2 timer, skal der tages backup ofte nok til det.

• (hvor hurtigt skal I være kørende igen?): Hvis I skal være