Hvad skal testes først? Ledelsens prioritering ud fra forretningen

Spørgsmålet om, hvad der skal testes først, kan blive overladt til IT, fordi det lyder teknisk. Men IT kan kun svare på halvdelen. IT ved, hvilke systemer der er udsatte, og hvor opsætningen er gammel. Ledelsen ved, hvilke dele af forretningen der ikke må gå i stå, hvad der er lovet kunderne, og hvor et brud ville gøre mest skade. En god prioritering kombinerer de to. Ledelsens bidrag er at sige, hvad der betyder mest for forretningen, så IT kan oversætte det til systemer.

Hvorfor prioriteringen ikke kun er IT’s

IT ser systemerne indefra. Det er nyttigt, men det giver et bestemt blik: det system, der er sværest at drive, eller som har flest kendte problemer, kan virke vigtigst. Fra ledelsens stol kan billedet være et andet. Et lille system, som IT knap tænker over, kan være det, som hele ordrestrømmen afhænger af, eller det, der rummer de oplysninger, kunderne har betroet virksomheden.

Den britiske kodeks for bestyrelsers styring af cyberrisici, udgivet af den britiske regering og NCSC, peger på, at ledelsen bør sikre sig, at de teknologier, oplysninger og tjenester, der er afgørende for virksomhedens mål, er identificeret, prioriteret og aftalt. Det er netop den opgave, ledelsen løser, når den bidrager til testens prioritering. → Kronjuvelerne

Fem spørgsmål, ledelsen kan svare på

Ledelsen behøver ikke kende systemerne for at bidrage. Den skal svare på spørgsmål om forretningen.

Hvad tjener vi pengene på? · hvilke processer og kanaler bærer omsætningen.
Hvad har vi lovet andre? · over for kunder, samarbejdspartnere og myndigheder, både i kontrakter og i markedsføring.
Hvad må ikke stå stille? · og hvor længe kan virksomheden klare sig uden det. → Hvad står stille, hvis systemerne er nede?
Hvilke oplysninger må ikke slippe ud? · persondata, priser, tegninger, aftaler eller andet, der har værdi for andre.
Hvad er nyt? · nye forretningsområder, nye kanaler eller nye samarbejder, som endnu ikke er afprøvet. → Ny digital forretning

Svarene kan skrives på en side. De behøver ikke være præcise, men de skal være ledelsens egne og være drøftet i direktionen.

Fra forretning til systemer

Når ledelsen har svaret, er det IT’s opgave at oversætte svarene til systemer. Hvilke systemer understøtter de processer, der bærer omsætningen? Hvor ligger de oplysninger, der ikke må slippe ud? Hvilke leverandører er involveret? Oversættelsen kan vise, at flere forretningsområder hviler på de samme få systemer, og så bliver prioriteringen tydeligere. Andre gange viser den, at en vigtig proces afhænger af et system hos en leverandør, som virksomheden ikke selv kan teste uden aftale. Det er i sig selv en nyttig opdagelse for ledelsen, fordi den peger på et spørgsmål til leverandøren og måske til kontrakten. → Leverandørrisiko

IT tilføjer derefter sin egen vurdering af, hvor udsat hvert system er, og hvor meget det har ændret sig. Hvordan den tekniske del af prioriteringen kan gribes an, forklarer opslagsværket penetrationtest.dk. Det endelige forslag bør komme tilbage til ledelsen, så den kan se, om rækkefølgen svarer til det, den lagde vægt på.

Når ledelsen og IT er uenige

Det sker, at IT vil teste et område, ledelsen ikke ser som vigtigt, eller omvendt. Det er ikke et problem, men et tegn på, at de to blikke supplerer hinanden. Det modsatte ville være mere bekymrende: hvis ledelsen og IT altid er enige, er der en risiko for, at ledelsen blot godkender IT’s forslag uden at have bidraget med sit eget. Uenigheden bør løses ved at spørge, hvad der ville ske, hvis det pågældende område blev ramt. Kan IT vise, at et tilsyneladende uvæsentligt system giver adgang til noget vigtigt, bør det have prioritet. Kan ledelsen vise, at et system bærer en væsentlig del af forretningen, bør det også.

Hvis uenigheden ikke kan løses, er det ledelsen, der beslutter. Det er ledelsen, der bærer konsekvensen, og den skal kunne forklare valget over for bestyrelsen. Beslutningen og begrundelsen bør skrives ned, så den kan tages op igen. → Risikovillighed

Kundekrav og egne behov

En særlig udfordring opstår, når en kunde kræver en test af et bestemt område. Kravet kan pege et andet sted hen end ledelsens egen prioritering. Det behøver ikke være et enten eller, men ledelsen bør være bevidst om, at en test, der kun følger kundens ønske, ikke nødvendigvis dækker det, virksomheden selv har mest brug for at vide. Kundens område og ledelsens eget vigtigste område kan dækkes i samme forløb, hvis det aftales fra starten. Hvis det ikke kan, bør ledelsen vælge bevidst og notere, hvilket område der så venter til næste gang, og hvorfor. → Kundekrav eller egne behov

Et tænkt eksempel

En virksomhed, der producerer og sælger specialfødevarer, skal bestille sin første test. IT foreslår at starte med kontornettet, fordi det er stort og uoverskueligt. Direktionen svarer på de fem spørgsmål og når frem til, at omsætningen i stigende grad kommer fra en webshop, at en stor detailkunde modtager ordrer automatisk fra virksomhedens system, og at opskrifterne er virksomhedens vigtigste værdi.

IT oversætter svarene og finder, at webshoppen, ordreintegrationen og det fildrev, hvor opskrifterne ligger, bør gå forud. Kontornettet kommer med i næste runde. Direktionen godkender rækkefølgen og noterer begrundelsen i referatet. Et halvt år senere åbner virksomheden et nyt salg direkte til restauranter. Ledelsen tager de fem spørgsmål op igen og ser, at den nye kanal nu bør med i næste test, før kontornettet. Prioriteringen var ikke forkert første gang, men forretningen havde flyttet sig.

Det skal I lade være med

At overlade hele prioriteringen til IT · ledelsen ved noget, IT ikke ved.
At prioritere ud fra, hvad der er lettest at teste · det vigtigste er ikke altid det enkleste.
At svare i systemnavne · svar i forretningsprocesser, og lad IT oversætte.
At lade et kundekrav afgøre det hele · vurder også egne behov.
At glemme at skrive begrundelsen ned · så kan ingen genbesøge valget.

Hvad kan og ikke kan konkluderes

Ledelsens prioritering gør testen mere relevant for forretningen og lettere at forklare bagefter. Den sikrer ikke, at de områder, der ikke testes, er i orden. Den kan heller ikke erstatte IT’s vurdering af, hvor systemerne er mest udsatte. Prioriteringen er et valg under usikkerhed, og den bør tages op igen, når forretningen ændrer sig.

Tjekliste til prioriteringen

☐ Har direktionen svaret på de fem spørgsmål om forretningen?
☐ Har IT oversat svarene til systemer og leverandører?
☐ Er IT’s vurdering af eksponering lagt oven på?
☐ Er rækkefølgen godkendt af ledelsen, med begrundelse?
☐ Er det aftalt, hvornår prioriteringen tages op igen?

Kilder

NCSC og UK Government, Cyber Governance Code of Practice: A1 om at de teknologier, oplysninger og tjenester, der er afgørende for organisationens mål, er identificeret, prioriteret og aftalt.

Senest gennemgået: oktober 2026.