Spørgsmål, direktionen bør stille IT‑chefen om sikkerhedstest

Direktionen kan ikke altid selv vurdere, om virksomhedens systemer holder, men den kan vurdere, om IT-chefen har et ordentligt grundlag for at sige det. Det kræver ingen teknisk viden, kun de rigtige spørgsmål og vilje til at følge svarene. Spørgsmålene falder i fire grupper: hvad der er undersøgt, hvornår det sidst skete, hvad der kom ud af det, og hvem der har ansvaret for resten. Får direktionen klare svar på de fire, har den et billede, den kan stå inde for. Får den uklare svar, ved den, hvor arbejdet skal sættes ind.

Formålet er ikke at eksaminere IT-chefen. Det er at give direktionen et grundlag, som den kan bruge over for bestyrelsen, kunder og samarbejdspartnere.

Hvorfor spørgsmålene hører til direktionen

En pjece på sikkerdigital.dk om toplederens ansvar sammenfatter risikostyring som det at stille spørgsmålene og handle på svarene. Pjecen er skrevet til offentlige myndigheder, men tanken gælder enhver direktion: ansvaret for, at risikoen er kendt og håndteret, kan ikke uddelegeres til den, der driver systemerne.

IT-chefen kender systemerne. Direktionen kender forretningen. Spørgsmålene er det sted, hvor de to former for viden mødes, og hvor direktionen kan se, om IT’s prioriteter passer til det, virksomheden lever af. → Ledelsens ansvar for IT-sikkerhed

Spørgsmål om dækning

Den første gruppe handler om, hvad der faktisk er undersøgt, og hvad der ikke er.

Hvilke systemer er testet udefra? · og er det dem, forretningen er mest afhængig af?
Hvad er bevidst holdt uden for? · og hvorfor? Et fravalg er i orden, når det er begrundet.
Hvem har testet? · en ekstern part, en leverandør eller IT selv?
Hvad med de systemer, leverandører driver? · er de med, eller antager vi, at leverandøren tager sig af det?

Svarene viser, om der er områder, ingen har kigget på. Det kan være her, de største overraskelser ligger. Bed gerne IT-chefen om at vise svaret som en enkel oversigt over systemerne med en markering af, hvad der er testet, og hvad der ikke er. En sådan oversigt er let at tage med til bestyrelsen, og den gør det tydeligt, hvis det, forretningen lever af, ligger i den grå zone, som ingen har undersøgt. → Kronjuvelerne

Spørgsmål om tidspunktet

Den anden gruppe handler om, hvor gammelt billedet er.

Hvornår blev der sidst testet? · og hvad er ændret siden?
Er der kommet nye systemer, nye leverandører eller nye måder at arbejde på? · ændringer kan gøre et resultat forældet.
Hvad ville få IT til at anbefale en ny test? · det siger noget om, hvordan IT tænker om risiko.

En test er et øjebliksbillede. Jo mere virksomheden har ændret sig siden, jo mindre fortæller det gamle resultat om i dag. Direktionen behøver ikke afgøre, hvor ofte der skal testes, men den bør vide, hvem der afgør det, og efter hvilke kriterier. → Hvem bestemmer, hvor ofte vi tester?

Spørgsmål om opfølgning

Den tredje gruppe kan være den mest afslørende, fordi den viser, om testen førte til noget.

Hvad blev fundet sidst? · i store træk og i forretningssprog, ikke i tekniske betegnelser.
Hvad er rettet, og hvad er ikke? · og er de åbne punkter accepteret af nogen, der må acceptere dem?
Er rettelserne kontrolleret? · eller regner vi med, at de virker?
Kom de samme problemer igen ved næste test? · gentagelser tyder på en årsag, der ikke er løst.

Hvis svaret er, at rapporten ligger i en mappe, men at ingen har fulgt op, er det et vigtigt svar. Det betyder ikke, at IT har svigtet. Det kan lige så godt betyde, at der ikke var afsat tid eller penge til at rette. → Bliver fundene rettet?

Spørgsmål om ansvar

Den fjerde gruppe handler om, hvem der bærer hvad.

Hvem ejer sikkerhedstesten i dag? · IT-chefen, en leverandør eller ingen bestemt?
Hvem kan acceptere en risiko på virksomhedens vegne? · og er det skrevet ned?
Hvad har IT brug for fra direktionen? · tid, penge, beslutninger eller opbakning over for andre afdelinger?

Det sidste spørgsmål er vigtigt. Det britiske NCSC skriver i sine spørgsmål til bestyrelser, at det er et tegn på, at der skal arbejdes med strukturen, hvis ledelsen har svært ved at pege på, hvor ansvaret ligger. Spørgsmålet om, hvad IT har brug for, gør samtalen gensidig og giver IT-chefen mulighed for at sige, hvad der mangler. → Hvem i ledelsen skal eje sikkerhedstesten?

Et tænkt eksempel

Direktøren i en grossistvirksomhed med lager og webshop beslutter at stille IT-chefen de fire grupper af spørgsmål på et ledelsesmøde. Svarene er ærlige. Webshoppen blev testet for to år siden. Lagerstyringen, som en leverandør driver, er aldrig testet. Tre fund fra sidste test står stadig åbne, fordi de krævede en opdatering, leverandøren ikke har prioriteret.

Ingen af svarene er katastrofale. Tilsammen giver de direktøren noget, der ikke var der før: en liste over, hvad der mangler, og hvem der skal handle. Direktøren beder IT-chefen om et forslag til en test af lagerstyringen og tager selv kontakt til leverandøren om de åbne punkter. På næste ledelsesmøde er spørgsmålene sat på dagsordenen igen, så status kan følges uden at nogen skal huske at spørge. IT-chefen siger bagefter, at det var første gang, de åbne punkter hos leverandøren fik opmærksomhed fra direktionen, og at det i sig selv fik tingene til at rykke.

Det skal I lade være med

At stille spørgsmålene én gang og aldrig igen · billedet ændrer sig, og spørgsmålene bør gentages.
At acceptere tekniske svar uden oversættelse · bed om forklaringen i forretningssprog.
At gøre det til et forhør · så får I kortere og mere forsigtige svar.
At glemme spørgsmålet om, hvad IT har brug for · uden det bliver samtalen ensidig.
At lade svarene ligge · et svar, ingen handler på, var spild af mødetid.

Hvad kan og ikke kan konkluderes

Spørgsmålene giver direktionen et billede af, hvad der er undersøgt, hvor gammelt resultatet er, og om der er fulgt op. De kan ikke vise, om systemerne faktisk holder, og de kan ikke erstatte en undersøgelse udefra. Hvorvidt svarene er gode nok, er sit eget spørgsmål. → Hvordan ved ledelsen, om svarene fra IT er gode nok?