En mail fra kunden fortæller, at en ekstern tester skal afprøve netværket, serverne og Microsoft 365-lejeren om tre uger. Det er kundens test, men det er jeres drift, der bliver målt, og jeres medarbejdere, der skal svare, når testeren spørger eller noget går galt. MSP’ens opgave er at gøre testen mulig og retvisende uden at blive dens bestiller, og det hviler på tre ting: en klar fordeling af, hvad der er kundens, hvad der er jeres, og hvad der er delt; en aftalt kontaktvej i hele testperioden; og en plan for, hvordan fundene håndteres bagefter.
Testen er en lejlighed til at vise, at driften holder. Den er også en lejlighed til at få øje på det, I selv har overset. Begge dele kræver, at I går ind i forløbet som samarbejdspartner og ikke som part, der skal forsvares.
Første skridt: læs bestillingen
Bed kunden om opgavebeskrivelsen, så snart I hører om testen. Den viser, hvad testeren må, og hvor I skal være forberedt. Se især efter:
- Systemer og adresser · hvilke servere, net, lejere og webløsninger testen omfatter.
- Testform · om testeren arbejder udefra, indefra med en udleveret maskine eller med testkonti i lejeren.
- Tidsrum · dage og klokkeslæt, og om der testes uden for arbejdstid.
- Kontakter · hvem hos kunden og hos testeren der kan træffe beslutninger undervejs.
Står der noget i beskrivelsen, som ikke passer med det, I drifter, så sig det nu. En server, der er udfaset, eller en firewall, som en anden leverandør passer, skal rettes i beskrivelsen før start, ikke opdages i rapporten. → Netværkstegning og systemoversigt
Hvad der er jeres, og hvad der er delt
Det sværeste spørgsmål ved en kundes test behøver ikke være teknisk. Det handler om ejerskab. Kundens servere og lejer er kundens. Men jeres fjernstyringsagent på serverne, jeres overvågning og den platform, I deler mellem flere kunder, er jeres eller fælles.
Kunden kan give tilladelse til test af sit eget miljø. Kunden kan ikke give tilladelse til test af jeres platform eller af andre kunders data. Hvis testen kommer tæt på noget delt, skal grænsen skrives ind, før testen begynder. Hvad I skal kræve af testeren i den forbindelse, er beskrevet særskilt. → MSP’ens godkendelse af testen
Den fælles anbefaling fra NCSC (UK), CISA og flere andre myndigheder til MSP’er og deres kunder lægger vægt på, at kontrakten tydeligt fordeler ansvaret mellem leverandør og kunde. En kundes test viser hurtigt, om jeres aftale gør det.
Det, I skal have klar
Arbejdslisten minder om den, en IT-afdeling selv har, men med jeres ekstra rolle som den, der kender de tekniske detaljer.
- Kontaktperson · en navngiven tekniker med stedfortræder, som kan nås i hele testperioden. → Kontaktpersonen i IT under testen
- Testkonti · oprettes efter kundens ønske og med de rettigheder, bestillingen angiver. Registrer dem, så de kan lukkes bagefter.
- Gendannelsespunkt · en frisk og kontrolleret backup af de systemer, testen rører.
- Overvågningen · jeres driftscentral og sikkerhedsovervågning skal vide, hvad der er aftalt om alarmer.
- Ændringsstop · undgå større opdateringer og omlægninger i testvinduet, så resultatet afspejler en kendt tilstand.
Alarmerne hos jer
Hvis I leverer overvågning til kunden, vil testen kunne udløse jeres alarmer. Det er et af de punkter, hvor jeres og kundens interesser skal afstemmes. Kunden kan ønske at se, om overvågningen opdager testen. Så må kun få hos jer kende tidspunktet, og der skal være en aftalt vej til at stoppe en eskalering. Ønsker kunden det ikke, skal vagten informeres, så den ikke ringer til kundens direktør om et angreb, der er aftalt. → Alarmer under testen
Uanset valget skal jeres reaktion noteres. Hvad opdagede I, hvornår, og hvad gjorde I? Den log er værdifuld for kunden og for jer selv.
Under testen
Jeres tekniker er bindeleddet, når noget opfører sig anderledes end forventet. Det kan være en låst konto, en tjeneste, der svarer langsomt, eller en bruger, der ringer til servicedesken. Aftal med kunden, hvem der beslutter at stoppe testen, og hvordan testeren bliver informeret. Det skal ikke være jeres tekniker alene, for testen er kundens.
Svar på testerens spørgsmål sagligt og fuldstændigt. Det er fristende at rette et fund i løbet af testen, når man ser det komme. Lad være, medmindre kunden beder om det, eller fundet er akut. En stille rettelse midt i testen gør rapporten upræcis, og kunden mister overblikket over, hvad der faktisk blev fundet.
Før jeres egen log over testperioden: hvem hos jer blev kontaktet, hvilke henvendelser kom ind fra kundens brugere, og hvilke driftshændelser fandt sted. Når rapporten kommer, kan I holde fundene op mod loggen og skelne testens spor fra almindelige fejl.
Efter testen
Når testeren melder færdig, er der tre opgaver hos jer. Først oprydningen: testkonti, undtagelser og eventuelle filer fra testeren skal fjernes efter en liste. → Oprydning efter testen
Dernæst rapporten. Kunden er modtager og afgør, hvad I får at se. Bed om de dele, der vedrører jeres drift, og om at blive inviteret til gennemgangen, så I kan spørge testeren direkte.
Til sidst rettelserne. Nogle fund ligger inden for driftsaftalen, andre er nye opgaver, og enkelte ligger hos andre leverandører. Den fordeling skal laves sammen med kunden og skrives ned. → Rettelser efter kundens test
Det skal I lade være med
- At give tilladelse på kundens vegne · testen er kundens beslutning, og kunden underskriver.
- At lade testen nå jeres fælles platform uden aftale · det kræver jeres egen godkendelse.
- At rette i stilhed undervejs · fundet forsvinder fra rapporten, men årsagen består.
- At skjule jeres egne alarmer · kunden skal vide, hvad overvågningen så.
- At glemme testkontiene · en konto, der lever videre efter testen, er et nyt fund.
- At tage rapporten personligt · fundene handler om opsætning og proces, ikke om enkeltpersoner.
Hvad kan og ikke kan konkluderes
En kundes test viser, hvordan kundens miljø holdt i testperioden og fra de udgangspunkter, testeren havde. Den siger noget om jeres drift hos netop den kunde. Den siger ikke noget om jeres platform som helhed eller om andre kunders miljøer. Et resultat uden alvorlige fund er ikke en godkendelse af jer som leverandør, og et alvorligt fund er ikke i sig selv et brud på aftalen.
Tjekliste, når kunden har bestilt en test
- ☐ Har I fået og læst opgavebeskrivelsen?
- ☐ Er det skrevet ned, hvad der er kundens, jeres og delt?
- ☐ Er der en navngiven kontaktperson med stedfortræder?
- ☐ Er testkonti oprettet og registreret?
- ☐ Er der en kontrolleret backup?
- ☐ Er det aftalt, hvordan jeres overvågning skal reagere?
- ☐ Er det aftalt, hvem der kan stoppe testen?
- ☐ Er der en plan for oprydning og fordeling af rettelser?
Kilder
- NCSC (UK), CISA, NSA, FBI m.fl.: Protecting Against Cyber Threats to Managed Service Providers and their Customers (AA22-131A): fælles anbefaling til MSP’er og kunder om bl.a. kontrakter, der tydeligt fordeler ansvaret, og logning efter aftale.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: MSP og penetrationstest · Beredskab under testen
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
