Microsoft 365 support aftale: Hvad får I reelt for pengene?

Teams kører, men ingen kan logge ind efter en ændring i Conditional Access. Microsoft 365 er ikke nede, så jeres sag bliver ikke “kritisk” hos Microsoft. I mellemtiden stopper arbejdet, og NIS2’s 24-timers rapporteringskrav tikker. En god Microsoft 365 support aftale handler derfor om drift af jeres tenant – ikke kun platformen.

• Skil platform fra tenant: Kortlæg hvad Microsoft dækker, og hvad I selv hæfter for i jeres konfiguration.
• Match SLA med forretning: Definér svartider pr. incident-type (login, mailflow, sikkerhed, møderum) og bind det i aftalen.
• Gør support til compliance: Indbyg detektion, triage og rapporteringsflow, så I kan nå NIS2 “early warning” inden 24 timer.
• Få menneskelig hjælp når det brænder: Aftal eskalering uden at blive sendt i selvhjælps-loop i Admin Center.
• Flyt fra reaktiv til proaktiv drift: Overvåg ændringer, Secure Score/Defender-signaler og backup/restore-test, så problemer fanges før brugerne gør.

Hvorfor “Microsoft support” ikke er det samme som IT-support til jeres virksomhed

Microsofts support og SLA’er er primært bygget til at holde platformen kørende. Det er relevant, når der er en bred tjeneste-fejl. Men de fleste hverdagsnedbrud i SMB’er skyldes tenant-ting: politikker, licenser, klientopsætning, Entra ID, Intune, Defender, mailflow, rettigheder og ændringer foretaget af jer selv eller en leverandør.

Praktisk tommelfingerregel

Hvis en ændring i jeres opsætning kan forklare problemet, er det tenant-support. Hvis Microsoft 365 er nede for “alle”, er det platform-support.

Før → Efter (1):
Før: “Vi køber licenser, så Microsoft fikser support.” Resultat: intern tid går med fejlsøgning og tickets, der ender i artikellinks.
Efter: “Vi køber licenser og en drift-/supportaftale til tenant.” Resultat: én indgang, tydelig eskalering, og ændringer styres og dokumenteres.

Sådan rammer I en support-SLA, der også virker under NIS2

NIS2 (Artikel 23) kræver, at væsentlige hændelser kan rapporteres med en “early warning” inden for 24 timer. Det betyder ikke, at alt skal være løst på 24 timer. Det betyder, at I skal kunne detektere, vurdere og rapportere hurtigt. Hvis jeres support setup starter med køtid, selvhjælps-bots og uklar eskalering, mister I tid dér, hvor I burde samle fakta.

Microsofts standard support har typisk begrænsninger på garanterede responstider for mindre kritiske sager, og “Severity A” handler i praksis om bred platformpåvirkning. Det er fint til store outages. Det hjælper jer ikke, hvis én fejlkonfigureret politik låser alle brugere ude.

Tjekliste: Hvad skal en Microsoft 365 support aftale indeholde i 2026?

Brug tjeklisten som beslutningsgrundlag, når I sammenligner Microsofts egen support, en intern IT-superbruger og en ekstern Managed Service Provider (MSP).

Krav i aftalen	Det skal stå sort på hvidt	Hvad I kigger efter i praksis
Scope: platform vs. tenant	Hvilke opgaver er inkluderet (Entra ID, Intune, mailflow, Teams, licenser, device onboarding, ændringsstyring)	Kan leverandøren løse “brugeren kan ikke logge ind” uden at åbne Microsoft-ticket først?
SLA pr. sagstype	Svartid og løsning/afhjælpningsmål pr. kategori (kritisk driftstop, sikkerhed, produktivitet, “how-to”)	Får I en konkret eskaleringsvej uden at vente på business hours ved driftsstop?
NIS2-beredskab	Incident-flow: detektion → triage → dokumentation → rapportering inden 24 timer	Er roller, kontaktliste og logkrav defineret? Kan I producere tidslinje og påvirkning på bestilling?
Ændringsstyring	Hvordan ændringer godkendes, testes og rulles tilbage (fx Conditional Access, mailflow-regler)	Findes der “break-glass” konti, og er rollback-procedure testet?
Overvågning og signaler	Hvilke alarmer overvåges (login-anomali, mailflow, Defender/secure score, admin-ændringer)	Får I proaktive beskeder, før brugerne ringer? Hvad er responstid uden for 8–16?
Backup & gendannelse	Hvad der backups, retention, og hvor ofte restore-test køres	Kan leverandøren dokumentere sidste restore-test og RTO/RPO-mål for jeres vigtigste data?
Dansk support og ejerskab	Kontaktkanaler, bemanding, og hvem der ejer sagen end-to-end	Kan I tale med en tekniker, der kender jeres tenant, eller starter I forfra hver gang?

Fejl der koster mest: Når oppetid bliver forvekslet med svartid

Microsoft kan levere høj oppetid på tjenesterne, og alligevel kan I stå stille. Årsagen er ofte en “selvforskyldt” fejl: en policy, en licensændring, en DNS-/mailflow-justering eller en Intune-profil, der blokerer adgang.

To klassikere, der rammer SMB’er

