Jeres IT-leverandør lover 24/7 support. Men hvad sker der reelt, når jeres ERP-system går ned fredag kl. 22? Hvis svaret gemmer sig bag formuleringen “best effort” i kontrakten, har I et problem. Denne tjekliste giver jer de konkrete punkter, I skal gennemgå for at sikre, at jeres IT-support SLA faktisk beskytter forretningen – ikke bare leverandøren.

Det vigtigste fra artiklen

• “Best effort” er ikke en garanti. Kræv definerede svartider og løsningstider for hver prioritet (P1–P4) – også uden for normal åbningstid.
• Skelne mellem helpdesk og beredskab. 24/7 IT-support kan betyde alt fra password-nulstilling til kritisk nedbrudshåndtering. Afklar præcis, hvad der er dækket hvornår.
• NIS2 kræver dokumenterede svartider. Med 24-timers rapporteringskravet er “vi vender tilbage mandag” ikke længere en mulighed for sikkerhedshændelser.
• Mål på forretningspåvirkning, ikke lukkede tickets. En god SLA fokuserer på, hvor hurtigt jeres medarbejdere kan arbejde igen – ikke hvor mange sager der lukkes.
• Gennemgå kontrakten mindst én gang årligt. Jeres IT-miljø ændrer sig. Det bør SLA’en også.

Hvorfor “24/7 support” ikke betyder det samme hos alle leverandører

Mange danske IT-leverandører markedsfører 24/7 support. Få af dem specificerer, hvad det dækker. Hos nogle betyder det en vagttelefon, der viderestiller til en tekniker med op til fire timers responstid. Hos andre betyder det automatiseret overvågning, der reagerer på kritiske alarmer inden for 15 minutter.

Forskellen er afgørende for jer som virksomhed. Hvis jeres Microsoft 365-miljø rammes af en sikkerhedshændelse lørdag nat, er fire timers ventetid ikke acceptabelt. Ifølge Identity Theft Resource Center (2025) oplevede 81 % af små virksomheder et sikkerhedsbrud i 2024/2025. Angreb sker ikke kun i kontortiden.

Før: I har en SLA, der lover “hurtig respons” uden definerede tidsrammer. En kritisk hændelse fredag aften bliver først håndteret mandag morgen.
Efter: Jeres SLA specificerer P1-respons inden 15 minutter døgnet rundt. Nedbruddet fredag aften er løst inden midnat, og jeres medarbejdere mærker det aldrig.

Hvad betyder P1, P2, P3 og P4 i en IT-support SLA?

Prioritetsniveauer er rygraden i enhver SLA. Uden dem behandles et nedbrud i jeres økonomisystem på samme måde som en printer, der ikke virker. Her er den struktur, I bør kræve:

Prioritet	Definition	Responstid	Løsningstid
P1 – Kritisk	Forretningen er stoppet. Alle eller mange brugere påvirket. Sikkerhedsbrud.	≤ 15 min (24/7)	≤ 4 timer
P2 – Høj	Væsentlig funktion nede. Workaround mulig, men begrænset.	≤ 30 min (24/7)	≤ 8 timer
P3 – Normal	Enkeltbruger påvirket. Workaround tilgængelig.	≤ 2 timer (åbningstid)	≤ 24 timer
P4 – Lav	Kosmetisk fejl, ønske om ændring, spørgsmål.	≤ 8 timer (åbningstid)	Planlagt

Bemærk forskellen på responstid og løsningstid. Responstid er, hvornår en tekniker aktivt arbejder på sagen. Løsningstid er, hvornår problemet er afhjulpet. Mange kontrakter specificerer kun responstid – og den kan blot være en automatisk kvittering pr. e-mail.

Tjekliste: 9 punkter I skal gennemgå i jeres IT-support SLA

Brug denne tjekliste til at auditere jeres nuværende kontrakt. Hvert punkt, I ikke kan svare “ja” til, er en potentiel risiko.

1. Er P1–P4 defineret med klare kriterier? Tjek at prioriteterne er beskrevet med forretningspåvirkning – ikke kun tekniske termer.
2. Er responstid OG løsningstid specificeret for hver prioritet? Hvis kun responstid er nævnt, har I ingen garanti for, hvornår problemet løses.
3. Gælder SLA’en 24/7 for P1 og P2? Mange aftaler gælder kun i åbningstiden. Verificér, at kritiske hændelser dækkes døgnet rundt.
4. Er der en eskalationsprocedure? Hvem kontaktes, hvis første tekniker ikke løser P1 inden for tidsrammen? Dokumentér navne og telefonnumre.
5. Dækker SLA’en sikkerhedshændelser specifikt? Et ransomware-angreb kræver en anden respons end et netværksnedbrud. Sikkerhedshændelser bør have en separat procedure – gerne koblet til MDR/SOC-overvågning.
6. Er der konsekvenser ved SLA-brud? Uden bod eller kompensation er SLA’en reelt uforpligtende for leverandøren.
7. Måles og rapporteres SLA-overholdelse? Kræv månedlige rapporter med faktiske svartider og løsningstider.
8. Er SLA’en tilpasset jeres cloud-miljø? Microsofts egne SLA’er for Azure og Microsoft 365 dækker kun platformens oppetid – ikke jeres konfiguration, brugerfejl eller integrationer.
9. Revideres SLA’en årligt? Jeres forretning vokser. Nye systemer, flere brugere og NIS2-krav ændrer behovet.

