Hvad IT bør rapportere til ledelsen efter testen

Når en sikkerhedstest er afsluttet, ligger der en rapport, som er skrevet til teknikere. Ledelsen har brug for noget andet: en tilbagemelding fra IT, der fortæller, hvad testen viste i forretningens sprog, hvad IT foreslår at gøre, og hvilke beslutninger ledelsen selv skal træffe. Det er ledelsens opgave at bestille den tilbagemelding, gerne før testen går i gang, så IT ved, hvad der forventes. En god tilbagemelding består af tre dele, et resumé, en plan og en liste over beslutninger, og den følges op af en kort status, indtil sagen er lukket.

Hvordan resultatet præsenteres på selve mødet, er et emne for sig. Her handler det om indholdet, som ledelsen bør kræve. → Hvordan skal resultatet præsenteres for direktionen?

Hvorfor ledelsen skal bestille tilbagemeldingen

Uden en bestilling får ledelsen enten den tekniske rapport, som den ikke kan bruge, eller en mundtlig opsummering, som ingen kan gå tilbage til. Ingen af delene giver et grundlag for at prioritere penge og tid. En bestilling behøver ikke være formel. Det er nok, at ledelsen siger, hvad den vil have, hvornår, og hvem der skal læse det. Aftal også, om testeren skal deltage, når IT fremlægger, så spørgsmål om fundene kan besvares med det samme.

Det amerikanske standardiseringsinstitut beskriver i sit Cybersecurity Framework 2.0, at ledelsen er ansvarlig for cybersikkerhedsrisikoen, og at forbedringer bør udpeges ud fra sikkerhedstest og øvelser. Rammeværket er frivilligt og amerikansk, men pointen passer til en dansk ledelse: testen er først nyttig, når resultatet bliver til forbedringer, og det kræver, at ledelsen får det i en form, den kan handle på. → Ledelsesresuméet

Første del: resuméet

Resuméet skal kunne læses af hele ledelsen på få minutter. Det bør svare på:

Hvad blev testet? · og hvad var bevidst udeladt?
Hvad er det vigtigste, testen fandt? · beskrevet som risiko for forretningen, ikke som teknisk fejl.
Hvad betyder det for os? · hvilke kunder, data eller processer er berørt?
Hvad var i orden? · det er også et resultat, og det fortæller, at tidligere indsats virker.
Hvad overraskede? · både positivt og negativt.

Det er IT’s opgave at oversætte. Testerens resumé kan være et godt udgangspunkt, men IT kender virksomheden og kan sætte fundene i forhold til forretningen på en måde, en ekstern tester ikke altid kan. → Fra teknisk fund til forretningsrisiko

Anden del: planen

Planen viser, hvad IT foreslår at gøre ved fundene.

Hvad rettes først? · og hvorfor netop det?
Hvem gør det? · IT selv, en leverandør eller en tredjepart?
Hvornår forventes det at være på plads? · med en realistisk dato frem for en ønskedato.
Hvad kræver det? · tid, penge eller beslutninger fra andre afdelinger.
Hvordan kontrolleres det, at rettelsen virker? · en rettelse, ingen har kontrolleret, er en antagelse.

Planen behøver ikke være lang. Det vigtige er, at hvert væsentligt fund har en ejer og en dato. Hvis noget ikke kan rettes, skal det fremgå, og det fører direkte til næste del. Ledelsen bør også se, hvordan planen hænger sammen med IT’s øvrige opgaver. En plan, der lægges oven i et fuldt program, vil skride, medmindre noget andet flyttes. Det er bedre at få det at vide nu end ved første status.

Tredje del: beslutningerne

Nogle fund kan IT ikke selv afgøre, hvad der skal ske med. Det gælder fx, når en rettelse koster mere end budgettet, når den kræver ændringer i forretningens måde at arbejde på, eller når et fund ikke kan rettes, og risikoen må accepteres for en tid.

Tilbagemeldingen bør samle de beslutninger, ledelsen skal træffe, i en kort liste med IT’s anbefaling til hver. Det gør det let at sætte dem på dagsordenen og at skrive i referatet, hvad der blev besluttet. En risiko, ledelsen har accepteret, bør stå med navn på den, der accepterede, og en dato for, hvornår den tages op igen. Hvis IT og ledelsen er uenige om en beslutning, bør uenigheden også fremgå. Det er bedre, at den står sort på hvidt, end at den dukker op igen, når en kunde eller revisor spørger.

Løbende status, indtil sagen er lukket

Efter den første tilbagemelding har ledelsen brug for en kort status med faste mellemrum. Rammeværket beskriver også, at organisationen løbende bør evaluere og justere sin håndtering af cyberrisici. En status efter en test er en enkel måde at gøre det på.

Status bør vise, hvad der er rettet og kontrolleret, hvad der er forsinket og hvorfor, og om der er kommet nye beslutninger til. Når det sidste væsentlige fund er rettet eller accepteret, bør IT melde det, så ledelsen kan lukke sagen. → Status på rettelserne

Et tænkt eksempel

En regnskabsvirksomhed med tre kontorer har fået testet sin klientportal og fjernadgangen for medarbejderne. Før testen bad partnerkredsen IT-chefen om en tilbagemelding på højst to sider inden for tre uger efter rapporten.

Tilbagemeldingen beskriver i et kort afsnit, at portalen holdt, men at fjernadgangen kunne misbruges, hvis en medarbejders adgangskode kom i forkerte hænder. Planen viser tre rettelser med ejer og dato. Under beslutninger står én: om alle medarbejdere skal bruge en ekstra bekræftelse ved login, også partnerne, som har bedt om at slippe. Partnerkredsen beslutter, at reglen gælder alle, og beder om status på næste partnermøde. Beslutningen står i referatet, så den ikke skal tages igen, når den første partner klager over besværet.

Det skal I lade være med

At nøjes med den tekniske rapport · bed om en tilbagemelding skrevet til jer.
At bestille tilbagemeldingen, efter rapporten er kommet · aftal formen på forhånd.
At lade beslutningerne ligge gemt i teksten · bed om dem samlet.
At glemme det, der var i orden · det er også ledelsesinformation.
At stoppe opfølgningen efter første møde · aftal en status, indtil sagen er lukket.

Hvad kan og ikke kan konkluderes

En god tilbagemelding giver ledelsen et grundlag for at prioritere, træffe de beslutninger, der hører til ledelsen, og følge op. Den kan ikke gøre fundene mindre alvorlige, og den kan ikke erstatte kontrol af, at rettelserne virker. Den er heller ikke bedre end de oplysninger, IT har fået fra testen. Hvis testen var smal, bliver tilbagemeldingen det også, og ledelsen bør huske det, når resultatet bruges over for bestyrelse eller kunder. → Hvornår kan ledelsen betragte testen som afsluttet?

Tjekliste til tilbagemeldingen

☐ Har vi aftalt form og frist, før testen gik i gang?
☐ Er resuméet skrevet i forretningens sprog?
☐ Har hvert væsentligt fund en ejer og en dato?
☐ Er ledelsens beslutninger samlet med IT’s anbefaling?
☐ Er der aftalt en løbende status, indtil sagen er lukket?

Kilder

NIST Cybersecurity Framework 2.0 (februar 2024): GV.RR-01 (ledelsen er ansvarlig for cybersikkerhedsrisikoen), GV.OV-03 (håndteringen evalueres og justeres) og ID.IM-02 (forbedringer udpeges ud fra sikkerhedstest og øvelser).

Senest gennemgået: oktober 2026.