Revisor nævner sikkerhedstest: sådan afklarer I forventningen

En bemærkning fra revisor om manglende sikkerhedstest kan hurtigt blive til en bestilling, der ikke svarer på det, revisor egentlig spurgte om. Afklaringen hviler på to spørgsmål: hvilken type revision eller erklæring er der tale om, og hvilken kontrol eller hvilket system vil revisor se dokumentation for?

Når de to ting er klare, kan I vurdere, om en penetrationstest er det rigtige svar, eller om revisor i virkeligheden efterspørger noget andet, for eksempel dokumentation for processer, adgangsstyring eller opfølgning på kendte sårbarheder.

Hvilken revision taler vi om?

Ordet revisor dækker over flere roller. Den finansielle revisor gennemgår regnskabet og kan i den forbindelse se på de IT-kontroller, der understøtter regnskabsdata. En revisor eller auditor i forbindelse med en ISO 27001-certificering vurderer ledelsessystemet for informationssikkerhed. Og en revisor, der skal afgive en erklæring om en leverandørs kontroller til dennes kunder, ser på de kontroller, erklæringen omfatter.

Hver rolle stiller sine egne spørgsmål, og en penetrationstest passer forskelligt ind. For den finansielle revisor kan spørgsmålet handle om ERP-systemet og adgangen til økonomidata. Ved en ISO-certificering kan det handle om, hvordan virksomheden håndterer tekniske sårbarheder. → ISO 27001-certificering og penetrationstest

Spørg derfor revisor direkte, hvilken opgave bemærkningen hører til, og om den står i et revisionsprotokollat, et ledelsesbrev eller blot blev nævnt på et møde. Det er en enkel afklaring, der sparer jer for at bestille noget, der ikke kan bruges.

Find det konkrete spørgsmål bag bemærkningen

En bemærkning som I bør overveje sikkerhedstest, er ikke en opgavebeskrivelse. Bed revisor om at præcisere: hvilke systemer er det, revisor er optaget af, hvilken kontrol eller hvilket krav henviser bemærkningen til, og hvilken dokumentation vil revisor gerne se?

Svaret kan vise, at revisor efterspørger en penetrationstest af et bestemt system. Det kan også vise, at revisor efterspørger dokumentation for, at virksomheden har en proces for at finde og rette sårbarheder, og at en enkelt test kun er en del af det. Forskellen mellem en praktisk afprøvning og en gennemgang af politikker og processer er beskrevet i → Penetrationstest eller IT-sikkerhedsaudit.

Notér revisors svar. Det gør det lettere at bestille den rigtige opgave og at vise revisor ved næste gennemgang, at bemærkningen er håndteret.

Er det driftsleverandøren, der har ansvaret for de systemer, revisor spørger til, så inddrag leverandøren tidligt. Leverandøren kan have egne test, egne erklæringer eller egne aftaler om sikkerhed, som allerede besvarer en del af spørgsmålet. Det kan også vise sig, at revisor reelt spørger til leverandørens kontroller, og at svaret derfor skal komme derfra. Uden den afklaring risikerer I at bestille en test af noget, I ikke selv råder over.

Hvad en pentestrapport kan vise revisor

En pentestrapport kan dokumentere, at bestemte systemer er afprøvet på et bestemt tidspunkt, af en bestemt part, med et beskrevet scope og en beskrevet metode. Den kan vise, hvilke svagheder der blev fundet, og hvor alvorlige de blev vurderet.

For revisor er scope ofte lige så interessant som fundene. Hvis rapporten handler om webshoppen, men revisor spørger til ERP-systemet, svarer den ikke på bemærkningen. Sørg for, at scope og metode står tydeligt, og at det fremgår, om testen omfattede produktionen eller et testmiljø. → Sådan læser I en pentestrapport

Revisor kan også være optaget af, hvem der udførte testen. Hvis den, der driver systemet, også har testet det, kan det svække dokumentationens værdi i revisors øjne. Spørg, om revisor har forventninger til testerens uafhængighed.

Tidspunktet kan også have betydning. Revisor ser typisk på en bestemt periode, for eksempel et regnskabsår eller den periode, en erklæring dækker. En test, der ligger lige efter periodens afslutning, siger ikke nødvendigvis noget om, hvordan systemerne stod i løbet af perioden. Afklar med revisor, hvornår testen skal ligge for at kunne indgå i den gennemgang, den skal understøtte, og planlæg den, så der også er tid til opfølgning, inden revisor kommer igen.

Dokumentationen omkring rapporten

En rapport alene viser, at der blev testet. Den viser ikke, hvad virksomheden gjorde bagefter. Revisor kan være mindst lige så interesseret i opfølgningen som i selve testen.

Saml derfor dokumentationen omkring rapporten. En handlingsplan med ejere og frister viser, at fundene er placeret. → Fra rapport til handlingsplan

Beslutninger om fund, der ikke rettes, bør være skrevet ned med begrundelse og en ansvarlig, der har godkendt dem. → Risikoaccept

Efterprøvede rettelser viser, at de vigtigste fund faktisk er lukket. En melding fra driftsleverandøren om, at noget er rettet, er ikke det samme som en kontrol. → Retest efter penetrationstest

Tilsammen giver de en dokumentationskæde, som revisor kan følge fra fund til beslutning til resultat. Den kæde siger mere om virksomhedens håndtering end en lang rapport uden opfølgning.

Revisor vurderer, testeren afprøver

Det er vigtigt at holde rollerne adskilt. Revisor vurderer, om virksomhedens kontroller og dokumentation lever op til det, revisionen eller erklæringen kræver. Testeren afprøver, om bestemte systemer kan udnyttes under aftalte forhold. Den ene rolle kan ikke erstatte den anden.

Det betyder også, at testeren ikke kan love, at revisor vil acceptere rapporten. Testeren kan beskrive opgaven, så den passer til revisors spørgsmål, men det er revisor, der vurderer, om dokumentationen er tilstrækkelig. Sammenhængen mellem standarder og test er beskrevet i → Penetrationstest og standarder.

Overvej at vise revisor opgavebeskrivelsen, før testen bestilles. Så kan revisor give en tilbagemelding på, om scope og leverance svarer til forventningen, mens det stadig er muligt at justere.

Det skal I lade være med

At bestille ud fra en løs bemærkning · Afklar revisionstype, system og kontrol først.
At sende en rapport med forkert scope · En test af webshoppen svarer ikke på et spørgsmål om ERP-systemet.
At aflevere rapporten uden opfølgning · Handlingsplan, risikoaccept og retest hører med.
At lade testeren love revisors accept · Det er revisor, der vurderer dokumentationen.
At blande audit og penetrationstest sammen · De besvarer forskellige spørgsmål.
At glemme at notere revisors svar · Den skriftlige afklaring er grundlaget for næste gennemgang.

Hvad kan og ikke kan konkluderes

En penetrationstest med tilhørende opfølgning kan give revisor dokumentation for, at bestemte systemer er afprøvet, og at fundene er håndteret. Den kan understøtte en vurdering af, hvordan virksomheden arbejder med tekniske sårbarheder.

Den kan ikke i sig selv dokumentere, at virksomheden opfylder et helt regelsæt eller en hel standard, og den kan ikke afgøre, hvad revisor accepterer.