Fejl der koster: Tre SLA-fælder danske SMV’er falder i

1. “Best effort” uden tidsgaranti

Formuleringen “vi bestræber os på at svare hurtigt” er juridisk set ingen forpligtelse. Kræv altid konkrete tidsangivelser i minutter eller timer.

2. SLA der kun gælder i åbningstiden

Cyberhændelser følger ikke kontortider. Guardz’ Mid-Year Findings (2025) viser, at SMV’er oplevede næsten en fordobling af ugentlige cyberhændelser. Mange af dem sker uden for 8–16. Hvis jeres SLA kun dækker hverdage, står I uden garanti, når det virkelig gælder.

3. Ingen kobling mellem drift og sikkerhed

Før: Jeres helpdesk håndterer alle henvendelser ens – et phishing-angreb behandles som en almindelig support-ticket og venter i kø.
Efter: Sikkerhedshændelser eskaleres automatisk til et dedikeret beredskab med direkte adgang til Microsoft Defender XDR, og truslen isoleres inden for minutter.

En IT-supporter kan nulstille passwords. Men at stoppe et aktivt ransomware-angreb kræver specialiseret sikkerhedsovervågning. Sørg for, at jeres SLA adskiller driftssupport fra sikkerhedsberedskab.

Sådan kobler I SLA til NIS2-krav

NIS2-direktivet kræver, at virksomheder rapporterer sikkerhedshændelser inden for 24 timer. Det stiller konkrete krav til jeres IT-support SLA:

• Detektionstid: Hvor hurtigt opdager jeres leverandør en hændelse? Uden 24/7 overvågning kan der gå timer, før nogen reagerer.
• Eskalationstid: Hvor hurtigt informeres jeres ledelse og de relevante myndigheder?
• Dokumentation: Logges alle handlinger, så I kan dokumentere forløbet over for tilsynsmyndigheder?

NIST Cybersecurity Framework 2.0 (2024) skærper fokus på “Continuous Monitoring” og “Respond” – og anbefaler reelt 24/7 beredskab for alle internetvendte systemer. Jeres SLA bør afspejle dette med specifikke tidsrammer for detektion, eskalation og rapportering af sikkerhedshændelser.

Ofte stillede spørgsmål om IT-support SLA

Hvad er en god SLA for IT-support?

En god SLA definerer P1–P4-prioriteter med konkrete svartider og løsningstider. For kritiske hændelser (P1) bør responstiden være maks 15 minutter – også uden for åbningstid. Kræv altid målbare tidsgarantier, ikke “best effort”.

Hvad koster 24/7 IT-support for en dansk SMV?

Prisen afhænger af antal brugere, systemer og SLA-niveau. Typisk ligger en managed service-aftale med 24/7 beredskab for kritiske hændelser mellem 300–800 kr. pr. bruger pr. måned. Sammenlign det med omkostningen ved blot én times nedetid for hele virksomheden.

Hvad er forskellen på responstid og løsningstid?

Responstid er tiden fra I melder fejlen, til en tekniker aktivt arbejder på den. Løsningstid er tiden, til problemet er afhjulpet. Mange leverandører angiver kun responstid – og den kan blot være en automatisk e-mailkvittering. Kræv begge dele i kontrakten.

Hvordan måler vi, om vores IT-leverandør overholder SLA’en?

Kræv månedlige SLA-rapporter med faktiske respons- og løsningstider pr. prioritet. Brug jeres ticketsystem til at verificere tallene. Hvis leverandøren ikke kan levere rapporterne, er det et advarselstegn.

Skal vores SLA dække sikkerhedshændelser separat?

Ja. Et ransomware-angreb kræver en fundamentalt anden respons end en printerfejl. Sikkerhedshændelser bør have en dedikeret eskalationsvej med kortere svartider og direkte adgang til sikkerhedsspecialister – ikke kun en generel helpdesk.

Hvad sker der, hvis leverandøren bryder SLA’en?

Det afhænger af kontrakten. Uden en bod- eller kompensationsklausul har I ingen reel sikkerhed. Forhandl en konkret konsekvens – fx reduktion i månedlig betaling – ved gentagne SLA-brud.

Hvordan hænger SLA sammen med NIS2-compliance?

NIS2 kræver 24-timers rapportering af sikkerhedshændelser. Jeres SLA skal sikre, at leverandøren kan detektere, eskalere og dokumentere hændelser inden for den tidsramme. Uden det risikerer I bøder og manglende compliance.

Tre skridt I kan tage i denne uge

1. Find jeres nuværende SLA-dokument. Gennemgå det med tjeklisten ovenfor. Markér hvert punkt, I ikke kan svare “ja” til, og send listen til jeres leverandør med krav om afklaring.
2. Kortlæg jeres kritiske systemer. Identificér de 3–5 systemer, hvor nedetid stopper forretningen (typisk ERP, e-mail, CRM). Sørg for, at netop disse systemer har P1-dækning 24/7.
3. Book en SLA-gennemgang. Invitér jeres IT-leverandør til et møde, hvor I gennemgår prioriteter, svartider og eskalationsprocedurer. Hvis leverandøren ikke vil stille op til den samtale, har I jeres svar. Vi tager gerne den snak med jer.