• Login-stop efter sikkerhedstiltag: En ny Conditional Access-regel uden korrekt undtagelse for break-glass eller servicekonti.
• Mailflow/Outlook-problemer: Ændringer i SPF/DKIM/DMARC eller connector-regler, der ikke er testet mod jeres domæner og tredjepartssystemer.

Før → Efter (2):
Før: “Vi ændrer i sikkerheden direkte i produktion.” Resultat: uforudsigelige udfald og manuel brandslukning.
Efter: “Vi kører ændringer som ændringssager med test og rollback.” Resultat: færre driftstop og hurtigere fejlfinding, fordi I har et spor af hvad der blev ændret og hvornår.

Hvordan vælger I mellem Microsoft, intern IT og en MSP?

Vælg ud fra ansvar og tid – ikke kun licenspris.

• Microsoft direkte: Godt når der er en platformfejl. Svagt når problemet handler om jeres konfiguration, devices, rettigheder eller forretningsprocesser.
• Intern IT-superbruger: Godt til små miljøer, men sårbart ved ferie/sygdom, og svært at holde styr på Entra ID, Intune og sikkerhedsovervågning ved siden af “rigtigt arbejde”.
• MSP/partner-led support: Godt når I vil have drift af tenant, proaktiv overvågning, dokumentation og en SLA, der passer til jeres risikoprofil.

Hvis I samtidig kører workloads i Azure, så aftal én ansvarlig part for både identitet, netværk og adgang. Ellers ender fejl i gråzoner. Se vores tilgang til Azure og IT-sikkerhed.

FAQ: Microsoft 365 support aftale (praktiske svar)

Hvad dækker en Microsoft 365 support aftale typisk – og hvad dækker den ikke?

Typisk dækker den platform-fejl, generelle produktproblemer og vejledning. Den dækker sjældent drift af jeres tenant: brugeroprettelse, licenser, Entra ID/Conditional Access, Intune-profiler, mailflow/DNS og governance. Hvis det er “jeres opsætning”, skal I have tenant-support via intern IT eller en partner.

Hvad er en realistisk SLA for IT support Microsoft 365 i en SMB?

Start med at opdele i sagstyper: (1) driftsstop for mange brugere, (2) sikkerhedshændelser, (3) kritisk bruger/leder, (4) almindelig support. Kræv fastlagt svartid pr. type og en eskaleringsvej. Hvis I har NIS2-krav eller høj afhængighed af Teams/Exchange, bør driftsstop og sikkerhed kunne triageres samme dag.

Hvordan hænger NIS2 krav til IT support sammen med en supportaftale?

NIS2 kræver, at I kan nå en “early warning” inden 24 timer. Aftalen skal derfor beskrive: hvem der modtager alarmer, hvem der vurderer påvirkning, hvordan I dokumenterer tidslinje, og hvem der hjælper med rapporteringsgrundlag. Uden det bliver support reaktiv og langsom, selv hvis platformen kører.

Hvorfor bliver Microsoft tickets nogle gange lukket uden løsning?

Mange sager ender i standardiserede flows med selvhjælpsartikler og first-line triage. Hvis problemet kræver kendskab til jeres miljø (policies, netværk, enheder), kan det se ud som “ikke reproducerbart” fra Microsofts side. En partner med adgang til jeres tenant kan typisk levere logs, ændringsspor og konkrete reproduktionsdata, så sagen ikke dør i første led.

Hvad skal vi spørge om, når vi sammenligner Microsoft 365 support priser?

Spørg ikke kun “hvad koster det pr. bruger”. Spørg: Hvilke opgaver er inkluderet (tenant-drift), hvor mange timer er reelt afsat, hvilke SLA’er gælder pr. sagstype, og hvad koster ændringer/projekter. Bed om eksempler på månedlig rapportering: hændelser, ændringer, og hvad der blev forebygget.

Kan vi klare os med Microsoft Business Assist eller skal vi have en MSP?

Hvis I primært har brug for generel vejledning og jeres miljø er simpelt, kan et add-on være nok. Hvis I har krav til eskalering, dokumentation, ændringsstyring, device management (Intune) eller compliance-flow (NIS2), så er en MSP-aftale mere realistisk, fordi den handler om jeres drift og ikke kun produktet.

Sådan kommer I i gang (konkrete skridt næste uge)

1. Lav en 60-minutters scope-audit: Skriv ned hvilke supportopgaver I forventer løst (brugere, licenser, Entra ID, Intune, mailflow, Teams, backup). Markér hvad der er platform vs. tenant.
2. Definér 4 sagstyper og deres SLA: Driftsstop, sikkerhed, VIP-kritisk, standard. Sæt svartid og eskalering pr. type.
3. Indfør ændringsstyring på 5 områder: Conditional Access, admin-roller, mailflow/DNS, Intune compliance, delingspolitikker. Kræv test og rollback.
4. Test NIS2-flowet: Kør en bordøvelse: “Brugerlogin stopper” eller “mistænkelig login-bølge”. Mål tid til triage og rapporteringsklart overblik.
5. Vælg ejer af tenant-driften: Enten intern rolle med backup-dækning eller en partner. Aftal månedlig driftstatus og kvartalsvis sikkerheds-/compliance-gennemgang.