Direktionen har bedt IT-chefen om et oplæg: skal virksomheden have en penetrationstest, og i givet fald af hvad? Beslutningen er ledelsens, men den bliver ikke bedre end det grundlag, IT lægger på bordet. Et godt oplæg hviler på fire ting: et ærligt billede af, hvad der findes, hvad I allerede ved er svagt, hvilke valg der er mellem forskellige test, og hvad det kræver af driften bagefter.
IT skal ikke sælge testen til ledelsen eller fraråde den. Opgaven er at gøre beslutningen oplyst, så ledelsen ved, hvad den vælger, og hvad den vælger fra.
Hvor grænsen går
Spørgsmålet om, hvorvidt virksomheden skal teste, hvad den får ud af det, og hvordan det passer ind i risiko og budget, er ledelsens. Den side af sagen er beskrevet for direktører og bestyrelser på sikkerhedstesten.dk. Her handler det om IT-afdelingens bidrag: de oplysninger, som kun IT kan levere, og som ledelsen ikke kan beslutte uden.
NCSC (UK) har udgivet en værktøjskasse til bestyrelser om cybersikkerhed, der netop lægger vægt på, at ledelsen kan stille de rigtige spørgsmål. IT-afdelingens oplæg er stedet, hvor de spørgsmål får konkrete svar.
Billedet af det, der findes
Ledelsen kan ikke vælge et scope uden at vide, hvad der kan testes. Giv et overblik i forretningstermer, ikke som en systemliste.
- Det, der vender ud mod internettet · hjemmeside, webshop, fjernadgang og mail, og hvad de bruges til. → Overblik over internetvendte systemer
- Det interne netværk · kontorer, lokationer og om alt kan nå alt.
- Identitet og cloud · katalog, Microsoft 365 eller andre lejere og de vigtigste cloudtjenester.
- Forretningskritiske systemer · det, virksomheden står stille uden.
- Systemer hos andre · det, leverandører drifter for jer, og som I måske ikke selv må teste.
Vær ærlig om huller i overblikket. Hvis I ikke ved, hvad der findes i et område, er det i sig selv en oplysning, ledelsen skal have.
Peg også på, hvilke områder der betyder mest for forretningen, hvis de bliver ramt. IT kender systemerne, men ledelsen kender konsekvenserne. Et kort afsnit om, hvad der ville ske, hvis et bestemt system var utilgængeligt i en uge, eller hvis dets data blev læst af udenforstående, hjælper ledelsen med at vælge, hvor en test giver mest værdi. Det er ledelsen, der vægter konsekvenserne; IT skal blot sørge for, at de er nævnt.
Det, I allerede ved
En test skal ikke bruges til at få bekræftet, hvad IT allerede ved. Fortæl ledelsen, hvilke svagheder I kender: forældede systemer, manglende adskillelse i netværket, konti med for mange rettigheder eller fund fra tidligere test, der stadig er åbne. → Kendte svagheder før testen
Det kan føles som at indrømme fejl. Men ledelsen bør vide, at nogle problemer kan løses uden en test, og at en test, der finder dem igen, ikke giver ny viden. Pengene kan måske bruges bedre på at rette først og teste bagefter.
Nævn også de krav, der kommer udefra, og hvad de præcist siger. Hvis en større kunde, et forsikringsselskab eller en samarbejdspartner har spurgt til test, så læg spørgsmålet frem i sin egentlige ordlyd. Ledelsen skal kunne se forskel på et krav om en uafhængig test af bestemte systemer og et mere generelt spørgsmål om, hvordan sikkerheden kontrolleres. Det første afgrænser testen; det andet giver ledelsen mere frihed til at vælge.
Valgmulighederne, ikke ét forslag
Giv ledelsen to eller tre muligheder i stedet for ét færdigt forslag. Det gør beslutningen til ledelsens og viser, hvad der fravælges.
- Smal test · fx kun de internetvendte systemer, som svar på det mest åbenlyse spørgsmål.
- Bredere test · også det interne net og identiteten, hvis spørgsmålet er, hvad en angriber kan nå efter første fodfæste.
- Målrettet test · et bestemt system, som kunder eller forsikring spørger til.
For hver mulighed: hvilket spørgsmål den svarer på, og hvad den ikke svarer på. Beskriv også, hvad der sker med driften i testperioden, fx om der testes i arbejdstiden, og om der er systemer, der kan blive påvirket. Hvad der påvirker omfanget, er blandt andet antallet af systemer, adresser og brugere, testform og krav til rapporten. Et konkret beløb fås ved at bede om pris og tilbud på et beskrevet scope.
Det, testen kræver af driften
Ledelsen skal vide, at en test ikke er en ydelse, man køber og glemmer. Den trækker på IT før, under og efter.
- Forberedelse · dokumentation, testkonti, backup og aftaler med leverandører. → Forberedelse i IT-afdelingen
- Testperioden · en kontaktperson, der kan nås, og beredskab, hvis noget går galt.
- Rettelserne · tid til at rette fundene, og måske projekter, der kræver budget.
- Opfølgning · kontrol af rettelserne og eventuelt en ny test.
Den sidste del bliver let glemt i et oplæg. NCSC understreger, at risikovurdering og beslutninger om rettelser er organisationens eget ansvar. En test uden tid og budget til at rette giver en rapport, men ikke mere sikkerhed. → Rapporten i næste års driftsplan
Når ledelsen har besluttet
Skriv beslutningen ned: hvad der testes, hvorfor, og hvad der bevidst er fravalgt. Det bliver jeres reference, når rapporten kommer, og ledelsen spørger, hvorfor et område ikke var med. Aftal, hvem i ledelsen der godkender testen formelt, og hvem der kan træffe beslutning, hvis testen skal stoppes. Aftal også, hvordan ledelsen vil have resultatet præsenteret, så rapporten ikke ender som et teknisk dokument, ingen i direktionen læser. → Status til ledelsen
Det skal I lade være med
- At beslutte for ledelsen · IT leverer grundlaget, ledelsen vælger.
- At skjule kendte svagheder · de hører med i grundlaget.
- At præsentere ét forslag som det eneste · vis valgmuligheder og fravalg.
- At udelade rettelserne · en test kræver ressourcer bagefter.
- At tale i tekniske detaljer · forklar, hvad hvert område betyder for forretningen.
- At love, hvad testen vil vise · ingen kan vide det på forhånd.
Hvad kan og ikke kan konkluderes
Et godt oplæg fra IT gør ledelsens beslutning oplyst. Det kan ikke afgøre, om virksomheden bør teste, eller hvor meget den bør bruge. Den vurdering afhænger af risiko, økonomi og krav fra omverdenen, som ledelsen kender bedre end IT. Oplægget viser heller ikke, hvor sikker virksomheden er; det viser, hvad IT ved, og hvad en test kan afklare.
Tjekliste til IT-afdelingens oplæg
- ☐ Er der et overblik over systemer i forretningstermer?
- ☐ Er huller i overblikket nævnt?
- ☐ Er kendte svagheder og åbne fund med?
- ☐ Er der to eller tre valgmuligheder med spørgsmål og fravalg?
- ☐ Er det beskrevet, hvad der påvirker omfanget?
- ☐ Er ressourcer til forberedelse, testperiode og rettelser med?
- ☐ Er der aftalt, hvordan beslutningen skrives ned?
Kilder
- NCSC (UK): Cyber Security Toolkit for Boards: værktøjskasse til bestyrelser om styring af cybersikkerhed og spørgsmål, ledelsen kan stille.
- NCSC (UK): Penetration testing: risikovurdering og beslutninger om rettelser er organisationens eget ansvar.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Rapporten i næste års driftsplan · Hyppighed af ekstern test
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
