Et årshjul for sikkerhedstest i et softwarehus

Når testen bliver planlagt fra gang til gang, kan den ende med at ligge, hvor der tilfældigvis var plads, og rapporten er så enten for gammel eller for ny til de kunder, der spørger. Et årshjul hviler på en enkel tanke: testen er ikke en enkelt begivenhed, men et forløb med forberedelse, test, rettelser, retest og opdaterede dokumenter til kunderne, og hvert led skal ligge, så det passer med jeres kunders kalender.

Hjulet behøver ikke være kompliceret. Det skal vise, hvornår de faste ting sker, hvem der har ansvaret, og hvordan testen spiller sammen med fornyelser, spørgeskemaer og jeres egne releases. Et regneark eller en fælles kalender er ofte nok.

Start med kundernes kalender

Det første, hjulet skal rumme, er de datoer, I ikke selv bestemmer. Gennemgå kunderne og notér:

Fornyelser · hvornår de største kontrakter skal forlænges, og om kunderne beder om den nyeste rapport i den forbindelse.
Årlige spørgeskemaer · hvornår kunderne sender deres faste sikkerhedsspørgeskema.
Krav om rapportens alder · om nogle kunder kræver, at rapporten ikke er ældre end en bestemt periode.
Kundernes egne revisioner · hvornår de skal dokumentere deres leverandører over for egen revisor.

Kunder, der henviser til GDPR, kan pege på artikel 32, hvor der står om en procedure for regelmæssig afprøvning, vurdering og evaluering af sikkerheden. Forordningen fastsætter ikke et interval, men kravet om regelmæssighed er en af grundene til, at kunderne spørger hvert år. → GDPR artikel 32

Når datoerne står samlet, kan de vise, at kundernes spørgsmål klumper sig sammen i bestemte perioder. Testen skal ligge, så den rapport, kunderne får i de perioder, er så frisk som muligt, og så der er tid til at rette fund først. → Rapport under et år

Leddene i hjulet

Et årshjul for test kan bestå af disse led. Rækkefølgen er fast; tidspunkterne er jeres egne:

Forberedelse · gennemgang af årets ændringer, opdatering af omfanget og opsætning af testkunder og roller.
Den faste test · den brede penetrationstest af produktets kerne.
Rettelser · tid til, at udviklingsteamet kan rette de vigtigste fund.
Retest · bekræftelse af rettelserne, så kunderne kan se, at fundene er lukket.
Dokumenter til kunderne · opdateret resumé eller erklæring, svarbibliotek og eventuel tillidsside.
Løbende vurderinger · faste punkter i årets løb, hvor ændringer i produktet gennemgås for behovet for en afgrænset test.

Det fjerde led er det, der kan blive klemt. Hvis retesten først ligger efter, at kunderne har fået rapporten, viser den rapport, de har, åbne fund. Planlæg derfor tid til rettelser og retest, før rapporten skal bruges. → Retest efter rettelser i en ny release

Et tænkt årshjul

Et softwarehus har mange kontraktfornyelser i første kvartal og modtager de fleste årlige spørgeskemaer i foråret. Hjulet kunne så se sådan ud:

Efterår · forberedelse og den faste test, med rettelser lige efter.
Vinter · retest, opdateret erklæring og nye svar i svarbiblioteket.
Første kvartal · fornyelserne får den nye rapport og retestbeviset.
Forår · skemaerne besvares med en rapport, der er få måneder gammel.
Løbende · en vurdering af væsentlige ændringer i forbindelse med de større releases.

Eksemplet er tænkt. Jeres hjul afhænger af jeres egne kunder, jeres releaseplan og jeres budgetår. Det vigtige er, at testen er placeret ud fra, hvornår rapporten skal bruges, og ikke ud fra, hvornår der var tid. → Samme skema hvert år

Releases og afgrænsede test i hjulet

Hjulet skal også rumme det, der ikke kan planlægges på dagen. En større ny funktion eller en ny integration kan kræve en afgrænset test midt i året. Læg derfor faste punkter ind, hvor produktejeren og den sikkerhedsansvarlige ser på kommende releases og beslutter, om noget skal testes særskilt. → Ændringer, der kræver en ny test

Sammenhængen mellem den faste test og de afgrænsede er beskrevet for sig. Hjulet er stedet, hvor de to får en plads i kalenderen. → Test og releases

Hjulet og certificeringer

Har I ISO 27001 eller en SOC 2-rapport, har I allerede en årlig rytme med revisioner og ledelsens gennemgang. Det kan være en fordel at lægge testen, så resultatet og opfølgningen kan indgå i den rytme. Testen bliver så både dokumentation over for kunderne og et input til jeres egen styring af sikkerheden. → ISO 27001 i softwarehuset

Budget, tid og ansvar

Testen skal også have en plads i budgettet, og budgettet kan blive lagt måneder før testen. Notér derfor i hjulet, hvornår næste års test skal besluttes, og hvad der påvirker omfanget: hvor mange produkter og moduler der skal med, hvor mange roller og integrationer, om der er afgrænsede test i løbet af året, og om retest skal indgå. Med de oplysninger klar kan I bede om → pris og tilbud i god tid.

Afsæt også tid hos jer selv. Forberedelse, rettelser og opdatering af dokumenter tager tid fra udviklerne og fra dem, der svarer kunderne, og den tid skal stå i planen, ikke kun den eksterne test.

Endelig virker et årshjul kun, hvis nogen ejer det. Det behøver ikke være en sikkerhedschef. I et lille softwarehus kan det være den tekniske direktør eller produktchefen. Det vigtige er, at én person sørger for, at hvert led bliver sat i gang til tiden, og at datoerne bliver opdateret, når kunderne eller produktet ændrer sig. Den person skal også vide, hvem der skal have besked, når et led er færdigt, fx sælgerne, når den nye erklæring er klar til brug.

Det skal I lade være med

Lægge testen, hvor der er plads · læg den ud fra, hvornår rapporten skal bruges.
Glemme tiden til rettelser og retest · ellers får kunderne en rapport med åbne fund.
Opdatere rapporten og glemme de afledte dokumenter · svarbibliotek, erklæring og tillidsside skal følge med.
Lade hjulet stå uændret år efter år · nye kunder og nye krav flytter datoerne.
Lade hjulet erstatte vurderingen af ændringer · væsentlige ændringer kan ikke vente på næste faste test.

Hvad kan og ikke kan konkluderes

Et årshjul viser, at testen er planlagt, og at rapporten er klar, når kunderne spørger. Det viser ikke, at produktet er sikkert mellem to test, og det siger intet om ændringer, der ikke er vurderet. Hjulet er en plan, ikke dokumentation i sig selv.

Tjekliste til årshjulet

☐ Står kundernes fornyelser, skemaer og krav om rapportens alder i kalenderen?
☐ Er den faste test placeret ud fra, hvornår rapporten skal bruges?
☐ Er der tid til rettelser og retest, før rapporten udleveres?
☐ Er opdatering af erklæring, svarbibliotek og tillidsside med i hjulet?
☐ Er der faste punkter for vurdering af væsentlige ændringer?
☐ Har hjulet en ejer?

Kilder

Forordning (EU) 2016/679 (GDPR), artikel 32, stk. 1, litra d: en procedure for regelmæssig afprøvning, vurdering og evaluering af effektiviteten af de tekniske og organisatoriske foranstaltninger.

Senest gennemgået: oktober 2026.