Et softwarehus, der skal igennem en revision, opdager hurtigt, at revisor ikke spørger, om produktet er sikkert. Revisor spørger, om den kontrol, I har beskrevet, faktisk er udført, og om I kan bevise det. Svaret hviler på, at pentestrapporten kun er ét led i beviset: revisor skal også kunne se, at testen var planlagt, at omfanget passede til det beskrevne, og at fundene blev fulgt op. Har I kun rapporten, har I kun en del af historien.
Hvilke revisioner der kan komme
For en SaaS-leverandør kan revisionen komme fra flere sider, og hver har sit eget formål.
- Jeres egen certificering · en revision af jeres ledelsessystem, fx efter ISO 27001, udført af et certificeringsorgan.
- En revisorerklæring · en SOC 2-rapport eller en ISAE-erklæring, som I selv har bestilt til brug for kunderne.
- Kundens revision · kundens egen revisor eller sikkerhedsfunktion, der bruger en aftalt revisionsret.
- Kundens revisors spørgsmål · når kundens regnskabsrevisor vil vide, hvordan I styrer et system, der påvirker kundens tal.
Den generelle vejledning til køberen, der får et spørgsmål fra sin revisor, findes på penetrationtest.dk. Her handler det om jer som leverandør, der skal levere beviset.
Revisor tester kontrollen, ikke produktet
IAASB beskriver ISAE 3402 som en standard for erklæringer om kontroller hos en serviceorganisation, til brug for brugervirksomhederne og deres revisorer. Logikken går igen i andre revisioner: I beskriver jeres kontroller, og revisor vurderer, om beskrivelsen holder, og om kontrollerne virker.
En årlig penetrationstest er i den sammenhæng en kontrol på linje med adgangsstyring og backup. Revisor efterprøver ikke selv produktet. Revisor ser efter, om testen blev gennemført som beskrevet, og om den blev fulgt op. Det betyder, at en rapport med alvorlige fund kan være et godt bevis, hvis opfølgningen er dokumenteret, mens en rapport uden fund kan være et svagt bevis, hvis omfanget ikke passer til det, I har beskrevet. → ISAE 3402 og ISAE 3000
Hvad beviset består af
Saml beviset om testen i én mappe, så det kan lægges frem samlet. Indholdet afhænger af revisionen, men disse dele går igen.
- Den beskrevne kontrol · hvad jeres politik eller kontrolbeskrivelse siger om test og hyppighed.
- Bestillingen · aftalen med testeren med omfang, testperiode og miljø.
- Rapporten · med dato, version og de testede dele af produktet.
- Handlingsplanen · hvem der fik hvilke fund, og hvornår de skulle være rettet.
- Opfølgningen · sager i udviklingens system, retestresultat eller en begrundet beslutning om at acceptere en risiko.
- Godkendelsen · hvem i ledelsen der har set resultatet og opfølgningen.
PCI DSS er et eksempel på en standard, der gør dele af dette til krav i de miljøer, den gælder: krav 11.4.1 nævner opbevaring af testresultater og afhjælpning i mindst tolv måneder, og krav 11.4.4 nævner gentagen test for at bekræfte rettelserne. Andre revisioner kan have andre krav, men det er de samme dokumenter, der efterspørges. → Retestbevis: vis kunden, at fundene er rettet
Beskrivelse, virkelighed og periode
En svaghed i beviset ligger ikke nødvendigvis i testen, men i afstanden mellem det, der står, og det, der er sket. Står der “test af hele platformen hvert år”, og rapporten dækker ét modul, vil revisor notere det. Står der “kritiske fund rettes inden for en bestemt frist”, skal sagerne vise, at fristen er holdt, eller at der er truffet en begrundet beslutning om en undtagelse.
Det er derfor klogt at læse jeres egen kontrolbeskrivelse, før testen bestilles. Passer den ikke længere til produktet, så ret beskrivelsen, før perioden begynder, ikke bagefter. En ændring midt i en revisionsperiode skal forklares. → Et årshjul for sikkerhedstest
Nogle erklæringer dækker en periode, fx en ISAE 3402 type 2. Ligger testen uden for den, kan den ikke bruges som bevis for, at kontrollen virkede i perioden, selv om rapporten er god. Aftal testens tidspunkt med blik på den periode, revisionen dækker, og lad der være tid til opfølgning inden periodens slutning.
Det samme gælder kundens revision. Kommer kunden med en revisionsret, er det rapporten og opfølgningen fra den aftalte periode, der er relevant, ikke den nyeste test, hvis den er lavet efter. → Kunden kræver revisionsret
Fortrolighed over for revisor
Revisor skal kunne se beviset, men det betyder ikke, at alle detaljer skal udleveres som kopi. Aftal, om revisor kan læse den fulde rapport hos jer eller i et delt læsemiljø, og om en kundeversion er nok til den del af revisionen, der går til kunderne. Det skal fremgå, hvad revisor har set, så konklusionen kan følges. Notér også, hvilken udgave af rapporten revisor fik adgang til, og hvornår. Kommer der senere en opdateret version efter en retest, er det tydeligt, hvilken der lå til grund for revisionens konklusion, og hvilken kunderne siden har fået.
Når en revisorerklæring sendes videre til kunderne, er det erklæringen, ikke rapporten, der følger med. Kunden kan stadig bede om en kundeversion af rapporten, men det er en særskilt udlevering. → Hel rapport, resumé eller erklæring
Et tænkt eksempel
Et softwarehus med en platform til ejendomsadministration har en SOC 2-rapport, der dækker et kalenderår. Kontrolbeskrivelsen siger, at platformen testes af en uafhængig tester hvert år, og at kritiske fund rettes inden for en aftalt frist.
Testen gennemføres i marts. Et kritisk fund rettes i april, og retesten bekræfter rettelsen. Et fund af lav alvorlighed accepteres af den tekniske chef med en skriftlig begrundelse. Da revisor beder om beviset i efteråret, ligger aftale, rapport, sager, retest og risikoaccept i samme mappe. Revisor kan følge kontrollen fra beskrivelse til opfølgning uden at bede om noget nyt.
Det skal I lade være med
- Sende rapporten alene · uden opfølgning er beviset ufuldstændigt.
- Beskrive mere test, end I får lavet · revisor holder jer op på beskrivelsen.
- Lægge testen uden for perioden · så kan den ikke bruges i den revision, den var tiltænkt.
- Acceptere risici mundtligt · en undtagelse skal være skrevet ned og godkendt.
- Lade revisor gætte på omfanget · bestillingen skal ligge ved.
Hvad kan og ikke kan konkluderes
En dokumenteret test med opfølgning kan vise revisor, at en beskrevet kontrol er udført og fulgt op i en bestemt periode. Det siger ikke, at produktet er uden svagheder, og det er revisor, der afgør, om beviset er tilstrækkeligt efter den standard, revisionen følger. Teksten er ikke revisionsfaglig vejledning.
Tjekliste til beviset
- ☐ Svarer kontrolbeskrivelsen til den test, der er lavet?
- ☐ Ligger aftale, rapport og handlingsplan samlet?
- ☐ Kan opfølgningen på hvert fund ses?
- ☐ Er accepterede risici skrevet ned og godkendt?
- ☐ Ligger testen inden for revisionsperioden?
- ☐ Er det aftalt, hvordan revisor får adgang til rapporten?
Kilder
- IAASB: Staff Overview, ISAE 3402: erklæringer om kontroller hos en serviceorganisation til brug for brugervirksomhederne og deres revisorer.
- PCI DSS krav 11, gengivet af Microsoft Learn: krav 11.4.1 om opbevaring af testresultater og afhjælpning i mindst tolv måneder og krav 11.4.4 om gentagen test for at bekræfte rettelser.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler om pentestrapporten
Læs også: SOC 2-rapporten og pentesten · Fund i backloggen
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest af SaaS hos Nielco IT